From bclaise@cisco.com Sat Feb 1 02:20:30 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768F91ACCDE; Sat, 1 Feb 2014 02:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAoLsPNm8sK3; Sat, 1 Feb 2014 02:20:28 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id CA02E1A1F66; Sat, 1 Feb 2014 02:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5103; q=dns/txt; s=iport; t=1391250024; x=1392459624; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=73xsq5RhwJKTMfxYjHmvoT/L/vddripmNZiC2k2bqgA=; b=MG/eZp4tYO2MUvfgPdp/NL8aeClZrz9LjoDoLSb8WE+Wrzlboay0we3k FTnGbsl0r1r964paLO/67hCxtQ80ekofjsJTFBaLHpnFBOU5x0Ip720RT UrPYfY1gZpimn7W3Tt3DY5fRn/NA7A07RmSTOLn4LNJWTDBlrRHpe4M34 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAFfJ7FKQ/khR/2dsb2JhbABYgwy7Z4MIgQYWdIIlAQEBBDhADQQdDxYPCQMCAQIBNw4GAQwIAQGIAc0qF48QhDgBA5gqhkiLWYMuOw X-IronPort-AV: E=Sophos;i="4.95,760,1384300800"; d="scan'208";a="4512083" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 01 Feb 2014 10:20:22 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s11AKL2K007264; Sat, 1 Feb 2014 10:20:21 GMT Message-ID: <52ECCA65.4000105@cisco.com> Date: Sat, 01 Feb 2014 11:20:21 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20140130234822.4124.16034.idtracker@ietfa.amsl.com> In-Reply-To: <20140130234822.4124.16034.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140130234822.4124.16034.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [pm-dir] IESG-AGENDA-DIST] Summarized Agenda for the 2014-02-06 IESG Teleconference X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Feb 2014 10:20:30 -0000 Dear all, Please find below the agenda of the Feb 6th IESG telechat. Please send your questions, comments, and concerns before Feb 5th COB. Thanks and Regards, Benoit. -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-alto-protocol-25 - IETF stream ALTO Protocol (Proposed Standard) Token: Spencer Dawkins IANA Review: IANA - Review Needed Consensus: Unknown Last call expires: 2014-02-04 o draft-ietf-p2psip-rpr-11 - IETF stream An Extension to REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-p2psip-drr-11 - IETF stream An Extension to REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-xrblock-rtcp-xr-qoe-13 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) Blocks for MOS Metric Reporting (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-ancp-mc-extensions-14 - IETF stream Multicast Control Extensions for ANCP (Proposed Standard) Token: Ted Lemon IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-stox-core-09 - IETF stream Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-stox-presence-07 - IETF stream Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Unknown 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items o draft-farrell-perpass-attack-05 - IETF stream Pervasive Monitoring is an Attack (Best Current Practice) Token: Jari Arkko IANA Review: IANA OK - No Actions Needed Consensus: Unknown Was deferred by Joel Jaeggli on 2014-01-23 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 2.3.3 For Action o status-change-5343-5590-5591-6353-to-internet-standard-01 - IETF stream Progressing RFCs 5343, 5590, 5591, and 6353 to Internet Standard (None) Token: Sean Turner 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-rtgwg-cl-requirement-15 - IETF stream Requirements for Advanced Multipath in MPLS Networks (Informational) Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-insipid-session-id-reqts-09 - IETF stream Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks (Informational) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-clue-telepresence-requirements-07 - IETF stream Requirements for Telepresence Multi-Streams (Informational) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Yes 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-crocker-id-adoption-05 - IETF stream Creating an IETF Working Group Draft (Informational) Token: Barry Leiba IANA Review: IANA OK - No Actions Needed Consensus: Unknown Last call expires: 2014-01-31 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 3.4.3 For Action o conflict-review-saintandre-jabberid-00 IETF conflict review for draft-saintandre-jabberid draft-saintandre-jabberid-12 The Jabber-ID Header Field (ISE: Informational) Token: Jari Arkko o conflict-review-irtf-dtnrg-tcp-clayer-00 IETF conflict review for draft-irtf-dtnrg-tcp-clayer draft-irtf-dtnrg-tcp-clayer-08 Delay Tolerant Networking TCP Convergence Layer Protocol (IRTF: Experimental) Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o TURN Revised and Modernized (tram) 4.1.2 Proposed for Approval o Public Notary Transparency (trans) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval NONE From vinayakh@gmail.com Sun Feb 2 06:04:38 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BA81A00D3 for ; Sun, 2 Feb 2014 06:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymdySjwdJxmC for ; Sun, 2 Feb 2014 06:04:36 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 959E71A000A for ; Sun, 2 Feb 2014 06:04:36 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so6110967pab.21 for ; Sun, 02 Feb 2014 06:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jBQNhFSVxLKL84PNQaA4FT7MIFynO9tzFZFZOEetOag=; b=ucheFjh5MfH/f6UpN+0rV2q9wcxKkkSx0UrUYO16YzikeM3bgIwSdzaZk3A6D1Svpb 5eG0fseXQnOjdBPpD1CJl81Qpeq9AtkAmhkOF7pyokqKDGU5yhi6vlEVgtuA+IEBcbO5 ej1ArLJ0be0Xpbn5OKMO+d5b1sto00PPsdG8sVR6/dJl1uqsdPpw0THFDmz42BcbF+47 jH5wydQMWU4obHwl9uX+1a9NSr/NBPaEQV2Xw+Fipt8653auq26gYeKBxx0nVlT0uget WLkkvNZxhDcA7jC/P7muZokrRGJfSaJOxCmZLmA0m/+nKe8FmEL5PzTh2apO78IPD02v 2Snw== MIME-Version: 1.0 X-Received: by 10.68.236.100 with SMTP id ut4mr31669465pbc.29.1391349872382; Sun, 02 Feb 2014 06:04:32 -0800 (PST) Received: by 10.66.126.2 with HTTP; Sun, 2 Feb 2014 06:04:32 -0800 (PST) Date: Sun, 2 Feb 2014 19:34:32 +0530 Message-ID: From: Vinayak Hegde To: "pm-dir@ietf.org" , varun.singh@iki.fi Content-Type: multipart/alternative; boundary=047d7b33d99ce6e8dc04f16ce22f Subject: [pm-dir] Review of XRBlock RTCP XR Bytes Discarded Metric X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:04:38 -0000 --047d7b33d99ce6e8dc04f16ce22f Content-Type: text/plain; charset=ISO-8859-1 Draft link : http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 Comments: Conforms to RFC 6390 metric reporting template In Section 3 you state: 'E' bit is set to '1' if it reports bytes discarded due to early arrival and is set to '0' if it reports bytes discarded due to late arrival. If a duplicate packet is received and discarded, these duplicate packets are ignored and not reported. In case both early and late discarded packets shall be reported, two Bytes Discarded report blocks MUST be included. In a measurement it is likely to have both types of discarded packets, early as well as late arrival, why not just multiplex one BDR block with both types (use two bits instead of 1 bit) and another 32-bit block for the number of packets. What has been your experience when doing measurements ? Thanks Vinayak --047d7b33d99ce6e8dc04f16ce22f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Conforms to RFC 6390 metric reporting template=

In Section 3 you state:
=A0=A0=A0
=A0=A0 'E' bit is = set to '1' if it reports bytes discarded due to early
=A0=A0 arr= ival and is set to '0' if it reports bytes discarded due to late =A0=A0 arrival.=A0 If a duplicate packet is received and discarded, these=A0=A0 duplicate packets are ignored and not reported.=A0 In case both ea= rly
=A0=A0 and late discarded packets shall be reported, two Bytes Disca= rded
=A0=A0 report blocks MUST be included.

In a measurement it is likely to have both types of discarded packets, = early as well as late arrival, why not just multiplex one BDR block with bo= th types (use two bits instead of 1 bit) and another 32-bit block for the n= umber of packets. What has been your experience when doing measurements ?
Thanks
Vinayak
--047d7b33d99ce6e8dc04f16ce22f-- From vinayakh@gmail.com Sun Feb 2 06:52:21 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0571A00E0 for ; Sun, 2 Feb 2014 06:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDIsd7hixAcd for ; Sun, 2 Feb 2014 06:52:20 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 123481A00DE for ; Sun, 2 Feb 2014 06:52:20 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so5942822pde.41 for ; Sun, 02 Feb 2014 06:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kUNGUgQ+MGgDHHp/NoB87617KwOYauIfWpgrN8wCYQQ=; b=gcKXOXQtF76tM60dk0GMwAdinwcOEE4aYFOo9QJBuyGloGdHRfgQUAYDyrescO4rRe zG5v++0GNyCmbl2KtTkH+FyXYDjfTcQ2ia2mCR5Xl3piEvJ/+4+4GnJ1mFFYgfjMG/7O l8r8KToAVjxQb9B6aDLOzHjzMwDyhmG/sChWLJedVHQdhbMqDAGc8tswQ44EZ3Kw/mAx MwLdAnaetHbffTH3PiIZeOJB2p0YThTbwtAbATK239H1JqIkbJ8Ffi1iCabFB1nrl6Zz elFXEV9vGBAdNMlyRRwafAkb79AnjxJkHoM31nelCzyZK2cqXK5pHr/8weWQ+Yrts8+b g1Eg== MIME-Version: 1.0 X-Received: by 10.68.244.229 with SMTP id xj5mr32138106pbc.108.1391352735910; Sun, 02 Feb 2014 06:52:15 -0800 (PST) Received: by 10.66.126.2 with HTTP; Sun, 2 Feb 2014 06:52:15 -0800 (PST) Date: Sun, 2 Feb 2014 20:22:15 +0530 Message-ID: From: Vinayak Hegde To: "pm-dir@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e07e394d3b104f16d8d26 Subject: [pm-dir] Review of RTP usage Draft X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 14:52:22 -0000 --047d7b2e07e394d3b104f16d8d26 Content-Type: text/plain; charset=ISO-8859-1 Draft Link : http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-11 Comments: None. This draft refers to RTCP XR blocks drafts/RFCs and the frameworks for them. We have been reviewing them separately. The draft also does not contain any new definition of performance metrics. Hence no check RFC 6390 conformance arises. Thanks Vinayak --047d7b2e07e394d3b104f16d8d26 Content-Type: text/html; charset=ISO-8859-1
This draft refers to RTCP XR blocks drafts/RFCs and the frameworks for them. We have been reviewing them separately. The draft also does not contain any new definition of performance metrics. Hence no check RFC 6390 conformance arises.

Thanks
Vinayak
--047d7b2e07e394d3b104f16d8d26-- From bclaise@cisco.com Sun Feb 2 14:07:24 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87C51A010C for ; Sun, 2 Feb 2014 14:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.436 X-Spam-Level: X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPJTldog_wyI for ; Sun, 2 Feb 2014 14:07:24 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7E1A010B for ; Sun, 2 Feb 2014 14:07:23 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s12M7Ire003004 for ; Sun, 2 Feb 2014 23:07:18 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s12M71wr016247 for ; Sun, 2 Feb 2014 23:07:11 +0100 (CET) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id s12M6wbD009881 for pm-dir@ietf.org; Sun, 2 Feb 2014 23:06:58 +0100 (CET) Date: Sun, 2 Feb 2014 23:06:58 +0100 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20140202220658.GA9879@sweet-brew-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [pm-dir] Performance metrics doctors generated email X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 22:07:25 -0000 Dear all, This is an automatically generated email. It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference. It also lists all the IETF internet-drafts that contain "performance metric". Regards, Benoit =========================================================== Normative References -------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00Active draft-ietf-xrblock-rtcp-xr-psi-decodability-00 Active draft-ietf-xrblock-rtcp-xr-qoe-13 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-07 In IESG processing - ID Tracker state drafts containing performance metric ------------------------------------ draft-ietf-alto-deployments-08 Active draft-ietf-cdni-footprint-capabilities-semantics-01Active draft-ietf-idr-te-pm-bgp-00 Active draft-ietf-ippm-2330-update-01 Active draft-ietf-ippm-lmap-path-01 Active draft-ietf-ippm-model-based-metrics-01 Active draft-ietf-ippm-rate-problem-05 Active draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-lmap-use-cases-02 Active draft-ietf-mmusic-sdp-mux-attributes-00 Active draft-ietf-nvo3-framework-05 In IESG processing - ID Tracker state draft-ietf-opsawg-oam-overview-13 Active draft-ietf-pce-pcep-service-aware-02 Active draft-ietf-ppsp-base-tracker-protocol-03 Active draft-ietf-ppsp-peer-protocol-08 Active draft-ietf-rtcweb-rtp-usage-11 Active draft-ietf-trill-loss-delay-01 Active draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00Active draft-ietf-xrblock-rtcp-xr-psi-decodability-00 Active draft-ietf-xrblock-rtcp-xr-qoe-13 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-07 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xt-discard-metrics-00 Active From varun@comnet.tkk.fi Sun Feb 2 13:52:23 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBABB1A010F for ; Sun, 2 Feb 2014 13:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QNUr_Rtgr_G for ; Sun, 2 Feb 2014 13:52:20 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 49B7F1A010E for ; Sun, 2 Feb 2014 13:52:19 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 88C6F271277_2EEBE0EB; Sun, 2 Feb 2014 21:52:14 +0000 (GMT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 3D38F27127C_2EEBE0EF; Sun, 2 Feb 2014 21:52:14 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 23F6E1E0C7; Sun, 2 Feb 2014 23:52:14 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dGp53S-hdnGO; Sun, 2 Feb 2014 23:52:08 +0200 (EET) Received: from [192.168.0.12] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 5CE331E07D; Sun, 2 Feb 2014 23:52:08 +0200 (EET) Content-Type: multipart/alternative; boundary="Apple-Mail=_E6C5182D-AF09-48A4-AFC4-6DD411E1E761" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Varun Singh In-Reply-To: Date: Sun, 2 Feb 2014 23:52:07 +0200 Message-Id: <19D27AD4-7056-4B57-AEE0-49EABAE893EF@comnet.tkk.fi> References: To: Vinayak Hegde X-Mailer: Apple Mail (2.1827) X-Mailman-Approved-At: Sun, 02 Feb 2014 16:51:47 -0800 Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Review of XRBlock RTCP XR Bytes Discarded Metric X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Feb 2014 21:52:23 -0000 --Apple-Mail=_E6C5182D-AF09-48A4-AFC4-6DD411E1E761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Vinayak, Thank you for the review, comments inline Regards, Varun ---- http://www.netlab.tkk.fi/~varun On 2.2.2014, at 16.04, Vinayak Hegde wrote: > Draft link : = http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metr= ic-01 >=20 > Comments: > Conforms to RFC 6390 metric reporting template >=20 > In Section 3 you state: > =20 > 'E' bit is set to '1' if it reports bytes discarded due to early > arrival and is set to '0' if it reports bytes discarded due to late > arrival. If a duplicate packet is received and discarded, these > duplicate packets are ignored and not reported. In case both early > and late discarded packets shall be reported, two Bytes Discarded > report blocks MUST be included. >=20 > In a measurement it is likely to have both types of discarded packets, = early as well as late arrival, why not just multiplex one BDR block with = both types (use two bits instead of 1 bit) and another 32-bit block for = the number of packets. What has been your experience when doing = measurements ? Depending on the use case and the measurement interval, an endpoint may = see both early and late discards. For example in congestion control of = real-time video, the feedback is sent often (at max multiples of RTT) = and it is unlikely both types of discards would occur simultaneously. = For congestion control, we=92ve not seen much reason to multiplex the = report blocks. As I see it, the main application for this measurement = block is reporting overuse when congestion occurs and helps the sender = calculate the goodput.=20 Is there a specific use-case that would benefit from multiplexed = reporting?=20 It was discussed in the WG before: brief glance at the archive revealed = two mails (search for E-flag or bit): http://www.ietf.org/mail-archive/web/xrblock/current/msg00550.html http://www.ietf.org/mail-archive/web/xrblock/current/msg00583.html > Thanks > Vinayak --Apple-Mail=_E6C5182D-AF09-48A4-AFC4-6DD411E1E761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Vinayak,

Thank you = for the review, comments = inline

Regards,
Conforms to RFC 6390 metric reporting = template

In Section 3 you state:
    =
   'E' bit is set to '1' if it reports bytes discarded due = to early
   arrival and is set to '0' if it reports bytes = discarded due to late
   arrival.  If a duplicate packet is received and = discarded, these
   duplicate packets are ignored and not = reported.  In case both early
   and late discarded = packets shall be reported, two Bytes Discarded
   report = blocks MUST be included.

In a measurement it is likely to have both types of discarded = packets, early as well as late arrival, why not just multiplex one BDR = block with both types (use two bits instead of 1 bit) and another 32-bit = block for the number of packets. What has been your experience when = doing measurements = ?

Depending = on the use case and the measurement interval, an endpoint may see both = early and late discards. For example in congestion control of real-time = video, the feedback is sent often (at max multiples of RTT) and it is = unlikely both types of discards would occur simultaneously. For = congestion control, we=92ve not seen much reason to multiplex the report = blocks. As I see it, the main application for this measurement block is = reporting overuse when congestion occurs and helps the sender calculate = the goodput. 

Is there a specific use-case = that would benefit from multiplexed = reporting? 

It was discussed in the WG = before: brief glance at the archive revealed two mails (search for = E-flag or bit):
http://www.ietf.org/mail-archive/web/xrblock/current/msg00550.html


Thanks
Vinayak
= --Apple-Mail=_E6C5182D-AF09-48A4-AFC4-6DD411E1E761-- From bclaise@cisco.com Thu Feb 6 06:09:06 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5D11A03C9 for ; Thu, 6 Feb 2014 06:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.035 X-Spam-Level: X-Spam-Status: No, score=-15.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJdEG3Kjwz_i for ; Thu, 6 Feb 2014 06:09:04 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BB8241A013E for ; Thu, 6 Feb 2014 06:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5247; q=dns/txt; s=iport; t=1391695744; x=1392905344; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=oDMNHRHbFXji69BjIUs4+PgCnMK4WESaTdKooRyJAVs=; b=OB+dWyfZtbOvH2hoZYfa73TvvBWPEQ6mFrJktBS3VHH3ASOK/dV99DOp WU6mE4PgzS2ndpiVt3FSKbeKlgBvLJ5y92tiK69fZPGs5IzmKAAbA5xN0 e7KPqxU0mvf4lEMxriBOTwbM57ut67e8SVhOQLc5Fa/2dnUik78LYNxPG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFABSX81KrRDoH/2dsb2JhbABZgww4g1i7cIEJFnSCJQEBAQQjVQ0EHAMBAgoWCwICCQMCAQIBOwIIBg0GAgEBBYd7Dq0VoSAXjhgRAS4RGAaCaYFJBIlJjmKBMoUWi1mBb4FfG4E1 X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208,217";a="105045542" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 06 Feb 2014 14:08:42 +0000 Received: from [10.21.126.172] (sjc-vpn6-1708.cisco.com [10.21.126.172]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16E8fFt006531 for ; Thu, 6 Feb 2014 14:08:41 GMT Message-ID: <52F39769.1040105@cisco.com> Date: Thu, 06 Feb 2014 06:08:41 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "pm-dir@ietf.org" References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> In-Reply-To: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050202040902000304020606" Subject: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:09:06 -0000 This is a multi-part message in MIME format. --------------050202040902000304020606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit PM-Dir, I believe that we need a little bit of consistency regarding the naming convention for the perf. metrics. Specifically because those xrblock perf. metrics should be the basis for an IETF registry. Feedback? Regards, Benoit -------- Original Message -------- Subject: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) Date: Wed, 5 Feb 2014 22:20:33 -0800 From: Benoit Claise To: The IESG CC: , Benoit Claise has entered the following ballot position for draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The metric names in the registry are not specific enough: payload type, calculation identifier metric, segment type, and potentially MOS. I guess they should say something about RTP. Let me file this DISCUSS while I double-check with the performance metric directorate. . --------------050202040902000304020606 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit PM-Dir,

I believe that we need a little bit of consistency regarding the naming convention for the perf. metrics.
Specifically because those xrblock perf. metrics should be the basis for an IETF registry.
Feedback?

Regards, Benoit


-------- Original Message --------
Subject: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)
Date: Wed, 5 Feb 2014 22:20:33 -0800
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
CC: <xrblock-chairs@tools.ietf.org>, <draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org> 


Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The metric names in the registry are not specific enough: payload type,
calculation identifier metric, segment type, and potentially MOS. I guess
they should say something about RTP. Let me file this DISCUSS while I
double-check with the performance metric directorate.




.


--------------050202040902000304020606-- From acmorton@att.com Fri Feb 7 07:16:27 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127661A8026 for ; Fri, 7 Feb 2014 07:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dK0c2Te9ETVp for ; Fri, 7 Feb 2014 07:16:25 -0800 (PST) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id B9BBB1A1F7B for ; Fri, 7 Feb 2014 07:16:24 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 4C684554413; Fri, 7 Feb 2014 10:19:36 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 7D9D2F0371; Fri, 7 Feb 2014 10:16:24 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 7 Feb 2014 10:16:24 -0500 From: "MORTON, ALFRED C (AL)" To: Benoit Claise , "pm-dir@ietf.org" Date: Fri, 7 Feb 2014 10:16:23 -0500 Thread-Topic: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) Thread-Index: Ac8jRQimDrZdi+w+R6KSXkrD+OU97QA0I4CQ Message-ID: <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> <52F39769.1040105@cisco.com> In-Reply-To: <52F39769.1040105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8BC23ECF9njfpsrvexg8rese_" MIME-Version: 1.0 Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 15:16:27 -0000 --_000_2845723087023D4CB5114223779FA9C8BC23ECF9njfpsrvexg8rese_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KaXQncyBub3QgY2xlYXIgd2hhdCByZWdpc3RyeSB5b3UgYXJlIGFza2luZyBh Ym91dDoNCg0KVGhlIElBTkEgc2VjdGlvbiBvZiB0aGlzIGRyYWZ0IHJlZmVyZW5jZXMgYW5kIGV4 aXN0aW5nIHJlZ2lzdHJ5IGZvcg0KUlRDUC1YUiBtZXRyaWNzIChkZWZpbmVkIGluIFJGQyAzNjEx KSwgd2hpY2ggaGFzIGF0dHJpYnV0ZSBuYW1lcw0KYW5kIGxvbmctZm9ybSBhdHRyaWJ1dGUgbmFt ZXMgZm9yIHRoZSAiTU9TIE1ldHJpY3MgYmxvY2siLg0KDQpBbHNvLCB0aGVyZSdzIGEgbmV3IHJl Z2lzdHJ5IG9mIGNhbGN1bGF0aW9uIGFsZ29yaXRobXMgZGVmaW5lZCBpbg0KdGhlIElBTkEgc2Vj dGlvbjoNCg0KICAgbyAgSW5pdGlhbCBhc3NpZ25tZW50cyBhcmUgYXMgZm9sbG93czoNCg0KTmFt ZSAgICAgICAgICAgICBOYW1lIERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgUmVmZXJlbmNl ICAgIFR5cGUNCj09PT09PT09PSAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 ICAgPT09PT09PT09PSAgICA9PT09DQpQNTY0ICAgICAgIElUVS1UIFAuNTY0IENvbXBsaWFudCBB bGdvcml0aG0gICAgICAgIFtQLjU2NF0gICAgICAgIFZvaWNlDQpHMTA3ICAgICAgIElUVS1UIEcu MTA3ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtHLjEwN10gICAgICAgIFZvaWNlDQpUUzEw MV8zMjkgIEVUU0kgVFMgMTAxIDMyOS01IEFubmV4IEUgICAgICAgICAgICAgIFtFVFNJXSAgICAg ICAgIFZvaWNlDQpKSjIwMV8xICAgIFRUQyBKSjIwMS4xICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFtUVENdICAgICAgICAgIFZvaWNlDQpHMTA3XzEgICAgIElUVS1UIEcuMTA3LjEgICAgICAg ICAgICAgICAgICAgICAgICAgIFtHLjEwNy4xXSAgICAgIFZvaWNlDQpQODYyICAgICAgIElUVS1U IFAuODYyICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQLjg2Ml0gICAgICAgIFZvaWNlDQpQ ODYyXzIgICAgIElUVS1UIFAuODYyLjIgICAgICAgICAgICAgICAgICAgICAgICAgIFtQLjg2Mi4y XSAgICAgIFZvaWNlDQpQODYzICAgICAgIElUVS1UIFAuODYzICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQLjg2M10gICAgICAgIFZvaWNlDQpQMTIwMV8xICAgIElUVS1UIFAuMTIwMS4xICAg ICAgICAgICAgICAgICAgICAgW1AuMTIwMS4xXSAgICAgIE11bHRpbWVkaWENClAxMjAxXzIgICAg SVRVLVQgUC4xMjAxLjIgICAgICAgICAgICAgICAgICAgICBbUC4xMjAxLjJdICAgICAgTXVsdGlt ZWRpYQ0KUDEyMDJfMSAgICBJVFUtVCBQLjEyMDIuMSAgICAgICAgICAgICAgICAgICAgIFtQLjEy MDIuMV0gICAgICAgICBWaWRlbw0KUDEyMDJfMiAgICBJVFUtVCBQLjEyMDIuMiAgICAgICAgICAg ICAgICAgICAgIFtQLjEyMDIuMl0gICAgICAgICBWaWRlbw0KDQpXaGljaCBvbmUgb2YgdGhlc2Us IG9yIG90aGVyIG5hbWluZyBjb252ZW50aW9uIGFyZSB5b3UgdGFsa2luZyBhYm91dD8NCkFsDQoN Cg0KRnJvbTogcG0tZGlyIFttYWlsdG86cG0tZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCZW5vaXQgQ2xhaXNlDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgOTow OSBBTQ0KVG86IHBtLWRpckBpZXRmLm9yZw0KU3ViamVjdDogW3BtLWRpcl0gRndkOiBCZW5vaXQg Q2xhaXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3 aXRoIERJU0NVU1MpDQoNClBNLURpciwNCg0KSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCBhIGxpdHRs ZSBiaXQgb2YgY29uc2lzdGVuY3kgcmVnYXJkaW5nIHRoZSBuYW1pbmcgY29udmVudGlvbiBmb3Ig dGhlIHBlcmYuIG1ldHJpY3MuDQpTcGVjaWZpY2FsbHkgYmVjYXVzZSB0aG9zZSB4cmJsb2NrIHBl cmYuIG1ldHJpY3Mgc2hvdWxkIGJlIHRoZSBiYXNpcyBmb3IgYW4gSUVURiByZWdpc3RyeS4NCkZl ZWRiYWNrPw0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1p ZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3aXRoIERJU0NVU1MpDQoNCkRhdGU6DQoNCldl ZCwgNSBGZWIgMjAxNCAyMjoyMDozMyAtMDgwMA0KDQpGcm9tOg0KDQpCZW5vaXQgQ2xhaXNlIDxi Y2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPg0KDQpUbzoNCg0KVGhl IElFU0cgPGllc2dAaWV0Zi5vcmc+PG1haWx0bzppZXNnQGlldGYub3JnPg0KDQpDQzoNCg0KPHhy YmxvY2stY2hhaXJzQHRvb2xzLmlldGYub3JnPjxtYWlsdG86eHJibG9jay1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+LCA8ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmlldGYub3Jn PjxtYWlsdG86ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmlldGYub3JnPg0K DQoNCg0KQmVub2l0IENsYWlzZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCg0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTEzOiBEaXNjdXNzDQoN Cg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0 IGFuZCByZXBseSB0byBhbGwNCg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBh bmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCg0KaW50cm9kdWN0b3J5IHBhcmFn cmFwaCwgaG93ZXZlci4pDQoNCg0KDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQoNCmZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0K DQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNh biBiZSBmb3VuZCBoZXJlOg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS8NCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpESVNDVVNTOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpUaGUgbWV0cmljIG5hbWVzIGluIHRo ZSByZWdpc3RyeSBhcmUgbm90IHNwZWNpZmljIGVub3VnaDogcGF5bG9hZCB0eXBlLA0KDQpjYWxj dWxhdGlvbiBpZGVudGlmaWVyIG1ldHJpYywgc2VnbWVudCB0eXBlLCBhbmQgcG90ZW50aWFsbHkg TU9TLiBJIGd1ZXNzDQoNCnRoZXkgc2hvdWxkIHNheSBzb21ldGhpbmcgYWJvdXQgUlRQLiBMZXQg bWUgZmlsZSB0aGlzIERJU0NVU1Mgd2hpbGUgSQ0KDQpkb3VibGUtY2hlY2sgd2l0aCB0aGUgcGVy Zm9ybWFuY2UgbWV0cmljIGRpcmVjdG9yYXRlLg0KDQoNCg0KDQoNCg0KDQoNCg0KLg0KDQoNCg0K DQo= --_000_2845723087023D4CB5114223779FA9C8BC23ECF9njfpsrvexg8rese_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiOw0KCWNv bG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBs aW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciO2NvbG9yOndpbmRvd3RleHQnPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+aXQncyBub3QgY2xlYXIgd2hhdCBy ZWdpc3RyeSB5b3UgYXJlIGFza2luZyBhYm91dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlRoZSBJQU5BIHNlY3Rpb24gb2Yg dGhpcyBkcmFmdCByZWZlcmVuY2VzIGFuZCBleGlzdGluZyByZWdpc3RyeSBmb3IgPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlJUQ1AtWFIg bWV0cmljcyAoZGVmaW5lZCBpbiBSRkMgMzYxMSksIHdoaWNoIGhhcyBhdHRyaWJ1dGUgbmFtZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+ YW5kIGxvbmctZm9ybSBhdHRyaWJ1dGUgbmFtZXMgZm9yIHRoZSAmcXVvdDtNT1MgTWV0cmljcyBi bG9jayZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6 d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci O2NvbG9yOndpbmRvd3RleHQnPkFsc28sIHRoZXJlJ3MgYSBuZXcgcmVnaXN0cnkgb2YgY2FsY3Vs YXRpb24gYWxnb3JpdGhtcyBkZWZpbmVkIGluIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz50aGUgSUFOQSBzZWN0aW9uOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+wqDC oCBvwqAgSW5pdGlhbCBhc3NpZ25tZW50cyBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPk5hbWXCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgTmFtZSBEZXNjcmlwdGlvbsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgUmVmZXJlbmNlwqDCoMKgIFR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+PT09PT09PT09wqDCoCA9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PcKgwqAgPT09PT09PT09PcKgwqDCoCA9PT09PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlA1 NjTCoMKgwqDCoMKgwqAgSVRVLVQgUC41NjQgQ29tcGxpYW50IEFsZ29yaXRobcKgwqDCoMKgwqDC oMKgIFtQLjU2NF3CoMKgwqDCoMKgwqDCoCBWb2ljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5HMTA3wqDCoMKgwqDCoMKgIElUVS1UIEcu MTA3wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IFtHLjEwN13CoMKgwqDCoMKgwqDCoCBWb2ljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5UUzEwMV8zMjnCoCBFVFNJIFRTIDEwMSAzMjkt NSBBbm5leCBFwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgW0VUU0ldIMKgwqDCoMKgwqDCoMKg wqBWb2ljZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5k b3d0ZXh0Jz5KSjIwMV8xwqDCoMKgIFRUQyBKSjIwMS4xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFtUVENdwqDCoMKgwqDCoMKgwqDCoMKgIFZv aWNlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3Rl eHQnPkcxMDdfMcKgwqDCoMKgIElUVS1UIEcuMTA3LjHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbRy4xMDcuMV3CoMKgwqDCoMKgIFZvaWNlPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlA4NjLC oMKgwqDCoMKgwqAgSVRVLVQgUC44NjLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgW1AuODYyXcKgwqDCoMKgwqDCoMKgIFZvaWNlPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlA4NjJfMsKg wqDCoMKgIElUVS1UIFAuODYyLjLCoMKgwqDCoCDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqBbUC44NjIuMl3CoMKgwqDCoMKgIFZvaWNlPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlA4NjPCoMKgwqDCoMKgwqAg SVRVLVQgUC44NjPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgW1AuODYzXcKgwqDCoMKgwqDCoMKgIFZvaWNlPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRvd3RleHQnPlAxMjAxXzHCoMKgwqAgSVRVLVQg UC4xMjAxLjHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIFtQLjEyMDEu MV3CoMKgwqDCoMKgIE11bHRpbWVkaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7Y29sb3I6d2luZG93dGV4dCc+UDEyMDFfMsKgwqDCoCBJVFUtVCBQLjEyMDEuMsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgW1AuMTIwMS4yXcKgwqDCoMKgwqAg TXVsdGltZWRpYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3 aW5kb3d0ZXh0Jz5QMTIwMl8xwqDCoMKgIElUVS1UIFAuMTIwMi4xwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBbUC4xMjAyLjFdwqDCoMKgwqDCoMKgwqDCoCBWaWRlbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz5Q MTIwMl8ywqDCoMKgIElUVS1UIFAuMTIwMi4ywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCBbUC4xMjAyLjJdwqDCoMKgwqDCoMKgwqDCoCBWaWRlbzxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6d2luZG93dGV4dCc+V2hpY2gg b25lIG9mIHRoZXNlLCBvciBvdGhlciBuYW1pbmcgY29udmVudGlvbiBhcmUgeW91IHRhbGtpbmcg YWJvdXQ/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndpbmRv d3RleHQnPkFsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOndp bmRvd3RleHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj b2xvcjp3aW5kb3d0ZXh0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO2NvbG9yOndpbmRvd3RleHQnPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s b3I6d2luZG93dGV4dCc+IHBtLWRpciBbbWFpbHRvOnBtLWRpci1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPkJlbm9pdCBDbGFpc2U8YnI+PGI+U2VudDo8L2I+IFRodXJzZGF5 LCBGZWJydWFyeSAwNiwgMjAxNCA5OjA5IEFNPGJyPjxiPlRvOjwvYj4gcG0tZGlyQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBbcG0tZGlyXSBGd2Q6IEJlbm9pdCBDbGFpc2UncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdpdGggRElTQ1VTUyk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5QTS1EaXIsPGJyPjxicj5JIGJlbGlldmUg dGhhdCB3ZSBuZWVkIGEgbGl0dGxlIGJpdCBvZiBjb25zaXN0ZW5jeSByZWdhcmRpbmcgdGhlIG5h bWluZyBjb252ZW50aW9uIGZvciB0aGUgcGVyZi4gbWV0cmljcy48YnI+U3BlY2lmaWNhbGx5IGJl Y2F1c2UgdGhvc2UgeHJibG9jayBwZXJmLiBtZXRyaWNzIHNob3VsZCBiZSB0aGUgYmFzaXMgZm9y IGFuIElFVEYgcmVnaXN0cnkuPGJyPkZlZWRiYWNrPzxicj48YnI+UmVnYXJkcywgQmVub2l0PG86 cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj4tLS0tLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3Jt YWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRyPjx0ZCBub3dy YXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1z b05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpyaWdodCc+PGI+U3ViamVjdDog PG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+PHAgY2xhc3M9TXNvTm9ybWFsPkJlbm9pdCBDbGFpc2UncyBEaXNjdXNzIG9uIGRyYWZ0LWll dGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdpdGggRElTQ1VTUyk8bzpwPjwvbzpwPjwvcD48 L3RkPjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGlu IDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGln bjpyaWdodCc+PGI+RGF0ZTogPG86cD48L286cD48L2I+PC9wPjwvdGQ+PHRkIHN0eWxlPSdwYWRk aW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPldlZCwgNSBGZWIgMjAxNCAy MjoyMDozMyAtMDgwMDxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48dHI+PHRkIG5vd3JhcCB2YWxp Z249dG9wIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFs IGFsaWduPXJpZ2h0IHN0eWxlPSd0ZXh0LWFsaWduOnJpZ2h0Jz48Yj5Gcm9tOiA8bzpwPjwvbzpw PjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFz cz1Nc29Ob3JtYWw+QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5j b20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+PC90ZD48L3Ry Pjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6MGluIDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249cmlnaHQgc3R5bGU9J3RleHQtYWxpZ246cmlnaHQn PjxiPlRvOiA8bzpwPjwvbzpwPjwvYj48L3A+PC90ZD48dGQgc3R5bGU9J3BhZGRpbmc6MGluIDBp biAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIElFU0cgPGEgaHJlZj0ibWFpbHRvOmll c2dAaWV0Zi5vcmciPiZsdDtpZXNnQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD48L3Rk PjwvdHI+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBhbGlnbj1yaWdodCBzdHlsZT0ndGV4dC1hbGlnbjpy aWdodCc+PGI+Q0M6IDxvOnA+PC9vOnA+PC9iPjwvcD48L3RkPjx0ZCBzdHlsZT0ncGFkZGluZzow aW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48YSBocmVmPSJtYWlsdG86eHJibG9j ay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPiZsdDt4cmJsb2NrLWNoYWlyc0B0b29scy5pZXRmLm9y ZyZndDs8L2E+LCA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9l QHRvb2xzLmlldGYub3JnIj4mbHQ7ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xz LmlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpw PjwvcD48cHJlPkJlbm9pdCBDbGFpc2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3Qg cG9zaXRpb24gZm9yPG86cD48L286cD48L3ByZT48cHJlPmRyYWZ0LWlldGYteHJibG9jay1ydGNw LXhyLXFvZS0xMzogRGlzY3VzczxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPjxwcmU+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPG86cD48L286cD48L3ByZT48cHJlPmVtYWlsIGFkZHJl c3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0 aGlzPG86cD48L286cD48L3ByZT48cHJlPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIu KTxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT48cHJlPlBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCI+aHR0cDovL3d3 dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PG86cD48 L286cD48L3ByZT48cHJlPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuPG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+VGhlIGRvY3VtZW50LCBh bG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxvOnA+ PC9vOnA+PC9wcmU+PHByZT48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLzwvYT48bzpwPjwvbzpwPjwv cHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9wcmU+PHByZT5ESVNDVVNTOjxvOnA+PC9vOnA+PC9wcmU+PHByZT4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PG86cD48L286cD48L3ByZT48cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT5UaGUgbWV0 cmljIG5hbWVzIGluIHRoZSByZWdpc3RyeSBhcmUgbm90IHNwZWNpZmljIGVub3VnaDogcGF5bG9h ZCB0eXBlLDxvOnA+PC9vOnA+PC9wcmU+PHByZT5jYWxjdWxhdGlvbiBpZGVudGlmaWVyIG1ldHJp Yywgc2VnbWVudCB0eXBlLCBhbmQgcG90ZW50aWFsbHkgTU9TLiBJIGd1ZXNzPG86cD48L286cD48 L3ByZT48cHJlPnRoZXkgc2hvdWxkIHNheSBzb21ldGhpbmcgYWJvdXQgUlRQLiBMZXQgbWUgZmls ZSB0aGlzIERJU0NVU1Mgd2hpbGUgSTxvOnA+PC9vOnA+PC9wcmU+PHByZT5kb3VibGUtY2hlY2sg d2l0aCB0aGUgcGVyZm9ybWFuY2UgbWV0cmljIGRpcmVjdG9yYXRlLjxvOnA+PC9vOnA+PC9wcmU+ PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT48 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxw cmU+LjxvOnA+PC9vOnA+PC9wcmU+PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_2845723087023D4CB5114223779FA9C8BC23ECF9njfpsrvexg8rese_-- From bclaise@cisco.com Sun Feb 9 14:07:38 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9131A0605 for ; Sun, 9 Feb 2014 14:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdbMCnXiV7Bv for ; Sun, 9 Feb 2014 14:07:35 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB191A0459 for ; Sun, 9 Feb 2014 14:07:35 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s19M7YOq010095 for ; Sun, 9 Feb 2014 23:07:34 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s19M7HPY015683 for ; Sun, 9 Feb 2014 23:07:27 +0100 (CET) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id s19M7FuN029397 for pm-dir@ietf.org; Sun, 9 Feb 2014 23:07:15 +0100 (CET) Date: Sun, 9 Feb 2014 23:07:14 +0100 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20140209220714.GA29394@sweet-brew-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: [pm-dir] Performance metrics doctors generated email X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:07:39 -0000 Dear all, This is an automatically generated email. It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference. It also lists all the IETF internet-drafts that contain "performance metric". Regards, Benoit =========================================================== Normative References -------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00Active draft-ietf-xrblock-rtcp-xr-psi-decodability-00 Active draft-ietf-xrblock-rtcp-xr-qoe-13 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state drafts containing performance metric ------------------------------------ draft-ietf-alto-deployments-08 Active draft-ietf-cdni-footprint-capabilities-semantics-01Active draft-ietf-idr-te-pm-bgp-00 Active draft-ietf-ippm-2330-update-01 Active draft-ietf-ippm-lmap-path-01 Active draft-ietf-ippm-model-based-metrics-01 Active draft-ietf-ippm-rate-problem-05 Active draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-lmap-use-cases-02 Active draft-ietf-mmusic-sdp-mux-attributes-00 Active draft-ietf-nvo3-framework-05 In IESG processing - ID Tracker state draft-ietf-opsawg-oam-overview-13 Active draft-ietf-pce-pcep-service-aware-02 Active draft-ietf-ppsp-base-tracker-protocol-03 Active draft-ietf-ppsp-peer-protocol-08 Active draft-ietf-rtcweb-rtp-usage-11 Active draft-ietf-trill-loss-delay-01 Active draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00Active draft-ietf-xrblock-rtcp-xr-psi-decodability-00 Active draft-ietf-xrblock-rtcp-xr-qoe-13 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xt-discard-metrics-00 Active From bill.wu@huawei.com Sun Feb 9 20:59:12 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5354F1A07AA for ; Sun, 9 Feb 2014 20:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2xVgduZ2Few for ; Sun, 9 Feb 2014 20:59:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADB041A0237 for ; Sun, 9 Feb 2014 20:59:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY42469; Mon, 10 Feb 2014 04:59:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:58:12 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 04:59:03 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 12:58:52 +0800 From: Qin Wu To: "pm-dir@ietf.org" , Varun Singh , "Huangyihong (Rachel)" Thread-Topic: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mHMohgTqbV6RzRzOEe/CvyioJpw== Date: Mon, 10 Feb 2014 04:58:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7B956nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "MORTON, ALFRED C \(AL\)" Subject: [pm-dir] Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 04:59:12 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7B956nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Authors: I am the assigned PM-DIR reviewer for this draft. Here is my review to this draft based on RFC6390 PM template. This draft defines two new metrics in the same metric block and has alread= y applied RFC6390 template to these two metrics, However I do have some comments below regarding metri= cs definition. 1. Appendix A, Part a, Bullet 3 says: " * Method of Measurement or Calculation: It must be measured in the source stream. It must be measured for the packets that have no further chance of being repaired. " The first sentence is a little bit confusing, are you saying the measuremen= t is applied to source stream, I think you can reference to section 3, the defin= ition "SSRC of source" for that. The second sentence seems also repeat what the definition of "unrepaired lo= ss count", you can simply reference that definition. 2. Appendix A, Part a, Bullet 5 says: " Measurement Point(s) with Potential Measurement Domain: See section 3, 1st paragraph. " Section 3, 1st paragraph doesn't explain where to measure? I suggest you can add the following sentence to the section 3, 1st paragrap= h as follows: " The measurement of these metrics is made at the receiving end of the RTP st= ream " And you then you reference section 3 for measurement points. 3. Appendix A, Part a, Bullet 6 says: " * Measurement Timing: See Section 4 for measurement timing. " Section 4 has no text to explain measurement timing. Since Since this metric doesn't rely on the measurement interval in the Measurement Information Block [RFC6776] indicating the span of the report, I believe you rely on sequence number range to indicate measurement timing, please make it clear in the text. 4. Appendix A, Part b, Bullet 3 My comment on Appendix A, part a Bullet 3 is also applied here. 5. Appendix A, Part b, Bullet 5 My comment on Appendix A, part a Bullet 5 is also applied here. 6. Appendix A, Part b, Bullet 6 My comment on Appendix A, part a Bullet 6 is also applied here. 7. Section 1, paragraph 1 s/measured on media stream/measured on RTP stream 8.Section 1, Paragraph 1 says: " Hence, the sending endpoint cannot assess the performance of the repair mechanism by observing the change in fraction loss and the cumulative loss statistics. " It is better to add a reference for fraction loss and the cumulative loss, = I think It should be RFC 3550 RTCP SR which carries fraction loss statistics. 9. Section 1, Paragraph 1 says: " When applications use multiple XR blocks, the endpoints require more concise reporting to save bandwidth. " I don't think the endpoints MUST have such concise reporting in such case. Therefore I suggest to say the endpoint may require more concise reporting = in such case. 10. Section 1, Paragraph 2 says: " Thus it is RECOMMENDED that this report block should be generated for those source packets that have no further chance of being repaired. But a potential ambiguity may result from sequence number range inconsistent. To address this issue, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that the report block reports on. " Whose ambiguity? RFC3550 or RFC5725? Not sure you should highlight using begin seq or end seq since RFC5725 also= use this. You'd better have more text to explain where sequence number inconsistency = come from? 11. Section 1, Paragraph 2 says: " In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre- repair loss count during the this range. Note that the metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of RFC3550. " The definition of repaired loss count here is not consistent with the defin= ition of repaired loss count in section 3? It looks repaired loss count here is referred to the value carried in the S= R while repaired loss count in section is referred to the packet that is repaired after loss repair mechanism is appl= ied. Please fix this to make them consistent. 12. Section 3, Paragraph 1 says: " This block describes the residual number of packets lost after applying repair mechanisms. The report block is complementary to the RTCP XR metrics defined in [RFC5725] as= it uses a non-RLE format. " What Does residual number mean? Suggest to remove residual. It doesn't add any benefit but introduce confusing. 13. Section 3 says: " begin_seq: 16 bits The sequence number of the first packet in the session or the sequence number of the first packet fully repaired that this block reports on. end_seq: 16 bits The sequence number of the last packet fully repaired that this block reports on plus one. " Why not use the same definition as defined in the RFC3611 or RFC5725, why m= ake these definitions so specific? I don't think the begin_seq should only be chosen either as the first packe= t sequence number in the session Or the first packet sequence number that is fully repaired. Why not choose = the sequence number of any packet you received? In some case, you may not lose any packet, then in such case, both unrepair= ed loss count and repaired loss count should be set to zero. Regards! -Qin ________________________________ --_000_B8F9A780D330094D99AF023C5877DABA43C7B956nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Authors:

I am the assigned P= M-DIR reviewer for this draft.

Here is my review t= o this draft based on RFC6390 PM template.

This draft defines = two new metrics  in the same metric block and has already applied RFC6= 390 template

to these two metric= s, However I do have some comments below regarding metrics definition.=

 

1. Appendix A, P= art a, Bullet 3 says:

“<= /span>

* Method of Measure= ment or Calculation: It must be measured in the

  source strea= m. It must be measured for the packets that

  have no furt= her chance of being repaired.

”<= /span>

The first sentence = is a little bit confusing, are you saying the measurement is

applied to source s= tream, I think you can reference to section 3, the definition “SSRC o= f source” for that.

The second sentence= seems also repeat what the definition of “unrepaired loss count̶= 1;,

you can simply refe= rence that definition.

 

2. Appendix A, P= art a, Bullet 5 says:

“<= /span>

Measurement Point(s= ) with Potential Measurement Domain: See

   &= nbsp;  section 3, 1st paragraph.

“<= /span>

Section 3, 1st para= graph doesn’t explain where to measure?

I suggest you can a= dd the following sentence to the section 3, 1st paragraph as follows:<= /o:p>

“<= /span>

The measurement of = these metrics is made at the receiving end of the RTP stream

”<= /span>

And you then you re= ference section 3 for measurement points.

 

3. Appendix A, P= art a, Bullet 6 says:

“<= /span>

* Measurement Timin= g: See Section 4 for measurement timing.

 

”<= /span>

Section 4 has no te= xt to explain measurement timing. Since

Since this metric d= oesn’t rely on the

measurement interva= l in the Measurement Information Block [RFC6776]

indicating the span= of the report, I believe you rely on sequence number

range to indicate m= easurement  timing, please make it clear in the text.

 

4. Appendix A, P= art b, Bullet 3

My comment on Appen= dix A, part a Bullet 3 is also applied here.

 

5. Appendix A, P= art b, Bullet 5

My comment on Appen= dix A, part a Bullet 5 is also applied here.

 

6. Appendix A, P= art b, Bullet 6

My comment on Appen= dix A, part a Bullet 6 is also applied here.

 

7. Section 1, pa= ragraph 1

s/measured on medi= a stream/measured on RTP stream<= /p>

 

8.Section 1, Par= agraph 1 says:

“<= /span>

Hence, the = sending

endpoint ca= nnot assess the performance of the repair mechanism by

observing t= he change in fraction loss and the cumulative loss

statistics.

”<= /span>

 

It is better to add= a reference for fraction loss and the cumulative loss, I think<= /span>

It should be RFC 35= 50 RTCP SR which carries fraction loss statistics.

 

9. Section 1, Pa= ragraph 1 says:

“<= /span>

When
applications use multiple XR blocks, the endpoints require more
concise reporting to save bandwidth.

&n= bsp;

”<= /span>

I don’t think= the endpoints MUST have such concise reporting in such case.

Therefore I suggest= to say the endpoint may require more concise reporting in such case.<= /o:p>

 

10. Section 1, P= aragraph 2 says:

“<= /span>

Thus it is RECOMMEN= DED that this report

block should be gen= erated for those source packets that have no

further chance of b= eing repaired. But a potential ambiguity may

result from sequenc= e number range inconsistent. To address this

issue, we use begin= sequence number and end sequence number to

explicitly indicate= the actual sequence number range that the report

   block = reports on.

”<= /span>

Whose ambiguity? RF= C3550 or RFC5725?

Not sure you should= highlight using begin seq or end seq since RFC5725 also use this.

You’d better = have more text to explain where sequence number inconsistency come from?

 

11. Section 1, P= aragraph 2 says:

“<= /span>

In addition,  = another metric, repaired loss count,

is also introduced = in this report block for calculating the pre-

repair loss count d= uring the this range. Note that the metrics in

this report block M= UST NOT be directly compared with the pre-repair

loss metric of RFC3550.

“<= /span>

The definition of r= epaired loss count here is not consistent with the definition of repaired l= oss count in section 3?

It looks repaired l= oss count here is referred to the value carried in the SR while repaired lo= ss count in section is

referred to the pac= ket that is repaired after loss repair mechanism is applied. Please fix thi= s to make them consistent.

 

 

12. Section 3, P= aragraph 1 says:

“<= /span>

This block describe= s the residual number of packets lost after

applying repair mec= hanisms. The report block is complementary to the

RTCP XR metrics def= ined in [RFC5725] as it uses a non-RLE format.

”<= /span>

What Does residual = number mean? Suggest to remove residual.

It doesn’t ad= d any benefit but introduce confusing.

 

13. Section 3 sa= ys:

“<= /span>

   begin_seq: 16 bits
 
      The sequence number of the first p=
acket in the session or the
      sequence number of the first packe=
t fully repaired that this block
      reports on.

 


   end_seq: 16 bits


 


      The sequence number of the last pa=
cket fully repaired that this


      block reports on plus one.


&n=
bsp;


”<=
/span>


Why not use th=
e same definition as defined in the RFC3611 or RFC5725, why make these defi=
nitions so specific?


I don’t think=
 the begin_seq should only be chosen either as the first packet sequence nu=
mber in the session


Or the first packet=
 sequence number that is fully repaired. Why not choose the sequence number=
 of any packet you received?


In some case, you m=
ay not lose any packet, then in such case, both unrepaired loss count =
 and  repaired loss count should be set to zero.


 


 


Regards!


-Qin
--_000_B8F9A780D330094D99AF023C5877DABA43C7B956nkgeml501mbschi_-- From bill.wu@huawei.com Mon Feb 10 01:05:22 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D11A07CB for ; Mon, 10 Feb 2014 01:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF76eP99d4_s for ; Mon, 10 Feb 2014 01:05:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D89921A07CD for ; Mon, 10 Feb 2014 01:05:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY63524; Mon, 10 Feb 2014 09:05:16 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:04:18 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:05:10 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 17:05:07 +0800 From: Qin Wu To: "snandaku@cisco.com" , "pm-dir@ietf.org" Thread-Topic: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 Thread-Index: Ac8mPzDD/EQT52mhQhiNgBwBJKjcDA== Date: Mon, 10 Feb 2014 09:05:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7B9F8nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "MORTON, ALFRED C \(AL\)" Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 09:05:22 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7B9F8nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Author: I am assigned PM-DIR reviewer for this draft. Here is my review to this draft. This draft categorizes existing SDP attribute and provides an analysis for = the multiplexing characteristics of SDP attributes. Most of these SDP attributes is more about configuration parameters or nego= tiation parameters related to RTP session and have little to do with performance metrics reporting, Section 5.27 references to RFC3611 for RTCP-XR attribute, however it doesn'= t go into details to discuss how performance metrics related SDP parameters are signaled(e.g., by referencing XR BLOCK related R= FCs that have already been published) together with SDP attribute. So most guidelines of RFC6390 don't apply here. However section 5.38 does contain one performance metric, i.e., 3GPP-QoE-Me= trics. 3GPP-QoE- metrics is defined in Section 5.3.2.3.1 of 3GPP TS 26.234 and Section 4.6 of RFC6064 and is not a single metric but a= set of metrics. As described in section 11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10= Metrics, i.e., O Corruption duration metric, O Rebuffering duration metric, O Initial buffering duration metric, O Successive loss of RTP packets, O Frame rate deviation, O Jitter duration, O Content Switch Time, O Average Codec Bitrate, O Codec Information, O Buffer Status. Unfortunately RFC6064 didn't request IANA to register these ten metrics as = SDP attribute, only 3GPP-QoE-Metrics get registered by IANA. RFC6064 does define an 3GPP-QoE-Metrics Header to negotiate the usage of th= e QoE metrics and define 3GPP-QoE-Feedback Header carry QoE metrics from the client to the server when it reports, which happens either during or at the end of the media delivery. Therefore QoE metrics reporting is supported using 3GPP-QoE-Feedb= ack Header in the RFC6064. So it is obvious the above ten QoE metrics has already been defined in 3GP= P. Unfortunately there is no registration for these ten metrics. I am wondering whether these ten QoE metrics need to be registered by IANA,= who will be responsible for registering these ten QoE Metrics? Can 3GPP-QoE-Metrics in the table of section 5.38 be updated as follows in = the same way as what section 12.1 is described for content attribute: 3GPP-QoE-Metrics: Corruption duration Medi= a Level 3GPP-QoE-Metrics: Rebuffering duration Media= Level 3GPP-QoE-Metrics: Initial buffering duration Media= Level 3GPP-QoE-Metrics: Successive loss of RTP packets Media Level 3GPP-QoE-Metrics: Frame rate deviation Medi= a Level 3GPP-QoE-Metrics: Jitter duration = Media Level 3GPP-QoE-Metrics: Content Switch Time Sessio= n Level ...... Nits: s/m-mline/m-line s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA43C7B9F8nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Author:

I am assigned PM-DIR reviewer for th= is draft.

Here is my review to this draft.

 

This draft categorizes existing SDP = attribute and provides an analysis for the multiplexing characteristics of = SDP attributes.

Most of these SDP attributes is more= about configuration parameters or negotiation parameters related to RTP se= ssion and have little to

do with performance metrics reportin= g,

 

Section 5.27 references to RFC3611 f= or RTCP-XR attribute, however it doesn’t go into details to discuss h= ow performance metrics

related SDP parameters are signaled(= e.g., by referencing XR BLOCK related RFCs that have already been published= ) together

with SDP attribute. So most guidelin= es of RFC6390 don’t apply here.

 

However section 5.38 does contain on= e performance metric, i.e., 3GPP-QoE-Metrics.

3GPP-QoE- metrics is defined in Sect= ion 5.3.2.3.1 of

3GPP TS 26.234 and Section 4.6 of RF=
C6064 and is not a single  metric but a set of metrics. 
As described in section 11.2 of 3GPP=
 TS 26.234, 3GPP QoE Metrics include 10 Metrics, i.e.,

O Corruption duration metric,=
 =



O Rebuffering duration metric,<=
/o:p>


O Initial buffering duration metric,=



O Successive loss of RTP packets,


O Frame rate deviation,


O Jitter duration,=



O Content Switch Time,


O Average Codec Bitrate,<=
/span>


O Codec Information,


O Buffer Status.

 


Unfortunately RFC6064 didn’t r=
equest IANA to register these ten metrics as SDP attribute, only 3GPP-QoE-M=
etrics  get registered by IANA.


 


RFC6064 does define an 3GPP-QoE-Metr=
ics Header to negotiate the usage of the QoE metrics and define 3GPP=
-QoE-Feedback Header


carry QoE metrics from the client to=
 the server when it


reports, which happens either during=
 or at the end of the media


delivery. Therefore QoE metrics repo=
rting is supported using 3GPP-QoE-Feedback Header in the RFC6064.


 


So it is obvious  the above ten=
 QoE metrics has already been defined in 3GPP. Unfortunately there is no re=
gistration for these ten metrics.


 


I am wondering whether these ten QoE=
 metrics need to be registered by IANA, who will be responsible for registe=
ring these ten QoE Metrics?


 


Can 3GPP-QoE-Metrics in the table of=
 section 5.38 be updated as follows in the same way as what section 12.1 is=
 described for content attribute:


 


3GPP-QoE-Metrics: Corruption duratio=
n            &n=
bsp;            =
;         Media Level


3GPP-QoE-Metrics: Rebuffering durati=
on            &=
nbsp;           &nbs=
p;       Media Level


3GPP-QoE-Metrics: Initial buffering =
duration           &=
nbsp;           &nbs=
p;  Media Level


3GPP-QoE-Metrics: Successive loss of=
 RTP packets          &nb=
sp;     Media Level


3GPP-QoE-Metrics: Frame rate deviati=
on            &=
nbsp;           &nbs=
p;        Media Level<=
/pre>

3GPP-QoE-Metrics: Jitter duration&nb=
sp;            =
            &nb=
sp;            =
     Media Level


3GPP-QoE-Metrics: Content Switch Tim=
e            &n=
bsp;            =
;       Session Level


……

Nits:


s/m-mline/m-line

s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics=
         


 


Regards!


-Qin
--_000_B8F9A780D330094D99AF023C5877DABA43C7B9F8nkgeml501mbschi_-- From rachel.huang@huawei.com Mon Feb 10 01:58:05 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBE81A07E4; Mon, 10 Feb 2014 01:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-HfvOm8xX6O; Mon, 10 Feb 2014 01:58:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id BC09F1A07E2; Mon, 10 Feb 2014 01:57:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAY69644; Mon, 10 Feb 2014 09:57:59 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:56:55 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Feb 2014 09:57:46 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Mon, 10 Feb 2014 17:57:35 +0800 From: "Huangyihong (Rachel)" To: Qin Wu , "pm-dir@ietf.org" , "Varun Singh" Thread-Topic: [xrblock]RE: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count Thread-Index: Ac8mHMohgTqbV6RzRzOEe/CvyioJpwAIUm3Q Date: Mon, 10 Feb 2014 09:57:35 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591E6FE@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Mon, 10 Feb 2014 07:27:51 -0800 Cc: Benoit Claise , "MORTON, ALFRED C \(AL\)" , "xrblock@ietf.org" Subject: [pm-dir] [xrblock]RE: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 09:58:05 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, Thanks for your comments. Please see inline. Best regards, Rachel From: Qin Wu Sent: Monday, February 10, 2014 12:59 PM To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel) Cc: MORTON, ALFRED C (AL); Benoit Claise Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-xr-post-= repair-loss-count Hi, Authors: I am the assigned PM-DIR reviewer for this draft. Here is my review to this draft based on RFC6390 PM template. This draft defines two new metrics in the same metric block and has alread= y applied RFC6390 template to these two metrics, However I do have some comments below regarding metri= cs definition. 1. Appendix A, Part a, Bullet 3 says: " * Method of Measurement or Calculation: It must be measured in the source stream. It must be measured for the packets that have no further chance of being repaired. " The first sentence is a little bit confusing, are you saying the measuremen= t is applied to source stream, I think you can reference to section 3, the defin= ition "SSRC of source" for that. [Rachel]: Sorry. It should be the "primary source stream". For some impleme= ntations using retransmission, it is possible that retransmission stream ha= s the same SSRC with the primary source stream, but in different sessions. The second sentence seems also repeat what the definition of "unrepaired lo= ss count", you can simply reference that definition. [Rachel]: How about changing to "It must be measured in the primary source = stream for the packets with no further chance to be repaired"? 2. Appendix A, Part a, Bullet 5 says: " Measurement Point(s) with Potential Measurement Domain: See section 3, 1st paragraph. " Section 3, 1st paragraph doesn't explain where to measure? I suggest you can add the following sentence to the section 3, 1st paragrap= h as follows: " The measurement of these metrics is made at the receiving end of the RTP st= ream " And you then you reference section 3 for measurement points. [Rachel]: Good suggestion. Thanks. 3. Appendix A, Part a, Bullet 6 says: " * Measurement Timing: See Section 4 for measurement timing. " Section 4 has no text to explain measurement timing. Since Since this metric doesn't rely on the measurement interval in the Measurement Information Block [RFC6776] indicating the span of the report, I believe you rely on sequence number range to indicate measurement timing, please make it clear in the text. [Rachel]: Good point. How about adding the following sentence to section 3? "This new RTCP extended report block share the same timing interval with RT= CP SR/RR " 4. Appendix A, Part b, Bullet 3 My comment on Appendix A, part a Bullet 3 is also applied here. [Rachel]: Okay. 5. Appendix A, Part b, Bullet 5 My comment on Appendix A, part a Bullet 5 is also applied here. [Rachel]: Okay. 6. Appendix A, Part b, Bullet 6 My comment on Appendix A, part a Bullet 6 is also applied here. [Rachel]: Okay. 7. Section 1, paragraph 1 s/measured on media stream/measured on RTP stream [Rachel]: Okay. 8.Section 1, Paragraph 1 says: " Hence, the sending endpoint cannot assess the performance of the repair mechanism by observing the change in fraction loss and the cumulative loss statistics. " It is better to add a reference for fraction loss and the cumulative loss, = I think It should be RFC 3550 RTCP SR which carries fraction loss statistics. [Rachel]: Will do. 9. Section 1, Paragraph 1 says: " When applications use multiple XR blocks, the endpoints require more concise reporting to save bandwidth. " I don't think the endpoints MUST have such concise reporting in such case. Therefore I suggest to say the endpoint may require more concise reporting = in such case. [Rachel]: You're right. Will do. 10. Section 1, Paragraph 2 says: " Thus it is RECOMMENDED that this report block should be generated for those source packets that have no further chance of being repaired. But a potential ambiguity may result from sequence number range inconsistent. To address this issue, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that the report block reports on. " Whose ambiguity? RFC3550 or RFC5725? Not sure you should highlight using begin seq or end seq since RFC5725 also= use this. You'd better have more text to explain where sequence number inconsistency = come from? [Rachel]: That's why we don't use the measurement interval in the Measureme= nt information Block [RFC6776]. The report block we develop is reporting th= e number of repaired packets and packets that won't be repaired anymore i= n the current interval. Some of the packets may not be repaired in current = interval, instead, they may be repaired in next or next several intervals. = If we use the same sequence range defined in RFC6776, like other RTCP XRs, = only cumulative counts are meaningful. So we choose to use the same interva= l with RTCP SR/RR and indicating the sequence number range explicitly. I will explain more in the draft to let people understand well. 11. Section 1, Paragraph 2 says: " In addition, another metric, repaired loss count, is also introduced in this report block for calculating the pre- repair loss count during the this range. Note that the metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of RFC3550. " The definition of repaired loss count here is not consistent with the defin= ition of repaired loss count in section 3? It looks repaired loss count here is referred to the value carried in the S= R while repaired loss count in section is referred to the packet that is repaired after loss repair mechanism is appl= ied. Please fix this to make them consistent. [Rachel]: I'm not trying to define repaired loss count here. I'm trying to = say that repaired loss count is used to calculating the pre-repaired loss c= ount. repaired loss count + unrepaired loss count =3D pre-repaired loss co= unt. Since some of the packet in the SR may not be repaired in current int= erval, pre-repaired loss count is not equal to the loss metrics in RTCP SR= . 12. Section 3, Paragraph 1 says: " This block describes the residual number of packets lost after applying repair mechanisms. The report block is complementary to the RTCP XR metrics defined in [RFC5725] as= it uses a non-RLE format. " What Does residual number mean? Suggest to remove residual. It doesn't add any benefit but introduce confusing. [Rachel]: Okay. 13. Section 3 says: " begin_seq: 16 bits The sequence number of the first packet in the session or the sequence number of the first packet fully repaired that this block reports on. end_seq: 16 bits The sequence number of the last packet fully repaired that this block reports on plus one. " Why not use the same definition as defined in the RFC3611 or RFC5725, why m= ake these definitions so specific? I don't think the begin_seq should only be chosen either as the first packe= t sequence number in the session Or the first packet sequence number that is fully repaired. Why not choose = the sequence number of any packet you received? In some case, you may not lose any packet, then in such case, both unrepair= ed loss count and repaired loss count should be set to zero. [Rachel]: Yes, you're right. The definition in RFC3611 is good. Regards! -Qin --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin,

 

Thanks for your commen= ts. Please see inline.

 

Best regards,

Rachel

 

From: Qin Wu
Sent: Monday, February 10, 2014 12:59 PM
To: pm-dir@ietf.org; Varun Singh; Huangyihong (Rachel)
Cc: MORTON, ALFRED C (AL); Benoit Claise
Subject: Request for an RFC 6369 review of draft-ietf-xrblock-rtcp-x= r-post-repair-loss-count

 

Hi, Authors:

I am the assigned P= M-DIR reviewer for this draft.

Here is my review t= o this draft based on RFC6390 PM template.

This draft defines = two new metrics  in the same metric block and has already applied RFC6= 390 template

to these two metric= s, However I do have some comments below regarding metrics definition.=

 

1. Appendix A, P= art a, Bullet 3 says:

“<= /span>

* Method of Measure= ment or Calculation: It must be measured in the

  source strea= m. It must be measured for the packets that

  have no furt= her chance of being repaired.

”<= /span>

The first sentence = is a little bit confusing, are you saying the measurement is

applied to source s= tream, I think you can reference to section 3, the definition “SSRC o= f source” for that.

 

[Rachel]: Sorry. It sh= ould be the ”primary source stream”. For some implementations u= sing retransmission, it is possible that retransmission stream has the same= SSRC with the primary source stream, but in different sessions.

 

The second sentence= seems also repeat what the definition of “unrepaired loss count̶= 1;,

you can simply refe= rence that definition.

 

[Rachel]: How about ch= anging to “It must be measure= d in the primary source stream for the packets with no further chance to be= repaired”?

 

2. Appendix A, P= art a, Bullet 5 says:

“<= /span>

Measurement Point(s= ) with Potential Measurement Domain: See

   &= nbsp;  section 3, 1st paragraph.

“<= /span>

Section 3, 1st para= graph doesn’t explain where to measure?

I suggest you can a= dd the following sentence to the section 3, 1st paragraph as follows:<= /o:p>

“<= /span>

The measurement of = these metrics is made at the receiving end of the RTP stream

”<= /span>

And you then you re= ference section 3 for measurement points.

 

[Rachel]: Good suggest= ion. Thanks.

 

3. Appendix A, P= art a, Bullet 6 says:

“<= /span>

* Measurement Timin= g: See Section 4 for measurement timing.

 

”<= /span>

Section 4 has no te= xt to explain measurement timing. Since

Since this metric d= oesn’t rely on the

measurement interva= l in the Measurement Information Block [RFC6776]

indicating the span= of the report, I believe you rely on sequence number

range to indicate m= easurement  timing, please make it clear in the text.

 

[Rachel]: Good point. = How about adding the following sentence to section 3?

 

“This new RTCP e= xtended report block share the same timing interval with RTCP SR/RR ”=

 

4. Appendix A, P= art b, Bullet 3

My comment on Appen= dix A, part a Bullet 3 is also applied here.<= o:p>

[Rachel]: Okay.

 

5. Appendix A, P= art b, Bullet 5

My comment on Appen= dix A, part a Bullet 5 is also applied here.

[Rachel]: Okay.

 

6. Appendix A, P= art b, Bullet 6

My comment on Appen= dix A, part a Bullet 6 is also applied here.

[Rachel]: Okay.

 

7. Section 1, pa= ragraph 1

s/measured on medi= a stream/measured on RTP stream

[Rachel]: Okay.

 

8.Section 1, Par= agraph 1 says:

“<= /span>

Hence, the = sending

endpoint ca= nnot assess the performance of the repair mechanism by

observing t= he change in fraction loss and the cumulative loss

statistics.

”<= /span>

 

It is better to add= a reference for fraction loss and the cumulative loss, I think<= /span>

It should be RFC 35= 50 RTCP SR which carries fraction loss statistics.

[Rachel]: Will do.

 

9. Section 1, Pa= ragraph 1 says:

“<= /span>

When
applications use multiple XR blocks, the endpoints require more
concise reporting to save bandwidth.

&n= bsp;

”<= /span>

I don’t think= the endpoints MUST have such concise reporting in such case.

Therefore I suggest= to say the endpoint may require more concise reporting in such case.<= /o:p>

 

[Rachel]: You’re= right. Will do.

 

10. Section 1, P= aragraph 2 says:

“<= /span>

Thus it is RECOMMEN= DED that this report

block should be gen= erated for those source packets that have no

further chance of b= eing repaired. But a potential ambiguity may

result from sequenc= e number range inconsistent. To address this

issue, we use begin= sequence number and end sequence number to

explicitly indicate= the actual sequence number range that the report

   block = reports on.

”<= /span>

Whose ambiguity? RF= C3550 or RFC5725?

Not sure you should= highlight using begin seq or end seq since RFC5725 also use this.

You’d better = have more text to explain where sequence number inconsistency come from?

[Rachel]: That’s= why we don’t use the measurement interval in the Measurement informa= tion Block [RFC6776]. The report block we develop is reporting the number o= f  repaired  packets and packets that won’t be repaired anymore in the current interval. Some of the packets may not be repaired i= n current interval, instead, they may be repaired in next or next several i= ntervals. If we use the same sequence range defined in RFC6776, like other = RTCP XRs, only cumulative counts are meaningful. So we choose to use the same interval with RTCP SR/RR and = indicating the sequence number range explicitly.

I will explain more in= the draft to let people understand well.

 

11. Section 1, P= aragraph 2 says:

“<= /span>

In addition,  = another metric, repaired loss count,

is also introduced = in this report block for calculating the pre-

repair loss count d= uring the this range. Note that the metrics in

this report block M= UST NOT be directly compared with the pre-repair

loss metric of RFC3550.

“<= /span>

The definition of r= epaired loss count here is not consistent with the definition of repaired l= oss count in section 3?

It looks repaired l= oss count here is referred to the value carried in the SR while repaired lo= ss count in section is

referred to the pac= ket that is repaired after loss repair mechanism is applied. Please fix thi= s to make them consistent.

 
[Rachel]=
: I’m not trying to define repaired loss count here. I’m trying=
 to say that repaired loss count is used to calculating the pre-repa=
ired loss count.  repaired loss count +=
 unrepaired loss count =3D pre-repaired loss count. Since  some of the=
 packet in the SR may not be repaired in current interval, pre-repaired los=
s count is not equal to the loss  metrics in RTCP SR.

 

12. Section 3, P= aragraph 1 says:

“<= /span>

This block describe= s the residual number of packets lost after

applying repair mec= hanisms. The report block is complementary to the

RTCP XR metrics def= ined in [RFC5725] as it uses a non-RLE format.

”<= /span>

What Does residual = number mean? Suggest to remove residual.

It doesn’t ad= d any benefit but introduce confusing.

[R= achel]: Okay.

 

13. Section 3 sa= ys:

“<= /span>

   begin_seq: 16 bits
 
      The sequence number of the first p=
acket in the session or the
      sequence number of the first packe=
t fully repaired that this block
      reports on.

 


   end_seq: 16 bits


 


      The sequence number of the last pa=
cket fully repaired that this


      block reports on plus one.


&n=
bsp;


”<=
/span>


Why not use th=
e same definition as defined in the RFC3611 or RFC5725, why make these defi=
nitions so specific?=



I don’t think=
 the begin_seq should only be chosen either as the first packet sequence nu=
mber in the session


Or the first packet=
 sequence number that is fully repaired. Why not choose the sequence number=
 of any packet you received?


In some case, you m=
ay not lose any packet, then in such case, both unrepaired loss count =
 and  repaired loss count should be set to zero.


[Rachel]: Yes, youR=
17;re right. The definition in RFC3611 is good.



 


Regards!


-Qin
--_000_51E6A56BD6A85142B9D172C87FC3ABBB4591E6FEnkgeml501mbschi_-- From snandaku@cisco.com Mon Feb 10 07:11:48 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F981A031B for ; Mon, 10 Feb 2014 07:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M2SJ4xiYLxY for ; Mon, 10 Feb 2014 07:11:45 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56B1A030C for ; Mon, 10 Feb 2014 07:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18845; q=dns/txt; s=iport; t=1392045105; x=1393254705; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=spGFS9/TgYeKA78OtDU/rwJh1O9XTMqph6h/bS+1zsU=; b=gOaEdQRoWjZsGhvo061mA5vltzb9bAI+aSZaJDFiIAwG0rX9K8hVBOyk cZveYQky512zHwZUuY3gI2dpxQK3Bm4jbKocWSdepPOzXa/LE7SkIQmf3 nFnokuqwDY9/ZufsEmRrfvnvfEvJ5+NAtlO5DNp5X/6VzH1DQ64CJ/ZNt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAP/r+FKtJXHB/2dsb2JhbABZgkhEgQ+/PoEQFnSCJQEBAQR5EAIBCA4DBAEBCyQyHQgBAQQBDQUIh33JVBeOTDEHgySBFASqTIMtgio X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208,217";a="19261863" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 10 Feb 2014 15:11:41 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1AFBfeV001883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 15:11:41 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.234]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 09:11:40 -0600 From: "Suhas Nandakumar (snandaku)" To: Qin Wu , "pm-dir@ietf.org" Thread-Topic: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 Thread-Index: Ac8mPzDD/EQT52mhQhiNgBwBJKjcDAAMBZNM Date: Mon, 10 Feb 2014 15:11:41 +0000 Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D07A601@xmb-aln-x12.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.99] Content-Type: multipart/alternative; boundary="_000_37D91FC30D69DE43B61E5EEADD959F180D07A601xmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Feb 2014 07:27:51 -0800 Cc: "Benoit Claise \(bclaise\)" , "MORTON, ALFRED C \(AL\)" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:11:48 -0000 --_000_37D91FC30D69DE43B61E5EEADD959F180D07A601xmbalnx12ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Qin Thanks for your inputs on the document. One general idea behind this draft was to define a generic framework for = categorizing multiplexing behavior of SDP attributes of today and of those = that will be defined in the future. Hence we started categorizing those that are registered with the IANA tod= ay as the reference. Regarding the RFC6064 QOE SDP attributes that are not registered with the= IANA, I will be happy to add those ten attributes to this document. Personally, i feel that these ten attributes must be registered with the = IANA to match the goals associated with this work. I would love to get your= thoughts on this. Cheers Suhas ________________________________ From: Qin Wu [bill.wu@huawei.com] Sent: Monday, February 10, 2014 1:05 AM To: Suhas Nandakumar (snandaku); pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attrib= utes-00 Hi, Author: I am assigned PM-DIR reviewer for this draft. Here is my review to this draft. This draft categorizes existing SDP attribute and provides an analysis for = the multiplexing characteristics of SDP attributes. Most of these SDP attributes is more about configuration parameters or nego= tiation parameters related to RTP session and have little to do with performance metrics reporting, Section 5.27 references to RFC3611 for RTCP-XR attribute, however it doesn= =92t go into details to discuss how performance metrics related SDP parameters are signaled(e.g., by referencing XR BLOCK related R= FCs that have already been published) together with SDP attribute. So most guidelines of RFC6390 don=92t apply here. However section 5.38 does contain one performance metric, i.e., 3GPP-QoE-Me= trics. 3GPP-QoE- metrics is defined in Section 5.3.2.3.1 of 3GPP TS 26.234 and Section 4.6 of RFC6064 and is not a single metric but a= set of metrics. As described in section 11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10= Metrics, i.e., O Corruption duration metric, O Rebuffering duration metric, O Initial buffering duration metric, O Successive loss of RTP packets, O Frame rate deviation, O Jitter duration, O Content Switch Time, O Average Codec Bitrate, O Codec Information, O Buffer Status. Unfortunately RFC6064 didn=92t request IANA to register these ten metrics a= s SDP attribute, only 3GPP-QoE-Metrics get registered by IANA. RFC6064 does define an 3GPP-QoE-Metrics Header to negotiate the usage of th= e QoE metrics and define 3GPP-QoE-Feedback Header carry QoE metrics from the client to the server when it reports, which happens either during or at the end of the media delivery. Therefore QoE metrics reporting is supported using 3GPP-QoE-Feedb= ack Header in the RFC6064. So it is obvious the above ten QoE metrics has already been defined in 3GP= P. Unfortunately there is no registration for these ten metrics. I am wondering whether these ten QoE metrics need to be registered by IANA,= who will be responsible for registering these ten QoE Metrics? Can 3GPP-QoE-Metrics in the table of section 5.38 be updated as follows in = the same way as what section 12.1 is described for content attribute: 3GPP-QoE-Metrics: Corruption duration Medi= a Level 3GPP-QoE-Metrics: Rebuffering duration Media= Level 3GPP-QoE-Metrics: Initial buffering duration Media= Level 3GPP-QoE-Metrics: Successive loss of RTP packets Media Level 3GPP-QoE-Metrics: Frame rate deviation Medi= a Level 3GPP-QoE-Metrics: Jitter duration = Media Level 3GPP-QoE-Metrics: Content Switch Time Sessio= n Level =85=85 Nits: s/m-mline/m-line s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics Regards! -Qin --_000_37D91FC30D69DE43B61E5EEADD959F180D07A601xmbalnx12ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello Qin

  Thanks for your inputs on the document. 

  One general idea behind this draft was to define a generic fram= ework for categorizing multiplexing behavior of SDP attributes of today and= of those that will be defined in the future.
  Hence we started categorizing those that are registered with th= e IANA today as the reference. 

  Regarding the RFC6064 QOE SDP attributes that are not registere= d with the IANA, I will be happy to add those ten attributes to this docume= nt. 
  
  Personally, i feel that these ten attributes must be registered= with the IANA to match the goals associated with this work. I would love to get your thoughts on this.

Cheers
Suhas
From: Qin Wu [bill.wu@huawei.com]
Sent: Monday, February 10, 2014 1:05 AM
To: Suhas Nandakumar (snandaku); pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux= -attributes-00

Hi, Author:

I am assigned PM-DIR reviewer for t= his draft.

Here is my review to this draft.

 

This draft categorizes existing SDP= attribute and provides an analysis for the multiplexing characteristics of= SDP attributes.

Most of these SDP attributes is mor= e about configuration parameters or negotiation parameters related to RTP s= ession and have little to

do with performance metrics reporti= ng,

 

Section 5.27 references to RFC3611 = for RTCP-XR attribute, however it doesn=92t go into details to discuss how = performance metrics

related SDP parameters are signaled= (e.g., by referencing XR BLOCK related RFCs that have already been publishe= d) together

with SDP attribute. So most guideli= nes of RFC6390 don=92t apply here.

 

However section 5.38 does contain o= ne performance metric, i.e., 3GPP-QoE-Metrics.

3GPP-QoE- metrics is defined in Sec= tion 5.3.2.3.1 of

3GPP TS 26.234 and Section 4.6 of RF=
C6064 and is not a single  metric but a set of metrics. 
As described in section 11.2 of 3GPP=
 TS 26.234, 3GPP QoE Metrics include 10 Metrics, i.e.,
O Corruption duration metric,=
 =

O Rebuffering duration metric,
O Initial buffering duration metric,=

O Successive loss of RTP packets,
O Frame rate deviation,
O Jitter duration,
O Content Switch Time,
O Average Codec Bitrate,

O Codec Information,


O Buffer Status.


 


Unfortunately RFC6064 didn=92t reque=
st IANA to register these ten metrics as SDP attribute, only 3GPP-QoE-Metri=
cs  get registered by IANA.


 


RFC6064 does define an 3GPP-QoE-Metr=
ics Header to negotiate the usage of the QoE metrics and define 3GPP=
-QoE-Feedback Header


carry QoE metrics from the client to=
 the server when it


reports, which happens either during=
 or at the end of the media


delivery. Therefore QoE metrics repo=
rting is supported using 3GPP-QoE-Feedback Header in the RFC6064.

 


So it is obvious  the above ten=
 QoE metrics has already been defined in 3GPP. Unfortunately there is no re=
gistration for these ten metrics.


 


I am wondering whether these ten QoE=
 metrics need to be registered by IANA, who will be responsible for registe=
ring these ten QoE Metrics?


 


Can 3GPP-QoE-Metrics in the table of=
 section 5.38 be updated as follows in the same way as what section 12.1 is=
 described for content attribute:


 


3GPP-QoE-Metrics: Corruption duratio=
n            &n=
bsp;            =
;         Media Level


3GPP-QoE-Metrics: Rebuffering durati=
on            &=
nbsp;           &nbs=
p;       Media Level


3GPP-QoE-Metrics: Initial buffering =
duration           &=
nbsp;           &nbs=
p;  Media Level


3GPP-QoE-Metrics: Successive loss of=
 RTP packets          &nb=
sp;     Media Level


3GPP-QoE-Metrics: Frame rate deviati=
on            &=
nbsp;           &nbs=
p;        Media Level


3GPP-QoE-Metrics: Jitter duration&nb=
sp;            =
            &nb=
sp;            =
     Media Level


3GPP-QoE-Metrics: Content Switch Tim=
e            &n=
bsp;            =
;       Session Level


=85=85


Nits:


s/m-mline/m-line


s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics=
         


 


Regards!


-Qin
--_000_37D91FC30D69DE43B61E5EEADD959F180D07A601xmbalnx12ciscoc_-- From bclaise@cisco.com Mon Feb 10 21:57:09 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DC01A0799 for ; Mon, 10 Feb 2014 21:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KotsQvfdxrT for ; Mon, 10 Feb 2014 21:57:05 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C67A71A0686 for ; Mon, 10 Feb 2014 21:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21300; q=dns/txt; s=iport; t=1392098225; x=1393307825; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=ppgNEqabBV7Exi2TOYeKOIldqWrJWXpYpWqkjXMNPfU=; b=lcP4DvGd6dZGSSwVNAsDcH5YdY8BkLD8bY2yt/0logi+/U+nQYeKcl2F Me4m2cueQgmw1d97YRjgPXNOynPPJ832OUJHzEj6JHabkOz5oyB8ULmoy yiL3KElkudxAWOvGYvostGrH+YDhGQ0urQuuMMweGA0zn5DkWhWEdF/xB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAEC7+VKrRDoJ/2dsb2JhbABZgkhEOINYhV22BoEMFnSCJQEBAQQjCksNBAkCEQMBAQEKFgEHAwICCQMCAQIBNAkIBgEMBgIBAQWHew6NRJt/oBwXjg4RAT8XAQaCaYFJBIlIjmKBMoUVi1mBb4FfG4E1 X-IronPort-AV: E=Sophos;i="4.95,823,1384300800"; d="scan'208,217";a="102163939" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 11 Feb 2014 05:57:05 +0000 Received: from [10.21.124.198] (sjc-vpn6-1222.cisco.com [10.21.124.198]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1B5v4wH023020; Tue, 11 Feb 2014 05:57:04 GMT Message-ID: <52F9BBB0.1090204@cisco.com> Date: Mon, 10 Feb 2014 21:57:04 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" , Qin Wu References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> <52F39769.1040105@cisco.com> <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> Content-Type: multipart/alternative; boundary="------------040808030007020103080007" Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 05:57:09 -0000 This is a multi-part message in MIME format. --------------040808030007020103080007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Al, I meant the different "metric name" entries in Appendix A of the draft. Qin Wu, in cc, agreed to improve those. We should avoid collisions with the exist XR block defined metrics. Regards, Benoit > > Hi Benoit, > > it's not clear what registry you are asking about: > > The IANA section of this draft references and existing registry for > > RTCP-XR metrics (defined in RFC 3611), which has attribute names > > and long-form attribute names for the "MOS Metrics block". > > Also, there's a new registry of calculation algorithms defined in > > the IANA section: > > o Initial assignments are as follows: > > Name Name Description Reference Type > > ========= =================================== ========== ==== > > P564 ITU-T P.564 Compliant Algorithm [P.564] Voice > > G107 ITU-T G.107 [G.107] Voice > > TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice > > JJ201_1 TTC JJ201.1 [TTC] Voice > > G107_1 ITU-T G.107.1 [G.107.1] Voice > > P862 ITU-T P.862 [P.862] Voice > > P862_2 ITU-T P.862.2 [P.862.2] Voice > > P863 ITU-T P.863 [P.863] Voice > > P1201_1 ITU-T P.1201.1 [P.1201.1] Multimedia > > P1201_2 ITU-T P.1201.2 [P.1201.2] Multimedia > > P1202_1 ITU-T P.1202.1 [P.1202.1] Video > > P1202_2 ITU-T P.1202.2 [P.1202.2] Video > > Which one of these, or other naming convention are you talking about? > > Al > > *From:*pm-dir [mailto:pm-dir-bounces@ietf.org] *On Behalf Of *Benoit > Claise > *Sent:* Thursday, February 06, 2014 9:09 AM > *To:* pm-dir@ietf.org > *Subject:* [pm-dir] Fwd: Benoit Claise's Discuss on > draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) > > PM-Dir, > > I believe that we need a little bit of consistency regarding the > naming convention for the perf. metrics. > Specifically because those xrblock perf. metrics should be the basis > for an IETF registry. > Feedback? > > Regards, Benoit > > > > -------- Original Message -------- > > *Subject: * > > > > Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with > DISCUSS) > > *Date: * > > > > Wed, 5 Feb 2014 22:20:33 -0800 > > *From: * > > > > Benoit Claise > > *To: * > > > > The IESG > > *CC: * > > > > > , > > > > Benoit Claise has entered the following ballot position for > draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > The metric names in the registry are not specific enough: payload type, > calculation identifier metric, segment type, and potentially MOS. I guess > they should say something about RTP. Let me file this DISCUSS while I > double-check with the performance metric directorate. > > > > > . > > --------------040808030007020103080007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Al,

I meant the different "metric name" entries in Appendix A of the draft.
Qin Wu, in cc, agreed to improve those.
We should avoid collisions with the exist XR block defined metrics.

Regards, Benoit

Hi Benoit,

it's not clear what registry you are asking about:

 

The IANA section of this draft references and existing registry for

RTCP-XR metrics (defined in RFC 3611), which has attribute names

and long-form attribute names for the "MOS Metrics block".

 

Also, there's a new registry of calculation algorithms defined in

the IANA section:

 

   o  Initial assignments are as follows:

 

Name             Name Description                  Reference    Type

=========   ===================================   ==========    ====

P564       ITU-T P.564 Compliant Algorithm        [P.564]        Voice

G107       ITU-T G.107                            [G.107]        Voice

TS101_329  ETSI TS 101 329-5 Annex E              [ETSI]         Voice

JJ201_1    TTC JJ201.1                            [TTC]          Voice

G107_1     ITU-T G.107.1                          [G.107.1]      Voice

P862       ITU-T P.862                            [P.862]        Voice

P862_2     ITU-T P.862.2                          [P.862.2]      Voice

P863       ITU-T P.863                            [P.863]        Voice

P1201_1    ITU-T P.1201.1                     [P.1201.1]      Multimedia

P1201_2    ITU-T P.1201.2                     [P.1201.2]      Multimedia

P1202_1    ITU-T P.1202.1                     [P.1202.1]         Video

P1202_2    ITU-T P.1202.2                     [P.1202.2]         Video

 

Which one of these, or other naming convention are you talking about?

Al

 

 

From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Thursday, February 06, 2014 9:09 AM
To: pm-dir@ietf.org
Subject: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)

 

PM-Dir,

I believe that we need a little bit of consistency regarding the naming convention for the perf. metrics.
Specifically because those xrblock perf. metrics should be the basis for an IETF registry.
Feedback?

Regards, Benoit



-------- Original Message --------

Subject:

Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)

Date:

Wed, 5 Feb 2014 22:20:33 -0800

From:

Benoit Claise <bclaise@cisco.com>

To:

The IESG <iesg@ietf.org>

CC:

<xrblock-chairs@tools.ietf.org>, <draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org>

 

Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
The metric names in the registry are not specific enough: payload type,
calculation identifier metric, segment type, and potentially MOS. I guess
they should say something about RTP. Let me file this DISCUSS while I
double-check with the performance metric directorate.
 
 
 
 
.
 

 

 


--------------040808030007020103080007-- From bill.wu@huawei.com Mon Feb 10 22:06:56 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2541A0799 for ; Mon, 10 Feb 2014 22:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sn6m_s7ygWfE for ; Mon, 10 Feb 2014 22:06:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9D61A08B3 for ; Mon, 10 Feb 2014 22:06:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAZ47349; Tue, 11 Feb 2014 06:06:43 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 06:05:45 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 06:06:39 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 14:06:32 +0800 From: Qin Wu To: Benoit Claise , "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" Thread-Topic: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) Thread-Index: AQHPIwOmLwhu2PB9J0WyKFRcpGvbR5qvljUsgAABKdA= Date: Tue, 11 Feb 2014 06:06:31 +0000 Message-ID: References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> <52F39769.1040105@cisco.com> <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> <52F9BBB0.1090204@cisco.com> In-Reply-To: <52F9BBB0.1090204@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 06:06:56 -0000 --_004_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_ Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_" --_000_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEJlbm9pdCBhbmQgQWw6DQpZZXMsIEkgY29uZmlybWVkIHRvIG1ha2UgY2hhbmdlIHRvIEFw cGVuZGl4IEEgb2YgZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLiBJIGFtIG5vdCBzdXBw b3NlZCB0byBjaGFuZ2UgY2FsY3VsYXRpb24gYWxnb3JpdGhtIG5hbWUgaW4gdGhpcyBkcmFmdC4N CkhlcmUgaXMgbXkgcHJvcG9zZWQgY2hhbmdlIHRvIEFwcGVuZGl4KCBTZWUgYXR0YWNoZWQpIHdo aWNoIEkgaGF2ZSBzZW50IHRvIG15IGF1dGhvcnMgZm9yIGNvbmZpcm1hdGlvbi4NCkhvcGUgdGhp cyBjbGFyaWZ5Lg0KDQpSZWdhcmRzIQ0KLVFpbg0KRnJvbTogQmVub2l0IENsYWlzZSBbbWFpbHRv OmJjbGFpc2VAY2lzY28uY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTEsIDIwMTQgMTo1 NyBQTQ0KVG86IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgcG0tZGlyQGlldGYub3JnOyBRaW4gV3UN ClN1YmplY3Q6IFJlOiBbcG0tZGlyXSBGd2Q6IEJlbm9pdCBDbGFpc2UncyBEaXNjdXNzIG9uIGRy YWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdpdGggRElTQ1VTUykNCg0KSGkgQWws DQoNCkkgbWVhbnQgdGhlIGRpZmZlcmVudCAibWV0cmljIG5hbWUiIGVudHJpZXMgaW4gQXBwZW5k aXggQSBvZiB0aGUgZHJhZnQuDQpRaW4gV3UsIGluIGNjLCBhZ3JlZWQgdG8gaW1wcm92ZSB0aG9z ZS4NCldlIHNob3VsZCBhdm9pZCBjb2xsaXNpb25zIHdpdGggdGhlIGV4aXN0IFhSIGJsb2NrIGRl ZmluZWQgbWV0cmljcy4NCg0KUmVnYXJkcywgQmVub2l0DQpIaSBCZW5vaXQsDQppdCdzIG5vdCBj bGVhciB3aGF0IHJlZ2lzdHJ5IHlvdSBhcmUgYXNraW5nIGFib3V0Og0KDQpUaGUgSUFOQSBzZWN0 aW9uIG9mIHRoaXMgZHJhZnQgcmVmZXJlbmNlcyBhbmQgZXhpc3RpbmcgcmVnaXN0cnkgZm9yDQpS VENQLVhSIG1ldHJpY3MgKGRlZmluZWQgaW4gUkZDIDM2MTEpLCB3aGljaCBoYXMgYXR0cmlidXRl IG5hbWVzDQphbmQgbG9uZy1mb3JtIGF0dHJpYnV0ZSBuYW1lcyBmb3IgdGhlICJNT1MgTWV0cmlj cyBibG9jayIuDQoNCkFsc28sIHRoZXJlJ3MgYSBuZXcgcmVnaXN0cnkgb2YgY2FsY3VsYXRpb24g YWxnb3JpdGhtcyBkZWZpbmVkIGluDQp0aGUgSUFOQSBzZWN0aW9uOg0KDQogICBvICBJbml0aWFs IGFzc2lnbm1lbnRzIGFyZSBhcyBmb2xsb3dzOg0KDQpOYW1lICAgICAgICAgICAgIE5hbWUgRGVz Y3JpcHRpb24gICAgICAgICAgICAgICAgICBSZWZlcmVuY2UgICAgVHlwZQ0KPT09PT09PT09ICAg PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0gICA9PT09PT09PT09ICAgID09PT0N ClA1NjQgICAgICAgSVRVLVQgUC41NjQgQ29tcGxpYW50IEFsZ29yaXRobSAgICAgICAgW1AuNTY0 XSAgICAgICAgVm9pY2UNCkcxMDcgICAgICAgSVRVLVQgRy4xMDcgICAgICAgICAgICAgICAgICAg ICAgICAgICAgW0cuMTA3XSAgICAgICAgVm9pY2UNClRTMTAxXzMyOSAgRVRTSSBUUyAxMDEgMzI5 LTUgQW5uZXggRSAgICAgICAgICAgICAgW0VUU0ldICAgICAgICAgVm9pY2UNCkpKMjAxXzEgICAg VFRDIEpKMjAxLjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1RUQ10gICAgICAgICAgVm9p Y2UNCkcxMDdfMSAgICAgSVRVLVQgRy4xMDcuMSAgICAgICAgICAgICAgICAgICAgICAgICAgW0cu MTA3LjFdICAgICAgVm9pY2UNClA4NjIgICAgICAgSVRVLVQgUC44NjIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgW1AuODYyXSAgICAgICAgVm9pY2UNClA4NjJfMiAgICAgSVRVLVQgUC44NjIu MiAgICAgICAgICAgICAgICAgICAgICAgICAgW1AuODYyLjJdICAgICAgVm9pY2UNClA4NjMgICAg ICAgSVRVLVQgUC44NjMgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1AuODYzXSAgICAgICAg Vm9pY2UNClAxMjAxXzEgICAgSVRVLVQgUC4xMjAxLjEgICAgICAgICAgICAgICAgICAgICBbUC4x MjAxLjFdICAgICAgTXVsdGltZWRpYQ0KUDEyMDFfMiAgICBJVFUtVCBQLjEyMDEuMiAgICAgICAg ICAgICAgICAgICAgIFtQLjEyMDEuMl0gICAgICBNdWx0aW1lZGlhDQpQMTIwMl8xICAgIElUVS1U IFAuMTIwMi4xICAgICAgICAgICAgICAgICAgICAgW1AuMTIwMi4xXSAgICAgICAgIFZpZGVvDQpQ MTIwMl8yICAgIElUVS1UIFAuMTIwMi4yICAgICAgICAgICAgICAgICAgICAgW1AuMTIwMi4yXSAg ICAgICAgIFZpZGVvDQoNCldoaWNoIG9uZSBvZiB0aGVzZSwgb3Igb3RoZXIgbmFtaW5nIGNvbnZl bnRpb24gYXJlIHlvdSB0YWxraW5nIGFib3V0Pw0KQWwNCg0KDQpGcm9tOiBwbS1kaXIgW21haWx0 bzpwbS1kaXItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA5OjA5IEFNDQpUbzogcG0tZGlyQGlldGYu b3JnPG1haWx0bzpwbS1kaXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbcG0tZGlyXSBGd2Q6IEJlbm9p dCBDbGFpc2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzog KHdpdGggRElTQ1VTUykNCg0KUE0tRGlyLA0KDQpJIGJlbGlldmUgdGhhdCB3ZSBuZWVkIGEgbGl0 dGxlIGJpdCBvZiBjb25zaXN0ZW5jeSByZWdhcmRpbmcgdGhlIG5hbWluZyBjb252ZW50aW9uIGZv ciB0aGUgcGVyZi4gbWV0cmljcy4NClNwZWNpZmljYWxseSBiZWNhdXNlIHRob3NlIHhyYmxvY2sg cGVyZi4gbWV0cmljcyBzaG91bGQgYmUgdGhlIGJhc2lzIGZvciBhbiBJRVRGIHJlZ2lzdHJ5Lg0K RmVlZGJhY2s/DQoNClJlZ2FyZHMsIEJlbm9pdA0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCkJlbm9pdCBDbGFpc2UncyBEaXNjdXNzIG9uIGRyYWZ0 LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdpdGggRElTQ1VTUykNCg0KRGF0ZToNCg0K V2VkLCA1IEZlYiAyMDE0IDIyOjIwOjMzIC0wODAwDQoNCkZyb206DQoNCkJlbm9pdCBDbGFpc2Ug PGJjbGFpc2VAY2lzY28uY29tPjxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+DQoNClRvOg0KDQpU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz48bWFpbHRvOmllc2dAaWV0Zi5vcmc+DQoNCkNDOg0KDQo8 eHJibG9jay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+PG1haWx0bzp4cmJsb2NrLWNoYWlyc0B0b29s cy5pZXRmLm9yZz4sIDxkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2VAdG9vbHMuaWV0Zi5v cmc+PG1haWx0bzpkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2VAdG9vbHMuaWV0Zi5vcmc+ DQoNCg0KDQpCZW5vaXQgQ2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KDQpkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6IERpc2N1c3MN Cg0KDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbA0KDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRv IGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KDQppbnRyb2R1Y3RvcnkgcGFy YWdyYXBoLCBob3dldmVyLikNCg0KDQoNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cDovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCg0KZm9yIG1vcmUg aW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0K DQoNCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLw0KDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCkRJU0NVU1M6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNClRoZSBtZXRyaWMgbmFtZXMgaW4g dGhlIHJlZ2lzdHJ5IGFyZSBub3Qgc3BlY2lmaWMgZW5vdWdoOiBwYXlsb2FkIHR5cGUsDQoNCmNh bGN1bGF0aW9uIGlkZW50aWZpZXIgbWV0cmljLCBzZWdtZW50IHR5cGUsIGFuZCBwb3RlbnRpYWxs eSBNT1MuIEkgZ3Vlc3MNCg0KdGhleSBzaG91bGQgc2F5IHNvbWV0aGluZyBhYm91dCBSVFAuIExl dCBtZSBmaWxlIHRoaXMgRElTQ1VTUyB3aGlsZSBJDQoNCmRvdWJsZS1jaGVjayB3aXRoIHRoZSBw ZXJmb3JtYW5jZSBtZXRyaWMgZGlyZWN0b3JhdGUuDQoNCg0KDQoNCg0KDQoNCg0KDQouDQoNCg0K DQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IFw7Y29sb3JcOndpbmRvd3Rl eHQiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZhbWls eTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLkhUTUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQ cmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9ybWF0dGVkDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFj azt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpi bGFjazt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSwgQmVub2l0IGFuZCBBbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVz LCBJIGNvbmZpcm1lZCB0byBtYWtlIGNoYW5nZSB0byBBcHBlbmRpeCBBIG9mIGRyYWZ0LWlldGYt eHJibG9jay1ydGNwLXhyLXFvZS4gSSBhbSBub3Qgc3VwcG9zZWQgdG8gY2hhbmdlIGNhbGN1bGF0 aW9uIGFsZ29yaXRobSBuYW1lIGluIHRoaXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhlcmUgaXMgbXkgcHJvcG9zZWQgY2hhbmdlIHRvIEFwcGVuZGl4KCBTZWUgYXR0YWNo ZWQpIHdoaWNoIEkgaGF2ZSBzZW50IHRvIG15IGF1dGhvcnMgZm9yIGNvbmZpcm1hdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG9wZSB0aGlzIGNsYXJpZnkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S ZWdhcmRzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUWluPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0 Ij4gQmVub2l0IENsYWlzZSBbbWFpbHRvOmJjbGFpc2VAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgcG0tZGlyQGlldGYub3JnOyBRaW4gV3U8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtwbS1kaXJdIEZ3ZDogQmVub2l0IENsYWlzZSdzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTEzOiAod2l0aCBESVNDVVNTKTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbCw8YnI+ DQo8YnI+DQpJIG1lYW50IHRoZSBkaWZmZXJlbnQgJnF1b3Q7bWV0cmljIG5hbWUmcXVvdDsgZW50 cmllcyBpbiBBcHBlbmRpeCBBIG9mIHRoZSBkcmFmdC48YnI+DQpRaW4gV3UsIGluIGNjLCBhZ3Jl ZWQgdG8gaW1wcm92ZSB0aG9zZS48YnI+DQpXZSBzaG91bGQgYXZvaWQgY29sbGlzaW9ucyB3aXRo IHRoZSBleGlzdCBYUiBibG9jayBkZWZpbmVkIG1ldHJpY3MuPGJyPg0KPGJyPg0KUmVnYXJkcywg QmVub2l0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcg O2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEJlbm9pdCw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93 dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+aXQncyBub3QgY2xlYXIgd2hhdCByZWdpc3Ry eSB5b3UgYXJlIGFza2luZyBhYm91dDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2Nv bG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBJQU5BIHNlY3Rpb24g b2YgdGhpcyBkcmFmdCByZWZlcmVuY2VzIGFuZCBleGlzdGluZyByZWdpc3RyeSBmb3INCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0 ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5SVENQLVhSIG1ldHJpY3MgKGRlZmluZWQgaW4g UkZDIDM2MTEpLCB3aGljaCBoYXMgYXR0cmlidXRlIG5hbWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPmFuZCBsb25nLWZvcm0gYXR0cmlidXRlIG5hbWVzIGZvciB0aGUgJnF1b3Q7 TU9TIE1ldHJpY3MgYmxvY2smcXVvdDsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtj b2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BbHNvLCB0aGVyZSdzIGEg bmV3IHJlZ2lzdHJ5IG9mIGNhbGN1bGF0aW9uIGFsZ29yaXRobXMgZGVmaW5lZCBpbg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3Rl eHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnRoZSBJQU5BIHNlY3Rpb246PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJbml0aWFsIGFzc2lnbm1lbnRzIGFyZSBhcyBmb2xs b3dzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xv cjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+TmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOYW1lIERlc2NyaXB0aW9u Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZmVyZW5jZSZu YnNwOyZuYnNwOyZuYnNwOyBUeXBlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPj09 PT09PT09PSZuYnNwOyZuYnNwOyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSZu YnNwOyZuYnNwOyA9PT09PT09PT09Jm5ic3A7Jm5ic3A7Jm5ic3A7ID09PT08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+UDU2NCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJVFUtVCBQLjU2NCBDb21wbGlhbnQgQWxnb3JpdGhtJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQLjU2NF0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVm9pY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RzEw NyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJVFUtVCBHLjEwNyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbRy4xMDddJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZvaWNlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlRTMTAxXzMyOSZuYnNwOyBFVFNJIFRTIDEwMSAzMjktNSBBbm5leCBF Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtFVFNJXSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtWb2ljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5KSjIwMV8xJm5ic3A7Jm5ic3A7Jm5ic3A7IFRUQyBKSjIwMS4xJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtUVENdJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZvaWNlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkcxMDdfMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJVFUtVCBHLjEw Ny4xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtHLjEwNy4xXSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWb2ljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5QODYyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElUVS1UIFAuODYy Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQLjg2Ml0m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVm9pY2U8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+UDg2Ml8yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElU VS1UIFAuODYyLjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W1AuODYyLjJd Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZvaWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPlA4NjMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVRV LVQgUC44NjMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg W1AuODYzXSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWb2ljZTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5k b3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QMTIwMV8xJm5ic3A7Jm5ic3A7Jm5ic3A7 IElUVS1UIFAuMTIwMS4xJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQLjEyMDEuMV0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTXVsdGltZWRpYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QMTIwMV8y Jm5ic3A7Jm5ic3A7Jm5ic3A7IElUVS1UIFAuMTIwMS4yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQLjEyMDEuMl0mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTXVsdGltZWRpYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5QMTIwMl8xJm5ic3A7Jm5ic3A7Jm5ic3A7IElUVS1UIFAuMTIwMi4xJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFtQLjEyMDIuMV0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVmlkZW88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7 Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UDEyMDJfMiZuYnNwOyZu YnNwOyZuYnNwOyBJVFUtVCBQLjEyMDIuMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUC4xMjAyLjJdJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZpZGVvPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3IDtjb2xvcjp3aW5kb3d0ZXh0JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5X aGljaCBvbmUgb2YgdGhlc2UsIG9yIG90aGVyIG5hbWluZyBjb252ZW50aW9uIGFyZSB5b3UgdGFs a2luZyBhYm91dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyA7Y29sb3I6d2luZG93dGV4dCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QWw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyA7Y29sb3I6d2luZG93dGV4dCZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOndpbmRvd3RleHQmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBw bS1kaXIgWzxhIGhyZWY9Im1haWx0bzpwbS1kaXItYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnBt LWRpci1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QmVub2l0IENs YWlzZTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgOTowOSBB TTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBtLWRpckBpZXRmLm9yZyI+cG0tZGly QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbcG0tZGlyXSBGd2Q6IEJlbm9pdCBD bGFpc2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdp dGggRElTQ1VTUyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QTS1EaXIsPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCBhIGxpdHRsZSBiaXQg b2YgY29uc2lzdGVuY3kgcmVnYXJkaW5nIHRoZSBuYW1pbmcgY29udmVudGlvbiBmb3IgdGhlIHBl cmYuIG1ldHJpY3MuPGJyPg0KU3BlY2lmaWNhbGx5IGJlY2F1c2UgdGhvc2UgeHJibG9jayBwZXJm LiBtZXRyaWNzIHNob3VsZCBiZSB0aGUgYmFzaXMgZm9yIGFuIElFVEYgcmVnaXN0cnkuPGJyPg0K RmVlZGJhY2s/PGJyPg0KPGJyPg0KUmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tLSA8bzpwPjwvbzpwPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFi bGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0 LWFsaWduOnJpZ2h0Ij48Yj5TdWJqZWN0OiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRk IHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C ZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2Ut MTM6ICh3aXRoIERJU0NVU1MpPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJp Z2h0Ij48Yj5EYXRlOiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZWQsIDUgRmViIDIw MTQgMjI6MjA6MzMgLTA4MDA8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmln aHQiPjxiPkZyb206IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRp bmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbm9pdCBDbGFpc2Ug PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VAY2lzY28uY29tIj4mbHQ7YmNsYWlzZUBjaXNjby5jb20m Z3Q7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIi IHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+VG86 IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBJRVNHIDxhIGhyZWY9Im1haWx0bzpp ZXNnQGlldGYub3JnIj4mbHQ7aWVzZ0BpZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3A+DQo8 L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRk aW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQi IHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5DQzogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90 ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0ibWFpbHRvOnhyYmxvY2stY2hhaXJzQHRvb2xzLmlldGYub3JnIj4mbHQ7 eHJibG9jay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcmZ3Q7PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpk cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2VAdG9vbHMuaWV0Zi5vcmciPiZsdDtkcmFmdC1p ZXRmLXhyYmxvY2stcnRjcC14ci1xb2VAdG9vbHMuaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cHJlPkJlbm9pdCBDbGFpc2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRp b24gZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHIt cW9lLTEzOiBEaXNjdXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+V2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5l IGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPG86cD48L286cD48L3ByZT4NCjxwcmU+ZW1haWwgYWRk cmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0 IHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwi Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1s PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElF U0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBi ZSBmb3VuZCBoZXJlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLyI+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1x b2UvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ESVNDVVNTOjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgbWV0cmljIG5hbWVzIGluIHRoZSByZWdp c3RyeSBhcmUgbm90IHNwZWNpZmljIGVub3VnaDogcGF5bG9hZCB0eXBlLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmNhbGN1bGF0aW9uIGlkZW50aWZpZXIgbWV0cmljLCBzZWdtZW50IHR5cGUsIGFu ZCBwb3RlbnRpYWxseSBNT1MuIEkgZ3Vlc3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGV5IHNo b3VsZCBzYXkgc29tZXRoaW5nIGFib3V0IFJUUC4gTGV0IG1lIGZpbGUgdGhpcyBESVNDVVNTIHdo aWxlIEk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kb3VibGUtY2hlY2sgd2l0aCB0aGUgcGVyZm9y bWFuY2UgbWV0cmljIGRpcmVjdG9yYXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_-- --_004_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="draft-ietf-xrblock-rtcp-xr-qoe-14(2014-2-11).docx" Content-Description: draft-ietf-xrblock-rtcp-xr-qoe-14(2014-2-11).docx Content-Disposition: attachment; filename="draft-ietf-xrblock-rtcp-xr-qoe-14(2014-2-11).docx"; size=37444; creation-date="Tue, 11 Feb 2014 05:59:24 GMT"; modification-date="Tue, 11 Feb 2014 06:01:06 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDozy0A3QEAAK4JAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 Vstu2zAQvBfoPwi8FhadHIqisJxDmxzbAHWBXmlyZRPhC+Q6if++KylSi9iREBO6CBAEzs7O7Cy1 unm2pniEmLR3Fbsql6wAJ73Sblex35u7xRdWJBROCeMdVOwIid2sP35YbY4BUkGnXarYHjF85TzJ PViRSh/A0ZfaRyuQXuOOByEfxA749XL5mUvvEBwusMFg69VPIhC1guJeRPwhLNXhTz4qXnuPziOk kuBY8a0715SumAjBaCmQiPNHp14VXfi61hKUlwdLpcoGLkQvISVqzZpygP7UQPPzJOQhobd/rOEa wd5HH9JVNpUBtMGDiBpSz+E71OJgsLh9Jn06SyKY9L7OX6Qu6WSrTtrrMFZhXNoRdVqLBoXHYS5w aEC2QrteoTdHxR3sFiJ5m+3PyagM0JMkEh7NHMPa4U6WB6dmSkuPPEaB/GoTwimZ2SZAkwAFakGh fRWSN0cgASINwAzLokcea39YWBCvs9s/mcFmXUEcqz/I3+2XbAodzHv07zjmL8gLmm/FR7p9gLfP fBItzJjebck9CDWL3x3wZP2absSN2BrItvuM6C/QkySeYPtrtuj9Bz5JpBMt3/sTLabd+Jc+Hy8w o7+zJZ0+Ezne/m2t/wIAAP//AwBQSwMEFAAGAAgAAAAhAJlVfgUEAQAA4QIAAAsACAJfcmVscy8u cmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACsks9Kw0AQxu+C77DMvZm0iog06UWE3kTiAwy70ySY/cPuVNu3dy2IBmrSg8ed +eab33zsenOwg3rnmHrvKlgWJSh22pvetRW8Nk+Le1BJyBkavOMKjpxgU19frV94IMlDqetDUtnF pQo6kfCAmHTHllLhA7vc2floSfIzthhIv1HLuCrLO4y/PaAeeaqtqSBuzQ2o5hjy5nlvv9v1mh+9 3lt2cmYF8kHYGTaLEDNblD5foxqKLUsFxuvnXE5IIRQZG/A80epyor+vRctChoRQ+8jTPF+KKaDl 5UDzEY0VP+l8+GgwR3TKdorm9j9p9D6JtzPxnDTfSDj6mPUnAAAA//8DAFBLAwQUAAYACAAAACEA nIHcTWQBAABQBwAAHAAIAXdvcmQvX3JlbHMvZG9jdW1lbnQueG1sLnJlbHMgogQBKKAAAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0lctOwzAQRfdI/EPkPXEToDzUpBuE1C0Uia2TTB4itiN7 AvTvGVrVTaEyG7OJNDfK3KM7Y2ex/JR99A7GdlplLIlnLAJV6qpTTcZe1o8XtyyyKFQleq0gYxuw bJmfny2eoBdIH9m2G2xEXZTNWIs43HNuyxaksLEeQNGbWhspkErT8EGUb6IBns5mc26mPVh+1DNa VRkzq4r815uBnP/ureu6K+FBl6MEhScseAuiAkMdhWkAqee2TmKCZPy0f3IZEgApGDj4b0u+fXoh gjJY3PQ0RRfCrvZlcBMyAlCV0jgF2Cs+hCQNyVBrhWtR9JNROMlHERRCjbIAQwftMAon+SCSkEmU o0UtX2n/3T7EMXcq7xCkdzXnIWlqrfHHcjjJG0nQTL4tp7fErk59ANchU/iA4hkQaTMmp3Qi+kAS usD/+770JnEV0t/+imGv+DK4C4lwehnckeBH/8H8CwAA//8DAFBLAwQUAAYACAAAACEATgZXQw0o AADDKQQAEQAAAHdvcmQvZG9jdW1lbnQueG1s7F1RcxpHl33fqv0PXbysvSXJDCAJUYEtWZKz+mrj sIjsppLKQ4tpRMfD9Gx3Y1n+9Xt7ZhA00giU5IuZmeMH24wQDE3fvueee++53/3Hl3nEPgttpIr7 jeCo2WAinqhQxnf9xk/jD4fdBjOWxyGPVCz6jQdhGv8x+Nd/+e6+F6rJYi5iy+glYtP7TD+dWZv0 3r0zk5mYc3OkEhHTD6dKz7mlh/ru3ZzrT4vkcKLmCbfyVkbSPrxrNZsnjfxlVL+x0HEvf4nDuZxo ZdTUul/pqelUTkT+z/I39C7vm/3mZX7L6Tu+0yKie1CxmcnELF9t/kdfjT7ibPkin1/6EJ/n0fJ5 98ku7xZqfk/fxzzKbvte6TDRaiKMoauX2Q8fXzFovvTe+QK6l3j8jV1uwX/P5Z3MuYwfX8btjo3v //HLO6Iv71323u/cS60+CK3FgPbSrQof3L8Ju+/RXgxH/Uaz+b57etam/ZdfGtIX/eTipZjyRWSf /mS4dil95aF2/9zLUN1fqNhqFb1zFyy/Nfm/9EafedRvRGJq3bsmyvQbZ8FJY/nEZ58QdNutl5/R Ou10X35G++Sk8/IzOsfd5svPOO6cbbnTk06w5U5P260td9ptdbbcKS3YljsNms3TLbcaNM/Ottxr EJw1t9xs0KLbfXnVgvZpZ9vtdk6O09t9t9otfGHVTcIn4vIq3Ryrxx+zx+HvC2NH8m5mr+MwvWTo 6WSvtIci6WylRe+bPxgtIrrgXiO7WZ3tVf2B9qmh53AzkbLfuFALLYVmH8W9+03BjT03kvcbYzkX xl1mIzXnZJL3vdl5bJ7+yoQ29PqrZDcW82Ssvtcyv8+v9OupHbTyhTFfL9xdrF2jlUjvkf5N8nul J6SG61mpM6zSfBj6dp0P6rkvir6ORAsj9GfRGHwUlg6tT+x/6S/3DX6v1SJhqz/fuY0xcH+nR0z2 V1m+wsJPvfp8z/1v8zNX4usfnB+xi4gQivfp3CZ3Gxm+id8ujwHPRcI3bYIG+Cb4pr/U0Rae0tex FToW9pDigKl9elJ7J9nSQVXbN218ZAqV1PRKazq67ENCjt0kIopuLNc2R1vV8F1jEbmw+2Gnj38V h+7Dw7VtCQ/g2uDa1gMmOioQdv21MaSLnZwXi0MROqrRLkyP0fFMlKMODRtrPvn01K/5V/77iP3v wjv4cLLhZFun8UAoOSoGhNLfyY4VgvarL4kkdqnH/rGIHlgQHLBWM+g8HmneQVYPzM42P3MlMPnz dCJ9zxufti4hyn8u+L2QO314BCgu+YS80EY2Dm4cbvzvTnIVuvFHh/3sfzaOuTpkhTY/cpWd+OiI 3UxmylrvQyPsRNiJsBN1DN+yKOPV/so7weoRb25+5Ep4qsGlWFhXOMkoFyQ+qbn3KeGa4JrgmuCa SuWaHiMr7yiDj3qsgy5bheXg+yP2i9Kx933CNcE1wTXBNZXONXmnGLxSab1SQaJuWfj/i4C/WmuJ QlYKWSl0K33j1iuwfGlv1mOA+Ox/Nv1zNWi+f/B4wfUDO8vqhrwPiVAKoRRCqdKGUjBfmC/MF+b7 qHoBGYsnihyQsXiqUgIZi56BjEUutVEgY8FG4yHLpW/YUCurJipib0bji+FbdvUl78AaiURpy978 PHrL3kdq8skw0m9iP/x4w34QVssJwo2VOBCYMDBhYMLKxoTlVFF20pGgD040nGhOB47YwWeQFZTI KLGJxtG9aBx9huT2Di8SqdpUO7nTfF49sROSxCRJUCns9PCLvnUw9VDbSUIPDv9PicOgvcuyoMcQ PYY48cuuPQnKHJQ5KPPSUuYELquRlT+/NZa0itAPikoxqs1BNEki16XXtQa2ALYAtgC22NfGhPFM GvY4hyUUUzp0DePxa1J9HlOCAw8HHg48HHj7euCtyhKYjCfRws2pYjSdg8U0/MSIu3QelZP5dqdg yLgxaiK5JWXZm8shTjrk+RCZpeOHSh+ZVYU2Kug83C4RWs28XsIpXSlopIXxDuuCvGaewKv4XrAz bhmPInXPLGn76LRAz/k9NV0ry8vK9BZGkGNknGke3wlvDQHtAe0B7QHt9xXae4dVwYFfvUIWNd3l c9fD0bn6dJ4kkZxkY3mPvKWB/4L/gv8qrf+C+cJ8Yb6lNd+qxNgDgpA0YczFztYlz34QcwWYAV4Y vHA1eGHADMAMwAzAjH1ludKKnY2h3QRDzOJ2Lq3LUxN7P11EEZuomPru5zyeCHYv7cxx/wAqACoA KtUAKlUJqJDAdqfyUnllQP23n6WRKkYCWxiRSXRSrP3+YshOu2lNVvrfM3D7aJNBm8x9NXwZgm4E 3Qi6EXTva9Dtx9tUGq4pplb6kyuiW3bP5CkBwZZPZlfxHbXTCA2FqGjduKF5B807aN7tsebdmJtP 7IPSRBy+ub4af3h7xNhHZQUxiFRIrIhH1OxOq0Vi2Jw/UGWxUSyUJF4gbxcWHCPiMsRlFYnLwDFW Uvwuh65eNqigYLoehcMrDM/NI34/vHQagYac35i6ZiJycK7oZ7LQWsR29SxvFUFkgMhYj3UCiL+S D4H4676Iv3qHVcGRX70emewgZxIptceUGgVyM2uT3rt3IaeCVtKd+yT0kdPDPVL67l2Yur53ubN7 h2QbgjoEdQjqPor7BoltCm7sHvNXSwI+B/ApW58eaGtcPen0yzAdTMOJxPoi54u5Q/dGfmFzFduZ 7yoA6wHrAeuRn9zX/GQ9YT0JdO3ywetBYblMzK1gi4TwvAgPnMpLxCfufzR8bdsymUREUfXiPnVr VERiQFu3Sfr567FPbh/yDN4a50nqQPGDt0cAeAB4AHgAeAB49ijgHVg598srChjcinmyAaXgri3R t9TbRvI+WiXaSbIyq5iTq3sS7hsCP1NBWbqJv1pwanBqcGpwanBq++TU5nSU03keefFHPRxbQesj Bezk2iYyrbgUxEunFZdUfEm6rIY1XPWO6/ImR3inhTFHDW/p4OXg5eDlSuvlYL4wX5hvac238hXT z+nP3EvSmxFfEkltcSpm/1hEDywIDlirGXRQOoTSIZQOVaR0COAE4ATgBODkGzNogwuVPGh5N7Ou L1WC5l+3SbTXo72+zO31wBjAGOvnGVrovkML3UiRkK1rPZidx0b2GxdqoSXJUOQNCRPjX3o3oDUz VCwwVt9rGWYPv9KvU9l/v9FqNvIrF8a/RmfPUoixIDfD2Ap7vJm8TSkO5kQy2FgvqEPYDY2ldA1L aAIhaTgyGVKzsJxKEual3A39BLkaSPBCgrcasoWVJ3u9w6ogJ1+9svFlZfQun75ipXYFXo8v7Exp J4VxTkx/Gnm7IrtUnzcEww+GHww/GP4pX0S232g233dPz9pdh9a1keFw7ZKD5clQu3/uZajuL6jV VqsoReOW3xr3A/p3Cco92ciz4CSD7UVPCLrt1svPaJ12ui8/A+QZyLMyk2eVR6Rp+cESoLmWABp8 87uYWFcxuTYjwIXgq6j83wz7L3G3UWIKnhE8I3hG5DK/cS6zIOJibPg4CIaNREQDzUlrnA659FS7 VJPFnIhFqJQg9CpGzMicUDgB8cG/OXMSkTjUSMQhNWCGQ34n3mvBP2URXuFZ9ybXorMuhyLESocu ouKO2IhDSbMM37qmFzGdOrRHVaYO4jmtC5Jt8og64DrgOuA64Lp9xXXeYVWbnEqyuKWznFCsindZ gHqkVUhw0M6Iw1jyGZRfGUYkrigot/JZinvn4+jB8sdA+0D7QPsVSbRUnqnd5ZivXu3AhEbDufHr vpxagZuvmJcbHOQ1bg8sFGZC46AEe6BCvWXBgKuNo6IBmhM1cTiAau/cWHq6klBI520XxHCI4RDD IYZDDLdPSj1WeYd0PZxaAWe5GbddqFBQafg8UbHLy1A3vJupQdKzbKrV3A/z2JxYTm8p4e/g7+Dv 4O/g7/bJ38l4Ei1Cv2On1k7vRs6TKGtmen9zyf4rS84xS87ORX7LoC90ibobiukoyGOdI2ToGl4h K2pMUWOKGtM9nh/lQfOCA796zOVmb2rBB68YZ1kQ3mXNvGnR8HohnmMwieB10qufqbM3TBlMtbDs nmvNY/tAbtDbPQjsENghsENgh8BunwK7x0DFO6tr7fAoYnMFlc9HeOjwReEJCk8qUngCSApICkha WkgK84X5wnxLa74FQUb16MTzJKEmMPmFnfvRQ8EC1INWZD8IV/3otJMSJ58UuwKRhXGtvaMPFyft syYbC8qxUVubF5ri0Mehj0O/tIc+zBfmC/MtrflWvlWHsAe7urwe/zhiH38cX/VYknUhTmjk5J1g P9MfV9LzKz3P/f83dvuQssUxtSjSNUAVSBoXyvZBhAQiJGyP5Nu9w6ogGK1eNB4v5rdC7/LZKxaI U0/i/Uy4wclG3sUCYsXrOBSVqKhELXMlKuJqxNXr5xmwJrAmsOY3rjUccJIx+uHHmxqCzYJi8v/h 0ULkqR9vVeC/4L/gv0rLC+9uvqfn7fZxczkRY3QpMCujlyga2nfcOdsy1eOkE2yZ6nHabm2Z6tFt dbYcNDRcJB8KWDhdpNk83XKrgJ+7w8/xTMxFvzGXsdJXpBjs2gH/vvmOznKzMTQ6n1IzGuqNOTX5 IMj914+myuwC4MHSPx7kqA3j+e8EQtNim10+fsVIz4Lt8JHPRe8ZaC6dFFtPhmQAzgSzYW/9xnlI 1ilJro1bpd0PnNq2m54adA6brcNmdxx0e+2zXrP5S8MNbno0JWdIucdLr+eW9oGGPbk34mYin45w JdnT9BD4cwcDvfxMxjSFavly+aTXf8YoWMqIjsZDb3vRuUKLOXDXEvfRE7ofNwNrtHa2LC95B87y IpABrQSQwS2tQjqq2BOOCFoEZF6eXxa0TzvbgEzn5DgFMrRJlzPXyOTVTcIn4vIqVepfPf6YPQ5/ J8mqkbyb2es4H6dMT3d1i1lXDB0L9L75g9EionPCvUZ2s6XxpEtYAPPdss06x90tuwzA3k0ah/n+ nVPbl+a7BkU8J/t6MNJvjOVcGDdmfp94ZQfrPdwBVK+Vml5pB0HtQ0Le507zeT1Q/WUqtZw4sa0e I/TMSGFZzgmqhxQA8Zj9mBCKJyGum4ki5ZKp8qtA4Org6kBBlxap1sLV1dbbzWmgNuGPUPJdvH09 3B1PSIIyGyTEEqHJn9F8u4nYxEMrTitwYSkFozNFDC84rYyMK2CMaSARUVqMOD/B5/6SElBIqa2q nDgDN3dJTCXVhDrt0kzrNZ2xOkPvJeRuIHdTEbmbqpxXBTmdNMNXXz4gGwfra24WkCH1gEfkwbdh RRq3FEXVa3EJaUj6w0GkzNbdkC5ALbbDQW03gzQ0iS08+F1au73vqT4bgjkFY0VKjzqfpG2okZdj GA0ALwAvAC+luRxZsqyd2ePsV20pwXu1iMJtCK8+yS8+ndKcGcYXoVRMaeZU+RX7vwWPpH3whceQ 6UKmC5mu0ma6YL4wX5hvac23FjTsLrisesRb1mkxU4ClpOiqP4vGgBELS7VXZqGpySm2Dphe8Giy IF3XtErrRghm8vmI7aPWUXDwpCsD7g7uDu4O7u4bizkg6+ga3lwbCx3IeR+LHVBrzsIvEql1zjEt o5HptN9HiVBwL0gpIKVQkZQCwCjAKMAowOg+g9Haci8/xdJuLXmqT0bQp1567HmuhaUQPisAT5Gr t33g7+Dv4O/g7/bZ39W2AqaAYniZgcGJjhMdJ3ppT3SYL8wX5lta80XxR65IU9Hij8dKBy+KfhmR VXxPDBXJUL4xb9m9tDM2VJbqQCSPvLKQSzXnkkR7iKLwFg7eDt4O3g7eDvSDltSouFddSYO8bs87 sGvt6doHrEVNpQnXnLIMyWw1JhY1IKgBQQ0IakAw7ASS5vyWGoshaf63ywi7WBKTTtZEgUHB1EUY maS7Sc9vowLkgLX1s2AVysi+Wj1mQ2/K9zfPzrZMIguCs+aWUWSY4XGhFuth/YSmwK1fSueNmD8+ r6dWDq+2RSDzVXclmJhl1ylpRTsBWyfxteouDVZ8jHNx7DomQTQC4t6yIeOAjAMyDsg4IOOwDk32 QwdtkI2xZNOI3/mM+stpB5zpONNxppf2TIf5wnxhvqU134qXt7mJAzWeQfiT8Sv2XkZiFd8Ljm9Y m8pkfMY9OOqsGAgfv8LFwcXBxZXWxcF8Yb4w39Kab8VRSc0R6kgkSltKB3l5nlrj1LmiEVEZOB19 uGifBAHgKAqUUaCMAmUUKKNAGQXKwrhWKzairtTYjYGancdG+sVZdBX1Wj3z9cIsq9mfiAMXKibv AsSqV5x8e8Sov/nOyeDvsgC1mMrJxg+JoE5wq+XEWxQwKmBUwKiUllF5jfkeX1ycOierjQxHlwII FAi01gh0PKNROf0GFTArfcWNPTeSA4R+r2WYNUR89QHn/R8EobXO2j+DuGpNiH7kc+H40BSdp6DU Q6P3PRm7OEeGNAPF2SJf2JnS/cZ5SGYqjdXcKu1+EHJLtttqBp3DZuuw2R0H3V6722s2f2kMvlvL M/Qbzeb7bur60ut5Y+oHFVv3RtxM5NOAc1mF++dOCHr5GSky9RvLl3MzXciK/nijERGHBbGejNlo PPTWkqABLebAXUvc+yZ0P6nrz5bk9KzdfUQDQ1pit07eRUAEWrFEUbPYcefsJPvybIHHPOkEWxr1 TtutLX163VZnSyxyFpykg4FeIpCbp1tuNUBTIRnCbgfANxxH7szWHVYw3y1G0TnubjEKmC+PNjuL W3TavHykBe3TzpaFDTonx+lpQ5uUTkZyNqnHVjcJn4jLq9TdkQfPH3/MHoe/L4wdybuZvY5zpElP d12EWVaIvDq9b/5gtIjIzbvXyG42n4dWHvNdgyKek309GPmGZxF9MRQfjUQcCi3CIb8T77Xgn9Lv swiR1LwYAsCf7DbRj+NpL4WZaJlkw2ivLZOGLYwImVVMhk6odPrA7MzNqM1CA0t89SacBYx1p0YR BIUffOLkoI2RsVrf0HUsYWxF/ODL3u71/SkruqP9errj7Hm64/S83T5uZjRI2emOgZp6XoCCIq3U 9EprAojOR/Qbz88Zc3xGlRaigPch0ocRKyb4nHnrRGaXkj9VMbtBChaI5bIzQg46rTRlt5GafKJk /wfSGJkrLWi2muUyMgeEIh6n3W8uC0AEQIQ7alNiD1wYAUoE039r9Rn5rYLDPAuZ6e/2UesoOHhM kzg/tzY3EiXkKCEvDgNxpJXqSAO9v4WGBq0BWmNdrJOg2zKfDlojm1TyzysrAIk/U6EXQe5MQJQ5 21MEUP1B54zC7gseTRYRz2j9p3PPvaWDq4OrQ6k5Mtl7rvi5Xpy4FnVDUYiQ19NpKtDs36ysQXld mShFgBKAEoASgJJ9BiVeFFUQgFavjfvfGfspltbs8unr0cPth9++5uVGysi1e3sLBz8HPwc/Bz+3 z37u9eVzrgos7WkrNds6CMWUuhsdieqd2QWuvh7O7lcSzPuZ/vyGcgeUO6DcAYp50CtBM3JB9zUm nG5USEAxD2Ilr5NvGRDd8gMV1iw0ieJAOG/VuDhUpOHxxrxl99LO2FBZ16zIo/XFYpekXynjlJDx ADxIF5AuIF1AuoB02cMZp/m8au/ArjXj0j5gLZqrlXDNqacymaHiBRUvjYDaaCEoVSVFGoBSgFKA UoDSfQalu4CySla8gILpGSce52lHjSWJv95t1LscsLZ+FqyyqdLe/oHDg8ODw4PD22eHV9vSlzly Dk8dnk0dHnNTznOWiiRBghUf41wcu46t0NSQA19nH/V80I2EbiSoBbtBJt9QG2EHgSPvzCog3asX 32WawGwa8Tu/qLFgBfJCT8QviF8Qv5Q2foH5wnxhvqU136oo6L6oOVlPPOY6TI3fJvkyEqv4XnB8 A0+SSE5SQSfjM+7BUWfFQPj4FS4OLg4urrQuDuYL84X5ltZ8K45Kaq5BOkpnXVD9wy4YvR6t4XMV iigDp9Qk3j4JAsBR9IijRxw94ugRR484esSFYR/FPRtRV2rsSiNm57F5OuQePeJ/sEd8FyBWveT1 hAatram977II9UCj59Gd0tQbPmfX2SBbKTR1h1stJ94igWUBywKWpbQsC8wX5gvzLa35giTNRyVX D5mmykVP4FatM/kf+Vz0/InQ6UBoCgZl2G90XFTIF3amdL9xHlJ3naQh0twq7X4Qckt7pdUMOofN 1mGzOw66vXb3+Vnj77vHFxen1Zg1/nyFjJuwfVOHCdtrwR17LqZBMIM+k54tYtcw9YYQxgcVW+OO VjORTwm3PRpbiWAGwQyCGQQz+9wm5uGNAjSPYKaRDv/V5HTKPwfheQDOLoWZaJlkM2avLZOG2Zlg kZqQDKtcce40Hmdjz8jYeWMX8Ry/OuLpNJ+PeE7P2+3jJiKe8m+3Ae2f5fBib+MAHQEdAR0BHe0z OqKq2BVJw41RE0m0XZiplNsZ+Ugj7pySO5Nx6i41j+8ECw5bx8c47MDkgMnpRTIWo0VEXDdR4SoH 0kM9+K5MTE4t8lq1VceS8SRaGPm5jk2qAxT1o6gfRf0o6kdRP4r6i9KOrW5rC1cRtE87zQzcFSYv OyfH6YwDIn7oOcYhQAcJb5wS8eVVyrCuHn/MHoe/L4wdybuZvY7D9JLTcaQ+PWIcHbKkCgp63/wB YGZvD7Kf24TpvLi4ZhmHmQp3+fj1KOmnTMKaEDsjsdW14hhfFaV91DoKDrylA3285UjuHHe3nMjH nbMtQ2dOOkHr5VP9tN3qvvwM8h1b7vQsONlyp5iPA1fX2Ji+WgJXV1tGZe0gXyPQry9ZKKZUBuuS zEUqVwWIACqtyvQbUN6G8naZeXSAti1QCKAt2rTw4Ky5BWFiMP0GNILowB8UHXAqWF6UWYBGKlkR +RMBM7PLp68jPfEcH7F1q5hERFH19gqh+606aelHr8dGWVUIXV965gO0A7SDCkcU/ex5haN3ZtUG 8KyYqF93WYCKubIBSXr+TH9+Q/kPyn9Q/oPyH5T/oPwH5T/Q9Mxy+SbmyVh9r2Vec/WVKqxoCK7T q8mf8PXCNX2uXaNgV2dl/bagw9SRazWm19ZqXWoIOAv2xFDJ2L4xb7OOqqGy1EslqeF4bbHYJSns yjgl4LyFA70CegX0CugV0CvaiSGTGLkrhN6PsqiBERNX5eMd2AXcUsWolQJP1z5gLZr8l3DN7zRP ZkX1T/Bq8GrwaqX1ajBfmC/Mt7TmW4tG/11AWfWqVlIBa24WWjjBll3WoB7AdCxJmfpuo77pgLX1 s2CVTZX21g4ODw4PDg8ODyzMHrIwc2KD4PAmJBOQaGGE/iwaA2ZTh8c4sTE5S8XaR8GKj3Eujl3H lp7OI/g6qLhBxQ0qbvtErhcwzFl+vbYp9mwYJJtG/M4vanw57YD4BfEL4pfSxi8wX5gvzLe05gu+ nWJTqgeYV5Jv/8nUUVK3AJ47voEnSSQn3FXGGJ9xD446KwbCx69wcXBxcHGldXEwX5gvzLe05guE WmWEOhKJ0pbqH7w8z8uMYcV3xFyFIsrAKTWJt0+CAHAUPeLoEUePOHrE0SOOHnH0iP9Te8R3AWLV I0vDI8aG/CFSHAMiHgu1xg+JoE5wq+XE2xVgVMCogFEpLaPyGvM9vrg4dV3N6Rz0SwEECgRaawQ6 nlH3Ur9BHTtKX3Fjz43kzj5m57GR/c0RKdABhw7466SbBmmX3BPEVWtC9COfi96m1reMnf6VDPuN E2d/NLhwpnS/cR6SaUpjNbdKux+ENC/eyWYFncNm67DZHQfdXrvbazZ/aaQjsOkpqW/rN5rN993U 3aXXXzUh+8+dCnQLM1Jh6jeW0iH/vPhuNB76C0lYgFbSW4khLaNbi9Ozdjdbo1etRb9BDY3fJkYn jnSQB3HMxS4IWtA7gt6RavSOvCZoSU+u5cGOoIVWInHDyzBu0iloRh5zgcnKarHeN4uIBRELIpY/ q7R7KcxEy8SVGffYtWXSsIURIbOKydAprE4fmJ0J1+g855bRIGZ6BLQKtAq0Wg20WvEStZp3OjsW JcmSxX5pXq1pOvaBZDvmSgsaMm25jMwByXuINYmP1lFwsFw3ODs4Ozg7ODvIehA7w81EPk0eLrMB 35hQt5tEeq2d3Gpqne/5QU+iJMojFptnZ60sj2eLCiYwWD2rn/iGB5wzW5fdhPnCfGG+pa1orAXd 4oXMBSCseoX5WT3UTKEs/7Esn9IF6+PZiHW54NFkEaWyJr6qSfvIkS7ezoGrg6uDq4Org174et3D npAty+pFR7oQjT6lWlaXRC5SpipAAfncDJz0OOlx0pf2pIf5wnxhvqU1X3ASVdat+omAmfHi6pex WMV3g09JPMdBLAs/2JN8Ivwc/Bz8HPwcCIk9JCRWHMSvNfR2AxJg/Jn+/IZiDygwQoERCozQv0Er aVE5F1pJ0Up636ORpU5uJJfw+HrhVErWrlGwqzM5DVswpiTrrdkFbFW02AMTcxO+MTF3qEgf5o15 y+6lnbGhsq6HlEdeGcilmnNJ7aY3Ap2kAKsAqxUBqxUnjmveSZrPP9/F2+dFHRXfD+0D1qI5bQnX nKbyJbOiyhckDZA0QNKgtEkDmC/MF+ZbWvOtOAgBBWMWmnSuYwtgaoT+LBoDRqK2NKVuo7LlgLX1 s2DVKXt5aweHB4cHhweHhyKXPSxymVP3DxzeRs7Bpg6PcWJjcpaKtY+CFR/jXBy7ji35Rx7B10HO C3JekPOCnNe+y3ll4/zYNOJ3flHjy/0LiF8QvyB+KW38AvOF+cJ8S2u+4Nsr3Utq/Iq9l5FYxfeC 4xt4kkRykspZGZ9xD446KwbCx69wcXBxcHGldXEwX5gvzLe05ltxVFLzipCRSJS2VP/g5XlqjVPn KhRRBk6pSbx9EgSAo2i7QdtNRdpuAEcBRwFHAUf3tV5rFyBWvf5wccTYxYzHsfArjmqNRK+zicJS aOoHt1pOvL0BRwZHBkdWWkcG84X5wnxLa76gRaucuH8GbtUaiX7kc9FjHvy878nYSWDJsN84bbji 2IWdKd1vnIfUTyeN1dwq7X4Qckt7pdUMOofN1mGzOw66vU6712z+0hh8t2ZH/UazeXrebh83s+uZ mpb+oGLr3ujlWbrjGbU19hv01kpf8Wz8pHvz2Xlsnk7gnZh+48IXNZuREFO/sZwWk6t8xTwZq++1 DN+5OzVf6QXXJL/clVfLgJ0vQqn8pSQoQGvp3mG1pN1XL2m7++KS0q1rI8PRkL6iZvN99/Ss3f0D 6/wNR3oSBTvIY0S2Co02NqVefs567CYmYzYaD71FWG0nSmTQcjgLPftLtpO3d/KFvhQki/cnDPeb bihaoLH4YgfL6UzjfCT28rpb12yILF0ZuEeJM9NkfZPlprS89NwajS4F9EWhLwp9UWHYR3HPRqRo GO/unTPn+8d9sTNbzIJutE9OEHIj5EbIva+pH1eL5CG5gpizeumfbBb0Zoaj4OPXQy/xUpiJlokb Etpj15ZJwxZGhMwqJrO80AMTfDLb3DGrEDJovhr01zcs5y+F5Y9BpQfuU/LiVSTFN4117GDyTIIV IQ0wETARMNE+Y6LawqIJ1ySqFO6CCesBiojttDPBDKUjNnEPEXQ51xkEfwnu8Xx9hcjO56eTzEUo ebqmBdznenIiaP0lK/yneOM9TPgMNpn455NbzzLFZQOTz+8i3ygJW+Z5rYoAaEpqCj6nUsUPpJA2 V1qwUFguI3NASmp+qzdwNXA1cDVwNXD1HsqCYjjLhiRo+6h11DpgOUG0JBhd4flqTDC6INEFiS5I dEGikgWVLKhk+baVLGvEgkdTVYRFqLkoB1WfzxRYX7Gc0KKm3jxc4l4ueDRZRKmOnC8jlwFZjzAH EwMmBkwMmJg9Z2Kedjasxd6QxqSkSdp5E62bMipa+w1vQYLm2Vkr612yRRg9OGt2tzyl1W1t8RlB +7TT3PIqnZPjE/cUcsB0M2l/E/WIqZuET8TlVVrUvXr8MXsc/r4wdiTvZvY6zpuu6OmkT0bffyRj 10dG75s/GC0iuuBeI7sTXZZiLAdJUJCOgnTqnIL5ltd8EYXT8UvD3OeVLEj/KZbWeJFkrevR/SD8 uaj7mfSRt3wIxLeAqs5xdwumOu6cpZCqOA9z0qHirBRLFQHA03ZrC/4j9LflTs+Cky13GlBL8JZb BVh16ge7yRt8w86BJVithberbanxKs//q3do18PnDUjp+Wf68xuKHFDkUOxc4bFK5bEAOLfAOADO JwwM2NFMOwuAUzupkiyUMn9ce4ScSUGrRO2LHLhZaBJti20NAWfBnhgqUqF7Y96ye2lnbKgsrY7k kVf+cEniOZI0AW7QcYJcIOGxIp4HYLVUYBX0iiXxvarmE9BxstlxcsBaNBA24ZpTBimZocIFFS4N JA1Q4UJ+0MkUQzGVzoNEkU41cn78CUuDAjVfvHxTzzxNAP8J1qJiOb+IBOFHIg6FFuGQ34n3JOPw KUuSFwTiIGdAzlCZar+R6Mc2lLGk6QJ3G5UvB6ytn4WxbKq0R2whG4FsxDphBX4G/MzfrYS+LRtR 2/KXOQ1+QTZiw+HZ1OExTjxNzl+x9lGwYmqci2PXsRWaWnPg66zrS0lDNvQlobGhzH1JyEVUOReR Dbdj04jf+eWOL9d6In5B/IL4Bb2m6WRCx9EPNwYJpi2t9717Gar7CxraqFW0bERJm3+LChWomeTl jpWg297S09I67WzpaQEkAyQDJDs3cp9lMLwYsgCNVLPX1Pjq0QWfvR4i/45v4EkSyUkq8GR8xj04 6qwYCB+/AqECoVYWof6/AAAAAP//7FfbbqMwEP0VxOM+bDEQLlGJ1E3TVR+2ikh/wAUn8Qowsk2y 7dfvjE3SRLnQx92qvGDPxRwP45nj8mZyux2rlha8WTnbccUblrl+6Ln9JO8qENBOC9eYyrlED/kg Gq3AhqqC88ydik5yJp0ntkVPRpW+U5xm7jOvmUKxk4uaNqhc3zXq1KVQx6tYYA1tn8VPyXucb+C+ oRUg9Cwc9TZFFAeyGwCHGOHd7t6IuAUzqXiZZ67n/UjiNEgQjBHN5RnhPVvSrtKnmvmByKxsQ7Ll pdhOISxSVAa8pi8K9fDeQazYUuNXWwG7TUlkN3HJgCSBf93Cj8PkukUQReF1i3CU9MG8hGMUpgNI o5AMII0DfwBp4ocDSCFgA0iJ58UDUImXpgNYCUm9AbDEB7jX40qCGI7RLhPOZgAJo5GBC8m6yxY8 ags4j+x+Znzf5092Xv7ulM75aq0fm89/fOGEnj2lpgj9L7UI/q7zp65MnYVq2kqmmNwwd+LYB4uV NiXLFNdWCrGcSdy4fm3BYSVpvdBUaptOnyMik2+Ok7NWSA2t5yMRmDXlZ9r/hYyoRcmqsbNgzMkf pkFEyPej4GBf++pnV9rqVz8DfnRENL762T9ORyNvdAdEbtfoDphnrzGdX7FCz/e1H0nosd8C9AdS LBJrRksmc7ZkkjUF2zcUtmFAxeWYl5krH8ue7CyF0B+wTm0VvrT2kksFJHe/OOlJ0KXVT+yJXb9d LZDubzMX8zfC6KxhHCVA3E082tUviuHQogV5AAwUJhKJEUwTz1xhXoTWooZ52F9pgIC/a+0WMjeO U/S1CIGYA0GE6arTEA6IqP1cISq8auBdCVpy6I+suBQF3k9AY3s13qAUuuNgznUBoBEbQIbSbf+h Gb6I8tUMYIWuZo2e/AUAAP//AwBQSwMEFAAGAAgAAAAhAPFhb5pTAQAA/wIAABAAAAB3b3JkL2Zv b3RlcjIueG1snFLJTsMwEL0j8Q+R761dEAVFTSukihMHxPIBxnEaC28aOwn9e8bZWA5VxcUjz/N7 b8Yzm92n0VkrIShnC7JaMpJJK1yp7KEgb68PizuShchtybWzsiBHGchue3mx6fIqQoZsG/IWgTpG n1MaRC0ND0vnpUWwcmB4xCscqOHw0fiFcMbzqN6VVvFIrxhbk1HGFaQBm48SC6MEuOCqmCi5qyol 5BgmBpzjOzD3TjRG2tg7UpAaa3A21MqHSc38Vw1brCeR9lQTrdHTu86f41YC73AURg9ldw5KD07I EDC7H8BZccVOeY8fmCRmxjkl/PacKjFc2VkmLcaf+c/DW+Lw6OBNk9R3I/gXW1wjn3U5rl/5XBDG 2P3Nw/qWTKm9rHij4w+kZzxBH17iUUt82nJdEM4JTVllS0xVCkJ8VKmw6zVLCEWnxEuxP3F9t18A AAD//wMAUEsDBBQABgAIAAAAIQCU4v4zaQEAALMDAAARAAAAd29yZC9lbmRub3Rlcy54bWykk9tu wyAMhu8n7R0i7lPoph0UNelN1QfY4QEYIQ1awAhIsr79nGO3qqqi7YYEG3/+jc1m+6WrqJHOKzAp Wa8YiaQRkCtzSMn72z5+JpEP3OS8AiNTcpSebLPbm02bSJMbCNJHiDA+adBbhmATSr0opeZ+BVYa dBbgNA+4dQequfusbSxAWx7Uh6pUONI7xh7JiIGU1M4kIyLWSjjwUIQuJIGiUEKOnynCLck7RO5A 1Fqa0GekTlaoAYwvlfUTTf+VhiWWE6S5VkSjq+lca5dkyx1vsR+6GmS34HLrQEjv0bobnDNxza7l Hi+wQ8wRSyT8zjkp0VyZGdNNx1n/5+atsHl0yE071KkQvIvsNEtRm4SjRZCXljsewBE0qTwl8bo/ Z3GLs5q/pISxpz1j9w/did60kwWvq/DD05Fdt8w4mm1ob8PV9v/jFF8SIcAEZep+Rl7PBbH/6LlI vqIN1U6vLfsGAAD//wMAUEsDBBQABgAIAAAAIQDksgSqaQEAALkDAAASAAAAd29yZC9mb290bm90 ZXMueG1spJLJbsMgEIbvlfoOFncH0qqLrNi5RHmALg9AMY5RDYMA283bd7w2jaLIai/YzPLNP8xs tl+6ihrpvAKTkvWKkUgaAbkyh5S8v+3jZxL5wE3OKzAyJUfpyTa7vdm0SQEQDATpI2QYnzToLkOw CaVelFJzvwIrDToLcJoHvLoD1dx91jYWoC0P6kNVKhzpHWOPZMRASmpnkhERayUceChCl5JAUSgh x8+U4ZbUHTJ3IGotTegrUicr1ADGl8r6iab/SsMWywnSXGui0dUU19ol1XLHWxyIrgbZLbjcOhDS e7TuBudMXLNrtccH7BBzxhIJv2tOSjRXZsZ063E2/3l4KxweHWrTDvXTCL5FdrJMUZuEo0WSl5Y7 HsARNKk8JfG6D7R4xW3NX1LC2NOesfuHLqI37WTB6yqceDq0644ZR7MN7W142v5/2uOLMgSYoEzd r8nruST2H0UXydfUoeBJqs++AQAA//8DAFBLAwQUAAYACAAAACEA8WFvmlMBAAD/AgAAEAAAAHdv cmQvZm9vdGVyMS54bWycUslOwzAQvSPxD5HvrV0QBUVNK6SKEwfE8gHGcRoLbxo7Cf17xtlYDlXF xSPP83tvxjOb3afRWSshKGcLsloykkkrXKnsoSBvrw+LO5KFyG3JtbOyIEcZyG57ebHp8ipChmwb 8haBOkafUxpELQ0PS+elRbByYHjEKxyo4fDR+IVwxvOo3pVW8UivGFuTUcYVpAGbjxILowS44KqY KLmrKiXkGCYGnOM7MPdONEba2DtSkBprcDbUyodJzfxXDVusJ5H2VBOt0dO7zp/jVgLvcBRGD2V3 DkoPTsgQMLsfwFlxxU55jx+YJGbGOSX89pwqMVzZWSYtxp/5z8Nb4vDo4E2T1Hcj+BdbXCOfdTmu X/lcEMbY/c3D+pZMqb2seKPjD6RnPEEfXuJRS3zacl0QzglNWWVLTFUKQnxUqbDrNUsIRafES7E/ cX23XwAAAP//AwBQSwMEFAAGAAgAAAAhAIMAorFTAQAA/wIAABAAAAB3b3JkL2hlYWRlcjIueG1s nFLJbsMgEL1X6j9Y3BNIq6aVFSeqFOXUQ9XlAwjgGJVNgO3m7zt463KIrF4YMY/33gwzm92nVlkj fJDWFGi1JCgThlkuzalA72+HxQPKQqSGU2WNKNBZBLTbXl9t2rziPgO2CXkDQBWjyzEOrBKahqV1 wgBYWq9phKs/YU39R+0WzGpHozxKJeMZ3xCyRoOMLVDtTT5ILLRk3gZbxkTJbVlKJoYwMvwc3565 t6zWwsTOEXuhoAZrQiVdGNX0f9WgxWoUaS410Wg1vmvdHDfuaQuj0Kovu7WeO2+ZCAGy+x6cFFfk kvfwgUliYswp4bfnWImm0kwyaTH+zH8a3hKGh3tvnKS+G4G/2MIauazNYf34S4EIIY93h/U9GlN7 UdJaxR9Ix3j2XXiNZyXgaUNVgegR4ZSVhkOqlD7EJ5kKu12ThGBwSrwUuxPWd/sFAAD//wMAUEsD BBQABgAIAAAAIQCDAKKxUwEAAP8CAAAQAAAAd29yZC9oZWFkZXIxLnhtbJxSyW7DIBC9V+o/WNwT SKumlRUnqhTl1EPV5QMI4BiVTYDt5u87eOtyiKxeGDGP994MM5vdp1ZZI3yQ1hRotSQoE4ZZLs2p QO9vh8UDykKkhlNljSjQWQS0215fbdq84j4Dtgl5A0AVo8sxDqwSmoaldcIAWFqvaYSrP2FN/Uft FsxqR6M8SiXjGd8QskaDjC1Q7U0+SCy0ZN4GW8ZEyW1ZSiaGMDL8HN+eubes1sLEzhF7oaAGa0Il XRjV9H/VoMVqFGkuNdFoNb5r3Rw37mkLo9CqL7u1njtvmQgBsvsenBRX5JL38IFJYmLMKeG351iJ ptJMMmkx/sx/Gt4Shod7b5ykvhuBv9jCGrmszWH9+EuBCCGPd4f1PRpTe1HSWsUfSMd49l14jWcl 4GlDVYHoEeGUlYZDqpQ+xCeZCrtdk4RgcEq8FLsT1nf7BQAA//8DAFBLAwQUAAYACAAAACEAxxxt FJwGAABRGwAAFQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZTW8bRRi+I/EfRntvYyd2Gkd1qtix G2jTRrFb1ON4Pd6denZnNTNO6htqj0hIiIJ6oBLiwgEBlVoJJMqvSSkqRepf4J2Z3fVOvCZJG0EF 9SHxzj7v98e8M7546U7E0D4RkvK46VXPVzxEYp8PaRw0vRv97rk1D0mF4yFmPCZNb0qkd2nj/fcu 4nUVkoggoI/lOm56oVLJ+tKS9GEZy/M8ITG8G3ERYQWPIlgaCnwAfCO2tFyprC5FmMYeinEEbK+P RtQn6NnPv7z45oG3kXHvMBARK6kXfCZ6mjdxSAx2OK5qhJzKNhNoH7OmB4KG/KBP7igPMSwVvGh6 FfPxljYuLuH1lIipBbQFuq75pHQpwXC8bGSKYJALrXZrjQtbOX8DYGoe1+l02p1qzs8AsO+DpVaX Is9ad63ayngWQPbrPO92pV6pufgC/5U5nRutVqveSHWxTA3Ifq3N4dcqq7XNZQdvQBZfn8PXWpvt 9qqDNyCLX53Ddy80Vmsu3oBCRuPxHFoHtNtNueeQEWfbpfA1gK9VUvgMBdmQZ5cWMeKxWpRrEb7N RRcAGsiwojFS04SMsA9p3MbRQFCsBeB1ggtv7JIv55a0LCR9QRPV9D5MMJTEjN+rp9+/evoYHd59 cnj3p8N79w7v/mgZOVTbOA6KVC+//ezPhx+jPx5//fL+F+V4WcT/9sMnz379vBwI5TNT5/mXj35/ 8uj5g09ffHe/BL4p8KAI79OISHSNHKA9HoFhxiuu5mQgTkfRDzEtUmzGgcQx1lJK+HdU6KCvTTFL o+Po0SKuB28KaB9lwMuT247CvVBMFC2RfCWMHOAO56zFRakXrmhZBTf3J3FQLlxMirg9jPfLZLdx 7MS3M0mgb2Zp6RjeDomj5i7DscIBiYlC+h0fE1Ji3S1KHb/uUF9wyUcK3aKohWmpS/p04GTTjGib RhCXaZnNEG/HNzs3UYuzMqu3yL6LhKrArET5PmGOGy/jicJRGcs+jljR4VexCsuU7E2FX8R1pIJI B4Rx1BkSKctorguwtxD0Kxg6VmnYd9g0cpFC0XEZz6uY8yJyi4/bIY6SMmyPxmER+4EcQ4pitMtV GXyHuxWinyEOOF4Y7puUOOE+vhvcoIGj0ixB9JuJ0LGEVu104IjGf9eOGYV+bHPg7NoxNMDnXz0s yay3tRFvwp5UVgnbR9rvItzRptvmYkjf/p67hSfxLoE0n9943rXcdy3X+8+33EX1fNJGO+ut0Hb1 3GCHYjMiRwsn5BFlrKemjFyVZkiWsE8Mu7Co6czxkOQnpiSEr2lfd3CBwIYGCa4+oirshTiBAbvq aSaBTFkHEiVcwsHOLJfy1ngY0pU9Ftb1gcH2A4nVDh/a5RW9nJ0LcjZmtwnM4TMTtKIZnFTYyoWU KZj9OsKqWqkTS6sa1Uyrc6TlJkMM502DxdybMIAgGFvAy6twQNei4WCCGRlqv9u9NwuLicJZhkiG eEjSGGm752NUNUHKcsXcBEDulMRIH/KO8VpBWkOzfQNpJwlSUVxtgbgsem8SpSyDZ1HSdXukHFlc LE4Wo4Om16gv1z3k46TpjeBMC1+jBKIu9cyHWQA3Q74SNu2PLWZT5bNoNjLD3CKowjWF9fucwU4f SIRUW1iGNjXMqzQFWKwlWf2X6+DWszLAZvpraLGyBsnwr2kBfnRDS0Yj4qtisAsr2nf2MW2lfKKI 6IXDAzRgE7GHIfw6VcGeIZVwNWE6gn6AezTtbfPKbc5p0RVvrwzOrmOWhDhtt7pEs0q2cFPHuQ7m qaAe2FaquzHu9KaYkj8jU4pp/D8zRe8ncFOwMtQR8OEeV2Ck67XpcaFCDl0oCanfFTA4mN4B2QJ3 sfAakgpuk81/Qfb1f1tzlocpazjwqT0aIEFhP1KhIGQX2pLJvmOYVdO9y7JkKSOTUQV1ZWLVHpB9 wvq6B67qvd1DIaS66SZpGzC4o/nnPqcVNAj0kFOsN6eH5HuvrYF/evKxxQxGuX3YDDSZ/3MVS3ZV S2/Is723aIh+MRuzallVgLDCVtBIy/41VTjlVms71pzFy/VMOYjivMWwmA9ECdz3IP0H9j8qfEZM GusNtc/3oLci+KFBM4O0gaw+ZwcPpBukXRzA4GQXbTJpVta16eikvZZt1mc86eZyjzhba3aSeJ/S 2flw5opzavEsnZ162PG1XVvoaojs0RKFpVF2kDGBMb9pFX914oPbEOgtuN+fMCVNMsFvSgLD6Nkz dQDFbyUa0o2/AAAA//8DAFBLAwQUAAYACAAAACEAfukRMbIiAACyowAAEQAAAHdvcmQvc2V0dGlu Z3MueG1snJ3bktzIkabv12zfgVbX2yIQAAJAmagxHEdaa2llQ2nmOlmVJGuVVVmWmWw29fT7oQ6i uufzsbHVjZrphUAgwsOPv3v89l9+vj+8+Wl/Ot8dH95dlb8prt7sH26Ot3cPn95d/fUv6w/d1Zvz ZfdwuzscH/bvrr7tz1f/8rv/+T9++/X6vL9c+LPzG4Z4OF8f3119OT1cn28+7+935x/u725Ox/Px 4+WHm+P99fHjx7ub/cv/Xb08cXp39flyebx++/blod8cH/cPjPbxeLrfXc6/OZ4+vX1+cj7efLnf P1zepqLIb0/7w+7ChM+f7x7Pr6Pd//+Oxqs+vw7y03/1ET/dH17/7mtZ/Fd/+fK5X4+n23888d+Z 3vbA4+l4sz+fWdn7w/Pn3u/uHl6HOR/+O+M8r+ePdx9Ou9O3fxrkd2zb34/H+zdfrx/3pxsWlD2v iqu3G+EDL4cR5uOfjpf3X06n45eH29/vd/wWktfj8fJCZtrHj+8vu8uewc+P+8PhiYVuDvsdk/96 /em0u7/fseXPvzwNeb58O+z/vHvYr08bvt4dGI2//WnHV1ZrUT5P7Hb/cfflcPnL7sP7y/HxlV6n l3nfnnZfede/nu5u/31/utzd7A7vH3c3/PT6p2WTX0a6Oz8edt9+fzzd/f34cNkd5u/PLpyCb69P vA79/Pevw0Z/nZ5Hv/m8O+1u+ISX10+84nQ8vI7JOXg8sbN//vJwc/nyxMDPz32+Pb3/vHvcz8/f ef7db4/X5+2Hlw8/v/npev8zW7W/vbtwHB/vbu93P7+7ymX99F1vv17/5yG+Xn9kcx7Ynz+ftt19 /Rezubt9d/XDy9r+6uen72a815+fn90/3H4f6OUfvxrnl7++DvOLB7fv3122uZzZnm3P//rjM2ft DruHm/17duywH79d9vPxy4fn//qPu9vL56c/ut3Y8sf97qf9uLv52/mwO38eNpH0RPxy+Mtpd/e0 7c8/PP318vMjguv957uPl3/bXxBOT3+7u/2/X86XH+8e9r/f3336fPnDA4x1eBnnvF+XH3ffjl8u /C3r8H3OSMhbdubr9fYf/8bSvm5rURRDs+b2eS836j9RiqrqF6c0xfjCN79+Jo/9C//9mtJ2a6Wj lSlnH61M/eqjldWUA0o9FYO/p1nGzil5LAJKWxbB3Nq69+9JxVL5aKkcx1FnkJq28rVOzZxeJMCv VjTlqvY1SG3fvJyRXz/TzqnWGVRF2c4BJQ8+gyoVYzBaXZSTj5ab0venasvBZ1AXReO7UJdr4e+p 67bx1WmKYWl0bk05r34WmqpLvttNLnqfW9POvX9P5vj4GuS6X31Fcz2WzlW5GVff7baYUkApm8pn 0JZL59/T1sWruv0VV7Vtva66ol1R594pZRPMjZWefa27VA++P13KRTCDuq79zHX1MPuZ63Iegxnk Ofv+9MVQ+273ZVEGz1RV6e/pczv49/QICt+5vl0Wn8FQNIPPYEhrcBqHivF054amHv38xLpkyEOg MYY2BbJ3LP5hJv2K38aiWXxuY+oCThzT3Dpfj3U5+SkZ81j7LoxtVzsnTkWb/D1TWgIenaoumNtU F42v9ZSXynd7aqtAA05tzs5vUzsvvgYTXOVrMJd59rM9l0sg/eemC/gNSuejLUWqfQ2WAk5QHl3S EtghS92skz9Tt9F76iUFc2vq3qXL0ha9c8jSRqOt9Rys6Jrn5KOt7dRn+56yiGQvlN6lGJRpUD5A hvWT8hsGUusyHkpX6v6URTW6XVUWzeg8Wha5aXQXSv7XLLoGZZkLX51UlG6PlqksX92zX8odKK3r eihjp9q5TKlcfdap6muVymVqqsm/JzXN7LuQmjzqOcW8rnrl+CfDO1idNrttWaZ2citgo7Sqmcqq rDs9JVBy62tQla3rn7JK5aSWXVk1aVDZCyUnX7eqGVxallWe3YIsN0vVZ1BjrvvO1ambnUPqqq6c Q+oGxa18XTflGrynZSP0maaoOl/rBjvRV6cp+8Z5p0nV6LzTVEvlnNg0yeU1QY7SLe+yaZvWR8vw gX9PTjmQYljRi8+6LYbKebSF41Rrlm2Z3eaD0mdft7ac3AMr21R3LnvbNrc+N2zlzlenS7NbQmWX ltU5sWumOqC0gXdYdu3c+er0GHbOVX3qRufRPg3uO5c9AiEYrcqrr05fLW55w9XF4rzT5959zbJv o50byiLQJUPqG1+doWpG3+2hyr3vwlD3i8udoc2Ly5CxGNpG5cGI5POzwHcGUnmqmuCcTlV266mc mnF2qTzl3m3lcsZ4cb6eWWuXiXPqF1/ruWoCnTVX0+yrMzdDIEPm3My+bkta3XMtoSy+BmuZ3SIu 1xLRpzu3ptYjGAjRelG5g7nT+JmDMrfKVamoZtcyqagLl4kI+M75LRVtO/vcyqJzyw5TrA2+p0xT 8B4MB7duMd8C7wPK4tZtSkXvFj6GXdeoRNpMPpdIKaWh0D1NqSo81plS7v3MpdQm99oSwtK5F8rs 2jkR7nVdD2VyqzNV9RjMDbsq4Koqp2huLQfVOD5VuBjOO3WRa5UHqS4Xj6GkOlWDagwoedVzmogi DSqVkZXdGMytnWfVMglDNRitqXA/dA0w/RefdS7brLokQXG5A2VymxzK7FKZOP3ofslGcS8ntTiO zvFtMbrsTdhV7r1DaWf/0raug/ODV+95jNS2bIOudVfkUmU8Hu3i0daELeZ5jNRVk8fwU8e0nav6 svHYYOqrLphbX62jf09flx45xT5pavUk0sAzzr1DvWTVmmnAnXPKWAR6O43F6jZ5GktCtLo/YzkE uz2WRO38mVRPzoljNbptmcZmchspTUVR+Tmdiqb090xlWzv3Tinw+NNElMA5ZCK0HlIC6TI1LLeu ztSs7mumKePQ+TNtpGXm1Lh9neY0BFJsznPAo0QAA0m+FPXia7C0mDU6a+Jvrcvrtejcd05rk2bn qrWpAttlzWURPIMy05NVYfY+58Wfc7Xfs7Fbeq7VXagKbBT9HiiBhV+RT3vFFfwyxgUlyGNURQ68 6qpoF5fKpDcwL20XqrKZJ/VYCAmNrs0I/NRuPVWbXeWj4SB7ZK5CmdS+bhUJAeWqqkrZuQrK6LGn qqqza00oQxO8J69uOVTEhNwirggJ9eozYVRNveqFqiFNqvIACqlv3blcTJ6BQv2VwZ5mfFrfH4RL 57uQc+2RkopoyOzf06bRY4NVW1XuA0JpRp9bSzxeTzDmaDeq9K+IWnpskAxy7/4CYbmhcnnQNY1n Uqou963Puiccrlqz6stc+Vr3OKHBaEjlgNIGOXEyh71HI6qBLJzaBxXRt1Utrmqoq+As4GEE+0PM wyMy1YjLUilfj4SP/TSOzNvnBsX9H94zepyiIt9Y+P6Mde25UJ5ZPGtVYaG0qucIzzZuqVbYLm6/ Vci9xUebqnnydZtyCtZgIoLuXzqBBnJOnMvGs6SAAtbW92fOXek8OnNKXP+QDR78e+BQt5GIJgaW HZQlkPFL1QZ8sDTAr5QTl6YOuHfBrPJZL7kNJPnSDm73VmszB7JqzSm55Ftxt3XnAOnkTs82WCCS U/alRJHyEDxTzVm/FBRKkPkmV4456O9pAs+I8EHrKwpldT1XbwktlQdQFrfw67IZHJ1Rl23lkhz4 Q1359yQOsO9CSp17oQQ9yjEYrcqN6h+ead0HRDUvHtUlhJJd09apHaMvJUyhcqfG7HSkRV2VhXs5 NZ/jZ6FG2dcqKaAsHrMDP9S4xoAyuGbCiC/d6oTSe4wYS6z2TFfdpN7xB3VTjR5TrRvsRF9REGuO vKqbNk1qV9UZRnB+y2nJfhYybO2nfosWRZQ14LccWcQ1gs+RMJi2vVuDNYFT1z91i2XlcqcFDqu6 hI3DLFe50zZzcLKYdOX705Wd23x1BzDAZ9DBvs7XHXan71wHj/hudwgXlwddXrLq4LrHpYwoa3Dm eiK0qgHrPmVHeEGZKt+fHi991V3o2yakDB4brPEn3RarB9Aevm4DOAffhSFFknxITaB/Bs6py+uB 9I+fubGeat+5MReB/hmRSP49RLIc71JPZeXWej3h2fsuTHWQWSUsR7JLd25qk+fa6hl8hq8BCOdR rc6aqFTv7yEP6HGkegYd6LIKxFogXZay85g3OLJh8tO4kFj1dVvIkrqkWAsSZ7puUDweT5B8DHTj WuWAQ1a8GV/rtVoCa2Oth9V3YW2WYH/Asnl8B0u591gNoJbR8+jYgsQWbHWaIpNADSiDa8Bmg5jp 9zSbOFDJByW7rbxR3BZrShJNym9QZseCNmWDuNLvweH3eFVT5sHtEFycymNpUBY/JVDWrDIExM/i tjIAosp1MLHJQO40hACznh8ogV8CpR98t6umSHp+Go6CIwqb0ILcKI7Aa/Dqg12oSYr4btcgCn1F MdM8V93UZAh9depmcc1EfGktVGMA1iJboFxFbNDlKLmk0WtsAHgFWKkNmececpM5Cyp3GopIgtUB nOGoPZ4JkMxNJlKvEhaDOLmEhdJ4XoZKniCKAwUnQ1e0bQggOAWnOpgbyF/nkA5x6fKg24AO+h5s PvfnwHMMczAaFS6qTzm+gNn0PeQoPTvW9HXjOPymB/nrsheK6+AN2+TxKiiTYwmaIYoWQSHOpt9D lYLbYg0xu0AvjHyR7xyYLLdHAe+UjgGEAkpT57ZVHPi6TdUYrA51BR75aWYMSJdV2GKO2mugOKax mbdMhs56Jo7jEmmuq8m5aq7JVvtoVEf5WhNf8mhRsxSD25ZE30q3e5sFSeprjYUU7MLSkqTUWa+k k1xnrXWAoiJ/G2TYqfCsghO8kppyGb+22bUzXgnH3madCyLbOlresoq6cxslGo1Ek545IP2do163 jOusEjZjpXUqR6Esjt/JRPNW5cRMNM/jlgBukkc9SI51ta8OcCT32nIiA6WnJAMhqvU0QmmCWaec XJ8SsAtybbmqssfJobSu66HMjoLPwEej0XIQZct1GSCMyQ/2Ae/U1RqsQY3v6pwIpt49V4CtHAbl eKBFjkzgmaF2fqtz56jxXOd1VXs0N0WA6scQKtwmJ6Qb1FZkDJ6s0gVDqHXcBiXaZAt0DWAeRx1l ElAeLeL9RbA6POS1cJloXvazwJFzNFBuiXn7bgOUdc81EyxyHwPK7F4oFLAjujpA9z2SRdiydF8z d8XgEVo4J8BBZmpWPUYMlC47Dj/3SCSXbz14e9WaeaAWO6J0HoflGXDJujrDhmF1CgIpeKbmOPgz sLzvwkAxdjAaCajKR2sB+AaUxWOdWx+ByZ8Zy6IPKCkFmnYEjxo8U6GCdG5jkzy2niciP4s+M1EK F1BS77HbPKXebaRMzaojjPOEjxy8p+0cy5apKXNLKM/kvl0qz3Vd+Z7O9eIdC8hU14HlMKOY3N6Z UYDOVeSDA72wAEPxudE1ovbvWarBrXWi8bPnnTMYt8btg6Vdg9VZwbr7+VlrEP/KO2tDlU1AmQJL iDi92/EZzJxHSlrEjstRKL3jhIAeF45bh0Jk2WYNZfHvaYsKIevPYO84hWIVj36BPRucD9oST1j5 AFh06cj5NpWV2xRQOseTQ+kdtUdoA4iIfmlqJo9GtNiWHmWDMrt93aa281j0prY9K0LWDMde54bV WfmsCTQ6YhroV+26EcrgHN+SXS711G8NMtxab6n+9Axh2yTCrfo91FE68qoloOieOJTWq8HbJgNy 9vdgB6jv3NLaJOCqXMwBX1NX4FYaJQqzx3faDOBSZQiFPEtwFjBvg53LzeD6lO4HGFC6BmSXs68O AH2PmLVtE9QqUn8UoGeoP6Krks6ASnmPodBpIgdSDH3haLoW3GCwC1ACHqUGy+Mh2ykNZC85V4/D tj2Vto1+aY8X6hxPnnZyOToUtXt67VCAc9P3DBSe+J4OZdB/Bzg7+sxHq8gWOKUe3LJrR/D+aiu3 WzeSWUcDNxjIKqKGHuNqx7x45qGdSto26Hsm4vGuZcive9ySyv+gVrGd6tnxsFghAf6tnXLtVgB9 BGZHjdO9iiIb/Z45zZ7HaMkHLL5zM7aycwjWYKAByfo6bqNdaJ7hZ5sobHC2yRRHo9H0xC0Uept4 nwVcd3hEV2dBzag1CJJg8mpwqiQiHQzFfSaeWR1L0JKRrvycrthIanW2K4lN3+2V9gfBMymyINd6 CiQ5lS8eE2qxVB3z0yJ5Aym2UlamJ4u0DOLF9qcrSgqaAsrs0eOO+iPP4ELB1fLR8uy4tK5oZ+eq jhC+S2VU1uTxXiir+86UrpGo1bmBdvSYKjDzoKMRDcHGQTmEhmABEgZKYId0lOB6Hr2rygBD21Vg PlWGQKnck4AS1F52FcBF5WvERJBr6+oyBXsKxesbCUQHnhGUxe1eQkUoW905gHbu/3QbPEMlUke2 xO2DbsMnqqyC0nvNakc40TGaUDDGdNZQsr+HXnIeW+9oU+LaeaM4fofEauvamZBdgBzZGtAFpzFT Ce0cj+vqngTmW+PZ/45GNo7I7cBUOoapQ1R4vVlHdX3AvR0og0V3Acb2PpodHpPbFFCmiIJfrXZV 17Wrx+y6vii8rgDK6F4BlNk9ia4n/eLyoCdiFVDa2XGd3VCBytJ1G0DaOV+Tq/YKy469djxSNwKD 93OKpepdLDsqaQI9N6Ix/Eupl/HsP6MFXWm6sSFUrmtA5tvzGADzCHLpM+S3veqCKeMI+zO0/XLK XFIkrc/M9K4Inkmj4/k6sIbBCcZSDWa9ddRzjTGTk3YOWdLsFn63AKpUD7lb6oh3qKcNJBJIj+D8 rOAgfd1W8JYqKTimkyNUeqJ5bq1DAXFp+9MXpGlVUkAJetNBWT0q1ZPNch7tt9pY1Zo9rONxcsr0 Fs83bhSX5H2J+Fd+29oweScomJp6Vl0dGnu4z9QnJJLaln2Fm6W+Jq2bijF4Jk3uhfZE5hyT1W/l n6q3e4ov3SLuazpF6imBsnTObxSYdL5z9Gtze4e2UmXAIfRYcznaN2BKfN2o4fBcG00bKAnRnSNV 7X3M+gbwmX8PsAnHOFMWurhHSRBncT23ta51WdW3hG6d30i1zat+T4tx619Kra/XO29hJK9D7jf8 m7+HCsKAd7q6CKQL8Tev1OgxfIP9wYgN5A7dhILT2OFNqXbuqVXxrgB9Rw2ucxXCyissezLFHluH EvhZPWLMM4Q9osJRIH1fBbUVfQ+6yaUyiDm3Nnoo3iWkp7Ojxzb6rYbD3zPQF8Bl1QDGTG2KfiAa oBZKPxZjwAfkg2eXSGPTBBIJ5L5bdv2URu/U1dNb2LGGUIJ4Is0pgAPpaZwAwTsnTkBH1HLo56L3 3Hs/kxVxeUA0L+D4uSLtq3MDzxdwyEy22k/9AvDX7QM6BwbajDyt+7T9moK+HhvF40j9Wg1ewdfT WcT7I9EOLIgsQJmSynhE8uBxciiz14oMdIZzH2Oj+Mkiqbl6VpEm5EFWnpZopAtsTzdKMDe6ZLkn PpQ091L7YKM4uonCrRzMmjytY35wZIJO31BGt7gGbDE/jVBWz7EABWqddwDP9O6jD0TMglmDqvFo 0QCs033nocLydq7CBXQ5SkML6iV1T4lxOQaDhGu9qtwZarr96TkFOFm4lhmowXXraUA5u7c70G3D bb6NsvgMKFdxfToACfaYA5TRdf1G8UjWQPTLa2MBNw3ugVFCOHicAmFAF1bdHyD1bvPRbmP0Gigo i3viW3t/z8sMLW11nauowfXMEM8sSXXwwBUUbgUM4OwcqQSl89g6lMljgwOhekfoQwniBwOdX4Kd 6xoOse4CcsJjkAOUQFZhvzkqbMAF89wUlNn9RlgqyJtBCXpiDgMV6aqdoUyOLRrwtgPJR2c4t8kH eqgEfDBSfuN8PZJ19blN5RycH+yqQIZM1CG7zqJqym3yYQKPGsygnQOdBabF8Tu0HsDAVt6ZqTTy UwKl0SjBQBzJ4/HDTBZZPYlhIRLsa41d5VUXw0JLftcLSwpukRnoDeE5o4HuKt6XAErvMRQu/8FI 0nUDERxI/wWnzb90Dflg5Y4qf88KblD9BZokBrn3saABg0pLQrcBMmEs2jyp3Qtl8lgAlNX5Godl 8hzyyFl0fQqlcWsdkAP2re3CSB7QT/AIls1R/SMt8NxvhBJEpaDQ1c9nwClRXY/SxuLxZ8ADLQFl co0xEhdr1f+Bkh3FCwVYlr5nC1f5rKmAdYuLEP7sspeCb2KA+p665IoopxCrGZVCIMtjQgAJqO/w ZygWUVnFM0GXnRHYhvtmUBaPPZFeoKe4z4A4rK9o03aOjx8RLsFuZw63r85WDOHnlKrZMqJww4zO OnP7pJ8sWjd5peC44eycr8lels7XOQcoHZJmk0tlAhg0h9NZExsMzjaAWMeUjHRTdSsNCifV31Nn x6nyzOBacwS66PbbuN075mehq3v360duWfDsGEqB3r466y31oJYD1y0GvY6ggLj00SiPcrlDANut 9ZFQsGfUoCyewR0J+LrfOMKHgXQhyhecOeo0Ao4fmujUD1T3+ZfiAAUcMnDqfa0HKnZ8tBEAhPM1 SsuzyyPVHQGHIJYDSUFmNZA7W87VpeVIgbLLkJEJqC02gigMLAc6eDWuFyZsPpcUYA09czeSc3Vb eQT15Ah9KETTlK9nrlTyGXA3hGcRaEHeOUZmJE+8+J5i3TrqaOTmG8dbjmDzvLsxMFlqafR7yAJ6 DGVcQJ/5M+DsAh6luiOQO2QxgjOHDRucbSqGHPU6rvQVdM200qHC9wfsjPsyW5tt52sorXc5mIoS 2I+t6NbQyOUObb6DDukTV3h55g7K5BYKlNnzp1NZ01tR54aa8yzCBJp8VU6kbTiroKOBsvPK7qmi y7VKMQAluVQLBVd3dcTAhFvikgL4HRg8nRvlWd4biJbmgZaBQjtGH41rCH3WNAnx+AEuOklxHY1b ST2GwjNc/xY8A7TTKWSTgrm1g9cvUD5BrwcdDVSYy95pq431teY6MI8sUAA1uS7ZKJ4PnrCrHE+B IB88Hk97WlqD6veAmfAYJEFYirv1mY4UmH9pR5N4tdanjlp5tYSmnpvPfE97Ipr+HjrQuSTnIkaK inXWA6W+vqcDc1N9OhEK9hj+RFjXtRkTm4PTCMW9tomgg/uNUIIMO/C7xiP1E7ZL9J6Gen1dHZym QMJyF6SjgSaMcrddJqJ5HuebEKSu5ybEmFtcUBbPL0ybgFNrfZrodhRR6HKja8D9C9GsqZPw84P/ 5bl30jV1IK+3+7Ocr+e8uJczzbhGLsXQWIEMoYeKYw0nqiGCc7pQk+LabKlGj/cSxkoBH6xRFxee WT0rMq2J2kfdn5ULIAIKHYWcr1fSL66zVtIvziEgCTzyMxMmd79kBiXkpwTKWqp0oTEPoSz7UiCN pGOdQuMI1Zo07Q76j84o2kY5HoAkF6Xoe2gK4LtAa0e8TX+GfsQ+t4RwUY4ntA46QkersLgCCvfc BRTClnpKaHVUe/yNi+kWvxdhZntcugAiDiK0c00lmJ4fSqCo5dQvpX+Id+/YiqM8W0FxVFB3SIPC IPMwk710W3nmkASzpgGPx/1njHWvgJ1B+zsOBXjI7LGambpQ9wG5GI9iOF03MPCeM5q5+9Oly8za +KmHgl3j7yGOpHJn3mwk31PuqPI7NeYurQFfdw23UOgMOhqYuKTYoLJ+5sCYef3P3FNf4u8hruC3 U5Cca90SgtI7gojihSLgg566MrUtaYaf3KOEEtyhPHOPp/fFmYEmBPKA+7M8/zNj8wWSD1vMq3NR S6tHPWaeqHx/QAkFX4pLGZz6zdVzfkM1uWU3o0wcyzZv6PRZ+Y0jHL2HXi2+c3Ne3Q+eZ2qh1XrC QS+C07iUYzA30AeTa7OFtvd+grnnwfH+FEAlx1dBCbC6M5lIj+LMdJNzm2+m9sZjnfNa9u5Vz8TY HP8GJcBbzisJLV8DqlgcLTyvOJuqNbfwm9fPQVlLlYlcFFZ6rmAh9+JYDyj0cTFO5HKxoKvgE0Wt gI3iHQ8XwLVuPZFGpzRVZ8DNqJ6RJo0e3OYAZfazvQCZ87gLlKBX5VJy74taTwAkA0Qh16QE9bQL aVrvRk/yn2tKdA0S7Z58dbhx3uOwAAaC2peFy8rcFlvIknrEbCHn6xYk8ANai+isEZaOouICl8Xj Vctmv/loTUFaXN8DxMzjBwuINY8nsjSjx1CWhnuYnK9Rzq7NaHwZ5CSgzI7jon09AXH9nkwZi+qs BWyTS7GN4pmhBVvd81kbxfOaUILbIKEE3ZZIxQboDK4hHIPzs4F4VZ8uLa2KXSKBZRuzrhvwg+Sn BG/OqyWXruDU6Wgdd7yppqXUa/DoF1c5AFLR0aC4r7mQBwzkG7i4YOewkTwGuQw5ZedeEPruHS7U BXlmdSHi4JESKLXrbSgBTnWhf7BbtwuRLM87L3ingS4Bu++YrGWiCbivwURw0vcHtzoYjbyZx4SW mduinXvpsRZIpJk+8S7fiD25t7sQE/J8ybKkoP/BQr+0gEOgZJc7C/6PnyxuZvC4y7JsfbeU4+m+ 5nlNzDpax+oza7kGEpYuFO61LfRVDHZupWu3ywMorrNWRK9HIzbKoF8KpfeIMxTguvalUEDNOWVr zuAUunspX6/c+eUSacV6cg8ZyuDYCFzDAB+CyTk6J1LmygVJOmtuPxgap1CMoGeBEGTtVhqUyeOJ a6JrkK8Olx67niPcPHq2AkoQS1uJpTm/rdwZ4Zi5zSmoVFJAAc6mq4NqDNaATKRXAuBiTKWerJXr Ois927Q1JPSiMwBg7Kd+5RozzyKs26Vb/qW0tnfNRHvAIuBe2pw6OhDYInU+OusGeJVaDqTecdL9 GdyS4BlaP6u0XAFIunSBEq1OplrFZ0D/N78pmcsGQcjrrKlTD7gKXJrn3mnxFlSVrdtFov6lZChn p4C2dCtg5RZp92mhLB4/ICFRe6XTSpMOz0ivPU2D1H5byTK5906DG7wMXVEKgIK1hguCGVAR6b7m OuTKu8WsdEULuAqK5wFXQJqejV0Be3imGEo9ukyc0AvOiVMaHBewAo4IdAn90oK13u5MVa9tpcLS Y1wr6f9AVk25d8zPym2qXuHCJdJdMNpM+yrXTMTSvM/cOoPWcjlKHtCtQdpnRRoDK9EzKSsIIq+0 XbF3nm3lt88XpJ9/99v76/vd5fOfT6//tR4fLm/ur3/aHd5dTbv7D6e73Zs/8hcbz99ffzj9bbx7 eKV/2H88nvb/THn/5cMr8Ycfngnn+93hsJ52N6+E48ePz5Tbu/PjvP/4NPDhj7vTp+8jP237/fVJ f73df/zf/xjtZv9w2Z/+9XT88vg86tfT7vEPD7f8/PpCSqxfxrt7uPx4d//6+/nLh/evTz3sTt/+ ifTl4fb//HTaBnz7fYG+Xl8+7+/32wr9uHv49Hq7/P7hh7++v+Jf+935Mpzvdu+u/v75h+lP29Nf r28Op/c322N/3D0+3j099eFT+e7qcPfp86XcHrvwr9vd6W9P//jwKb3Q0hONf220p3/sbraP5a9f /mP7g+f/5K9e/uP7b9Xrb9X33+rX3+rvvzWvvzXff8uvv+Xtt8/fHvenw93D395d/eM/t98/Hg+H 49f97e+/0//TT8+LcHv80/Hyh4ebw5fbPSxye7w5/+Hh/WV3OT+t0fnz7nEPJ+y+HC6w5PH66Qe2 +emHNz9d73++vLva395drt6cH+9u73c/v7vKL5fIvvz1Yfft+OXyi7/dRtr++PEXv7653V3YoicB drw+7T9trHPZfTjsf/Fn28Os9unbm4f913dXbM7xcPvu6omR3v7yOZjkF5Pg31+fP+H7N329vt3f 3HEU3n+7/3A8sHpPJ+w3z+tzuDtf3u8fd6fd5Xh6pf2vJ/ZjpP3lAuOcf/f/BAAAAP//AwBQSwME FAAGAAgAAAAhAPivhODkDAAAwUwAAA8AAAB3b3JkL3N0eWxlcy54bWzsXF9v3MYRfy/Q73C4d0e6 P7qTjMiBJNuxAVlRLLl9LHi8PR0jHnkleZbtpz4E+YOmCNoCRov0wU7SwgVav6RAUkdtv4wl20/5 Cp2dXS73ONwleTonBZo8RCaP8+PuzPxmZnfn7s237k38xl0WxV4YbDZbb6w2Gyxww6EXHG027xxe v7TebMSJEwwdPwzYZvM+i5tvXfnpT948uRwn930WNwAgiC9Hm81xkkwvr6zE7phNnPiNcMoC+GwU RhMngcvoaCUcjTyXXQ3d2YQFyUp7dbW3EjHfSeDl8dibxk2JdlIF7SSMhtModFkcw2gnvsCbOF7Q vALDG4buVTZyZn4S88toP5KX8gr/XA+DJG6cXHZi1/M2m4feBGa0x04at8OJEzThE+bEyVbsOZvN s6e/fv6v3/N7460gLn7ajSnICn+T7wRHIHnX8TebLLh052Ae+8H40s4evzXwhoDsRJcOtpoguIID T/9qE5iq6YincrMFnYKGD4SFQBdstBu6x2x4kMAHm02wMt68c3M/8sLIS+5n9w7YxLvhDYcM/EE9 F4y9Ifv5mAV3YjbM7r97Ha0rb7jhLEg2m+1eHw3gx8Nr91w25daF1wXOBN68xwV8/vpfprItPlHQ UNHjY+ZwV2y0aku0a0t0akt0uUSs6QuHOcspq/7Y114Tbu814fZfEy7Entei340l47oOOvmSUQ+9 xGccsxJTDmaDpJ5AEoXBUWX8a5Pp2Ik9CNEVB3Tj8NZuYz9iIgEkbMglZ14WcDY2LMTf9x2XjUN/ yKLGIbuXcGHKtKpoe2HjYOq4EEnyg6hOzl3vaJw0DsYYkPIwvVXLXITkrhfjLHQV9GyxT4i9HXlE c7225W232NCbTdKBisg5985OdWEMonPC3XJhPtGC165VlKTv7JVLci0VvLNfUZK+c72iJCaNOQ3Z vPqqEx03ihyhb/OfndAPo9HMT22ad76+zYuUcOFrbY6kJItcsG/zojmqNLZcF2qRAuvY5pxxxixv m3ZGHrO8bfJ5FplRbIrIobTNKJV5ZYawEew2u+vxEv9iYRSZve9EzlHkTMd5N+x0+Z1KyerdWZhg atOZ08a0XEn+ZgDlbcwahTgdrFor4Uj74LwsxqkcgMzGqRyJzBCVQ5IZolJsMorXClJmFBttVcxB k5giR9/GXAWBOcEIYaNtYfyiOaJe/KLyNkXQ+EXlbVrIRZ5Wag6KYlNEDkVRhKLUjl8Uwha/ColK IWoTlULUJiqFqE1UClGLqER8IaJSFJt/KpbpRKUQNhdVEDpRKYTNPwuJSkuyekSl8jZFUKJSeZsW chRTRKUoNkXkUBRRKUptolKI2kSlELWJSiFqE5VC1CYqhahFVCK+EFEpis0/Fct0olIIm4sqCJ2o FMLmn4VExXpRrwArrqLTXEblbYqgRKXyNi3kKKaISlFsisihKKJSlNpEpRC1iUohahOVQtQmKoWo TVQKUYuoRHwholIUm38qlulEpRA2F1UQOlEphM0/C4mK+9EXICqVtymCEpXK27SQo5giKkWxKSKH oohKUWoTlULUJiqFqE1UClGbqBSiNlEpRC2iEvGFiEpRbP6pWKYTlULYXFRB6ESlEDb/LCQqHvBc gKhU3qYISlQqb9NCjmKKqBTFpogciiIqRalNVApRm6gUojZRKURtolKI2kSlELWISsQXIipFsfmn YplOVAphc1EFoROVQtj8kx/M+ayhn5/pDG3V3/U0QbWrH2bJQd1mIxZBvwcje7nVodK9WDMWrukr 7cduh+FxQ5176mrq4HqjGog38L0Qt6jvl+53d/Dsmh7Zm1sSDt/ZadwQbQnl6Ghcik72yaHPQ2/Z 4P0Q2F4DDyb3p9A3MdV33aGdg/e1QL8OjoB3edyErgynhX0XvNEC5LDVRLZb4Gyk8vDf0O8zTJ+B LpzVta2ujAjQWMLffuINw5Md6I6JQl89KM7EnFkS8tNUdvWa8ZO9/CfD92Zxcpsfod4MsjcLwFgc zYKI7/Eeow6sA+XF7ZkPN/gb+aOgJTk86OZBHQXO9DBEbsoJy62e+EE6ACAFzjh+sMMbfVAr4p7W W4O6LlE6PsPVTLWcdangqwI4r1avEm+vpftjxqZ7gCHAZhMx12A2uak018FEBDOAu1IVSokDfuQO Wmt3UY3OKGHQncWvEPA9Nx3bIEzG4l44S7jqd+/O25roO8r1S21FnmjmybqkXn372/kuKfEMvnqA /89s05GhV7eNuLeobdqEAalt5Kt02wBfcEBLMI7nZ6qTqN+vvfCly7ZXZqm2rJ10S4l7i1qqY7SU TKYDB1rN3uGdY8jZ1FjLNSCn2i54foyOoMikmzN1HDv9tKCIUNn1nrieC4B4Kwt7irEi8KWMzcLg ZrPbwqqDs3Q+Jp5crkZonIbZQQiBcYiDHaGYYxYpQyjOppYp8o2qLHbHkNdcCFA84JvSGiW1bIRs qLPoBg9Mgs1Z1ZAOMM0AqlEP5zafleEWKMeQBxJnIDqxTCOkziwSb+MQJcX7VLNSOq60ASrrayoe mDpUx4+TgS8iPvxD5FLolsVILyqF4T1HKAI+32G+f8vBVJmEU3iv4VGfjXjGgk9bq9h0l4OCTJGE E7N8hL1RRgDQrD4YccknYVY5UHHAItmwZVJ7l8QQaPTixb7JE6pq3DyuuTrMhZomnBzw+ovUYqtk bC8fPzl/dPrq8z+cf/VEDLAolpVWZhVClizl5jJQacGAYZA7gKwTPKzTuGegV2AlO4YuZrAJL9Hk 6i8LPrzJB3gsiDRfphnLBtlIrZUIWcppyVnoKUfcA+tg/bcEK60ZrHT+8MPzP/1NWKnUIhAesMUc /qbUHjLXk33O0xB6wlGnMF7xKPxjYQUF4X4UhiMMBZmyllbl2ly6V6Sssy//UUtZy3aYwRI1AdYR cd6mBdHcri+ykNhfn51+KvwlX7jIeqbUjTLNpIU58ZPM4OXswJhbOVNsw5cp4FsgfA0kMgUWXfyL FUIj8QOoQXC1yVd+quEfGhOz5Rms30QeWUhW5ZiFpNMMtJCwB1/nGLIbKXnrzlqI/2wxcR4UBr6u /v/9tA1DduWqc6yWpK7PHCzjXN6uKr0CdDLyfPjOS7qEh2p+y/eOVDU5lzUEKmjEUIdVTr4kUJ1/ +ruzz/594dxbuECQu7FVsy1W9/+XyXadmAVscv7IHDll4V4aOec2TPSdK5EbyM7Iur4xAhf4WBZ+ 53wSE/USXHKDTJ6nzcdfnD/6ENyyOHNUnX9BAcIjMQ/XBdUH0ItopANVHzwtV578qlQnsgiDPxfb FMpyWkcejegVn7gH+q9T8amtOschWh+F0HqMZSpglu2CFihWOkeq2u5aS+oKnoWbmH8wGSntb6y2 l1f+ZdoqrwAqem2mrQHRFt89W6a2WmuyGjJqa72zim4Ag0+1H5t2eTPKGismo3P+4EsPlyj7/O9f QEz47vSjV395+PLxJ8+/+c2L07++/M9n351+vFB8qGh/W7E7pIP86smLL59B1b/QkNTCZ7o9jCoX m3jMIcuKVfyPvxyml6JcxBHIzhewuNw54OV1IpJNx8ygY31ZlV9TVM0MqYKqFtelmha7AiMvihNe w4jDmlyuqE/GzAbnf/4ajg9+8fZ2u9PCc8NyU0A+0852lr5FMCLmeXH68OyDP559++zl06cXYwHR ZlelikU2CMBz+RfQte0UD02D1EmTE+fP9euSQCU+DBFYLv/UGeOIbmwd8qca/BSuWBtVF8B65aZG KyCz7fQf7swRlmk/Lqer7AL8uJwu3EbnFY22theX9l3wueMRWw4Z0UNpsbB6/s2vikkpj3HMJTCG Blrdk1/BkDcw0AzE/+WpEQk76bIiK2KrlvfVFUEPi6Qinn1SrAhQHY7apAmwU5XtiKyKHtHToG3H 90P4FQz8JrvQUfHpJpzvHaehbwfOxuxDU9VUtqADgOzon1/MnxbCZOYTS2aKi6wnqpoHp8TLPn37 9Pzjf8KJyPnjD0TB08jmna96pM/qSnJA21bzyToNjGhaRSxHBXN7U8oZ+I8gkPqB/jJCVZfgkpl6 6Elner5Fzjbza93t9f5GRx6wSIfQsy+OJ11+wd/UJed2FTbgSDp9sPCB1ro4BsaVXOET7X7admR6 SafX69rf0l1Ld3BMGGvdjZKR9rpQbFrn0u+0pbpMb1lvd0tGCgqjewVzKoXDt37JUFurGxslY221 NuAU1zqdVhuGW/JIp5+2DJmm3Or21nC4PJfJQzCtUsMRZNcVGiHqRq/86n4nnEUe/GII/IIT337J lhUFP+wkFxY5EV4/67dwDlnoEJdZc5m0p74AURV8SW1dNWYqzufjJoaRV5+///IpbKKewvFTvcjJ xYUHmOPIfE7Ug4ahOtBVtzQDgHfldJnm5PjKfwEAAP//AwBQSwMEFAAGAAgAAAAhAObJwnJoCgAA ZIEAABIAAAB3b3JkL251bWJlcmluZy54bWzsXc1u67gV3hfoOwQGvOji2vqXHUzuwIltYIqLTjFz +wCKLd8ItSRDUpK5s+6my6LoophVd32Hdvo0M0Bn1VfoISlKZCIdSzKTOLE2N9fij8iPh+THcw6P vvjyu3B7ducnaRBHFwN9pA3O/GgVr4Po08XgDx+X7yaDszTzorW3jSP/YvDZTwdfvv/1r764P49u w2s/gYxnUEeUnt9B8k2W7c7H43R144deOop3fgSJmzgJvQx+Jp/GoZf88Xb3bhWHOy8LroNtkH0e G5rmDPJq4ovBbRKd51W8C4NVEqfxJiNFzuPNJlj5+R9eImnyXlZyHq9uQz/K6BvHib+FNsRRehPs Ul5b2LU26OINr+QO68RduOX57ndN3rZOvHvAOdyyZt/HyXqXxCs/TeHpnCUWNeoa9u4cQFJFUaJJ E+R38paEXhAV1RDxeDD+xeCNYPDG7N1jUlXZEcDiPQiTd51mibfKfncbnkm/vlpfDDSaJUqDNaTd eVt4MjPnrmuYgzEpHN5us+CDf+dvP37e+TwPfbolT1muLNxtedqlOdeuLNdhKds7khDAH/4uEPkk 45l1lgvkfRkWD9f+Kgi9vGoo+dH/rkgb5iXg8W9XvJatv8lYRbvfJ6TVGfQ5/8vzwCsG8P9dnF4M LNMg2cdlxiAi/Sf1sFT4ceNFn+hULXPntSfsJckyjrKU5AwiKOZ7aTZLAy+vmWaCN0BDSUvgD+Rk OOgU80NxGA1pJ2jV3aGw2UDVQEFSRSjK3IqgMFRBMRrmAnuQYLiGhggGSRXRKHMrQsNUgYY1YlPh ICBsx0WAmJqyWDgTDpsiICwVQNj/+/efXz8UdkMotvG9n3zws8xPik5LC6fzJuBw2sDxTRx6UTUa VLwPXTufYpKs/Y0He24++5BdxG2IBL6bwi4CS+doaI2G9mjojIbuaDgpIOu+r+iWxdcEvhmLeyxN FtdSIb+iNWTydPiMhlMVENkTKx/mSohIsgRRmb8zRLDPC3SQEBPhJ7xM+EXYIWMqEju8dK5sbUnH tgs71K3pbD6zS+oCL23HDm93O3Sh++Xvf/r5x78p4Ym6MaGsooYd0WRxhN40U9QtA+MENFkE461z Rd126VmkTjhIsojHG2aLuqXTPaMOCnfiSlC8ab744mAcG2N8cUCOiTM+ERhvhDUaxhRbU2myuKae IGs0LNNGWCNNliB6ftbIlDoiazQ0yzYX3VnjUjcczTGuCtYNPTxa1liywCpaT1LF8Slzdyb1vXaR qHIrFK29dlFUO/faxXzN6LWLxfJ5bFzxhfXOx8QUnwSKN8ITBd5Xtcf22kVQ3ZW8rxKiI9Ausg1J 5ImmdjUx9NmM8bz2tmdbM2ZgvO5tzwm1bldQot72XOx9PTvs2WHFDOnZYTFDenYo+e307JBrXXrb MygcENt8b3tm7nUSRACZYF7ea3tm67DEDokvq838CrrYnq+WhuYurg6wPeO+FIV2srvbRKkNrCLt CnSH9+fXsLwzR0/W3uDB7/R7/gC8vKgPaPr9FXFzpIXYM1z6T4pjtgI0d5uQAOVuMtJckVW6p8ZU 22BqUB+a+3MRU/YMF9IT0oa2gpPa3x7AyW1yiIieFGt+DkBPjns/B6inxOCfA8/+HNAGZeYkJa+t heMUsrb2pwlKQ5sT1+ZAtzyTsEVZOpNMjEt3qi+6aqw1S5tqmj4vzg5AtNt5Njz9mcTAHE4sSIU2 l7elitzUnwEArtCxHdMJQdctrH/TqeyvUZrlkP4dGWHXpyancFXHSuqTJo5hoz4qIdB6cf+gmADd D8+Gq9MTK8hcZTenDxzqXY17rSJDqYTYlt2EaxYKemraGjaghm3LvscTm58ykZ42ZZz4glMMKLtQ oqCzljHBhtUE1zBpBdJ1k9+rQHrblAq26i1cn1HQYVtDPcvNCTjii9NVN4pLnEiHj5ur2RMbG2TL nD64DFO6nCN9Pnrm5DgWVUfWLFm2rsm7j+5qlTO5JY9hwi/yGMtYLmxXmzHxbW951/Xl4nIxzzWG omGR3TBveds5vd1sQMSpyjGKM7hh/amYWNKtRv3srEhAdg7x7hldLTZBkmYfAnKxXgI0V+vDH367 20tXQXAxmCUBXEmHNvF73heDX/71l59+/CudijPAUsjDboQLzjZtjgnPqnZtDjQs7M+O9Y1SXOlA y8cvkw8+cvzqROZa4Qo3MF83tM+qhG0LLVxufeXoUq4nC67B+R8iuEqoq60inIBAySqZOWFsIqMx db4r0s19/6KsdKFg2LbHWwmBdn7TZD/jKMLfYpsUApycBt5NKfze0AhuL+Mk8k+TNaXrKeIbX2KA +Va8+zb7vC2iCnlM8sX1Pd15K7+YECLz+/mH/1QGKlhBCCoeAiNfPF4T+WuuupRNxF1POo3GhRMn gZTXD8x///HPyvAIJzMwLc9ibEaJZzHbsHTbnudhONqfxWYzZwbX7cowHrBFtNMpRxCQrnLWseAK s7MiETlz7dmjiOIYCcKFq5UfM4KXCMI1gzORAiSIirkeiT0K6MOR6HS+gRO+uBoPcw2nAjT23ZAm ih+RKz5QVh+Ox/EptnWiua6XEJosQvJAsX04JEpOEqqV4FTLXY/KPiX44ago4fsSKhCBScEMohrx emD2KswPR6YpM38B5TrVniPg7FOuHw5OVwpdtd6qD9xFNe31+OxVxB+OT1cq2wAfNYG7qFa+HqK9 SvsuELUklQxDkVQ6pm2BsSEPXNaeVC4XlmObs5LvtCaV0mSXT365gusRqVCwGD65RzWMDKKD6+Tp IINTQv5IwhXgU4bp4nxdPC4fZwBYGZ8y8OsjfPqosLkNDeI7qpCVpwh4ye1ppH34XFLCQvuosNIs 6aPCisHFlXhvPMUkEUzJ+Bw5bnLZx20oXdPqTDfHH7dhSiPriuQSPhdguQtnxvaY9uRyPrXhkwHM tUXWazf1HnnGqLCvkVE+YtZqNJevkTxWQdHzxJ4nPlBo9zyx54n91wMGktKmZulUr4TseeJb4In6 449LuQttYV5qi65EceEYi+VkWarEWmshe9N28S0tbG73pm2QLOp+PtQJFmoYYm/bZh79oqtib9vm 9xwEVHrbdo16pLdtI9817G3bEGAKwae3be+llcdh24aPdcL2C/+WH6ESQod9Rb7VSTcSas0GhTjk JMMuFWNuba2LMe+v1sWYbaqyGL/XWNVI5kJUX4wqQ7+GjwgnwZr4ST9y4xTSKCL8Wggc1XgSQUb4 WdQimKZ5Vo5ri1oE78EDahF87g6oRTAQHlCL4NZ1QC2CC9QBtQjmnANqETxqGtVSM6NYlyqFFZuI rA+ti7FGty7GjBOti+Vn1cpy3Du3agLrbBa1L4csT+j7kPWJ+4hWthNZoLgfdmU5ZIXidycryyHC wr+pV1kOkRb++bnKcoi4oOUQecHKwaeAybpaOe4gS8yXoaqhcMmmY0FEYvA3IiKDF0RkBsUGkRm0 HCIzeEMRocELIlKDF0TEhm+eVaMP941rRx+DBuK3dCvXVWhMRGh41JTKDiIyg5ZDZEYqx/amaz+B kADv/w8AAP//AwBQSwMEFAAGAAgAAAAhAJ/Id172AAAAbAEAABMACAFkb2NQcm9wcy9jdXN0b20u eG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJDLbsMgEEX3lfIPiD0Bk7oJ FnaU2Mm6i7R7hLFjyTwExK1V9d+LlT72Xc7c0Zkzw/fvegST8mGwpoTZmkCgjLTtYPoSvlzOaAdB iMK0YrRGlXBWAe6r1QN/9tYpHwcVQEKYUMJrjK7AOMir0iKsU2xS0lmvRUyl77HtukGqxsqbViZi SsgTlrcQrUbuFwfvvGKK/0W2Vi524fUyu6Rb8W/4DDodh7aEH01eN01OckRPrEYZyY6IbdgWkR0h 9EjrMzucPiFwyzCFwAidTg/dKPpEm2IxurcQfZVtGCVsy+gjx39djn/2VRwvIvc3VV8AAAD//wMA UEsDBBQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAgBY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5y ZWxzIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhM/BigIxDAbgu+A7lNydzngQ kel4WRa8ibjgtXQyM8VpU5oo+vYWTyss7DEJ+f6k3T/CrO6Y2VM00FQ1KIyOeh9HAz/n79UWFIuN vZ0pooEnMuy75aI94WylLPHkE6uiRDYwiaSd1uwmDJYrShjLZKAcrJQyjzpZd7Uj6nVdb3T+bUD3 YapDbyAf+gbU+ZlK8v82DYN3+EXuFjDKHxHa3VgoXMJ8zJS4yDaPKAa8YHi3mqrcC7pr9cd/3QsA AP//AwBQSwMEFAAGAAgAAAAhABXVnjDiAAAAVQEAABgAKABjdXN0b21YbWwvaXRlbVByb3BzMS54 bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJBNa8MwDIbvg/4Ho3vq pMm6pcQp+Wih17HCrq7jJIbYCrYzNsb++xx26o47iUdCel5UHD/0RN6ldQoNg2QbA5FGYKfMwOD6 eo6egTjPTccnNJKBQTiWm4eic4eOe+48WnnxUpPQUKFeWgZfWVunTZtnUXxq8ihLH89RVZ+aqHqq 82Rf1WmaZN9AgtqEM47B6P18oNSJUWrutjhLE4Y9Ws19QDtQ7HslZIti0dJ4uovjPRVL0Os3PUG5 5vndfpG9u8c12mLVfy03dZsUDpbP4yfQsqB/VCvfvaL8AQAA//8DAFBLAwQUAAYACAAAACEAqchc qowAAADaAAAAEwAoAGN1c3RvbVhtbC9pdGVtMS54bWwgoiQAKKAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAskmyCs4vLUpOLVYITs1JTS5JTQkuqcxJtVWKcQxw1IsI9lFSAAv4JeYC BYFiSgoVuTl5xVZJtkoZJSUFVvr6xckZqbmJxXr5Bal5QLm0/KLcxBIgtyhdPz8tLTM51SU/uTQ3 Na9E38jAwEw/KTMpJzM/vSixIKMSahhVjLKz0Yd7xo6XCwAAAP//AwBQSwMEFAAGAAgAAAAhALmk dKF7AQAA8QIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAIyS30/CMBDH3038H5a+j3YgRhcY8Ud4ksREjMa32h5QWbumPRj893YbDKY++Nbr fe9zd992NNnpPNqC86owY5L0GInAiEIqsxyT1/k0viGRR24kzwsDY7IHTybZ5cVI2FQUDp5dYcGh Ah8FkvGpsGOyQrQppV6sQHPfCwoTkovCaY4hdEtquVjzJdA+Y9dUA3LJkdMKGNuWSA5IKVqk3bi8 BkhBIQcNBj1Negk9aRGc9n8W1JkzpVa4t2Gnw7jnbCmaZKveedUKy7LslYN6jDB/Qt9nTy/1qrEy lVcCSDaSIkWFOWQjejqGk998foHA5roNQkI44Fi47E5qZZRHV0V18TFTeb6GfVk46UN9JwoACV44 ZTG8ZEPvXAR1zj3OwtMuFMj7/c9GvwVVPwdbVf2NbFA3bMOwX21nMzbIKBiUNnYeM2+Dh8f5lGR9 llzFrB8nyZwN0+FtythHtVenvjKsudCHCf9JvE5Z0iUeAY1F3U+afQMAAP//AwBQSwMEFAAGAAgA AAAhAC23tl5QAgAAbwkAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUlcGO0zAQhu9IvEPkOxsnDd22 2nTVli2c9sAuZ+SmTmsptiPbbXafgRPiGbhy3QPibQCJt2BsJ2VpidQg0EKiSu1kPB1//vPP2fkN L4ItVZpJkaLoBKOAikwumVil6NX1/MkABdoQsSSFFDRFt1Sj8/HjR2fVKJfC6ADWCz1SKVobU47C UGdryok+kSUV8CyXihMDP9UqlHnOMvpMZhtOhQljjPuhogUx8N96zUqN6mrVMdUqqZalkhnVGprl ha/HCRNoXHcXVCNBOHR9zTjVwSWtgpeSE59QEiE1jSBnS4oU4RjuPu7hpziBTwzfEhTaStmaKE3N LhH7cE44K26bqHJ1XX7JTLZu4luiGFkU1K/RbAUPNnqBUwTbx/FkcIp8JErRACL2qiMxNOUvOAO3 qreLuJzM1XEp0XxucyACdepVrs/Qn9MBkQm0VThQhxymwCFxPCyTuBMHXTGt/Wb/Cw7fPr79/Omd A0EKcwlqAYxOEFeMv6Cs3sqBViJghEEjUXP7xD2tDPo+/LNWyMbITojqA41+SAUP8IWN7kslaiJt UkmaVcdL5cuHN+2IrjbiX0LU+0OIHOrjEX19fweIXj+fxr0obnmrrGKGv6kYLpdUNaDv20vObujS H8B9b3lYwczkRjGqrN+2sDgFDkPnLdZpk04O05XFw/rsjPAFWG0LBztp/MSxk6eb03afOBMri/jC TQqYQTApnBvgZLpvIztjabMRKDTsOHFmpGCAooXE3M1cN206k+g+c35NIsanf4dEPYT1+DsAAAD/ /wMAUEsDBBQABgAIAAAAIQCnamYQWQEAAD0EAAAUAAAAd29yZC93ZWJTZXR0aW5ncy54bWzsU8Fu gkAQvTfpP5C9V5bWKiGCiTGeemrtB6wwyCbsDtldofr1HcFatB7k3hPDezOzb+ZlZvMvVXo1GCtR xywYceaBTjGTehuzz/XqKWSedUJnokQNMduDZfPk8WHWRA1sPsA5yrQeddE2MjErnKsi37dpAUrY EVagicvRKOHo12x9zHOZwhLTnQLt/GfOJ76BUjhSYAtZWXbq1tzTrUGTVQZTsJaEqLLrp4TULCGN mazt6es1kcxoxMmUj/l0HIZtwgaz/VLWRNaiJJb5x3QlzBvk7gflZ/Rdbosb8Bqrv7kLdA7VFU6C Fpk5vuF+azStllGiPcSMDKCgEiktu41TLJEWK3YOOxllT9mwys2FomG1pj/5kFK/daEduguv/AiD 4DXgIX+53w+quO1In+h50ocvXTkz/77Uyazzpz0YrJxU8gArNAuDjQVDh0F87+iTbwAAAP//AwBQ SwMEFAAGAAgAAAAhAGtXAu6aAQAA7AIAABAACAFkb2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJPb9wgEMXvkfIdLJ8b411t/mqWqNooyiFtIq2TnBGM bVQMCNg0++07xFmvq97q08wb/Hj8AG4/BlO8Y4ja2XW5qOqyQCud0rZbly/N/dlVWcQkrBLGWVyX e4zlLT89gefgPIakMRZkYeO67FPyN4xF2eMgYkVjS5PWhUEkakPHXNtqiXdO7ga0iS3r+oLhR0Kr UJ35ybAcHW/e0/+aKidzvvja7D0F5tDg4I1IyH/mOKZSLg3AJhUal4Rp9IB8SfLUwLPoMPJzYGMB by6oyBf16grYWMOmF0HIRAj5+fXlBbCZAN+9N1qKRHT5Dy2Di65NxdMnhyIbAJsvAWKzRbkLOu15 DWzewqO2lGV1DWysKFwQXRC+p0SrHHFqYSuFwQ0h4K0wEYEdBdi4wQu75w878Rt10aDsrTOuy1e5 cdW3x6QqOsXXqrztr/jiG3eX+X3Z/S3OGLzp1G+9kJT0sl7QEY40ZiPYEjRUdLyD4VGAB7qzYPKu 9K/tUB3W/DvIfF/Hx8sXy6qm7xPoQSMo06vifwAAAP//AwBQSwECLQAUAAYACAAAACEA6M8tAN0B AACuCQAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAA IQCZVX4FBAEAAOECAAALAAAAAAAAAAAAAAAAABYEAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAA IQCcgdxNZAEAAFAHAAAcAAAAAAAAAAAAAAAAAEsHAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5y ZWxzUEsBAi0AFAAGAAgAAAAhAE4GV0MNKAAAwykEABEAAAAAAAAAAAAAAAAA8QkAAHdvcmQvZG9j dW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAPFhb5pTAQAA/wIAABAAAAAAAAAAAAAAAAAALTIAAHdv cmQvZm9vdGVyMi54bWxQSwECLQAUAAYACAAAACEAlOL+M2kBAACzAwAAEQAAAAAAAAAAAAAAAACu MwAAd29yZC9lbmRub3Rlcy54bWxQSwECLQAUAAYACAAAACEA5LIEqmkBAAC5AwAAEgAAAAAAAAAA AAAAAABGNQAAd29yZC9mb290bm90ZXMueG1sUEsBAi0AFAAGAAgAAAAhAPFhb5pTAQAA/wIAABAA AAAAAAAAAAAAAAAA3zYAAHdvcmQvZm9vdGVyMS54bWxQSwECLQAUAAYACAAAACEAgwCisVMBAAD/ AgAAEAAAAAAAAAAAAAAAAABgOAAAd29yZC9oZWFkZXIyLnhtbFBLAQItABQABgAIAAAAIQCDAKKx UwEAAP8CAAAQAAAAAAAAAAAAAAAAAOE5AAB3b3JkL2hlYWRlcjEueG1sUEsBAi0AFAAGAAgAAAAh AMccbRScBgAAURsAABUAAAAAAAAAAAAAAAAAYjsAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQIt ABQABgAIAAAAIQB+6RExsiIAALKjAAARAAAAAAAAAAAAAAAAADFCAAB3b3JkL3NldHRpbmdzLnht bFBLAQItABQABgAIAAAAIQD4r4Tg5AwAAMFMAAAPAAAAAAAAAAAAAAAAABJlAAB3b3JkL3N0eWxl cy54bWxQSwECLQAUAAYACAAAACEA5snCcmgKAABkgQAAEgAAAAAAAAAAAAAAAAAjcgAAd29yZC9u dW1iZXJpbmcueG1sUEsBAi0AFAAGAAgAAAAhAJ/Id172AAAAbAEAABMAAAAAAAAAAAAAAAAAu3wA AGRvY1Byb3BzL2N1c3RvbS54bWxQSwECLQAUAAYACAAAACEAdD85esIAAAAoAQAAHgAAAAAAAAAA AAAAAADqfgAAY3VzdG9tWG1sL19yZWxzL2l0ZW0xLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhABXV njDiAAAAVQEAABgAAAAAAAAAAAAAAAAA8IAAAGN1c3RvbVhtbC9pdGVtUHJvcHMxLnhtbFBLAQIt ABQABgAIAAAAIQCpyFyqjAAAANoAAAATAAAAAAAAAAAAAAAAADCCAABjdXN0b21YbWwvaXRlbTEu eG1sUEsBAi0AFAAGAAgAAAAhALmkdKF7AQAA8QIAABEAAAAAAAAAAAAAAAAAFYMAAGRvY1Byb3Bz L2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAC23tl5QAgAAbwkAABIAAAAAAAAAAAAAAAAAx4UAAHdv cmQvZm9udFRhYmxlLnhtbFBLAQItABQABgAIAAAAIQCnamYQWQEAAD0EAAAUAAAAAAAAAAAAAAAA AEeIAAB3b3JkL3dlYlNldHRpbmdzLnhtbFBLAQItABQABgAIAAAAIQBrVwLumgEAAOwCAAAQAAAA AAAAAAAAAAAAANKJAABkb2NQcm9wcy9hcHAueG1sUEsFBgAAAAAWABYAjAUAAKKMAAAAAA== --_004_B8F9A780D330094D99AF023C5877DABA43C7D54Ankgeml501mbschi_-- From bclaise@cisco.com Mon Feb 10 22:25:07 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B2D1A0696 for ; Mon, 10 Feb 2014 22:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0HqLAwdCFqU for ; Mon, 10 Feb 2014 22:25:03 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BC91E1A068F for ; Mon, 10 Feb 2014 22:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28219; q=dns/txt; s=iport; t=1392099903; x=1393309503; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=2dSuWndT2MwVQMI625gp1W0mbkHp6r5bAURiQtd2o7Q=; b=G8grZL3U0dSxCA8WBjew9fvWgLB3QcqXDe3ni947Ro39CS7Ud6w+H/0g keG/RQRx1tNuqAQKhYVwfF2lJJmeZyM5DMhs4a5fM4Tf2j5cD7kyDDgtL LxgwdGc1QW225ezUK+WGfZpUoIrzCDw8YjUx4j5damxZuRURCxFJOBXsQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAFnB+VKrRDoJ/2dsb2JhbABZgkhEOINYhV22BoENFnSCJQEBAQQjCksNBAkCDgMDAQEBChYBAQYDAgIJAwIBAgE0CQgGAQwGAgEBBYd7Do1Fm3+gGheODhEBLhEMCwEGgmmBSQSJSI5igTKFFYtZgW+BXxuBNQ X-IronPort-AV: E=Sophos;i="4.95,823,1384300800"; d="scan'208,217";a="102868888" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 11 Feb 2014 06:25:03 +0000 Received: from [10.21.124.198] (sjc-vpn6-1222.cisco.com [10.21.124.198]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1B6P2xM004340; Tue, 11 Feb 2014 06:25:02 GMT Message-ID: <52F9C23E.3060308@cisco.com> Date: Mon, 10 Feb 2014 22:25:02 -0800 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Qin Wu , "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> <52F39769.1040105@cisco.com> <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> <52F9BBB0.1090204@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010207020002040703030008" Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 06:25:07 -0000 This is a multi-part message in MIME format. --------------010207020002040703030008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Qin, That works for me. As a new PM-DIR member and someone deeply involved in XRBLOCK, do I guess correctly that you have checked for naming collisions, and also some sort of naming consistency in the XRBLOCK metrics? http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-01#section-4 might help as an inventory as of Oct 2013 Regards, Benoit. > > Hi, Benoit and Al: > > Yes, I confirmed to make change to Appendix A of > draft-ietf-xrblock-rtcp-xr-qoe. I am not supposed to change > calculation algorithm name in this draft. > > Here is my proposed change to Appendix( See attached) which I have > sent to my authors for confirmation. > > Hope this clarify. > > Regards! > > -Qin > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* Tuesday, February 11, 2014 1:57 PM > *To:* MORTON, ALFRED C (AL); pm-dir@ietf.org; Qin Wu > *Subject:* Re: [pm-dir] Fwd: Benoit Claise's Discuss on > draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) > > Hi Al, > > I meant the different "metric name" entries in Appendix A of the draft. > Qin Wu, in cc, agreed to improve those. > We should avoid collisions with the exist XR block defined metrics. > > Regards, Benoit > > Hi Benoit, > > it's not clear what registry you are asking about: > > The IANA section of this draft references and existing registry for > > RTCP-XR metrics (defined in RFC 3611), which has attribute names > > and long-form attribute names for the "MOS Metrics block". > > Also, there's a new registry of calculation algorithms defined in > > the IANA section: > > o Initial assignments are as follows: > > Name Name Description Reference Type > > ========= =================================== ========== ==== > > P564 ITU-T P.564 Compliant Algorithm [P.564] Voice > > G107 ITU-T G.107 [G.107] Voice > > TS101_329 ETSI TS 101 329-5 Annex E [ETSI] Voice > > JJ201_1 TTC JJ201.1 [TTC] Voice > > G107_1 ITU-T G.107.1 [G.107.1] Voice > > P862 ITU-T P.862 [P.862] Voice > > P862_2 ITU-T P.862.2 [P.862.2] Voice > > P863 ITU-T P.863 [P.863] Voice > > P1201_1 ITU-T P.1201.1 [P.1201.1] Multimedia > > P1201_2 ITU-T P.1201.2 [P.1201.2] Multimedia > > P1202_1 ITU-T P.1202.1 [P.1202.1] Video > > P1202_2 ITU-T P.1202.2 [P.1202.2] Video > > Which one of these, or other naming convention are you talking about? > > Al > > *From:*pm-dir [mailto:pm-dir-bounces@ietf.org] *On Behalf Of > *Benoit Claise > *Sent:* Thursday, February 06, 2014 9:09 AM > *To:* pm-dir@ietf.org > *Subject:* [pm-dir] Fwd: Benoit Claise's Discuss on > draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) > > PM-Dir, > > I believe that we need a little bit of consistency regarding the > naming convention for the perf. metrics. > Specifically because those xrblock perf. metrics should be the > basis for an IETF registry. > Feedback? > > Regards, Benoit > > > > -------- Original Message -------- > > *Subject: * > > > > Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: > (with DISCUSS) > > *Date: * > > > > Wed, 5 Feb 2014 22:20:33 -0800 > > *From: * > > > > Benoit Claise > > *To: * > > > > The IESG > > *CC: * > > > > > , > > > > Benoit Claise has entered the following ballot position for > > draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer tohttp://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The metric names in the registry are not specific enough: payload type, > > calculation identifier metric, segment type, and potentially MOS. I guess > > they should say something about RTP. Let me file this DISCUSS while I > > double-check with the performance metric directorate. > > > > > > > > > > . > > > --------------010207020002040703030008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Qin,

That works for me.

As a new PM-DIR member and someone deeply involved in XRBLOCK, do I guess correctly that you have checked for naming collisions, and also some sort of naming consistency in the XRBLOCK metrics?

http://tools.ietf.org/html/draft-claise-ippm-perf-metric-registry-01#section-4 might help as an inventory as of Oct 2013

Regards, Benoit.

Hi, Benoit and Al:

Yes, I confirmed to make change to Appendix A of draft-ietf-xrblock-rtcp-xr-qoe. I am not supposed to change calculation algorithm name in this draft.

Here is my proposed change to Appendix( See attached) which I have sent to my authors for confirmation.

Hope this clarify.

 

Regards!

-Qin

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, February 11, 2014 1:57 PM
To: MORTON, ALFRED C (AL); pm-dir@ietf.org; Qin Wu
Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)

 

Hi Al,

I meant the different "metric name" entries in Appendix A of the draft.
Qin Wu, in cc, agreed to improve those.
We should avoid collisions with the exist XR block defined metrics.

Regards, Benoit

Hi Benoit,

it's not clear what registry you are asking about:

 

The IANA section of this draft references and existing registry for

RTCP-XR metrics (defined in RFC 3611), which has attribute names

and long-form attribute names for the "MOS Metrics block".

 

Also, there's a new registry of calculation algorithms defined in

the IANA section:

 

   o  Initial assignments are as follows:

 

Name             Name Description                  Reference    Type

=========   ===================================   ==========    ====

P564       ITU-T P.564 Compliant Algorithm        [P.564]        Voice

G107       ITU-T G.107                            [G.107]        Voice

TS101_329  ETSI TS 101 329-5 Annex E              [ETSI]         Voice

JJ201_1    TTC JJ201.1                            [TTC]          Voice

G107_1     ITU-T G.107.1                          [G.107.1]      Voice

P862       ITU-T P.862                            [P.862]        Voice

P862_2     ITU-T P.862.2                          [P.862.2]      Voice

P863       ITU-T P.863                            [P.863]        Voice

P1201_1    ITU-T P.1201.1                     [P.1201.1]      Multimedia

P1201_2    ITU-T P.1201.2                     [P.1201.2]      Multimedia

P1202_1    ITU-T P.1202.1                     [P.1202.1]         Video

P1202_2    ITU-T P.1202.2                     [P.1202.2]         Video

 

Which one of these, or other naming convention are you talking about?

Al

 

 

From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Thursday, February 06, 2014 9:09 AM
To: pm-dir@ietf.org
Subject: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)

 

PM-Dir,

I believe that we need a little bit of consistency regarding the naming convention for the perf. metrics.
Specifically because those xrblock perf. metrics should be the basis for an IETF registry.
Feedback?

Regards, Benoit



-------- Original Message --------

Subject:

Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS)

Date:

Wed, 5 Feb 2014 22:20:33 -0800

From:

Benoit Claise <bclaise@cisco.com>

To:

The IESG <iesg@ietf.org>

CC:

<xrblock-chairs@tools.ietf.org>, <draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org>

 

Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-qoe-13: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-qoe/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
The metric names in the registry are not specific enough: payload type,
calculation identifier metric, segment type, and potentially MOS. I guess
they should say something about RTP. Let me file this DISCUSS while I
double-check with the performance metric directorate.
 
 
 
 
.
 

 

 

 


--------------010207020002040703030008-- From bill.wu@huawei.com Mon Feb 10 22:46:20 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC851A07AF for ; Mon, 10 Feb 2014 22:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GYJzQjfmoOM for ; Mon, 10 Feb 2014 22:46:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 441001A0355 for ; Mon, 10 Feb 2014 22:46:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDL64086; Tue, 11 Feb 2014 06:46:15 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 06:46:04 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Feb 2014 06:46:14 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Tue, 11 Feb 2014 14:46:07 +0800 From: Qin Wu To: Benoit Claise , "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" Thread-Topic: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) Thread-Index: AQHPIwOmLwhu2PB9J0WyKFRcpGvbR5qvljUsgAABKdD//4B7AIAAi4ww Date: Tue, 11 Feb 2014 06:46:07 +0000 Message-ID: References: <20140206062033.24078.98355.idtracker@ietfa.amsl.com> <52F39769.1040105@cisco.com> <2845723087023D4CB5114223779FA9C8BC23ECF9@njfpsrvexg8.research.att.com> <52F9BBB0.1090204@cisco.com> <52F9C23E.3060308@cisco.com> In-Reply-To: <52F9C23E.3060308@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7D58Fnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [pm-dir] Fwd: Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-qoe-13: (with DISCUSS) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 06:46:20 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7D58Fnkgeml501mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGhhdmUgY2hlY2tlZCB0aGF0LCBJIHdpbGwgY2hlY2sgYWdhaW4gdG8gbWFrZSBzdXJl IGV2ZXJ5dGhpbmcgaXMgY29uc2lzdGVudCBiZWZvcmUgdGhlIHVwZGF0ZSBpcyBwb3N0ZWQuDQoN ClJlZ2FyZHMhDQotUWluDQpGcm9tOiBwbS1kaXIgW21haWx0bzpwbS1kaXItYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlbm9pdCBDbGFpc2UNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDExLCAyMDE0IDI6MjUgUE0NClRvOiBRaW4gV3U7IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgcG0t ZGlyQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3BtLWRpcl0gRndkOiBCZW5vaXQgQ2xhaXNlJ3Mg RGlzY3VzcyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3aXRoIERJU0NV U1MpDQoNCkhpIFFpbiwNCg0KVGhhdCB3b3JrcyBmb3IgbWUuDQoNCkFzIGEgbmV3IFBNLURJUiBt ZW1iZXIgYW5kIHNvbWVvbmUgZGVlcGx5IGludm9sdmVkIGluIFhSQkxPQ0ssIGRvIEkgZ3Vlc3Mg Y29ycmVjdGx5IHRoYXQgeW91IGhhdmUgY2hlY2tlZCBmb3IgbmFtaW5nIGNvbGxpc2lvbnMsIGFu ZCBhbHNvIHNvbWUgc29ydCBvZiBuYW1pbmcgY29uc2lzdGVuY3kgaW4gdGhlIFhSQkxPQ0sgbWV0 cmljcz8NCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2xhaXNlLWlwcG0tcGVy Zi1tZXRyaWMtcmVnaXN0cnktMDEjc2VjdGlvbi00IG1pZ2h0IGhlbHAgYXMgYW4gaW52ZW50b3J5 IGFzIG9mIE9jdCAyMDEzDQoNClJlZ2FyZHMsIEJlbm9pdC4NCkhpLCBCZW5vaXQgYW5kIEFsOg0K WWVzLCBJIGNvbmZpcm1lZCB0byBtYWtlIGNoYW5nZSB0byBBcHBlbmRpeCBBIG9mIGRyYWZ0LWll dGYteHJibG9jay1ydGNwLXhyLXFvZS4gSSBhbSBub3Qgc3VwcG9zZWQgdG8gY2hhbmdlIGNhbGN1 bGF0aW9uIGFsZ29yaXRobSBuYW1lIGluIHRoaXMgZHJhZnQuDQpIZXJlIGlzIG15IHByb3Bvc2Vk IGNoYW5nZSB0byBBcHBlbmRpeCggU2VlIGF0dGFjaGVkKSB3aGljaCBJIGhhdmUgc2VudCB0byBt eSBhdXRob3JzIGZvciBjb25maXJtYXRpb24uDQpIb3BlIHRoaXMgY2xhcmlmeS4NCg0KUmVnYXJk cyENCi1RaW4NCkZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2NvLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDE6NTcgUE0NClRvOiBNT1JUT04sIEFM RlJFRCBDIChBTCk7IHBtLWRpckBpZXRmLm9yZzxtYWlsdG86cG0tZGlyQGlldGYub3JnPjsgUWlu IFd1DQpTdWJqZWN0OiBSZTogW3BtLWRpcl0gRndkOiBCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBv biBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3aXRoIERJU0NVU1MpDQoNCkhp IEFsLA0KDQpJIG1lYW50IHRoZSBkaWZmZXJlbnQgIm1ldHJpYyBuYW1lIiBlbnRyaWVzIGluIEFw cGVuZGl4IEEgb2YgdGhlIGRyYWZ0Lg0KUWluIFd1LCBpbiBjYywgYWdyZWVkIHRvIGltcHJvdmUg dGhvc2UuDQpXZSBzaG91bGQgYXZvaWQgY29sbGlzaW9ucyB3aXRoIHRoZSBleGlzdCBYUiBibG9j ayBkZWZpbmVkIG1ldHJpY3MuDQoNClJlZ2FyZHMsIEJlbm9pdA0KSGkgQmVub2l0LA0KaXQncyBu b3QgY2xlYXIgd2hhdCByZWdpc3RyeSB5b3UgYXJlIGFza2luZyBhYm91dDoNCg0KVGhlIElBTkEg c2VjdGlvbiBvZiB0aGlzIGRyYWZ0IHJlZmVyZW5jZXMgYW5kIGV4aXN0aW5nIHJlZ2lzdHJ5IGZv cg0KUlRDUC1YUiBtZXRyaWNzIChkZWZpbmVkIGluIFJGQyAzNjExKSwgd2hpY2ggaGFzIGF0dHJp YnV0ZSBuYW1lcw0KYW5kIGxvbmctZm9ybSBhdHRyaWJ1dGUgbmFtZXMgZm9yIHRoZSAiTU9TIE1l dHJpY3MgYmxvY2siLg0KDQpBbHNvLCB0aGVyZSdzIGEgbmV3IHJlZ2lzdHJ5IG9mIGNhbGN1bGF0 aW9uIGFsZ29yaXRobXMgZGVmaW5lZCBpbg0KdGhlIElBTkEgc2VjdGlvbjoNCg0KICAgbyAgSW5p dGlhbCBhc3NpZ25tZW50cyBhcmUgYXMgZm9sbG93czoNCg0KTmFtZSAgICAgICAgICAgICBOYW1l IERlc2NyaXB0aW9uICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlICAgIFR5cGUNCj09PT09PT09 PSAgID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ICAgPT09PT09PT09PSAgICA9 PT09DQpQNTY0ICAgICAgIElUVS1UIFAuNTY0IENvbXBsaWFudCBBbGdvcml0aG0gICAgICAgIFtQ LjU2NF0gICAgICAgIFZvaWNlDQpHMTA3ICAgICAgIElUVS1UIEcuMTA3ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtHLjEwN10gICAgICAgIFZvaWNlDQpUUzEwMV8zMjkgIEVUU0kgVFMgMTAx IDMyOS01IEFubmV4IEUgICAgICAgICAgICAgIFtFVFNJXSAgICAgICAgIFZvaWNlDQpKSjIwMV8x ICAgIFRUQyBKSjIwMS4xICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtUVENdICAgICAgICAg IFZvaWNlDQpHMTA3XzEgICAgIElUVS1UIEcuMTA3LjEgICAgICAgICAgICAgICAgICAgICAgICAg IFtHLjEwNy4xXSAgICAgIFZvaWNlDQpQODYyICAgICAgIElUVS1UIFAuODYyICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQLjg2Ml0gICAgICAgIFZvaWNlDQpQODYyXzIgICAgIElUVS1UIFAu ODYyLjIgICAgICAgICAgICAgICAgICAgICAgICAgIFtQLjg2Mi4yXSAgICAgIFZvaWNlDQpQODYz ICAgICAgIElUVS1UIFAuODYzICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQLjg2M10gICAg ICAgIFZvaWNlDQpQMTIwMV8xICAgIElUVS1UIFAuMTIwMS4xICAgICAgICAgICAgICAgICAgICAg W1AuMTIwMS4xXSAgICAgIE11bHRpbWVkaWENClAxMjAxXzIgICAgSVRVLVQgUC4xMjAxLjIgICAg ICAgICAgICAgICAgICAgICBbUC4xMjAxLjJdICAgICAgTXVsdGltZWRpYQ0KUDEyMDJfMSAgICBJ VFUtVCBQLjEyMDIuMSAgICAgICAgICAgICAgICAgICAgIFtQLjEyMDIuMV0gICAgICAgICBWaWRl bw0KUDEyMDJfMiAgICBJVFUtVCBQLjEyMDIuMiAgICAgICAgICAgICAgICAgICAgIFtQLjEyMDIu Ml0gICAgICAgICBWaWRlbw0KDQpXaGljaCBvbmUgb2YgdGhlc2UsIG9yIG90aGVyIG5hbWluZyBj b252ZW50aW9uIGFyZSB5b3UgdGFsa2luZyBhYm91dD8NCkFsDQoNCg0KRnJvbTogcG0tZGlyIFtt YWlsdG86cG0tZGlyLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW5vaXQgQ2xhaXNl DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDYsIDIwMTQgOTowOSBBTQ0KVG86IHBtLWRpckBp ZXRmLm9yZzxtYWlsdG86cG0tZGlyQGlldGYub3JnPg0KU3ViamVjdDogW3BtLWRpcl0gRndkOiBC ZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2Ut MTM6ICh3aXRoIERJU0NVU1MpDQoNClBNLURpciwNCg0KSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCBh IGxpdHRsZSBiaXQgb2YgY29uc2lzdGVuY3kgcmVnYXJkaW5nIHRoZSBuYW1pbmcgY29udmVudGlv biBmb3IgdGhlIHBlcmYuIG1ldHJpY3MuDQpTcGVjaWZpY2FsbHkgYmVjYXVzZSB0aG9zZSB4cmJs b2NrIHBlcmYuIG1ldHJpY3Mgc2hvdWxkIGJlIHRoZSBiYXNpcyBmb3IgYW4gSUVURiByZWdpc3Ry eS4NCkZlZWRiYWNrPw0KDQpSZWdhcmRzLCBCZW5vaXQNCg0KDQotLS0tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0Og0KDQpCZW5vaXQgQ2xhaXNlJ3MgRGlzY3VzcyBvbiBk cmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3aXRoIERJU0NVU1MpDQoNCkRhdGU6 DQoNCldlZCwgNSBGZWIgMjAxNCAyMjoyMDozMyAtMDgwMA0KDQpGcm9tOg0KDQpCZW5vaXQgQ2xh aXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPg0KDQpUbzoN Cg0KVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+PG1haWx0bzppZXNnQGlldGYub3JnPg0KDQpDQzoN Cg0KPHhyYmxvY2stY2hhaXJzQHRvb2xzLmlldGYub3JnPjxtYWlsdG86eHJibG9jay1jaGFpcnNA dG9vbHMuaWV0Zi5vcmc+LCA8ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmll dGYub3JnPjxtYWlsdG86ZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lQHRvb2xzLmlldGYu b3JnPg0KDQoNCg0KQmVub2l0IENsYWlzZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxv dCBwb3NpdGlvbiBmb3INCg0KZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTEzOiBEaXNj dXNzDQoNCg0KDQpXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUg aW50YWN0IGFuZCByZXBseSB0byBhbGwNCg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRo ZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCg0KaW50cm9kdWN0b3J5 IHBhcmFncmFwaCwgaG93ZXZlci4pDQoNCg0KDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQoNCmZvciBt b3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu DQoNCg0KDQoNCg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlv bnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS8NCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpESVNDVVNTOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpUaGUgbWV0cmljIG5hbWVz IGluIHRoZSByZWdpc3RyeSBhcmUgbm90IHNwZWNpZmljIGVub3VnaDogcGF5bG9hZCB0eXBlLA0K DQpjYWxjdWxhdGlvbiBpZGVudGlmaWVyIG1ldHJpYywgc2VnbWVudCB0eXBlLCBhbmQgcG90ZW50 aWFsbHkgTU9TLiBJIGd1ZXNzDQoNCnRoZXkgc2hvdWxkIHNheSBzb21ldGhpbmcgYWJvdXQgUlRQ LiBMZXQgbWUgZmlsZSB0aGlzIERJU0NVU1Mgd2hpbGUgSQ0KDQpkb3VibGUtY2hlY2sgd2l0aCB0 aGUgcGVyZm9ybWFuY2UgbWV0cmljIGRpcmVjdG9yYXRlLg0KDQoNCg0KDQoNCg0KDQoNCg0KLg0K DQoNCg0KDQoNCg0K --_000_B8F9A780D330094D99AF023C5877DABA43C7D58Fnkgeml501mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0K c3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuag vOW8jyI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1M UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0KcC5IVE1M UHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1hdHRlZA0K CXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlllcywgSSBoYXZlIGNoZWNrZWQgdGhhdCwgSSB3aWxsIGNoZWNrIGFnYWlu IHRvIG1ha2Ugc3VyZSBldmVyeXRoaW5nIGlzIGNvbnNpc3RlbnQgYmVmb3JlIHRoZSB1cGRhdGUg aXMgcG9zdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LVFpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHBtLWRpciBbbWFpbHRvOnBtLWRpci1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZW5vaXQgQ2xhaXNlPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDI6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IFFp biBXdTsgTU9SVE9OLCBBTEZSRUQgQyAoQUwpOyBwbS1kaXJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtwbS1kaXJdIEZ3ZDogQmVub2l0IENsYWlzZSdzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTEzOiAod2l0aCBESVNDVVNTKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBRaW4sPGJyPg0K PGJyPg0KVGhhdCB3b3JrcyBmb3IgbWUuPGJyPg0KPGJyPg0KQXMgYSBuZXcgUE0tRElSIG1lbWJl ciBhbmQgc29tZW9uZSBkZWVwbHkgaW52b2x2ZWQgaW4gWFJCTE9DSywgZG8gSSBndWVzcyBjb3Jy ZWN0bHkgdGhhdCB5b3UgaGF2ZSBjaGVja2VkIGZvciBuYW1pbmcgY29sbGlzaW9ucywgYW5kIGFs c28gc29tZSBzb3J0IG9mIG5hbWluZyBjb25zaXN0ZW5jeSBpbiB0aGUgWFJCTE9DSyBtZXRyaWNz Pzxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNs YWlzZS1pcHBtLXBlcmYtbWV0cmljLXJlZ2lzdHJ5LTAxI3NlY3Rpb24tNCI+aHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2xhaXNlLWlwcG0tcGVyZi1tZXRyaWMtcmVnaXN0cnktMDEj c2VjdGlvbi00PC9hPiBtaWdodCBoZWxwIGFzIGFuIGludmVudG9yeSBhcyBvZiBPY3QgMjAxMzxi cj4NCjxicj4NClJlZ2FyZHMsIEJlbm9pdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGksIEJlbm9pdCBhbmQgQWw6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywg SSBjb25maXJtZWQgdG8gbWFrZSBjaGFuZ2UgdG8gQXBwZW5kaXggQSBvZiBkcmFmdC1pZXRmLXhy YmxvY2stcnRjcC14ci1xb2UuIEkgYW0gbm90IHN1cHBvc2VkIHRvIGNoYW5nZSBjYWxjdWxhdGlv biBhbGdvcml0aG0gbmFtZSBpbiB0aGlzIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IZXJlIGlzIG15IHByb3Bvc2VkIGNoYW5nZSB0byBBcHBlbmRpeCggU2VlIGF0dGFjaGVk KSB3aGljaCBJIGhhdmUgc2VudCB0byBteSBhdXRob3JzIGZvciBjb25maXJtYXRpb24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvcGUgdGhpcyBjbGFyaWZ5Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVn YXJkcyE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVFpbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ IEJlbm9pdCBDbGFpc2UgWzxhIGhyZWY9Im1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbSI+bWFpbHRv OmJjbGFpc2VAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJy dWFyeSAxMSwgMjAxNCAxOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBNT1JUT04sIEFMRlJFRCBDIChB TCk7IDxhIGhyZWY9Im1haWx0bzpwbS1kaXJAaWV0Zi5vcmciPnBtLWRpckBpZXRmLm9yZzwvYT47 IFFpbiBXdTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3BtLWRpcl0gRndkOiBCZW5vaXQgQ2xh aXNlJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6ICh3aXRo IERJU0NVU1MpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpIEFsLDxicj4NCjxicj4NCkkgbWVhbnQgdGhlIGRpZmZlcmVudCAmcXVvdDttZXRy aWMgbmFtZSZxdW90OyBlbnRyaWVzIGluIEFwcGVuZGl4IEEgb2YgdGhlIGRyYWZ0Ljxicj4NClFp biBXdSwgaW4gY2MsIGFncmVlZCB0byBpbXByb3ZlIHRob3NlLjxicj4NCldlIHNob3VsZCBhdm9p ZCBjb2xsaXNpb25zIHdpdGggdGhlIGV4aXN0IFhSIGJsb2NrIGRlZmluZWQgbWV0cmljcy48YnI+ DQo8YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgQmVub2l0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5pdCdzIG5vdCBjbGVhciB3aGF0IHJlZ2lz dHJ5IHlvdSBhcmUgYXNraW5nIGFib3V0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlIElBTkEgc2VjdGlvbiBvZiB0aGlzIGRyYWZ0 IHJlZmVyZW5jZXMgYW5kIGV4aXN0aW5nIHJlZ2lzdHJ5IGZvcg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlJUQ1AtWFIgbWV0cmljcyAoZGVm aW5lZCBpbiBSRkMgMzYxMSksIHdoaWNoIGhhcyBhdHRyaWJ1dGUgbmFtZXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+YW5kIGxvbmctZm9ybSBh dHRyaWJ1dGUgbmFtZXMgZm9yIHRoZSAmcXVvdDtNT1MgTWV0cmljcyBibG9jayZxdW90Oy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFs c28sIHRoZXJlJ3MgYSBuZXcgcmVnaXN0cnkgb2YgY2FsY3VsYXRpb24gYWxnb3JpdGhtcyBkZWZp bmVkIGluDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+dGhlIElBTkEgc2VjdGlvbjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IEluaXRpYWwgYXNz aWdubWVudHMgYXJlIGFzIGZvbGxvd3M6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5hbWUgRGVzY3Jp cHRpb24mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVmZXJl bmNlJm5ic3A7Jm5ic3A7Jm5ic3A7IFR5cGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PT09PT09PT09Jm5ic3A7Jm5ic3A7ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Jm5ic3A7Jm5ic3A7ID09PT09PT09PT0mbmJzcDsmbmJz cDsmbmJzcDsgPT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5QNTY0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElUVS1U IFAuNTY0IENvbXBsaWFudCBBbGdvcml0aG0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgW1AuNTY0XSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBWb2ljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5HMTA3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElUVS1UIEcu MTA3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtHLjEw N10mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVm9pY2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VFMxMDFfMzI5 Jm5ic3A7IEVUU0kgVFMgMTAxIDMyOS01IEFubmV4IEUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0VU U0ldICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1ZvaWNl PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkpK MjAxXzEmbmJzcDsmbmJzcDsmbmJzcDsgVFRDIEpKMjAxLjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1RUQ10mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVm9pY2U8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RzEwN18xJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElUVS1UIEcuMTA3LjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg W0cuMTA3LjFdJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFZvaWNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlA4NjImbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSVRVLVQgUC44NjImbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1AuODYyXSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWb2ljZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5QODYyXzImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SVRVLVQgUC44NjIuMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbUC44NjIu Ml0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVm9pY2U8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+UDg2MyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBJVFUtVCBQLjg2MyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUC44NjNdJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFZvaWNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlAxMjAxXzEmbmJzcDsmbmJzcDsmbmJzcDsgSVRVLVQgUC4xMjAx LjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgW1AuMTIwMS4xXSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNdWx0aW1l ZGlhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PlAxMjAxXzImbmJzcDsmbmJzcDsmbmJzcDsgSVRVLVQgUC4xMjAxLjImbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1AuMTIwMS4y XSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNdWx0aW1lZGlhPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlAxMjAyXzEmbmJzcDsmbmJz cDsmbmJzcDsgSVRVLVQgUC4xMjAyLjEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW1AuMTIwMi4xXSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWaWRlbzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5QMTIwMl8yJm5ic3A7Jm5ic3A7Jm5i c3A7IElUVS1UIFAuMTIwMi4yJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtQLjEyMDIuMl0mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVmlkZW88L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPldoaWNoIG9uZSBvZiB0aGVzZSwgb3Ig b3RoZXIgbmFtaW5nIGNvbnZlbnRpb24gYXJlIHlvdSB0YWxraW5nIGFib3V0Pzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BbDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IHBtLWRpciBbPGEgaHJlZj0i bWFpbHRvOnBtLWRpci1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cG0tZGlyLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZW5vaXQgQ2xhaXNlPGJyPg0KPGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAwNiwgMjAxNCA5OjA5IEFNPGJyPg0KPGI+VG86PC9i PiA8YSBocmVmPSJtYWlsdG86cG0tZGlyQGlldGYub3JnIj5wbS1kaXJAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFtwbS1kaXJdIEZ3ZDogQmVub2l0IENsYWlzZSdzIERpc2N1c3Mg b24gZHJhZnQtaWV0Zi14cmJsb2NrLXJ0Y3AteHItcW9lLTEzOiAod2l0aCBESVNDVVNTKTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBNLURpciw8YnI+DQo8 YnI+DQpJIGJlbGlldmUgdGhhdCB3ZSBuZWVkIGEgbGl0dGxlIGJpdCBvZiBjb25zaXN0ZW5jeSBy ZWdhcmRpbmcgdGhlIG5hbWluZyBjb252ZW50aW9uIGZvciB0aGUgcGVyZi4gbWV0cmljcy48YnI+ DQpTcGVjaWZpY2FsbHkgYmVjYXVzZSB0aG9zZSB4cmJsb2NrIHBlcmYuIG1ldHJpY3Mgc2hvdWxk IGJlIHRoZSBiYXNpcyBmb3IgYW4gSUVURiByZWdpc3RyeS48YnI+DQpGZWVkYmFjaz88YnI+DQo8 YnI+DQpSZWdhcmRzLCBCZW5vaXQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQotLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tIDxv OnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBj ZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3Jh cD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxi PlN1YmplY3Q6IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6 MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbm9pdCBDbGFpc2UncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS0xMzogKHdpdGggRElTQ1VT Uyk8bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxp Z249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPkRhdGU6IDwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlZCwgNSBGZWIgMjAxNCAyMjoyMDozMyAtMDgw MDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGln bj0idG9wIiBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RnJvbTogPC9i PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86 YmNsYWlzZUBjaXNjby5jb20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+PG86cD48L286 cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0 eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIElFU0cgPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPiZs dDtpZXNnQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRy Pg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxp Z246cmlnaHQiPjxiPkNDOiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBjbSAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt YWlsdG86eHJibG9jay1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPiZsdDt4cmJsb2NrLWNoYWlyc0B0 b29scy5pZXRmLm9yZyZndDs8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYteHJibG9j ay1ydGNwLXhyLXFvZUB0b29scy5pZXRmLm9yZyI+Jmx0O2RyYWZ0LWlldGYteHJibG9jay1ydGNw LXhyLXFvZUB0b29scy5pZXRmLm9yZyZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+QmVub2l0IENsYWlz ZSBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UtMTM6IERpc2N1c3M8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XaGVu IHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBs eSB0byBhbGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQg aW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlBsZWFzZSByZWZlciB0byA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCI+aHR0cDovL3d3dy5pZXRm Lm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8L2E+PG86cD48L286cD48 L3ByZT4NCjxwcmU+Zm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBD T01NRU5UIHBvc2l0aW9ucy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgZG9jdW1lbnQs IGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXhyYmxvY2stcnRjcC14ci1xb2UvIj5odHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXFvZS88L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRJU0NVU1M6PG86cD48L286cD48L3ByZT4NCjxw cmU+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPlRoZSBtZXRyaWMgbmFtZXMgaW4gdGhlIHJlZ2lzdHJ5IGFyZSBub3Qgc3Bl Y2lmaWMgZW5vdWdoOiBwYXlsb2FkIHR5cGUsPG86cD48L286cD48L3ByZT4NCjxwcmU+Y2FsY3Vs YXRpb24gaWRlbnRpZmllciBtZXRyaWMsIHNlZ21lbnQgdHlwZSwgYW5kIHBvdGVudGlhbGx5IE1P Uy4gSSBndWVzczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxkIHNheSBzb21ldGhp bmcgYWJvdXQgUlRQLiBMZXQgbWUgZmlsZSB0aGlzIERJU0NVU1Mgd2hpbGUgSTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmRvdWJsZS1jaGVjayB3aXRoIHRoZSBwZXJmb3JtYW5jZSBtZXRyaWMgZGly ZWN0b3JhdGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+LjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8F9A780D330094D99AF023C5877DABA43C7D58Fnkgeml501mbschi_-- From bill.wu@huawei.com Wed Feb 12 04:31:20 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5D1A0980 for ; Wed, 12 Feb 2014 04:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on4V8a4Omt9J for ; Wed, 12 Feb 2014 04:31:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1DA1A0824 for ; Wed, 12 Feb 2014 04:31:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBA84798; Wed, 12 Feb 2014 12:31:13 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 12:30:46 +0000 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Feb 2014 12:30:59 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Wed, 12 Feb 2014 20:30:55 +0800 From: Qin Wu To: "Suhas Nandakumar (snandaku)" , "pm-dir@ietf.org" Thread-Topic: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 Thread-Index: Ac8mPzDD/EQT52mhQhiNgBwBJKjcDAAMBZNMAF4CYHA= Date: Wed, 12 Feb 2014 12:30:54 +0000 Message-ID: References: <37D91FC30D69DE43B61E5EEADD959F180D07A601@xmb-aln-x12.cisco.com> In-Reply-To: <37D91FC30D69DE43B61E5EEADD959F180D07A601@xmb-aln-x12.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7DFFEnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Benoit Claise \(bclaise\)" , "MORTON, ALFRED C \(AL\)" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 12:31:20 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7DFFEnkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Suhas: Great, thanks for taking my proposed change for adding ten attributes. Regarding registering ten attributes, draft-ietf-mmusic-sdp-mux-attributes-= 00 Is not supposed to define any new attributes but simply references them def= ined in 3GPP document, categorizes and analyzes them. I don't know whether you should do this or what procedure you should follow= to register 3GPP owned attribute. However If you really like to do this, I think you need to update RFC6064 f= or 3GPP-QoE-Metrics attribute registry defined in http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-par= ameters-12 and replace it with these ten attributes as ten 3GPP QoE metrics registries= . Regards! -Qin From: Suhas Nandakumar (snandaku) [mailto:snandaku@cisco.com] Sent: Monday, February 10, 2014 11:12 PM To: Qin Wu; pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-at= tributes-00 Hello Qin Thanks for your inputs on the document. One general idea behind this draft was to define a generic framework for = categorizing multiplexing behavior of SDP attributes of today and of those = that will be defined in the future. Hence we started categorizing those that are registered with the IANA tod= ay as the reference. Regarding the RFC6064 QOE SDP attributes that are not registered with the= IANA, I will be happy to add those ten attributes to this document. Personally, i feel that these ten attributes must be registered with the = IANA to match the goals associated with this work. I would love to get your= thoughts on this. Cheers Suhas ________________________________ From: Qin Wu [bill.wu@huawei.com] Sent: Monday, February 10, 2014 1:05 AM To: Suhas Nandakumar (snandaku); pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attrib= utes-00 Hi, Author: I am assigned PM-DIR reviewer for this draft. Here is my review to this draft. This draft categorizes existing SDP attribute and provides an analysis for = the multiplexing characteristics of SDP attributes. Most of these SDP attributes is more about configuration parameters or nego= tiation parameters related to RTP session and have little to do with performance metrics reporting, Section 5.27 references to RFC3611 for RTCP-XR attribute, however it doesn'= t go into details to discuss how performance metrics related SDP parameters are signaled(e.g., by referencing XR BLOCK related R= FCs that have already been published) together with SDP attribute. So most guidelines of RFC6390 don't apply here. However section 5.38 does contain one performance metric, i.e., 3GPP-QoE-Me= trics. 3GPP-QoE- metrics is defined in Section 5.3.2.3.1 of 3GPP TS 26.234 and Section 4.6 of RFC6064 and is not a single metric but a= set of metrics. As described in section 11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10= Metrics, i.e., O Corruption duration metric, O Rebuffering duration metric, O Initial buffering duration metric, O Successive loss of RTP packets, O Frame rate deviation, O Jitter duration, O Content Switch Time, O Average Codec Bitrate, O Codec Information, O Buffer Status. Unfortunately RFC6064 didn't request IANA to register these ten metrics as = SDP attribute, only 3GPP-QoE-Metrics get registered by IANA. RFC6064 does define an 3GPP-QoE-Metrics Header to negotiate the usage of th= e QoE metrics and define 3GPP-QoE-Feedback Header carry QoE metrics from the client to the server when it reports, which happens either during or at the end of the media delivery. Therefore QoE metrics reporting is supported using 3GPP-QoE-Feedb= ack Header in the RFC6064. So it is obvious the above ten QoE metrics has already been defined in 3GP= P. Unfortunately there is no registration for these ten metrics. I am wondering whether these ten QoE metrics need to be registered by IANA,= who will be responsible for registering these ten QoE Metrics? Can 3GPP-QoE-Metrics in the table of section 5.38 be updated as follows in = the same way as what section 12.1 is described for content attribute: 3GPP-QoE-Metrics: Corruption duration Medi= a Level 3GPP-QoE-Metrics: Rebuffering duration Media= Level 3GPP-QoE-Metrics: Initial buffering duration Media= Level 3GPP-QoE-Metrics: Successive loss of RTP packets Media Level 3GPP-QoE-Metrics: Frame rate deviation Medi= a Level 3GPP-QoE-Metrics: Jitter duration = Media Level 3GPP-QoE-Metrics: Content Switch Time Sessio= n Level ...... Nits: s/m-mline/m-line s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA43C7DFFEnkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Suhas:<= /span>

Great, thanks for taki= ng my proposed change for adding ten attributes.

 

Regarding registering = ten attributes, draft-ietf-mmusic-sdp-mux-attributes-00

Is not supposed to def= ine any new attributes but simply references them defined in 3GPP document,= categorizes and analyzes them.

I don’t know whe= ther you should do this or what procedure you should follow to register 3GP= P owned attribute.

 

However If you really = like to do this, I think you need to update RFC6064 for 3GPP-QoE-Metrics at= tribute registry defined in

http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-pa= rameters-12

and replace it with th= ese ten attributes as ten 3GPP QoE metrics registries.

 

Regards!

-Qin=

From: Suhas Na= ndakumar (snandaku) [mailto:snandaku@cisco.com]
Sent: Monday, February 10, 2014 11:12 PM
To: Qin Wu; pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp= -mux-attributes-00

 

Hello Qin

 

  Thanks for your input= s on the document. 

 

  One general idea behi= nd this draft was to define a generic framework for categorizing multiplexi= ng behavior of SDP attributes of today and of those that will be defined in the future.

  Hence we started cate= gorizing those that are registered with the IANA today as the reference.&nb= sp;

 

  Regarding the RFC6064= QOE SDP attributes that are not registered with the IANA, I will be happy = to add those ten attributes to this document. 

  

  Personally, i feel th= at these ten attributes must be registered with the IANA to match the goals= associated with this work. I would love to get your thoughts on this.

 

Cheers

Suhas

From: Qin Wu [bill.wu@huawei.com]<= br> Sent: Monday, February 10, 2014 1:05 AM
To: Suhas Nandakumar (snandaku); pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux= -attributes-00

Hi, Author:

I am assigned PM-DIR rev= iewer for this draft.<= /p>

Here is my review to thi= s draft.

 

This draft categorizes e= xisting SDP attribute and provides an analysis for the multiplexing charact= eristics of SDP attributes.

Most of these SDP attrib= utes is more about configuration parameters or negotiation parameters relat= ed to RTP session and have little to

do with performance metr= ics reporting,

 

Section 5.27 references = to RFC3611 for RTCP-XR attribute, however it doesn’t go into details = to discuss how performance metrics

related SDP parameters a= re signaled(e.g., by referencing XR BLOCK related RFCs that have already be= en published) together

with SDP attribute. So m= ost guidelines of RFC6390 don’t apply here.

 

However section 5.38 doe= s contain one performance metric, i.e., 3GPP-QoE-Metrics.

3GPP-QoE- metrics is def= ined in Section 5.3.2.3.1 of<= /span>

3GPP TS 26.234 and Secti=
on 4.6 of RFC6064 and is not a single  metric but a set of metrics. 
As described in section =
11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10 Metrics, i.e.,
O Corruption duration me=
tric, 
O Rebuffering duration m=
etric,
O Initial buffering dura=
tion metric,
O Successive loss of RTP=
 packets,
O Frame rate deviation,<=
/span>
O Jitter duration,
O Content Switch Time,
O Average Codec Bitrate,=

O Codec Information,
O Buffer Status.<=
span style=3D"color:black">
 
Unfortunately RFC6064 di=
dn’t request IANA to register these ten metrics as SDP attribute, onl=
y 3GPP-QoE-Metrics  get registered by IANA.
 
RFC6064 does define an 3=
GPP-QoE-Metrics Header to negotiate the usage of the QoE metrics and=
 define 3GPP-QoE-Feedback Header
carry QoE metrics from t=
he client to the server when it
reports, which happens e=
ither during or at the end of the media<=
o:p>
delivery. Therefore QoE =
metrics reporting is supported using 3GPP-QoE-Feedback Header in the RFC606=
4.
 
So it is obvious  t=
he above ten QoE metrics has already been defined in 3GPP. Unfortunately th=
ere is no registration for these ten metrics.
 
I am wondering whether t=
hese ten QoE metrics need to be registered by IANA, who will be responsible=
 for registering these ten QoE Metrics?<=
o:p>
 
Can 3GPP-QoE-Metrics in =
the table of section 5.38 be updated as follows in the same way as what sec=
tion 12.1 is described for content attribute:
 
3GPP-QoE-Metrics: Corrup=
tion duration          &n=
bsp;            =
;           Media Level
3GPP-QoE-Metrics: Rebuff=
ering duration          &=
nbsp;           &nbs=
p;         Media Level
3GPP-QoE-Metrics: Initia=
l buffering duration         &=
nbsp;           &nbs=
p;    Media Level
3GPP-QoE-Metrics: Succes=
sive loss of RTP packets        &nb=
sp;       Media Level
3GPP-QoE-Metrics: Frame =
rate deviation          &=
nbsp;           &nbs=
p;          Media Level=

3GPP-QoE-Metrics: Jitter=
 duration           =
            &nb=
sp;            =
       Media Level
3GPP-QoE-Metrics: Conten=
t Switch Time          &n=
bsp;            =
;         Session Level
……
Nits:
s/m-mline/m-line<=
span style=3D"color:black">
s/3GPP-QoE-Metricsn/3GPP=
-QoE-Metrics         
 
Regards!
-Qin
--_000_B8F9A780D330094D99AF023C5877DABA43C7DFFEnkgeml501mbschi_-- From snandaku@cisco.com Wed Feb 12 09:01:38 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557881A08CE for ; Wed, 12 Feb 2014 09:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL_x7UHfhRsi for ; Wed, 12 Feb 2014 09:01:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 803161A04C6 for ; Wed, 12 Feb 2014 09:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29157; q=dns/txt; s=iport; t=1392224494; x=1393434094; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TDkl2rYAdX92C91aFCOQDsopbKG67ow3rH/ha7fE5a8=; b=E8HHZDvYDE5s+YzZXmv6P+t8CM7DdN6W+zccjJiEWRQimsoXNj/VPywz ddz9f/Jo0cXNq2FTjfeW8Ral7yyrlDnvIUjSf9UN7sDl6OwR9PIYYIuq0 recWe32gFlnzndN0qvw6ROaXenbUdQjq0/4h5CxXsaskvaPZpzItLZnBO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQFAJqn+1KtJV2a/2dsb2JhbABagkhEOFe/KIEVFnSCJQEBAQR5EAIBCA4DBAEBCxYBBgcyFAkIAQEEAQ0FCAGHfA3JXxeOSCcKBgGDJIEUBKpLgy2CKg X-IronPort-AV: E=Sophos;i="4.95,833,1384300800"; d="scan'208,217";a="303407903" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Feb 2014 17:01:33 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1CH1XNp025510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 17:01:33 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.234]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 11:01:33 -0600 From: "Suhas Nandakumar (snandaku)" To: Qin Wu , "pm-dir@ietf.org" Thread-Topic: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 Thread-Index: Ac8mPzDD/EQT52mhQhiNgBwBJKjcDAAMBZNMAF4CYHAACyh5tA== Date: Wed, 12 Feb 2014 17:01:32 +0000 Message-ID: <37D91FC30D69DE43B61E5EEADD959F180D07EC0C@xmb-aln-x12.cisco.com> References: <37D91FC30D69DE43B61E5EEADD959F180D07A601@xmb-aln-x12.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.186] Content-Type: multipart/alternative; boundary="_000_37D91FC30D69DE43B61E5EEADD959F180D07EC0Cxmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 12 Feb 2014 09:15:21 -0800 Cc: "Benoit Claise \(bclaise\)" , "MORTON, ALFRED C \(AL\)" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attributes-00 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:01:38 -0000 --_000_37D91FC30D69DE43B61E5EEADD959F180D07EC0Cxmbalnx12ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Qin for your inputs. I will post an updated version of the draft-iet= f-mmusic-sdp-mux-attributes-00 with the changes below. Cheers Suhas ________________________________ From: Qin Wu [bill.wu@huawei.com] Sent: Wednesday, February 12, 2014 4:30 AM To: Suhas Nandakumar (snandaku); pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-at= tributes-00 Hi, Suhas: Great, thanks for taking my proposed change for adding ten attributes. Regarding registering ten attributes, draft-ietf-mmusic-sdp-mux-attributes-= 00 Is not supposed to define any new attributes but simply references them def= ined in 3GPP document, categorizes and analyzes them. I don=92t know whether you should do this or what procedure you should foll= ow to register 3GPP owned attribute. However If you really like to do this, I think you need to update RFC6064 f= or 3GPP-QoE-Metrics attribute registry defined in http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-par= ameters-12 and replace it with these ten attributes as ten 3GPP QoE metrics registries= . Regards! -Qin From: Suhas Nandakumar (snandaku) [mailto:snandaku@cisco.com] Sent: Monday, February 10, 2014 11:12 PM To: Qin Wu; pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-at= tributes-00 Hello Qin Thanks for your inputs on the document. One general idea behind this draft was to define a generic framework for = categorizing multiplexing behavior of SDP attributes of today and of those = that will be defined in the future. Hence we started categorizing those that are registered with the IANA tod= ay as the reference. Regarding the RFC6064 QOE SDP attributes that are not registered with the= IANA, I will be happy to add those ten attributes to this document. Personally, i feel that these ten attributes must be registered with the = IANA to match the goals associated with this work. I would love to get your= thoughts on this. Cheers Suhas ________________________________ From: Qin Wu [bill.wu@huawei.com] Sent: Monday, February 10, 2014 1:05 AM To: Suhas Nandakumar (snandaku); pm-dir@ietf.org Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise) Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux-attrib= utes-00 Hi, Author: I am assigned PM-DIR reviewer for this draft. Here is my review to this draft. This draft categorizes existing SDP attribute and provides an analysis for = the multiplexing characteristics of SDP attributes. Most of these SDP attributes is more about configuration parameters or nego= tiation parameters related to RTP session and have little to do with performance metrics reporting, Section 5.27 references to RFC3611 for RTCP-XR attribute, however it doesn= =92t go into details to discuss how performance metrics related SDP parameters are signaled(e.g., by referencing XR BLOCK related R= FCs that have already been published) together with SDP attribute. So most guidelines of RFC6390 don=92t apply here. However section 5.38 does contain one performance metric, i.e., 3GPP-QoE-Me= trics. 3GPP-QoE- metrics is defined in Section 5.3.2.3.1 of 3GPP TS 26.234 and Section 4.6 of RFC6064 and is not a single metric but a= set of metrics. As described in section 11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10= Metrics, i.e., O Corruption duration metric, O Rebuffering duration metric, O Initial buffering duration metric, O Successive loss of RTP packets, O Frame rate deviation, O Jitter duration, O Content Switch Time, O Average Codec Bitrate, O Codec Information, O Buffer Status. Unfortunately RFC6064 didn=92t request IANA to register these ten metrics a= s SDP attribute, only 3GPP-QoE-Metrics get registered by IANA. RFC6064 does define an 3GPP-QoE-Metrics Header to negotiate the usage of th= e QoE metrics and define 3GPP-QoE-Feedback Header carry QoE metrics from the client to the server when it reports, which happens either during or at the end of the media delivery. Therefore QoE metrics reporting is supported using 3GPP-QoE-Feedb= ack Header in the RFC6064. So it is obvious the above ten QoE metrics has already been defined in 3GP= P. Unfortunately there is no registration for these ten metrics. I am wondering whether these ten QoE metrics need to be registered by IANA,= who will be responsible for registering these ten QoE Metrics? Can 3GPP-QoE-Metrics in the table of section 5.38 be updated as follows in = the same way as what section 12.1 is described for content attribute: 3GPP-QoE-Metrics: Corruption duration Medi= a Level 3GPP-QoE-Metrics: Rebuffering duration Media= Level 3GPP-QoE-Metrics: Initial buffering duration Media= Level 3GPP-QoE-Metrics: Successive loss of RTP packets Media Level 3GPP-QoE-Metrics: Frame rate deviation Medi= a Level 3GPP-QoE-Metrics: Jitter duration = Media Level 3GPP-QoE-Metrics: Content Switch Time Sessio= n Level =85=85 Nits: s/m-mline/m-line s/3GPP-QoE-Metricsn/3GPP-QoE-Metrics Regards! -Qin --_000_37D91FC30D69DE43B61E5EEADD959F180D07EC0Cxmbalnx12ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Thanks Qin for your inputs. I will post an updated version of the&nb= sp;draft-ietf-mmusic-sdp-mux-attributes-00 with the changes below.

Cheers
Suhas
From: Qin Wu [bill.wu@huawei.com]
Sent: Wednesday, February 12, 2014 4:30 AM
To: Suhas Nandakumar (snandaku); pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp= -mux-attributes-00

Hi, Suhas:

Great, thanks for taki= ng my proposed change for adding ten attributes.

 

Regarding registering = ten attributes, draft-ietf-mmusic-sdp-mux-attributes-00

Is not supposed to def= ine any new attributes but simply references them defined in 3GPP document,= categorizes and analyzes them.

I don=92t know whether= you should do this or what procedure you should follow to register 3GPP ow= ned attribute.

 

However If you really = like to do this, I think you need to update RFC6064 for 3GPP-QoE-Metrics at= tribute registry defined in

http://www.iana.org/assignments/sdp-parameters/sdp-param= eters.xhtml#sdp-parameters-12

and replace it with th= ese ten attributes as ten 3GPP QoE metrics registries.

 

Regards!

-Qin

From: Suhas = Nandakumar (snandaku) [mailto:snandaku@cisco.com]
Sent: Monday, February 10, 2014 11:12 PM
To: Qin Wu; pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: RE: Request for an RFC 6390 review of draft-ietf-mmusic-sdp= -mux-attributes-00

 

Hello Qin

 

  Thanks for your inp= uts on the document. 

 

  One general idea be= hind this draft was to define a generic framework for categorizing multiple= xing behavior of SDP attributes of today and of those that will be defined in the future.

  Hence we started ca= tegorizing those that are registered with the IANA today as the reference.&= nbsp;

 

  Regarding the RFC60= 64 QOE SDP attributes that are not registered with the IANA, I will be happ= y to add those ten attributes to this document. 

  

  Personally, i feel = that these ten attributes must be registered with the IANA to match the goa= ls associated with this work. I would love to get your thoughts on this.

 

Cheers

Suhas

From: Qin Wu [bill.wu@huawei.c= om]
Sent: Monday, February 10, 2014 1:05 AM
To: Suhas Nandakumar (snandaku); pm-dir@ietf.org
Cc: MORTON, ALFRED C (AL); Benoit Claise (bclaise)
Subject: Request for an RFC 6390 review of draft-ietf-mmusic-sdp-mux= -attributes-00

Hi, Author:

I am assigned PM-DIR r= eviewer for this draft.

Here is my review to t= his draft.

 

This draft categorizes= existing SDP attribute and provides an analysis for the multiplexing chara= cteristics of SDP attributes.

Most of these SDP attr= ibutes is more about configuration parameters or negotiation parameters rel= ated to RTP session and have little to

do with performance me= trics reporting,

 

Section 5.27 reference= s to RFC3611 for RTCP-XR attribute, however it doesn=92t go into details to= discuss how performance metrics

related SDP parameters= are signaled(e.g., by referencing XR BLOCK related RFCs that have already = been published) together

with SDP attribute. So= most guidelines of RFC6390 don=92t apply here.

 

However section 5.38 d= oes contain one performance metric, i.e., 3GPP-QoE-Metrics.

3GPP-QoE- metrics is d= efined in Section 5.3.2.3.1 of 

3GPP TS 26.234 and Sect=
ion 4.6 of RFC6064 and is not a single  metric but a set of metrics. <=
/span>
As described in section=
 11.2 of 3GPP TS 26.234, 3GPP QoE Metrics include 10 Metrics, i.e.,<=
span style=3D"color:black">
O Corruption duration m=
etric, 
O Rebuffering duration =
metric,
O Initial buffering dur=
ation metric,
O Successive loss of RT=
P packets,
O Frame rate deviation,=

O Jitter duration,
O Content Switch Time,<=
/span>
O Average Codec Bitrate=
,
O Codec Information,
O Buffer Status.=

 
Unfortunately RFC6064 d=
idn=92t request IANA to register these ten metrics as SDP attribute, only 3=
GPP-QoE-Metrics  get registered by IANA.
 
RFC6064 does define an =
3GPP-QoE-Metrics Header to negotiate the usage of the QoE metrics an=
d define 3GPP-QoE-Feedback Header=

carry QoE metrics from =
the client to the server when it<=
/pre>

reports, which happens =
either during or at the end of the media=



delivery. Therefore QoE=
 metrics reporting is supported using 3GPP-QoE-Feedback Header in the RFC60=
64.


 


So it is obvious  =
the above ten QoE metrics has already been defined in 3GPP. Unfortunately t=
here is no registration for these ten metrics.


 


I am wondering whether =
these ten QoE metrics need to be registered by IANA, who will be responsibl=
e for registering these ten QoE Metrics?=



 


Can 3GPP-QoE-Metrics in=
 the table of section 5.38 be updated as follows in the same way as what se=
ction 12.1 is described for content attribute:


 


3GPP-QoE-Metrics: Corru=
ption duration          &=
nbsp;           &nbs=
p;           Media Level<=
/span>


3GPP-QoE-Metrics: Rebuf=
fering duration          =
            &nb=
sp;         Media Level


3GPP-QoE-Metrics: Initi=
al buffering duration         =
            &nb=
sp;    Media Level=



3GPP-QoE-Metrics: Succe=
ssive loss of RTP packets        &n=
bsp;       Media Level


3GPP-QoE-Metrics: Frame=
 rate deviation          =
            &nb=
sp;          Media Level


3GPP-QoE-Metrics: Jitte=
r duration           =
;            &n=
bsp;            =
;       Media Level


3GPP-QoE-Metrics: Conte=
nt Switch Time          &=
nbsp;           &nbs=
p;         Session Level


=85=85


Nits:


s/m-mline/m-line=



s/3GPP-QoE-Metricsn/3GP=
P-QoE-Metrics         


 


Regards!


-Qin
--_000_37D91FC30D69DE43B61E5EEADD959F180D07EC0Cxmbalnx12ciscoc_-- From nobody Thu Feb 13 10:29:27 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D068F1A0396 for ; Thu, 13 Feb 2014 09:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EduojehEKVx3 for ; Thu, 13 Feb 2014 09:42:01 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 358FC1A02F5 for ; Thu, 13 Feb 2014 09:42:01 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1DHftki004760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 11:41:57 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DHfJvR015056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 18:41:54 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 18:41:32 +0100 From: "Scharf, Michael (Michael)" To: Vinayak Hegde Thread-Topic: Performance directorate review of draft-ietf-alto-deployments Thread-Index: AQHOuD/udJ9PdAngME6QKDnjb9ct7Zq0UCZQ Date: Thu, 13 Feb 2014 17:41:32 +0000 Message-ID: <655C07320163294895BBADA28372AF5D1E4E44@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D0BEB38@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D1E4E44FR712WXCHMBA15zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/xPP8Km9m6zNGAxhq1JrIuAU0uwc X-Mailman-Approved-At: Thu, 13 Feb 2014 10:29:26 -0800 Cc: "sprevidi@cisco.com" , Enrico Marocco , "Gurbani, Vijay K \(Vijay\)" , "martin.stiemerling@neclab.eu" , "ietf-alto@skiesel.de" , "pm-dir@ietf.org" Subject: Re: [pm-dir] Performance directorate review of draft-ietf-alto-deployments X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:42:07 -0000 --_000_655C07320163294895BBADA28372AF5D1E4E44FR712WXCHMBA15zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vinayak, Finally, I found some cycles to re-write the section you flagged. I first w= anted to mostly remove the content, but since draft-ietf-alto-protocol incl= udes a reference to this content, I tried instead to rewrite the section to= illustrate the high-level idea, whithout going into details (which would p= robably require another draft). The new text states very explicitly that it= does not intend to formally specify any measurement method or metric. The = new text can be found here: http://tools.ietf.org/html/draft-ietf-alto-deployments-09#section-3.4 Please let me know if I missed something or if you have suggestions for fur= ther improvement. Thanks Michael From: Vinayak Hegde [mailto:vinayakh@gmail.com] Sent: Monday, September 23, 2013 11:33 AM To: Scharf, Michael (Michael) Cc: martin.stiemerling@neclab.eu; ietf-alto@skiesel.de; sprevidi@cisco.com;= pm-dir@ietf.org Subject: Re: Performance directorate review of draft-ietf-alto-deployments On Fri, Sep 13, 2013 at 6:50 PM, Scharf, Michael (Michael) > wrote: [snipped] Thanks again! You are welcome. Comments inline. ________________________________ From: Vinayak Hegde [mailto:vinayakh@gmail.com] Sent: Saturday, September 07, 2013 6:23 PM To: martin.stiemerling@neclab.eu; ietf= -alto@skiesel.de; sprevidi@cisco.com; Scharf, Michael (Michael) Cc: pm-dir@ietf.org Subject: Performance directorate review of draft-ietf-alto-deployments Hi, There was a performance review either requested by you or was triggered by = Benoit's script. I am reviewing this from a performance metrics point of vi= ew. I looked at the draft (https://datatracker.ietf.org/doc/draft-ietf-alto-dep= loyments/?include_text=3D1) These comments are only on the Section 6.3 Moni= toring ALTO Comments on Section 6.3 The authors should define some recommended metrics here (possibly IPPM Type= -P metrics) if not recommended metric here. This section can be substantial= ly expanded. [MS] I am not sure if this document should really formally define metrics (= the current wording implies that). The more important aspect seems to me th= e overall effects that an operator may want to look at when deploying ALTO.= This significantly differs between different use cases of ALTO. For instan= ce, if ALTO is used for traffic optimization inside one AS, monitoring a me= tric that describes inter-domain traffic may not be required. Therefore, th= e relevant metrics will depend on the use case, as also noted in your revie= w. An alternative document structure would have some discussion of monitori= ng per use case, but this would imply a significant change of the table of = content of the document. We currently look into this, but this requires fee= dback from the ALTO WG, too. Yeah a couple of use-cases would really help though it is bit more work. It= would make the document more complete and usable for implementers. Comments on section 6.3.1 There are several metrics defined here but they can be more clearly defined= by following the formats specified in RFC 6390. Also useful will some use-= cases to explain why these metrics make sense and what needs to be used in = which scenario. [MS] Agreed. As I said, one potential solution is to move this discussion t= o the descriptions of the use cases (Section 4, 5, etc.), maybe with one "m= onitoring" subsection per use-case. Yup. Agree. Makes sense. As regards to the network hop-count to be used indirectly for latency, it m= ight be better to define a different metric for latency as the average netw= ork loads and buffers on each device can be radically different. For exampl= e a hybrid network that contains a backbone network, last mile access netw= ork and a mobile network (which is not unusual in many ISPs today). The del= ay for transit (as well as packet loss) internally from one to other might = be drastically different. [MS] I agree that hop-count and latency may not correlate. Also, measuring = hop-count can be difficult in some cases. If the Internet traffic is carrie= d over an MPLS/IP aggregation/core network, the number of routers that are = traversed by the traffic can be pretty different to the number of IP hops. = Reducing the IP hops does not necessarily imply a more efficient routing. M= y current thinking is that the document should more focus on "traffic local= ity" than path monitoring metrics. Agree. Makes sense. Can you reword the mentioned paragraph ? Section 6.3.3 The example given here can be expanded to give a more clearer picture of wh= ich are the active monitoring agents and which are the passive components. = The metrics used for monitoring need to standardized. Also you might want t= o add some recommendation on the data interchange format and method of deli= very. This is especially important as the interacting entities (ISP and App= lication Owner) are present at different layers and have different prioriti= es.This can also be fixed in section 6.3.1 above. [MS] Yes, the text and Figure 19 describes the scenario at a very high-leve= l and, indeed, it is not clear. Both the question what somebody can measure= , and whether this is done actively or passively, depends on the use case a= nd who that entity actually is. But I don't believe that this document can = provide comprehensive guidance on data exchange formats and methods of deli= very, because inter-organization communication raises a lot of non-technica= l issues, and even standardization of new protocols might be needed. That s= eems outside the scope of this document specifically, and ALTO in general. = This seems more related to LMAP. The document need not be comprehensive. That was not the intention of the s= uggestion. But non-normative language about possible measures / metrics cou= ld be useful for guidance. Data interchange formats such as JSON could be u= sed for easy parsing instead of binary serialisation. -- Vinayak --_000_655C07320163294895BBADA28372AF5D1E4E44FR712WXCHMBA15zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vinayak,

 <= /p>

Finally, I= found some cycles to re-write the section you flagged. I first wanted to m= ostly remove the content, but since draft-ietf-alto-protocol includes a reference to this content, I tried instead to rewrite the secti= on to illustrate the high-level idea, whithout going into details (which wo= uld probably require another draft). The new text states very explicitly th= at it does not intend to formally specify any measurement method or metric. The new text can be found here:<= o:p>

 = ;

http://tools.ietf.org/htm= l/draft-ietf-alto-deployments-09#section-3.4

 <= /p>

Please let= me know if I missed something or if you have suggestions for further impro= vement.

 = ;

Thanks

 = ;

Michael

 = ;

 = ;

 = ;

From: Vinayak = Hegde [mailto:vinayakh@gmail.com]
Sent: Monday, September 23, 2013 11:33 AM
To: Scharf, Michael (Michael)
Cc: martin.stiemerling@neclab.eu; ietf-alto@skiesel.de; sprevidi@cis= co.com; pm-dir@ietf.org
Subject: Re: Performance directorate review of draft-ietf-alto-deplo= yments

 

On Fri, Sep 13, 2013 at 6:50 PM, Scharf, Michael (Mi= chael) <michael.scharf@alcatel-lucent.com> wrote:

[snipped] 

Thanks again!

 

 

You are welcome. Comments inline.

From: Vinayak Heg= de [mailto:vinayakh= @gmail.com]
Sent: Saturday, September 07, 2013 6:23 PM
To: martin.stiemerling@neclab.eu; ietf-alto@skiesel= .de; sprevidi@cisco.com; Scharf, Michael (Michael)
Cc: pm-dir@ietf= .org
Subject: Performance directorate review of draft-ietf-alto-deploymen= ts

Hi,

There was a performan= ce review either requested by you or was triggered by Benoit's script. I am= reviewing this from a performance metrics point of view.

I looked at the draft= (https://datatracker.ietf.org/doc/draft-= ietf-alto-deployments/?include_text=3D1) These comments are only on the Section 6.3 Monitoring ALTO

Comments on Section 6.3

The authors should define some recommended metrics h= ere (possibly IPPM Type-P metrics) if not recommended metric here. This sec= tion can be substantially expanded.
 

[MS] I am not sure if this document shou= ld really formally define metrics (the current wording implies that). The m= ore important aspect seems to me the overall effects that an operator may want to look at when deploying ALTO. This significantly di= ffers between different use cases of ALTO. For instance, if ALTO is us= ed for traffic optimization inside one AS, monitoring a metr= ic that describes inter-domain traffic may not be required. = Therefore, the relevant metrics will depend on the use case, as also noted in your re= view. An alternative document structure would have some discussion of monit= oring per use case, but this would imply a significant change of the t= able of content of the document. We currently look into this, but this requires feedback from the ALTO WG, too= .

Yeah a couple of use-cases would really help though = it is bit more work. It would make the document more complete and usable fo= r implementers.

 

Comments on section 6.3.1

There are several metrics defined here but they can = be more clearly defined by following the formats specified in RFC 6390. Als= o useful will some use-cases to explain why these metrics make sense and wh= at needs to be used in which scenario.
 

[MS] Agreed. As I said, one potential so= lution is to move this discussion to the descriptions of the use cases (Sec= tion 4, 5, etc.), maybe with one "monitoring" subsection per use-case.

 

Yup. Agree. Makes sense.

 

As regards to the network hop-count to be used indir= ectly for latency, it might be better to define a different metric for late= ncy as the average network loads and buffers on each device can be radicall= y different. For example a hybrid network that contains  a backbone network, last mile access network a= nd a mobile network (which is not unusual in many ISPs today). The delay fo= r transit (as well as packet loss) internally from one to other might be dr= astically different.
 

[MS] I agree that hop-count and latency = may not correlate. Also, measuring hop-count can be difficult in some cases= . If the Internet traffic is carried over an MPLS/IP aggregation/core network, the number of routers that are traversed by the traffic can be pr= etty different to the number of IP hops. Reducing the IP hops does not nece= ssarily imply a more efficient routing. My current thinking is that the doc= ument should more focus on "traffic locality" than path monitoring metrics.

 

Agree. Makes sense. Can you reword the mentioned par= agraph ?

Section 6.3.3

The example given here can be expanded to give a mor= e clearer picture of which are the active monitoring agents and which are t= he passive components. The metrics used for monitoring need to standardized= . Also you might want to add some recommendation on the data interchange format and method of delivery. This= is especially important as the interacting entities (ISP and Application O= wner) are present at different layers and have different priorities.This ca= n also be fixed in section 6.3.1 above.
 

[MS] Yes, the text and Figure 19 describ= es the scenario at a very high-level and, indeed, it is not clear. Bot= h the question what somebody can measure, and whether this is done actively or passively, depends on the use case and who that entity ac= tually is. But I don't believe that this document can provide com= prehensive guidance on data exchange formats and methods of delivery, = because inter-organization communication raises a lot of non-technical issues, and even standardization of new protocols m= ight be needed. That seems outside the scope of this document specifically,= and ALTO in general. This seems more related to LMAP.

 

The document need not= be comprehensive. That was not the intention of the suggestion. But non-no= rmative language about possible measures / metrics could be useful for guid= ance. Data interchange formats such as JSON could be used for easy parsing instead of binary serialisation.

-- Vinayak

--_000_655C07320163294895BBADA28372AF5D1E4E44FR712WXCHMBA15zeu_-- From nobody Fri Feb 14 02:44:29 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD3A1A0202 for ; Fri, 14 Feb 2014 02:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiETSmxYQi_z for ; Fri, 14 Feb 2014 02:44:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 989DD1A0201 for ; Fri, 14 Feb 2014 02:44:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD09467; Fri, 14 Feb 2014 10:44:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 10:43:15 +0000 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 10:44:18 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 14 Feb 2014 18:44:07 +0800 From: Qin Wu To: Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Thread-Topic: Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: Ac8pca6eWa5s6xYeSnOXZFCh5wWZBw== Date: Fri, 14 Feb 2014 10:44:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C7F994nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/DkDFkfyq-0Bzq5COeZxUu16dpxU Cc: "pm-dir@ietf.org" Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 10:44:27 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C7F994nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin ________________________________ --_000_B8F9A780D330094D99AF023C5877DABA43C7F994nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, authors:

I am assigned Perfo= rmance Directorate reviewer for this draft.

Here is my review t= o this draft.

 

This draft uses the= link latency, latency variation and packet loss information for end to end= path selection.

The link latency, l= atency variation and packet loss metrics are defined in OSPF-TE draft and I= SIS-TE draft and

used to calculate p= ath metrics described in this draft, e.g., P2P latency metric, P2P latency = variation metric, packet loss

metric, P2MP latenc= y metric, P2MP latency variation metric.

 

These calculated pa= th metrics( 6 metrics) are carried in PCEP message using the same Metric Ob= ject with different metric type. 

The calculated metr= ics are used as constraint for path computation

 

In this draft, each= calculated metric is discussed in each separate section from metric name, = metric description

perspective to meas= urement unit, calculation method perspective.

IANA is also reques= ted to register these 6 metric types. Therefore I believe this draft confor= ms to RFC6390 guideline.

However I have a fe= w comments regarding these metrics definitions.

1. Section 4, 2<= sup>nd paragraph says:

“<= /span>

   This d= ocument defines the following optional types for the METRIC

   object= defined in [RFC5440].

”<= /span>

s/defined in [= RFC5440]/defined in section 7.4 of [RFC5440]

 

2. Section 4.1 s= ays:

“<= /span>

   Link d= elay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-= TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP

   encode= s the sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

 

   - A Li= nk delay metric of link L is denoted D(L).

 

   - A P2= P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.

 

   * T=3D= 13(TBA - IANA): Latency metric

”<= /span>

For people who are = not familiar with Metrics Object Format, it is not easy to figure out what = T=3D13 stands for? Would it be good to add some context text or<= /span>

Introduce Metric Ob= ject format first.

 

 

3. Section 4.2 s= ays:

“<= /span>

   - A La= tency variation of link L is denoted DV(L).

 

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),=

   (i=3D1= ...K)}.

”<= /span>

Why not sum of late= ncy variation metrics of individual links?

 

4. Section 4.2 s= ays:

“<= /span>

Specification of th= e "Function" used to drive latency variation

metric of a path fr= om latency variation metrics of individual links

along the path is b= eyond the scope of this document.

”<= /span>

s/drive/derive=

 

5. Section 4

Section 4.3 says:

“Packet Loss = Metric metric type of METRIC Object”

Section 4.2 says:

“P2P latency = variation metric type of METRIC

   Object= ”

For consistency, yo= u may either use “xx Metric metric type” or “xx metric ty= pe of Metric Object”.

 

6.Section 4.3 sa= ys:

“<= /span>

   The en= d to end Packet Loss for the path is represented by this<= /p>

   metric= .

 

   - A Pa= cket loss of link L is denoted PL(L).

 

   - A P2= P packet loss metric for the Path P =3D function {PL(Lpi),

   (i=3D1= ...K)}.

”<= /span>

Is function of pack= et loss metric of individual link same as function of latency variation met= ric of individual link?

If they are not sam= e, please use different function name, e.g., function a for packet loss, fu= nction b for latency variation?

 

Regards!=

-Qin

 

 

 

 

--_000_B8F9A780D330094D99AF023C5877DABA43C7F994nkgeml501mbschi_-- From nobody Fri Feb 14 06:20:25 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9041A0262 for ; Fri, 14 Feb 2014 06:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.552 X-Spam-Level: ** X-Spam-Status: No, score=2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_T7Oimhn225 for ; Fri, 14 Feb 2014 06:20:20 -0800 (PST) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0E31A025C for ; Fri, 14 Feb 2014 06:20:20 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-red.research.att.com (Postfix) with ESMTP id 948C95543BD; Fri, 14 Feb 2014 09:23:51 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id A7F39E0374; Fri, 14 Feb 2014 09:20:18 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 14 Feb 2014 09:20:18 -0500 From: "MORTON, ALFRED C (AL)" To: Qin Wu , Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Date: Fri, 14 Feb 2014 09:20:17 -0500 Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: Ac8pca6eWa5s6xYeSnOXZFCh5wWZBwAHJbQQ Message-ID: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8BC5B99F5njfpsrvexg8rese_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/1CEUSCwYOlYMNJwX_RVm9Avh3Zs Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 14:20:24 -0000 --_000_2845723087023D4CB5114223779FA9C8BC5B99F5njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; = ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin --_000_2845723087023D4CB5114223779FA9C8BC5B99F5njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A few additional comments, we ca= n help the authors a bit more

I think, but Qin wa= s on the right track.

 

Al

 

Qin wro= te:

3. Section 4.2 says:

<= span style=3D'font-size:12.0pt'>“

   - A Latency variation = of link L is denoted DV(L).

 

   - A P2P latency variation m= etric for the Path P =3D function {DV(Lpi),

   (i=3D1...K)}.

&#= 8221;

Why not sum of latency variation metrics of individual links?

-------------------------------------------------------<= o:p>

 

= Sum is a rather = worst-case approximation of the Path DV.

&nb= sp;

We have studied these sorts of e2e Path estimates = in IPPM.

Packet Delay Variation is the most compl= ex, but a couple of

possibilities for "fun= ction" are specified here:

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>http://tools.ietf.org/html/rfc6049#pa= ge-20

 

Simila= rly, we have functions, which could be cited as references

in this draft, for loss

http://tools.ietf.org/html/rfc6049#= page-18

 

and= for mean delay

http://tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to= leave the "function" unspecified and out of scope,

assuming your loss and delay metric definitions are compatible= .

 

 

 

 

 

Hi, authors:

I am assigned Performance Directorate reviewer for this d= raft.

Here is my review to this draft.

 

This draft uses the link late= ncy, latency variation and packet loss information for end to end path sele= ction.

The link latency, latency variation and packet loss metrics are def= ined in OSPF-TE draft and ISIS-TE draft and

used to calculate path metric= s described in this draft, e.g., P2P latency metric, P2P latency variation = metric, packet loss

metric, P2MP latency metric, P2MP latency variation m= etric.

 

These calculated path metrics( 6 metrics) are carried in PCE= P message using the same Metric Object with different metric type. 

T= he calculated metrics are used as constraint for path computation

&nb= sp;

I= n this draft, each calculated metric is discussed in each separate section = from metric name, metric description

perspective to measurement unit, calc= ulation method perspective.

IANA is also requested to register these 6 metr= ic types. Therefore I believe this draft conforms to RFC6390 guideline.

How= ever I have a few comments regarding these metrics definitions.<= /span>

1. Secti= on 4, 2nd paragraph says:

“

   This document= defines the following optional types for the METRIC

<= p class=3DMsoNormal>   object de= fined in [RFC5440].

”

s/defined in [RFC5440]/defined in sectio= n 7.4 of [RFC5440]

 

2. Section 4.1 says:

=

“

   = Link delay metric is defined in [OSPF-TE-EXPRESS] and

=

   [ISIS-TE= -EXPRESS].  P2P latency metric type of METRIC object in PCEP

 &nb= sp; encodes the sum of the link delay metric of all links along a P2P<= /o:p>

 = ;  Path.  Specifically, extending on the above mentioned terminol= ogy:

 

   - A Link delay metric of link L is denoted D(L).

<= o:p> 

   - A P2P latency metric for the Path P =3D Sum {D(Lpi), (= i=3D1...K)}.

 

   * T=3D13(TBA - IANA): Latency metric

= 221;

For people who are not familiar with Metrics Object Format, it is not = easy to figure out what T=3D13 stands for? Would it be good to add some con= text text or

Introduce Metric Object format first.

 

&n= bsp;

3. Section 4.2 says:

<= span style=3D'font-size:12.0pt'>“

   - A Latency variation = of link L is denoted DV(L).

 

   - A P2P latency variation m= etric for the Path P =3D function {DV(Lpi),

   (i=3D1...K)}.

&#= 8221;

Why not sum of latency variation metrics of individual links?

&n= bsp;

4. Section 4.2 says:

“

Specification of the "Function&quo= t; used to drive latency variation

metric of a path from latency variation = metrics of individual links

along the path is beyond the scope of this docu= ment.

”

s/drive/derive

 

5. Section 4

Section 4.3 says:

&= #8220;Packet Loss Metric metric type of METRIC Object”

Section 4.2 sa= ys:

“P2P latency variation metric type of METRIC

   Object&= #8221;

For consistency, you may either use “xx Metric metric typeR= 21; or “xx metric type of Metric Object”.

=

 

6.Section 4= .3 says:

“

   The end to end Packet Loss for the path = is represented by this

   metric.

 

<= p class=3DMsoNormal>   - A Packe= t loss of link L is denoted PL(L).

 

   - A P2P packet loss = metric for the Path P =3D function {PL(Lpi),

   (i=3D1...K)}.

&#= 8221;

Is function of packet loss metric of individual link same as function= of latency variation metric of individual link?

If they are not same, plea= se use different function name, e.g., function a for packet loss, function = b for latency variation?

 

<= span style=3D'font-size:12.0pt'>Regards!

-Qin

<= o:p> 

 

 

 

= --_000_2845723087023D4CB5114223779FA9C8BC5B99F5njfpsrvexg8rese_-- From nobody Fri Feb 14 06:25:45 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7471A0209 for ; Fri, 14 Feb 2014 05:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-D28fRp2s8B for ; Fri, 14 Feb 2014 05:09:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 635F21A00FB for ; Fri, 14 Feb 2014 05:09:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDP01901; Fri, 14 Feb 2014 13:08:58 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 13:07:53 +0000 Received: from LGGEML413-HUB.china.huawei.com (10.72.61.116) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Feb 2014 13:08:56 +0000 Received: from HTIPL8571 (10.195.41.214) by lggeml413-hub.china.huawei.com (10.72.61.116) with Microsoft SMTP Server id 14.3.158.1; Fri, 14 Feb 2014 21:08:36 +0800 From: Dhruv Dhody To: "'Qin Wu'" References: In-Reply-To: Date: Fri, 14 Feb 2014 18:38:22 +0530 Message-ID: <019a01cf2985$daf3e580$90dbb080$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_019B_01CF29B3.F4AC2180" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8pca6eWa5s6xYeSnOXZFCh5wWZBwAC+mNg Content-Language: en-us X-Originating-IP: [10.195.41.214] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/KS2a5zFd1X-sHVRYCjBmSQSntwM X-Mailman-Approved-At: Fri, 14 Feb 2014 06:25:43 -0800 Cc: dhruv.ietf@gmail.com, vishwas.manral@hp.com, vishwas.ietf@gmail.com, swallow@cisco.com, pm-dir@ietf.org, zali@cisco.com, ke-kumaki@kddi.com Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:09:06 -0000 ------=_NextPart_000_019B_01CF29B3.F4AC2180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_019C_01CF29B3.F4AD32F0" ------=_NextPart_001_019C_01CF29B3.F4AD32F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Qin, Thanks for your review of our document. Comments inline and diff file attached. I will also get confirmation from co-authors and contributors if they are okay with these changes. From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 4:14 PM To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss information for end to end path selection. The link latency, latency variation and packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency metric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believe this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] [DhruvDhody>] Okay, But Metric section is 7.8 in RFC5440 http://tools.ietf.org/html/rfc5440#section-7.8 :) 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. * T=13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy to figure out what T=13 stands for? Would it be good to add some context text or Introduce Metric Object format first. [DhruvDhody>] Done! Check the diff file attached if this is acceptable to you. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P = function {DV(Lpi), (i=1...K)}. " Why not sum of latency variation metrics of individual links? [DhruvDhody>] Making it a sum and aligning to http://tools.ietf.org/html/draft-ietf-mpls-te-express-path-00#section-2.1 Is not a bad idea in my opinion. I need to discuss further with my co-authors, if there is any objection to that. 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive [DhruvDhody>] sentence removed. 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric type of Metric Object". [DhruvDhody>] Done! 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P = function {PL(Lpi), (i=1...K)}. " Is function of packet loss metric of individual link same as function of latency variation metric of individual link? If they are not same, please use different function name, e.g., function a for packet loss, function b for latency variation? [DhruvDhody>] I have updated this, please check the diff. Regards, Dhruv Regards! -Qin ------=_NextPart_001_019C_01CF29B3.F4AD32F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin,

 

Thanks for your review of our document.  Comments inline and = diff file attached.

I will also get confirmation from co-authors and contributors if they = are okay with these changes.  

 

From:= = Qin Wu [mailto:bill.wu@huawei.com]
Sent: Friday, February 14, = 2014 4:14 PM
To: Dhruv Dhody; vishwas.manral@hp.com; = zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: = pm-dir@ietf.org
Subject: Request for an RFC 6390 review of = draft-ietf-pce-pcep-service-aware-02

 

Hi, authors:

I am assigned = Performance Directorate reviewer for this draft.

Here is my review to = this draft.

 

This draft uses the = link latency, latency variation and packet loss information for end to = end path selection.

The link latency, latency variation and = packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and =

used to calculate path metrics described in = this draft, e.g., P2P latency metric, P2P latency variation metric, = packet loss

metric, P2MP latency metric, P2MP latency = variation metric.

 

These calculated path = metrics( 6 metrics) are carried in PCEP message using the same Metric = Object with different metric type. 

The calculated = metrics are used as constraint for path computation =

 

In this draft, each = calculated metric is discussed in each separate section from metric = name, metric description

perspective to = measurement unit, calculation method = perspective.

IANA is also requested to register these 6 = metric types. Therefore I believe this draft conforms to RFC6390 = guideline.

However I have a few comments regarding these = metrics definitions.

1. Section 4, 2nd paragraph = says:

“

   This = document defines the following optional types for the = METRIC

   object defined in = [RFC5440].

”

s/defined in = [RFC5440]/defined in section 7.4 of [RFC5440]

[DhruvDhody>] Okay, But Metric section is = 7.8 in RFC5440 http://tools.ietf= .org/html/rfc5440#section-7.8 :)

 

2. Section 4.1 = says:

“

   Link = delay metric is defined in [OSPF-TE-EXPRESS] and

   = [ISIS-TE-EXPRESS].  P2P latency metric type of METRIC object in = PCEP

   encodes the sum of the link = delay metric of all links along a P2P

   = Path.  Specifically, extending on the above mentioned = terminology:

 

   - A Link = delay metric of link L is denoted D(L).

 

   - A P2P = latency metric for the Path P =3D Sum {D(Lpi), = (i=3D1...K)}.

 

   * = T=3D13(TBA - IANA): Latency metric

”

For people who are = not familiar with Metrics Object Format, it is not easy to figure out = what T=3D13 stands for? Would it be good to add some context text = or

Introduce Metric Object format = first.

 

=

[DhruvDhody>] Done! Check the diff file attached if this is = acceptable to you.

 

3. Section 4.2 = says:

“

   - A = Latency variation of link L is denoted DV(L).

 

   - A P2P = latency variation metric for the Path P =3D function = {DV(Lpi),

   = (i=3D1...K)}.

”

Why not sum of = latency variation metrics of individual links?

[DhruvDhody>] Making it a sum and aligning to http://tools.ietf.org/html/draft-ietf-mpls-te-express-path-00#s= ection-2.1

Is not a bad idea in my opinion. I need to discuss further with my = co-authors, if there is any objection to that.

 

4. Section 4.2 = says:

“

Specification of the = "Function" used to drive latency = variation

metric of a path from latency variation = metrics of individual links

along the path is = beyond the scope of this document.

”

s/drive/derive

 

[DhruvDhody>] sentence removed.

 

5. Section = 4

Section 4.3 says:

“Packet Loss = Metric metric type of METRIC Object”

Section 4.2 = says:

“P2P latency variation metric type of = METRIC

   = Object”

For consistency, you may either use “xx = Metric metric type” or “xx metric type of Metric = Object”.

[DhruvDhody>] Done!

 

6.Section 4.3 = says:

“

   The end = to end Packet Loss for the path is represented by = this

   metric.

 

   - A = Packet loss of link L is denoted PL(L).

 

   - A P2P = packet loss metric for the Path P =3D function = {PL(Lpi),

   = (i=3D1...K)}.

”

Is function of packet = loss metric of individual link same as function of latency variation = metric of individual link?

If they are not same, = please use different function name, e.g., function a for packet loss, = function b for latency variation?

[DhruvDhody>] I have updated this, please check the diff. =

 

Regards,

Dhruv

 

Regards!

-Qin

 

 

 

 

------=_NextPart_001_019C_01CF29B3.F4AD32F0-- ------=_NextPart_000_019B_01CF29B3.F4AC2180 Content-Type: text/html; name="Diff draft-ietf-pce-pcep-service-aware-02.txt - draft-ietf-pce-pcep-service-aware-03.txt.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Diff draft-ietf-pce-pcep-service-aware-02.txt - draft-ietf-pce-pcep-service-aware-03.txt.html" =0A= =0A= =0A= =0A= =0A= Diff: draft-ietf-pce-pcep-service-aware-02.txt - = draft-ietf-pce-pcep-service-aware-03.txt =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
< draft-ietf-pce-pcep-service-aware-02.txt   draft-ietf-pce-pcep-service-aware-03.txt >
PCE Working Group = D. Dhody PCE Working Group = D. Dhody
Internet-Draft = Huawei Technologies Internet-Draft = Huawei Technologies
Intended status: Standards Track = V. Manral Intended status: = Standards Track V. Manral
Expires: July 11, 2014 = Hewlett-Packard Corp. Expires: August 18, 2014 = Hewlett-Packard Corp.
= Z. = Ali = Z. Ali
= G. = Swallow = G. Swallow
= Cisco = Systems = Cisco Systems
= K. = Kumaki = K. Kumaki
= KDDI = Corporation = KDDI Corporation
= January 7, 2014 = February 14, 2014
Extensions to the Path Computation Element Communication = Protocol (PCEP) Extensions to the Path = Computation Element Communication Protocol (PCEP)
= to compute service aware Label Switched Path (LSP). = to compute service aware Label = Switched Path (LSP).
= draft-ietf-pce-pcep-service-aware-02 = draft-ietf-pce-pcep-service-aware-03
Abstract Abstract
= In certain networks like financial information network (stock/ = In certain networks like financial = information network (stock/
= commodity trading) and enterprises using cloud based = applications, commodity trading) = and enterprises using cloud based applications,
= Latency (delay), Latency-Variation (jitter) and Packet Loss is = Latency (delay), Latency-Variation (jitter) = and Packet Loss is
= becoming a key requirement for path computation along with = other becoming a key requirement = for path computation along with other
= constraints and metrics. Latency, Latency-Variation and Packet = Loss constraints and metrics. = Latency, Latency-Variation and Packet Loss
= is associated with the Service Level Agreement (SLA) between = is associated with the Service Level = Agreement (SLA) between
= customers and service providers. = customers and service providers.
=
skipping to change at page 2, line = 7 skipping to = change at page 2, line 7
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups = may also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. = Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= This Internet-Draft will expire on July = 11, 2014. This = Internet-Draft will expire on August 18, = 2014.
Copyright Notice Copyright Notice
= Copyright (c) 2014 IETF Trust and the persons identified as the = Copyright (c) 2014 IETF Trust and the = persons identified as the
= document authors. All rights reserved. document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the = IETF Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
=
skipping to change at page 5, line = 19 skipping to = change at page 5, line 19
= consistently: for instance, if the delay of a computed path = segment consistently: for instance, = if the delay of a computed path segment
= is exchanged between two PCEs residing in different domains, = is exchanged between two PCEs residing in = different domains,
= consistent ways of defining the delay must be used. consistent ways of defining the delay must be = used.
4. = PCEP Extensions 4. PCEP = Extensions
= This section defines PCEP extensions (see [RFC5440]) for = requirements This section defines = PCEP extensions (see [RFC5440]) for requirements
= outlined in Section 3. The proposed solution is used to = support outlined in Section 3. The = proposed solution is used to support
= network performance and service aware path computation. = network performance and service aware path = computation.
= This document defines the following optional types for the = METRIC The = METRIC object is defined in section 7.8 of [RFC5440], = comprising
= object defined in [RFC5440]. = of metric-value, = metric-type (T field) and flags. This document
defines the = following optional types for the METRIC object.
= For explanation of these metrics, the following terminology is = used For explanation of these = metrics, the following terminology is used
= and expanded along the way. and = expanded along the way.
= - A network comprises of a set of N links {Li, (i=3D1...N)}. = - A network comprises of a set of N links = {Li, (i=3D1...N)}.
= - A path P of a P2P LSP is a list of K links {Lpi,(i=3D1...K)}. = - A path P of a P2P LSP is a list of K links = {Lpi,(i=3D1...K)}.
4.1. Latency (Delay) Metric 4.1. Latency (Delay) Metric
= Link delay metric is defined in [OSPF-TE-EXPRESS] and Link delay metric is defined in [OSPF-TE-EXPRESS] = and
= [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in = PCEP [ISIS-TE-EXPRESS]. P2P = latency metric type of METRIC object in PCEP
= encodes the sum of the link delay metric of all links along a = P2P encodes the sum of the link = delay metric of all links along a P2P
= Path. Specifically, extending on the above mentioned = terminology: Path. Specifically, = extending on the above mentioned terminology:
= - A Link delay metric of link L is denoted D(L). - A Link delay metric of link L is denoted = D(L).
= - A P2P latency metric for the Path P =3D Sum {D(Lpi), = (i=3D1...K)}. - A P2P latency = metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.
= * T=3D13(TBA - IANA): Latency metric * Metric Type = T=3D13(TBA - IANA): Latency metric
= PCC MAY use this latency metric in PCReq message to request a = path PCC MAY use this latency = metric in PCReq message to request a path
= meeting the end to end latency requirement. In this case B bit = MUST meeting the end to end latency = requirement. In this case B bit MUST
= be set to suggest a bound (a maximum) for the path latency = metric be set to suggest a bound (a = maximum) for the path latency metric
= that must not be exceeded for the PCC to consider the computed = path that must not be exceeded for = the PCC to consider the computed path
= as acceptable. The path metric must be less than or equal to = the as acceptable. The path metric = must be less than or equal to the
= value specified in the metric-value field. value specified in the metric-value field.
= PCC MAY also use this metric to ask PCE to optimize latency = during PCC MAY also use this metric = to ask PCE to optimize latency during
= path computation, in this case B flag will be cleared. path computation, in this case B flag will be = cleared.
=
skipping to change at page 6, line = 34 skipping to = change at page 6, line 34
= Latency (Delay) Metric (24 bits): Represents the end to end = Latency Latency (Delay) Metric (24 = bits): Represents the end to end Latency
= (delay) quantified in units of microseconds and MUST be encoded = as (delay) quantified in units = of microseconds and MUST be encoded as
= integer value. With the maximum value 16,777,215 = representing integer value. = With the maximum value 16,777,215 representing
= 16.777215 sec. 16.777215 = sec.
4.2. Latency Variation (Jitter) Metric 4.2. Latency Variation (Jitter) Metric
= Link delay variation metric is defined in [OSPF-TE-EXPRESS] and = Link delay variation metric is defined in = [OSPF-TE-EXPRESS] and
= [ISIS-TE-EXPRESS]. P2P latency variation metric type of METRIC = [ISIS-TE-EXPRESS]. P2P latency variation = metric type of METRIC
= object in PCEP encodes a function of the = link delay variation metric object = in PCEP encodes the sum of the link delay = variation metric of
= of all links along a P2P Path. Specifically, extending on the = above all links along a P2P Path. = Specifically, extending on the above
= mentioned terminology: mentioned = terminology:
= - A Latency variation of link L is denoted DV(L). - A Latency variation of link L is denoted = DV(L).
= - A P2P latency variation metric for the Path P =3D function {DV(Lpi), - A P2P latency variation metric for the Path P =3D = Sum {DV(Lpi),
= (i=3D1...K)}. (i=3D1...K)}.
= Specification of the "Function" used to drive = latency variation * Metric Type T=3D14(TBA - IANA): Latency = Variation metric
metric of a path from latency = variation metrics of individual links
along the path is beyond the = scope of this document.
= =
= * T=3D14(TBA - IANA): Latency Variation metric
= PCC MAY use this latency variation metric in PCReq message to = request PCC MAY use this latency = variation metric in PCReq message to request
= a path meeting the end to end latency variation requirement. In = this a path meeting the end to end = latency variation requirement. In this
= case B bit MUST be set to suggest a bound (a maximum) for the = path case B bit MUST be set to = suggest a bound (a maximum) for the path
= latency variation metric that must not be exceeded for the PCC = to latency variation metric that = must not be exceeded for the PCC to
= consider the computed path as acceptable. The path metric must = be consider the computed path as = acceptable. The path metric must be
= less than or equal to the value specified in the metric-value = field. less than or equal to the = value specified in the metric-value field.
= PCC MAY also use this metric to ask PCE to optimize latency = variation PCC MAY also use this = metric to ask PCE to optimize latency variation
= during path computation, in this case B flag will be cleared. = during path computation, in this case B flag = will be cleared.
=
skipping to change at page 7, line = 39 skipping to = change at page 7, line 36
= on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on = receipt.
= Latency variation (jitter) Metric (24 bits): Represents the end = to Latency variation (jitter) = Metric (24 bits): Represents the end to
= end Latency variation (jitter) quantified in units of = microseconds end Latency = variation (jitter) quantified in units of microseconds
= and MUST be encoded as integer value. With the maximum = value and MUST be encoded as = integer value. With the maximum value
= 16,777,215 representing 16.777215 sec. 16,777,215 representing 16.777215 sec.
4.3. Packet Loss Metric 4.3. Packet Loss Metric
= [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional = Link [OSPF-TE-EXPRESS] and = [ISIS-TE-EXPRESS] defines "Unidirectional Link
= Loss". Packet Loss Metric metric type = of METRIC object in PCEP Loss". = Packet Loss metric type of METRIC object in PCEP encodes a
= encodes a function of the link's unidirectional loss metric of = all function of the link's = unidirectional loss metric of all links along
= links along a P2P Path. Specifically, extending on the above = a P2P Path. Specifically, extending on the = above mentioned
= mentioned terminology: = terminology:
= The end to end Packet Loss for the path is represented by this = The end to end Packet Loss for the path is = represented by this
= metric. metric.
= - A Packet loss of link L is denoted PL(L). - A Packet loss of link L is denoted PL(L).
= - A P2P packet loss metric for the Path P =3D function {PL(Lpi), - An Effective Packet = loss at link L along the Path P is denoted
(i=3D1...K)}. = EPL(Lpi) =3D = (((100-EPL(Lpi-1)) * PL(Lpi))/100). Where = EPL(Lp1) =3D
PL(Lp1).
= Specification of the "Function" used to drive = end to end packet loss = - A P2P packet loss metric for the Path P =3D sum = {EPL(Lpi),
= metric of a path from packet loss metrics of = individual links along (i=3D1...K)}.
the path is beyond the = scope of this document.
= * T=3D15(TBA - IANA): Packet Loss metric * Metric Type = T=3D15(TBA - IANA): Packet Loss metric
= PCC MAY use this packet loss metric in PCReq message to request = a PCC MAY use this packet loss = metric in PCReq message to request a
= path meeting the end to end packet loss requirement. In this case = B path meeting the end to end = packet loss requirement. In this case B
= bit MUST be set to suggest a bound (a maximum) for the path = packet bit MUST be set to suggest a = bound (a maximum) for the path packet
= loss metric that must not be exceeded for the PCC to consider = the loss metric that must not be = exceeded for the PCC to consider the
= computed path as acceptable. The path metric must be less than = or computed path as acceptable. = The path metric must be less than or
= equal to the value specified in the metric-value field. = equal to the value specified in the = metric-value field.
= PCC MAY also use this metric to ask PCE to optimize packet loss = PCC MAY also use this metric to ask PCE to = optimize packet loss
= during path computation, in this case B flag will be cleared. = during path computation, in this case B flag = will be cleared.
=
skipping to change at page 12, line = 33 skipping to = change at page 12, line 33
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P latency metric of the Path to destination Dest_j is denoted = by - P2P latency metric of the Path = to destination Dest_j is denoted by
= LM(Dest_j). LM(Dest_j).
= - P2MP latency metric for the P2MP tree T =3D Maximum = {LM(Dest_j), - P2MP latency metric = for the P2MP tree T =3D Maximum {LM(Dest_j),
= (j=3D1...M)}. (j=3D1...M)}.
= Value for P2MP latency metric is to be assigned = by IANA Value for P2MP = latency metric type (T) is to be assigned by = IANA.
6.3.2. P2MP Latency Variation Metric 6.3.2. P2MP Latency Variation Metric
= P2MP latency variation metric type of METRIC object in PCEP = encodes P2MP latency variation = metric type of METRIC object in PCEP encodes
= the path latency variation metric for destination that observes = the the path latency variation = metric for destination that observes the
= worst latency variation metric among all destinations of the = P2MP worst latency variation metric = among all destinations of the P2MP
= tree. Specifically, extending on the above mentioned = terminology: tree. Specifically, = extending on the above mentioned terminology:
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P latency variation metric of the Path to destination Dest_j = is - P2P latency variation metric = of the Path to destination Dest_j is
= denoted by LVM(Dest_j). denoted by = LVM(Dest_j).
= - P2MP latency variation metric for the P2MP tree T =3D Maximum = - P2MP latency variation metric for the P2MP = tree T =3D Maximum
= {LVM(Dest_j), (j=3D1...M)}. = {LVM(Dest_j), (j=3D1...M)}.
= Value for P2MP latency variation metric is to be assigned by IANA Value = for P2MP latency variation metric type (T) = is to be assigned by
IANA.
6.3.3. P2MP Packet Loss Metric 6.3.3. P2MP Packet Loss Metric
= P2MP packet loss metric type of METRIC object in PCEP encodes = the P2MP packet loss metric type of = METRIC object in PCEP encodes the
= path packet loss metric for destination that observes the worst = path packet loss metric for destination that = observes the worst
= packet loss metric among all destinations of the P2MP tree. = packet loss metric among all destinations of = the P2MP tree.
= Specifically, extending on the above mentioned terminology: = Specifically, extending on the above = mentioned terminology:
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P packet loss metric of the Path to destination Dest_j is = denoted - P2P packet loss metric of = the Path to destination Dest_j is denoted
= by PLM(Dest_j). by = PLM(Dest_j).
= - P2MP packet loss metric for the P2MP tree T =3D Maximum = {PLM(Dest_j), - P2MP packet loss = metric for the P2MP tree T =3D Maximum {PLM(Dest_j),
= (j=3D1...M)}. (j=3D1...M)}.
= Value for P2MP packet loss metric is to be = assigned by IANA Value for = P2MP packet loss metric type (T) is to be = assigned by IANA.
6.4. Stateful PCE 6.4. = Stateful PCE
= [STATEFUL-PCE] specifies a set of extensions to PCEP to enable = [STATEFUL-PCE] specifies a set of extensions = to PCEP to enable
= stateful control of MPLS-TE and GMPLS LSPs via PCEP and = maintaining stateful control of = MPLS-TE and GMPLS LSPs via PCEP and maintaining
= of these LSPs at the stateful PCE. A Path Computation LSP = State of these LSPs at the stateful = PCE. A Path Computation LSP State
= Report message (also referred to as PCRpt message) is a PCEP = message Report message (also = referred to as PCRpt message) is a PCEP message
= sent by a PCC to a PCE to report the current state of an LSP. = This sent by a PCC to a PCE to = report the current state of an LSP. This
= message contains the metric-list as part of attributes, the new = message contains the metric-list as part of = attributes, the new
= metric types defined in this document for network performance = metric types defined in this document for = network performance
=
skipping to change at page 15, line = 51 skipping to = change at page 15, line 51
= [OSPF-TE-EXPRESS] = [OSPF-TE-EXPRESS]
= Giacalone, S., Ward, D., Drake, J., Atlas, A., and = S. Giacalone, S., Ward, = D., Drake, J., Atlas, A., and S.
= Previdi, "OSPF Traffic Engineering (TE) Metric = Extensions Previdi, = "OSPF Traffic Engineering (TE) Metric Extensions
= [draft-ietf-ospf-te-metric-extensions]", December = 2013. = [draft-ietf-ospf-te-metric-extensions]", December 2013.
= [ISIS-TE-EXPRESS] = [ISIS-TE-EXPRESS]
= Previdi, S., Giacalone, S., Ward, D., Drake, J., = Atlas, Previdi, S., = Giacalone, S., Ward, D., Drake, J., Atlas,
= A., Filsfils, C., and Q. Wu, "IS-IS Traffic = Engineering A., = Filsfils, C., and Q. Wu, "IS-IS Traffic Engineering
= (TE) Metric Extensions [draft-ietf-isis-te-metric- = (TE) Metric Extensions = [draft-ietf-isis-te-metric-
= extensions-00]", October = 2013. extensions]", = October 2013.
= [MPLS-TE-EXPRESS-PATH] = [MPLS-TE-EXPRESS-PATH]
= Atlas, A., Drake, J., Ward, D., Giacalone, S., = Previdi, Atlas, A., = Drake, J., Ward, D., Giacalone, S., Previdi,
= S., and C. Filsfils, "Performance-based Path Selection = for S., and C. Filsfils, = "Performance-based Path Selection for
= Explicitly Routed LSPs [draft-atlas-mpls-te-express- Explicitly Routed LSPs [draft-ietf-mpls-te-express-path]",
path]", = September 2013. October 2013.
= [PCEP-MIB] [PCEP-MIB]
= Kiran Koushik, A., Stephan, E., Zhao, Q., King, D., and = J. Kiran Koushik, A., = Stephan, E., Zhao, Q., King, D., and J.
= Hardwick, "PCE communication protocol(PCEP) = Management Hardwick, = "PCE communication protocol(PCEP) Management
= Information Base [draft-ietf-pce-pcep-mib]", July 2013. = Information Base [draft-ietf-pce-pcep-mib]", February
2014.
= [STATEFUL-PCE] = [STATEFUL-PCE]
= Crabbe, E., Medved, J., Minei, I., and R. Varga,, = "PCEP Crabbe, E., = Medved, J., Minei, I., and R. Varga,, "PCEP
= Extensions for Stateful PCE = (draft-ietf-pce-stateful- = Extensions for Stateful PCE (draft-ietf-pce-stateful-
= pce)", October 2013. = pce)", October 2013.
= [PCEP-BW-UTIL] = [PCEP-BW-UTIL]
= Wu, Q., Dhody, D., and S. Previdi, "Extensions to = Path Wu, Q., Dhody, D., = and S. Previdi, "Extensions to Path
= Computation Element Communication Protocol (PCEP) = for Computation Element = Communication Protocol (PCEP) for
= handling Link Bandwidth Utilization = (draft-wu-pce-pcep- = handling Link Bandwidth Utilization (draft-wu-pce-pcep-
= link-bw-utilization)", January 2014. link-bw-utilization)", February 2014.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
= Clarence Filsfils Clarence = Filsfils
= Cisco Systems Cisco Systems
= EMail: cfilsfil@cisco.com EMail: = cfilsfil@cisco.com
= Siva Sivabalan Siva = Sivabalan
= Cisco Systems Cisco Systems
= EMail: msiva@cisco.com EMail: = msiva@cisco.com
 End of changes. 20 change blocks. 
33 lines changed or = deleted 32 lines changed or = added

This = html diff was produced by rfcdiff 1.41. The latest version is available = from http://tools.ietf.org/t= ools/rfcdiff/
=0A= =0A= =0A= ------=_NextPart_000_019B_01CF29B3.F4AC2180-- From nobody Fri Feb 14 13:48:32 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574251A0411; Fri, 14 Feb 2014 13:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.457 X-Spam-Level: X-Spam-Status: No, score=-13.457 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSeI0055fUdh; Fri, 14 Feb 2014 13:48:09 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E16311A03A9; Fri, 14 Feb 2014 13:48:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6501; q=dns/txt; s=iport; t=1392414488; x=1393624088; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=8zY+SX/q93/aCVMGWJJVT46Yu2CLjISVPARZaJ4MlL4=; b=b2m+FoupWoFQ2OjrfKmwG8qh8UbZaknlhm9BZqiVCQdO7QtHL17vSvFu ZyovrKs6oYaliYMzAgGGQc0r0dArgRzMedz7DyspBwKEoBUNxb6AoceaA IvNDuR4WcpzbL1YFcvaZF2yMOJiPnFXXiUK6SF6FjQ8Z6HMHbac8kOnq1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsULAHKO/lKtJV2b/2dsb2JhbABQCSeCX8A+gRgWdIIlAQEBBDg1Cw0ELBYPCQMCAQIBRQYBDAgBAYgByGIXjh4IWoQ4AQOYLIZHi1yDLjuBNQ X-IronPort-AV: E=Sophos;i="4.95,847,1384300800"; d="scan'208";a="304233676" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 14 Feb 2014 21:48:05 +0000 Received: from [10.82.245.17] (rtp-vpn2-1296.cisco.com [10.82.245.17]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1ELm1oF017597; Fri, 14 Feb 2014 21:48:02 GMT Message-ID: <52FE529B.1000602@cisco.com> Date: Fri, 14 Feb 2014 18:30:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20140213233357.15870.40506.idtracker@ietfa.amsl.com> In-Reply-To: <20140213233357.15870.40506.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140213233357.15870.40506.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/SCk_BmFh5raWnRYqIoLVief12-s Subject: [pm-dir] [IESG-AGENDA-DIST] Summarized Agenda for the 2014-02-20 IESG Teleconference X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:48:12 -0000 Dear all, Please find below the agenda of the Feb 20th IESG telechat. Please send your questions, comments, and concerns before Feb 19th COB. Thanks and Regards, Benoit. -------- Original Message -------- 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-pcp-nat64-prefix64-05 - IETF stream Learning NAT64 PREFIX64s using Port Control Protocol (PCP) (Proposed Standard) Token: Ted Lemon IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-mmusic-sdp-g723-g729-05 - IETF stream Offer/Answer Considerations for G723 Annex A and G729 Annex B (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-pcp-description-option-04 - IETF stream PCP Description Option (Proposed Standard) Token: Ted Lemon IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-avtext-rtp-duplication-05 - IETF stream Duplicating RTP Streams (Proposed Standard) Token: Gonzalo Camarillo IANA Review: Version Changed - Review Needed Consensus: Unknown o draft-ietf-pwe3-iccp-13 - IETF stream Inter-Chassis Communication Protocol for L2VPN PE Redundancy (Proposed Standard) Token: Stewart Bryant IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-dane-registry-acronyms-03 - IETF stream Adding acronyms to simplify DANE conversations (Proposed Standard) Token: Stephen Farrell IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-qresync-rfc5162bis-10 - IETF stream IMAP Extensions for Conditional STORE Operation or Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC) (Proposed Standard) Token: Barry Leiba IANA Review: IANA OK - Actions Needed Consensus: Yes o draft-ietf-manet-olsrv2-rmpr-optimization-00 - IETF stream Routing MPR Optimization for the Optimized Link State Routing Protocol version 2 (OLSRv2) (Proposed Standard) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-l2vpn-vpls-mib-14 - IETF stream Virtual Private Lan Services (VPLS) Management Information Base (Proposed Standard) Token: Stewart Bryant IANA Review: IANA - Not OK Consensus: Unknown Last call expires: 2014-02-14 o draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) for Bytes Discarded Metric (Proposed Standard) Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-xrblock-rtcp-xr-synchronization-08 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) Blocks for Synchronization Delay and Offset Metrics Reporting (Proposed Standard) Token: Gonzalo Camarillo IANA Review: Version Changed - Review Needed Consensus: Unknown 2.1.2 Returning Items o draft-ietf-alto-protocol-25 - IETF stream ALTO Protocol (Proposed Standard) Token: Spencer Dawkins IANA Review: IANA - Not OK Consensus: Unknown 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-opsec-vpn-leakages-03 - IETF stream Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks (Informational) Token: Joel Jaeggli IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-v6ops-nat64-experience-09 - IETF stream NAT64 Operational Experience (Informational) Token: Joel Jaeggli IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-mpls-forwarding-08 - IETF stream MPLS Forwarding Compliance and Performance Requirements (Informational) Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-allen-dispatch-imei-urn-as-instanceid-12 - IETF stream Using the International Mobile station Equipment Identity (IMEI) Uniform Resource Name (URN) as an Instance ID (Informational) Token: Gonzalo Camarillo IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-housley-pkix-test-oids-00 - IETF stream Object Identifiers for Test Certificate Policies (Informational) Token: Sean Turner IANA Review: IANA OK - No Actions Needed Consensus: Unknown 3.2.2 Returning Items o draft-montemurro-gsma-imei-urn-19 - IETF stream A Uniform Resource Name Namespace for the Global System for Mobile communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI) (Informational) Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Yes 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items o conflict-review-saintandre-jabberid-00 IETF conflict review for draft-saintandre-jabberid draft-saintandre-jabberid-12 The Jabber-ID Header Field (ISE: Informational) Token: Pete Resnick o conflict-review-irtf-cfrg-ocb-00 IETF conflict review for draft-irtf-cfrg-ocb draft-irtf-cfrg-ocb-07 The OCB Authenticated-Encryption Algorithm (IRTF: Informational) Token: Stephen Farrell 3.4.2 Returning Items o conflict-review-irtf-dtnrg-tcp-clayer-00 IETF conflict review for draft-irtf-dtnrg-tcp-clayer draft-irtf-dtnrg-tcp-clayer-08 Delay Tolerant Networking TCP Convergence Layer Protocol (IRTF: Experimental) Token: Martin Stiemerling 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o TURN Revised and Modernized (tram) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Network Configuration (netconf) From nobody Fri Feb 14 14:04:59 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F651A00BB; Fri, 14 Feb 2014 14:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqL6SQE5eVdg; Fri, 14 Feb 2014 14:04:49 -0800 (PST) Received: from omx.cbeyond.com (omx.cbeyond.com [50.20.30.10]) by ietfa.amsl.com (Postfix) with ESMTP id F02051A0024; Fri, 14 Feb 2014 14:04:35 -0800 (PST) X-SBRS: -1.8 X-HAT: Sender Group ONNET_RELAY, Policy $ACCEPTED applied. X-Hostname: omx08bay.sys.cbeyond.net X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIFAPSR/lJFD9PBUmdsb2JhbABZgwaDP74XFgMBJUuCXgEFQCkUFhgDAgECATEbDAgBAYgBBch0kzgEiUiVU45/Hg X-IronPort-AV: E=Sophos;i="4.95,847,1384318800"; d="scan'208";a="59045989" Received: from unknown (HELO alans-mbp.telchemy.com) ([69.15.211.193]) by omx.cbeyond.com with ESMTP/TLS/DHE-RSA-AES128-SHA; 14 Feb 2014 17:04:33 -0500 Message-ID: <52FE92F1.1020505@telchemy.com> Date: Fri, 14 Feb 2014 17:04:33 -0500 From: Alan Clark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ppsp-chairs@tools.ietf.org, ppsp@ietf.org, draft-ietf-ppsp-base-tracker-protocol@tools.ietf.org, pm-dir@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/7r8y7FSnxZMGVp6N78ZeTbfnhAE Subject: [pm-dir] PM DIR review of draft-ietf-ppsp-base-tracker-protocol-03 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:04:52 -0000 This is a PM Directorate review of draft-ietf-ppsp-base-tracker-protocol-03 and is focused on the definition of metrics and the need for the use of RFC6390 templates. This draft defines four metrics, onlineTime, uploadedBytes, downloadedBytes and availBandwidth. There is insufficient definition of these metrics and this draft SHOULD use RFC6390 templates to define these. General comments: (i) Online Time is defined as how long the peer has been in the P2P streaming system, expressed as an 8 bit value. It is not clear what the units are, or if it is intended that this is some form of enumerated value. (ii) There does not appear to be a definition of the time window to which the uploaded and downloaded bytes relate. Do these relate to a specific file, in which case the file size should also be shown, or to an aggregate count, in which case the time window should be defined. (iii) Uploaded/downloaded bytes could refer to layer 2/3 bytes or to content bytes. in the context of this draft it seems more likely that content bytes would be the parameter of interest however this should be specified. (iv) “Available Bandwidth” has a very specific meaning and an associated set of measurement methodologies. Available bandwidth typically applies to the difference between raw network bandwidth and the current traffic level. Within a peer to peer network it seems likely that the intent is to report either the raw network access bandwidth for a node or the measured (effective) uploaded bit rate. The definition of these metrics should be provided in RFC6390 form and should describe the units of measurement, the measurement interval, the measurement method and the intended application Regards Alan Clark From nobody Fri Feb 14 17:37:13 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597941A001A; Fri, 14 Feb 2014 17:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uR5zPl4wZ0S; Fri, 14 Feb 2014 17:37:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 646091A0015; Fri, 14 Feb 2014 17:37:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDP41201; Sat, 15 Feb 2014 01:37:00 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 01:36:37 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 01:36:59 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 09:36:52 +0800 From: Qin Wu To: Alan Clark , "ppsp-chairs@tools.ietf.org" , "ppsp@ietf.org" , "draft-ietf-ppsp-base-tracker-protocol@tools.ietf.org" , "pm-dir@ietf.org" Thread-Topic: [pm-dir] PM DIR review of draft-ietf-ppsp-base-tracker-protocol-03 Thread-Index: AQHPKdDPogDyYUinxk+szypAsC67qpq1hwCA Date: Sat, 15 Feb 2014 01:36:52 +0000 Message-ID: References: <52FE92F1.1020505@telchemy.com> In-Reply-To: <52FE92F1.1020505@telchemy.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/Wc5gsh4MqZsmSxFo5_ph_2Nfl4c Subject: Re: [pm-dir] PM DIR review of draft-ietf-ppsp-base-tracker-protocol-03 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:37:06 -0000 I agree with Alan's comments. One comment to add: I think The metric name "Available Bandwidth" needs to be more specific, "A= vailable Bandwidth" is well defined in draft-ietf-ospf-te-metric-extensions as link metric. "Available Bandwidth" = defined in draft-ietf-ppsp-base-tracker-protocol-03 is only related to uploading bandwidth and can be difference between total = uploading bandwidth and used uploading bandwidth. Regards! -Qin -----Original Message----- From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Alan Clark Sent: Saturday, February 15, 2014 6:05 AM To: ppsp-chairs@tools.ietf.org; ppsp@ietf.org; draft-ietf-ppsp-base-tracker= -protocol@tools.ietf.org; pm-dir@ietf.org Subject: [pm-dir] PM DIR review of draft-ietf-ppsp-base-tracker-protocol-03 This is a PM Directorate review of=20 draft-ietf-ppsp-base-tracker-protocol-03 and is focused on the=20 definition of metrics and the need for the use of RFC6390 templates. This draft defines four metrics, onlineTime, uploadedBytes,=20 downloadedBytes and availBandwidth. There is insufficient definition of=20 these metrics and this draft SHOULD use RFC6390 templates to define these. General comments: (i) Online Time is defined as how long the peer has been in the P2P=20 streaming system, expressed as an 8 bit value. It is not clear what the=20 units are, or if it is intended that this is some form of enumerated value. (ii) There does not appear to be a definition of the time window to=20 which the uploaded and downloaded bytes relate. Do these relate to a=20 specific file, in which case the file size should also be shown, or to=20 an aggregate count, in which case the time window should be defined. (iii) Uploaded/downloaded bytes could refer to layer 2/3 bytes or to=20 content bytes. in the context of this draft it seems more likely that=20 content bytes would be the parameter of interest however this should be=20 specified. (iv) "Available Bandwidth" has a very specific meaning and an associated=20 set of measurement methodologies. Available bandwidth typically applies=20 to the difference between raw network bandwidth and the current traffic=20 level. Within a peer to peer network it seems likely that the intent is=20 to report either the raw network access bandwidth for a node or the=20 measured (effective) uploaded bit rate. The definition of these metrics should be provided in RFC6390 form and=20 should describe the units of measurement, the measurement interval, the=20 measurement method and the intended application Regards Alan Clark _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir From nobody Fri Feb 14 18:36:17 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD3C1A002B for ; Fri, 14 Feb 2014 18:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5To3D6EFMTo for ; Fri, 14 Feb 2014 18:36:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A0E241A0026 for ; Fri, 14 Feb 2014 18:36:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD61621; Sat, 15 Feb 2014 02:36:06 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 02:35:43 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 02:36:04 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 10:35:55 +0800 From: Qin Wu To: "MORTON, ALFRED C (AL)" , Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: AQHPKY/quYkd/zkR1EeByu39qGgdLJq1kanA Date: Sat, 15 Feb 2014 02:35:54 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C80858nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/yGm8gze2NeGkB4CIXZfiJwK25L0 Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 02:36:16 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C80858nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cis= co.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each s= ub path is millisecond. Using sum may be the worse case approximation of path DV and cause the gran= ularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definite= ly we Can improve granularity of measurement/calculation result but at the cost o= f Consuming more computation overhead. So there is tradeoff to pick one or an= other. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; = ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin --_000_B8F9A780D330094D99AF023C5877DABA43C80858nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Al:

You raise very good co= mments for this. Here are a few thoughts below.

 

Regards!

-Qin=

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swal= low@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

A few additional comments, we can help the authors a bit m= ore

I think, but Qin was on the right track.=

 

Al

 

Qin wrote:

3. Section 4.2 s= ays:

“<= /span>

   - A La= tency variation of link L is denoted DV(L).

 

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),=

   (i=3D1= ...K)}.

”<= /span>

Why not sum of late= ncy variation metrics of individual links?

-------------------------------------------------------

 

Sum is a rather worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estimates in IPPM.=

Packet Delay Variation is the most complex, but a couple o= f

possibilities for "function" are specified here:=

htt= p://tools.ietf.org/html/rfc6049#page-20

 

[Qin]: Yes, it is a rat hole that needs t= o be fixed.

Do you know how the function defined in s= ection 6.4.5.1 of RFC6049

Can be applied to this draft and quoted a= s function of latency variation

For complete path from source to destinat= ion.

 

It seems to me we only know delay variati= on of each sub path, which is

gathered from link delay variation advert= isement defined in

draft-ietf-ospf-te-metric-extensions. The= unit of delay variation of each sub path

is millisecond.

 

Using sum may be the worse case approxima= tion of path DV and cause the granularity

of measurement result very coarse, but th= e computation overhead

for calculation of path DV can be minimiz= ed.

If we use integral function defined in se= ction 6.4.5.1 of RFC6049, definitely we

Can improve granularity of measurement/ca= lculation result but at the cost of

Consuming more computation overhead. So t= here is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as refe= rences

in this draft, for loss

htt= p://tools.ietf.org/html/rfc6049#page-18

 

[Qin]: Yes, I agree= Composition Function defined in section 5.1.5 can be=

cited as reference = for this draft.

 

and for mean delay

http://tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to leave the "function" unspecified = and out of scope,

assuming your loss and delay metric definitions are compat= ible.

 

[Qin]: Exactly.

 

 

 

From: pm-dir [= mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisc= o.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-p= cep-service-aware-02

 

Hi, authors:

I am assigned Perfo= rmance Directorate reviewer for this draft.

Here is my review t= o this draft.

 

This draft uses the= link latency, latency variation and packet loss information for end to end= path selection.

The link latency, l= atency variation and packet loss metrics are defined in OSPF-TE draft and I= SIS-TE draft and

used to calculate p= ath metrics described in this draft, e.g., P2P latency metric, P2P latency = variation metric, packet loss

metric, P2MP latenc= y metric, P2MP latency variation metric.

 

These calculated pa= th metrics( 6 metrics) are carried in PCEP message using the same Metric Ob= ject with different metric type. 

The calculated metr= ics are used as constraint for path computation

 

In this draft, each= calculated metric is discussed in each separate section from metric name, = metric description

perspective to meas= urement unit, calculation method perspective.

IANA is also reques= ted to register these 6 metric types. Therefore I believe this draft confor= ms to RFC6390 guideline.

However I have a fe= w comments regarding these metrics definitions.

1. Section 4, 2<= sup>nd paragraph says:

“<= /span>

   This d= ocument defines the following optional types for the METRIC

   object= defined in [RFC5440].

”<= /span>

s/defined in [= RFC5440]/defined in section 7.4 of [RFC5440]

 

2. Section 4.1 s= ays:

“<= /span>

   Link d= elay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-= TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP

   encode= s the sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

 

   - A Li= nk delay metric of link L is denoted D(L).

 

   - A P2= P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.

 

   * T=3D= 13(TBA - IANA): Latency metric

”<= /span>

For people who are = not familiar with Metrics Object Format, it is not easy to figure out what = T=3D13 stands for? Would it be good to add some context text or<= /span>

Introduce Metric Ob= ject format first.

 

 

3. Section 4.2 s= ays:

“<= /span>

   - A La= tency variation of link L is denoted DV(L).

 

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),=

   (i=3D1= ...K)}.

”<= /span>

Why not sum of late= ncy variation metrics of individual links?

 

4. Section 4.2 s= ays:

“<= /span>

Specification of th= e "Function" used to drive latency variation

metric of a path fr= om latency variation metrics of individual links

along the path is b= eyond the scope of this document.

”<= /span>

s/drive/derive=

 

5. Section 4

Section 4.3 says:

“Packet Loss = Metric metric type of METRIC Object”

Section 4.2 says:

“P2P latency = variation metric type of METRIC

   Object= ”

For consistency, yo= u may either use “xx Metric metric type” or “xx metric ty= pe of Metric Object”.

 

6.Section 4.3 sa= ys:

“<= /span>

   The en= d to end Packet Loss for the path is represented by this<= /p>

   metric= .

 

   - A Pa= cket loss of link L is denoted PL(L).

 

   - A P2= P packet loss metric for the Path P =3D function {PL(Lpi),

   (i=3D1= ...K)}.

”<= /span>

Is function of pack= et loss metric of individual link same as function of latency variation met= ric of individual link?

If they are not sam= e, please use different function name, e.g., function a for packet loss, fu= nction b for latency variation?

 

Regards!=

-Qin

 

 

 

 

--_000_B8F9A780D330094D99AF023C5877DABA43C80858nkgeml501mbschi_-- From nobody Sat Feb 15 05:42:25 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31281A0219 for ; Sat, 15 Feb 2014 05:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.552 X-Spam-Level: ** X-Spam-Status: No, score=2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK-gA8g-rTqN for ; Sat, 15 Feb 2014 05:42:18 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 855DF1A0212 for ; Sat, 15 Feb 2014 05:42:17 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id 72F171202BE; Sat, 15 Feb 2014 08:45:42 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id 94EECE0277; Sat, 15 Feb 2014 08:42:15 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Sat, 15 Feb 2014 08:42:15 -0500 From: "MORTON, ALFRED C (AL)" To: Qin Wu , Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Date: Sat, 15 Feb 2014 08:42:13 -0500 Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: AQHPKY/quYkd/zkR1EeByu39qGgdLJq1kanAgADANoA= Message-ID: <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8BC5B9B79njfpsrvexg8rese_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/ykHxXtK8OpUZKIR9Htl60bOkTn8 Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 13:42:23 -0000 --_000_2845723087023D4CB5114223779FA9C8BC5B9B79njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Qin, authors, I read, in draft-ietf-ospf-te-metric-extensions: 4.3.4. Delay Variation This 24-bit field carries the average link delay variation over a configurable interval in micro-seconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. So this is an *average* DV, to my surprise, and therefore the sum function Qin proposed is reasonable. (it still doesn't say here what form of delay variation has been measured) However, delay variation is better characterized in summary statistics which describe the breadth of the DV distribution. In bimodal delay distributions, the average can be misleading. But you have what you have in draft-ietf-ospf-te-metric-extensions for now, and summing averages is an easy problem. Use RFC6049 for the other metrics, like loss and delay. regards, Al From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 9:36 PM To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.c= om; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each s= ub path is millisecond. Using sum may be the worse case approximation of path DV and cause the gran= ularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definite= ly we Can improve granularity of measurement/calculation result but at the cost o= f Consuming more computation overhead. So there is tradeoff to pick one or an= other. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@= cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin --_000_2845723087023D4CB5114223779FA9C8BC5B9B79njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Qin, authors,

 

I read, in draft-ietf-o= spf-te-metric-extensions:

4.3.4. Delay Variation

   = This 24-bit field carries the average link delay variation over a

   configurable interval in micro-seconds, encod= ed as an integer value.

   When set to = 0, it has not been measured. When set to the maximum

<= p class=3DMsoNormal>   value 16,777,215 (16.777215 sec), then the delay is at lea= st that

   value and may be larger.

 

So this is an *a= verage* DV, to my surprise,

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>and therefore the= sum function Qin proposed is reasonable.

&n= bsp;

(it still doesn't say here what form of delay var= iation has been measured)

 

However, delay variation is better characterized in summary<= /o:p>

statistics which describe the breadth of the DV distri= bution.

In bimodal delay distributions, the avera= ge can be misleading.

 

But you have what you have in draft-ietf-ospf-te-metric-exten= sions

for now, and summing averages is an eas= y problem.  Use RFC6049

for the other metric= s, like loss and delay.

 <= /p>

regards,

Al

 

 

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent= : Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL)= ; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke= -kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-d= ir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02<= o:p>

 

=

Hi, Al:

You raise very good= comments for this. Here are a few thoughts below.

 

Regards!

-Qin

 

From: MORTON, ALFRED C (AL) [= mailto:acmorton@att.com]
Sen= t: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody= ; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-= kumaki@kddi.com
Cc: pm-dir= @ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 revie= w of draft-ietf-pce-pcep-service-aware-02

=

 

A few additional comments, = we can help the authors a bit more

I think, but Q= in was on the right track.

 

Al

 

Qi= n wrote:

3. Section 4.2 says:

“

   - A Latency vari= ation of link L is denoted DV(L).

 

   - A P2P latency varia= tion metric for the Path P =3D function {DV(Lpi),

   (i=3D1...K)}= .

”

Why not sum of latency variation metrics of individual links?

----------------------------------------------------= ---

 

Sum is a rat= her worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estim= ates in IPPM.

Packet Delay Variation is the most = complex, but a couple of

possibilities for "= function" are specified here:

http://tools.ietf.org/html/rfc6049= #page-20

 

[Qin]: Yes, i= t is a rat hole that needs to be fixed.

Do you know how the function defined in section 6.4.5.1 of RF= C6049

Can be applied to this= draft and quoted as function of latency variation

For complete path from source to destination.

 

It seems to me we only know delay variation of each sub= path, which is

gathered fr= om link delay variation advertisement defined in

=

draft-ietf-ospf-te-metric-extensions. The unit of del= ay variation of each sub path

 = ;

Using sum may be the worse case= approximation of path DV and cause the granularity <= /p>

of measurement result very coarse, but the computa= tion overhead

for calculati= on of path DV can be minimized.

If we use integral function defined in section 6.4.5.1 of RFC6049, defi= nitely we

Can improve granul= arity of measurement/calculation result but at the cost of

Consuming more computation overhead. So ther= e is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as r= eferences

in this draft, for loss

http://to= ols.ietf.org/html/rfc6049#page-18

 

[Qin]: Yes, I agree Composition Function defined in section 5.1.5= can be

cited as reference for this draft.

 

and for mean delay

http://tools.ietf.org/html/rfc6049#secti= on-4.2

 

So,= no need to leave the "function" unspecified and out of scope,

assuming your loss and delay metric definitions are= compatible.

 

[Qin]: Exactly.

 

 <= /span>

 

From: pm-dir [mailto:pm-= dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday= , February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cis= co.com; ke-kumaki@kddi.comCc: pm-dir@ietf.org
Su= bject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-s= ervice-aware-02

=  

Hi, a= uthors:

I am assigned Performance Directorate reviewer for this draft.=

Here= is my review to this draft.

 

This draft uses the link latency, laten= cy variation and packet loss information for end to end path selection.

Th= e link latency, latency variation and packet loss metrics are defined in OS= PF-TE draft and ISIS-TE draft and

used to calculate path metrics described= in this draft, e.g., P2P latency metric, P2P latency variation metric, pac= ket loss

metric, P2MP latency metric, P2MP latency variation metric. =

 

These calculated path metrics( 6 metrics) are carried in PCEP message us= ing the same Metric Object with different metric type. 

The calculate= d metrics are used as constraint for path computation

 

In this draft= , each calculated metric is discussed in each separate section from metric = name, metric description

perspective to measurement unit, calculation meth= od perspective.

IANA is also requested to register these 6 metric types. Th= erefore I believe this draft conforms to RFC6390 guideline.

However I have = a few comments regarding these metrics definitions.

1. Section 4, 2= nd paragraph says:

“

   This document defines the= following optional types for the METRIC

   object defined in [RF= C5440].

”

s/defined in [RFC5440]/defined in section 7.4 of [RFC5= 440]

 

2. Section 4.1 says:

“

   Link delay met= ric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-TE-EXPRESS].&nbs= p; P2P latency metric type of METRIC object in PCEP

   encodes th= e sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

&nbs= p;

&n= bsp;  - A Link delay metric of link L is denoted D(L).

 

 &n= bsp; - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.

<= o:p> 

   * T=3D13(TBA - IANA): Latency metric

”<= /span>

For people = who are not familiar with Metrics Object Format, it is not easy to figure o= ut what T=3D13 stands for? Would it be good to add some context text or

Int= roduce Metric Object format first.

 

 

3. Sectio= n 4.2 says:

“

   - A Latency variation of link L is den= oted DV(L).

 

   - A P2P latency variation metric for the Pa= th P =3D function {DV(Lpi),

   (i=3D1...K)}.

”

Why not sum = of latency variation metrics of individual links?

 <= /p>

4. Section 4.2 = says:

“

Specification of the "Function" used to drive l= atency variation

metric of a path from latency variation metrics of individ= ual links

along the path is beyond the scope of this document.

”=

s/dr= ive/derive

 

5. Section 4

Section 4.3 says:<= /p>

“Packet Loss= Metric metric type of METRIC Object”

Section 4.2 says:<= /span>

“P2P = latency variation metric type of METRIC

   Object”

For cons= istency, you may either use “xx Metric metric type” or “x= x metric type of Metric Object”.

 

6.Section 4.3 says:

&#= 8220;

   The end to end Packet Loss for the path is represented b= y this

   metric.

 

   - A Packet loss of link L i= s denoted PL(L).

 

   - A P2P packet loss metric for the Pat= h P =3D function {PL(Lpi),

   (i=3D1...K)}.

=

”

Is function o= f packet loss metric of individual link same as function of latency variati= on metric of individual link?

If they are not same, please use different fu= nction name, e.g., function a for packet loss, function b for latency varia= tion?

 

Regards!

-Qin

 

 <= /o:p>

=  

 

= --_000_2845723087023D4CB5114223779FA9C8BC5B9B79njfpsrvexg8rese_-- From nobody Sat Feb 15 06:21:42 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B90A1A020A for ; Sat, 15 Feb 2014 06:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxr1xkrFqMjB for ; Sat, 15 Feb 2014 06:21:37 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id C39131A0234 for ; Sat, 15 Feb 2014 06:21:34 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-255-15.research.att.com [135.207.255.15]) by mail-pink.research.att.com (Postfix) with ESMTP id C6F4D12007D for ; Sat, 15 Feb 2014 09:24:59 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-green.research.att.com (Postfix) with ESMTP id AFC6BE0105 for ; Sat, 15 Feb 2014 09:20:39 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Sat, 15 Feb 2014 09:21:32 -0500 From: "MORTON, ALFRED C (AL)" To: "pm-dir@ietf.org" Date: Sat, 15 Feb 2014 09:21:28 -0500 Thread-Topic: pm-dir meeting at IETF-89 Thread-Index: Ac8qWCQd3BO9MOp0Ri6HIkq3XOe+6Q== Message-ID: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/o_7330fzP7qTo38DEMrstMnSpnM Subject: [pm-dir] pm-dir meeting at IETF-89 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 14:21:39 -0000 pm-dir members, As you can see: https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJv= VUhta3VLSjl3SkE&usp=3Dsharing We are in pretty good shape at the moment on=20 volunteers for reviews and completed reviews this year. Thanks to all who have contributed! I would like to welcome a new member to the Directorate, Qin Wu. =20 This will be no surprise to those following the mailing list, as he has completed three reviews in the last week. I would like to propose a brief meeting of pm-dir at IETF-89, primarily to discuss membership review and any topics members would like to raise. 1300-1400 GMT Tuesday Afternoon Session I I note that IPFIX has been cancelled, and perhaps we could=20 use that meeting space or an alternate space. In any case, let's meet at IETF registration at 1300=20 and go from there. If you'd like to attend but have a conflict at that time, please suggest an alternate. regards, Al pm-dir admin From nobody Sat Feb 15 14:33:29 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4C1A00F6 for ; Sat, 15 Feb 2014 14:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngXN9w88qpXI for ; Sat, 15 Feb 2014 14:33:25 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 215711A00AA for ; Sat, 15 Feb 2014 14:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49377; q=dns/txt; s=iport; t=1392503601; x=1393713201; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Ig4QdA4v8tCEtmTuT2Y7rJUxuOYiujSCiyAHh/Mv9PY=; b=H8AK2KgpyNqvL/W6ETbLWvi6keaT6eu/baZVTB1u1sWnFVxascEZgU4/ m675YCmOBrGlGTjsMCLLHNqU8IoqCnfgkxtb1rbUpkCRUOiHZYfqEiaVK OqYZ6nXaGlkS1Jy1Pl/ga8hOf/VSyvEdUtet1NfKxTmu+4IrgIgUclrOO M=; X-IronPort-AV: E=Sophos;i="4.95,852,1384300800"; d="scan'208,217";a="4523370" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 15 Feb 2014 22:33:20 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1FMXK27025964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Feb 2014 22:33:20 GMT Received: from [10.61.97.232] (dhcp-10-61-97-232.cisco.com [10.61.97.232]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1FMXBXx009082; Sat, 15 Feb 2014 22:33:15 GMT Message-ID: <52FFEB1B.8010606@cisco.com> Date: Sat, 15 Feb 2014 22:32:59 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , Qin Wu , Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> Content-Type: multipart/alternative; boundary="------------030500060308090500020001" Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/dOyCsv8p0KdReJjW_aYHg2F_oA8 Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 22:33:29 -0000 This is a multi-part message in MIME format. --------------030500060308090500020001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Al, All, For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-TLV". Several parts of the text (4.1 through 4.4) say, "This (field) carries the (metric) over a configurable interval". Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ? P. On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: > > Hi Qin, authors, > > I read, in *draft-ietf-ospf-te-metric-extensions*: > > *4.3.4* > *. > Delay Variation* > > This 24-bit field carries the average link delay variation over a > > configurable interval in micro-seconds, encoded as an integer value. > > When set to 0, it has not been measured. When set to the maximum > > value 16,777,215 (16.777215 sec), then the delay is at least that > > value and may be larger. > > So this is an **average** DV, to my surprise, > > and therefore the sum function Qin proposed is reasonable. > > (it still doesn't say here what form of delay variation has been measured) > > However, delay variation is better characterized in summary > > statistics which describe the breadth of the DV distribution. > > In bimodal delay distributions, the average can be misleading. > > But you have what you have in *draft-ietf-ospf-te-metric-extensions* > > for now, and summing averages is an easy problem. Use RFC6049 > > for the other metrics, like loss and delay. > > regards, > > Al > > *From:*Qin Wu [mailto:bill.wu@huawei.com] > *Sent:* Friday, February 14, 2014 9:36 PM > *To:* MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; > zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com > *Cc:* pm-dir@ietf.org > *Subject:* RE: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > Hi, Al: > > You raise very good comments for this. Here are a few thoughts below. > > Regards! > > -Qin > > *From:*MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > *Sent:* Friday, February 14, 2014 10:20 PM > *To:* Qin Wu; Dhruv Dhody; vishwas.manral@hp.com > ; zali@cisco.com > ; swallow@cisco.com ; > ke-kumaki@kddi.com > *Cc:* pm-dir@ietf.org > *Subject:* RE: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > A few additional comments, we can help the authors a bit more > > I think, but Qin was on the right track. > > Al > > Qin wrote: > > *3. Section 4.2 says:* > > " > > - A Latency variation of link L is denoted DV(L). > > - A P2P latency variation metric for the Path P = function {DV(Lpi), > > (i=1...K)}. > > " > > Why not sum of latency variation metrics of individual links? > > ------------------------------------------------------- > > Sum is a rather worst-case approximation of the Path DV. > > We have studied these sorts of e2e Path estimates in IPPM. > > Packet Delay Variation is the most complex, but a couple of > > possibilities for "function" are specified here: > > http://tools.ietf.org/html/rfc6049#page-20 > > *[Qin]: Yes, it is a rat hole that needs to be fixed.* > > *Do you know how the function defined in section 6.4.5.1 of RFC6049* > > *Can be applied to this draft and quoted as function of latency variation* > > *For complete path from source to destination.* > > ** > > *It seems to me we only know delay variation of each sub path, which is * > > *gathered from link delay variation advertisement defined in * > > *draft-ietf-ospf-te-metric-extensions. The unit of delay variation of > each sub path* > > *is millisecond.* > > ** > > *Using sum may be the worse case approximation of path DV and cause > the granularity * > > *of measurement result very coarse, but the computation overhead* > > *for calculation of path DV can be minimized.* > > *If we use integral function defined in section 6.4.5.1 of RFC6049, > definitely we* > > *Can improve granularity of measurement/calculation result but at the > cost of* > > *Consuming more computation overhead. So there is tradeoff to pick one > or another.* > > ** > > Similarly, we have functions, which could be cited as references > > in this draft, for loss > > http://tools.ietf.org/html/rfc6049#page-18 > > *[Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be* > > *cited as reference for this draft.* > > and for mean delay > > http://tools.ietf.org/html/rfc6049#section-4.2 > > So, no need to leave the "function" unspecified and out of scope, > > assuming your loss and delay metric definitions are compatible. > > [Qin]: Exactly. > > *From:*pm-dir [mailto:pm-dir-bounces@ietf.org] *On Behalf Of *Qin Wu > *Sent:* Friday, February 14, 2014 5:44 AM > *To:* Dhruv Dhody; vishwas.manral@hp.com > ; zali@cisco.com > ; swallow@cisco.com ; > ke-kumaki@kddi.com > *Cc:* pm-dir@ietf.org > *Subject:* [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > Hi, authors: > > I am assigned Performance Directorate reviewer for this draft. > > Here is my review to this draft. > > This draft uses the link latency, latency variation and packet loss > information for end to end path selection. > > The link latency, latency variation and packet loss metrics are > defined in OSPF-TE draft and ISIS-TE draft and > > used to calculate path metrics described in this draft, e.g., P2P > latency metric, P2P latency variation metric, packet loss > > metric, P2MP latency metric, P2MP latency variation metric. > > These calculated path metrics( 6 metrics) are carried in PCEP message > using the same Metric Object with different metric type. > > The calculated metrics are used as constraint for path computation > > In this draft, each calculated metric is discussed in each separate > section from metric name, metric description > > perspective to measurement unit, calculation method perspective. > > IANA is also requested to register these 6 metric types. Therefore I > believe this draft conforms to RFC6390 guideline. > > However I have a few comments regarding these metrics definitions. > > *1. Section 4, 2^nd paragraph says:* > > " > > This document defines the following optional types for the METRIC > > object defined in [RFC5440]. > > " > > s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] > > *2. Section 4.1 says:* > > " > > Link delay metric is defined in [OSPF-TE-EXPRESS] and > > [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP > > encodes the sum of the link delay metric of all links along a P2P > > Path. Specifically, extending on the above mentioned terminology: > > - A Link delay metric of link L is denoted D(L). > > - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. > > * T=13(TBA - IANA): Latency metric > > " > > For people who are not familiar with Metrics Object Format, it is not > easy to figure out what T=13 stands for? Would it be good to add some > context text or > > Introduce Metric Object format first. > > ** > > ** > > *3. Section 4.2 says:* > > " > > - A Latency variation of link L is denoted DV(L). > > - A P2P latency variation metric for the Path P = function {DV(Lpi), > > (i=1...K)}. > > " > > Why not sum of latency variation metrics of individual links? > > *4. Section 4.2 says:* > > " > > Specification of the "Function" used to drive latency variation > > metric of a path from latency variation metrics of individual links > > along the path is beyond the scope of this document. > > " > > s/drive/derive > > *5. Section 4* > > Section 4.3 says: > > "Packet Loss Metric metric type of METRIC Object" > > Section 4.2 says: > > "P2P latency variation metric type of METRIC > > Object" > > For consistency, you may either use "xx Metric metric type" or "xx > metric type of Metric Object". > > *6.Section 4.3 says:* > > " > > The end to end Packet Loss for the path is represented by this > > metric. > > - A Packet loss of link L is denoted PL(L). > > - A P2P packet loss metric for the Path P = function {PL(Lpi), > > (i=1...K)}. > > " > > Is function of packet loss metric of individual link same as function > of latency variation metric of individual link? > > If they are not same, please use different function name, e.g., > function a for packet loss, function b for latency variation? > > Regards! > > -Qin > > > > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir --------------030500060308090500020001 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Al, All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ?

P.


On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:

Hi Qin, authors,

 

I read, in draft-ietf-ospf-te-metric-extensions:

4.3.4. Delay Variation

   This 24-bit field carries the average link delay variation over a

   configurable interval in micro-seconds, encoded as an integer value.

   When set to 0, it has not been measured. When set to the maximum

   value 16,777,215 (16.777215 sec), then the delay is at least that

   value and may be larger.

 

So this is an *average* DV, to my surprise,

and therefore the sum function Qin proposed is reasonable.

 

(it still doesn't say here what form of delay variation has been measured)

 

However, delay variation is better characterized in summary

statistics which describe the breadth of the DV distribution.

In bimodal delay distributions, the average can be misleading.

 

But you have what you have in draft-ietf-ospf-te-metric-extensions

for now, and summing averages is an easy problem.  Use RFC6049

for the other metrics, like loss and delay.

 

regards,

Al

 

 

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

Hi, Al:

You raise very good comments for this. Here are a few thoughts below.

 

Regards!

-Qin

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

A few additional comments, we can help the authors a bit more

I think, but Qin was on the right track.

 

Al

 

Qin wrote:

3. Section 4.2 says:

“

   - A Latency variation of link L is denoted DV(L).

 

   - A P2P latency variation metric for the Path P = function {DV(Lpi),

   (i=1...K)}.

”

Why not sum of latency variation metrics of individual links?

-------------------------------------------------------

 

Sum is a rather worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estimates in IPPM.

Packet Delay Variation is the most complex, but a couple of

possibilities for "function" are specified here:

http://tools.ietf.org/html/rfc6049#page-20

 

[Qin]: Yes, it is a rat hole that needs to be fixed.

Do you know how the function defined in section 6.4.5.1 of RFC6049

Can be applied to this draft and quoted as function of latency variation

For complete path from source to destination.

 

It seems to me we only know delay variation of each sub path, which is

gathered from link delay variation advertisement defined in

draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each sub path

is millisecond.

 

Using sum may be the worse case approximation of path DV and cause the granularity

of measurement result very coarse, but the computation overhead

for calculation of path DV can be minimized.

If we use integral function defined in section 6.4.5.1 of RFC6049, definitely we

Can improve granularity of measurement/calculation result but at the cost of

Consuming more computation overhead. So there is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as references

in this draft, for loss

http://tools.ietf.org/html/rfc6049#page-18

 

[Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be

cited as reference for this draft.

 

and for mean delay

http://tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to leave the "function" unspecified and out of scope,

assuming your loss and delay metric definitions are compatible.

 

[Qin]: Exactly.

 

 

 

From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

Hi, authors:

I am assigned Performance Directorate reviewer for this draft.

Here is my review to this draft.

 

This draft uses the link latency, latency variation and packet loss information for end to end path selection.

The link latency, latency variation and packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and

used to calculate path metrics described in this draft, e.g., P2P latency metric, P2P latency variation metric, packet loss

metric, P2MP latency metric, P2MP latency variation metric.

 

These calculated path metrics( 6 metrics) are carried in PCEP message using the same Metric Object with different metric type. 

The calculated metrics are used as constraint for path computation

 

In this draft, each calculated metric is discussed in each separate section from metric name, metric description

perspective to measurement unit, calculation method perspective.

IANA is also requested to register these 6 metric types. Therefore I believe this draft conforms to RFC6390 guideline.

However I have a few comments regarding these metrics definitions.

1. Section 4, 2nd paragraph says:

“

   This document defines the following optional types for the METRIC

   object defined in [RFC5440].

”

s/defined in [RFC5440]/defined in section 7.4 of [RFC5440]

 

2. Section 4.1 says:

“

   Link delay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP

   encodes the sum of the link delay metric of all links along a P2P

   Path.  Specifically, extending on the above mentioned terminology:

 

   - A Link delay metric of link L is denoted D(L).

 

   - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}.

 

   * T=13(TBA - IANA): Latency metric

”

For people who are not familiar with Metrics Object Format, it is not easy to figure out what T=13 stands for? Would it be good to add some context text or

Introduce Metric Object format first.

 

 

3. Section 4.2 says:

“

   - A Latency variation of link L is denoted DV(L).

 

   - A P2P latency variation metric for the Path P = function {DV(Lpi),

   (i=1...K)}.

”

Why not sum of latency variation metrics of individual links?

 

4. Section 4.2 says:

“

Specification of the "Function" used to drive latency variation

metric of a path from latency variation metrics of individual links

along the path is beyond the scope of this document.

”

s/drive/derive

 

5. Section 4

Section 4.3 says:

“Packet Loss Metric metric type of METRIC Object”

Section 4.2 says:

“P2P latency variation metric type of METRIC

   Object”

For consistency, you may either use “xx Metric metric type” or “xx metric type of Metric Object”.

 

6.Section 4.3 says:

“

   The end to end Packet Loss for the path is represented by this

   metric.

 

   - A Packet loss of link L is denoted PL(L).

 

   - A P2P packet loss metric for the Path P = function {PL(Lpi),

   (i=1...K)}.

”

Is function of packet loss metric of individual link same as function of latency variation metric of individual link?

If they are not same, please use different function name, e.g., function a for packet loss, function b for latency variation?

 

Regards!

-Qin

 

 

 

 



_______________________________________________
pm-dir mailing list
pm-dir@ietf.org
https://www.ietf.org/mailman/listinfo/pm-dir

--------------030500060308090500020001-- From nobody Sun Feb 16 05:44:51 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7F1A01F5 for ; Sun, 16 Feb 2014 05:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.552 X-Spam-Level: ** X-Spam-Status: No, score=2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deluy-mNH4oS for ; Sun, 16 Feb 2014 05:44:44 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id 54FF11A01FB for ; Sun, 16 Feb 2014 05:44:44 -0800 (PST) Received: from mail-azure.research.att.com (unknown [135.207.255.18]) by mail-pink.research.att.com (Postfix) with ESMTP id A68F51202C1; Sun, 16 Feb 2014 08:48:11 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-azure.research.att.com (Postfix) with ESMTP id EE31CE0294; Sun, 16 Feb 2014 08:44:41 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Sun, 16 Feb 2014 08:44:41 -0500 From: "MORTON, ALFRED C (AL)" To: Paul Aitken , Qin Wu , Dhruv Dhody , "vishwas.manral@hp.com" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Date: Sun, 16 Feb 2014 08:44:39 -0500 Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: Ac8qnfH4XOR7rV6FQe+b6VVnzPHhdAAfzVpQ Message-ID: <2845723087023D4CB5114223779FA9C8BC5B9B95@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> <52FFEB1B.8010606@cisco.com> In-Reply-To: <52FFEB1B.8010606@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2845723087023D4CB5114223779FA9C8BC5B9B95njfpsrvexg8rese_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/Kgh_2vvfQPeqJhNrpVr3cOY9xxE Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 13:44:49 -0000 --_000_2845723087023D4CB5114223779FA9C8BC5B9B95njfpsrvexg8rese_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All Paul's suggestions for increasing clarity are fine with me. Al From: Paul Aitken [mailto:paitken@cisco.com] Sent: Saturday, February 15, 2014 5:33 PM To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali= @cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Al, All, For clarity, it would be better to name this as, "Average Delay Variation".= Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-= TLV". Several parts of the text (4.1 through 4.4) say, "This (field) carries the = (metric) over a configurable interval". Is it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)= ? P. On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: Hi Qin, authors, I read, in draft-ietf-ospf-te-metric-extensions: 4.3.4. Delay Variation This 24-bit field carries the average link delay variation over a configurable interval in micro-seconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. So this is an *average* DV, to my surprise, and therefore the sum function Qin proposed is reasonable. (it still doesn't say here what form of delay variation has been measured) However, delay variation is better characterized in summary statistics which describe the breadth of the DV distribution. In bimodal delay distributions, the average can be misleading. But you have what you have in draft-ietf-ospf-te-metric-extensions for now, and summing averages is an easy problem. Use RFC6049 for the other metrics, like loss and delay. regards, Al From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 9:36 PM To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com<= mailto:swallow@cisco.com>; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each s= ub path is millisecond. Using sum may be the worse case approximation of path DV and cause the gran= ularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definite= ly we Can improve granularity of measurement/calculation result but at the cost o= f Consuming more computation overhead. So there is tradeoff to pick one or an= other. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@= cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir --_000_2845723087023D4CB5114223779FA9C8BC5B9B95njfpsrvexg8rese_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= All Paul's suggestions for increasing clarity are fine with me.

Al

 

From: Paul Aitken [m= ailto:paitken@cisco.com]
Sent: Saturday, February 15, 2014 5:33 = PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral= @hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: Re: [pm-dir] Request for an RFC 6390 r= eview of draft-ietf-pce-pcep-service-aware-02

 

Al,= All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1= would be clearer as "Average Uni= directional Link Delay Sub-TLV".

Several parts of the text (4.1= through 4.4) say, "This (field) carries the (metric) over a configurable interval".

Is it impo= rtant or necessary to convey the configured size of the interval and the ti= me of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ?

= P.


On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:<= /p>

Hi Qin, authors,

 =

I read, in draft-ietf-ospf-te-metri= c-extensions:

4.3.4. Delay Variation

   This 24-bit field carries the average link delay variat= ion over a

   configurable inte= rval in micro-seconds, encoded as an integer value.

   When set to 0, it has not been measured. When set t= o the maximum

   value 16,777,2= 15 (16.777215 sec), then the delay is at least that

   value and may be larger.

 

So this is an *average<= /b>* DV, to my surprise,

and therefore th= e sum function Qin proposed is reasonable.

(it still doesn't say here what = form of delay variation has been measured)

However, delay variation is bett= er characterized in summary

statistics wh= ich describe the breadth of the DV distribution.

In bimodal delay distributions, the average can be misleading.

 

But = you have what you have in draft-ietf-ospf-te-metric-extens= ions

for now, and summing averages is= an easy problem.  Use RFC6049

for t= he other metrics, like loss and delay.

&n= bsp;

regards,

Al

 

 

= From: Qin Wu [mailto:bill.wu@huawe= i.com]
Sent: Friday, February 14, 2014 9:36 PM
To:= MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.= com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm= -dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-0= 2

 

Hi, Al:

You raise very go= od comments for this. Here are a few thoughts below.

<= p class=3DMsoNormal> <= /p>

Regards!<= /o:p>

-Qin

 =

From: MORTON, ALFRED C (AL)= [mailto:acmorton@att.com]
S= ent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dho= dy; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; k= e-kumaki@kddi.com
Cc: pm-d= ir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 rev= iew of draft-ietf-pce-pcep-service-aware-02

 

A few additional c= omments, we can help the authors a bit more

I think, but Qin was on the right track.

 

Al

 

Qin wrote:

3. Section 4= .2 says:

“

   - A Latency variation of link L is denot= ed DV(L).

 

   - A P2P latency variation metric for the Path= P =3D function {DV(Lpi),

   (i=3D1...K)}.

<= p class=3DMsoNormal>”

Why not sum of= latency variation metrics of individual links?

-------------------------------------------------------<= /o:p>

 

Sum is a rat= her worst-case approximation of the Path DV.

 

We have studied these sorts o= f e2e Path estimates in IPPM.

Packet Dela= y Variation is the most complex, but a couple of

possibilities for "function" are specified here:

http://tools.ietf.org/html/rfc6049#page-20

<= p class=3DMsoNormal> <= /p>

[Qin]: Yes, it is a rat hole that needs t= o be fixed.

Do you = know how the function defined in section 6.4.5.1 of RFC6049=

Can be applied to this draft and q= uoted as function of latency variation

For complete path from source to destination.

 =

It seems to me we only know delay variat= ion of each sub path, which is

gathered from link delay variation advertisement defined in

draft-ietf-ospf-te-m= etric-extensions. The unit of delay variation of each sub path

is millisecond.=

 

Using sum may be the worse case approximation = of path DV and cause the granularity

of measurement result very coarse, but the computation o= verhead

for calcula= tion of path DV can be minimized.

If we use integral function defined in section 6.4.5.1 of RF= C6049, definitely we

Consuming more = computation overhead. So there is tradeoff to pick one or another.

 

 

S= imilarly, we have functions, which could be cited as references=

in this draft, for loss

http://tools.i= etf.org/html/rfc6049#page-18

=  

[Qin]: Yes, I agree Composition Function defined in section 5= .1.5 can be

cited as reference for this draft.

 

and for mean delay

http://tools.ietf.or= g/html/rfc6049#section-4.2

 

So, no need to leave the "function"= ; unspecified and out of scope,

<= span style=3D'font-size:10.0pt;font-family:"Courier New","serif"'>assuming = your loss and delay metric definitions are compatible.

 

[Qin]: Exactly.

 

 

 

From: pm-dir [mailto:pm-= dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday= , February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cis= co.com; ke-kumaki@kddi.comCc: pm-dir@ietf.org
Su= bject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-s= ervice-aware-02

 = ;

Hi, a= uthors:

I am assigned Performance Directorate reviewer for this draft.

Here= is my review to this draft.

 

This draft uses the link latency, laten= cy variation and packet loss information for end to end path selection.

Th= e link latency, latency variation and packet loss metrics are defined in OS= PF-TE draft and ISIS-TE draft and

used to calculate path metrics described= in this draft, e.g., P2P latency metric, P2P latency variation metric, pac= ket loss

metric, P2MP latency metric, P2MP latency variation metric.

&nbs= p;

These calculated path metrics( 6 metrics) are carried in PCEP message us= ing the same Metric Object with different metric type. 

The calculate= d metrics are used as constraint for path computation

 

In this draft= , each calculated metric is discussed in each separate section from metric = name, metric description

perspective to measurement unit, calculation meth= od perspective.

IANA is also requested to register these 6 metric types. Th= erefore I believe this draft conforms to RFC6390 guideline.

However I have = a few comments regarding these metrics definitions.

1. Section 4, 2= nd paragraph says:

“

   This document defines the= following optional types for the METRIC

   object defined in [RF= C5440].

”

s/defined in [RFC5440]/defined in section 7.4 of [RFC5= 440]

 

2. Section 4.1 says:

“

   Link delay met= ric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-TE-EXPRESS].&nbs= p; P2P latency metric type of METRIC object in PCEP

   encodes th= e sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

 

&n= bsp;  - A Link delay metric of link L is denoted D(L).

 

 &n= bsp; - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.

&= nbsp;

   * T=3D13(TBA - IANA): Latency metric

”=

For people = who are not familiar with Metrics Object Format, it is not easy to figure o= ut what T=3D13 stands for? Would it be good to add some context text or

Int= roduce Metric Object format first.

 

 <= /o:p>

3. Sectio= n 4.2 says:

“

   - A Latency variation of link L is den= oted DV(L).

 

   - A P2P latency variation metric for the Pa= th P =3D function {DV(Lpi),

   (i=3D1...K)}.

”<= /o:p>

Why not sum = of latency variation metrics of individual links?

 <= /p>

4. Section 4.2 = says:

“

Specification of the "Function" used to drive l= atency variation

metric of a path from latency variation metrics of individ= ual links

along the path is beyond the scope of this document.<= /o:p>

”

s/dr= ive/derive

 

5. Section 4

Section 4.3 says:<= /p>

“Packet Loss= Metric metric type of METRIC Object”

Section 4.2 says:=

“P2P = latency variation metric type of METRIC

   Object”

For cons= istency, you may either use “xx Metric metric type” or “x= x metric type of Metric Object”.

 

6.Section 4.3 says:=

&#= 8220;

   The end to end Packet Loss for the path is represented b= y this

   metric.

 

   - A Packet loss of link L i= s denoted PL(L).

 

   - A P2P packet loss metric for the Pat= h P =3D function {PL(Lpi),

   (i=3D1...K)}.

=

”

Is function o= f packet loss metric of individual link same as function of latency variati= on metric of individual link?

If they are not same, please use different fu= nction name, e.g., function a for packet loss, function b for latency varia= tion?

 

Regards!

-Qin

 <= /o:p>

 

 = ;

 




_________________=
______________________________
pm-dir mailing list
pm-dir@ietf.org
https://www.ietf.org/mailman/listinfo/pm-dir

 

= --_000_2845723087023D4CB5114223779FA9C8BC5B9B95njfpsrvexg8rese_-- From nobody Sun Feb 16 14:07:47 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9126B1A02C4 for ; Sun, 16 Feb 2014 14:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.449 X-Spam-Level: X-Spam-Status: No, score=-7.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IVM-2JPJD8G for ; Sun, 16 Feb 2014 14:07:45 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DF31F1A02AA for ; Sun, 16 Feb 2014 14:07:44 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s1GM7fDV015183 for ; Sun, 16 Feb 2014 23:07:41 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s1GM7NwA014019 for ; Sun, 16 Feb 2014 23:07:33 +0100 (CET) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id s1GM7LRP002268 for pm-dir@ietf.org; Sun, 16 Feb 2014 23:07:21 +0100 (CET) Date: Sun, 16 Feb 2014 23:07:21 +0100 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20140216220721.GA2266@sweet-brew-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/gpjkTAP8Un1-MjsRuxTH-iNAyVg Subject: [pm-dir] Performance metrics doctors generated email X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 22:07:46 -0000 Dear all, This is an automatically generated email. It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference. It also lists all the IETF internet-drafts that contain "performance metric". Regards, Benoit =========================================================== Normative References -------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01Active draft-ietf-xrblock-rtcp-xr-psi-decodability-01 Active draft-ietf-xrblock-rtcp-xr-qoe-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state drafts containing performance metric ------------------------------------ draft-ietf-alto-deployments-09 Active draft-ietf-bmwg-sip-bench-term-09 Active draft-ietf-cdni-footprint-capabilities-semantics-02Active draft-ietf-idr-te-pm-bgp-00 Active draft-ietf-ippm-2330-update-02 Active draft-ietf-ippm-lmap-path-02 Active draft-ietf-ippm-model-based-metrics-02 Active draft-ietf-ippm-rate-problem-05 Active draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-lmap-use-cases-02 Active draft-ietf-mmusic-sdp-mux-attributes-01 Active draft-ietf-nvo3-framework-05 In IESG processing - ID Tracker state draft-ietf-opsawg-oam-overview-13 Active draft-ietf-pce-pcep-service-aware-03 Active draft-ietf-ppsp-base-tracker-protocol-03 Active draft-ietf-ppsp-peer-protocol-08 Active draft-ietf-rtcweb-rtp-usage-12 Active draft-ietf-trill-loss-delay-02 Active draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 Active draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01Active draft-ietf-xrblock-rtcp-xr-psi-decodability-01 Active draft-ietf-xrblock-rtcp-xr-qoe-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xt-discard-metrics-00 Active From nobody Mon Feb 17 01:40:06 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36F1A042C for ; Mon, 17 Feb 2014 01:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.749 X-Spam-Level: X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jehtVv2WUPFv for ; Mon, 17 Feb 2014 01:40:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EF8591A0394 for ; Mon, 17 Feb 2014 01:39:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDQ94450; Mon, 17 Feb 2014 09:39:56 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 09:39:49 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 09:39:54 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 17 Feb 2014 17:39:46 +0800 From: Qin Wu To: "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" Thread-Topic: pm-dir meeting at IETF-89 Thread-Index: Ac8qWCQd3BO9MOp0Ri6HIkq3XOe+6QBa39XQ Date: Mon, 17 Feb 2014 09:39:46 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/5ptcPlTXywo6AKFgZ5DTr5NZMRk Subject: Re: [pm-dir] pm-dir meeting at IETF-89 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:40:04 -0000 Al: Thanks for your brief introduction, I have no conflict with your proposed m= eet date based on my present schedule. Regards! -Qin -----Original Message----- From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of MORTON, ALFRED C= (AL) Sent: Saturday, February 15, 2014 10:21 PM To: pm-dir@ietf.org Subject: [pm-dir] pm-dir meeting at IETF-89 pm-dir members, As you can see: https://docs.google.com/spreadsheet/ccc?key=3D0AmKrqWIOBsprdGZqMnB6dmx5bFJv= VUhta3VLSjl3SkE&usp=3Dsharing We are in pretty good shape at the moment on=20 volunteers for reviews and completed reviews this year. Thanks to all who have contributed! I would like to welcome a new member to the Directorate, Qin Wu. =20 This will be no surprise to those following the mailing list, as he has completed three reviews in the last week. I would like to propose a brief meeting of pm-dir at IETF-89, primarily to discuss membership review and any topics members would like to raise. 1300-1400 GMT Tuesday Afternoon Session I I note that IPFIX has been cancelled, and perhaps we could=20 use that meeting space or an alternate space. In any case, let's meet at IETF registration at 1300=20 and go from there. If you'd like to attend but have a conflict at that time, please suggest an alternate. regards, Al pm-dir admin _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir From nobody Mon Feb 17 03:42:20 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5219B1A048E for ; Mon, 17 Feb 2014 03:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGx1ousOayHV for ; Mon, 17 Feb 2014 03:42:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 600D91A047D for ; Mon, 17 Feb 2014 03:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1411; q=dns/txt; s=iport; t=1392637333; x=1393846933; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Kt0SCAruCan8ysfkUt6bovc+e0oSFLJP0dWz0HUhOSs=; b=Iry780/kTYjS1rtR0tyQAFKl38bteSmXdl2N4qIHdMfMHGWhMdEN052C mQcFrQh1AFscxuG9yYJkUDX5ReFTw6kAT3RR2kHCZiwVoRqGhiwRY+EjE B5/IikXN6pwpmdbP/a8NYPSTD4Pckl04DWFt1YKvYfOKvVbX5Ol6Rqma+ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAMj0AVOQ/khN/2dsb2JhbABZgwY4wAuBHhZ0giYBAQQBAQE1NhsLISUPAhYwBgEMBgIBAYgBDctEEwSPCIQ4AQOYLIZHik6BDoMtPIEsBA X-IronPort-AV: E=Sophos;i="4.95,860,1384300800"; d="scan'208";a="5303525" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 17 Feb 2014 11:42:12 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1HBgBUV006255; Mon, 17 Feb 2014 11:42:11 GMT Message-ID: <5301F593.90909@cisco.com> Date: Mon, 17 Feb 2014 11:42:11 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" , "pm-dir@ietf.org" References: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/nzetykNfabr5-XzXeea8mhs-FDE Subject: Re: [pm-dir] pm-dir meeting at IETF-89 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:42:18 -0000 Dear all, > pm-dir members, > > As you can see: > https://docs.google.com/spreadsheet/ccc?key=0AmKrqWIOBsprdGZqMnB6dmx5bFJvVUhta3VLSjl3SkE&usp=sharing > > We are in pretty good shape at the moment on > volunteers for reviews and completed reviews > this year. Thanks to all who have contributed! > > I would like to welcome a new member to the Directorate, > Qin Wu. > This will be no surprise to those following the mailing list, > as he has completed three reviews in the last week. Welcome Qin. Qin had many interactions with the PM-DIR, as he authored multiple XRBLOCK. So he knows already what the PM-DIR looks for. > I would like to propose a brief meeting of pm-dir at IETF-89, > primarily to discuss membership review and any topics members > would like to raise. > > 1300-1400 GMT Tuesday Afternoon Session I > > I note that IPFIX has been cancelled, and perhaps we could > use that meeting space or an alternate space. > In any case, let's meet at IETF registration at 1300 > and go from there. Good initiative Al. I booked the IESG breakout room (room TBD) for this. Regards, Benoit > > If you'd like to attend but have a conflict at that time, > please suggest an alternate. > > regards, > Al > pm-dir admin > > _______________________________________________ > pm-dir mailing list > pm-dir@ietf.org > https://www.ietf.org/mailman/listinfo/pm-dir > From nobody Mon Feb 17 05:55:57 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB171A01F6 for ; Mon, 17 Feb 2014 05:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4kCyQ8aGBRo for ; Mon, 17 Feb 2014 05:55:54 -0800 (PST) Received: from mail-red.research.att.com (mail-red.research.att.com [204.178.8.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4231A01F1 for ; Mon, 17 Feb 2014 05:55:54 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-red.research.att.com (Postfix) with ESMTP id 70C225542E9; Mon, 17 Feb 2014 08:59:33 -0500 (EST) Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 7DF28F0374; Mon, 17 Feb 2014 08:55:51 -0500 (EST) Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Mon, 17 Feb 2014 08:55:51 -0500 From: "MORTON, ALFRED C (AL)" To: Benoit Claise Date: Mon, 17 Feb 2014 08:53:28 -0500 Thread-Topic: [pm-dir] pm-dir meeting at IETF-89 Thread-Index: Ac8r1VDvXsrepqdITFOEgu9tRQdhxAAElIk8 Message-ID: <2845723087023D4CB5114223779FA9C8BC2BCF1A@njfpsrvexg8.research.att.com> References: <2845723087023D4CB5114223779FA9C8BC5B9B7A@njfpsrvexg8.research.att.com>, <5301F593.90909@cisco.com> In-Reply-To: <5301F593.90909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/dElVGBq2a1Ho63XkhcsQv6hTqPU Cc: "pm-dir@ietf.org" Subject: Re: [pm-dir] pm-dir meeting at IETF-89 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:55:55 -0000 Thanks! ________________________________________ From: Benoit Claise [bclaise@cisco.com] ... > I would like to propose a brief meeting of pm-dir at IETF-89, > primarily to discuss membership review and any topics members > would like to raise. > > 1300-1400 GMT Tuesday Afternoon Session I > > I note that IPFIX has been cancelled, and perhaps we could > use that meeting space or an alternate space. > In any case, let's meet at IETF registration at 1300 > and go from there. Good initiative Al. I booked the IESG breakout room (room TBD) for this. Regards, Benoit From nobody Mon Feb 17 08:32:40 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9D21A0526 for ; Mon, 17 Feb 2014 08:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6QqlTUqgfOP for ; Mon, 17 Feb 2014 08:23:01 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C51A052A for ; Mon, 17 Feb 2014 08:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56022; q=dns/txt; s=iport; t=1392654179; x=1393863779; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=CpEDlWYjJ/geZwyhPfDSURgQe+aSRmTieSpyeUrM744=; b=HRS8YifxKCHufZ7BPUstGmLvmBMhwMSST95XH3PxFzzhANwa4XSpOXCF 2/AY9LbGSiYQNGSyxH+MBVsTbBkaeR7BTTb7elCo8lgOeVffAyxaNfC2r n5pjkvckI+rwGuG5OWfZMASNkARSPZrkej/s/CWiG1ISEhaUhgsNPeBNe c=; X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208,217";a="102967939" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 17 Feb 2014 16:20:58 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1HGKvMc013998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 16:20:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.215]) by xhc-rcd-x04.cisco.com ([::1]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 10:20:57 -0600 From: "Zafar Ali (zali)" To: Dhruv Dhody , "'MORTON, ALFRED C (AL)'" , "Paul Aitken (paitken)" , "'Qin Wu'" , "George Swallow (swallow)" , "ke-kumaki@kddi.com" Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: AQHPKp3vbZG8Ac1W0U2CJSFKwlH61Zq4SdKAgAGscQD//754gA== Date: Mon, 17 Feb 2014 16:20:56 +0000 Message-ID: In-Reply-To: <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.249.227] Content-Type: multipart/alternative; boundary="_000_CF27A088968A2zaliciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/4it2QRW5qGOF2ztInAtTlPLkkgk X-Mailman-Approved-At: Mon, 17 Feb 2014 08:32:39 -0800 Cc: "dhruv.ietf@gmail.com" , "vishwas.ietf@gmail.com" , "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:23:11 -0000 --_000_CF27A088968A2zaliciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi: This is my understanding that we need to just use the baseline IGP drafts f= or definition of all parameters we are using in this draft. So would it be = fair that this draft just puts-in reference for the parameters used and poi= nt to IGO (OSPF) doc for the definition. We should not copy any text from I= GP drafts or any other RFC (just pointer). That will also improve readabili= ty and consistency for this draft. Thanks Regards =85 Zafar From: "dhruv.dhody@huawei.com" > Date: Monday, February 17, 2014 10:18 AM To: "'MORTON, ALFRED C (AL)'" >, = "Paul Aitken (paitken)" >, 'Qin= Wu' >, zali >, "George Swallow (swallow)" >, "ke-kumaki@kddi.com" > Cc: "pm-dir@ietf.org" >, "dhruv.ietf@gmail.com" >, 'Vishwas Manral' > Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi All, The authors are grateful for the comments and have prepared an updated vers= ion. Qin, Could you have a look and suggest if we have addressed your comments & chan= ges are acceptable to you? Regarding interval, see my comment inline. Regards, Dhruv From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Sunday, February 16, 2014 7:15 PM To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 All Paul's suggestions for increasing clarity are fine with me. Al From: Paul Aitken [mailto:paitken@cisco.com] Sent: Saturday, February 15, 2014 5:33 PM To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@ci= sco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Al, All, For clarity, it would be better to name this as, "Average Delay Variation".= Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-= TLV". Several parts of the text (4.1 through 4.4) say, "This (field) carries the = (metric) over a configurable interval". Is it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)= ? [DhruvDhody>] The metrics we have in this I.D. are calculated based on lin= k metrics defined in OSPF-TE draft [1], and is not measured directly. Therefore the time of the interval is same as link metrics defined in OSPF-= TE draft. OSPF-TE draft section 7 discusses this. [2] We do not see a reason to mention this in the PCE I.D. [1]http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05 [2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#sect= ion-7 P. On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: Hi Qin, authors, I read, in draft-ietf-ospf-te-metric-extensions: 4.3.4. Delay Variation This 24-bit field carries the average link delay variation over a configurable interval in micro-seconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. So this is an *average* DV, to my surprise, and therefore the sum function Qin proposed is reasonable. (it still doesn't say here what form of delay variation has been measured) However, delay variation is better characterized in summary statistics which describe the breadth of the DV distribution. In bimodal delay distributions, the average can be misleading. But you have what you have in draft-ietf-ospf-te-metric-extensions for now, and summing averages is an easy problem. Use RFC6049 for the other metrics, like loss and delay. regards, Al From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 9:36 PM To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com<= mailto:swallow@cisco.com>; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: =93 - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. =94 Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each s= ub path is millisecond. Using sum may be the worse case approximation of path DV and cause the gran= ularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definite= ly we Can improve granularity of measurement/calculation result but at the cost o= f Consuming more computation overhead. So there is tradeoff to pick one or an= other. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@= cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: =93 This document defines the following optional types for the METRIC object defined in [RFC5440]. =94 s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: =93 Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric =94 For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: =93 - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. =94 Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: =93 Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. =94 s/drive/derive 5. Section 4 Section 4.3 says: =93Packet Loss Metric metric type of METRIC Object=94 Section 4.2 says: =93P2P latency variation metric type of METRIC Object=94 For consistency, you may either use =93xx Metric metric type=94 or =93xx me= tric type of Metric Object=94. 6.Section 4.3 says: =93 The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. =94 Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir --_000_CF27A088968A2zaliciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <239B6C16356B844AAB5D19D4B9682785@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi: 

This is my understanding that we need to just use the baseline IGP dra= fts for definition of all parameters we are using in this draft. So would i= t be fair that this draft just puts-in reference for the parameters used an= d point to IGO (OSPF) doc for the definition. We should not copy any text from IGP drafts or any other = RFC (just pointer). That will also improve readability and consistency= for this draft. 

Thanks

Regards =85 Zafar

From: "dhruv.dhody@huawei.com" <dhruv.dhody@huawei.com>
Date: Monday, February 17, 2014 10:= 18 AM
To: "'MORTON, ALFRED C (AL)'&q= uot; <acmorton@att.com>, &quo= t;Paul Aitken (paitken)" <pait= ken@cisco.com>, 'Qin Wu' <b= ill.wu@huawei.com>, zali <zali@cisco.com>, "G= eorge Swallow (swallow)" <swal= low@cisco.com>, "ke-kumak= i@kddi.com" <ke-kumaki@kd= di.com>
Cc: "pm-dir@ietf.org" <= pm-dir@ietf.org>, "dhru= v.ietf@gmail.com" <dhru= v.ietf@gmail.com>, 'Vishwas Manral' <vishwas.iet= f@gmail.com>
Subject: RE: [pm-dir] Request for a= n RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

Hi All,

 

The authors are grateful for the = comments and have prepared an updated version.

 

Qin,

Could you have a look and suggest= if we have addressed your comments & changes are acceptable to you?

 

Regarding interval, see my commen= t inline.

 

Regards,

Dhruv

 

From: MORTON, AL= FRED C (AL) [mailto:acmorton@att.com]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

All Paul's suggestions for increasing clarity = are fine with me.

Al

 

From: Paul Aitke= n [mailto:paitken@cisco.com]
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

Al, All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be cle= arer as "Average Unidirectional L= ink Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries= the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)= ?

[DhruvDhody>] The metric= s we have in this I.D.  are calculated based on link metrics defined i= n OSPF-TE draft [1], and is not measured directly.

Therefore the time of the i= nterval is same as link metrics defined in OSPF-TE draft. OSPF-TE draft sec= tion 7 discusses this. [2]

We do not see a reason to m= ention this in the PCE I.D.


[1]http://tools.ietf.org/htm= l/draft-ietf-ospf-te-metric-extensions-05

[2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-= 7


P.


On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:

Hi Qin, authors,

 

I read, in draft-ietf-ospf-te-metric-extensions:

4.3.4. Delay Variation

   This 24-bit field carries the average link delay var= iation over a

   configurable interval in micro-seconds, encoded as a= n integer value.

   When set to 0, it has not been measured. When set to= the maximum

   value 16,777,215 (16.777215 sec), then the delay is = at least that

   value and may be larger.

 

So this is an *average* DV, to my surprise,

and therefore the sum function Qin proposed is reasonable.=

 

(it still doesn't say here what form of delay variation has been = measured)

 

However, delay variation is better characterized in summary

statistics which describe the breadth of the DV distribution.

In bimodal delay distributions, the average can be misleading.

 

But you have what you have in draft-ietf-ospf-te-metric-extensions

for now, and summing averages is an easy problem.  Use RFC60= 49

for the other metrics, like loss and delay.

 

regards,

Al

 

 

From: Qin Wu [ma= ilto:bill.wu@huawei.com]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

Hi, Al:

You raise very good co= mments for this. Here are a few thoughts below.

 

Regards!

-Qin=

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; vi= shwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

A few additional comments, we can help the authors a bit more

I think, but Qin was on the right track.

 

Al

 

Qin wrote:

3. Section 4.2 s= ays:

=93

   - A La= tency variation of link L is denoted DV(L).

 <= /o:p>

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),

   (i=3D1= ...K)}.

=94

Why not sum of late= ncy variation metrics of individual links?

-------------------------------------------------------

 

Sum is a rather worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estimates in IPPM.=

Packet Delay Variation is the most complex, but a couple of

possibilities for "function" are specified here:=

http://too= ls.ietf.org/html/rfc6049#page-20

 

[Qin]: Yes, it is a ra= t hole that needs to be fixed.

Do you know how the fu= nction defined in section 6.4.5.1 of RFC6049

Can be applied to this= draft and quoted as function of latency variation

For complete path from= source to destination.

 =

It seems to me we only= know delay variation of each sub path, which is

gathered from link del= ay variation advertisement defined in

draft-ietf-ospf-te-met= ric-extensions. The unit of delay variation of each sub path

is millisecond.=

 =

Using sum may be the w= orse case approximation of path DV and cause the granularity

of measurement result = very coarse, but the computation overhead

for calculation of pat= h DV can be minimized.

If we use integral fun= ction defined in section 6.4.5.1 of RFC6049, definitely we<= /o:p>

Can improve granularit= y of measurement/calculation result but at the cost of

Consuming more computa= tion overhead. So there is tradeoff to pick one or another.=

 =

 <= /p>

Similarly, we have functions, which could be cited as references<= /span>

in this draft, for loss

http://too= ls.ietf.org/html/rfc6049#page-18

 <= /p>

[Qin]: Yes, I agree= Composition Function defined in section 5.1.5 can be=

cited as reference = for this draft.

 

and for mean delay

http:/= /tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to leave the "function" unspecified and out= of scope,

assuming your loss and delay metric definitions are compatible.

 <= /p>

[Qin]: Exactly.=

 

 

 

From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.ma= nral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-p= cep-service-aware-02

 

Hi, authors:=

I am assigned Perfo= rmance Directorate reviewer for this draft.

Here is my review t= o this draft.

 <= /o:p>

This draft uses the= link latency, latency variation and packet loss information for end to end= path selection.

The link latency, l= atency variation and packet loss metrics are defined in OSPF-TE draft and I= SIS-TE draft and

used to calculate p= ath metrics described in this draft, e.g., P2P latency metric, P2P latency = variation metric, packet loss

metric, P2MP latenc= y metric, P2MP latency variation metric.

 <= /o:p>

These calculated pa= th metrics( 6 metrics) are carried in PCEP message using the same Metric Ob= ject with different metric type. 

The calculated metr= ics are used as constraint for path computation

 <= /o:p>

In this draft, each= calculated metric is discussed in each separate section from metric name, = metric description

perspective to meas= urement unit, calculation method perspective.

IANA is also reques= ted to register these 6 metric types. Therefore I believe this draft confor= ms to RFC6390 guideline.

However I have a fe= w comments regarding these metrics definitions.

1. Section 4, 2<= sup>nd paragraph says:

=93

   This d= ocument defines the following optional types for the METRIC

   object= defined in [RFC5440].

=94

s/defined in [= RFC5440]/defined in section 7.4 of [RFC5440]

 <= /o:p>

2. Section 4.1 s= ays:

=93

   Link d= elay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-= TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP<= o:p>

   encode= s the sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

 <= /o:p>

   - A Li= nk delay metric of link L is denoted D(L).

 <= /o:p>

   - A P2= P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.<= /o:p>

 <= /o:p>

   * T=3D= 13(TBA - IANA): Latency metric

=94

For people who are = not familiar with Metrics Object Format, it is not easy to figure out what = T=3D13 stands for? Would it be good to add some context text or=

Introduce Metric Ob= ject format first.

 

 

3. Section 4.2 s= ays:

=93

   - A La= tency variation of link L is denoted DV(L).

 <= /o:p>

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),

   (i=3D1= ...K)}.

=94

Why not sum of late= ncy variation metrics of individual links?

 <= /o:p>

4. Section 4.2 s= ays:

=93

Specification of th= e "Function" used to drive latency variation

metric of a path fr= om latency variation metrics of individual links

along the path is b= eyond the scope of this document.

=94

s/drive/derive

 <= /o:p>

5. Section 4

Section 4.3 says:

=93Packet Loss Metr= ic metric type of METRIC Object=94

Section 4.2 says:

=93P2P latency vari= ation metric type of METRIC

   Object= =94

For consistency, yo= u may either use =93xx Metric metric type=94 or =93xx metric type of Metric= Object=94.

 <= /o:p>

6.Section 4.3 sa= ys:

=93

   The en= d to end Packet Loss for the path is represented by this<= /p>

   metric= .

 <= /o:p>

   - A Pa= cket loss of link L is denoted PL(L).

 <= /o:p>

   - A P2= P packet loss metric for the Path P =3D function {PL(Lpi),

   (i=3D1= ...K)}.

=94

Is function of pack= et loss metric of individual link same as function of latency variation met= ric of individual link?

If they are not sam= e, please use different function name, e.g., function a for packet loss, fu= nction b for latency variation?

 <= /o:p>

Regards!

-Qin

 

 <= /o:p>

 <= /o:p>

 



_______________________________________________
pm-dir mailing list
pm-dir@ietf.org

https://www.i=
etf.org/mailman/listinfo/pm-dir

 

 --_000_CF27A088968A2zaliciscocom_-- From nobody Mon Feb 17 08:33:05 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955C01A0211 for ; Mon, 17 Feb 2014 07:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.653 X-Spam-Level: ** X-Spam-Status: No, score=2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AMeODiV_KO8 for ; Mon, 17 Feb 2014 07:18:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF91A0207 for ; Mon, 17 Feb 2014 07:18:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBF42232; Mon, 17 Feb 2014 15:18:52 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 15:18:43 +0000 Received: from LGGEML422-HUB.china.huawei.com (10.72.61.118) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 17 Feb 2014 15:18:48 +0000 Received: from HTIPL8571 (10.195.41.103) by lggeml422-hub.china.huawei.com (10.72.61.118) with Microsoft SMTP Server id 14.3.158.1; Mon, 17 Feb 2014 23:18:23 +0800 From: Dhruv Dhody To: "'MORTON, ALFRED C (AL)'" , "'Paul Aitken'" , "'Qin Wu'" , , , References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> <52FFEB1B.8010606@cisco.com> <2845723087023D4CB5114223779FA9C8BC5B9B95@njfpsrvexg8.research.att.com> In-Reply-To: <2845723087023D4CB5114223779FA9C8BC5B9B95@njfpsrvexg8.research.att.com> Date: Mon, 17 Feb 2014 20:48:06 +0530 Message-ID: <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0368_01CF2C21.95FF4070" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8qnfH4XOR7rV6FQe+b6VVnzPHhdAAfzVpQADUwpAA= Content-Language: en-us X-Originating-IP: [10.195.41.103] X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/M04TEIyWJ04vRh29xDsUsAwum9Y X-Mailman-Approved-At: Mon, 17 Feb 2014 08:32:58 -0800 Cc: dhruv.ietf@gmail.com, vishwas.ietf@gmail.com, pm-dir@ietf.org Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:19:04 -0000 ------=_NextPart_000_0368_01CF2C21.95FF4070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0369_01CF2C21.95FF4070" ------=_NextPart_001_0369_01CF2C21.95FF4070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, The authors are grateful for the comments and have prepared an updated version. Qin, Could you have a look and suggest if we have addressed your comments & changes are acceptable to you? Regarding interval, see my comment inline. Regards, Dhruv From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Sunday, February 16, 2014 7:15 PM To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 All Paul's suggestions for increasing clarity are fine with me. Al From: Paul Aitken [mailto:paitken@cisco.com] Sent: Saturday, February 15, 2014 5:33 PM To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Al, All, For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-TLV". Several parts of the text (4.1 through 4.4) say, "This (field) carries the (metric) over a configurable interval". Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ? [DhruvDhody>] The metrics we have in this I.D. are calculated based on link metrics defined in OSPF-TE draft [1], and is not measured directly. Therefore the time of the interval is same as link metrics defined in OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2] We do not see a reason to mention this in the PCE I.D. [1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05 [2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-7 P. On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: Hi Qin, authors, I read, in draft-ietf-ospf-te-metric-extensions: 4.3.4. Delay Variation This 24-bit field carries the average link delay variation over a configurable interval in micro-seconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. So this is an *average* DV, to my surprise, and therefore the sum function Qin proposed is reasonable. (it still doesn't say here what form of delay variation has been measured) However, delay variation is better characterized in summary statistics which describe the breadth of the DV distribution. In bimodal delay distributions, the average can be misleading. But you have what you have in draft-ietf-ospf-te-metric-extensions for now, and summing averages is an easy problem. Use RFC6049 for the other metrics, like loss and delay. regards, Al From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 9:36 PM To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P = function {DV(Lpi), (i=1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each sub path is millisecond. Using sum may be the worse case approximation of path DV and cause the granularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definitely we Can improve granularity of measurement/calculation result but at the cost of Consuming more computation overhead. So there is tradeoff to pick one or another. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss information for end to end path selection. The link latency, latency variation and packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency metric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believe this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. * T=13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy to figure out what T=13 stands for? Would it be good to add some context text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P = function {DV(Lpi), (i=1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric type of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P = function {PL(Lpi), (i=1...K)}. " Is function of packet loss metric of individual link same as function of latency variation metric of individual link? If they are not same, please use different function name, e.g., function a for packet loss, function b for latency variation? Regards! -Qin _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir ------=_NextPart_001_0369_01CF2C21.95FF4070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

The authors are grateful for the comments and have prepared an = updated version.

 

Qin,

Could you have a look and suggest if we have addressed your comments = & changes are acceptable to you?

 

Regarding interval, see my comment inline.

 

Regards,

Dhruv

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: = Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; = Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; = ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: = [pm-dir] Request for an RFC 6390 review of = draft-ietf-pce-pcep-service-aware-02

 

All Paul's suggestions for increasing clarity are = fine with me.

Al

 

From: Paul Aitken [mailto:paitken@cisco.com] =
Sent: Saturday, February 15, 2014 5:33 PM
To: = MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: = pm-dir@ietf.org
Subject: = Re: [pm-dir] Request for an RFC 6390 review of = draft-ietf-pce-pcep-service-aware-02

 

Al, = All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, = 4.1 would be clearer as "Average Unidirectional Link Delay = Sub-TLV".

Several parts of the text (4.1 through 4.4) say, = "This (field) carries the (metric) over a configurable interval".

Is = it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes = ago) ?

[DhruvDhody>] The metrics we have in this I.D.  are = calculated based on link metrics defined in OSPF-TE draft [1], and is = not measured directly.

Therefore the time of the interval is same as link metrics defined in = OSPF-TE draft. OSPF-TE draft section 7 discusses this. = [2]

We do not see a reason to mention this in the PCE = I.D.


[1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05=

[2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensi= ons-05#section-7


P.


On 15/02/2014 13:42, MORTON, ALFRED = C (AL) wrote:

Hi Qin, authors,

 

I read, in = draft-ietf-ospf-te-metric-extensions<= span style=3D'font-size:10.0pt;font-family:"Courier = New"'>:

4.3.4. Delay = Variation

   This = 24-bit field carries the average link delay variation over = a

   = configurable interval in micro-seconds, encoded as an integer = value.

   When = set to 0, it has not been measured. When set to the = maximum

   value = 16,777,215 (16.777215 sec), then the delay is at least = that

   value = and may be larger.

 

So this is an = *average* DV, to my surprise,

and therefore the sum function Qin proposed is = reasonable.

 

(it still doesn't = say here what form of delay variation has been = measured)

 

However, delay = variation is better characterized in summary

statistics which describe the breadth of the DV = distribution.

In bimodal delay = distributions, the average can be misleading.

 

But you have what = you have in draft-ietf-ospf-te-metric-extensions<= o:p>

for now, and = summing averages is an easy problem.  Use = RFC6049

for the other = metrics, like loss and delay.

 

regards,

Al

 

 

From:= = Qin Wu [mailto:bill.wu@huawei.com] =
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, = ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: = pm-dir@ietf.org
Subject: = RE: [pm-dir] Request for an RFC 6390 review of = draft-ietf-pce-pcep-service-aware-02

 

Hi, Al:

You raise very good = comments for this. Here are a few thoughts = below.

 

Regards!

-Qin

 

From:= = MORTON, ALFRED C (AL) [mailto:acmorton@att.com] =
Sent: Friday, February 14, 2014 10:20 PM
To: Qin = Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: = pm-dir@ietf.org
Subject: = RE: [pm-dir] Request for an RFC 6390 review of = draft-ietf-pce-pcep-service-aware-02

 

A few additional = comments, we can help the authors a bit more

I think, but Qin was on the right track.

 

Al

 

Qin = wrote:

3. Section 4.2 = says:

“

   - A = Latency variation of link L is denoted DV(L).

 

   - A P2P = latency variation metric for the Path P =3D function = {DV(Lpi),

   = (i=3D1...K)}.

”

Why not sum of = latency variation metrics of individual links?

-------------------------------------------------------=

 

Sum is a rather = worst-case approximation of the Path DV.

 

We have studied = these sorts of e2e Path estimates in IPPM.

Packet Delay Variation is the most complex, but a couple = of

possibilities for = "function" are specified here:

http://tools.ietf.org= /html/rfc6049#page-20

 

[Qin]: Yes, it is a rat hole that needs to be = fixed.

Do you know how the function defined in section = 6.4.5.1 of RFC6049

Can be applied to this draft and quoted as = function of latency variation

For complete path from source to = destination.

 

It seems to me we only know delay variation of = each sub path, which is

gathered from link delay variation = advertisement defined in

draft-ietf-ospf-te-metric-extensions. The unit = of delay variation of each sub path

is millisecond.

 

Using sum may be the worse case approximation = of path DV and cause the granularity

of measurement result very coarse, but the = computation overhead

for calculation of path DV can be = minimized.

If we use integral function defined in section = 6.4.5.1 of RFC6049, definitely we

Can improve granularity of = measurement/calculation result but at the cost = of

Consuming more computation overhead. So there = is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as = references

in this draft, for = loss

http://tools.ietf.org= /html/rfc6049#page-18

 

[Qin]: Yes, I agree = Composition Function defined in section 5.1.5 can = be

cited as reference for this = draft.

 

and for mean delay

http://tools.ietf= .org/html/rfc6049#section-4.2

 

So, no need to = leave the "function" unspecified and out of = scope,

assuming your loss = and delay metric definitions are compatible.

 

[Qin]: = Exactly.

 

 

 

 

Hi, authors:

I am assigned = Performance Directorate reviewer for this draft.

Here is my review to = this draft.

 

This draft uses the = link latency, latency variation and packet loss information for end to = end path selection.

The link latency, latency variation and = packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and =

used to calculate path metrics described in = this draft, e.g., P2P latency metric, P2P latency variation metric, = packet loss

metric, P2MP latency metric, P2MP latency = variation metric.

 

These calculated path = metrics( 6 metrics) are carried in PCEP message using the same Metric = Object with different metric type. 

The calculated = metrics are used as constraint for path computation =

 

In this draft, each = calculated metric is discussed in each separate section from metric = name, metric description

perspective to = measurement unit, calculation method = perspective.

IANA is also requested to register these 6 = metric types. Therefore I believe this draft conforms to RFC6390 = guideline.

However I have a few comments regarding these = metrics definitions.

1. Section 4, 2nd paragraph = says:

“

   This = document defines the following optional types for the = METRIC

   object defined in = [RFC5440].

”

s/defined in = [RFC5440]/defined in section 7.4 of [RFC5440]

 

2. Section 4.1 = says:

“

   Link = delay metric is defined in [OSPF-TE-EXPRESS] and

   = [ISIS-TE-EXPRESS].  P2P latency metric type of METRIC object in = PCEP

   encodes the sum of the link = delay metric of all links along a P2P

   = Path.  Specifically, extending on the above mentioned = terminology:

 

   - A Link = delay metric of link L is denoted D(L).

 

   - A P2P = latency metric for the Path P =3D Sum {D(Lpi), = (i=3D1...K)}.

 

   * = T=3D13(TBA - IANA): Latency metric

”

For people who are = not familiar with Metrics Object Format, it is not easy to figure out = what T=3D13 stands for? Would it be good to add some context text = or

Introduce Metric Object format = first.

 

 

3. Section 4.2 = says:

“

   - A = Latency variation of link L is denoted DV(L).

 

   - A P2P = latency variation metric for the Path P =3D function = {DV(Lpi),

   = (i=3D1...K)}.

”

Why not sum of = latency variation metrics of individual links?

 

4. Section 4.2 = says:

“

Specification of the = "Function" used to drive latency = variation

metric of a path from latency variation = metrics of individual links

along the path is = beyond the scope of this document.

”

s/drive/derive

 

5. Section = 4

Section 4.3 says:

“Packet Loss = Metric metric type of METRIC Object”

Section 4.2 = says:

“P2P latency variation metric type of = METRIC

   = Object”

For consistency, you may either use “xx = Metric metric type” or “xx metric type of Metric = Object”.

 

6.Section 4.3 = says:

“

   The end = to end Packet Loss for the path is represented by = this

   metric.

 

   - A = Packet loss of link L is denoted PL(L).

 

   - A P2P = packet loss metric for the Path P =3D function = {PL(Lpi),

   = (i=3D1...K)}.

”

Is function of packet = loss metric of individual link same as function of latency variation = metric of individual link?

If they are not same, = please use different function name, e.g., function a for packet loss, = function b for latency variation?

 

Regards!

-Qin

 

 

 

 



______________________=
_________________________
pm-dir mailing =
list
pm-dir@ietf.org
=
https://www.ietf.or=
g/mailman/listinfo/pm-dir

 

------=_NextPart_001_0369_01CF2C21.95FF4070-- ------=_NextPart_000_0368_01CF2C21.95FF4070 Content-Type: text/html; name="Diff draft-ietf-pce-pcep-service-aware-02.txt - draft-ietf-pce-pcep-service-aware-04.txt.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Diff draft-ietf-pce-pcep-service-aware-02.txt - draft-ietf-pce-pcep-service-aware-04.txt.html" =0A= =0A= =0A= =0A= =0A= Diff: draft-ietf-pce-pcep-service-aware-02.txt - = draft-ietf-pce-pcep-service-aware-04.txt =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A=
< draft-ietf-pce-pcep-service-aware-02.txt   draft-ietf-pce-pcep-service-aware-04.txt >
PCE Working Group = D. Dhody PCE Working Group = D. Dhody
Internet-Draft = Huawei Technologies Internet-Draft = Huawei Technologies
Intended status: Standards Track = V. Manral Intended status: = Standards Track V. Manral
Expires: July 11, 2014 = Hewlett-Packard Corp. Expires: September 2, = 2014 Hewlett-Packard Corp.
= Z. = Ali = Z. Ali
= G. = Swallow = G. Swallow
= Cisco = Systems = Cisco Systems
= K. = Kumaki = K. Kumaki
= KDDI = Corporation = KDDI Corporation
= January 7, 2014 = March 2014
Extensions to the Path Computation Element Communication = Protocol (PCEP) Extensions to the Path = Computation Element Communication Protocol (PCEP)
= to compute service aware Label Switched Path (LSP). = to compute service aware Label = Switched Path (LSP).
= draft-ietf-pce-pcep-service-aware-02 = draft-ietf-pce-pcep-service-aware-04
Abstract Abstract
= In certain networks like financial information network (stock/ = In certain networks like financial = information network (stock/
= commodity trading) and enterprises using cloud based = applications, commodity trading) = and enterprises using cloud based applications,
= Latency (delay), Latency-Variation (jitter) and Packet Loss is = Latency (delay), Latency-Variation (jitter) = and Packet Loss is
= becoming a key requirement for path computation along with = other becoming a key requirement = for path computation along with other
= constraints and metrics. Latency, Latency-Variation and Packet = Loss constraints and metrics. = Latency, Latency-Variation and Packet Loss
= is associated with the Service Level Agreement (SLA) between = is associated with the Service Level = Agreement (SLA) between
= customers and service providers. = customers and service providers.
=
skipping to change at page 2, line = 7 skipping to = change at page 2, line 7
= Internet-Drafts are working documents of the Internet = Engineering Internet-Drafts are = working documents of the Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups = may also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. = Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, = or obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work = in progress."
= This Internet-Draft will expire on July = 11, 2014. This = Internet-Draft will expire on September 2, = 2014.
Copyright Notice Copyright Notice
= Copyright (c) 2014 IETF Trust and the persons identified as the = Copyright (c) 2014 IETF Trust and the = persons identified as the
= document authors. All rights reserved. document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the = IETF Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
=
skipping to change at page 2, line = 38 skipping to = change at page 2, line 38
= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = 4 2. Terminology . . . . . . . . . = . . . . . . . . . . . . . . . . 4
= 3. PCEP Requirements . . . . . . . . . . . . . . . . . . . . . . = 4 3. PCEP Requirements . . . . . . = . . . . . . . . . . . . . . . . 4
= 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . = 5 4. PCEP Extensions . . . . . . . = . . . . . . . . . . . . . . . . 5
= 4.1. Latency (Delay) Metric . . . . . . . . . . . . . . . . . = 5 4.1. Latency (Delay) Metric . = . . . . . . . . . . . . . . . . 5
= 4.1.1. Latency (Delay) Metric Value . . . . . . . . . . . . = 6 4.1.1. Latency (Delay) = Metric Value . . . . . . . . . . . . 6
= 4.2. Latency Variation (Jitter) Metric . . . . . . . . . . . . = 6 4.2. Latency Variation = (Jitter) Metric . . . . . . . . . . . . 6
= 4.2.1. Latency Variation (Jitter) Metric Value . . . . . . . = 7 4.2.1. Latency Variation = (Jitter) Metric Value . . . . . . . 7
= 4.3. Packet Loss Metric . . . . . . . . . . . . . . . . . . . = 7 4.3. Packet Loss Metric . . . = . . . . . . . . . . . . . . . . 7
= 4.3.1. Packet Loss Metric Value . . . . . . . . . . . . . . = 8 4.3.1. Packet Loss Metric = Value . . . . . . . . . . . . . . 8
= 4.4. Non-Understanding / Non-Support of Service Aware Path = 4.4. Non-Understanding / Non-Support of = Service Aware Path
= Computation . . . . . . . . . . . . . . . . . . . . . . . = 8 = Computation . . . . . . . . . . . . . . . . . . . . . . . 9
= 4.5. Mode of Operation . . . . . . . . . . . . . . . . . . . . = 9 4.5. Mode of Operation . . . . = . . . . . . . . . . . . . . . . 9
= 4.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . = 9 = 4.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 10
= 5. Relationship with Objective Functions . . . . . . . . . . . . = 10 5. Relationship with Objective = Functions . . . . . . . . . . . . 10
= 6. Protocol Consideration . . . . . . . . . . . . . . . . . . . = 11 6. Protocol Consideration . . = . . . . . . . . . . . . . . . . . 11
= 6.1. Inter-domain Consideration . . . . . . . . . . . . . . . = 11 6.1. Inter-domain = Consideration . . . . . . . . . . . . . . . 11
= 6.1.1. Inter-AS Link . . . . . . . . . . . . . . . . . . . . = 11 6.1.1. Inter-AS Link . . . = . . . . . . . . . . . . . . . . . 11
= 6.1.2. Inter-Layer Consideration . . . . . . . . . . . . . . = 11 6.1.2. Inter-Layer = Consideration . . . . . . . . . . . . . . 11
= 6.2. Reoptimization Consideration . . . . . . . . . . . . . . = 12 6.2. Reoptimization = Consideration . . . . . . . . . . . . . . 12
= 6.3. Point-to-Multipoint (P2MP) . . . . . . . . . . . . . . . = 12 6.3. Point-to-Multipoint = (P2MP) . . . . . . . . . . . . . . . 12
= 6.3.1. P2MP Latency Metric . . . . . . . . . . . . . . . . . = 12 6.3.1. P2MP Latency Metric = . . . . . . . . . . . . . . . . . 12
= 6.3.2. P2MP Latency Variation Metric . . . . . . . . . . . . = 12 6.3.2. P2MP Latency = Variation Metric . . . . . . . . . . . . 12
= 6.3.3. P2MP Packet Loss Metric . . . . . . . . . . . . . . . = 13 6.3.3. P2MP Packet Loss = Metric . . . . . . . . . . . . . . . 13
= 6.4. Stateful PCE . . . . . . . . . . . . . . . . . . . . . . = 13 6.4. Stateful PCE . . . . . = . . . . . . . . . . . . . . . . . 13
= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 13 7. IANA Considerations . . . . = . . . . . . . . . . . . . . . . . 13
= 8. Security Considerations . . . . . . . . . . . . . . . . . . . = 14 8. Security Considerations . . = . . . . . . . . . . . . . . . . . 14
= 9. Manageability Considerations . . . . . . . . . . . . . . . . = 14 9. Manageability Considerations = . . . . . . . . . . . . . . . . 14
= 9.1. Control of Function and Policy . . . . . . . . . . . . . = 14 9.1. Control of Function and = Policy . . . . . . . . . . . . . 14
= 9.2. Information and Data Models . . . . . . . . . . . . . . . = 14 9.2. Information and Data = Models . . . . . . . . . . . . . . . 14
= 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . = 14 9.3. Liveness Detection and = Monitoring . . . . . . . . . . . . 14
= 9.4. Verify Correct Operations . . . . . . . . . . . . . . . . = 14 9.4. Verify Correct = Operations . . . . . . . . . . . . . . . . 14
= 9.5. Requirements On Other Protocols . . . . . . . . . . . . . = 14 9.5. Requirements On Other = Protocols . . . . . . . . . . . . . 14
= 9.6. Impact On Network Operations . . . . . . . . . . . . . . = 14 = 9.6. Impact On Network Operations . . . . . . . . . . . . . . 15
= 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 14 = 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
= 11. References . . . . . . . . . . . . . . . . . . . . . . . . . = 15 11. References . . . . . . . . = . . . . . . . . . . . . . . . . . 15
= 11.1. Normative References . . . . . . . . . . . . . . . . . . = 15 11.1. Normative References . = . . . . . . . . . . . . . . . . . 15
= 11.2. Informative References . . . . . . . . . . . . . . . . . = 15 11.2. Informative References = . . . . . . . . . . . . . . . . . 15
= Appendix A. Contributor Addresses . . . . . . . . . . . . . . . = 17 Appendix A. Contributor = Addresses . . . . . . . . . . . . . . . 17
1. = Introduction 1. Introduction
= Real time network performance is becoming a critical in the = path Real time network performance = is becoming a critical in the path
= computation in some networks. Mechanisms to measure Latency, = computation in some networks. Mechanisms to = measure Latency,
= Latency-Variation, and Packet Loss in an MPLS network are = described Latency-Variation, and = Packet Loss in an MPLS network are described
=
skipping to change at page 5, line = 19 skipping to = change at page 5, line 19
= consistently: for instance, if the delay of a computed path = segment consistently: for instance, = if the delay of a computed path segment
= is exchanged between two PCEs residing in different domains, = is exchanged between two PCEs residing in = different domains,
= consistent ways of defining the delay must be used. consistent ways of defining the delay must be = used.
4. = PCEP Extensions 4. PCEP = Extensions
= This section defines PCEP extensions (see [RFC5440]) for = requirements This section defines = PCEP extensions (see [RFC5440]) for requirements
= outlined in Section 3. The proposed solution is used to = support outlined in Section 3. The = proposed solution is used to support
= network performance and service aware path computation. = network performance and service aware path = computation.
= This document defines the following optional types for the = METRIC The = METRIC object is defined in section 7.8 of [RFC5440], = comprising
= object defined in [RFC5440]. = of metric-value, = metric-type (T field) and flags. This document
defines the = following optional types for the METRIC object.
= For explanation of these metrics, the following terminology is = used For explanation of these = metrics, the following terminology is used
= and expanded along the way. and = expanded along the way.
= - A network comprises of a set of N links {Li, (i=3D1...N)}. = - A network comprises of a set of N links = {Li, (i=3D1...N)}.
= - A path P of a P2P LSP is a list of K links {Lpi,(i=3D1...K)}. = - A path P of a P2P LSP is a list of K links = {Lpi,(i=3D1...K)}.
4.1. Latency (Delay) Metric 4.1. Latency (Delay) Metric
= Link delay metric is defined in [OSPF-TE-EXPRESS] and Link delay metric is defined in [OSPF-TE-EXPRESS] = and
= [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in = PCEP [ISIS-TE-EXPRESS]. P2P = latency metric type of METRIC object in PCEP
= encodes the sum of the link delay metric of all links along a = P2P encodes the sum of the link = delay metric of all links along a P2P
= Path. Specifically, extending on the above mentioned = terminology: Path. Specifically, = extending on the above mentioned terminology:
= - A Link delay metric of link L is denoted D(L). - A Link delay metric of link L is denoted = D(L).
= - A P2P latency metric for the Path P =3D Sum {D(Lpi), = (i=3D1...K)}. - A P2P latency = metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.
= * T=3D13(TBA - IANA): Latency metric This is as per sum of means = composition function (section 4.2.5 of
[RFC6049]).
=
* Metric Type T=3D13(TBA - IANA): Latency = metric
= PCC MAY use this latency metric in PCReq message to request a = path PCC MAY use this latency = metric in PCReq message to request a path
= meeting the end to end latency requirement. In this case B bit = MUST meeting the end to end latency = requirement. In this case B bit MUST
= be set to suggest a bound (a maximum) for the path latency = metric be set to suggest a bound (a = maximum) for the path latency metric
= that must not be exceeded for the PCC to consider the computed = path that must not be exceeded for = the PCC to consider the computed path
= as acceptable. The path metric must be less than or equal to = the as acceptable. The path metric = must be less than or equal to the
= value specified in the metric-value field. value specified in the metric-value field.
= PCC MAY also use this metric to ask PCE to optimize latency = during PCC MAY also use this metric = to ask PCE to optimize latency during
= path computation, in this case B flag will be cleared. path computation, in this case B flag will be = cleared.
=
skipping to change at page 6, line = 34 skipping to = change at page 6, line 37
= Latency (Delay) Metric (24 bits): Represents the end to end = Latency Latency (Delay) Metric (24 = bits): Represents the end to end Latency
= (delay) quantified in units of microseconds and MUST be encoded = as (delay) quantified in units = of microseconds and MUST be encoded as
= integer value. With the maximum value 16,777,215 = representing integer value. = With the maximum value 16,777,215 representing
= 16.777215 sec. 16.777215 = sec.
4.2. Latency Variation (Jitter) Metric 4.2. Latency Variation (Jitter) Metric
= Link delay variation metric is defined in [OSPF-TE-EXPRESS] and = Link delay variation metric is defined in = [OSPF-TE-EXPRESS] and
= [ISIS-TE-EXPRESS]. P2P latency variation metric type of METRIC = [ISIS-TE-EXPRESS]. P2P latency variation = metric type of METRIC
= object in PCEP encodes a function of the = link delay variation metric object = in PCEP encodes the sum of the link delay = variation metric of
= of all links along a P2P Path. Specifically, extending on the = above all links along a P2P Path. = Specifically, extending on the above
= mentioned terminology: mentioned = terminology:
= - A Latency variation of link L is denoted DV(L). - A = Latency variation of link L is denoted DV(L) = (average delay
variation for link L).
= - A P2P latency variation metric for the Path P =3D function {DV(Lpi), - A P2P latency variation metric for the Path P =3D = Sum {DV(Lpi),
= (i=3D1...K)}. (i=3D1...K)}.
= Specification of the "Function" used to drive = latency variation Since we have an average delay variation for the links, sum = is an
metric of a path from = latency variation metrics of individual = links = acceptable composition function for the path for simplicity. This
along the path is beyond the = scope of this = document. document allows use of an enhanced composition function for = latency
variation in future.
= * T=3D14(TBA - IANA): Latency Variation metric * Metric Type = T=3D14(TBA - IANA): Latency Variation metric
= PCC MAY use this latency variation metric in PCReq message to = request PCC MAY use this latency = variation metric in PCReq message to request
= a path meeting the end to end latency variation requirement. In = this a path meeting the end to end = latency variation requirement. In this
= case B bit MUST be set to suggest a bound (a maximum) for the = path case B bit MUST be set to = suggest a bound (a maximum) for the path
= latency variation metric that must not be exceeded for the PCC = to latency variation metric that = must not be exceeded for the PCC to
= consider the computed path as acceptable. The path metric must = be consider the computed path as = acceptable. The path metric must be
= less than or equal to the value specified in the metric-value = field. less than or equal to the = value specified in the metric-value field.
= PCC MAY also use this metric to ask PCE to optimize latency = variation PCC MAY also use this = metric to ask PCE to optimize latency variation
= during path computation, in this case B flag will be cleared. = during path computation, in this case B flag = will be cleared.
=
skipping to change at page 7, line = 39 skipping to = change at page 7, line 45
= on transmission and MUST be ignored on receipt. on transmission and MUST be ignored on = receipt.
= Latency variation (jitter) Metric (24 bits): Represents the end = to Latency variation (jitter) = Metric (24 bits): Represents the end to
= end Latency variation (jitter) quantified in units of = microseconds end Latency = variation (jitter) quantified in units of microseconds
= and MUST be encoded as integer value. With the maximum = value and MUST be encoded as = integer value. With the maximum value
= 16,777,215 representing 16.777215 sec. 16,777,215 representing 16.777215 sec.
4.3. Packet Loss Metric 4.3. Packet Loss Metric
= [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] defines "Unidirectional = Link [OSPF-TE-EXPRESS] and = [ISIS-TE-EXPRESS] defines "Unidirectional Link
= Loss". Packet Loss Metric metric type = of METRIC object in PCEP Loss". = Packet Loss metric type of METRIC object in PCEP encodes a
= encodes a function of the link's unidirectional loss metric of = all function of the link's = unidirectional loss metric of all links along
= links along a P2P Path. Specifically, extending on the above = a P2P Path. Specifically, extending on the = above mentioned
= mentioned terminology: = terminology:
= The end to end Packet Loss for the path is represented by this = The end to end Packet Loss for the path is = represented by this
= metric. metric.
= - A Packet loss of link L is denoted PL(L). - A Packet loss of link L is denoted PL(L) in percentage.
= - A P2P packet loss metric for the Path P =3D function {PL(Lpi), - A Packet loss in fraction of link L is denoted FPL(L) =3D = PL(L)/100.
(i=3D1...K)}. =
= Specification of the "Function" used to drive = end to end packet loss = - A P2P packet loss metric in percentage for the Path P =3D (1 -
= metric of a path from packet loss metrics of = individual links along ((1-FPL(Lp1)) * (1-FPL(Lp2)) * .. * (1-FPL(LpK))) * = 100 for a path P
= the path is beyond the scope of this = document. with link 1 to K.
= * T=3D15(TBA - IANA): Packet Loss metric This is as per the = composition function (section 5.1.5 of [RFC6049]).
=
* Metric Type T=3D15(TBA - IANA): Packet Loss = metric
= PCC MAY use this packet loss metric in PCReq message to request = a PCC MAY use this packet loss = metric in PCReq message to request a
= path meeting the end to end packet loss requirement. In this case = B path meeting the end to end = packet loss requirement. In this case B
= bit MUST be set to suggest a bound (a maximum) for the path = packet bit MUST be set to suggest a = bound (a maximum) for the path packet
= loss metric that must not be exceeded for the PCC to consider = the loss metric that must not be = exceeded for the PCC to consider the
= computed path as acceptable. The path metric must be less than = or computed path as acceptable. = The path metric must be less than or
= equal to the value specified in the metric-value field. = equal to the value specified in the = metric-value field.
= PCC MAY also use this metric to ask PCE to optimize packet loss = PCC MAY also use this metric to ask PCE to = optimize packet loss
= during path computation, in this case B flag will be cleared. = during path computation, in this case B flag = will be cleared.
=
skipping to change at page 12, line = 33 skipping to = change at page 12, line 38
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P latency metric of the Path to destination Dest_j is denoted = by - P2P latency metric of the Path = to destination Dest_j is denoted by
= LM(Dest_j). LM(Dest_j).
= - P2MP latency metric for the P2MP tree T =3D Maximum = {LM(Dest_j), - P2MP latency metric = for the P2MP tree T =3D Maximum {LM(Dest_j),
= (j=3D1...M)}. (j=3D1...M)}.
= Value for P2MP latency metric is to be assigned = by IANA Value for P2MP = latency metric type (T) is to be assigned by = IANA.
6.3.2. P2MP Latency Variation Metric 6.3.2. P2MP Latency Variation Metric
= P2MP latency variation metric type of METRIC object in PCEP = encodes P2MP latency variation = metric type of METRIC object in PCEP encodes
= the path latency variation metric for destination that observes = the the path latency variation = metric for destination that observes the
= worst latency variation metric among all destinations of the = P2MP worst latency variation metric = among all destinations of the P2MP
= tree. Specifically, extending on the above mentioned = terminology: tree. Specifically, = extending on the above mentioned terminology:
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P latency variation metric of the Path to destination Dest_j = is - P2P latency variation metric = of the Path to destination Dest_j is
= denoted by LVM(Dest_j). denoted by = LVM(Dest_j).
= - P2MP latency variation metric for the P2MP tree T =3D Maximum = - P2MP latency variation metric for the P2MP = tree T =3D Maximum
= {LVM(Dest_j), (j=3D1...M)}. = {LVM(Dest_j), (j=3D1...M)}.
= Value for P2MP latency variation metric is to be assigned by IANA Value = for P2MP latency variation metric type (T) = is to be assigned by
IANA.
6.3.3. P2MP Packet Loss Metric 6.3.3. P2MP Packet Loss Metric
= P2MP packet loss metric type of METRIC object in PCEP encodes = the P2MP packet loss metric type of = METRIC object in PCEP encodes the
= path packet loss metric for destination that observes the worst = path packet loss metric for destination that = observes the worst
= packet loss metric among all destinations of the P2MP tree. = packet loss metric among all destinations of = the P2MP tree.
= Specifically, extending on the above mentioned terminology: = Specifically, extending on the above = mentioned terminology:
= - A P2MP Tree T comprises of a set of M destinations {Dest_j, = - A P2MP Tree T comprises of a set of M = destinations {Dest_j,
= (j=3D1...M)} (j=3D1...M)}
= - P2P packet loss metric of the Path to destination Dest_j is = denoted - P2P packet loss metric of = the Path to destination Dest_j is denoted
= by PLM(Dest_j). by = PLM(Dest_j).
= - P2MP packet loss metric for the P2MP tree T =3D Maximum = {PLM(Dest_j), - P2MP packet loss = metric for the P2MP tree T =3D Maximum {PLM(Dest_j),
= (j=3D1...M)}. (j=3D1...M)}.
= Value for P2MP packet loss metric is to be = assigned by IANA Value for = P2MP packet loss metric type (T) is to be = assigned by IANA.
6.4. Stateful PCE 6.4. = Stateful PCE
= [STATEFUL-PCE] specifies a set of extensions to PCEP to enable = [STATEFUL-PCE] specifies a set of extensions = to PCEP to enable
= stateful control of MPLS-TE and GMPLS LSPs via PCEP and = maintaining stateful control of = MPLS-TE and GMPLS LSPs via PCEP and maintaining
= of these LSPs at the stateful PCE. A Path Computation LSP = State of these LSPs at the stateful = PCE. A Path Computation LSP State
= Report message (also referred to as PCRpt message) is a PCEP = message Report message (also = referred to as PCRpt message) is a PCEP message
= sent by a PCC to a PCE to report the current state of an LSP. = This sent by a PCC to a PCE to = report the current state of an LSP. This
= message contains the metric-list as part of attributes, the new = message contains the metric-list as part of = attributes, the new
= metric types defined in this document for network performance = metric types defined in this document for = network performance
=
skipping to change at page 15, line = 5 skipping to = change at page 15, line 16
= Mechanisms defined in this document do not have any impact on = network Mechanisms defined in this = document do not have any impact on network
= operations in addition to those already listed in [RFC5440]. = operations in addition to those already = listed in [RFC5440].
10. Acknowledgments 10. Acknowledgments
= We would like to thank Young Lee, Venugopal Reddy, Reeja Paul, = We would like to thank Young Lee, Venugopal = Reddy, Reeja Paul,
= Sandeep Kumar Boina, Suresh Babu, Quintin Zhao, Chen Huaimo and = Sandeep Kumar Boina, Suresh Babu, Quintin = Zhao, Chen Huaimo and
= Avantika for their useful comments and suggestions. Avantika for their useful comments and = suggestions.
Also the authors gratefully acknowledge reviews and = feedback provided
by Qin Wu, Alfred Morton and Paul Aitken during = performance
directorate review.
=
11. References 11. = References
11.1. Normative References 11.1. Normative References
= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate = [RFC2119] Bradner, S., "Key words for use = in RFCs to Indicate
= Requirement Levels", BCP 14, RFC 2119, March 1997. = Requirement Levels", BCP 14, RFC = 2119, March 1997.
= [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation = Element [RFC5440] Vasseur, JP. and = JL. Le Roux, "Path Computation Element
= (PCE) Communication Protocol (PCEP)", RFC 5440, = March (PCE) = Communication Protocol (PCEP)", RFC 5440, March
= 2009. = 2009.
=
skipping to change at page 15, line = 39 skipping to = change at page 16, line 5
= Traffic Engineering", RFC 5392, January 2009. = Traffic Engineering", RFC 5392, = January 2009.
= [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of = [RFC5541] Le Roux, JL., Vasseur, JP., and = Y. Lee, "Encoding of
= Objective Functions in the Path Computation Element = Objective Functions in the Path = Computation Element
= Communication Protocol (PCEP)", RFC 5541, June 2009. = Communication Protocol (PCEP)", = RFC 5541, June 2009.
= [RFC5623] Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, = [RFC5623] Oki, E., Takeda, T., Le Roux, = JL., and A. Farrel,
= "Framework for PCE-Based Inter-Layer MPLS and GMPLS = "Framework for PCE-Based = Inter-Layer MPLS and GMPLS
= Traffic Engineering", RFC 5623, September 2009. = Traffic Engineering", RFC 5623, = September 2009.
[RFC6049] Morton, A. and E. Stephan, "Spatial = Composition of
Metrics", RFC 6049, January = 2011.
=
= [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay = [RFC6374] Frost, D. and S. Bryant, "Packet = Loss and Delay
= Measurement for MPLS Networks", RFC 6374, September = 2011. Measurement for = MPLS Networks", RFC 6374, September 2011.
= [OSPF-TE-EXPRESS] = [OSPF-TE-EXPRESS]
= Giacalone, S., Ward, D., Drake, J., Atlas, A., and = S. Giacalone, S., Ward, = D., Drake, J., Atlas, A., and S.
= Previdi, "OSPF Traffic Engineering (TE) Metric = Extensions Previdi, = "OSPF Traffic Engineering (TE) Metric Extensions
= [draft-ietf-ospf-te-metric-extensions]", December = 2013. = [draft-ietf-ospf-te-metric-extensions]", December 2013.
= [ISIS-TE-EXPRESS] = [ISIS-TE-EXPRESS]
= Previdi, S., Giacalone, S., Ward, D., Drake, J., = Atlas, Previdi, S., = Giacalone, S., Ward, D., Drake, J., Atlas,
= A., Filsfils, C., and Q. Wu, "IS-IS Traffic = Engineering A., = Filsfils, C., and Q. Wu, "IS-IS Traffic Engineering
= (TE) Metric Extensions [draft-ietf-isis-te-metric- = (TE) Metric Extensions = [draft-ietf-isis-te-metric-
= extensions-00]", October = 2013. extensions]", = October 2013.
= [MPLS-TE-EXPRESS-PATH] = [MPLS-TE-EXPRESS-PATH]
= Atlas, A., Drake, J., Ward, D., Giacalone, S., = Previdi, Atlas, A., = Drake, J., Ward, D., Giacalone, S., Previdi,
= S., and C. Filsfils, "Performance-based Path Selection = for S., and C. Filsfils, = "Performance-based Path Selection for
= Explicitly Routed LSPs [draft-atlas-mpls-te-express- Explicitly Routed LSPs [draft-ietf-mpls-te-express-path]",
path]", = September 2013. October 2013.
= [PCEP-MIB] [PCEP-MIB]
= Kiran Koushik, A., Stephan, E., Zhao, Q., King, D., and = J. Kiran Koushik, A., = Stephan, E., Zhao, Q., King, D., and J.
= Hardwick, "PCE communication protocol(PCEP) = Management Hardwick, = "PCE communication protocol(PCEP) Management
= Information Base [draft-ietf-pce-pcep-mib]", July 2013. = Information Base [draft-ietf-pce-pcep-mib]", February
2014.
= [STATEFUL-PCE] = [STATEFUL-PCE]
= Crabbe, E., Medved, J., Minei, I., and R. Varga,, = "PCEP Crabbe, E., = Medved, J., Minei, I., and R. Varga,, "PCEP
= Extensions for Stateful PCE = (draft-ietf-pce-stateful- = Extensions for Stateful PCE (draft-ietf-pce-stateful-
= pce)", October 2013. = pce)", October 2013.
= [PCEP-BW-UTIL] = [PCEP-BW-UTIL]
= Wu, Q., Dhody, D., and S. Previdi, "Extensions to = Path Wu, Q., Dhody, D., = and S. Previdi, "Extensions to Path
= Computation Element Communication Protocol (PCEP) = for Computation Element = Communication Protocol (PCEP) for
= handling Link Bandwidth Utilization = (draft-wu-pce-pcep- = handling Link Bandwidth Utilization (draft-wu-pce-pcep-
= link-bw-utilization)", January 2014. link-bw-utilization)", February 2014.
Appendix A. Contributor Addresses Appendix A. Contributor Addresses
= Clarence Filsfils Clarence = Filsfils
= Cisco Systems Cisco Systems
= EMail: cfilsfil@cisco.com EMail: = cfilsfil@cisco.com
= Siva Sivabalan Siva = Sivabalan
= Cisco Systems Cisco Systems
= EMail: msiva@cisco.com EMail: = msiva@cisco.com
=
skipping to change at page 17, line = 45 skipping to = change at page 17, line 45
= Dhruv Dhody Dhruv Dhody
= Huawei Technologies Huawei = Technologies
= Leela Palace Leela Palace
= Bangalore, Karnataka 560008 = Bangalore, Karnataka 560008
= INDIA INDIA
= EMail: dhruv.ietf@gmail.com EMail: = dhruv.ietf@gmail.com
= Vishwas Manral Vishwas = Manral
= Hewlett-Packard Corp. = Hewlett-Packard Corp.
= 191111 Pruneridge Ave.
Cupertino, CA = 95014
= USA USA
= EMail: vishwas.manral@hp.com = EMail: vishwas.ietf@gmail.com
= Zafar Ali Zafar Ali
= Cisco Systems Cisco Systems
= EMail: zali@cisco.com EMail: = zali@cisco.com
= George Swallow George = Swallow
= Cisco Systems Cisco Systems
= EMail: swallow@cisco.com EMail: = swallow@cisco.com
 End of changes. 30 change blocks. 
41 lines changed or = deleted 55 lines changed or = added

This = html diff was produced by rfcdiff 1.41. The latest version is available = from http://tools.ietf.org/t= ools/rfcdiff/
=0A= =0A= =0A= ------=_NextPart_000_0368_01CF2C21.95FF4070-- From nobody Mon Feb 17 17:02:38 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965F41A0024 for ; Mon, 17 Feb 2014 17:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.252 X-Spam-Level: X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BubGSB7YX40c for ; Mon, 17 Feb 2014 17:02:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 86C641A022B for ; Mon, 17 Feb 2014 17:02:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BDR59768; Tue, 18 Feb 2014 01:02:24 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 01:02:15 +0000 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Feb 2014 01:02:22 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 18 Feb 2014 09:02:10 +0800 From: Qin Wu To: Dhruv Dhody , "'MORTON, ALFRED C (AL)'" , "'Paul Aitken'" , "zali@cisco.com" , "swallow@cisco.com" , "ke-kumaki@kddi.com" Thread-Topic: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 Thread-Index: AQHPK/ONguhJn795xEaxJTFmiFdxXJq6MeIw Date: Tue, 18 Feb 2014 01:02:09 +0000 Message-ID: References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> <52FFEB1B.8010606@cisco.com> <2845723087023D4CB5114223779FA9C8BC5B9B95@njfpsrvexg8.research.att.com> <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> In-Reply-To: <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C815D6nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/z_ot7z52vqUUp1cocpfBEqj5hyg Cc: "dhruv.ietf@gmail.com" , "vishwas.ietf@gmail.com" , "pm-dir@ietf.org" Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02 X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 01:02:37 -0000 --_000_B8F9A780D330094D99AF023C5877DABA43C815D6nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dhruv: Thanks for your proposed changes and clarification. Your proposed changes look acceptable to me. Regards! -Qin From: Dhruv Dhody Sent: Monday, February 17, 2014 11:18 PM To: 'MORTON, ALFRED C (AL)'; 'Paul Aitken'; Qin Wu; zali@cisco.com; swallow= @cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org; dhruv.ietf@gmail.com; vishwas.ietf@gmail.com Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi All, The authors are grateful for the comments and have prepared an updated vers= ion. Qin, Could you have a look and suggest if we have addressed your comments & chan= ges are acceptable to you? Regarding interval, see my comment inline. Regards, Dhruv From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Sunday, February 16, 2014 7:15 PM To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 All Paul's suggestions for increasing clarity are fine with me. Al From: Paul Aitken [mailto:paitken@cisco.com] Sent: Saturday, February 15, 2014 5:33 PM To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@ci= sco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Al, All, For clarity, it would be better to name this as, "Average Delay Variation".= Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-= TLV". Several parts of the text (4.1 through 4.4) say, "This (field) carries the = (metric) over a configurable interval". Is it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)= ? [DhruvDhody>] The metrics we have in this I.D. are calculated based on lin= k metrics defined in OSPF-TE draft [1], and is not measured directly. Therefore the time of the interval is same as link metrics defined in OSPF-= TE draft. OSPF-TE draft section 7 discusses this. [2] We do not see a reason to mention this in the PCE I.D. [1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05 [2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#sect= ion-7 P. On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: Hi Qin, authors, I read, in draft-ietf-ospf-te-metric-extensions: 4.3.4. Delay Variation This 24-bit field carries the average link delay variation over a configurable interval in micro-seconds, encoded as an integer value. When set to 0, it has not been measured. When set to the maximum value 16,777,215 (16.777215 sec), then the delay is at least that value and may be larger. So this is an *average* DV, to my surprise, and therefore the sum function Qin proposed is reasonable. (it still doesn't say here what form of delay variation has been measured) However, delay variation is better characterized in summary statistics which describe the breadth of the DV distribution. In bimodal delay distributions, the average can be misleading. But you have what you have in draft-ietf-ospf-te-metric-extensions for now, and summing averages is an easy problem. Use RFC6049 for the other metrics, like loss and delay. regards, Al From: Qin Wu [mailto:bill.wu@huawei.com] Sent: Friday, February 14, 2014 9:36 PM To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com<= mailto:swallow@cisco.com>; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 Hi, Al: You raise very good comments for this. Here are a few thoughts below. Regards! -Qin From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com] Sent: Friday, February 14, 2014 10:20 PM To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep= -service-aware-02 A few additional comments, we can help the authors a bit more I think, but Qin was on the right track. Al Qin wrote: 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? ------------------------------------------------------- Sum is a rather worst-case approximation of the Path DV. We have studied these sorts of e2e Path estimates in IPPM. Packet Delay Variation is the most complex, but a couple of possibilities for "function" are specified here: http://tools.ietf.org/html/rfc6049#page-20 [Qin]: Yes, it is a rat hole that needs to be fixed. Do you know how the function defined in section 6.4.5.1 of RFC6049 Can be applied to this draft and quoted as function of latency variation For complete path from source to destination. It seems to me we only know delay variation of each sub path, which is gathered from link delay variation advertisement defined in draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each s= ub path is millisecond. Using sum may be the worse case approximation of path DV and cause the gran= ularity of measurement result very coarse, but the computation overhead for calculation of path DV can be minimized. If we use integral function defined in section 6.4.5.1 of RFC6049, definite= ly we Can improve granularity of measurement/calculation result but at the cost o= f Consuming more computation overhead. So there is tradeoff to pick one or an= other. Similarly, we have functions, which could be cited as references in this draft, for loss http://tools.ietf.org/html/rfc6049#page-18 [Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be cited as reference for this draft. and for mean delay http://tools.ietf.org/html/rfc6049#section-4.2 So, no need to leave the "function" unspecified and out of scope, assuming your loss and delay metric definitions are compatible. [Qin]: Exactly. From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu Sent: Friday, February 14, 2014 5:44 AM To: Dhruv Dhody; vishwas.manral@hp.com; zali@= cisco.com; swallow@cisco.com; ke-kumaki@kddi.com Cc: pm-dir@ietf.org Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-ser= vice-aware-02 Hi, authors: I am assigned Performance Directorate reviewer for this draft. Here is my review to this draft. This draft uses the link latency, latency variation and packet loss informa= tion for end to end path selection. The link latency, latency variation and packet loss metrics are defined in = OSPF-TE draft and ISIS-TE draft and used to calculate path metrics described in this draft, e.g., P2P latency m= etric, P2P latency variation metric, packet loss metric, P2MP latency metric, P2MP latency variation metric. These calculated path metrics( 6 metrics) are carried in PCEP message using= the same Metric Object with different metric type. The calculated metrics are used as constraint for path computation In this draft, each calculated metric is discussed in each separate section= from metric name, metric description perspective to measurement unit, calculation method perspective. IANA is also requested to register these 6 metric types. Therefore I believ= e this draft conforms to RFC6390 guideline. However I have a few comments regarding these metrics definitions. 1. Section 4, 2nd paragraph says: " This document defines the following optional types for the METRIC object defined in [RFC5440]. " s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] 2. Section 4.1 says: " Link delay metric is defined in [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP encodes the sum of the link delay metric of all links along a P2P Path. Specifically, extending on the above mentioned terminology: - A Link delay metric of link L is denoted D(L). - A P2P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}. * T=3D13(TBA - IANA): Latency metric " For people who are not familiar with Metrics Object Format, it is not easy = to figure out what T=3D13 stands for? Would it be good to add some context = text or Introduce Metric Object format first. 3. Section 4.2 says: " - A Latency variation of link L is denoted DV(L). - A P2P latency variation metric for the Path P =3D function {DV(Lpi), (i=3D1...K)}. " Why not sum of latency variation metrics of individual links? 4. Section 4.2 says: " Specification of the "Function" used to drive latency variation metric of a path from latency variation metrics of individual links along the path is beyond the scope of this document. " s/drive/derive 5. Section 4 Section 4.3 says: "Packet Loss Metric metric type of METRIC Object" Section 4.2 says: "P2P latency variation metric type of METRIC Object" For consistency, you may either use "xx Metric metric type" or "xx metric t= ype of Metric Object". 6.Section 4.3 says: " The end to end Packet Loss for the path is represented by this metric. - A Packet loss of link L is denoted PL(L). - A P2P packet loss metric for the Path P =3D function {PL(Lpi), (i=3D1...K)}. " Is function of packet loss metric of individual link same as function of la= tency variation metric of individual link? If they are not same, please use different function name, e.g., function a = for packet loss, function b for latency variation? Regards! -Qin _______________________________________________ pm-dir mailing list pm-dir@ietf.org https://www.ietf.org/mailman/listinfo/pm-dir --_000_B8F9A780D330094D99AF023C5877DABA43C815D6nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dhruv:<= /span>

Thanks for your propos= ed changes and clarification.

Your proposed changes = look acceptable to me.

 

Regards!

-Qin=

From: Dhruv Dhody
Sent: Monday, February 17, 2014 11:18 PM
To: 'MORTON, ALFRED C (AL)'; 'Paul Aitken'; Qin Wu; zali@cisco.com; = swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org; dhruv.ietf@gmail.com; vishwas.ietf@gmail.com Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

Hi All,=

 <= /p>

The authors are grateful = for the comments and have prepared an updated version.

 <= /p>

Qin,

Could you have a look and= suggest if we have addressed your comments & changes are acceptable to= you?

 <= /p>

Regarding interval, see m= y comment inline.

 <= /p>

Regards,

Dhruv

 <= /p>

 <= /p>

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@ci= sco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

All Paul's suggestions for increasing cla= rity are fine with me.

Al

 

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

Al, All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be cle= arer as "Average Unidirectional L= ink Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries= the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the interval = and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago)= ?

[DhruvDhody>] Th= e metrics we have in this I.D.  are calculated based on link metrics d= efined in OSPF-TE draft [1], and is not measured directly.

Therefore the time = of the interval is same as link metrics defined in OSPF-TE draft. OSPF-TE d= raft section 7 discusses this. [2]

We do not see a rea= son to mention this in the PCE I.D.


[1] = http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05=

[2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-= 7


P.


On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:

Hi Qin, authors,

 

I read, in draft-ietf-ospf-te-metric-extensions:

4.3.4<= b>. Delay Variation

   This 24-bit field carries the average link de= lay variation over a

   configurable interval in micro-seconds, encod= ed as an integer value.

   When set to 0, it has not been measured. When= set to the maximum

   value 16,777,215 (16.777215 sec), then the de= lay is at least that

   value and may be larger.

 

So this is an *average* DV, to my surprise,<= o:p>

and therefore the sum function Qin proposed is reasonable.=

 

(it still doesn't say here what form of delay variation ha= s been measured)

 

However, delay variation is better characterized in summar= y

statistics which describe the breadth of the DV distributi= on.

In bimodal delay distributions, the average can be mislead= ing.

 

But you have what you have in draft-ietf-ospf-te-metric-extensions<= /o:p>

for now, and summing averages is an easy problem.  Us= e RFC6049

for the other metrics, like loss and delay.

 

regards,

Al

 

 

From: Qin Wu [= mailto:bill.wu@huawei.com]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com= ; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

Hi, Al:

You raise very good co= mments for this. Here are a few thoughts below.

 

Regards!

-Qin=

 

From: MORTON, = ALFRED C (AL) [mailto:acmorton@att.com<= /a>]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; vi= shwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi= .com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-p= ce-pcep-service-aware-02

 

A few additional comments, we can help the authors a bit m= ore

I think, but Qin was on the right track.=

 

Al

 

Qin wrote:

3. Section 4.2 s= ays:

“=

   - A La= tency variation of link L is denoted DV(L).

 <= /o:p>

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),

   (i=3D1= ...K)}.

”=

Why not sum of late= ncy variation metrics of individual links?

-------------------------------------------------------

 

Sum is a rather worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estimates in IPPM.=

Packet Delay Variation is the most complex, but a couple o= f

possibilities for "function" are specified here:=

htt= p://tools.ietf.org/html/rfc6049#page-20

 

[Qin]: Yes, it is a rat hole that nee= ds to be fixed.

Do you know how the function defined = in section 6.4.5.1 of RFC6049

Can be applied to this draft and quot= ed as function of latency variation

For complete path from source to dest= ination.

 

It seems to me we only know delay var= iation of each sub path, which is

gathered from link delay variation ad= vertisement defined in

draft-ietf-ospf-te-metric-extensions.= The unit of delay variation of each sub path

is millisecond.=

 

Using sum may be the worse case appro= ximation of path DV and cause the granularity

of measurement result very coarse, bu= t the computation overhead

for calculation of path DV can be min= imized.

If we use integral function defined i= n section 6.4.5.1 of RFC6049, definitely we

Can improve granularity of measuremen= t/calculation result but at the cost of

Consuming more computation overhead. = So there is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as refe= rences

in this draft, for loss

htt= p://tools.ietf.org/html/rfc6049#page-18

 

[Qin]: Yes, I agree= Composition Function defined in section 5.1.5 can be=

cited as reference = for this draft.

 

and for mean delay

http://tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to leave the "function" unspecified = and out of scope,

assuming your loss and delay metric definitions are compat= ible.

 

[Qin]: Exactly.=

 

 

 

 

Hi, authors:=

I am assigned Perfo= rmance Directorate reviewer for this draft.

Here is my review t= o this draft.

 <= /o:p>

This draft uses the= link latency, latency variation and packet loss information for end to end= path selection.

The link latency, l= atency variation and packet loss metrics are defined in OSPF-TE draft and I= SIS-TE draft and

used to calculate p= ath metrics described in this draft, e.g., P2P latency metric, P2P latency = variation metric, packet loss

metric, P2MP latenc= y metric, P2MP latency variation metric.

 <= /o:p>

These calculated pa= th metrics( 6 metrics) are carried in PCEP message using the same Metric Ob= ject with different metric type. 

The calculated metr= ics are used as constraint for path computation

 <= /o:p>

In this draft, each= calculated metric is discussed in each separate section from metric name, = metric description

perspective to meas= urement unit, calculation method perspective.

IANA is also reques= ted to register these 6 metric types. Therefore I believe this draft confor= ms to RFC6390 guideline.

However I have a fe= w comments regarding these metrics definitions.

1. Section 4, 2<= sup>nd paragraph says:

“=

   This d= ocument defines the following optional types for the METRIC

   object= defined in [RFC5440].

”=

s/defined in [= RFC5440]/defined in section 7.4 of [RFC5440]

 <= /o:p>

2. Section 4.1 s= ays:

“=

   Link d= elay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-= TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP<= o:p>

   encode= s the sum of the link delay metric of all links along a P2P

   Path.&= nbsp; Specifically, extending on the above mentioned terminology:

 <= /o:p>

   - A Li= nk delay metric of link L is denoted D(L).

 <= /o:p>

   - A P2= P latency metric for the Path P =3D Sum {D(Lpi), (i=3D1...K)}.<= /o:p>

 <= /o:p>

   * T=3D= 13(TBA - IANA): Latency metric

”=

For people who are = not familiar with Metrics Object Format, it is not easy to figure out what = T=3D13 stands for? Would it be good to add some context text or=

Introduce Metric Ob= ject format first.

 

 

3. Section 4.2 s= ays:

“=

   - A La= tency variation of link L is denoted DV(L).

 <= /o:p>

   - A P2= P latency variation metric for the Path P =3D function {DV(Lpi),

   (i=3D1= ...K)}.

”=

Why not sum of late= ncy variation metrics of individual links?

 <= /o:p>

4. Section 4.2 s= ays:

“=

Specification of th= e "Function" used to drive latency variation

metric of a path fr= om latency variation metrics of individual links

along the path is b= eyond the scope of this document.

”=

s/drive/derive

 <= /o:p>

5. Section 4

Section 4.3 says:

“Packet Loss = Metric metric type of METRIC Object”

Section 4.2 says:

“P2P latency = variation metric type of METRIC

   Object= ”

For consistency, yo= u may either use “xx Metric metric type” or “xx metric ty= pe of Metric Object”.

 <= /o:p>

6.Section 4.3 sa= ys:

“=

   The en= d to end Packet Loss for the path is represented by this<= /p>

   metric= .

 <= /o:p>

   - A Pa= cket loss of link L is denoted PL(L).

 <= /o:p>

   - A P2= P packet loss metric for the Path P =3D function {PL(Lpi),

   (i=3D1= ...K)}.

”=

Is function of pack= et loss metric of individual link same as function of latency variation met= ric of individual link?

If they are not sam= e, please use different function name, e.g., function a for packet loss, fu= nction b for latency variation?

 <= /o:p>

Regards!

-Qin

 

 <= /o:p>

 <= /o:p>

 

=  

_______________________________________________
pm-dir mailing list
pm-dir@ietf.org

https://www.i=
etf.org/mailman/listinfo/pm-dir

 

--_000_B8F9A780D330094D99AF023C5877DABA43C815D6nkgeml501mbschi_-- From nobody Tue Feb 18 02:50:03 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E251A0477 for ; Tue, 18 Feb 2014 02:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.048 X-Spam-Level: X-Spam-Status: No, score=-5.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWF3G4kCbcMY for ; Tue, 18 Feb 2014 02:49:55 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 366D81A047E for ; Tue, 18 Feb 2014 02:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60266; q=dns/txt; s=iport; t=1392720590; x=1393930190; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DaPyNbuBV3Sq9FIFMKjfI/1V1Uu6nWw9JdcsAjsAwQw=; b=Z2Vj371OOHpkE1+fNnGxV1R6dualZOdfZdtCbrBYgjaJrKXcI9+2eky/ eo3654YnOaZD09FdTAg+piy5AONsdWL98MiaM7iS4OjllpvSIsnM02agE 9h6fF6Ekohr7bM/fB15kLzstqkA1S37K2jGyPqkcz9EvqaqHP9k/Db33d 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FADI6A1OQ/khN/2dsb2JhbABZgkJEOIk2tnGBFhZ0giUBAQEEAQEBZAcKERwEAQEBCRYBAQYHCQMCAQIBFR8JCAYBDAYCAQGIAQ3LMhePBwEGhDIEhViSVIEyhRWLXIMt X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208,217";a="4716999" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-2.cisco.com with ESMTP; 18 Feb 2014 10:49:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1IAnlP7019604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Feb 2014 10:49:48 GMT Received: from [10.147.1.36] (dhcp-10-147-1-36.cisco.com [10.147.1.36]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s1IAnkZY025724; Tue, 18 Feb 2014 10:49:46 GMT Message-ID: <53033ACA.1050907@cisco.com> Date: Tue, 18 Feb 2014 10:49:46 +0000 From: Paul Aitken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "pm-dir@ietf.org" , draft-ietf-ospf-te-metric-extensions@tools.ietf.org References: <2845723087023D4CB5114223779FA9C8BC5B99F5@njfpsrvexg8.research.att.com> <2845723087023D4CB5114223779FA9C8BC5B9B79@njfpsrvexg8.research.att.com> <52FFEB1B.8010606@cisco.com> <2845723087023D4CB5114223779FA9C8BC5B9B95@njfpsrvexg8.research.att.com> <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> In-Reply-To: <036701cf2bf3$7c470470$74d50d50$@dhody@huawei.com> Content-Type: multipart/alternative; boundary="------------020907000709060609010502" Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/PMIef__K3L-nGKxwm6gznDR7G2M Subject: [pm-dir] draft-ietf-ospf-te-metric-extensions X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 10:50:02 -0000 This is a multi-part message in MIME format. --------------020907000709060609010502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The comments below are really applicable to draft-ietf-ospf-te-metric-extensions, which pm-dir hasn't been asked to review. Nevertheless, I hope that the authors will consider them useful for the next version. viz: . clearly indicate that these metrics are averages . indicate that the configurable interval is specified in section 7. Thanks, P. > *From:*MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > *Sent:* Sunday, February 16, 2014 7:15 PM > *To:* Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; > zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com > *Cc:* pm-dir@ietf.org > *Subject:* RE: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > All Paul's suggestions for increasing clarity are fine with me. > > Al > > *From:*Paul Aitken [mailto:paitken@cisco.com] > *Sent:* Saturday, February 15, 2014 5:33 PM > *To:* MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; > vishwas.manral@hp.com ; zali@cisco.com > ; swallow@cisco.com ; > ke-kumaki@kddi.com > *Cc:* pm-dir@ietf.org > *Subject:* Re: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > Al, All, > > For clarity, it would be better to name this as, "Average Delay > Variation". Similarly, 4.1 would be clearer as "Average Unidirectional > Link Delay Sub-TLV". > > Several parts of the text (4.1 through 4.4) say, "This (field) carries > the (metric) over a configurable interval". > > Is it important or necessary to convey the configured size of the > interval and the time of the interval (ie, whether it was 5ms, 5s, or > 5 minutes ago) ? > > */[DhruvDhody>] The metrics we have in this I.D. are calculated based > on link metrics defined in OSPF-TE draft [1], and is not measured > directly./* > > */Therefore the time of the interval is same as link metrics defined > in OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2]/* > > */We do not see a reason to mention this in the PCE I.D./* > > > *//*[1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05 > > [2] > http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-7 > > > P. > > > On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote: > > Hi Qin, authors, > > I read, in *draft-ietf-ospf-te-metric-extensions*: > > *4.3.4* > *. > Delay Variation* > > This 24-bit field carries the average link delay variation over a > > configurable interval in micro-seconds, encoded as an integer > value. > > When set to 0, it has not been measured. When set to the maximum > > value 16,777,215 (16.777215 sec), then the delay is at least that > > value and may be larger. > > So this is an **average** DV, to my surprise, > > and therefore the sum function Qin proposed is reasonable. > > (it still doesn't say here what form of delay variation has been > measured) > > However, delay variation is better characterized in summary > > statistics which describe the breadth of the DV distribution. > > In bimodal delay distributions, the average can be misleading. > > But you have what you have in *draft-ietf-ospf-te-metric-extensions* > > for now, and summing averages is an easy problem. Use RFC6049 > > for the other metrics, like loss and delay. > > regards, > > Al > > *From:*Qin Wu [mailto:bill.wu@huawei.com] > *Sent:* Friday, February 14, 2014 9:36 PM > *To:* MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com > ; zali@cisco.com > ; swallow@cisco.com > ; ke-kumaki@kddi.com > > *Cc:* pm-dir@ietf.org > *Subject:* RE: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > Hi, Al: > > You raise very good comments for this. Here are a few thoughts below. > > Regards! > > -Qin > > *From:*MORTON, ALFRED C (AL) [mailto:acmorton@att.com] > *Sent:* Friday, February 14, 2014 10:20 PM > *To:* Qin Wu; Dhruv Dhody; vishwas.manral@hp.com > ; zali@cisco.com > ; swallow@cisco.com > ; ke-kumaki@kddi.com > > *Cc:* pm-dir@ietf.org > *Subject:* RE: [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > A few additional comments, we can help the authors a bit more > > I think, but Qin was on the right track. > > Al > > Qin wrote: > > *3. Section 4.2 says:* > > " > > - A Latency variation of link L is denoted DV(L). > > - A P2P latency variation metric for the Path P = function > {DV(Lpi), > > (i=1...K)}. > > " > > Why not sum of latency variation metrics of individual links? > > ------------------------------------------------------- > > Sum is a rather worst-case approximation of the Path DV. > > We have studied these sorts of e2e Path estimates in IPPM. > > Packet Delay Variation is the most complex, but a couple of > > possibilities for "function" are specified here: > > http://tools.ietf.org/html/rfc6049#page-20 > > *[Qin]: Yes, it is a rat hole that needs to be fixed.* > > *Do you know how the function defined in section 6.4.5.1 of RFC6049* > > *Can be applied to this draft and quoted as function of latency > variation* > > *For complete path from source to destination.* > > ** > > *It seems to me we only know delay variation of each sub path, > which is * > > *gathered from link delay variation advertisement defined in * > > *draft-ietf-ospf-te-metric-extensions. The unit of delay variation > of each sub path* > > *is millisecond.* > > ** > > *Using sum may be the worse case approximation of path DV and > cause the granularity * > > *of measurement result very coarse, but the computation overhead* > > *for calculation of path DV can be minimized.* > > *If we use integral function defined in section 6.4.5.1 of > RFC6049, definitely we* > > *Can improve granularity of measurement/calculation result but at > the cost of* > > *Consuming more computation overhead. So there is tradeoff to pick > one or another.* > > ** > > Similarly, we have functions, which could be cited as references > > in this draft, for loss > > http://tools.ietf.org/html/rfc6049#page-18 > > *[Qin]: Yes, I agree Composition Function defined in section 5.1.5 > can be* > > *cited as reference for this draft.* > > and for mean delay > > http://tools.ietf.org/html/rfc6049#section-4.2 > > So, no need to leave the "function" unspecified and out of scope, > > assuming your loss and delay metric definitions are compatible. > > [Qin]: Exactly. > > *From:*pm-dir [mailto:pm-dir-bounces@ietf.org] *On Behalf Of *Qin Wu > *Sent:* Friday, February 14, 2014 5:44 AM > *To:* Dhruv Dhody; vishwas.manral@hp.com > ; zali@cisco.com > ; swallow@cisco.com > ; ke-kumaki@kddi.com > > *Cc:* pm-dir@ietf.org > *Subject:* [pm-dir] Request for an RFC 6390 review of > draft-ietf-pce-pcep-service-aware-02 > > Hi, authors: > > I am assigned Performance Directorate reviewer for this draft. > > Here is my review to this draft. > > This draft uses the link latency, latency variation and packet > loss information for end to end path selection. > > The link latency, latency variation and packet loss metrics are > defined in OSPF-TE draft and ISIS-TE draft and > > used to calculate path metrics described in this draft, e.g., P2P > latency metric, P2P latency variation metric, packet loss > > metric, P2MP latency metric, P2MP latency variation metric. > > These calculated path metrics( 6 metrics) are carried in PCEP > message using the same Metric Object with different metric type. > > The calculated metrics are used as constraint for path computation > > In this draft, each calculated metric is discussed in each > separate section from metric name, metric description > > perspective to measurement unit, calculation method perspective. > > IANA is also requested to register these 6 metric types. Therefore > I believe this draft conforms to RFC6390 guideline. > > However I have a few comments regarding these metrics definitions. > > *1. Section 4, 2^nd paragraph says:* > > " > > This document defines the following optional types for the METRIC > > object defined in [RFC5440]. > > " > > s/defined in [RFC5440]/defined in section 7.4 of [RFC5440] > > *2. Section 4.1 says:* > > " > > Link delay metric is defined in [OSPF-TE-EXPRESS] and > > [ISIS-TE-EXPRESS]. P2P latency metric type of METRIC object in PCEP > > encodes the sum of the link delay metric of all links along a P2P > > Path. Specifically, extending on the above mentioned terminology: > > - A Link delay metric of link L is denoted D(L). > > - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}. > > * T=13(TBA - IANA): Latency metric > > " > > For people who are not familiar with Metrics Object Format, it is > not easy to figure out what T=13 stands for? Would it be good to > add some context text or > > Introduce Metric Object format first. > > ** > > ** > > *3. Section 4.2 says:* > > " > > - A Latency variation of link L is denoted DV(L). > > - A P2P latency variation metric for the Path P = function {DV(Lpi), > > (i=1...K)}. > > " > > Why not sum of latency variation metrics of individual links? > > *4. Section 4.2 says:* > > " > > Specification of the "Function" used to drive latency variation > > metric of a path from latency variation metrics of individual links > > along the path is beyond the scope of this document. > > " > > s/drive/derive > > *5. Section 4* > > Section 4.3 says: > > "Packet Loss Metric metric type of METRIC Object" > > Section 4.2 says: > > "P2P latency variation metric type of METRIC > > Object" > > For consistency, you may either use "xx Metric metric type" or "xx > metric type of Metric Object". > > *6.Section 4.3 says:* > > " > > The end to end Packet Loss for the path is represented by this > > metric. > > - A Packet loss of link L is denoted PL(L). > > - A P2P packet loss metric for the Path P = function {PL(Lpi), > > (i=1...K)}. > > " > > Is function of packet loss metric of individual link same as > function of latency variation metric of individual link? > > If they are not same, please use different function name, e.g., > function a for packet loss, function b for latency variation? > > Regards! > > -Qin > > > > _______________________________________________ > > pm-dir mailing list > > pm-dir@ietf.org > > https://www.ietf.org/mailman/listinfo/pm-dir > --------------020907000709060609010502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The comments below are really applicable to draft-ietf-ospf-te-metric-extensions, which pm-dir hasn't been asked to review.

Nevertheless, I hope that the authors will consider them useful for the next version.

viz:

• clearly indicate that these metrics are averages
• indicate that the configurable interval is specified in section 7.


Thanks,
P.

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Sunday, February 16, 2014 7:15 PM
To: Paul Aitken; Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

All Paul's suggestions for increasing clarity are fine with me.

Al

 

From: Paul Aitken [mailto:paitken@cisco.com]
Sent: Saturday, February 15, 2014 5:33 PM
To: MORTON, ALFRED C (AL); Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: Re: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

Al, All,

For clarity, it would be better to name this as, "Average Delay Variation". Similarly, 4.1 would be clearer as "Average Unidirectional Link Delay Sub-TLV".

Several parts of the text (4.1 through 4.4) say, "This (field) carries the (metric) over a configurable interval".

Is it important or necessary to convey the configured size of the interval and the time of the interval (ie, whether it was 5ms, 5s, or 5 minutes ago) ?

[DhruvDhody>] The metrics we have in this I.D.  are calculated based on link metrics defined in OSPF-TE draft [1], and is not measured directly.

Therefore the time of the interval is same as link metrics defined in OSPF-TE draft. OSPF-TE draft section 7 discusses this. [2]

We do not see a reason to mention this in the PCE I.D.


[1] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05

[2] http://tools.ietf.org/html/draft-ietf-ospf-te-metric-extensions-05#section-7


P.


On 15/02/2014 13:42, MORTON, ALFRED C (AL) wrote:

Hi Qin, authors,

 

I read, in draft-ietf-ospf-te-metric-extensions:

4.3.4. Delay Variation

   This 24-bit field carries the average link delay variation over a

   configurable interval in micro-seconds, encoded as an integer value.

   When set to 0, it has not been measured. When set to the maximum

   value 16,777,215 (16.777215 sec), then the delay is at least that

   value and may be larger.

 

So this is an *average* DV, to my surprise,

and therefore the sum function Qin proposed is reasonable.

 

(it still doesn't say here what form of delay variation has been measured)

 

However, delay variation is better characterized in summary

statistics which describe the breadth of the DV distribution.

In bimodal delay distributions, the average can be misleading.

 

But you have what you have in draft-ietf-ospf-te-metric-extensions

for now, and summing averages is an easy problem.  Use RFC6049

for the other metrics, like loss and delay.

 

regards,

Al

 

 

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Friday, February 14, 2014 9:36 PM
To: MORTON, ALFRED C (AL); Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

Hi, Al:

You raise very good comments for this. Here are a few thoughts below.

 

Regards!

-Qin

 

From: MORTON, ALFRED C (AL) [mailto:acmorton@att.com]
Sent: Friday, February 14, 2014 10:20 PM
To: Qin Wu; Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: RE: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

A few additional comments, we can help the authors a bit more

I think, but Qin was on the right track.

 

Al

 

Qin wrote:

3. Section 4.2 says:

“

   - A Latency variation of link L is denoted DV(L).

 

   - A P2P latency variation metric for the Path P = function {DV(Lpi),

   (i=1...K)}.

”

Why not sum of latency variation metrics of individual links?

-------------------------------------------------------

 

Sum is a rather worst-case approximation of the Path DV.

 

We have studied these sorts of e2e Path estimates in IPPM.

Packet Delay Variation is the most complex, but a couple of

possibilities for "function" are specified here:

http://tools.ietf.org/html/rfc6049#page-20

 

[Qin]: Yes, it is a rat hole that needs to be fixed.

Do you know how the function defined in section 6.4.5.1 of RFC6049

Can be applied to this draft and quoted as function of latency variation

For complete path from source to destination.

 

It seems to me we only know delay variation of each sub path, which is

gathered from link delay variation advertisement defined in

draft-ietf-ospf-te-metric-extensions. The unit of delay variation of each sub path

is millisecond.

 

Using sum may be the worse case approximation of path DV and cause the granularity

of measurement result very coarse, but the computation overhead

for calculation of path DV can be minimized.

If we use integral function defined in section 6.4.5.1 of RFC6049, definitely we

Can improve granularity of measurement/calculation result but at the cost of

Consuming more computation overhead. So there is tradeoff to pick one or another.

 

 

Similarly, we have functions, which could be cited as references

in this draft, for loss

http://tools.ietf.org/html/rfc6049#page-18

 

[Qin]: Yes, I agree Composition Function defined in section 5.1.5 can be

cited as reference for this draft.

 

and for mean delay

http://tools.ietf.org/html/rfc6049#section-4.2

 

So, no need to leave the "function" unspecified and out of scope,

assuming your loss and delay metric definitions are compatible.

 

[Qin]: Exactly.

 

 

 

From: pm-dir [mailto:pm-dir-bounces@ietf.org] On Behalf Of Qin Wu
Sent: Friday, February 14, 2014 5:44 AM
To: Dhruv Dhody; vishwas.manral@hp.com; zali@cisco.com; swallow@cisco.com; ke-kumaki@kddi.com
Cc: pm-dir@ietf.org
Subject: [pm-dir] Request for an RFC 6390 review of draft-ietf-pce-pcep-service-aware-02

 

Hi, authors:

I am assigned Performance Directorate reviewer for this draft.

Here is my review to this draft.

 

This draft uses the link latency, latency variation and packet loss information for end to end path selection.

The link latency, latency variation and packet loss metrics are defined in OSPF-TE draft and ISIS-TE draft and

used to calculate path metrics described in this draft, e.g., P2P latency metric, P2P latency variation metric, packet loss

metric, P2MP latency metric, P2MP latency variation metric.

 

These calculated path metrics( 6 metrics) are carried in PCEP message using the same Metric Object with different metric type. 

The calculated metrics are used as constraint for path computation

 

In this draft, each calculated metric is discussed in each separate section from metric name, metric description

perspective to measurement unit, calculation method perspective.

IANA is also requested to register these 6 metric types. Therefore I believe this draft conforms to RFC6390 guideline.

However I have a few comments regarding these metrics definitions.

1. Section 4, 2nd paragraph says:

“

   This document defines the following optional types for the METRIC

   object defined in [RFC5440].

”

s/defined in [RFC5440]/defined in section 7.4 of [RFC5440]

 

2. Section 4.1 says:

“

   Link delay metric is defined in [OSPF-TE-EXPRESS] and

   [ISIS-TE-EXPRESS].  P2P latency metric type of METRIC object in PCEP

   encodes the sum of the link delay metric of all links along a P2P

   Path.  Specifically, extending on the above mentioned terminology:

 

   - A Link delay metric of link L is denoted D(L).

 

   - A P2P latency metric for the Path P = Sum {D(Lpi), (i=1...K)}.

 

   * T=13(TBA - IANA): Latency metric

”

For people who are not familiar with Metrics Object Format, it is not easy to figure out what T=13 stands for? Would it be good to add some context text or

Introduce Metric Object format first.

 

 

3. Section 4.2 says:

“

   - A Latency variation of link L is denoted DV(L).

 

   - A P2P latency variation metric for the Path P = function {DV(Lpi),

   (i=1...K)}.

”

Why not sum of latency variation metrics of individual links?

 

4. Section 4.2 says:

“

Specification of the "Function" used to drive latency variation

metric of a path from latency variation metrics of individual links

along the path is beyond the scope of this document.

”

s/drive/derive

 

5. Section 4

Section 4.3 says:

“Packet Loss Metric metric type of METRIC Object”

Section 4.2 says:

“P2P latency variation metric type of METRIC

   Object”

For consistency, you may either use “xx Metric metric type” or “xx metric type of Metric Object”.

 

6.Section 4.3 says:

“

   The end to end Packet Loss for the path is represented by this

   metric.

 

   - A Packet loss of link L is denoted PL(L).

 

   - A P2P packet loss metric for the Path P = function {PL(Lpi),

   (i=1...K)}.

”

Is function of packet loss metric of individual link same as function of latency variation metric of individual link?

If they are not same, please use different function name, e.g., function a for packet loss, function b for latency variation?

 

Regards!

-Qin

 

 

 

 



_______________________________________________
pm-dir mailing list
pm-dir@ietf.org
https://www.ietf.org/mailman/listinfo/pm-dir

 


--------------020907000709060609010502-- From nobody Thu Feb 20 04:04:46 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1891A00DB; Thu, 20 Feb 2014 04:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dK7LX98GP0M; Thu, 20 Feb 2014 04:04:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 820DE1A00B6; Thu, 20 Feb 2014 04:04:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140220120442.13246.47038.idtracker@ietfa.amsl.com> Date: Thu, 20 Feb 2014 04:04:42 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/7tQuq6DSUZ5nlBPlQNm31g7_HEk Cc: xrblock-chairs@tools.ietf.org, "Romascanu, Dan \(Dan\)" , "pm-dir@ietf.org" , draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric@tools.ietf.org Subject: [pm-dir] Benoit Claise's No Objection on draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01: (with COMMENT) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 12:04:45 -0000 Benoit Claise has entered the following ballot position for draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I put myself in the shoes of the operator looking at the different extended reports, and I'm trying to understand how to correlate the number of discarded bytes with number of discarded packets from the different extended reports. >From the document, there could be 3 different extended reports reporting the number of discarded packets: o Reporting the number of discarded packets in a measurement interval, i.e., during either the last reporting interval or since the beginning of the session, as indicated by a flag in the suggested XR report [RFC7002]. If an endpoint needs to report packet discard due to other reasons than early- and late-arrival (for example, discard due to duplication, redundancy, etc.) then it should consider using the Discarded Packets Report Block [RFC7002]. o Reporting gaps and bursts of discarded packets during a measurement interval, i.e., the last reporting interval or the duration of the session [RFC7003]. o Reporting run-length encoding of discarded packet during a measurement interval, i.e., between a set of sequence numbers [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]. First of all, it would be nice to mention that the measurement intervals from the different extended reports are synchronized. Talking to Dan Romacanu (btw thanks Dan), I understand that the number of bytes can be correlated to the number of packet in bullet 1 (RFC 7002) and/or in the bullet 3 ([I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]), depending on the flag value expressing whether we speak about delta or running counters. A few sentences (or a new section) about this would be an extremely useful addition from an operational point of view. Note: it was confusing to me that [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] refers to http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06, a very old version of the draft ... which still contains the bytes extended report. Mentioning RFC 7097 obviously solves that one. Thanks again Dan for gently highlighting the obvious to me :-) From nobody Fri Feb 21 02:56:20 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954771A0514; Fri, 21 Feb 2014 02:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXVohFpw276q; Fri, 21 Feb 2014 02:56:12 -0800 (PST) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2771A0512; Fri, 21 Feb 2014 02:56:11 -0800 (PST) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B7F9B27117C_30730C6B; Fri, 21 Feb 2014 10:56:06 +0000 (GMT) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 29096271177_30730C6F; Fri, 21 Feb 2014 10:56:06 +0000 (GMT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 1D5C51E0CC; Fri, 21 Feb 2014 12:56:06 +0200 (EET) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4dtzEatRph36; Fri, 21 Feb 2014 12:56:01 +0200 (EET) Received: from [192.168.0.12] (cs181253247.pp.htv.fi [82.181.253.247]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 991BF1E07D; Fri, 21 Feb 2014 12:56:00 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Varun Singh In-Reply-To: <20140220120442.13246.47038.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 12:55:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <511CBE17-4953-4834-97D7-0E99BBCFE2B3@comnet.tkk.fi> References: <20140220120442.13246.47038.idtracker@ietfa.amsl.com> To: Benoit Claise X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/3GslIOrqFHvlYxDHeZpPQMLfLHo Cc: "" , "Romascanu, Dan \(Dan\)" , "pm-dir@ietf.org" , The IESG , draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric@tools.ietf.org Subject: Re: [pm-dir] Benoit Claise's No Objection on draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01: (with COMMENT) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 10:56:15 -0000 Hi Benoit, Comments inline. Cheers, Varun On 20 Feb 2014, at 14:04, Benoit Claise wrote: >=20 > I put myself in the shoes of the operator looking at the different > extended reports, and I'm trying to understand how to correlate the > number of discarded bytes with number of discarded packets from the > different extended reports. >=20 >> =46rom the document, there could be 3 different extended reports = reporting > the number of discarded packets: >=20 > o Reporting the number of discarded packets in a measurement > interval, i.e., during either the last reporting interval or = since > the beginning of the session, as indicated by a flag in the > suggested XR report [RFC7002]. If an endpoint needs to report > packet discard due to other reasons than early- and late-arrival > (for example, discard due to duplication, redundancy, etc.) then > it should consider using the Discarded Packets Report Block > [RFC7002]. >=20 > o Reporting gaps and bursts of discarded packets during a > measurement interval, i.e., the last reporting interval or the > duration of the session [RFC7003]. >=20 > o Reporting run-length encoding of discarded packet during a > measurement interval, i.e., between a set of sequence numbers > [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]. >=20 >=20 > First of all, it would be nice to mention that the measurement = intervals > from the different extended reports are synchronised. > Talking to Dan Romacanu (btw thanks Dan), I understand that the number = of > bytes can be correlated to the number of packet in bullet 1 (RFC 7002) > and/or in the bullet 3 = ([I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]), > depending on the flag value expressing whether we speak about delta or > running counters. > A few sentences (or a new section) about this would be an extremely > useful addition from an operational point of view. >=20 Instead of creating another section or adding the comment to the = Introduction, I suggest adding it to Section 4, where the document discusses protocol=20= operation. NEW TEXT: 4.1. Reporting Node (Receiver) The media receiver MAY send the Bytes Discard Reports as part of the regularly scheduled RTCP packets as per RFC3550. It MAY also include Bytes Discard Reports in immediate or early feedback packets as per [RFC4585]. Transmission of RTCP XR Bytes Discarded Report is up to the discretion of the media receiver, as is the reporting granularity. However, it is RECOMMENDED that the media receiver signals the bytes discarded packets using the method defined in this document. When reporting several metrics in a single RTCP packet, the reporting intervals for the report blocks are synchronized, therefore the media receiver may choose to additionally send the Discarded Packets [RFC7002] or Discard RLE [RFC7097] Report Block to assist the media sender in correlating the bytes discarded to the packets discarded in that particular interval. If all packets over a reporting period were discarded, the media receiver MAY use the Discarded Packets Report Block [RFC7002] instead. > Note: it was confusing to me that=20 > [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] refers to > = http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-= 06, > a very old version of the draft ... which still contains the bytes > extended report. Mentioning RFC 7097 obviously solves that one. Thanks > again Dan for gently highlighting the obvious to me :-) >=20 Will be fixed in the upcoming version. From nobody Sun Feb 23 14:07:43 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCBB1A0752 for ; Sun, 23 Feb 2014 14:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0JMqx0ca71j for ; Sun, 23 Feb 2014 14:07:40 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id F327F1A074D for ; Sun, 23 Feb 2014 14:07:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s1NM7cNa008872 for ; Sun, 23 Feb 2014 23:07:39 +0100 (CET) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id s1NM7Le4024860 for ; Sun, 23 Feb 2014 23:07:32 +0100 (CET) Received: (from bclaise@localhost) by sweet-brew-5.cisco.com (8.13.8+Sun/8.13.6/Submit) id s1NM7Kbj014822 for pm-dir@ietf.org; Sun, 23 Feb 2014 23:07:20 +0100 (CET) Date: Sun, 23 Feb 2014 23:07:20 +0100 From: Benoit Claise To: pm-dir@ietf.org Message-ID: <20140223220720.GA14820@sweet-brew-5.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/NENyJDHAi7iKzgWYMqYALSwY7Xk Subject: [pm-dir] Performance metrics doctors generated email X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Feb 2014 22:07:41 -0000 Dear all, This is an automatically generated email. It lists the IETF internet-drafts that reference the PMOL RFC 6390, as a normative or informative reference. It also lists all the IETF internet-drafts that contain "performance metric". Regards, Benoit =========================================================== Normative References -------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state Informative References ---------------------- draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01Active draft-ietf-xrblock-rtcp-xr-psi-decodability-01 Active draft-ietf-xrblock-rtcp-xr-qoe-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state drafts containing performance metric ------------------------------------ draft-ietf-alto-deployments-09 Active draft-ietf-bmwg-sip-bench-term-09 Active draft-ietf-cdni-footprint-capabilities-semantics-02Active draft-ietf-idr-te-pm-bgp-00 Active draft-ietf-ippm-2330-update-02 Active draft-ietf-ippm-lmap-path-02 Active draft-ietf-ippm-model-based-metrics-02 Active draft-ietf-ippm-rate-problem-05 Active draft-ietf-ippm-testplan-rfc2680-04 In IESG processing - ID Tracker state draft-ietf-lmap-use-cases-02 Active draft-ietf-mmusic-sdp-mux-attributes-01 Active draft-ietf-nvo3-framework-05 In IESG processing - ID Tracker state draft-ietf-opsawg-oam-overview-14 In IESG processing - ID Tracker state draft-ietf-pce-pcep-service-aware-03 Active draft-ietf-ppsp-base-tracker-protocol-03 Active draft-ietf-ppsp-peer-protocol-08 Active draft-ietf-rtcweb-rtp-usage-12 Active draft-ietf-trill-loss-delay-02 Active draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-loss-conceal-09 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01Active draft-ietf-xrblock-rtcp-xr-psi-decodability-01 Active draft-ietf-xrblock-rtcp-xr-qoe-15 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xr-synchronization-08 In IESG processing - ID Tracker state draft-ietf-xrblock-rtcp-xt-discard-metrics-00 Active From nobody Mon Feb 24 15:02:24 2014 Return-Path: X-Original-To: pm-dir@ietfa.amsl.com Delivered-To: pm-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524121A0334; Mon, 24 Feb 2014 15:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.348 X-Spam-Level: X-Spam-Status: No, score=-7.348 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHQ-7xYt-h8U; Mon, 24 Feb 2014 15:02:16 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id E80661A01CB; Mon, 24 Feb 2014 15:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3880; q=dns/txt; s=iport; t=1393282936; x=1394492536; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=jqiDken+LwftDpbF864AY+7inKZeqiV/soESgJK5ijE=; b=Ba+8qUtgd8wom9FskDnQyoA35QcEmVafRmVniHojEav3QLOtmaDxdQw/ lFLDZASmEIT82ilBscfAp2Vu2kLUWsP7RwDR78yn95ZPDI+HEa0XhoNJV tujJgEf/qiwISeQ/RXPjIvLiX5McnIgi4iwZRZBNJdzzXtvy9L4EX0HvF 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMTOC1OQ/khN/2dsb2JhbABZgwY7wgSBIBZ0giUBAQEEOEABEAsYCRYECwkDAgECAUUGDQEFAgEBiAENxgIXjmQHhDgBA5g0gTKFFotfgW+BPzs X-IronPort-AV: E=Sophos;i="4.97,537,1389744000"; d="scan'208";a="6017537" Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 24 Feb 2014 23:02:14 +0000 Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1ON2DZS012699; Mon, 24 Feb 2014 23:02:14 GMT Message-ID: <530BCF75.8070602@cisco.com> Date: Tue, 25 Feb 2014 00:02:13 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Varun Singh References: <20140220120442.13246.47038.idtracker@ietfa.amsl.com> <511CBE17-4953-4834-97D7-0E99BBCFE2B3@comnet.tkk.fi> In-Reply-To: <511CBE17-4953-4834-97D7-0E99BBCFE2B3@comnet.tkk.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/NMXKcndoAQ0kU0CBUTQ83__q2aA Cc: "" , "Romascanu, Dan \(Dan\)" , "pm-dir@ietf.org" , The IESG , draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric@tools.ietf.org Subject: Re: [pm-dir] Benoit Claise's No Objection on draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01: (with COMMENT) X-BeenThere: pm-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Performance Metrics Directorate Discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:02:22 -0000 Hi Varun, That would be helpful. Thanks. Regards, Benoit > Hi Benoit, > > Comments inline. > > Cheers, > Varun > > On 20 Feb 2014, at 14:04, Benoit Claise wrote: > >> I put myself in the shoes of the operator looking at the different >> extended reports, and I'm trying to understand how to correlate the >> number of discarded bytes with number of discarded packets from the >> different extended reports. >> >>> From the document, there could be 3 different extended reports reporting >> the number of discarded packets: >> >> o Reporting the number of discarded packets in a measurement >> interval, i.e., during either the last reporting interval or since >> the beginning of the session, as indicated by a flag in the >> suggested XR report [RFC7002]. If an endpoint needs to report >> packet discard due to other reasons than early- and late-arrival >> (for example, discard due to duplication, redundancy, etc.) then >> it should consider using the Discarded Packets Report Block >> [RFC7002]. >> >> o Reporting gaps and bursts of discarded packets during a >> measurement interval, i.e., the last reporting interval or the >> duration of the session [RFC7003]. >> >> o Reporting run-length encoding of discarded packet during a >> measurement interval, i.e., between a set of sequence numbers >> [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]. >> >> >> First of all, it would be nice to mention that the measurement intervals >> from the different extended reports are synchronised. >> Talking to Dan Romacanu (btw thanks Dan), I understand that the number of >> bytes can be correlated to the number of packet in bullet 1 (RFC 7002) >> and/or in the bullet 3 ([I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]), >> depending on the flag value expressing whether we speak about delta or >> running counters. >> A few sentences (or a new section) about this would be an extremely >> useful addition from an operational point of view. >> > Instead of creating another section or adding the comment to the Introduction, > I suggest adding it to Section 4, where the document discusses protocol > operation. > > NEW TEXT: > > > 4.1. Reporting Node (Receiver) > > The media receiver MAY send the Bytes Discard Reports as part of the > regularly scheduled RTCP packets as per RFC3550. It MAY also include > Bytes Discard Reports in immediate or early feedback packets as per > [RFC4585]. > > Transmission of RTCP XR Bytes Discarded Report is up to the > discretion of the media receiver, as is the reporting granularity. > However, it is RECOMMENDED that the media receiver signals the bytes > discarded packets using the method defined in this document. When > reporting several metrics in a single RTCP packet, the reporting > intervals for the report blocks are synchronized, therefore the media > receiver may choose to additionally send the Discarded Packets > [RFC7002] or Discard RLE [RFC7097] Report Block to assist the media > sender in correlating the bytes discarded to the packets discarded in > that particular interval. > > If all packets over a reporting period were discarded, the media > receiver MAY use the Discarded Packets Report Block [RFC7002] > instead. > > >> Note: it was confusing to me that >> [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] refers to >> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-metrics-06, >> a very old version of the draft ... which still contains the bytes >> extended report. Mentioning RFC 7097 obviously solves that one. Thanks >> again Dan for gently highlighting the obvious to me :-) >> > Will be fixed in the upcoming version. > > . >