From matt@advanced.org Fri Dec 1 11:33:55 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09731 for ; Fri, 1 Dec 2000 11:33:54 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA02581 for ippm-l@advanced.org; Fri, 1 Dec 2000 11:19:47 -0500 (EST) Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA21036 for ; Fri, 1 Dec 2000 11:19:46 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id eB1GJe728514; Fri, 1 Dec 2000 11:19:40 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: , "Merike Kaeo" , "Allison Mankin" , "Will Leland" Subject: Agenda for IPPM in San Diego Date: Fri, 1 Dec 2000 11:25:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Proposed agenda for the IP Performance Metrics WG (ippm) Tuesday, 12 December 2000, 17:00-18:00 ====================================== Introduction of new co-chair & agenda bashing (<= 5 min) Discuss the new charter and milestones (15 min) Update on Bulk Transfer Capacity (10 min) --Mark Allman http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-03.txt Update on Network Performance Measurement for Periodic Streams (10 min) --Vilho Raisanen http://www.ietf.org/internet-drafts/draft-ietf-ippm-npmps-03.txt http://www.ietf.org/internet-drafts/draft-raisanen-ippm-npmps-results-00.txt (also http://www-nrc.nokia.com/netperf/results.pdf ) One-way delay protocol document discussion (10 min) -- Ben Teitelbaum http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-00.txt Discussion of any issues with IPDV or loss patterns -- speakers TBD, at least the chairs & Phil Chimento. http://www.ietf.org/internet-drafts/draft-ietf-ippm-ipdv-05.txt http://www.ietf.org/internet-drafts/draft-ietf-ippm-loss-pattern-04.txt --Matt From matt@advanced.org Fri Dec 1 17:29:30 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10490 for ; Fri, 1 Dec 2000 17:29:30 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA20403 for ippm-l@advanced.org; Fri, 1 Dec 2000 17:21:59 -0500 (EST) Received: from mucus.advanced.org (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA16292; Fri, 1 Dec 2000 17:21:55 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by mucus.advanced.org (Postfix) with ESMTP id 4429E10CB; Fri, 1 Dec 2000 17:21:37 -0500 (EST) Sender: ben@advanced.org Message-ID: <3A282471.C91280F5@internet2.edu> Date: Fri, 01 Dec 2000 17:21:37 -0500 From: Ben Teitelbaum Organization: Internet2 (UCAID) / Advanced Network & Services X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Tamas Varga Cc: ippm@advanced.org Subject: Re: I-D ACTION:draft-ietf-ippm-owdp-00.txt References: <200011242356.SAA00967@ietf.org> <3A2221FD.5FD9E3AA@eth.ericsson.se> <3A240F75.89A51E24@internet2.edu> <3A2626F3.42616444@eth.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tamas Varga wrote: > > Dear Ben, > > Ben Teitelbaum wrote: > > These are both helpful suggestions. With respect to the first comment, it > > would seem ideal to identify the Type-P explicitly during session initiation > > negotiation. However, since the notion of Type-P has not been formalized, I'm > > not quite sure how to do include a Type-P identifier. Any suggestions? > > As far as I understood Section 13 and 15 of RFC2330, type-P is a generic > notation for the packet/service type we want to measure. The problem is > that it can be substituted by different network, transport & application > layer protocols and the information required to describe them depends > on the protocol itself. But this is somewhat easier, since OWDP focuses > on UDP based test packets only. I think three things may be interesting > in the IP header: Type-of-Service (TOS), Time-to-time (TTL) and Don't > Fragment (DF) bit. Filling up TOS with an appropriate DSCP would be useful > to select packet treatment in a DiffServ network. TTL may limit the scope > of the measurements. (Anyway, what is if a multicast destination address > is specified? ). DF can be handy to ensure that the packet was transmitted > in one piece, otherwise we won't know how many of the fragments were lost. > > I think, setting DSCP is an essential feature. It should be included in > the Ression-Request message. There is a room nearby the port field. > The other two feautres may be handy, but it does not necesarily follow > that we should include them. > Tamas, Although I like the idea of TTL and DF, I don't actually like the idea of including DSCP explicitly. As the DiffServ working group has defined DSCPs, they have only local significance. Instead, I think what we want is the 16-bit RFC 2836 PHB identification code. This way, if you desire a particular PHB for your session, you need not know what DSCP in the Session-Sender's local environment is used to indicate it. > > With respect to your second comment, I am open to including an option to allow > > periodic sampling. We thought about supporting arbitrary distributions, but > > decided to keep things simple by including Poisson only. Adding an option for > > periodic sampling wouldn't add much complication, so I'm inclided to throw it > > into the next draft. > > Moreover uniform distribution can be useful, if we choose a random > value from the (0, 1/Inv-Lambda) interval. Other distributions require > more parameters, which makes the interpretation of the required fields > complicated. Anyway, periodic sampling is still reasonable, allocation > of 1 bit for this purpose is quite easy. Just curious, in what circumstances is a uniform distribution useful? > > Back to multicasting for a while. As I see, this question is not clarified > yet in the document. I think it is silently assumed, that unicast test flows > are used by the measurements. However, the architecture may be multicast > aware if the Server is able to track Session-Receivers. Yes, unicast was our silent assumption. As the document now stands, I don't think it would be particularly difficult to extend it to support multicast. We would add an additional Receiver field to each record of the Retrieve-Session response: {SeqNo, ReceiverAddr, SendTimestamp, RecvTimestamp} and then punt on exactly how a Server tracked Session-Receivers. -- ,,, `o-o- < Benjamin Teitelbaum - Advanced Network & Services, Inc. . Internet2 From matt@advanced.org Sat Dec 2 06:15:35 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26076 for ; Sat, 2 Dec 2000 06:15:35 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id GAA11632 for ippm-l@advanced.org; Sat, 2 Dec 2000 06:06:22 -0500 (EST) Received: from hotmail.com (oe12.law4.hotmail.com [216.33.148.116]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id GAA12254 for ; Sat, 2 Dec 2000 06:06:16 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 2 Dec 2000 03:05:44 -0800 X-Originating-IP: [139.179.145.10] From: "omurhan akdemir" To: Subject: Pathchar Date: Sat, 2 Dec 2000 13:02:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C05C60.18B36640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 02 Dec 2000 11:05:44.0921 (UTC) FILETIME=[D1407C90:01C05C4F] This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C05C60.18B36640 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable hi I wonder what the meaning of negative propagation delay values on = pathchar's output is. sample output: 2 sdscdmz-fddi.cerf.net (198.17.46.153) | 45 Mb/s, -13 us (2.70 ms) 3 qualcomm-sdsc-ds3.cerf.net (134.24.47.200) By the way, is there any way of plotting rtt of each probe of each = sample versus packet size? Kind regards omurhan=20 ------=_NextPart_000_0007_01C05C60.18B36640 Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable
hi
 
I wonder what the meaning of negative = propagation=20 delay values on pathchar's output is.
sample output:
 
2 sdscdmz-fddi.cerf.net (198.17.46.153)
=20 |    45 Mb/s,   -13 us (2.70 ms)
3=20 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
By the way, is there any way of = plotting rtt of=20 each probe of each sample versus packet size?
 
Kind regards
omurhan 
------=_NextPart_000_0007_01C05C60.18B36640-- From matt@advanced.org Sat Dec 2 10:47:17 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25771 for ; Sat, 2 Dec 2000 10:47:17 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA06342 for ippm-l@advanced.org; Sat, 2 Dec 2000 10:41:10 -0500 (EST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA14950 for ; Sat, 2 Dec 2000 10:41:09 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA83208 for ; Sat, 2 Dec 2000 10:11:42 -0600 Received: from d04nm203.raleigh.ibm.com (d04nm203.raleigh.ibm.com [9.67.228.40]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id KAA54054 for ; Sat, 2 Dec 2000 10:39:29 -0500 Importance: Normal Subject: Re: Pathchar To: X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Redha Bournas" Date: Sat, 2 Dec 2000 10:39:56 -0500 X-MIMETrack: Serialize by Router on D04NM203/04/M/IBM(Release 5.0.3 (Intl)|21 March 2000) at 12/02/2000 10:39:58 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id KAA03497 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id KAB06342 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA25771 unsubscribe. Thanks, Redha Bournas "omurhan akdemir" on 12/02/2000 06:02:16 AM To: cc: Subject: Pathchar hi I wonder what the meaning of negative propagation delay values on pathchar's output is. sample output: 2 sdscdmz-fddi.cerf.net (198.17.46.153) |    45 Mb/s,   -13 us (2.70 ms) 3 qualcomm-sdsc-ds3.cerf.net (134.24.47.200) By the way, is there any way of plotting rtt of each probe of each sample versus packet size? Kind regards omurhan From matt@advanced.org Mon Dec 4 03:08:37 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05456 for ; Mon, 4 Dec 2000 03:08:37 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id CAA27024 for ippm-l@advanced.org; Mon, 4 Dec 2000 02:55:18 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id CAA27176 for ; Mon, 4 Dec 2000 02:55:17 -0500 (EST) Received: from x54.ripe.net (x54.ripe.net [193.0.1.54]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id IAA29609; Mon, 4 Dec 2000 08:54:45 +0100 (CET) Received: (from marks@localhost) by x54.ripe.net (8.8.8/8.8.5) id IAA02844; Mon, 4 Dec 2000 08:54:45 +0100 (CET) Date: Mon, 4 Dec 2000 08:54:45 +0100 From: Mark Santcroos To: "omurhan akdemir" Cc: Subject: Re: Pathchar Message-ID: <20001204085444.A2746@ripe.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from omurhan@hotmail.com on Sat, Dec 02, 2000 at 01:02:16PM +0200 X-Handles: MS6-6BONE, MS32260-NIC, MS18417-RIPE On Sat, Dec 02, 2000 at 01:02:16PM +0200, omurhan akdemir wrote: > I wonder what the meaning of negative propagation delay values on > pathchar's output is. Hi Omurhan, Some types of networks are intrinsically difficult for pathchar to measure. Two notable examples are switched networks (with multiple queues at Layer 2) or striped networks. Router implementations may very well forward a packet faster than they can return an ICMP error message in response to a packet. Because of this fact, it's possible to see faster response times from longer partial paths; the result is a seemingly non-sensical, negative estimate of per-hop round-trip time. Btw. I suggest you to look at: http://www.employees.org/~bmah/Software/pchar/ Pchar is an open source re-implementation of Van Jacobson's Pathchar utility. (It is also where I have shamelessly stole the answer about negative rrt's from) Regards, Mark -- Mark Santcroos RIPE Network Coordination Centre PGP KeyID: 1024/0x3DCBEB8D PGP Fingerprint: BB1E D037 F29D 4B40 0B26 F152 795F FCAB 3DCB EB8D From matt@advanced.org Mon Dec 4 07:11:39 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24888 for ; Mon, 4 Dec 2000 07:11:38 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id HAA01809 for ippm-l@advanced.org; Mon, 4 Dec 2000 07:05:51 -0500 (EST) Received: from mcl.iis.u-tokyo.ac.jp (pipi.iis.u-tokyo.ac.jp [157.82.107.130]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA19467 for ; Mon, 4 Dec 2000 07:05:50 -0500 (EST) Received: from jubilo (jubilo [157.82.107.143]) by mcl.iis.u-tokyo.ac.jp (8.9.3/3.7W/99112604) with SMTP id VAA02176 for ; Mon, 4 Dec 2000 21:03:33 +0900 (JST) Message-ID: <007401c05deb$0d15e3d0$8f6b529d@iis.utokyo.ac.jp> From: "Leping HUANG" To: "IPPM Mailing list" Subject: finding bandwidth measurement tool Date: Mon, 4 Dec 2000 21:09:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Dear Sir/Madam: I want to do some measurement on my ADSL link, but feel some difficulty to find a suitable tools to do measurement. Because My ADSL link only has a private IP address, i can only measure the uplink using the tools like Pchar. Obviously, the downlink and uplink has different bandwidth, but i can not measure it.!! I think any-ICMP style measurement can not be used to measure my downlink bandwidth, is it correct? Are there any tools can be used to measure downlink bandwidth with/without receiver side damaon? thank you. Leping HUANG Sezaki Lab Institute of Industrial Science University of Tokyo lphuang@mcl.iis.u-tokyo.ac.jp office phone/FAX: +81(3)3403-2596 From matt@advanced.org Tue Dec 5 07:03:48 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18812 for ; Tue, 5 Dec 2000 07:03:48 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id GAA05617 for ippm-l@advanced.org; Tue, 5 Dec 2000 06:51:30 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id GAA11109; Tue, 5 Dec 2000 06:51:28 -0500 (EST) Received: from x49.ripe.net (x49.ripe.net [193.0.1.49]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id MAA07689; Tue, 5 Dec 2000 12:50:57 +0100 (CET) Received: from localhost (henk@localhost) by x49.ripe.net (8.8.8/8.8.5) with ESMTP id MAA24863; Tue, 5 Dec 2000 12:50:55 +0100 (CET) X-Authentication-Warning: x49.ripe.net: henk owned process doing -bs Date: Tue, 5 Dec 2000 12:50:55 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Matthew J Zekauskas cc: ippm@advanced.org, ben@advanced.org Subject: Re: Agenda for IPPM in San Diego In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ben, Matt, > Proposed agenda for the IP Performance Metrics WG (ippm) > > Tuesday, 12 December 2000, 17:00-18:00 > ====================================== > One-way delay protocol document discussion (10 min) > -- Ben Teitelbaum > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-00.txt I read the draft and have 2 major issues (besides a bunch of smaller comments, which I'll post to the list as soon as I've decoded my own handwriting in the margin). 1. The protocol assumes a setup mechanism for sessions. We've always used a different approach: tell the sender that it should send something to a target, tell the target that it should listen, but don't care if sender or target aren't ready yet. This has a practical advantage (it is much easier to implement) and a theoretical advantage: one can also easily measure losses over broken links (where a setup protocol will fail). The disadvantage is that it is harder to raise alarms when packets don't arrive. Should we try to include this method in the protocol? 2. Padding and such. In order to avoid compression along the way, we use a random bit pattern to pad the packets. (If you have a packet with lots of zero's, it may be compressed by some intelligent device, and thus get a travel time corresponding to a much shorter packet.) Besides that, we also include much more info in our packets, such as NTP (clock) errors, experimental status words, source and destination address, etc, etc. In short, each packet contains everything we want to know about the packet, without having to rely on other data at source/target. So, what we do is: * take N byte packet * Fill it with a random bit pattern. * Take a number between 0 and N-l (with l the number of bytes for all data). * Put the data starting somewhere between 0 and N-l. * Make the 0th byte a pointer to the data. What I think we should put in the draft is a mechanism for this, even if implementations decide that they don't want to or need to use it. (Perhaps we should sit down sometime before/after the meeting, since I have a feeling that we won't be able to resolve these issues in the 10 minutes allocated for this draft). Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Tue Dec 5 09:03:24 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24123 for ; Tue, 5 Dec 2000 09:03:24 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id IAA09911 for ippm-l@advanced.org; Tue, 5 Dec 2000 08:55:38 -0500 (EST) Received: from mucus.advanced.org (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id IAA11180; Tue, 5 Dec 2000 08:55:35 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by mucus.advanced.org (Postfix) with ESMTP id 1F7E610CB; Tue, 5 Dec 2000 08:55:37 -0500 (EST) Sender: ben@advanced.org Message-ID: <3A2CF3D9.CFF7ED2E@internet2.edu> Date: Tue, 05 Dec 2000 08:55:37 -0500 From: Ben Teitelbaum Organization: Internet2 (UCAID) / Advanced Network & Services X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Henk Uijterwaal (RIPE-NCC)" Cc: Matthew J Zekauskas , ippm@advanced.org, Stanislav Shalunov Subject: Re: Agenda for IPPM in San Diego References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Henk, I'm not sure I understand point 1). With what we have written, a client could request a session to begin at a future start time; the server can tell the sender to send and the receiver to listen (the means by which the server tells them is unspecified); then, if there is 100% packet loss at the time of the scheduled session, this is captured. Does that work for you? As for point 2), note that you can always run in Encrypted mode, which effectively fills the entire packet payload with random bits. Let's definitely sit down next week. Cheers, "Henk Uijterwaal (RIPE-NCC)" wrote: > > Ben, Matt, > > > Proposed agenda for the IP Performance Metrics WG (ippm) > > > > Tuesday, 12 December 2000, 17:00-18:00 > > ====================================== > > > One-way delay protocol document discussion (10 min) > > -- Ben Teitelbaum > > http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-00.txt > > I read the draft and have 2 major issues (besides a bunch of smaller > comments, which I'll post to the list as soon as I've decoded my own > handwriting in the margin). > > 1. The protocol assumes a setup mechanism for sessions. We've always > used a different approach: tell the sender that it should send > something to a target, tell the target that it should listen, but > don't care if sender or target aren't ready yet. > > This has a practical advantage (it is much easier to implement) and > a theoretical advantage: one can also easily measure losses over > broken links (where a setup protocol will fail). The disadvantage > is that it is harder to raise alarms when packets don't arrive. > > Should we try to include this method in the protocol? > > 2. Padding and such. > > In order to avoid compression along the way, we use a random bit > pattern to pad the packets. (If you have a packet with lots of > zero's, it may be compressed by some intelligent device, and thus > get a travel time corresponding to a much shorter packet.) > > Besides that, we also include much more info in our packets, such > as NTP (clock) errors, experimental status words, source and > destination address, etc, etc. In short, each packet contains > everything we want to know about the packet, without having to > rely on other data at source/target. > > So, what we do is: > * take N byte packet > * Fill it with a random bit pattern. > * Take a number between 0 and N-l (with l the number of bytes for > all data). > * Put the data starting somewhere between 0 and N-l. > * Make the 0th byte a pointer to the data. > > What I think we should put in the draft is a mechanism for this, even > if implementations decide that they don't want to or need to use it. > > (Perhaps we should sit down sometime before/after the meeting, since I > have a feeling that we won't be able to resolve these issues in the 10 > minutes allocated for this draft). > > Henk > > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.535-4414, Fax -4445 > 1016 AB Amsterdam Home: +31.20.4195305 > The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > A man can take a train and never reach his destination. > (Kerouac, well before RFC2780). -- ,,, `o-o- < Benjamin Teitelbaum - Advanced Network & Services, Inc. . Internet2 From matt@advanced.org Tue Dec 5 09:31:16 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28327 for ; Tue, 5 Dec 2000 09:31:15 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA12251 for ippm-l@advanced.org; Tue, 5 Dec 2000 09:25:35 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA14136; Tue, 5 Dec 2000 09:25:34 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id JAA06792; Tue, 5 Dec 2000 09:25:32 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 83524767; Tue, 5 Dec 2000 09:25:31 -0500 (EST) Sender: shalunov@internet2.edu To: "Henk Uijterwaal (RIPE-NCC)" Cc: Matthew J Zekauskas , ippm@advanced.org, ben@advanced.org Subject: draft-ietf-ippm-owdp-00 References: From: stanislav shalunov Date: 05 Dec 2000 09:25:31 -0500 In-Reply-To: Message-ID: <874s0j6j38.fsf@cain.internet2.edu> Lines: 38 X-Mailer: Gnus v5.7/Emacs 20.4 "Henk Uijterwaal (RIPE-NCC)" writes: > 1. The protocol assumes a setup mechanism for sessions. We've always > used a different approach: tell the sender that it should send > something to a target, tell the target that it should listen, but > don't care if sender or target aren't ready yet. > > This has a practical advantage (it is much easier to implement) and > a theoretical advantage: one can also easily measure losses over > broken links (where a setup protocol will fail). The disadvantage > is that it is harder to raise alarms when packets don't arrive. > > Should we try to include this method in the protocol? Henk, The reason for the setup mechanisms is to allow for a wide range of possible applications of the protocol. A central notion is to be able to run "open" servers--have a one-way ping. > 2. Padding and such. The reason padding isn't just supposed to be unspecified pseudo-random is concern about high-bandwidth covert channels. Depending on how much of a concern it is for other people we can take different routes: * Make it unspecified pseudo-random; * Take pseudo-random bits from the same source as the one used to obtain inter-packet times; * Use some well-defined source of pseudo-random bits, same for all flows. -- Stanislav Shalunov Internet Engineer, Internet2 Sex is the mathematics urge sublimated. -- M. C. Reed. From matt@advanced.org Tue Dec 5 16:39:28 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21722 for ; Tue, 5 Dec 2000 16:39:27 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA22891 for ippm-l@advanced.org; Tue, 5 Dec 2000 16:30:47 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA26155 for ; Tue, 5 Dec 2000 16:30:46 -0500 (EST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20201; Tue, 5 Dec 2000 13:30:20 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id eB5LUEA82889; Tue, 5 Dec 2000 13:30:14 -0800 (PST) (envelope-from bmah) Message-Id: <200012052130.eB5LUEA82889@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Mark Santcroos Cc: "omurhan akdemir" , ippm@advanced.org Subject: Re: Pathchar In-Reply-To: <20001204085444.A2746@ripe.net> References: <20001204085444.A2746@ripe.net> Comments: In-reply-to Mark Santcroos message dated "Mon, 04 Dec 2000 08:54:45 +0100." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1429404380P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 05 Dec 2000 13:30:14 -0800 Sender: bmah@cisco.com --==_Exmh_1429404380P Content-Type: text/plain; charset=us-ascii If memory serves me right, Mark Santcroos wrote: > On Sat, Dec 02, 2000 at 01:02:16PM +0200, omurhan akdemir wrote: > > I wonder what the meaning of negative propagation delay values on > > pathchar's output is. [snip] > Some types of networks are intrinsically difficult for pathchar to > measure. Two notable examples are switched networks (with multiple > queues at Layer 2) or striped networks. These facts are true, but most likely not quite the explanation for what the original poster was asking about. > Router implementations may very well forward a packet faster than they > can return an ICMP error message in response to a packet. Because of > this fact, it's possible to see faster response times from longer > partial paths; the result is a seemingly non-sensical, negative > estimate of per-hop round-trip time. This is more likely to be the case. Another possibility is that large (or fluctuating) queue lengths at an interface can interfere with the linear fit algorithms used by pathchar. > Btw. I suggest you to look at: > http://www.employees.org/~bmah/Software/pchar/ > > Pchar is an open source re-implementation of Van Jacobson's Pathchar > utility. (It is also where I have shamelessly stole the answer about > negative rrt's from) :-) Another implementation is clink; while it doesn't run on as many platforms as pchar does, it does a couple of things that pchar doesn't do such as kernel-level timestamps. There's a link to it from pchar's Web page. Bruce. --==_Exmh_1429404380P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6LV5m2MoxcVugUsMRAvL0AJ9GCPx8DmuuxOUN2wjk9XL+sfblBACdESDu hDSjhGMg3QILnouPeQ2G1kU= =0+p0 -----END PGP SIGNATURE----- --==_Exmh_1429404380P-- From matt@advanced.org Wed Dec 6 19:34:25 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19522 for ; Wed, 6 Dec 2000 19:34:24 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id TAA28379 for ippm-l@advanced.org; Wed, 6 Dec 2000 19:24:43 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id TAA26948 for ; Wed, 6 Dec 2000 19:24:42 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id TAA10002 for ; Wed, 6 Dec 2000 19:24:41 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 4D805767; Wed, 6 Dec 2000 19:24:36 -0500 (EST) Sender: shalunov@internet2.edu To: ippm@advanced.org Subject: draft-ietf-ippm-owdp-01 From: stanislav shalunov Date: 06 Dec 2000 19:24:35 -0500 Message-ID: <87ofyp2i4c.fsf@cain.internet2.edu> Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.4 New version of draft-ietf-ippm-owdp is now available at http://www.internet2.edu/~shalunov/draft-ietf-ippm-owdp-01.txt (and will be available on the IETF server after accepting drafts is resumed). This is the version that will be presented during next week's IETF meeting. It fills gaps in version -00, fixes some bugs, and incorporates some feedback we received from the working group. -- Stanislav Shalunov Internet Engineer, Internet2 "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw From matt@advanced.org Thu Dec 7 17:01:25 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14529 for ; Thu, 7 Dec 2000 17:01:25 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA28262 for ippm-l@advanced.org; Thu, 7 Dec 2000 16:53:46 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA00038 for ; Thu, 7 Dec 2000 16:53:45 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id WAA15127; Thu, 7 Dec 2000 22:53:13 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id WAA26862; Thu, 7 Dec 2000 22:53:13 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Thu, 7 Dec 2000 22:53:13 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: ippm@advanced.org Subject: Re: draft-ietf-ippm-owdp-00 In-Reply-To: <874s0j6j38.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On 5 Dec 2000, stanislav shalunov wrote: > "Henk Uijterwaal (RIPE-NCC)" writes: > > > 1. The protocol assumes a setup mechanism for sessions. We've always > > used a different approach: tell the sender that it should send > > something to a target, tell the target that it should listen, but > > don't care if sender or target aren't ready yet. > > > > This has a practical advantage (it is much easier to implement) and > > a theoretical advantage: one can also easily measure losses over > > broken links (where a setup protocol will fail). The disadvantage > > is that it is harder to raise alarms when packets don't arrive. > > > > Should we try to include this method in the protocol? > > Henk, > > The reason for the setup mechanisms is to allow for a wide range of > possible applications of the protocol. A central notion is to be able > to run "open" servers--have a one-way ping. We basically have to solve 2 problems here: a) How to do measurements with 2 different devices. This requires that the packet formats are understandable by both sides. b) How to set up a measurement relation between source and target. A setup mechanism is one possible method to accomplish (b) but there are lots of others and I don't think that we should limit ourselves to one method unless there are convincing technical arguments. This is something we should really discuss by voice next week. > > 2. Padding and such. > > The reason padding isn't just supposed to be unspecified pseudo-random > is concern about high-bandwidth covert channels. Please explain. > Depending on how > much of a concern it is for other people we can take different routes: > > * Make it unspecified pseudo-random; Isn't user data sent over a link random (when viewed by a machine)? Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Thu Dec 7 17:30:32 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18961 for ; Thu, 7 Dec 2000 17:30:31 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA28333 for ippm-l@advanced.org; Thu, 7 Dec 2000 17:25:18 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA21435 for ; Thu, 7 Dec 2000 17:25:17 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id RAA00827; Thu, 7 Dec 2000 17:25:15 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id C22327C6; Thu, 7 Dec 2000 17:25:13 -0500 (EST) Sender: shalunov@internet2.edu To: "Henk Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org Subject: Re: draft-ietf-ippm-owdp-00 References: From: stanislav shalunov Date: 07 Dec 2000 17:25:13 -0500 In-Reply-To: Message-ID: <8766kv27jq.fsf@cain.internet2.edu> Lines: 51 X-Mailer: Gnus v5.7/Emacs 20.4 "Henk Uijterwaal (RIPE-NCC)" writes: > We basically have to solve 2 problems here: > > a) How to do measurements with 2 different devices. > This requires that the packet formats are understandable by both sides. > > b) How to set up a measurement relation between source and target. > > A setup mechanism is one possible method to accomplish (b) but there are > lots of others and I don't think that we should limit ourselves to one > method unless there are convincing technical arguments. This is something > we should really discuss by voice next week. Henk, I think nothing in the draft implies that OWDP-Test sessions have to be set up with OWDP-Control only. One can imagine situations when it is convenient to set the sessions up using different means, and retrieve the results using yet another method. Of course, connection parameters have to be somehow transferred anyway. Should we explicitly mention the possibility of use of OWDP-Test without OWDP-Control? (In fact, if you make Server, Retrieve-Client and Control-Client the same host in logical roles picture on p.3 of -01, it collapses into set up without OWDP-Control.) > On 5 Dec 2000, stanislav shalunov wrote: > > The reason padding isn't just supposed to be unspecified pseudo-random > > is concern about high-bandwidth covert channels. > > Please explain. I had in mind environments where covert channels can be viewed as a problem (secretive commercial world, the military, etc.). Low-bandwidth covert channels are of course always available in any network, but unspecified padding of large packets could be used to funnel data out of a network at a high rate. After thinking about your comment and some internal discussion padding is changed to unspecified pseudo-random with a message to implementers to make available a switch for zero padding. Does this address your concern? -- Stanislav Shalunov Internet Engineer, Internet2 Sex is the mathematics urge sublimated. -- M. C. Reed. From matt@advanced.org Thu Dec 7 21:07:24 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03181 for ; Thu, 7 Dec 2000 21:07:23 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA02242 for ippm-l@advanced.org; Thu, 7 Dec 2000 20:59:34 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA04304 for ; Thu, 7 Dec 2000 20:59:33 -0500 (EST) Received: from hogpa.mt.att.com ([135.16.74.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id eB81x2508258 for ; Thu, 7 Dec 2000 20:59:02 -0500 (EST) Received: from acmortonw by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id UAA27291; Thu, 7 Dec 2000 20:58:58 -0500 Message-Id: <3.0.32.20001207205854.0068d0c4@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 07 Dec 2000 20:58:58 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: FW: draft-ietf-ippm-npmps-03.txt; IPPM-style measurement results Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id UAA05523 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id UAB02242 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA03181 Vilho, Glenn, and all, Your new draft deserves at least one (minor) comment. Section 4.2.1 gives the Global Metric Parameters, one of which is: + periodic packet interval incT, a time duration In practice, it may be difficult for measurement sources to maintain this periodic sending interval exactly. I'd like to suggest adding a new parameter for section 4.2.2 Metrics Reported at MP(Src) to cover the cases where sending times have some variation from the ideal interval. Something like: + incTerror, offset from the specified incT (could be reported on a per packet basis, or as a range at the end of test). Note that packetized real-time media streams from users may also exhibit variation from strict periodic launch times. The point is to capture and report any variation so it doesn't get lost. Regards, Al Morton At 03:47 PM 11/22/00 +0200, vilho.raisanen@nokia.com wrote: > > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Vilho Räisänen > vilho.raisanen@nokia.com > Senior research engineer > Nokia Research Center, Helsinki, Finland >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > >Dear IPPM list members, > >I submitted the latest revised form (-03) of the npmps draft >today to internet-drafts@ietf.org; it is also available at > >http://www-nrc.nokia.com/netperf/npmps-03.txt > >Moreover, following the advice of IPPM chairs, I made an >independent draft submission of VoIP media stream emulation >measurement results using metrics using npmps-like metrics. >The full draft with figures is available from > >http://www-nrc.nokia.com/netperf/results.pdf > >and a version with good old ASCII from > >http://search.ietf.org/internet-drafts/draft-raisanen-ippm-npmps-results-00. >txt > > Cheers, > Vilho > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Vilho Räisänen > vilho.raisanen@nokia.com > Senior research engineer > Nokia Research Center, Helsinki, Finland >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > > From matt@advanced.org Thu Dec 7 21:07:28 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03206 for ; Thu, 7 Dec 2000 21:07:27 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id VAA04424 for ippm-l@advanced.org; Thu, 7 Dec 2000 21:03:26 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id VAA05745 for ; Thu, 7 Dec 2000 21:02:29 -0500 (EST) Received: from hogpa.mt.att.com ([135.16.74.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id eB821wY00778 for ; Thu, 7 Dec 2000 21:01:58 -0500 (EST) Received: from acmortonw by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id VAA27444; Thu, 7 Dec 2000 21:01:54 -0500 Message-Id: <3.0.32.20001207210151.006d58e8@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 07 Dec 2000 21:01:54 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: Comments on draft-ietf-ippm-ipdv.05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" IPPM folks, There has been a pause in the discussion on delay variation since Phil Chimento offered to begin a serious re-write. I'd like to offer my support of Mike Pierce's position, that measuring a set of delays and determining their variation provides information beyond what is available with the current metric (the difference in delay between consecutive packet pairs). I've got the impression that Phil will be attempting to include both these metrics in the text of the new draft (is that right, Phil?). Assuming both these metrics are described in ipdv-06, it may help to capture the advantages of each, providing guidance to future readers. Much of this material could be distilled from the recent messages. Since my past efforts have been mostly associated with ITU-T and T1A1, I'll change hats and highlight what I consider to be two key advantages of the current ipdv metric: Ruediger Geib's message reminds us that the pair-wise delay differences can be calculated without synchronized measurement clocks. When all the code and the wires come together (implementation time), it can be very comforting to know that this measurement will be useful even if others must be discarded due to clock synchronization problems. Another point for ipdv is its similarity to the calculation of interarrival jitter measurement in RTCP reports. RFC 1889 (RTP) gives the calculation of interarrival jitter in section 6.3.1, with a sample implementation in an appendix. Although there are some differences in method (RTCP interarrival jitter uses order of arrival, as opposed to sending sequence with ipdv) there should be a favorable comparison between a "smoothed jitter" computed using ipdv singletons and the RTCP reports of jitter in many circumstances (If many packets were re-ordered, the results would probably not agree). It seems valuable to have a metric that can be related to measurements made by user's endpoints. Shortly, the ITU-T will be having discussions on performance parameters for delay variation. I'm convinced that both metrics should be included in the appropriate Recommendations there as well. Regards, Al Morton From matt@advanced.org Fri Dec 8 10:05:08 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25559 for ; Fri, 8 Dec 2000 10:05:08 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id JAA15044 for ippm-l@advanced.org; Fri, 8 Dec 2000 09:57:03 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id JAA17567 for ; Fri, 8 Dec 2000 09:57:02 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA23736 for ; Fri, 8 Dec 2000 07:57:02 -0700 (MST)] Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA06616 for ; Fri, 8 Dec 2000 07:57:02 -0700 (MST)] Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Dec 2000 08:57:01 -0600 Message-ID: From: Grotefeld Glenn-cecl03 To: "'Al Morton'" , ippm@advanced.org Subject: RE: FW: draft-ietf-ippm-npmps-03.txt; IPPM-style measurement res ults Date: Fri, 8 Dec 2000 08:57:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id JAA17842 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id JAB15044 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA25559 Al, One item to be concerned about is that with a MP(Src) that is truly independent of Src, MP (Src)is NOT responsible for sending times, but merely reports on them. I wanted the flexibility for Src can generate packets that may not follow the "incT" interval, but without any other signaling or messaging that could distort the performance compared to times when Src is NOT being measured. I am NOT convinced that we should introduce this change. Rather than introducing a new variable, I would prefer to change the description to " + nominal periodic packet interval incT, a time duration". This would increase the tie-in to section 4.3, where the general description of the procedure calls incT a "nominal interval". If we do go forward with a change, I would suggest something other than "incTerror", which suggests incremental terror. 8-) Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 576-5992 847 538-7455 FAX ~-----Original Message----- ~From: Al Morton [mailto:acmorton@att.com] ~Sent: Thursday, December 07, 2000 7:59 PM ~To: ippm@advanced.org ~Subject: Re: FW: draft-ietf-ippm-npmps-03.txt; IPPM-style measurement ~results ~ ~ ~Vilho, Glenn, and all, ~ ~Your new draft deserves at least one (minor) comment. ~ ~Section 4.2.1 gives the Global Metric Parameters, ~one of which is: ~+ periodic packet interval incT, a time duration ~ ~In practice, it may be difficult for measurement sources ~to maintain this periodic sending interval exactly. ~I'd like to suggest adding a new parameter for section ~4.2.2 Metrics Reported at MP(Src) to cover the cases ~where sending times have some variation from the ideal interval. ~Something like: ~+ incTerror, offset from the specified incT ~(could be reported on a per packet basis, or as a range ~at the end of test). ~ ~Note that packetized real-time media streams from users ~may also exhibit variation from strict periodic launch times. ~The point is to capture and report any variation ~so it doesn't get lost. ~ ~Regards, ~Al Morton ~ ~ ~ ~At 03:47 PM 11/22/00 +0200, vilho.raisanen@nokia.com wrote: ~> ~> ~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~> Vilho Räisänen ~> vilho.raisanen@nokia.com ~> Senior research engineer ~> Nokia Research Center, Helsinki, Finland ~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~> ~>Dear IPPM list members, ~> ~>I submitted the latest revised form (-03) of the npmps draft ~>today to internet-drafts@ietf.org; it is also available at ~> ~>http://www-nrc.nokia.com/netperf/npmps-03.txt ~> ~>Moreover, following the advice of IPPM chairs, I made an ~>independent draft submission of VoIP media stream emulation ~>measurement results using metrics using npmps-like metrics. ~>The full draft with figures is available from ~> ~>http://www-nrc.nokia.com/netperf/results.pdf ~> ~>and a version with good old ASCII from ~> ~>http://search.ietf.org/internet-drafts/draft-raisanen-ippm-npm ~ps-results-00. ~>txt ~> ~> Cheers, ~> Vilho ~> ~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~> Vilho Räisänen ~> vilho.raisanen@nokia.com ~> Senior research engineer ~> Nokia Research Center, Helsinki, Finland ~>%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~> ~> ~> ~ From matt@advanced.org Sat Dec 9 12:28:23 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25467 for ; Sat, 9 Dec 2000 12:28:23 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA10720 for ippm-l@advanced.org; Sat, 9 Dec 2000 12:17:24 -0500 (EST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA12304; Sat, 9 Dec 2000 12:17:22 -0500 (EST) Message-Id: <200012091717.MAA12304@betelgeuse.advanced.org> From: Mail Sender To: ipp@pwg.org CC: ippl@awod.com, ippm@advanced.org, ippm-request@advanced.org, ipp-request@pwg.org, ips@ece.cmu.edu Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From matt@advanced.org Mon Dec 11 17:29:46 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20766 for ; Mon, 11 Dec 2000 17:29:46 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA01578 for ippm-l@advanced.org; Mon, 11 Dec 2000 17:20:19 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA01232 for ; Mon, 11 Dec 2000 17:20:18 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBBMJ7501626; Mon, 11 Dec 2000 17:19:08 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA00395; Mon, 11 Dec 2000 17:18:04 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Mon, 11 Dec 2000 17:19:03 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: ippm@advanced.org Cc: "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: on 's model Date: Mon, 11 Dec 2000 17:19:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Stanislav, Benjamin, Matt, I have a question regarding the model chosen in the one way delay measurement protocol. Basically, the model chosen is more complete than I had anticipated (not that this is good or bad). I copy a figure from your draft (below). Your draft covers both the OWDP-Test and OWDP-Control protocols. +----------------+ +------------------+ | Session-Source |--OWDP-Test-->| Session-Receiver | +----------------+ +------------------+ ^ ^ | | | | V | +----------------+<---------------------+ | Server |<------------+ +----------------+ | ^ | | | OWDP-Control OWDP-Control | | V V +----------------+ +-----------------+ | Control-Client | | Retrieve-Client | +----------------+ +-----------------+ An alternative (I think) is to define the OWDP-Test protocol and to rely on the work in the RMONMIB WG to handle the OWDP-Control protocol through SNMP and the current draft MIBs being discussed therein. (see figure below). +----------------+ +------------------+ | Session-Source |--OWDP-Test-->| Session-Receiver | +----------------+ +------------------+ ^ ^ | | SNMP SNMP | | V | +----------------+<---------------------+ |SNMP Server Appl| +----------------+ The drafts I refer to are: At a minimum, I would hope that your draft would be constructed in such a way that it does not exclude the use of the later model where one uses an SNMP application to configure the test source and sinks and the measurements are run using the OWDP-Test protocol without relying on the OWDP-Control protocol. I would much appreciate hearing your thoughts on this later approach. Thanks, Bob ----------------------------------------------------- Robert G. Cole AT&T Labs, Network Design and Performance Analysis Dept. Tel: (410) 939-8732 FAX: (410) 939-8732 Pager: (888) 858-PAGE, pin 127113 email: rgcole@att.com URL: http://chapman.mt.att.com/ 330 Saint Johns St., 2nd Floor Havre de Grace, MD 21078 USA From matt@advanced.org Mon Dec 11 19:30:34 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14829 for ; Mon, 11 Dec 2000 19:30:34 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id TAA02520 for ippm-l@advanced.org; Mon, 11 Dec 2000 19:20:51 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id TAA04755 for ; Mon, 11 Dec 2000 19:20:50 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id BAA07592; Tue, 12 Dec 2000 01:19:56 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id BAA13437; Tue, 12 Dec 2000 01:19:56 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Tue, 12 Dec 2000 01:19:56 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "Cole, Robert G (Bob), ALSVC" cc: ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bob, > An alternative (I think) is to define the OWDP-Test protocol and to > rely on the work in the RMONMIB WG to handle the OWDP-Control protocol > through SNMP and the current draft MIBs being discussed therein. > (see figure below). > > +----------------+ +------------------+ > | Session-Source |--OWDP-Test-->| Session-Receiver | > +----------------+ +------------------+ > ^ ^ > | | > SNMP SNMP > | | > V | > +----------------+<---------------------+ > |SNMP Server Appl| > +----------------+ In this picture, which process is sitting where and what does SNMP-SA exactly tell the SS and SR? My preference would be: SA sits at a control point SS and SR are measurement nodes SA tells SS to send measurement packets starting at t=x with some set of parameters. SA tells SR to expect data from SS starting at t=x SS tells SA what it has sent SR tells SR what it has received. SR combines the 2 to report delays This also works to measure losses (count the number of packets at both ends) and thus connectivity. > At a minimum, I would hope that your draft would be constructed in > such a way that it does not exclude the use of the later model where > one uses an SNMP application to configure the test source and sinks > and the measurements are run using the OWDP-Test protocol without > relying on the OWDP-Control protocol. > > I would much appreciate hearing your thoughts on this later approach. I think that there is a lot of mileage in this idea. The feedback that I get from our customers on our work (http://www.ripe.net/test-traffic), is that they are interested in eventually integrating delay and loss measurements in their existing monitoring systems, and not in a stand-alone device. If we come up with our own protocol, then I fear that the next thing we have to do, is to write a wrapper around the OWDP setup protocol in order to integrate it with SNMP. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Mon Dec 11 20:31:09 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22655 for ; Mon, 11 Dec 2000 20:31:09 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA05989 for ippm-l@advanced.org; Mon, 11 Dec 2000 20:26:28 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA23728 for ; Mon, 11 Dec 2000 20:26:27 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id UAA09965; Mon, 11 Dec 2000 20:26:23 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 307487CA; Mon, 11 Dec 2000 20:26:21 -0500 (EST) Sender: shalunov@internet2.edu To: "Cole, Robert G (Bob), ALSVC" Cc: ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model References: From: stanislav shalunov Date: 11 Dec 2000 20:26:21 -0500 In-Reply-To: Message-ID: <87g0juv39e.fsf@cain.internet2.edu> Lines: 34 X-Mailer: Gnus v5.7/Emacs 20.4 "Cole, Robert G (Bob), ALSVC" writes: > Basically, the model chosen is more complete than I had anticipated > (not that this is good or bad). [...] > An alternative (I think) is to define the OWDP-Test protocol > and to rely on the work in the RMONMIB WG to handle the > OWDP-Control protocol through SNMP and the current draft > MIBs being discussed therein. Robert, draft-ietf-ippm-owdp-00 defines both OWDP-Control and OWDP-Test, but it's not anticipated that all hosts that speak OWDP-Test would necessarily also speak OWDP-Control. Additionally it should be mentioned that our draft doesn't specify protocols used on the unlabeled links of the example setup figure (and doesn't even discuss whether there should be a protocol on this links). The task of Session-Sender and Session-Receiver configuration could be accomplished in a number of different ways. This could be SNMP. This could be sending shell commands over an SSH session. This could be anything. I suppose we should explicitly mention the possibility of using OWDP-Test without OWDP-Control, which will be done in the next draft revision. This is a prose change only. -- Stanislav Shalunov Internet Engineer, Internet2 A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt From matt@advanced.org Mon Dec 11 20:50:44 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24929 for ; Mon, 11 Dec 2000 20:50:44 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA06896 for ippm-l@advanced.org; Mon, 11 Dec 2000 20:47:00 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA05258 for ; Mon, 11 Dec 2000 20:47:00 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id UAA10198; Mon, 11 Dec 2000 20:46:56 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id B6CCB7CA; Mon, 11 Dec 2000 20:46:49 -0500 (EST) Sender: shalunov@internet2.edu To: "Henk Uijterwaal (RIPE-NCC)" Cc: "Cole, Robert G (Bob), ALSVC" , ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model References: From: stanislav shalunov Date: 11 Dec 2000 20:46:49 -0500 In-Reply-To: Message-ID: <87d7eyv2ba.fsf@cain.internet2.edu> Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 "Henk Uijterwaal (RIPE-NCC)" writes: > If we come up with our own protocol, then I fear that the next thing > we have to do, is to write a wrapper around the OWDP setup protocol > in order to integrate it with SNMP. Henk, Since OWDP-Test and OWDP-Control are separable, I don't think there's need to define a wrapper. On the other hand, having OWDP-Control can be helpful in the scenario of network monitoring system using SNMP for a single network. Namely, you could, e.g., have a single host in your domain that speaks OWDP-Control and allow (subject to a policy) use of your network monitoring nodes to send or receive test traffic to/from outside your domain. -- Stanislav Shalunov Internet Engineer, Internet2 "Nuclear war can ruin your whole compile." -- Karl Lehenbauer From matt@advanced.org Mon Dec 11 20:54:14 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25308 for ; Mon, 11 Dec 2000 20:54:13 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA05420 for ippm-l@advanced.org; Mon, 11 Dec 2000 20:50:38 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA06898 for ; Mon, 11 Dec 2000 20:50:37 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id CAA15728; Tue, 12 Dec 2000 02:49:46 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id CAA17356; Tue, 12 Dec 2000 02:49:46 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Tue, 12 Dec 2000 02:49:46 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: "Cole, Robert G (Bob), ALSVC" , ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model In-Reply-To: <87g0juv39e.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Stanislav, > > Basically, the model chosen is more complete than I had anticipated > > (not that this is good or bad). > [...] > > An alternative (I think) is to define the OWDP-Test protocol > > and to rely on the work in the RMONMIB WG to handle the > > OWDP-Control protocol through SNMP and the current draft > > MIBs being discussed therein. > draft-ietf-ippm-owdp-00 defines both OWDP-Control and OWDP-Test, but > it's not anticipated that all hosts that speak OWDP-Test would > necessarily also speak OWDP-Control. > > Additionally it should be mentioned that our draft doesn't specify > protocols used on the unlabeled links of the example setup figure (and > doesn't even discuss whether there should be a protocol on this links). > The task of Session-Sender and Session-Receiver configuration could be > accomplished in a number of different ways. > > This could be SNMP. This could be sending shell commands over an SSH > session. This could be anything. If it can be anything, then I believe the draft should simply say "how the sessions are configured, is not discussed in this draft" instead of putting 1 specific solution in the draft with a footnote that one can use something else as well. Including a specific solution, IMHO, gives the mistaken impression that this is somehow preferred over other solutions. If you want to make OWDP-control a protocol, put it another draft. Henk ps. Ben, Matt, Stanislav: are you here and can we meet to discuss this draft by VOS sometime tomorrow? ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Mon Dec 11 21:03:44 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26395 for ; Mon, 11 Dec 2000 21:03:44 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id VAA01457 for ippm-l@advanced.org; Mon, 11 Dec 2000 21:00:33 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id VAA06311 for ; Mon, 11 Dec 2000 21:00:32 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id CAA16630; Tue, 12 Dec 2000 02:59:33 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id CAA18209; Tue, 12 Dec 2000 02:59:32 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Tue, 12 Dec 2000 02:59:32 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: stanislav shalunov cc: "Cole, Robert G (Bob), ALSVC" , ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model In-Reply-To: <87d7eyv2ba.fsf@cain.internet2.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Stanislav, > > If we come up with our own protocol, then I fear that the next thing > > we have to do, is to write a wrapper around the OWDP setup protocol > > in order to integrate it with SNMP. > Since OWDP-Test and OWDP-Control are separable, I don't think there's > need to define a wrapper. If your measurement device uses OWDP-control and mine SNMP, then in order to set up a measurement session between the two, one will have to translate OWDP to SNMP (or the other way around). > On the other hand, having OWDP-Control can be helpful in the scenario > of network monitoring system using SNMP for a single network. > Namely, you could, e.g., have a single host in your domain that speaks > OWDP-Control and allow (subject to a policy) use of your network > monitoring nodes to send or receive test traffic to/from outside your > domain. I fail to see why we need an extra protocol for this: with SNMP, one can tell this host just as well to start sending/receiving test-traffic from/to other sites. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Tue Dec 12 01:40:36 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03323 for ; Tue, 12 Dec 2000 01:40:36 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id BAA08294 for ippm-l@advanced.org; Tue, 12 Dec 2000 01:32:51 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id BAA00622 for ; Tue, 12 Dec 2000 01:32:49 -0500 (EST) Received: from hogpa.mt.att.com ([135.16.74.2]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id eBC6WIY29754; Tue, 12 Dec 2000 01:32:18 -0500 (EST) Received: from acmortonw by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id BAA15215; Tue, 12 Dec 2000 01:32:16 -0500 Message-Id: <3.0.32.20001212013213.0070d6c0@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 12 Dec 2000 01:32:16 -0500 To: "Geib, Ruediger" , ippm@advanced.org From: Al Morton Subject: RE: Comments on draft-ietf-ippm-ipdv.05 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 10:16 AM 11/15/00 +0100, Geib, Ruediger wrote: >Hi IPPMers (and to spare [5] from being deleted ;-) > >As "unknown reference" of above draft I'd like to point out my view on Mike's comments: > >Finally I'd like to ask Mike to provide access to the following references quoted by him: >Y.1540 and Y.1541. >Distributiuon of these documents to the IPPM WG was promised during the last meeting. I however never saw any information on the list or on the archive. > > Ruediger's request for a copy of Draft ITU-T Rec Y.1541 can't be satisfied by the ITU directly, but since T1A1 discusses this as well, the 11/2000 version is posted as below: ftp://ftp.t1.org/pub//t1a1/t1a1.3/0a130560.doc ftp://ftp.t1.org/pub//t1a1/t1a1.3/0a130560.ps Note that draft Y.1541 is very much a work-in-progress, especially some of the values in Table 1, and the parameter definition for delay variation. I'm sure that a near-final version of I.380 -> Y.1540 exists on T1A1's site, and when I find it I'll post that URL, too. Al From matt@advanced.org Tue Dec 12 11:05:37 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12544 for ; Tue, 12 Dec 2000 11:05:37 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA23244 for ippm-l@advanced.org; Tue, 12 Dec 2000 11:01:40 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA23056 for ; Tue, 12 Dec 2000 10:58:59 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBCFvi520387; Tue, 12 Dec 2000 10:57:44 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA12255; Tue, 12 Dec 2000 10:56:41 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 12 Dec 2000 10:57:37 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: stanislav shalunov Cc: ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: RE: on 's model Date: Tue, 12 Dec 2000 10:57:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Stanislav, Thanks. I agree with what you are saying. I would just like to see these options spelled out in an introductory section of the draft. I would then also like to make sure that the source and sink contrl tables in the kalbfleisch-sspmmib draft align with the control requirements of the OWDP-test protocol as spelled out in your draft. Thanks, Bob > -----Original Message----- > From: stanislav shalunov [SMTP:shalunov@internet2.edu] > Sent: Monday, December 11, 2000 8:26 PM > To: Cole, Robert G (Bob), ALSVC > Cc: ippm@advanced.org; Carl W. Kalbfleisch; Dan Romascanu; Steve > Waldbusser; Russell Dietz > Subject: Re: on 's model > > "Cole, Robert G (Bob), ALSVC" writes: > > > Basically, the model chosen is more complete than I had anticipated > > (not that this is good or bad). > [...] > > An alternative (I think) is to define the OWDP-Test protocol > > and to rely on the work in the RMONMIB WG to handle the > > OWDP-Control protocol through SNMP and the current draft > > MIBs being discussed therein. > > Robert, > > draft-ietf-ippm-owdp-00 defines both OWDP-Control and OWDP-Test, but > it's not anticipated that all hosts that speak OWDP-Test would > necessarily also speak OWDP-Control. > > Additionally it should be mentioned that our draft doesn't specify > protocols used on the unlabeled links of the example setup figure (and > doesn't even discuss whether there should be a protocol on this links). > The task of Session-Sender and Session-Receiver configuration could be > accomplished in a number of different ways. > > This could be SNMP. This could be sending shell commands over an SSH > session. This could be anything. > > I suppose we should explicitly mention the possibility of using > OWDP-Test without OWDP-Control, which will be done in the next draft > revision. This is a prose change only. > > -- > Stanislav Shalunov Internet Engineer, Internet2 > > A large number of installed systems work by fiat. That is, they work > by being declared to work. -- Anatol Holt From matt@advanced.org Tue Dec 12 11:06:03 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12607 for ; Tue, 12 Dec 2000 11:06:02 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA20168 for ippm-l@advanced.org; Tue, 12 Dec 2000 10:56:05 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA22577 for ; Tue, 12 Dec 2000 10:56:04 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBCFswY15588; Tue, 12 Dec 2000 10:54:58 -0500 (EST) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA15023; Tue, 12 Dec 2000 10:54:09 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 12 Dec 2000 10:54:46 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: "Henk Uijterwaal (RIPE-NCC)" Cc: ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: RE: on 's model Date: Tue, 12 Dec 2000 10:54:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Henk, see my responses below. thx, Bob > -----Original Message----- > From: Henk Uijterwaal (RIPE-NCC) [SMTP:henk@ripe.net] > Sent: Monday, December 11, 2000 7:20 PM > To: Cole, Robert G (Bob), ALSVC > Cc: ippm@advanced.org; Carl W. Kalbfleisch; Dan Romascanu; Steve > Waldbusser; Russell Dietz > Subject: Re: on 's model > > Bob, > > > > An alternative (I think) is to define the OWDP-Test protocol and to > > rely on the work in the RMONMIB WG to handle the OWDP-Control protocol > > through SNMP and the current draft MIBs being discussed therein. > > (see figure below). > > > > +----------------+ +------------------+ > > | Session-Source |--OWDP-Test-->| Session-Receiver | > > +----------------+ +------------------+ > > ^ ^ > > | | > > SNMP SNMP > > | | > > V | > > +----------------+<---------------------+ > > |SNMP Server Appl| > > +----------------+ > > In this picture, which process is sitting where and what does SNMP-SA > exactly tell the SS and SR? > > My preference would be: > > SA sits at a control point > SS and SR are measurement nodes > > SA tells SS to send measurement packets starting at t=x with some set > of parameters. > SA tells SR to expect data from SS starting at t=x > > SS tells SA what it has sent > SR tells SR what it has received. > > SR combines the 2 to report delays [Cole, Robert G (Bob), ALSVC] Exactly ! If you look at the Kalbfleisch sspmmib draft, it contains two contrl table; one for source and one for sink. The sink table tells the sink what to expect and when. Also, now that you all have a draft containing the OWDP-test protocol, we can align the source and sink table contrl info with your test protocol requirements. > This also works to measure losses (count the number of packets at both > ends) and thus connectivity. > > > At a minimum, I would hope that your draft would be constructed in > > such a way that it does not exclude the use of the later model where > > one uses an SNMP application to configure the test source and sinks > > and the measurements are run using the OWDP-Test protocol without > > relying on the OWDP-Control protocol. > > > > I would much appreciate hearing your thoughts on this later approach. > > I think that there is a lot of mileage in this idea. The feedback that I > get from our customers on our work (http://www.ripe.net/test-traffic), is > that they are interested in eventually integrating delay and loss > measurements in their existing monitoring systems, and not in a > stand-alone device. If we come up with our own protocol, then I fear that > the next thing we have to do, is to write a wrapper around the OWDP setup > protocol in order to integrate it with SNMP. [Cole, Robert G (Bob), ALSVC] I don't think we are suggesting any sort of wrapper, but i guess I do not fully understand your concern. I think the control aspects of the setup protocol are to be contained in the sspmmib source and sink contrl tables on the respective measurement nodes. > Henk > > -------------------------------------------------------------------------- > ---- > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.535-4414, Fax -4445 > 1016 AB Amsterdam Home: +31.20.4195305 > The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------- > ---- > > A man can take a train and never reach his destination. > (Kerouac, well before > RFC2780). From matt@advanced.org Tue Dec 12 11:53:11 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21302 for ; Tue, 12 Dec 2000 11:53:11 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id LAA24633 for ippm-l@advanced.org; Tue, 12 Dec 2000 11:43:32 -0500 (EST) Received: from lon-s04.thguk.com (www.thguk.com [194.74.216.9]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id LAA23541 for ; Tue, 12 Dec 2000 11:43:31 -0500 (EST) Received: by mailhost.thguk.com with Internet Mail Service (5.5.2448.0) id ; Tue, 12 Dec 2000 16:41:36 -0000 Message-ID: From: Max Edwards To: "'ippm@advanced.org'" Subject: eMetrics Conference Date: Tue, 12 Dec 2000 16:41:34 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Dear Sir/Madam, I am producing the UK's first conference on eMetrics which will deal with monitoring your eBusiness performance. This will include topics such as aligning IT with corporate eBusiness goals; metrics flexibility for evolving eBusiness systems; implementing metrics measurement tools for smooth eBusiness transition and maximising profitability of IT networks and applications. I am doing some pre-production research and am interested in finding more information about the subject area of eBusiness and identifying gurus/speakers in this area. Would you be interested in an event such as this or might you be able to assist me in my enquiry? Thank you for your time and I look forward to hearing from you. Kind regards, Max Edwards > Business Strategy Division marcus evans 4 Cavendish Square London W1M 0BX Tel: (020) 7499 0900 Fax: (020) 7629 3533 email: maxe@marcusevansuk.com > marcus evans is dedicated to the provision of strategic business > information for all its customers by understanding what they need, and > delivering it through premium products and services in the format best > suited to each customer. To find out more about how you and your > organisation can access the very best information, please visit us at: > www.marcusevans.com > > > > From matt@advanced.org Tue Dec 12 18:06:12 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00977 for ; Tue, 12 Dec 2000 18:06:12 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA04881 for ippm-l@advanced.org; Tue, 12 Dec 2000 17:57:34 -0500 (EST) Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA03892 for ; Tue, 12 Dec 2000 17:57:33 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBCMuOY28675; Tue, 12 Dec 2000 17:56:24 -0500 (EST) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id RAA13454; Tue, 12 Dec 2000 17:55:34 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 12 Dec 2000 17:56:23 -0500 Message-ID: From: "Cole, Robert G (Bob), ALSVC" To: "Henk Uijterwaal (RIPE-NCC)" , stanislav shalunov Cc: ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: RE: on 's model Date: Tue, 12 Dec 2000 17:56:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Henk, > -----Original Message----- > From: Henk Uijterwaal (RIPE-NCC) [SMTP:henk@ripe.net] > Sent: Monday, December 11, 2000 9:00 PM > To: stanislav shalunov > Cc: Cole, Robert G (Bob), ALSVC; ippm@advanced.org; Carl W. Kalbfleisch; > Dan Romascanu; Steve Waldbusser; Russell Dietz > Subject: Re: on 's model > > Stanislav, > > > I fail to see why we need an extra protocol for this: with SNMP, one can > tell this host just as well to start sending/receiving test-traffic > from/to other sites. [Cole, Robert G (Bob), ALSVC] Will there be cases where the snmp mgmr and the OWDP source are within the same AS and the sink is outside, in which case it may be necessary to have a control protocol between the source and sink to configure the sink? Bob > Henk > > -------------------------------------------------------------------------- > ---- > Henk Uijterwaal Email: henk.uijterwaal@ripe.net > RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk > Singel 258 Phone: +31.20.535-4414, Fax -4445 > 1016 AB Amsterdam Home: +31.20.4195305 > The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------------------- > ---- > > A man can take a train and never reach his destination. > (Kerouac, well before > RFC2780). > From matt@advanced.org Tue Dec 12 23:14:37 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27937 for ; Tue, 12 Dec 2000 23:14:36 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id XAA28385 for ippm-l@advanced.org; Tue, 12 Dec 2000 23:07:00 -0500 (EST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id XAA01352; Tue, 12 Dec 2000 23:06:58 -0500 (EST) From: vilho.raisanen@nokia.com Received: from esvir08nok.nokia.com (esvir08nok.nokia.com [131.228.20.80]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id eBD473K28586; Wed, 13 Dec 2000 06:07:03 +0200 (EET) Received: from esebh01nok.ntc.nokia.com (unverified) by esvir08nok.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 13 Dec 2000 06:06:56 +0200 Received: by esebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 13 Dec 2000 06:06:56 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10610A4A6@eseis04nok> To: ippm@advanced.org Cc: matt@advanced.org, kaeo@merike.com Subject: npmps-04 Date: Wed, 13 Dec 2000 06:06:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C064BA.208F49D0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C064BA.208F49D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, please find attached my (intended) slides, the results document, as = well as the v-04 of the npmps draft. Lacking my slides, I forgot the IP version = from the list of additions to the -03 version of the metric. Moreover, I had = read Glenn's answer to Al sloppily, which I apologize. I now realize that = Glenn was not in favour of including error of incT into the actual metric. After some thought, I came to the conclusion that I support Glenn's = proposal of calling incT a nominal duration of the inter-packet interval and mentioning the possiblility of error in discussion later. If process scheduling or some other reason causes marked variations in incT, this should be treated as a deviation from the norm rather than a part of a normal measurement arrangement. The only changes in v-04 to v-03 are as follows: - changed definition of incT at p. 8 into + incT, nominal duration of inter-packet interval - added text on incT error into Sec. 4.6: + Error due to variation of incT - For clarity, I added a mention of packet loss as the second sentence = to to Sec 4.4, which now reads The sample metric thus defined is intended to probe the delays and the delay variation as experienced by multimedia streams of an application. Due to the definition of the metric, also packet = loss status of packets is recorded. The delay is assumed to be measured = at transport layer level. Since a range of packet sizes and nominal=20 interval between packets is used, the method probes only a specific=20 time scale of network QoS variations. For those intested in a computer repair story with a human interest = tint, I'll attach one at the end of the message. For the rest, just read the = docs & the slides and you'll do fine. BR, Vilho %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=20 Vilho R=E4is=E4nen =20 vilho.raisanen@nokia.com =20 Senior research engineer =20 Nokia Research Center, Helsinki, Finland=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% * * * end of real business * * * ~~ How to boot up a stubborn computer - a small tale of fatherly wisdom = ~~ At boot, my laptop reported that it was the modem driver that caused = the crash. From previous experience, I knew that the order in which device drivers are loaded sometimes makes a difference, at least in some = operating systems. Armed with this piece of what I thought of as profound = knowledge, I booted NT with and without my PCMCIA NIC, without CD-ROM drive and experimenting with all combinations. I even tried the VGA mode. To no = avail. At this point I remembered my father's tale of a dysfunctional old = radio. He told me having opened the casing, and - lacking training in electronics = - could not do very much more. So he just blew some dust off the valves = and closed it again. Surprise, surprise: now it worked. Lacking better ideas, I did just the same: I located the modem, opened = a tiny cover and blew some imaginary dust off the printed board. = Reassembly, boot - succcess. ------_=_NextPart_000_01C064BA.208F49D0 Content-Type: application/vnd.ms-powerpoint; name="npmps-res.ppt" Content-Disposition: attachment; filename="npmps-res.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAA EAAAHAAAAAEAAAD+////AAAAAAEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////9S AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAP//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAADQjO8FtGTA AQMAAADAFQAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB/////wUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAGACAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUA bQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH/////BAAAAP////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAACx0AAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAAC AAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAADEDwAAAAAAAAIA AAD9/////v///wQAAAAUAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAD+////FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAAB0AAAD+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////BQBE AG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAPAAAA EAAAADgAAgD///////////////8VAAAAFgAAABcAAAAYAAAAGQAAAAAAAAAAAAAAAAAAAAAAAABK AAAA/AIAACAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAKAAAACkAAAAqAAAAKwAAACwA AAAtAAAALgAAAC8AAAAwAAAAGgACAP///////////////zUAAAA2AAAANwAAADgAAAA5AAAAAAAA AAAAAAAAAAAAAAAAAFYAAAAoAAAAQAAAAEEAAAD+////QwAAAEQAAABFAAAARgAAAEcAAABIAAAA SQAAAEoAAABLAAAATAAAAE0AAAD+/////v////////8AAAAA//////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////wAAAAD///////// //////////////////////////////////////////////////////////////////////9wIRvw WAIAAAsD0FmYmhQkDB6FdPyoLnzsV/APbc6WdCbv0Neh7WRaegQAAM72//8zCwAAbQQAAG4NAAAh pzAAivcHABYCAAAA/nicpZM9a1NhGIbv5z3ntDEahRQtgSKtdGibVE3aEjtkcFD/gPQXiHSsdPCr WttFQUFwEC0OFgo2iR9ZdLCCbmbRqSCipr9AcHASIV7vaRJFaJccuHjf5+u+nyQnpj1SUHJSqLr8 E0JgCUWce53P+Ns+Z7Jda9u3qvrDv1Xf32OmXs7fPjPfbGXHTd5Zv1wUuzabTR1pVawzd5hzOEip oDI3j9MMbGhRb7QETt9jynoABeVgLO7fVlfnaau7zjbes71NEJ8/2Kqz69y/u/6/2f54s0gjzkFZ P83j4rjts6Py/G7K6Vi5V8so1WHWndUmDrdghPty1w7t3dOBg7IazuPiuDvlQc4TkeO7D3U+uKMZ 1AfgEsob0B+W9Y34AzVfvxzM6jWsBLn43p17veVe0rCc5WCYt3VQoQ0osowSdlBJSytlB9RnSR3i Tc5Yj4YsVBbXIhpn0L0AK1AhfkX+HfX39H1kZpPZT2h8RusLml/RbuDRwGsLzy07BdeJb8Jt6nfp u0f/feYeMv8InVX01vTWnugl703ZKvhVNQenoUicJT9EPUNfH/0p5pLMJ9CJ0AvRDdB3+Dj8/OfN 20W4ooItaILclC2idUPTcNKW9BjWYJ24Qu0pPc/tml7YVdWYqzFfs3MwCXnyx6iP65llVYV1G9Oq jaI1qhL3aSiSn8J7wo7iexz/PEzGu+z0awbx//EP0FeWigAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAA lA8AABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMAAAAAEAAAAzAAAAAUAAADgAAAABgAAAOwAAAAH AAAA+AAAAAgAAAA8AQAACQAAAFABAAASAAAAXAEAAAoAAACAAQAACwAAAIwBAAAMAAAAmAEAAA0A AACkAQAADgAAALABAAAPAAAAuAEAABEAAADAAQAAAgAAAOQEAAAeAAAAIAAAAG5wbXBzLXN0eWxl IG1lYXN1cmVtZW50IHJlc3VsdHMAHgAAAAEAAAAAcG1wHgAAAAkAAAB2cmFpc2FuZQBsZSAeAAAA AQAAAAByYWkeAAAAAQAAAAByYWkeAAAAOgAAAEM6XFVTRVJTXFVTRVJJTkZcTVNPRkZJQ0VcVEVN UExBVEVcQmxhbmsgUHJlc2VudGF0aW9uLnBvdABvaR4AAAAJAAAAdnJhaXNhbmUAVVNFDwDoA0wM AAABAOkDKAAAAGAYAADgEAAAjxAAAOgXAAAFAAAACgAAAAIAAAADAAAAAQACAAAAAAEPAPIDaAIA AC8AyA/qAAAAMADSDwQAAAACAAAAAAC6DygAAAAYIBwgCP8UMDv/W/8IMAowDDAOMBAw5f8E/yQA KABbAFwAewBi/+H/EAC6D6YAAAABMAIwDP8O//swGv8b/x//Af+bMJww/TD+MJ0wnjAFMPwwGSAd IAn/FTA9/13/CTALMA0wDzARMLAAMCAyIDMgAyHg/wX/QTBDMEUwRzBJMGMwgzCFMIcwjjChMKMw pTCnMKkwwzDjMOUw5zDuMPUw9jAhACUAKQAsAC4AOgA7AD8AXQB9AGH/Y/9k/2X/Z/9o/2n/av9r /2z/bf9u/2//cP+e/5//DwDVB5gAAAAAALcPRAAAAEEAcgBpAGEAbAAAAC7UAzDMsxIAQgHmAAgA AAAUoOYApLcSAKS3EgCwsxIA+NMDMNSzEgAIAAAA1LMSAH7UAzAAAAYiEAC3D0QAAABSAG8AdABp AHMAIABTAGEAbgBzACAAUwBlAHIAaQBmACAAZgBvAHIAIABOAG8AawBpAGEAAAAAANSzEgB+1AMw AAAGAgAApA8GAAAAAAABAAEAAAClDxIAAAAAAJI4AAAAACIgAAABAFoAMgAAAKsPHgAAAP8fAAAF AOABAAAAAAAAaAFoAdAC0AI4BDgEoAWgBQAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8A AAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAA BQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEMAUAAA8A APAoBQAAAAAG8CABAAAEiAAAIwAAAA8AAAAFAAAAAQAAACMAAAACAAAABAAAAAMAAAACAAAAAAAA AAQAAAAAAAAABwAAAAAAAAAJAAAAAAAAAAgAAAAAAAAABwAAAAAAAAAEAAAAAAAAACEAAAAAAAAA GwAAAAAAAAAHAAAAAAAAAAwAAAAAAAAAEgAAAAAAAAAIAAAAAAAAACUAAAAAAAAAGAAAAAAAAAB3 AAAAAAAAAAQAAAAEAAAAJQAAAAAAAAAGAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAJAAAAAAAAAAkA AAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAACQAAAAAAAAAJAAAAAAAAAAkAAAAAAAAAAgAA AAAAAAACAAAABQAAAAQAAABPAAHwsAAAAAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAIYAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAhgAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAACGADIAB/AkAAAAAwTsV/AP bc6WdCbv0Neh7WRa/wBgAgAAAQAAAAAAAAAAAIYAAwgL8AADAACBADBlAQCCAJiyAACDADBlAQCE AJiyAACFAAIAAACHAAEAAACIAAAAAACJAAAAAAC/AAIADwAMAfQAABANAQAAACAOAQAAACCAAQAA AACBAQQAAAiCAQAAAQCDAf///wCEAQAAAQCFAQAAACCGQQAAAACHwQAAAACIAQAAAACJAQAAAACK AQAAAACLAQAAAACMAQAAAACNAQAAAACOAQAAAACPAQAAAACQAQAAAACRAQAAAACSAQAAAACTAQAA AACUAQAAAACVAQAAAACWAQAAAACXwQAAAACYAQAAAACZAQAAAACaAQAAAACbAQAAAACcAQMAAEC/ ARwAHgDAAQEAAAjBAQAAAQDCAf///wDDAQAAACDEAQAAAADFQQAAAADGwQAAAADHAQAAAADIAQAA AADJAQAAAADKAQAAAADLAc4YAADMAQAACADNAQAAAADOAQAAAADPwQAAAADXAQIAAAD/AQ4ADgAA AgAAAAABAgIAAAgCAsvLywADAgAAACAEAgAAAQAFAjhjAAAGAjhjAAAHAgAAAAAIAgAAAAAJAgAA AQAKAgAAAAALAgAAAAAMAgAAAQANAgAAAAAOAgAAAAAPAgABAAAQAgAAAAARAgAAAAA/AgAAAwCA AgAAAACBAgAAAQCCAgUAAACDApwxAACEAgAAAACFAvD5BgCGAgAAAACHAvcAABCIAgAAACC/AgEA DwDAAgAAAADBAgAAAADCAmQAAADDAgAAAADEAgAAAADFAgAAAADGAgAAAADHAgAAAADIAgAAAADJ AgAAAADKAjB1AADLAtASEwDMAjDt7P/NAkBUiQDOAgCAAADPAgCA///QAgAAef/RAjIAAADSAiBO AADTAlDDAADUAgAAAADVAhAnAADWAnCUAADXArA8///YAgAAAADZAhAnAADaAnCUAAD/AhYAHwAE AwEAAABBA6gpAQBCAwAAAABDAwMAAABEA3y+AQBFAwAAAAB/AwAADwCEA3y+AQCFAwAAAACGA3y+ AQCHAwAAAACAABrxIAAAAMzs/wBnZ2cAqampAPz+uQAGPegAosH+APr9AADA/vkAQAAe8RAAAACi wf4A/////wIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAQAAAAEAAAAAAAAAAAAAIAAAAAADwDQB88A AAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAA TAAAAGQAAABMAAAAZAAAAOCzEgB+1AMw2LMSAAgAAAAQFwAAdA0AALr9//+y////AQAAAHAA+wMI AAAAAAAAAHAIAABwAPsDCAAAAAEAAAAwDAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQA AABYFcABAAAAAKS3EgABAAAAEBcAABAOAAAAAAAAAAAAAAAA//8/ANkPDAAAAAAA2g8EAAAAAAAl AA8A8A/9AgAAAADzAxQAAAAWAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8fAAAA bnBtcHMtc3R5bGUgbWVhc3VyZW1lbnQgcmVzdWx0cwAAqg8KAAAAIAAAAAEAAAAAABAAnw8EAAAA BQAAAAAAqA8mAAAAVmlsaG8gUuRpc+RuZW4NTm9raWENSGVsc2lua2ksIEZpbmxhbmQAAKoPCgAA ACcAAAABAAAAAAAAAPMDFAAAAAUAAAAAAAAAAgAAAAABAAAAAAAAAACfDwQAAAAAAAAAAACoDx8A AABucG1wcy1zdHlsZSBtZWFzdXJlbWVudCByZXN1bHRzAACqDwoAAAAgAAAAAQAAAAAAEACfDwQA AAABAAAAAACoD4cBAABFeGFtcGxlIGFwcGxpY2F0aW9uIG9mIG5wbXBzIG1ldHJpY3MgY2FsbGVk IGZvciBpbiB0aGUgcHJldmlvdXMgbWVldGluZy4NSW4gdGhlIGRyYWZ0OiByZXN1bHRzIGZyb20g UlQgbWVkaWEgc3RyZWFtIGVtdWxhdGlvbiBtZWFzdXJlbWVudCBwcmVzZW50ZWQgdXNpbmcgbnBt cHMtbGlrZSBtZXRyaWNzLg1FeGFtcGxlcyBvZiBkZXJpdmF0aXZlIG1ldHJpY3MgKG5vdCBpbnRl bmRlZCB0byBiZSBjb3ZlcmVkIGJ5IG5wbXBzKSBwcm92aWRlZDogZGVsYXkgZGlzdHJpYnV0aW9u LCBtYXBwaW5nIHRvIGxpc3RlbmluZyB0ZXN0IG1hdGVyaWFsLg1GdWxsIHRleHQgKHcvZmlncykg YXZhaWxhYmxlIGluIFBERiBmb3JtYXQgZnJvbSBodHRwOi8vd3d3LW5yYy5ub2tpYS5jb20vbmV0 cGVyZi8uAAChDzoAAACuAAAAAAAAAAAA2gAAAAEAAQAAAA0ArgAAAAAAAAC3AAAAAAAAACAAAAAA AAQABj3o/gMAAAAAAAAAAACqDwoAAACIAQAAAQAAAAAAAQABBFAAAAAAAAAB////fwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAASAAAA6gMAAAAADwD4A0YJAAACAO8DGAAAAAEAAAABAgcJCAAAAAAAAAAAAAAAAAAAAGAA 8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAAAA/wD///8AAAAA AP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAAM8wA /8xmAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq6gBgAPAHIAAAAP///wAA AAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8AAAAAAICAgAAAAAAAwMDAAABm /wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wAzADMALKysgAAAKMPPgAA AAEA//0/AAAAIiAAAGQAAAAAAAEAWgAAAAAAAAAAAOABAAAAAAIAAAD//+8AAQABAP///////yQA AAAAAQAAEACjD44AAAAFAP/9PwAFACIgAABkAAAAAAQAAFoAKAAAALEAAADgAQAAAAACAAAA///v AAAAAQD///////8YAAAAAAEAAGkFAAAMAH0AAAAABqQBKQEAAAAAbAUAAAAAZAAAAAAASgNYAgAA AwAAABIAgTUAAAEAEyBkABQAcQTCAwAAAgAUAIAFAAC7AKAF7wQAAAAAIACjD24AAAAFAP/9PwAA ACIgAABkAAAAAAAAAFoAKAAAAAAAAADgAQAAAAACAAAA///vAAAAAAD///////8KAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9OAAAABQAA AAEJAAAEAAEAAAAAAAAAAQAACQAAAQAgAQAAAAACAAAJAAABAEACAAAAAAMAAQkAAAAAAQBgAwAA AAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPQgAAAAUAAAAAAAAAAAAC ABQAAQAAAQAAKQEAAAIAFAACAAABAABYAgAAAgAQAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAA ow9CAAAABQAAAAAAAAAAAAIAEgABAAABAAApAQAAAgASAAIAAAEAAFgCAAACAA4AAwAAAAAAAAAC ABAABAAAAAAAAAACABAADwAMBFoFAAAPAALwUgUAABAACPAIAAAABQAAACIEAAAQABjxBAAAAAEA AAAPAAPw5AQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAA AA8ABPAIAQAAEgAK8AgAAAACBAAAAAoAAAMBC/BgAAAAfwABAAEAgAAUeL4BgQB4YQEAggCirQAA gwB4YQEAhACirQAAhwABAAAAvwAQAB8AgQEAAAAIgwEAAAAIvwEBABEAwAEBAAAIywGcMQAA/wEB AAkAAQICAAAIPwIAAAIAAAAQ8AgAAACQACABLBdAAg8AEfAQAAAAAADDCwgAAAAAAAAAAQDmAA8A DfBgAAAAAACfDwQAAAAAAAAAAACoDywAAABUaXRsZTogMzYgcHQgUm90aXMgU2FucyBTZXJpZiBm b3IgTm9raWEgQk9MRAAAog8GAAAALQAAAAAAAACqDwoAAAAtAAAAAQAAAAAADwAE8I4BAAASAArw CAAAAAcEAAAACgAA8wAL8FoAAAB/AAEAAQCAADR5vgGBAHhhAQCCAKKtAACDAHhhAQCEAKKtAAC/ ABAAHwCBAQAAAAiDAQAAAAi/AQEAEQDAAQEAAAjLAZwxAAD/AQEACQABAgIAAAg/AgAAAgAAABDw CAAAANACAwV9FLAODwAR8BAAAAAAAMMLCAAAAAEAAAACAOYADwAN8OwAAAAAAJ8PBAAAAAEAAAAA AKgPuAAAAE5va2lhIFBvd2VyUG9pbnQgOTlUZW1wbGF0ZSAtIEp1bHkgMTk5OQsoUm90aXMgU2Fu cyBTZXJpZiBmb3IgTm9raWEgMjQgcHQpIA0NDQ0NQ0hBTkdFIFRIRSBDT0RFID0gRmlsZSBuYW1l CyhSb3RpcyBTYW5zIFNlcmlmIGZvciBOb2tpYSA4IHB0KSALNyBjaGFyYWN0ZXJzICsgYSAoYW5p bWF0ZWQpIHMgKHN0aWxsKS5QUFQAAKIPBgAAALkAAAAAAAAAqg8KAAAAuQAAAAEAAAAAAA8ABPCq AAAAsgQK8AgAAAAcBAAAAAoAAEMAC/CCAAAAfwCAAIAABEEEAAAABcFqAAAABgEBAAAASAA6AFwA TABvAGcAbwBzACAALQA5ADcALQA5ADgAXABMAG8AZwBvAHMAXwBQAGkAeABlAGwAUAByAGUAcwBz AFwAVwBNAEYAXwBjAGQAcgBcAG4AMQBfAEMATQBZAEsALgB3AG0AZgAAAAAAEPAIAAAAABCWFKAX fxAPAATwVAEAABIACvAIAAAAHQQAAAAKAADjAAvwVAAAAIAA9HC+AYEAeGEBAIIAoq0AAIMAeGEB AIQAoq0AAL8AEgAfAIEBAAAACIMBAAAACL8BAAAQAMABAQAACMsBnDEAAP8BAAAIAAECAgAACD8C AAACAAAAEPAIAAAAMxCQAMAMsBAPAA3w0AAAAAAAnw8EAAAABAAAAAAAqA8uAAAAKiAgICAgICCp IE5PS0lBIDE5OTkgICBGSUxFTkFNcy5QUFQvIERBVEUgLyBOTgAAoQ8yAAAALwAAAAAAABAAAFoA CQAAAAAAAwABAAgAAQAAAAIAAwACAAEACAAlAAAAAAADAAEACAAAANgPBAAAAAAAAAAAAKoPIgAA AAEAAAAAAAAAFgAAAAAAAAAIAAAAAQAAAAMAEAAAAAAAAAAAAKYPFgAAAPEeAAD+AGgBaAHQAtAC OAQ4BKAFoAUPAATwQgAAABIACvAIAAAAAQQAAAAMAABzAAvwKgAAAIEBAAAACJMBHkCXAJQB3r1o AL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACRkZEAAAAAAGGP/QAArgAA /AEoAM7OzgAgALoPLAAAAEIAbABhAG4AawAgAFAAcgBlAHMAZQBuAHQAYQB0AGkAbwBuAC4AcABv AHQADwDwA4MCAAABAPEDCAAAAAAAAIAAAAwwDwAMBEMCAAAPAALwOwIAACAACPAIAAAAAwAAAAMI AAAPAAPw2QEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAA AA8ABPApAQAAEgAK8AgAAAACCAAAAAoAAPMAC/BaAAAAfwABAAEAgABUcb4BgQBmXQEAggCiqwAA gwBmXQEAhACiqwAAvwAQAB8AgQEAAAAIgwEAAAAIvwEBABEAwAEBAAAIywGcMQAA/wEBAAkAAQIC AAAIPwIAAAIAAAAQ8AgAAABlCzUCWg40Fg8AEfAQAAAAAADDCwgAAAADAAAABgLmAA8ADfCHAAAA AACfDwQAAAACAAAAAACoDzsAAABCb2R5IFRleHQNU2Vjb25kIExldmVsDVRoaXJkIExldmVsDUZv dXJ0aCBMZXZlbA1GaWZ0aCBMZXZlbAAAog8eAAAACgAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA AAQAAACqDwoAAAA8AAAAAQAAAAAADwAE8HAAAAASAArwCAAAAAMIAAAACgAAgwAL8DAAAAB/AAQA BACHAAEAAAB/AQAAAQC/AQEAEQDAAQEAAAjLAZwxAAD/AQgACQA/AgEAAwAAABDwCAAAABQCOwJU DnQKDwAR8BAAAAAAAMMLCAAAAAIAAAAFAOYADwAE8EIAAAASAArwCAAAAAEIAAAADAAAcwAL8CoA AACBAQAAAAiTAZPHZgCUAfpXlAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAA AAAAkZGRAAAAAABhj/0AAK4AAPwBKADOzs4ADwDJD8oAAAAPAAwEmgAAAA8AAvCSAAAAMAAI8AgA AAABAAAAAQwAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAWAACAArwCAAA AAAMAAAFAAAADwAE8EIAAAASAArwCAAAAAEMAAAADAAAcwAL8CoAAACBAQAAAAiTAZPHZgCUAfpX lAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAAAABhj/0AAK4A APwBKADOzs4ADwDuA9gBAAACAO8DGAAAAAAAAAAPEAAAAAAAAAAAAIAAAAAABwAAAA8ADASIAQAA DwAC8IABAABQAAjwCAAAAAMAAAADiAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAAAAAAKwAAAB3 AAAAAAAAAAIACvAIAAAAAIgAAAUAAAAPAATwbAAAABIACvAIAAAAAogAACACAABDAAvwGAAAAIAA 1G++Ab8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAoAXgAYAWcAgPABHwEAAAAAAAwwsIAAAAAAAA AA8A5gAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADiAAAIAIAAEMAC/AYAAAA gAC0s3oAvwEAAAEA/wEAAAEAAQMHBAAAAAAQ8AgAAACQCcAD0BTgDQ8AEfAQAAAAAADDCwgAAAAB AAAAEADmAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAGIAAAADAAAgwAL8DAA AACBAQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAkZGRAAAAAABhj/0AAK4AAPwBKADOzs4ADwDuA9gBAAACAO8DGAAAAAEAAAANDgAA AAAAAAAAAIAAAAAABwAAAA8ADASIAQAADwAC8IABAABAAAjwCAAAAAMAAAAkUAAADwAD8BgBAAAP AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAFAAAAUAAAAPAATwbAAAABIA CvAIAAAAEFAAACACAABDAAvwGAAAAIAA1HK+Ab8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAAkAAg ASwXQAIPABHwEAAAAAAAwwsIAAAAAAAAAA0A5gAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAA EgAK8AgAAAARUAAAIAIAAEMAC/AYAAAAgAB0cr4BvwEAAAEA/wEAAAEAAQMHBAAAAAAQ8AgAAADQ AgMFfRSwDg8AEfAQAAAAAADDCwgAAAABAAAADgDmAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgA AAASAArwCAAAAAFQAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAR5AlwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAkZGRAAAAAABhj/0AAK4AAPwBKADOzs4A AAByFyAAAAABAFAAAAAAAKIVAAAtGAAAVAwAAN8aAAAWABAA/xgAAAAA9Q8cAAAAAAEAAIMVAAMA AAAAvxwAAAEAAAAWAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHgAAAAIAAAA3AGFpHgAAABkAAABN aWNyb3NvZnQgUG93ZXJQb2ludCA0LjAAXFRFQAAAAJDULtAAAAAAQAAAAKC2A3HUs74BQAAAADCU h5kLV8ABQAAAAIADFWoMV8ABAwAAAA8AAAADAAAASQAAAEcAAADKDQAA/////wMAAAAIAG8QWgsA AAEACQAAA90GAAAIAMgAAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAugMAAJMCAAAJAAAA JgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFADI8AAwAAAAABQAAABEDXoAAAAA AAAACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQA DAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwCkwK6AwUAAAAEAQ0AAAAHAAAA/AIAAP///wAA AAQAAAAtAQAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQEABAAAAC0BAAAJAAAAHQYhAPAAmQLAAwAA AAAEAAAALQEAAAcAAAD8AgAA////AAAABAAAAC0BAgAEAAAA8AEAAAgAAAD6AgAAAAAAAAAAAAAE AAAALQEAABAAAAAmBg8AFgD/////AAAqAwAAdQIAAKMDAACLAgAAAwAAAB4ABQAAAC4BAAAAAAUA AAAKAgAAAAAFAAAACQIAAAAABQAAAAEC////AAcAAAD8AgEAAAAAAAAABAAAAC0BAwAEAAAALQEB AAQAAAADAQgABwAAABIEmQIUAMADdwAFAAAACwLwxPqZBQAAAAwCOwKfDQQAAAADAQgABQAAAAwC AQABAAQAAAADAQgABQAAAAwCAQABAAUAAAAMAqsAFwQFAAAABgEBAAAABwAAAPwCAAAAc/8AAAAE AAAALQEEAAQAAAAtAQEABQAAAAYBAQAAAAUAAAALAvXqIeQeAAAAJAMNADIAqQAAAKkAAAACAFYA AgC7AH8AvACBALwAAgDtAAIA7QCpAJgAqQAyACwAMgAqADIAqQAIAAAA+gIAAAAAAAAAAAAABAAA AC0BBQAHAAAA/AIAAP///wAAAAQAAAAtAQYABAAAAPABBAAHAAAA/AIAAABw/wAAAAQAAAAtAQQA BAAAAC0BAQAFAAAABgEBAAAADgAAACQDBQAoAgIAKAKpAPQBqQD0AQIAKAICAAQAAAAtAQUABAAA AC0BBgAEAAAA8AEEAAcAAAD8AgAAAHP/AAAABAAAAC0BBAAEAAAALQEBAAUAAAAGAQEAAAASAAAA JAMHAIICAgDIAgIAaAJUANQCqQCIAqkAKAJUAIICAgAEAAAALQEFAAQAAAAtAQYABAAAAPABBAAH AAAA/AIAAABz/wAAAAQAAAAtAQQABAAAAC0BAQAFAAAABgEBAAAADgAAACQDBQASAwIAEgOpAN4C qQDeAgIAEgMCAAQAAAAtAQUABAAAAC0BBgAEAAAA8AEEAAcAAAD8AgAAAHP/AAAABAAAAC0BBAAE AAAALQEBAAUAAAAGAQEAAAAgAAAAOAUCAAkABABmA4wAVgOpABwDqQB4AwIAuwMCABcEqQDdA6kA zQOMAGYDjAB5A2gAugNoAJoDLAB5A2gABAAAAC0BBQAEAAAALQEGAAQAAADwAQQABwAAAPwCAAAA c/8AAAAEAAAALQEEAAQAAAAtAQEABQAAAAYBAQAAAMgAAAA4BQIAPQAkAAIBLAACASQAAwEgAAQB HAAFARkACAEVAAoBEgANAQ8AEwEKABYBCAAZAQYAIQEEACsBAgA3AQEARwEAAHEBAACaAQAAqgEB ALYBAgDAAQQAxwEGAM4BCgDUAQ8A1wESANkBFQDbARkA3AEcAN4BIADeASQA3wEsAN8BRQDfAX4A 3gGHAN4BiwDcAY8A2wGSANkBlgDXAZkA1AGcAM4BoQDHAaQAvwGnALUBqQCpAaoAmgGrAHABqwBG AasANwGqACsBqQAhAacAGQGkABMBoQANAZwACgGZAAgBlgAFAZIABAGPAAMBiwACAYcAAgF+AAIB LAAxAXcAMQF6ADIBfAAzAX4ANQF/ADcBgAA5AYAAQQGBAKABgQCkAYEAqAGAAKoBfwCsAX4ArgF9 AK8BewCwAXoAsAF3ALABZACwATQAsAExAK8BLwCuAS0ArQErAKsBKwCoASoAoQEpAEEBKQA9ASoA OQEqADcBKwA1ASwAMwEuADIBMAAxATEAMQE0ADEBdwAEAAAALQEFAAQAAAAtAQYABAAAAPABBAAE AAAALQECAAQAAAAtAQAABAAAACcB//8IAAAAJgYPAAYA/////wEABAAAAC0BAwAEAAAALQEBAAcA AAAbBJIC9wF+AhYABAAAAC0BAgAEAAAALQEAABwAAAD7AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY AAAAXgMKUNJ87XfbfO130Gfvd14DClAAAAoABAAAAC0BBAAFAAAACQIAAAACBQAAABQCAAAAABwA AAD7Avb/AAAAAAAAkAEAAAAAAAAAAlJvdGlzIFNhbnMgU2VyaWYgZm9yIE5va2lhANUAAAoABAAA AC0BBwAEAAAA8AEEAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAJAAAA MgqLAh8AAQAAADEABQAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAA AC4BGAAAAAUAAAACAQEAAAATAAAAMgqLAiQACAAAACAgICAgICCpAwACAAMAAgADAAMAAgAFAAUA AAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC9v8AAAAAAACQAQEAAAAAAAACUm90aXMgU2FucyBTZXJp ZiBmb3IgTm9raWEAUQAACgAEAAAALQEEAAQAAADwAQcABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAA LgEYAAAABQAAAAIBAQAAAAkAAAAyCosCOwABAAAAIAACAAUAAAAuAQEAAAAFAAAAAgECAAAAHAAA APsC9v8AAAAAAACQAQAAAAAAAAACUm90aXMgU2FucyBTZXJpZiBmb3IgTm9raWEA1gAACgAEAAAA LQEHAAQAAADwAQQABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABsAAAAy CosCPQANAAAATk9LSUEgMTk5OSAgIAAGAAYABQADAAUAAwAFAAUABQAFAAIAAwADAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABMAAAAy CosCdQAIAAAARklMRU5BTXMEAAIABAAFAAYABgAHAAQABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAHgAAADIKiwKbAA8AAAAuUFBULyBE QVRFIC8gTk4AAgAFAAUABAADAAIABgAFAAQABQADAAMAAgAGAAcABQAAAC4BAQAAAAUAAAACAQIA AAAFAAAAAgECAAAABAAAAC0BAwAEAAAALQEBAAcAAAAbBE0BdwPeAEoABAAAAC0BAgAEAAAALQEA AAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC1P8AAAAAAAC8AgAAAAAAAAACUm90aXMgU2FucyBT ZXJpZiBmb3IgTm9raWEAUgAACgAEAAAALQEEAAQAAADwAQcABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAADYAAAAyCiIBrgAfAAAAbnBtcHMtc3R5bGUgbWVhc3VyZW1lbnQg cmVzdWx0cwAXABYAIgAWABAAFQAQABEAEwAMABQADgAhABUAFQARABYAEAAUACIAFQAXABAADQAQ ABQAEQAWAAwAEAARAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQMABAAAAC0B AQAHAAAAGwQjAjUDeQGUAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7 AuL/AAAAAAAAkAEAAAAAAAAAAlJvdGlzIFNhbnMgU2VyaWYgZm9yIE5va2lhANcAAAoABAAAAC0B BwAEAAAA8AEEAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAcAAAAMgqW AY4BDgAAAFZpbGhvIFLkaXPkbmVuDwAHAAgADgAOAAgAEAAOAAcACwANAA8ADQAPAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAy CsQBwgEFAAAATm9raWEAEwAOAAwABwAOAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUA AAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACEAAAAyCvIBhQERAAAASGVsc2lua2ksIEZpbmxh bmQAEgANAAcACwAHAA8ADQAHAAYABwANAAcADwAHAA4ADgAOAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAIBAgAAAAQAAAAtAQEABAAAAC0BAwAcAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0A dysDZhsHAIoBAAAKAAYAAAAHAIoBAAAKAAQAAAAtAQQABAAAAPABBwAPAAAAJgYPABQAVE5QUAQA DAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA/////wEAAAADAAAAAAABAgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAA AAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5kAgAAIAIA ABEAAAABAAAAkAAAAAMAAACYAAAADgAAALgAAAAPAAAAxAAAAAQAAADUAAAABgAAANwAAAAHAAAA 5AAAAAgAAADsAAAACQAAAPQAAAAKAAAA/AAAABcAAAAEAQAACwAAAAwBAAAQAAAAFAEAABMAAAAc AQAAFgAAACQBAAANAAAALAEAAAwAAADAAQAAAgAAAOQEAAAeAAAAFgAAAEE0IFBhcGVyICgyMTB4 Mjk3IG1tKQBzAB4AAAABAAAAADQgUB4AAAAGAAAATm9raWEAZXIDAAAAax8AAAMAAAAJAAAAAwAA AAIAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAMRUIAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAAsAAAAAAAAAHhAAAAUAAAAGAAAAQXJpYQEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAI AAAACQAAAP7///8LAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAA ACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAA MwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABB AAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAAD+////SwAAAEwAAABNAAAATgAAAE8A AABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAAD+/////v////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////bAAbAAAAUm90aXMgU2FucyBTZXJpZiBmb3IgTm9r aWEAFwAAAEJsYW5rIFByZXNlbnRhdGlvbi5wb3QAIAAAAG5wbXBzLXN0eWxlIG1lYXN1cmVtZW50 IHJlc3VsdHMAIAAAAG5wbXBzLXN0eWxlIG1lYXN1cmVtZW50IHJlc3VsdHMADBAAAAYAAAAeAAAA CwAAAEZvbnRzIFVzZWQAAwAAAAIAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4A AAANAAAAU2xpZGUgVGl0bGVzAAMAAAACAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4A AAABAAAAAgAAAAoAAABfUElEX0dVSUQAAgAAAOQEAABBAAAATgAAAHsAQwA4ADAARQA2AEIAOAAy AC0AQwAyAEYARAAtADEAMQBEADQALQBBAEUAOQAxAC0AMAAwADAAMAAwADAAMAAwADAAMAAwADAA fQAAAAAAAAAAAAAAAAD2DyAAAAAUAAAAX8CR4+ccAAAIAPQDAwD//3ZyYWlzYW5lCAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C064BA.208F49D0 Content-Type: application/vnd.ms-powerpoint; name="1kalvo.ppt" Content-Disposition: attachment; filename="1kalvo.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAIwAAAAAAAAAA EAAAJgAAAAEAAAD+////AAAAACQAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////IgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAA/v////7///8hAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAAP7////+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAALBtl/u0ZMAB EgAAAAADAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAaBwAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMAAADEGgAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALACAAAAAAAADwDo AwAHAAABAOkDKAAAAIAWAADgEAAAFREAAFkWAAAFAAAACgAAAAoAAAATAAAAAQAAAAAAAAEPAPID TgEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAApLcSAKS3EgCwsxIA+NMDMNSzEgAIAAAA1LMSAH7UAzAAAAQAEAC3D0QA AABBAHIAaQBhAGwAAABOAGUAdwAgAFIAbwBtAGEAbgAAAKS3EgCktxIAsLMSAPjTAzDUsxIACAAA ANSzEgB+1AMwAAAEIgAApA8KAAAAAQADAAEAAQASAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAA BQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAA AAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsE MAEAAA8AAPAoAQAAAAAG8NAAAAACZAAAGQAAABUAAAAEAAAAAQAAAAsAAAAAAAAACAAAAAAAAAAd AAAAAAAAAAUAAAAAAAAAHQAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABQAAAAAAAAAFAAAAAAAAAAUA AAAAAAAABQAAAAAAAAAGAAAABAAAAAgAAAAAAAAABAAAAAAAAAAFAAAAAAAAAAUAAAAAAAAABgAA AAMAAAAGAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAIAAAAEAAAA YwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgQABrxBAAAAP8zAABA AB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAQAAAAAAAAAAAAAgAAA AAAPANAHPgEAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAPoDZwAAAAAA/gMDAAAAAAAA AAD9AzQAAABLAAAAZAAAAEsAAABkAAAA4LMSAH7UAzDYsxIACAAAABAXAAB0DQAA6Pz//5r///8A AAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAPoDZwAAAAAA/gMDAAAAAAEAAAD9 AzQAAAA2AAAAZAAAADYAAABkAAAA4LMSAH7UAzDYsxIACAAAAKYXAADADAAAyPj//6z///8BAAAA cAD7AwgAAAAAAAAALAsAAHAA+wMIAAAAAQAAAIoIAAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABC AAAAZAAAACyMegAAAAAApLcSAAEAAAAQFwAAEA4AAAAAAAAAAAAAAAD//z8A2Q8MAAAAAADaDwQA AAAAAAwATwDZDwwAAAAAANoPBAAAAAAAPAAPAPAPoAIAAAAA8wMUAAAAGQAAAAAAAAACAAAADgEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPGQAAAElFVEYgIzQ5IHVwZGF0ZSAoLTAzLnR4dCkAAKoPCgAA ABoAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKgPqwEAAEdlbmVyaWMgYXBwcm9hY2g6DUtlZXAgbWV0 cmljIGdlbmVyaWM6IG5vIHN0YXRpc3RpY3MgZGVmaW5lZC4NRGlzY3Vzc2lvbiBvbiBwYWNrZXQg bG9zcyBzaGFycGVuZWQuDVJldmlzZWQgZGlzY3Vzc2lvbjoNRGVmaW5pdGlvbiBvZiBzcHVyaW91 cyBtZWFzdXJlbWVudCBwYWNrZXRzLg1OZWVkIGZvciBkZWZpbmluZyBhZGVxdWF0ZSBhY2N1cmFj eSBmb3IgcGxhY2VtZW50IG9mIE1QKFNyYy9Ec3QpLg1SZW1vdmVkICJwYWNrZXQgSUQgY29ycnVw dGVkIiAoY292ZXJlZCBieSAicGFja2V0IGNvcnJ1cHRlZCIpLg1BZGRpdGlvbnM6DVBsYWNlaG9s ZGVyIGZvciBnbG9iYWwgbGV2ZWwgcmVvcmRlcmluZyBtZXRyaWMuDVBvc3NpYmlsaXR5IG9yIHBh Y2tldCBpbnRlZ3JpdHkgY2hlY2sgbWVudGlvbmVkLg1JUCB2ZXJzaW9uIGFkZGVkIHRvIG1ldHJp Yy4AAKEPbAAAABIAAAAAAAAAAABRAAAAAQAAAAAAFAAAAAAAAAAAAK0AAAABAAAAAAALAAAAAAAA AAAAfQAAAAEAAAAAABIAAAAAAAAAUQAAAAAAAAAUAAAAAAAAAK0AAAAAAAAACwAAAAAAAAB9AAAA AAAAAAAAqg8KAAAArAEAAAEAAAAAAAAA6gMAAAAADwD4A1gIAAACAO8DGAAAAAEAAAABAgcJCAAA AAAAAAAAAAAAAAAAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAH IAAAAAAA/wD///8AAAAAAP//AAD/mQAAAP//AP8AAACWlpYAYADwByAAAAD//8wAAAAAAGZmMwCA gAAAM5kzAIAAAAAAM8wA/8xmAGAA8AcgAAAA////AAAAAAAzMzMAAAAAAN3d3QCAgIAATU1NAOrq 6gBgAPAHIAAAAP///wAAAAAAgICAAAAAAAD/zGYAAAD/AMwAzADAwMAAYADwByAAAAD///8AAAAA AICAgAAAAAAAwMDAAABm/wD/AAAAAJkAAGAA8AcgAAAA////AAAAAACAgIAAAAAAADOZ/wCZ/8wA zADMALKysgAAAKMPPgAAAAEA//0/AAAAIiAAAGQAAAAAAAEAZAAAAAAAAAAAAEACAAAAAAIAAAD/ /+8AAQABAP///////xwAAAAAAwAAEACjD3gAAAAFAP/9PwABACIgAABkAAAAAAAAAGQAFAAAANgA AABAAgAAAAACAAAA///vAAEAAQD///////8YAAAAAAEAAIAFAAATINQBIAEAAAIAEgCABQAAIiDQ AkACAAAAAIAFAAATIPADYAMAAAAAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQA AAAAAAAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////wwAAAAAAQAAAAUAACABIAEA AAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAA AQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAE AAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABQA AQAAAAAAAAACABAAAgAAAAAAAAACABAAAwAAAAAAAAACABAABAAAAAAAAAACABAAgACjDz4AAAAF AAAAAAAAAAAAAgASAAEAAAAAAAAAAgAOAAIAAAAAAAAAAgAOAAMAAAAAAAAAAgAOAAQAAAAAAAAA AgAOAA8ADASGBAAADwAC8H4EAAAQAAjwCAAAAAYAAAAKBAAADwAD8BYEAAAPAATwKAAAAAEACfAQ AAAA9fX19fX19fX19fX19fX19QIACvAIAAAAAAQAAAUAAAAPAATw0gAAABIACvAIAAAAAgQAAAAK AACTAAvwNgAAAH8AAQABAIAAVB56AIcAAQAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAAAAEAegAPAA3wVAAAAAAA nw8EAAAAAAAAAAAAqA8gAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAA ACEAAAAAAAAAqg8KAAAAIQAAAAEAAAAAAA8ABPAWAQAAEgAK8AgAAAADBAAAAAoAAIMAC/AwAAAA fwABAAEAgAC0HnoAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAADg BLAB0BQADw8AEfAQAAAAAADDCwgAAAABAAAAAgB6AA8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IA AABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2 ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAA AwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwXgAAACIACvAIAAAACAQAAAAKAACTAAvwNgAA AIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACMsBakoAAP8BCAAIAAECAgAACAAA EPAIAAAAIAEgAfAVYA8PAATw1gAAABIACvAIAAAACQQAAAAKAACDAAvwMAAAAH8AAAABAIAAdB96 AIEBBAAACIMBAAAACL8BAAARAMABAQAACP8BAAAJAAECAgAACAAAEPAIAAAAWw+kAVQGexAPAA3w dgAAAAAAnw8EAAAABAAAAAAAqA8WAAAASUVURiAjNDkNU2FuIERpZWdvLCBDQQAAoQ8YAAAAFwAA AAAAAAAAABcAAAABAAMAAQABAA4AAACqDyQAAAAGAAAAAAAAAAIAAAABAAAAAAABAAAAAAAAAA4A AAABAAAAAAAPAATwogAAABIACvAIAAAACgQAAAAKAACDAAvwMAAAAH8AAAABAIAA1B96AIEBBAAA CIMBAAAACL8BAAARAMABAQAACP8BAAAJAAECAgAACAAAEPAIAAAASw9WCToPaxAPAA3wQgAAAAAA nw8EAAAABAAAAAAAoQ8cAAAAAQAAAAAAAAAAAAEAAAABAAcAAQABAA4A/zMA/gAAqg8KAAAAAQAA AAEAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sA lAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZ ADMzzADMzP8AsrKyACAAug8sAAAAQgBsAGEAbgBrACAAUAByAGUAcwBlAG4AdABhAHQAaQBvAG4A LgBwAG8AdAAPAPADdAYAAAEA8QMIAAAAAAAAgAAADDAPAAwENAYAAA8AAvAsBgAAQAAI8AgAAAAH AAAABzQAAA8AA/DEBQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA0 AAAFAAAADwAE8O8AAAASAArwCAAAAAI0AAAACgAA0wAL8E4AAAB/AAEAAQCAAJQjegCBADllAQCC AJ2yAACDADllAQCEAJ2yAAC/ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIA AAgAABDwCAAAAAAAAABnBx4BDwAR8BAAAAAAAMMLCAAAAAAAAAAKAnoADwAN8FkAAAAAAJ8PBAAA AAQAAAAAAKgPAQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD5DwQAAAAAAAAAAACq DxQAAAABAAAAAQAAAAAAAQAAAAEAAAAAAA8ABPDxAAAAEgAK8AgAAAADNAAAAAoAANMAC/BOAAAA fwABAAEAgAD0I3oAgQA5ZQEAggCdsgAAgwA5ZQEAhACdsgAAvwAQAB8AgQEEAAAIgwEAAAAIvwEB ABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAK4JFREeAQ8AEfAQAAAAAADDCwgAAAABAAAA BwB6AA8ADfBbAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxYAAAACAAAAAAAACAAAAgACAAAA AAACAAwAAAD4DwQAAAAAAAAAAACqDxQAAAABAAAAAQAAAAAAAQAAAAEAAAAAAA8ABPBkAAAAEgAK 8AgAAAAENAAAAAoAAGMAC/AkAAAAfwAEAAQAhwABAAAAfwEAAAEAvwERABEA/wEIAAkAPwIBAAEA AAAQ8AgAAACtAfQCIQ4OCg8AEfAQAAAAAADDCwgAAAACAAAABQB6AA8ABPA0AQAAEgAK8AgAAAAF NAAAAAoAANMAC/BOAAAAfwABAAEAgABUJHoAgQA5ZQEAggCdsgAAgwA5ZQEAhACdsgAAvwAQAB8A gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACdCkcCzg6sFA8AEfAQ AAAAAADDCwgAAAADAAAABgJ6AA8ADfCeAAAAAACfDwQAAAACAAAAAACoD1IAAABDbGljayB0byBl ZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxl dmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoP CgAAAFMAAAABAAAAAAAPAATw9QAAABIACvAIAAAABjQAAAAKAADjAAvwVAAAAH8AAQABAIAAtCR6 AIEAOWUBAIIAnbIAAIMAOWUBAIQAnbIAAIcAAgAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMAB AQAACP8BAQAJAAECAgAACAAAEPAIAAAAOxUAAGcHWRYPABHwEAAAAAAAwwsIAAAABAAAAAkCegAP AA3wWQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADAAA APoPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAABAAAAAQAAAAAADwAE8PcAAAASAArwCAAAAAc0 AAAACgAA4wAL8FQAAAB/AAEAAQCAABQlegCBADllAQCCAJ2yAACDADllAQCEAJ2yAACHAAIAAAC/ ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAADsVrgkVEVkW DwAR8BAAAAAAAMMLCAAAAAUAAAAIAnoADwAN8FsAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEP FgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAANgPBAAAAAAAAAAAAKoPFAAAAAEAAAABAAAAAAAB AAAAAQAAAAAADwAE8EgAAAASAArwCAAAAAE0AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAYgG agCUAbatigC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAA zJkAMzPMAMzM/wCysrIADwDJD0wEAAAPAAwEHAQAAA8AAvAUBAAAMAAI8AgAAAAFAAAABUgAAA8A A/CsAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAABIAAAFAAAADwAE 8NMAAAASAArwCAAAAAJIAAAACgAA0wAL8E4AAAB/AAEAAQCAABQiegCBADllAQCCAJ2yAACDADll AQCEAJ2yAAC/ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAA AAAAAABnBx4BDwAR8BAAAAAAAMMLCAAAAAAAAAAKAnoADwAN8D0AAAAAAJ8PBAAAAAQAAAAAAKgP AQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD5DwQAAAAAAAAADwAE8NUAAAASAArw CAAAAANIAAAACgAA0wAL8E4AAAB/AAEAAQCAAHQiegCBADllAQCCAJ2yAACDADllAQCEAJ2yAAC/ ABAAHwCBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAAAArgkVER4B DwAR8BAAAAAAAMMLCAAAAAEAAAAHAnoADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEP FgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADAAAAPgPBAAAAAAAAAAPAATw2QAAABIACvAIAAAABEgA AAAKAADjAAvwVAAAAH8AAQABAIAA1CJ6AIEAOWUBAIIAnbIAAIMAOWUBAIQAnbIAAIcAAgAAAL8A EAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAOxUAAGcHWRYP ABHwEAAAAAAAwwsIAAAAAgAAAAkCegAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8U AAAAAgAAAAAAAAAAAAIAAAAAAAIADAAAAPoPBAAAAAAAAAAPAATw2wAAABIACvAIAAAABUgAAAAK AADjAAvwVAAAAH8AAQABAIAANCN6AIEAOWUBAIIAnbIAAIMAOWUBAIQAnbIAAIcAAgAAAL8AEAAf AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAOxWuCRURWRYPABHw EAAAAAAAwwsIAAAAAwAAAAgCegAPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAA AgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA2A8EAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABSAAAAAwA AIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGIBmoAlAG2rYoAvwESABIA/wEAAAgABAMJAAAAPwMBAAEA EADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPYAQAAAgDvAxgAAAAB AAAADQ4AAAAAAAAAAACAAAAAAAcAAAAPAAwEiAEAAA8AAvCAAQAAIAAI8AgAAAADAAAAA2AAAA8A A/AYAQAADwAE8CgAAAABAAnwEAAAAJsCAADhAbAAAQAAEAQAAAACAArwCAAAAABgAAAFAAAADwAE 8GwAAAASAArwCAAAAAJgAAAgAgAAQwAL8BgAAACAAJQgegC/AQAAAQD/AQAAAQABAwIEAAAAABDw CAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAHoADwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwbAAAABIACvAIAAAAA2AAACACAABDAAvwGAAAAIAA9CB6AL8BAAABAP8BAAABAAEDAwQAAAAA EPAIAAAA2AOwAdAUAA8PABHwEAAAAAAAwwsIAAAAAQAAAA4AegAPAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABYAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgA vwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADM zP8AsrKyAAAAchckAAAAAQAgAAAAAAAIBwAACgAQAGgPAAATABAA5BUAABkAEAA4GgAAAAD1DxwA AAAOAQAAgxUAAwAAAAAYHAAAAQAAABkAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUA AAAGAAAABwAAAAgAAAAJAAAACgAAAP7////+//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////+/wAABAACAAAAAAAAAAAAAAAA AAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuGAIAANQBAAAQAAAA AQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAALwAAAAGAAAAxAAAAAcAAADMAAAACAAAANQAAAAJ AAAA3AAAAAoAAADkAAAAFwAAAOwAAAALAAAA9AAAABAAAAD8AAAAEwAAAAQBAAAWAAAADAEAAA0A AAAUAQAADAAAAHMBAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNob3cAAB4AAAAJAAAATW90 b3JvbGEAIFNoAwAAAGgcAAADAAAADAAAAAMAAAABAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAA AwAAADEVCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAEAAAAEAAAAFRpbWVz IE5ldyBSb21hbgAGAAAAQXJpYWwAFwAAAEJsYW5rIFByZXNlbnRhdGlvbi5wb3QAGgAAAElFVEYg IzQ5IHVwZGF0ZSAoLTAzLnR4dCkADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAIAAAAe AAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAP7/AAAEAAIAAAAAAAAAAAAAAAAA AAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJQaAAANAAAAAQAAAHAAAAACAAAAeAAAAAQAAAC4 AAAABwAAANAAAAAIAAAAHAEAAAkAAAAwAQAAEgAAADwBAAAKAAAAXAEAAAsAAABoAQAADAAAAHQB AAANAAAAgAEAAA8AAACMAQAAEQAAAJQBAAACAAAA5AQAAB4AAAA2AAAATmV0d29yayBQZXJmb3Jt YW5jZSBNZWFzdXJlbWVudCBmb3IgUGVyaW9kaWMgU3RyZWFtcyAAAAAeAAAAEAAAAEdsZW5uIEdy b3RlZmVsZAAeAAAAQwAAAEM6XFByb2dyYW0gRmlsZXNcTWljcm9zb2Z0IE9mZmljZVxUZW1wbGF0 ZXNcQmxhbmsgUHJlc2VudGF0aW9uLnBvdAAAHgAAAAkAAAB2cmFpc2FuZQBtIEYeAAAAAwAAADI3 AGkeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AG9zb0AAAAAAZLSdYgAAAEAAAACAGuBxcOu/ AUAAAAAg9qOefo+/AUAAAACQl4P7tGTAAQMAAAA+AAAARwAAAPYYAAD/////AwAAAAgAbxBNDAAA AQAJAAADcwwAAAYAXAAAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAm Bg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAbAFROUFAUAMjwADAAAAAAFAAAAEQNegAAAAAA AAAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAM AAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALKAroDBQAAAAQBDQAAAAcAAAD8AgAA////AAAA BAAAAC0BAAAIAAAA+gIFAAEAAAAAAAAABAAAAC0BAQAEAAAALQEAAAkAAAAdBiEA8ADQAsADAAAA AAQAAAAtAQAABwAAAPwCAAD///8AAAAEAAAALQECAAQAAADwAQAACAAAAPoCAAAAAAAAAAAAAAQA AAAtAQAAEAAAACYGDwAWAP////8AAC4AAAAuAAAArAMAAJQCAAAIAAAA+gIAAAIAAAAAAAAABAAA AC0BAwAHAAAA/AIBAAAAAAAAAAQAAAAtAQQAXAAAACQDLACVADAAiwAxAIEAMgBuADgAXABBAE4A TgBBAFwAOABuADIAgQAxAIsAMACVADAAKwIxADUCMgA/AjgAUgJBAGQCTgBzAlwAfwJuAIgCgQCO AosAkAKVAJACQwOQAk0DkAJXA44CagOIAnwDfwKLA3MClwNkAqADUgKmAz8CqAM1AqgDKwKoA5UA qAOLAKYDgQCgA24AlwNcAIsDTgB8A0EAagM4AFcDMgBNAzEAQwMwAAQAAAAtAQAABAAAAPABAwAE AAAALQECAAgAAAAmBg8ABgD/////AQAEAAAALQEEAAQAAAAtAQEABwAAABsEwAIPAY8CRgAEAAAA LQECAAQAAAAtAQAAHAAAAPsCAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAD0Awr20nztd9t87XfQ Z+939AMK9gAACgAEAAAALQEDAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC7f8AAAAAAAC8AgAA AAAAAAAiQXJpYWwAAADwAwqm0nztd9t87XfQZ+938AMKpgAACgAEAAAALQEFAAQAAADwAQMABQAA AAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABAAAAAyCqYCUAAGAAAASUVURiAj BQANAAsACwAGAAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAu ARgAAAAFAAAAAgEBAAAACgAAADIKpgKIAAIAAAA0OQoACwAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAbAAAAMgq9AlAADQAAAFNhbiBE aWVnbywgQ0EADQAKAAsABQAOAAUACgAMAAsABQAFAA4ADQAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAACAQIAAAAEAAAALQEEAAQAAAAtAQEABwAAABsEvgKLAo0CjgEEAAAALQECAAQAAAAtAQAABQAA AAkCAAAAAgUAAAAUAgAAAAAFAAAAAgECAAAABAAAAC0BBAAEAAAALQEBAAcAAAAbBLkAeQNAAEgA BAAAAC0BAgAEAAAALQEAAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC2/8AAAAAAAC8AgAAAAAA AAAiQXJpYWwAAAD0Awr30nztd9t87XfQZ+939AMK9wAACgAEAAAALQEDAAQAAADwAQUABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAC0AAAAyCooACAEZAAAASUVURiAjNDkg dXBkYXRlICgtMDMudHh0KQAKABkAFwAXAAoAFQAVABUACgAXABcAFwAUAA0AFQAKAA0ADAAVABUA CgANABQADQAMAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQQABAAAAC0BAQAH AAAAGwSBAnkDpABIAAQAAAAtAQIABAAAAC0BAAAFAAAACQIAAAACBQAAABQCAAAAABwAAAD7AuD/ AAAAAAAAkAEAAAAAAAAAIkFyaWFsAAAA8AMKp9J87XfbfO130Gfvd/ADCqcAAAoABAAAAC0BBQAE AAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgrIAFIA AQAAAJU5BQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLg/wAAAAAAALwCAAAAAAAAACJBcmlhbAAA APQDCvjSfO1323ztd9Bn73f0Awr4AAAKAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAIQAAADIKyAB2ABEAAABHZW5lcmljIGFwcHJvYWNoOgAZ ABIAEwASAA0ACAASAAkAEgATABQADAAUABIAEgATAAsABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA +wLo/wAAAAAAAJABAAAAAAAAACJBcmlhbAAAAPADCqjSfO1323ztd9Bn73fwAwqoAAAKAAQAAAAt AQUABAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACAAAADIK 7ACCAAEAAACWOQUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC6P8AAAAAAAC8AgAAAAAAAAAiQXJp YWwAAAD0Awr50nztd9t87XfQZ+939AMK+QAACgAEAAAALQEDAAQAAADwAQUABQAAAAkCAAAAAgUA AAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAEgAAAAyCuwAoAArAAAAS2VlcCBtZXRyaWMgZ2Vu ZXJpYzogbm8gc3RhdGlzdGljcyBkZWZpbmVkLgARAA4ADQAPAAYAFgANAAgACQAHAA0ABwAPAA0A DwANAAkABwANAAgABwAPAA4ABwANAAgADgAIAAYADgAIAAYADgANAAcADgAOAAgABgAPAA0ADwAH AAUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC6P8AAAAAAACQAQAAAAAAAAAiQXJpYWwAAADwAwqp 0nztd9t87XfQZ+938AMKqQAACgAEAAAALQEFAAQAAADwAQMABQAAAAkCAAAAAgUAAAAUAgAAAAAF AAAALgEYAAAABQAAAAIBAQAAAAgAAAAyCg8BggABAAAAljkFAAAALgEBAAAABQAAAAIBAgAAABwA AAD7Auj/AAAAAAAAvAIAAAAAAAAAIkFyaWFsAAAA9AMK+tJ87XfbfO130Gfvd/QDCvoAAAoABAAA AC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAA9AAAA MgoPAaAAJAAAAERpc2N1c3Npb24gb24gcGFja2V0IGxvc3Mgc2hhcnBlbmVkLhEABwANAA4ADgAO AA0ABwAOAA8ABwAOAA8ABwAOAA4ADQANAA4ACAAGAAcADwANAA0ABwANAA8ADQAKAA4ADgAOAA4A DgAHAAUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC4P8AAAAAAACQAQAAAAAAAAAiQXJpYWwAAADw Awqq0nztd9t87XfQZ+938AMKqgAACgAEAAAALQEFAAQAAADwAQMABQAAAAkCAAAAAgUAAAAUAgAA AAAFAAAALgEYAAAABQAAAAIBAQAAAAgAAAAyCjsBUgABAAAAlTkFAAAALgEBAAAABQAAAAIBAgAA ABwAAAD7AuD/AAAAAAAAvAIAAAAAAAAAIkFyaWFsAAAA9AMK+9J87XfbfO130Gfvd/QDCvsAAAoA BAAAAC0BAwAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAk AAAAMgo7AXYAEwAAAFJldmlzZWQgZGlzY3Vzc2lvbjoAFwASABIACQASABEAFAAJABMACQASABIA EwASABIACQATABQACgAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7Auj/AAAAAAAAkAEAAAAAAAAA IkFyaWFsAAAA8AMKq9J87XfbfO130Gfvd/ADCqsAAAoABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAA AAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgpgAYIAAQAAAJY5BQAAAC4BAQAA AAUAAAACAQIAAAAcAAAA+wLo/wAAAAAAALwCAAAAAAAAACJBcmlhbAAAAPQDCvzSfO1323ztd9Bn 73f0Awr8AAAKAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAF AAAAAgEBAAAASAAAADIKYAGgACsAAABEZWZpbml0aW9uIG9mIHNwdXJpb3VzIG1lYXN1cmVtZW50 IHBhY2tldHMuABEADgAIAAYADwAHAAgABgAPAA8ABgAPAAgABwANAA8ADgAKAAYADwAPAA0ABwAV AA0ADgANAA8ACQANABYADQAPAAgABgAPAA0ADgANAA0ACAAOAAYABQAAAC4BAQAAAAUAAAACAQIA AAAcAAAA+wLo/wAAAAAAAJABAAAAAAAAACJBcmlhbAAAAPADCqzSfO1323ztd9Bn73fwAwqsAAAK AAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAA CAAAADIKggGCAAEAAACWOQUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC6P8AAAAAAAC8AgAAAAAA AAAiQXJpYWwAAAD0Awr90nztd9t87XfQZ+939AMK/QAACgAEAAAALQEDAAQAAADwAQUABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAFUAAAAyCoIBoAA0AAAATmVlZCBmb3Ig ZGVmaW5pbmcgYWRlcXVhdGUgYWNjdXJhY3kgZm9yIHBsYWNlbWVudCBvZhEADgANAA8ABgAIAA8A CQAHAA8ADQAIAAcADgAHAA8ADgAHAA0ADwANAA8ADwANAAgADQAHAA0ADgANAA8ACQANAA4ADQAH AAgADgAKAAYADwAHAA0ADQAOABUADQAPAAgABwAOAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAGQAAADIKnwGgAAwAAABNUChTcmMv RHN0KS4UABAACAAQAAkADgAGABIADQAIAAgABwAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7Auj/ AAAAAAAAkAEAAAAAAAAAIkFyaWFsAAAA8AMKrdJ87XfbfO130Gfvd/ADCq0AAAoABAAAAC0BBQAE AAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgrCAYIA AQAAAJY5BQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLo/wAAAAAAALwCAAAAAAAAACJBcmlhbAAA APQDCv7SfO1323ztd9Bn73f0Awr+AAAKAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAUQAAADIKwgGgADEAAABSZW1vdmVkICJwYWNrZXQgSUQg Y29ycnVwdGVkIiAoY292ZXJlZCBieSAicGFja2V0ABEADgAVAA8ADQANAA8ABwALAA8ADQANAA4A DQAIAAcABgASAAYADgAOAAoACQAPAA4ACAAOAA4ADAAGAAgADgAOAA4ADQAJAA4ADgAHAA8ADQAH AAsADwANAA0ADgANAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUA AAAuARgAAAAFAAAAAgEBAAAAGQAAADIK3wGgAAwAAABjb3JydXB0ZWQiKS4NAA8ACQAKAA4ADwAI AA0ADwALAAgABwAFAAAALgEBAAAABQAAAAIBAgAAABwAAAD7AuD/AAAAAAAAkAEAAAAAAAAAIkFy aWFsAAAA8AMKrtJ87XfbfO130Gfvd/ADCq4AAAoABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAIAAAAMgoLAlIAAQAAAJU5BQAAAC4BAQAAAAUA AAACAQIAAAAcAAAA+wLg/wAAAAAAALwCAAAAAAAAACJBcmlhbAAAAPQDCv/SfO1323ztd9Bn73f0 Awr/AAAKAAQAAAAtAQMABAAAAPABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAA AgEBAAAAFgAAADIKCwJ2AAoAAABBZGRpdGlvbnM6FwAUABMACQALAAkAEwAUABEACwAFAAAALgEB AAAABQAAAAIBAgAAABwAAAD7Auj/AAAAAAAAkAEAAAAAAAAAIkFyaWFsAAAA8AMKr9J87XfbfO13 0Gfvd/ADCq8AAAoABAAAAC0BBQAEAAAA8AEDAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAAIAAAAMgovAoIAAQAAAJY5BQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLo/wAA AAAAALwCAAAAAAAAACJBcmlhbAAAAPQDCgDSfO1323ztd9Bn73f0AwoAAAAKAAQAAAAtAQMABAAA APABBQAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAATgAAADIKLwKgAC8A AABQbGFjZWhvbGRlciBmb3IgZ2xvYmFsIGxldmVsIHJlb3JkZXJpbmcgbWV0cmljLgAQAAcADQAN AA4ADgAPAAcADgAOAAkABwAIAA4ACgAGAA8ABwAOAA8ADQAHAAcABgAOAA0ADQAHAAcACQANAA8A CQAPAA0ACgAGAA8ADwAGABYADQAIAAkABwANAAcABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLo /wAAAAAAAJABAAAAAAAAACJBcmlhbAAAAPADCrDSfO1323ztd9Bn73fwAwqwAAAKAAQAAAAtAQUA BAAAAPABAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACAAAADIKUgKC AAEAAACWOQUAAAAuAQEAAAAFAAAAAgECAAAAHAAAAPsC6P8AAAAAAAC8AgAAAAAAAAAiQXJpYWwA AAD0AwoB0nztd9t87XfQZ+939AMKAQAACgAEAAAALQEDAAQAAADwAQUABQAAAAkCAAAAAgUAAAAU AgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAE8AAAAyClICoAAwAAAAUG9zc2liaWxpdHkgb3IgcGFj a2V0IGludGVncml0eSBjaGVjayBtZW50aW9uZWQuEAAPAA0ADQAHAA8ABgAHAAcACAANAAcADgAK AAYADwANAA4ADQANAAgABwAHAA4ACAAOAA4ACgAGAAgADgAGAA4ADgAOAA0ADQAHABUADgAOAAgA BwAPAA4ADgAOAAcABQAAAC4BAQAAAAUAAAACAQIAAAAcAAAA+wLo/wAAAAAAAJABAAAAAAAAACJB cmlhbAAAAPADCrHSfO1323ztd9Bn73fwAwqxAAAKAAQAAAAtAQUABAAAAPABAwAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAACAAAADIKdQKCAAEAAACWOQUAAAAuAQEAAAAF AAAAAgECAAAAHAAAAPsC6P8AAAAAAAC8AgAAAAAAAAAiQXJpYWwAAAD0AwoC0nztd9t87XfQZ+93 9AMKAgAACgAEAAAALQEDAAQAAADwAQUABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAA AAIBAQAAADAAAAAyCnUCoAAbAAAASVAgdmVyc2lvbiBhZGRlZCB0byBtZXRyaWMuAAcAEAAGAA4A DQAJAA4ABgAPAA8ABgAOAA4ADwANAA8ABwAIAA4ABwAVAA4ACAAJAAcADQAHAAUAAAAuAQEAAAAF AAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQEABAAAAC0BBAAcAAAA+wIQAAcAAAAAALwCAAAAAAEC AiJTeXN0ZW0Ad7oDZq0HAIoBAAAKAAYAAAAHAIoBAAAKAAQAAAAtAQUABAAAAPABAwAPAAAAJgYP ABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA/////wEAAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFNsaWRlIFRpdGxlcwADAAAAAQAAAACYAAAAAwAAAAAA AAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABO AAAAewA0ADUANwBFADcANgA5ADAALQBDADUARgA5AC0AMQAxAEQANAAtAEEARQA5ADUALQAwADAA MAAwADAAMAAwADAAMAAwADAAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIAAAABQAAABf wJHjRBwAAAgA9AMDABIAdnJhaXNhbmUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAIAAAACQAA AAoAAAD+/////v////////////////////////8aAAIA//////////////////////////////// //////////8AAAAAAAAAAAAAAAAAAAAACwAAACgAAAD///////////////////////////////// /////////////////////////////////////////////////////////wAAAAD///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// AAAAAP////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////8AAAAA//////////////////////////////////////////////////// ////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQD//////////wEAAAAQjYFkm0/PEYbqAKoA uSnoAAAAAAAAAAAAAAAAgGrdAbVkwAESAAAAAAMAAAAAAABQAG8AdwBlAHIAUABvAGkAbgB0ACAA RABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAADAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABoHAAAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAAAMQa AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAsAIAAAAAAAD//////////wMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA/v////////8nAAAAFAAAABUAAAAWAAAAFwAAABgA AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAAP7//////////////yUAAAD9/////v// //7////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////0MAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAIAAAACQAAAAoA AAD+/////v////////////////////////8aAAIA//////////////////////////////////// //////8AAAAAAAAAAAAAAAAAAAAACwAAACgAAAD///////////////////////////////////// /////////////////////////////////////////////////////wAAAAD///////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////AAAA AP////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////8AAAAA//////////////////////////////////////////////////////// ////////////////////////AQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAA AP7////+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////8AAFNsaWRlIFRpdGxlcwADAAAAAQAAAACYAAAAAwAAAAAAAAAgAAAA AQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewA0 ADUANwBFADcANgA5ADAALQBDADUARgA5AC0AMQAxAEQANAAtAEEARQA5ADUALQAwADAAMAAwADAA MAAwADAAMAAwADAAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIAAAABQAAABfwJHjRBwA AAgA9AMDAP//dnJhaXNhbmUIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA== ------_=_NextPart_000_01C064BA.208F49D0 Content-Type: application/octet-stream; name="results.pdf" Content-Disposition: attachment; filename="results.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNCAwIG9iago8PC9MZW5ndGggNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1XTXPbOAy9+1dgekpnLEXfkXvrV3Z62O6m8bSHtgdaom1uJFElqTj+v/0h C5CSLTlpD42TyRhSSODh4QGkAz+MIKDfwSjq2Y/ZDf59meWQBwHU+LnAz2qW5OHIyq21nTWzH5D7 Mf1YB2O7qOHNcnb5KQP0vlzPQvDodYjhgiTI4gRd534Cy/ri00+hfza8ebn8b/Z+CTc9hjBIgx6G NV38OEzDsfksLGGUIZrwgORDs5aqZkbIhlXgAX9oheIaXrdKVHOIgiA8AZmEyQDSmj1JURCOzWeB TBaZn49AnkLIIYsWkS1WlthAYYoxJzYtOEPFrtKBqH+h5cqS1RQcam6UKDR8+esEW5wlKUVfIDxn O1RJHGRTm9b8OUXxlZ8gRQd8n334haqQpHBgK7bxiduxGZ6JqyQbRGW4ariBd4qtzal+giClkESQ s+MRKWM7fBZBeeBnRNAA6qO8E+wxNcFATeTEc0WEjO3gTOTEicNhOfEUE5phrTxstq4y2gsC3zyc chWneUoIrJisHY0FNLKD54kp8CPiasD4T2Hkiitq/+ARZelioCx0NMV5OLHtgnNQFkUOzltm+Eaq /SuYjKsJsj+ZhcmVlUiW9xJp2rrVnjb7ihqc6U7xmjcG+ho9ZiLpmUizPvsonNrJeZjIsp6JwIdb w0ynQa7BbIWGv3ktn0tEFPrYidR9/TBZkudSFp1NH23WwNDUnhUwvinpH6KBdVdVUMjmMBt3wmwJ EokKPIpVXjBc0yp5LzSWzqK/5QWVEcKAnj5dv42CKIOvtDFapH5MJzRutLP/yu+fvvv06MVB5KcR eOgfX06RIViFGKS6E83mkERPGD+kAe+bjWg4V7jKgh2QLpm+g2upMJFvFx/eL6+/vZyDcG6ZnrvE 8XGIsFGya7UPH6XhGIGZiTeJMVW/Bmq2B1ZpCaXQeHysOvMUUKaPXE98ufR8eCrf0hbl6OSeVaIE LAkwDPsg6q5GBibutHiAWjZmq21OBG7FoWtL7LZyjqJvK1aQhU7kSsuK43tY7cHmNHE1Ak/K2IMR NUegxkmEtVh6vFAwYkhCp49l8NwZoSfukAHF11xxe9LiLtxaEQzcXAhLM68dDGK8IcpeEJEYa+II w26webX/on/tBLNEHVRYAtJE0SlFIj8ltUC3SAcrCtyPeZ/UdWtM++rycrfb+YKbtS/V5pKMy1CU HltheVmBtepH+lFco8gnDXW7ZaXcwTu8fuH0VYL/EQZtvfhbU1f+o3kVD/MqdjMqy8KJeaZplQxz O/ThdU/FGUYUXp4yiIc74evCdCiKJ8Y0itUwbO3SDiJwQ70Sdxy+Rt/HG6bdwE3XulbiusDmJL6x LVBkQqHryh46pECaItZp33S4Z9oMQhcd1csHKneLsDAYuhvwkf4Z6G6FMYex5By6W+V82gwIgmAd /SCGjbjnNJT5A6tbPK16L+S5N50rmgATb9jVUhkaODjNqgES1mniq8SOu8eE7w8uf0XbkBP2uR3v Jab9SHdR2usuurJiW+AFfWym59FdHPbXl8jOSCXLzh4x5zoeo3zhZ3kvPuLms8RvBTUvBVbTIJ81 8LrrhXIjb8ek4WSsKmxvO5EHBmPrrrzAwxPRVhXWlrYZjgOCFqJ3bJ5GU8lIvD684ehkflDSWsna ATi6TDMr51M8UyxWT65cDlKDo5PG0ehqNXY3brMVNzvOUS9N2UpB7vAS8JY1rGS2Y65FU+GnU/+h cY6Hz1M++7bqRatbXoi1QGzo+bTd6GZy6LDeZ7zwj5PdSRw3T1Le4XGCZ0nprieAB3JTehitBXff KxHo/jcQteVJC2wRgWfQ3qVHj/bfQ5KTgdTp0eViKPb0kmm/Rc5hK3f8nqs5ZVdLRLrhDVesIiHD 1+T7nI5xbrayHHf0ALP/YkpdzSYAdCcMW2Egwr7CAxNkw70dXUOwUEcOfps3ET6MxHFv/w+/Y8j4 ZW5kc3RyZWFtCmVuZG9iago1IDAgb2JqCjE0NzEKZW5kb2JqCjMgMCBvYmoKPDwKL1R5cGUgL1Bh Z2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Q cm9jU2V0IFsvUERGIC9UZXh0XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDQg MCBSCj4+CmVuZG9iago5IDAgb2JqCjw8L0xlbmd0aCAxMCAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nK1Xy27bOBTd+ysuuhikQKxIfsWeXZN20GAmTdoYmMVkFrRE22wkUiUpO+73 9kPmXEpOZDmzaZMACWHLh+eee+7DcZQMKObf/SEtet9632gaDfknvNQ+pwVdzHtnXyaE5+fLXkJ9 fjmhZDSK4lFC59NBNKJ5caLfzr/2ziNGnWcnZVG6vvO7XFIhhausLKT2ZKWrcu/40cE0jqb1wzep NwtpaRDHMb/1YU6fe5/B6+/elKZxTAX+z/A/742mSes0Dad1T/9MBDH4x5PhCNDTOoQvP5T7oaXu cEjiadzQCMf6/mEySNrHX+KSDGbRBGrumVzppbGF8MpokVOf5GOpoB29K63KWaekw3GUjPYcw7HR aBAn7eMvcRzNJtG0xXFwQOEnAAdJNIrjCZ2PxtFkypB/KISb705JaIQsihL2yaRVGyixkVQ5SWb5 kqFIOSpxxksyi5hYTP1kGGCzk/la0hsrtm/os7mjdC2sSD1gnVepayCUXtHSmoKvxrt8XeueZ8Tx hBH9rlQpUyWl07zKmGYudu6UcuNARdoUnxIriVe+Ko/LHAeVtaLpQhbSW6bjqnRNwtWAeySVSxcR 4oAC3yqBF7xi7O0a7yCCJvYXgaGYt0K70lgfBIC1EFumBDlvpSgcCU8eGnlVBIH53AoezK3samoF nrIkFsCAXsw4cAWBjBa7kEGd9ZEyG9EfuNGvFWstnNEABL5fm6zLNVATZcnZeCnN3tC1BPQNnkBt 0F1qrKT7k+ubu/u3tBF5JdkLRxJUPlcazmAJYRSTygzQ7JpMutSqBUgrTQWjZdILFJnMndwiREn/ jP+NjtrSOB5OQl8aoxOiqAbJJDk88wOv0Jwm8XlTHcOIPkm/Nfahk9COUV+jJsdo69NQ5qzYUlnn DzxDsqjy0J+6DGhbW4EbWFC1m4x31aoCWjKbzWiBeKTUlJlCcjWyZ0qjNFe0JrSDnIvm/uQjsqH0 gwo1dFPl1WkXNRURJI/pARVcCuvv39bJdjI1OjsFHIpQNx31tEu4i/bMf8/wgNghHe/FVoDkpdAi E/BhO+a6Wt7LVBY84jjqmthe02ceqJUMlZFB5lSgj9HVLek64UfhBmdCaP8UIhktg/aFQDsCybJa 5FD0KgQufQS4zSg8ES46TszC+HWbkDt2/XA2GwbXjxKMk7yXTDD52ufwwCu4fgT/jQe16xOu+SeV hIX3V69q9tF4X2KcmGDMtgytHhH6wZb/oE1aU6HDoWuX6DxWSb97OU3ohtrQ2iDdaW7SB3I7na6t 0ep7XUGcEw2HOCfsrnYHZlS2PWi7NWCTum6LdgQLOAw0vAtmtzwyqqKf5gLT6OriGpjwaykytJP4 iKRC3oeXmH3XciXA2H+nJL4QTs7p9vL68uodfbq6pMZthVmo/H+GY2125+uw7k/eYChh4r1BTXCl CFohLKn7jVwE9en64/c9X7q6Ii8WufSmfJHkn5gLzgM6ic8S/uxC+TPXZrdUj5CgXVUNmy4eyPGU CeQiumDrc4ZcnV1bac0z6IvMPmI4/qV09UjjaPC0WswamPlhHo6sctALxcJgrXju3bncyPy0K5+K ZAS5RL5DQutaNRqbRia8QJrzXKb+CezOpkHa9zCXg7fk0aoSGt9SpM0CsacjdPo06/dmOw1KZthQ 9vvK0SDFp0XYldwOZitqtfC4Wipwko9ewoaICpuLVTz1zb6FdcNs82g7GUsNpzokE8GaLd/WzP/f u/L3m72LskryXS9FQr/R/PL2DM0UVkD14W1wWuVqpWA1UstukB94swFrNNZVSKpfwwO1O/jDKDVd 5wA3IkXaeEIubG7QebMji/S5+lu9ol7sjrcbypQDNNStwna3j+nmritd3YAWWK02L973JKATRVh3 NsqhBCAtmJSCXRL21Oc7DgpG+uq4/I6vjLDf9JNpWBPqQngybeOr/dZ2WAULUVu620L6DeIgrJfN R80Cy5hmu3u6uHvfeLyuHPZzhaB4aWy+LXCEe+qD2v1PX6S4YipPJQIPicfqaKuS01iKHecufIsQ Gyx/3IPaw+8/S+GVymVuZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKMTU0MQplbmRvYmoKOCAwIG9i ago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDIgMCBSCi9S ZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHRdCi9Gb250IDw8Ci9SNiA2IDAgUgo+Pgo+ PgovQ29udGVudHMgOSAwIFIKPj4KZW5kb2JqCjEyIDAgb2JqCjw8L0xlbmd0aCAxMyAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nK1X23LbNhB911fsS2fkGYkhKermSR7cSxLPxKli c9qHqg8QAUWISYAGQCvq9+ZDuguSNkk7nU4S+4EwuZeD3XMWcBhEMYT02y6yYnQ3uoNVMKMf/6q7 zgr4OR29uF4A2qf7UQRTeh1BlCRBmESwXMVBAmkxVmfpp9EyoKgpH5dFaafWnXIBhWC2MqIQyoER tsqdJdN4FQar2vj3zOmdMBCHYUiffkvhw+gD4vpztIJVGEKBzzU+81GyijqrlV8dRupbdhAi/nAx SzD0qt7C9RdpvyihBhiicBU2MPyyzj+L4qi7/C4sUbwOFljNFsml2mtTMCe1YjlMQXwuJdYOLkoj c6pTNMCYREmL0S+bGsVh1F1+F8ZkvQhWHYyzJ61aROvY92ox84miGfaotyaDH9CwZbJoMCDfLrKs Miw7gd53+fWA7BsyxRF2I1zAMm7IfeOY4sxwuH4L76SqPsMcM9vsIHiVS/UR7iqmXFWAtBBhE2wA 6QHXXHJQ2hGeEKaUhY8zVlkBpdG7XBQWmAV3ECCVE2ZasuxWOHCGKVtIa7H/9Zd7pIFUWQroy3vh jhiAQYHbliWqDYvgMHNANtMwiBOYxkmw9KZvtXWQ5Tq7BXsrjkCu7lTKjOX5qfbEAIajFPGPMJj/ NIFd5Ya7mAWLFYVj+73IHOjKtHWnzWiFsYyuFJ86I0vgImen7hCwcBRG+I3glh6DzhcUlCAwJP3J Npugj+vmY2cDrO06CuXZHAjl5UvsZWEncDzI7ECvhtmE0tXHg49BiR0zH7H8T8I9ZsO6UMjgCfeT dbzw3J+HswQ5Hi8XUW/tDX4A9+frJMCHJ/8MrgQWOYOSGVYI5Ilt6+r3063Ij9LEfBk2+dPDs8Md n6U2DlEcqM+lMI4RHg1vgmUUwXa8+eVqe4auXLIela0zghUgkMx+9MFRugNY1BcSm1VcarCsIJZj ULjcQC2XCchABBAtwl603cmhITvlmnFgDqcmNu5BTaRQDCd9LuGrJRo+7+E63fRCHQRDUSCRGOey Gcr4hTJYj6VbhhpUw3J0wEI43QvXt64BWvmPaPmOokWrq1bSPV4zkiMCNeTsZIEAEDBHvh6batPJ IfjEC7GXVis/HmoxbMeEWyheaulhSIM9kYPuBXDhx9PX4De7pMn7qPh7ZqRwpxoBoieGWsh0nmN5 BfWiF+7GZMAwCBc2M3InuC+DZ2CErCcStoNsFiy9bC/+W/znjxr11fR85eMNc4dzeP/iIoDXjeBf S6WkPXS9sckYkuNQJKw1+aY4re8lzcU/Nu8fwDdhd4wUh2y9SK9gh83fUaFp/pAUHzfj5RR2xvGb XO+QSMVQwuc+g99xXaEpWKzR5ea8Li2vdYHc6xdyChzHI5nRHgef/OHxqhbB8Fu6n6YhfsSbAp7V n2vb7dhLRbWXkEwrhf3DP7ZnE4hWHdteuO2Ya2Slwy11XYY5y+34ExLuFUTLVkjUTDyJ4BOwnb4X 9SlIZIRc3It8QveexnQ7vtzcJ9uzXtDaC4/j29phmJKnubYWU87BCsTGnxYC35JBbdmXYy2EZ84G 6nRfAHimij77+xeAjhLgCfthJ3J9fKQoTjyBomRWq0n9QvTbjrlbjaF8kY3Nec6gUjREO9+TIMZr C15l/GrWHBO9aIpu7sAN27vBOHpGx4T+fFhD63BGb0nW0fbsL/n3ef8642cWmTT+X3ePG3cjMlG6 /+G7uXWXvw5crLirhMoEqKqg/zFqx2Hj0fNGpifvizcdYGWZYxnxhlYfYtsxEbOd7M1NyXeGev2U 3RTPMVdZH7E+Pl60oz7TxlSl84k4Kj5zlKh7pfgXFvj5YGVuZHN0cmVhbQplbmRvYmoKMTMgMCBv YmoKMTM3NgplbmRvYmoKMTEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9UZXh0XQov Rm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDEyIDAgUgo+PgplbmRvYmoKMTUgMCBv YmoKPDwvTGVuZ3RoIDE2IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVbBbts4 EL37K+ayQALEiihLstxbi7TYHBZtEmP3sNkDLdE2NxSpiJRd/28/pI+UnMpJe0mTBNGAGs48zrx5 VByxhGL/ezTKevI4eaQimvmfsDS2y5o+LCeXtznBf7meMJr6ZUYsTaM4ZTQvkiilZX2mz5f/T+aR j7qszpq6sVPrDkpQLbjtWlEL7agVtlPOetekiKOid/5cOrMSLSVxHPtXH5d0M7kBrn8mBRVxTDWe CzzVJC3YyCqCtZ3o15wgBv44n6UIXfRHuP0m7Tct9DMMLC7iAUYw+/wzlrCx+VtYWLKIclTziORa r01bcyeN5oqmJL42ErWj900rla8Te4YxZekRYzCHGiUxG5u/hTFd5FExwpieQHhFwIThzHFO81na R/xLuFaWlszKcalFRXvptsQ1/rg6WIk3a7prSxoc33kEMU193OpsSkvreN3cn8GF3Z//K/+7GC8l YenZli8P7vrqp8t3cnnAi3ekjSPeNEqWfKXEC0e/MMt7Irs7x11nw7ZWlELuRHWpjHWXpnMevBWP ndBliDLFrqc4d1d/DyhOyJ/NFklgf5aF1iV+5E5s7/AGI5Bncd+DGR4fv6JmSoRyV6KVOxBx5wc5 VP2t2p4neZ9yuRW0NkqZvdSboddIvuXIuRJCUyNaPw4gBB7EUVoVEKkDKaM3Jy0Zq8392Sye5pgJ qTsn7P35Be23styS6TZbR84gPMhmRYs+kdRkXVcd5LOIDvAG3YqGF0nqX3wCmNLoshVOaGHtBYn1 WpShVkaL6Z4fUD6F/3tu4Vk3QFHByzqJ2UZKbk8y+U1brta+7iGr6XQ1RdGbPk5E144wBXuhFD1o s9dw4zjIFovoztZUJ/EqgzIG+ipgsXSQQiFpWXYt0h8PRVUnfC0aY60Ew4HqUPe9PonWtKbhm6BJ PRwceAVaa7ETLeCCMJbgtJMV0vad2nHViYg+CDT34kVVf1WuSlpkR2yk6iN5b7c347vktHS8FWS3 qEj0RM/HCVvMs8BFlrMFsXkRJRklaZb4Jy6+y1s2pysTiIxpmg++WQGOZrOXzovB+VWcT2NwPpkz XHrg/Ce5wTmIBQm7vE3YsCOfR4vhCqX+1VMsDGg63Jcn1ULzndm0vD7S5nOnuumfQlmpHySGQIm1 uz/HYAV2TFGGoDyzKMtDNOf4no83tBLjgR2javfM7zcuho1fePkgHEbQU3/EcDIgREBSeaJ5vgzI 9ltz+kEQODGNj4Dywsf104Jvgz+eOl+Z2s9M6adNe8YYfyVUBCH54UQYYCdaPVyaR3YcT/lja/RC ZVnGsqCyLE+8miYZvi1ObO/wBirLigx2L7MZvad15wenxfUeBPdYps4Gc/Sx9BZ6iyEYknvB1QLz 1D7Qjbk76ivHxfSzrzUqcQWvRC+7aK8zJ6MHtP4ECCL91eaR+6CrwzGuV3UFkgrtLQgxQq649UTx AiZ+pd+WbAexBhsgKCUEwSvmCuQad/A7os/+pmVuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMTEx OQplbmRvYmoKMTQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01lZGlhQm94IFswIDAgNjEyIDc5Ml0K L1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0IFsvUERGIC9JbWFnZUMgL0ltYWdl SSAvVGV4dF0KL1hPYmplY3Q8PC9SMTkKMTkgMCBSL1IxNwoxNyAwIFI+PgovRm9udCA8PAovUjIx IDIxIDAgUgovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMjQgMCBv YmoKPDwvTGVuZ3RoIDI1IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3VpZk9y2 EU4Ux4knLue+L2QSJytnh8ZBgqCdPMiu2KWUVbKkTeUhmwfuDHaX9pAckxytN7/XPyTdAA+AQ2p3 pTdLJU2D3Wh83Wg0ThowTij+7Yh1vvhi8QVRgcA/5pNLr3Pywcni3aeSgPzJ+YKRFX5mhIVhQENG YsWDkJzkR8X9k88WcYBaTzZHu3xXr+rmeqtJrtN6X+lcFw2pdL3fNjWKckUDZYUfr5vyTFeEU0qR 9Y8T8mTxBHD9e6GIopTk8JvA73YRKuZQylCXi+JlLKCAn0oRgmplTXj6VVZ/VehihIFRRVsYhrTt C8aZS74SFsaTQII3OyQPi/OyytMmK4t0S1ZEf7nLwHfkwa7KtugnNsIYsrDDaMjWR5wyl3wljGEi A+VgjDwIL6GQM7CZShKH0mo8ucRoaS7LTbktL65JWmxIA9/aqCHlOan360uSklo3WNpmdaOLrLgg ja5B4DI1oUXJCpvaHJ1pXUDtXVk1ekOygvwn+m9APtDb8uqYlMUWmyDlvtlmhUZ92Fie7nao8Uw3 V9rGQq+vgG9l9TnZ6cr0T7H2wrs2iH1QoK/RVQa9mPnYdlX5PNvozbGpBDj0l2m+2/Y4OqOzmtSX 5VURtLV5iLWtqw4GFrnSlTUB7G3KWSxn1x6WfY0iyyflM3K231zopl4G5OQSmoY2ihrwpA14fZvl WUOu0tr4HzyAjljt0vXnuvH06WKzasoV/JCN3qbX1kYrWJuKV5cZdKRhguFrrTcIGFt8nm732tNm bMoKgL6rNHYkANiWdQ3j4fQIOjXdbDIcKWjwsqn2etk21Uqd3g88feg7fX6u1032XB+TwWqyOktr vXFro/srfa6ryjp0FGBLa4FxjF9xOe6vSmuyyaDZCvvL1mudbXttj02jb7D3Ic68yDr2mvURkeW2 LGu9PCbLXG+yfb60/l422cVlY3pSkzr7nwkt07A/SDoQoMnaD660+KA/mvKiSvM2Bkl6Vj7XAXlU Al7ojHVW6+21j60F07nUCaBZX2EYrcHK9EKPRwmMkKLJ1hCy2Lk7cMdypub7vfVkXYJz6l1ZbKDl 0tMHI6Mqv8xwIMDo52/PKPMcSLxKnjoAxaI5JSYCVjSACIAoCOI++Jx8hn09GqQp+NZ6G2L7o+wC bCY86JMtIxfwL1twxiHJKsiiMSTThAn4DzJupReYYq+Azzx+iPwQ+c8WNIgjqaQAVVEsrJhkIBYm OBcBhWreaecWECE8jhKYWywpGcwinMpoRIOInV0QH2LolaNYjmJhABjaWs9c/Qmjnf4EfNvp9Gk6 px/FHP22lqtfUMlb/UCGnc4RzWf0G7FBf1vL08+hA/KOjHqdPi3m9KOYo9/W8vQLg6AlZa/Tp8M5 /Sjm6Le1PP2RQdCSca/Tp6M5/Sjm6Le1PP1Sxp1+KZNep0/Hc/pRzNFva3n6FVOdfsVpr9OjQWRG P4o5+m2tTj+LlZEKmUAbuiLHIuhmUWKCzi+Gtni5SKLQ1qZmddYVhVJoA5OS2ya9ohG2WGkQJoqK hHxsYCsc2uSft4I+U9WTdUaNZLaq9yH3MwTyvQ+5j2Q0qiVN+l5X6P0Y0DikEejslACVc9yaJJLG sDcIhCUqm/GihA3txpCoKBVtouq9MiPSgZKYRywoaUJO4JBUSrnknUDFIfVaTGA/4WOakeggJbL3 E5IiitE5jCnp0XcCxahQfQ9CkyoZO2pGog95Bhm0RWVowSNMjkyIyKPvBoup2G00ggE/gjUt0cPi coBl6CTGmGOhinz6TrCE8BrloGAEa1qihxVJ2sNCWkQcgwkyhfDou8GSIvK6SIwja0ZiyFs06WEh LTjFnATrAO7Rd4MVq9DrIhAewZqW6GGpSPWwkBY0spMA7Ohd+m6wYPHjNiricAxrWmI2X0mMphh7 cyCnIbUE67DIbmnWjfh4HFAzEn2a6gZ8bkgBDUCrCXbhQN4OCyy1/JbYQX6alujzkwr7/KRwbg9N TsLwcenboWG0nSy7iJWHiWlSYkhMQgyJSeBqixoMIpIefUs8UMMP1QM80xJDRlIDHkMnoUmOEZU+ fTs8IvJa49FBhpyWGFJRN3ByS4tQGQyKhh59Szwykm5rcXKAZ1piyEFiSI1IC2bWniyJhEffEo+i XsbDQ8ARnmmJIfnEQ05EWlCuhuQz0LfEY5ZzTk4JD+JnWmI26wjsoRjBDKSDhZmDS2VhdOlGiNEC Y9xJMxIdiLgbv7khYdmBG4kEe2sgbwCB58BuE7ieHeWZaYm+Zyjt12aGhl2EzS5cefQNQPCI1p8U D1PMpMSQYqIBCNIQpmYGFzDbuPRNQLjwmgnjg/l7WqIHImifei2Nu3jMJzz26RuAiNhLqZyPu2ZG ogci6bDsQlqEITOJhEcefRMQGXvLqBjy9DibTEoM2SQashvSgnHjhQTC1KVvAqK4l7RCceCRaYke CB6qd0AMnSRxnzpc+gYgMPF72YEdLKamJSyQbh87sSE83LVFbGrXdsi3ZzXe0Y3Ht2ct3tGLy2/P SryjE4/Pu5OGoejx7VmFd3Th8e1Zg3f04PHtWYF3dODxff/0u9bRrvZgV9zzI6Wm/Bdz7vL7YsdX MXP5fbHjM8ptMrD8vtjzmUxcflfs+YJ5/K7Y80OpXH5X7PmSxS6/K/b8WEqX3xV7fsIil98VD04V LP/AvzdeID2A8XNyvuhvLleGimgAu1FIy0HC8Q7pG/e+iUelsIswV4vfMmewUFoxSBfwYcR/bcz/ 9nx9PsE/qP/6De2/Pl/ffPgOfhBYxpKR5XRG1wtkD3C9NoELYoTAftXY9V17rm2Yb3Rn3JC7oHha OLzvtTxIcVB6863Tqv0gDftNozfENZa8i9rvIw27iVVk9FqtK/wgDfwfOLI/NIYmisDsjOUfmTal Zf64bST0SrEB8xNHyU+tA2D1ZU/y32iVrCLZs1dYhjkZyj9zqv7cbe8XnVHM1Ptlp5Yxc+/zK8sO D+r9um8gMRV/g+X2Pvy31kBKmOBfXwOBByuHlbR4fmc+9QHwewcO8e4+kigaDlBj2Fmx9rrCP1rF hSxj3to/wbUc8nJLJok5cqXw49H2KPZ2xw4JLpywzQQWH7C0P1j/Tws8u92d+XTKg3VOoGCxKANp rs3/8MeleXvBrLv+NH6+wLjs7LZ0ayxMvT49afjElpmZ0+M5i6cFXs1imLvD0DH57b/8+d7pkQk3 2r44Ob1/752x5QLP31rLDd1ai+eqHj1YPrlKC+2ee97kSYFXMxl2S/wFvfxXZ1AMi8AXXfq9JBBY p8CEHeLslB8dv7V6N8ClCV/BZjk0SRvmXRaaFBO9tRIS+CGLTQYLI4tVmY5qZ57EsGSbJd5zWe8L U08KW8SG3hd/s8pY99VTthIo8Hf8NP3AJKR49hIa8PYu1cpy1gqHonuyRHwt/VMm/h55+qIL24As T8om3S5JVmyydQrfjFS6bvbp1s7DNAghg4rA5rpHOi3I411W4KOFZ2u8TD89evT42en9Y7L88OG/ lvb2+cOHnyzJRhdlo43C/W6nK/vEpLzS3bzbazUX6/Z1RRK9TdZlcY635+v27cTzdHuMN887++5h ex2Qj0DUPCVAqWN8czDWWeEFeF7WDajb7vOiBjy7bD28N8HW1mltnhYUJdFVVVb2GQyD+B3USTPJ fH6WNe9adhwkEbHlESxTyVyaMxUoM7F8MnrnY95LtI9w9IZcZc2l8dCDR0/Bk+LjTz8lDzbpDhWS R4AzW3m39k+hj07vg0kbvcZ3BXWz31wbBe7DnrazrZRp4mxf1c01mXjwYh+a2JcWuW6qbN0Hi/tK p24qneZkU4KvGueZwviVgnkuAfXRHnzUkLY1bQOf7esmO8dIw/jpXoz4Qelkwv8Du9oXEWVuZHN0 cmVhbQplbmRvYmoKMjUgMCBvYmoKMjkxMAplbmRvYmoKMjMgMCBvYmoKPDwKL1R5cGUgL1BhZ2UK L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9j U2V0IFsvUERGIC9JbWFnZUIgL1RleHRdCi9Gb250IDw8Ci9BIDI3IDAgUgovUjIxIDIxIDAgUgov UjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDI0IDAgUgo+PgplbmRvYmoKOTEgMCBvYmoKPDwvTGVu Z3RoIDkyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVdNc9s2EL3rV+zkUnsq MiRFSVSmnantfDlNHMfWpBdfIBIyEZMEDYBS9H/zQ/oAUjZpd3pIlBwEkdDi4b3dt+vADyMK7P/9 Ii1H96N7SvyJ/ece9ddpSafL0curGWH/cj0KybOPQwrj2A/ikOZJ5Me0LI+q4+W30dy3UZfZUV3W 2tNmV3AqOdON4iWvDCmum8JouzVKAj9pN39OjVxxRVEQBPbVmyV9GX0Brn9GCSVBQCU+F/gsRnES 9laJW+Wj6mduEAB/MJvECJ20V7j6IfSPildPMIRBEnQw3LI9fxJGYX/5S1jCaOHPwOYeyXm1lqpk RsiKFeQR/14LcEcntRKF5Sl8gjEO4z1Gt+w4ioKwv/wljPFi5ic9jLMBhJ8IGIW4czCjeTxrIxpJ K041V/byPKNGi+qWTj5dkdCUysooWfTTSdM2F2lOOpdbbDc5MxZTQJ49KTsyOd9nHCEkFXLrrViV bUVm8CujOCs13Rz98SfNYrpbCfNSU812hWQZKWb4zfEg3pYrThVnyhMZjhcptGEaYYESn/Y4o1il S6E1lCNRGa422CSqdElbpp+h06zkPl0WuBMiS8PdJex18YVYsWW7Nm6KDf6z2phOo4UrjulsMoey c9REf2lfH6A+ZjOrvFUo9um10Gnj7ncA/eMA+s/iqAu/7Akm18RAttlKddfSWktl6Iu8HjiK00Rx +45nA37b7KmsE+EXRolU+2RPkErcCltX/XeWc1lxD4yPadVAA/NMsYyXskLaIDOyTigDZSoIpV3q srouhH0ngV3Jpso8xK77gJ+LGCediPHiQbn+MjmMiNNkz/LUpyu+Bm9VyvWhing6Tbrw4aARENmv YYwKd99PFcsqruzDabB/OKZrf0wvrDjntmYgO10bVCpTmaZLJQFUk+cB90a40pq8GNPp2aUN47k4 nUSLMV29PYNDRrMx7ftKuIB1ua0WLXlRbLdGrgvZBw7DV7DS+T/hZHrn0zuFilzzIgO2iy4TO3di 4K4v6yBPrNdgn5AZ8qqzGeDNFFsbT3Cz9kRdl55LPy+IfPPdwIVceFENItVK3qIg9M3xA36Q3F1g 0nL7eIX/4/ZvviOckLVO2MBuRGWp0jZZzysgRVaD3/tGPN5oQO1HvuGFbnlH+++IDkNQ/okp2DBo nj9jOX4K8s3y+rzt//v2D4paqWl5fvn+88XL5TWF6FYTJH7NUPNTsNP1hmZVCJ2jxFqiPBelA9jJ 3eNq4mD4LZIp0YlPH9kdqwQvxZg+QHGpDVZW757+oOu6WX3jqREbTl/l+SXpmvM0f7hJd+J9wwph dsRh8o3r1rSCUWdwkgfr6vcrkKebVSkMDOS5EUSLaO6MYBJMpij5MES37a/dhgNYwWQa4w62hft0 0phcqt8wWmSZzbRD+cEEpu7O+CqKXFJ/tHrI7gt5JxidSVX7g+eX/mefTuV3ioP54MXb8wsPM2I8 pfanKNCmfrrj48nF62G4HMb+in6fTDHqUTyZA/RgwxuvZKJ4RQ6qf8WEZoD6V2XP8FNZPlMqXESJ Uyrq1JlhAOyv3YYDKBVNOqXmPr1tigJk1Tu0r9z5o3ko1EMoFoVBe9aLx0Nujs5ujmnoyzKFhe3w KnMTElIIuK7sdg3/0Jh4uuR+4HeZo7lmMm1cx7bF5vp54SrGdXr00ZLtbIWnsrYd1G5aN6pqi93I QTyJiUjptmwz+OyGuUK15abbvgzR3FmoQ7id278V8DzM0QWD8YmhYWMPw0ijDbl3mkRZFzZAW9Md tBpjBlMc3aAFOX60o0E0BwvBlMAcYbch6DaXhZ087Np62pi2AoXXuD+J7PzhDrIzT7UbBLsTlT1I yQ1mzm7qsAMhW8mNY6tTCvOiQEty5Fq6cQi7VazOh9CU9f20aLLWpBik0w28291I/yejPr3HeL3h auwiDyeivaggjRdrx5SdXMFWie63Fs6p7aXIDVbuLIzKqx3uXeJO1W0vff8FOlEJBmVuZHN0cmVh bQplbmRvYmoKOTIgMCBvYmoKMTQ5MQplbmRvYmoKOTAgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL01l ZGlhQm94IFswIDAgNjEyIDc5Ml0KL1BhcmVudCAyIDAgUgovUmVzb3VyY2VzIDw8IC9Qcm9jU2V0 IFsvUERGIC9UZXh0XQovRm9udCA8PAovUjYgNiAwIFIKPj4KPj4KL0NvbnRlbnRzIDkxIDAgUgo+ PgplbmRvYmoKOTQgMCBvYmoKPDwvTGVuZ3RoIDk1IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicpVLLbtswELzrK/boArFKyoJMHxOgh5yKpAJ6ZsiVzUIiaZJq6n5vPqRL+VEpx0Q6 cEDuzs4MyUpeAcv/FaihOBZHEOUmf9PWHKsBHtri63MDVN92BYd13ubA67pkNYetqMoa2mFlv7S/ im2ZWVu98oOP65hOPcKAMo4BB7QJAsaxTzGXVoKV4lz8XSX3ggEqxlg++tbCU/FEun4WAgRjMNC6 o7UvasFnSEzoUNiPOGCknzWbmqjF2cLzm4lvFu07DZwJdpExwfP8Da/4HH5KC692ZUNpXpU82s6F QSbjrOxhDfjHG8oO7n0wfc6Jv9NY8/qqcYKXjCrG5/BTGutdU4qZxu1CwgcIK06eWQPbujkzpgOC cv4UzP6QwLpkFIIL9Go6DGgVBZAc5KpHmzBYTPDDKYPplKscHYSsicE6T9KrW5ULe2nN3ynPeEdp KvQJZASLqFEDhT3R+jF4F2lmt+DR+Bt7543d/x8ck7RaBh3BWHg9GHUAJal1oglOoR7zhRHzgupm L4LGzlgaTv1LSzfmiSdGGMaY4AUXRJ3re/eK+i5bJycBjyM9ET0lFKSNvUwIJhF9covOyzwaTk9L B9lRPmPyYypnF/oPUr4dmWVuZHN0cmVhbQplbmRvYmoKOTUgMCBvYmoKNDY1CmVuZG9iago5MyAw IG9iago8PAovVHlwZSAvUGFnZQovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUGFyZW50IDIgMCBS Ci9SZXNvdXJjZXMgPDwgL1Byb2NTZXQgWy9QREYgL1RleHRdCi9Gb250IDw8Ci9SNiA2IDAgUgo+ Pgo+PgovQ29udGVudHMgOTQgMCBSCj4+CmVuZG9iagoyNyAwIG9iago8PC9UeXBlL0ZvbnQvTmFt ZS9BL1N1YnR5cGUvVHlwZTMvRW5jb2RpbmcgMjYgMCBSL0ZpcnN0Q2hhciAwL0xhc3RDaGFyIDYx L0NoYXJQcm9jczw8L2E2MQo4OSAwIFIvYTYwCjg4IDAgUi9hNTkKODcgMCBSL2E1OAo4NiAwIFIv YTU3Cjg1IDAgUi9hNTYKODQgMCBSL2E1NQo4MyAwIFIvYTU0CjgyIDAgUi9hNTMKODEgMCBSL2E1 Mgo4MCAwIFIvYTQ4Cjc2IDAgUi9hNDYKNzQgMCBSL2E0NQo3MyAwIFIvYTQ0CjcyIDAgUi9hNDMK NzEgMCBSL2E0Mgo3MCAwIFIvYTQxCjY5IDAgUi9hNDAKNjggMCBSL2EzOAo2NiAwIFIvYTM3CjY1 IDAgUi9hMzYKNjQgMCBSL2EzNAo2MiAwIFIvYTMzCjYxIDAgUi9hMzIKNjAgMCBSL2EzMQo1OSAw IFIvYTMwCjU4IDAgUi9hMjkKNTcgMCBSL2EyOAo1NiAwIFIvYTI3CjU1IDAgUi9hMjYKNTQgMCBS L2EyNQo1MyAwIFIvYTI0CjUyIDAgUi9hMjMKNTEgMCBSL2EyMgo1MCAwIFIvYTIxCjQ5IDAgUi9h MjAKNDggMCBSL2ExOQo0NyAwIFIvYTE4CjQ2IDAgUi9hMTcKNDUgMCBSL2ExNgo0NCAwIFIvYTE1 CjQzIDAgUi9hMTMKNDEgMCBSL2ExMgo0MCAwIFIvYTExCjM5IDAgUi9hMTAKMzggMCBSL2E5CjM3 IDAgUi9hOAozNiAwIFIvYTcKMzUgMCBSL2E2CjM0IDAgUi9hNQozMyAwIFIvYTQKMzIgMCBSL2Ez CjMxIDAgUi9hMQoyOSAwIFIvYTAKMjggMCBSL2E1MAo3OCAwIFIvYTQ5Cjc3IDAgUi9hMgozMCAw IFIvYTUxCjc5IDAgUi9hMzkKNjcgMCBSL2ExNAo0MiAwIFIvYTM1CjYzIDAgUi9hNDcKNzUgMCBS Pj4vRm9udEJCb3hbMCAtNDQgNjAgMTAzXS9Gb250TWF0cml4WzEgMCAwIDEgMCAwXS9XaWR0aHNb CjAgMCAzOSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNDggMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwCjAgMCAwIDUxIDAgMCAwIDQzIDAgMCAwIDAgMCAwIDAgNjAKMCAzNyAyNiA0MSAw IDAgMCAwIDAgMCAwIDAgMCAwXT4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlL0ZvbnQvTmFtZS9S MjEvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9Db3VyaWVyLUJvbGQvRW5jb2RpbmcgMjIgMCBSPj4K ZW5kb2JqCjIyIDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjMyLy5ub3RkZWZd Pj4KZW5kb2JqCjYgMCBvYmoKPDwvVHlwZS9Gb250L05hbWUvUjYvU3VidHlwZS9UeXBlMS9CYXNl Rm9udC9Db3VyaWVyL0VuY29kaW5nIDcgMCBSPj4KZW5kb2JqCjcgMCBvYmoKPDwvVHlwZS9FbmNv ZGluZy9EaWZmZXJlbmNlc1sKMzIvLm5vdGRlZgozOS9xdW90ZXNpbmdsZQoyMjgvYWRpZXJlc2lz XT4+CmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjMgMCBSCjggMCBSCjEx IDAgUgoxNCAwIFIKMjMgMCBSCjkwIDAgUgo5MyAwIFIKXSAvQ291bnQgNwo+PgplbmRvYmoKMSAw IG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMiAwIFIKPj4KZW5kb2JqCjk2IDAgb2JqCjw8 IC9DcmVhdGlvbkRhdGUgKEQ6MjAwMDEwMTcwOTEwMjcpCi9Qcm9kdWNlciAoQWxhZGRpbiBHaG9z dHNjcmlwdCA1LjUwKQo+PgplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL1hPYmplY3QgL05hbWUg L1IxNyAvU3VidHlwZSAvSW1hZ2UgL0xlbmd0aCAxOCAwIFIKL0NvbG9yU3BhY2VbL0luZGV4ZWQg L0RldmljZVJHQiAyNTUKPDAwMDAwMDExMTExMTIyMjIyMjMzMzMzMzM3MzczNzQzNDM0MzQ0NDQ0 NDRhNGE0YTRiNGI0YjUyNTI1MjU1NTU1NTU5NTk1OTVkNWQ1ZDY2NjY2NjZlNmU2ZTc3Nzc3Nzc4 Nzg3ODc5Nzk3OTdkN2Q3ZDgxODE4MTg4ODg4ODhhOGE4YTk2OTY5Njk5OTk5OWEzYTNhM2FhYWFh YWFmYWZhZmJiYmJiYmNjY2NjY2RkZGRkZGVlZWVlZWZmZmZmZjAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMD4KXS9XaWR0aCA0NjcvSGVpZ2h0IDM4My9CaXRzUGVyQ29tcG9uZW50IDgv RmlsdGVyL0ZsYXRlRGVjb2RlL0RlY29kZVBhcm1zPDwvUHJlZGljdG9yIDE1L0NvbHVtbnMgNDY3 Pj4KPj4Kc3RyZWFtCnic7d1tQ6JaG4bhGzSt1F6sdjWW/v+fZWbOHhvTTB/fgAcETcVmL5GGxeV1 fqipjNZ4BMICzahJpJ4vM9lo37lsnN9zASLvZ3svIoZRaDGMsbzfB/80Ipp2ynuOQWS27y+FyKCg wyg0GcaSJKpp92LvMdjm3ouY5HQYhSbDWJJENY3hVzOG4ljJYkiPYSxJaBpDegxjb1M9/htspSUJ TWGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5ri RVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYum eNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5riRVO8IpmuOtJUu5RMndehnF4biw+7vZXb0lS7lEzb 44rzUlz8ZTfrWWiqc0qmT3c5mfwO/qqm81zieqp1Sqb1qiHOU3CDjpTrNNU5NdPa4o3I6LVi0FTr djW1/70zZNW0k89kJWN88Z3s72bbMpapyt+0Xdn2dnvzz5wv/zox11PtUlpPW1cr+0giwm2v1imZ uo+h0rw+Xn5MU61Tm0dyt7jzrW2ASVOt43wvXjTFi6Z40RQvmuJFU7xoihdN8aIpXjTFi6Z40RQv muJFU7xoihdN8aIpXjTFi6Z40RQvmuJFU7xoihdN8aIpXjTFi6Z40RQvmuJFU7xoihdN8aIpXjTF i6Z40RQvmuJFU7xoihdN8aIpXjTFi6Z40RQvmuJFU7xoihdN8aIpXjTFi6Z40RQvmuJFU7xoihdN 8aIpXjTFi6Z40RQvmuJFU7z2Nh3kjUxso2H7N5PZ4i/Vcj2FidtevGiKl66mtj1/Z5rfsnTsdDUN FsutQIRoihdN8QqZOsP3iZjHpeMvv+WLBcQbTaO3adrtl4pZcayPj2s1VZpq14Zp6+TcCD4xGN7s tIB4o2n0NkztlWMHW+k4gqbaFXo8bZfyxpe3/tMC4o2m0QuZdvt2qZiLsIB4o2n0thzLWP2+U1Rm pal2bT8+HbyKWTpX2gbTVLvCps7040OKRftN7ndawLeMi6YRCu8jDY1gw1tXmlmiqXaF95FKmc0v qS0g3mgava/me9tlxStSaKpdIVPrxT9zqTqlT1PtCj+eHl108gX37a4LiDeaRi9kWq8ag+mF03zY dQHxRtPobTOdte8Vd3qFphoW3vZK2Wg8SLO66wLijabRC58Tfz266PbklufEUxuvXcGLpnhtmNaX X+A+UmrjeorXtvOnzvhU/VIHmmrXlv3eoUil9UP1CYg01a6QaWf4w6zXulOliwaFphq2bR7Jm0Ti PFJ6C5s+mi6o80TT1LZl23uX5bY31YX3kX5ODMd0KtxHSm3bjmWmo2JG+WCGptrFOQe8vpobPOd1 DqktfD3Sr6ucWK0iTVNbyLRR8Z7OZj/znHhq2zrn4O798vg0vYVMW9Y/ObG7Y6UnVghNNSx8fPo2 sMUsXKoezNBUu3gsgxdN8dowbd0s78TRq9Jl2zTVrg1T5214eZzxXkunr/iQSlPtCm177ff/TcQ4 OjtRfPVGmmoXH0/xoileG6bWi23e7vBKOjTVsA3TdqY86DxGWkC80TR6m+faHk31qd71BcQbTaO3 aVpTfb2V0ALijabRoyleNMWLpnjxuYp4cc4BL5ripWTqPX/x9No/TWN1Pv+9toBvGRdNI6Rk2h5X nJfg6tCn4qW8rVytRFPtUjKtV7Iy+T13nDWrxtpVhTTVLjXTT0fHcr/BbtBU49RMa7J62Gq/nJbD C/iWcdE0QrubOr33k5V9pE4+kxX1p8HtOC6a7pZty1imi+fFKG57xWrJ3eodzfVUu5TW09ZVbrGP JI1Cee1rNNUuJdPRa0Wa/t/km7Sq69tZmmqX2jxSt+c/IbVec//lxf1ejePcIF40xYumeNEUL5ri RVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYum eNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5riRVO8aIoXTfGiKV40xYumeNEUL81NR/67+F/zGTnN Tbm6RoimeGln6kxN7924sLp0mu6SdqbBArmeRo+meNEUL5riRVO8aIoXTfGiKV40xYumeNEUL5ri RVO8aIrX3qaDvJGJbTReNN2vmcyOg39yPYWJ2168aIoXTfGiKV40xYumeNEUr3SYDvLeWzsX848C LR2ma59j/xFN8aIpXjTFi6Z40RQvmuJFU7xoihdN8aIpXjTFi6Z4pcrUv0HM157ilSpTnkxViqZ4 0RQvmuJFU7xoihdN8aIpXjTFK4Wmk/kL/IppxvyDYUqhKVfX/4imeNEUL5riRVO80mvKPyf0Vek1 5er6VTTFi6Z40RQvmuJFU7xSb+q/fIdQ9rPUm659iXnRFC+a4kVTvEBMg2sf+EpnXiCmPLBZiaZ4 YZkG598O/NmMWKZcXb1oihekqT9fOC7EPLK0BGl64MesyKbB8hZ/6epgQjb1PwimIw5oXxjf9PD2 mw7GNDh0HR/AX0vY2dR5Hcrp9edFtYO49y4jmQajUP4VCH7W9/w+Jt2SRNW0Pa44L8WL8ALi6q+Y rq27H0XvrR3D425KTev3OZn8vl9+3L34w43VsteeSRrJNBjFPpvqib89Dnap1m+hSjXZf5tu7/+0 2iWJsql7O+fp88ad8t5jWP/tjmQajGIf022r+vqm2n8sDj5n26tLCiQ+9v8Fj2FVX5LsYuq/2VhA 9PQ3VV1S68Z7G9hve7f+uW2L8B8IFr84wWnh1XfbPrf+pbf5KCS6aTsjecnbU7Xv/q6mR8n+/KDE hzG1ZSzZnU2rxtq2l+mbqmnran0fiembqunotSLN64ObQ01lyvNI3Z6c7797x/5CUecGmb6l2NQ6 nFMuuxXJdHPyN5H8vfBkh2J1/J+e8B1itSw5LWcWw4hkujn5m0Szt2Et8aE8FS/lbXyf8CicxtmF szKMSKZPd8kf2LRkUkt6KLNmcNSe7B0yawYTQsEwIpnqMQHhT20lORTHyorYjZoOd8io/bgYRjTT jYnCZPocRZJDsV9Oy8mPott3KpnFMGi6V07v/cTdN0r8DrGmr+7D+V6myW9qRIdtr7vDKXfZxEcx b+UhIJKpHpO/c9Nkh9Io+Cf7kh1F9+NB5ndHMIxIpnpM/s5NEx3KpFX1j0mTvUOs5+uC05veLIYR bR5Ji8lf//EryaG4P9urlvQdMmrb/pSHP4wUzw2yL6IpXjTFi6Z40RQvmuJFU7xoihdN8ToQ05Vz JttPn9S3zwO1JpK+O4imf/rsn76gb/imzs+J+eO5Js5bX0qX83Od82uxypnu9EZk/sana/3zYudu u33zPiuW+887Q2iqZZ1hxfl3UpOW9cNo5m88pLZcS6//aD1XDWnczE+neHT13K3xNiiUu/1HaZQu RqMLoamWNW5zMmnVrOdKVuzGQ8ZF6pYyi2uy5q4SmD6a4jy5b9wPvI9Hx0JTLQsu6Bj9qnrvK1nv Y9sej/s16Ui5a5eXt1pegeKdXpbLnLn89nR1MKbBuc7rgree9nInR681mfysemvx4larpk7vwzrn tlfTGhVTrOfarPXofjDLGN6G9cHf9srT1e+qf6sNU9vJzK/woamWdeTSebFqTuPs3PD2fnxTd9fX /Z93+qXgNQw2TEe/HkyrWRWaapl7LGOcyYX/3Jby/CLY0S8nU+yd3rj7TvfBS6ZsmHoHPuYN95HS lpWZX7zuxzkHlFoniwlBmmI0a/pTRV6c72U6R1O8aIoXTfGiKV40xYumeNEUr/8D+ij7WQplbmRz dHJlYW0KZW5kb2JqCjE4IDAgb2JqCjI4OTAKZW5kb2JqCjE5IDAgb2JqCjw8IC9UeXBlIC9YT2Jq ZWN0IC9OYW1lIC9SMTkgL1N1YnR5cGUgL0ltYWdlIC9MZW5ndGggMjAgMCBSCi9Db2xvclNwYWNl Wy9JbmRleGVkIC9EZXZpY2VSR0IgMjU1CjwwMDAwMDAxMTExMTEyMjIyMjIyODI4MjgzMzMzMzM0 NDQ0NDQ0NjQ2NDY1MzUzNTM1NTU1NTU1OTU5NTk2NDY0NjQ2NjY2NjY2ZDZkNmQ2ZTZlNmU3MTcx NzE3Nzc3Nzc3ODc4Nzg3OTc5Nzk4MTgxODE4ODg4ODg4YThhOGE4ZDhkOGQ5MzkzOTM5Njk2OTY5 ODk4OTg5OTk5OTlhM2EzYTNhNGE0YTRhYWFhYWFhZmFmYWZiYmJiYmJjY2NjY2NkZGRkZGRkZmRm ZGZlZWVlZWVmZmZmZmYwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA+Cl0vV2lkdGggNDgyL0hlaWdodCAzOTEvQml0c1BlckNv bXBvbmVudCA4L0ZpbHRlci9GbGF0ZURlY29kZS9EZWNvZGVQYXJtczw8L1ByZWRpY3RvciAxNS9D b2x1bW5zIDQ4Mj4+Cj4+CnN0cmVhbQp4nO2dfVvayB6GJwLFwqnQI71wtcUVvv9HAmoqLqx4FuoF FROYkwTCi2boTIhu8vjcf8SEzG8m8WZeMglgtQTBxqJidKgYHk3F8vZRHJ9bwbo72KyT9KOpuOc2 FjflWrDeKdXF4KnxmkdFEkRTceeiKGaDQKtjNy0hO2zgs4Km4vZGq3QLQsy/U3FW0FXcChcB85vi 2XrfPKcIkqr+OsGINylEGZGJc4+jWN7/LG4Nt7ofxbEoRwRNol70uT9V7DCPeJNClBFvUojZuTtP 4lHsjJTMG2rh9sR5YWtf/yw6RjgFxY5RNbGINylEGfEmhcQ49x0lmort+nq45dXaXafDmiJI2cLM iolFvEkh6qbyLQqJce47SjQVT+8awv5SCkq8ae52Aep3mQp1rUguAqeQGIe1o0R3dms4FhX/rdFu eWs+mzgqTltEPMXJHgJ5XXaUUDEiVAwPFcNDxfBQMTxUDA8Vw0PF8FAxPFQMDxXDQ8XwUDE8VAwP FcNDxfBQMTxUDA8Vw0PF8FAxPFQMDxXDQ8XwUDE8VAwPFcNDxfBQMTxUDA8Vw0PF8FAxPFQMDxXD Q8XwJK14VLbyB2dCEkO6YrH9VV2sxYiwoYaHiuGhYnioGB4qhoeK4aFieKgYHiqGh4rhoWJ4qBge KoaHiuGhYnioGB4qhoeK4aFieKgYHiqGh4rhoWJ4qBgeKoaHiuGhYnioGB4qhoeK4aFieKgYHiqG h4rhOUCxG/WlHlScOkwUy9tHcXxuhVsdP/Vw7C0qtej8SBowUdxzG4ub8kqn8/ejn7qfr+2koeLU YaK4c1EUs0FjuWELx09tn1TV+ZE0YKK43bRWzfNy01/rlKZyq52m4vRhpLgVLrY2C982jffz/Ega OFCxdPOWcH9crdP0jz8URN6KCidvjisXv4TY7kpjNNTP1liL04dJLbbrW8OtpVhn4r1FZLcZnR9J AyaKp3cNYX8phZu+Yvf6tCoHefbFKcZodms4Xs5yLBvmYDl8WIhyfdP3UnHq4Bw1PFQMDxXDQ8Xw UDE8GVPs+ItJ9XfJyBZZU1x4/TLQoGJ4qBgeKoaHiuGhYnioGB4qhoeK4aFieKgYHiqGh4rhoWJ4 qBgeKoaHiuGhYnioGB4qhoeK4aFieKgYnkwq9tcWxVctCIhMKmZVNoGK4aFieKgYHiqGh4rhoWJ4 klY8KltRX1OdFFRsiHR3ZxBYixFhQw1PdhUH20e5Vy0OguwqLrxBcRBQMTzZUbz5sh4qNiJDigsv F1SsARXDQ8XwUDE8VAwPFcNDxfBQMTxUDE+0Yjn+6YijD59LUSH6+SUKFcckUvHw4VOlIKQ7nnwx lUzFqSNKsV06DX94aTS5OCC/RKHimEQpnm/dhJ0b3pCl4tQR3Rf3Pn+M+eOlVJw6ohUPHxblz7E+ F0bFqUN10eSOHmQphmUqTh17rotH9+Lo06lhg/22iuW47C35i9h7USiWT/9MRenzfCgaEUG6+SWK uhazKu9FMdx6tFatdNtwwouKU4diuFXNR+03zS9RqDgme+eoe3XjD69QceqIVuz+WAR/zW9LUHHq UPTFxVr/uOotD8svUag4JtGK201r5NakfXlYfolCxTFRKnb+ahgPp5/nlyhUHBNFQy3q1vdLYTcP yy9RqDgmikcCbou14Vj8kY1HAqh4L3svmg7NL1GoOCZUDE+U4vb6BS3l7vb8CBWnjji1WN4+iuPz 8PaO7GxHUXHqUN4vlpOK6h5dz20sbsqraRHn70cqTjWqEfWjEI2bb9FT1J2LopgNVncZbeFQcaqJ Vtyffc21W8NZ9OOX7aa13Ty3qTjVKGe3fHOK2a3g5TYVZwSF4j9znrndgdSGfYr7xx8Kr/OkDRWb 48rFLyGqW69sNdTnBTbUICiGWz8cSx7JRvRwy65vDbeoOO0oL5qephVVezu9awh782mnf13xyH8M 81W/XTXTxJrAHI5Fxb8sXsr91xWzKu9l7wRmJUNPfVCxiuha7N563a3bK1MxANGKuw3/A4nz6ww9 EkDFKtRTH89vMMTIL1GoOCbRim15VhTzuyfDT7s8zy9RqDgmiuviwa+FOPpYN5+louLUEeuiSTe/ RKHimFAxPFGK7T/WL07vDJ+Wp+LUEaVYDmaV/+T9L2V6MO6OqTh1RDfU83+mjrDyJ5+Mf0CFilMH +2J4qBieKMXuj8XReayvZKLiFBKluJc7G/1zlUB+iULFMYlS3P4zF2d6+mV+iULFMYlU3DL/pp7I /BKFimNCxfBQMTxUDE+k4vULfCQAAE59wEPF8FAxPFQMDxXDQ8XwUDE8VAwPFcNDxfBQMTxUDA+M Yn4bhAoYxazKKqgYHiqGJ2nFo/Jr9YdUHAfpisX2I/GsxYiwoYaHiuGhYnioGB4qhoeK4aFieKgY HiqGh4rhoWJ4qBgeKoaHiuGhYnioGB4qhoeK4aFieKgYnkwodqW3mFQFFcchE4qjRFKxLlQMDxXD Q8XwUDE8VAwPFcNDxfBQMTxUDA8Vw0PF8FAxPFQMj4liefsojs+tnfXh2Nuo1KLzS/QgqTgmJop7 bmNxU67trPfztZ00VJw6TBS3vxbFbNDYWbdPqur8koKKD8FIsbc7/EnUcL1TmsqtdpqK04ep4vCX 9sL1duHbuvF+kV9SUPEhHKhYunlLuD82v2fdP/5QEHnrFQ6Sis1x5eKXENtd6e8UN61NQ721vv0b mqzFqcOkFtv1zXBrte74z0XKbjM6v0QPkopjYqJ4eueNoL+Uttfd69OqHOTZF6cYo9mt4Xg5y+E3 zKv14cNClOubvpeKUwcnMOGhYnioGB4qhoeK4aFieKgYHiqGh4rhoWJ4qBgeKoaHiuGhYnioGB4q hoeK4aFieKgYHiqGh4rhoWJ4qBgeKoaHiuGhYnioGB4qhoeK4aFieKgYHiqGh4rhoWJ4qBgeKoaH iuFJWvGobOUPzuQ5VBwb6YpFcWubtRgRNtTwUDE8VAwPFcNDxfBQMTxUDA8Vw0PF8GApHpW9xVHu FQ4hw2ApZlWOgIrhoWJ4qBgeKoaHiuGhYnioGB5AxcH8xys8QZZVABXT8y6oitlkr6FieKgYHiqG h4rhgVbM28c+0IpZlX2oGJ60K3alt5hUBRXHJu2Kf2NOw+40SPiOPeMrfvdV+Z0ofs9V+Z0o3nh+ f9dQ70nxO/X87hRvPE/eyf3GQxXL20dxfG6tt0fVg44geu+zxWh9DaXtdKS67ApkL478vHaPI8Z7 1TzkLSJ2lcRQ3HMbi5tyLTo/Lf5dxZvFzPcc1Oxg8/7M9ERQFbe/FsVs0FhvD2uKhHNV9zcrKnYE EVEygjIiFQd57Q/RjeifeotxJdwMKnrw9UbBYc0XfunPuvRhJVwLUjvrXj/muRtFqEN2lMRR7IXI ziaur3rzK99+ynqvrG9BGZGKlZV1E3JQhF/kve8+mG+T43WdD2r/vaqQmOduFKEO2VESU/FyEZGf 1hFkSfH+biIqJOjrg3fFpmZvFn/9sbO5GQ6kWXEvJ47Fx6OXCRcRr+3f4TwpdrjKUbByT4I71CRT yIfNADAC5Y7IPc6T64qT0tYrcRQ3rZ2GmqSbGIrt+u5wi6SbGIqndw1hfyn9PiFJBXFmt4ZjUVFd KJHUkcAEJkk3VCziDKXDCIPI+IXEiNi+nDpI8fCnzF/kX0xaq3Hs4E+lph8SpDzLGRQSptSOWF4e mISFFxS7kRoh7sC0ELfniuO63j95fZ0zHLc2h3WI4uHka67/6+rFpPVvcO0rSz/ELtXk4KlhUEhf 1Be9D2faEc7fj/4/IUyuEbaKeB6pEdIp1YXm2SwjZKeiff7hYQn3WrQ2h3WIYn+yWt6fWp0Lo6uo 67Pii3nuPYWsJlr0C+lcWWJ+c6kdYQsn+O+vkmuErSKeR/4+xLFXcwrahTj26vw1/mPhYcnvn/xa HEYcpHgVazYXMpw2Xs5zq7FLp9boZ8OgkPBNYRqxSq4Vtj717cjfh0jX6yPn3w0LEdPBld5/bBnR F2f+ShhxkOLyVBa+WS9mNPciu5e5l5OgaubXUlhXJoUETfukZRCxSdnWDNtVrFVQmGB+UzwzKmT4 IBt5g4jpXcMKFfuLwxTXrf78wkzxcHYhTBT3cl7vla8ZRLi3jlVKq2J5/7N4rvmGXe13n+7Kmufv 75/3VrUuEcUmTVuI3wuZtO3tP73RdLdpOjOezobaGx+L84JuyFqoUdM+HAerlVoYcYji7p/LPEwm rWc3y4GKdkj4XtSOCPq72e2VaRlhcq2wHcV6BQVJux+Xt/m0CxlOLoX++a/fFP5KGHGI4qANFWdG k9Z+wy5M5rntD14hXpB2hOye1IL+Tr+MsAsLkmuF7SjWK8hPOrtpLq9stQtxr0+r8n6mef47isOI QxT7V+Ved2w0ad39vLzBrR2yvuTXjpjdLqyTU5OI5X8mTK4TtqNYr6CtRrRlUMh0sNA//x3FYQQn MOGhYnioGB4qhoeK4aFieKgYHiqGh4rheX+Kt+7WRN+4aUfPItmOyOb/ior3JdDckW7elWL5wzn6 dt0ScjAJJtc9Z8EUeD0f3MVe3spe3qU5/7EoXNxNjr4WhOutfrMEFWeB/qyx6DktYcuvR3Y+eJah J87F/cOVe920RLce3MgJbqcXLo4Gvz6eDR+uRPdTbTqtCSrOAt3zon/D2r1uFMT8+2Xeczas5sOn /wLNYqXYfxCh4y1Wj4FMS4KKs8Dq8YJpv+n/bRSC52AWk8dJy3+kbeierVOtH6Pxb8aLWjG3Ds8e 71Hx6q7tadWvxeNCKX/fErNe06/jYaptxfJ+4lbYUGeDbiMn3OuWc3PlbTh5/znF9uWyoRad//6v uUz1TPFc5oOHp6g4C/ifk7hxW7J7cmr5A6mlYm9Q7f0T+pPy6tsTnime9i9zrt0UVJwFvIsm60TU lp8sqgfPJk/7Ml8eH194w7Cvq2/GeabYv8I6qnO4lXHcfPCJgyWc+gDFLoWzllQMiWMvJ7B8OEdN MgYVw0PF8FAxPFQMDxXDQ8XwUDE8/wcjY3LeCmVuZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKMzc2 NwplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9EaWZmZXJlbmNlc1swCi9hMC9hMS9h Mi9hMy9hNC9hNS9hNi9hNy9hOC9hOS9hMTAvYTExL2ExMi9hMTMvYTE0L2ExNQovYTE2L2ExNy9h MTgvYTE5L2EyMC9hMjEvYTIyL2EyMy9hMjQvYTI1L2EyNi9hMjcvYTI4L2EyOS9hMzAvYTMxCi9h MzIvYTMzL2EzNC9hMzUvYTM2L2EzNy9hMzgvYTM5L2E0MC9hNDEvYTQyL2E0My9hNDQvYTQ1L2E0 Ni9hNDcKL2E0OC9hNDkvYTUwL2E1MS9hNTIvYTUzL2E1NC9hNTUvYTU2L2E1Ny9hNTgvYTU5L2E2 MC9hNjEvYTYyL2E2MwovYTY0L2E2NS9hNjYvYTY3L2E2OC9hNjkvYTcwL2E3MS9hNzIvYTczL2E3 NC9hNzUvYTc2L2E3Ny9hNzgvYTc5Ci9hODAvYTgxL2E4Mi9hODMvYTg0L2E4NS9hODYvYTg3L2E4 OC9hODkvYTkwL2E5MS9hOTIvYTkzL2E5NC9hOTUKL2E5Ni9hOTcvYTk4L2E5OS9hMTAwL2ExMDEv YTEwMi9hMTAzL2ExMDQvYTEwNS9hMTA2L2ExMDcvYTEwOC9hMTA5L2ExMTAvYTExMQovYTExMi9h MTEzL2ExMTQvYTExNS9hMTE2L2ExMTcvYTExOC9hMTE5L2ExMjAvYTEyMS9hMTIyL2ExMjMvYTEy NC9hMTI1L2ExMjYvYTEyNwovYTEyOC9hMTI5L2ExMzAvYTEzMS9hMTMyL2ExMzMvYTEzNC9hMTM1 L2ExMzYvYTEzNy9hMTM4L2ExMzkvYTE0MC9hMTQxL2ExNDIvYTE0MwovYTE0NC9hMTQ1L2ExNDYv YTE0Ny9hMTQ4L2ExNDkvYTE1MC9hMTUxL2ExNTIvYTE1My9hMTU0L2ExNTUvYTE1Ni9hMTU3L2Ex NTgvYTE1OQovYTE2MC9hMTYxL2ExNjIvYTE2My9hMTY0L2ExNjUvYTE2Ni9hMTY3L2ExNjgvYTE2 OS9hMTcwL2ExNzEvYTE3Mi9hMTczL2ExNzQvYTE3NQovYTE3Ni9hMTc3L2ExNzgvYTE3OS9hMTgw L2ExODEvYTE4Mi9hMTgzL2ExODQvYTE4NS9hMTg2L2ExODcvYTE4OC9hMTg5L2ExOTAvYTE5MQov YTE5Mi9hMTkzL2ExOTQvYTE5NS9hMTk2L2ExOTcvYTE5OC9hMTk5L2EyMDAvYTIwMS9hMjAyL2Ey MDMvYTIwNC9hMjA1L2EyMDYvYTIwNwovYTIwOC9hMjA5L2EyMTAvYTIxMS9hMjEyL2EyMTMvYTIx NC9hMjE1L2EyMTYvYTIxNy9hMjE4L2EyMTkvYTIyMC9hMjIxL2EyMjIvYTIyMwovYTIyNC9hMjI1 L2EyMjYvYTIyNy9hMjI4L2EyMjkvYTIzMC9hMjMxL2EyMzIvYTIzMy9hMjM0L2EyMzUvYTIzNi9h MjM3L2EyMzgvYTIzOQovYTI0MC9hMjQxL2EyNDIvYTI0My9hMjQ0L2EyNDUvYTI0Ni9hMjQ3L2Ey NDgvYTI0OS9hMjUwL2EyNTEvYTI1Mi9hMjUzL2EyNTQvYTI1NQpdID4+CmVuZG9iagoyOCAwIG9i ago8PC9MZW5ndGggMTUxID4+CnN0cmVhbQowIDAgMCAwIDI3IDUyIGQxCjI3IDAgMCA1MiAwIDAg Y20KQkkKL0lNIHRydWUvVyAyNy9IIDUyL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAy NwovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoaP///////////////kceH4fh+/D8cPD3h73ve97+4AI AIAKRUkKZW5kc3RyZWFtCmVuZG9iagoyOSAwIG9iago8PC9MZW5ndGggMTIzID4+CnN0cmVhbQow IDAgMCA0NCAxNCA1MiBkMQoxNCAwIDAgOCAwIDQ0IGNtCkJJCi9JTSB0cnVlL1cgMTQvSCA4L0JQ QyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAxNAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmpf// +ACACApFSQplbmRzdHJlYW0KZW5kb2JqCjMwIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQoz OSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iagozMSAwIG9iago8PC9MZW5ndGggMTgwID4+ CnN0cmVhbQowIDAgMCAwIDM3IDUzIGQxCjM3IDAgMCA1MyAwIDAgY20KQkkKL0lNIHRydWUvVyAz Ny9IIDUzL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzNwovQmxhY2tJczEgdHJ1ZQo+ PgpJRCAmoOUB4IHp6enp6KDfCD6TfT9N6/v163//0/////3X/////vX////f6/713+v+2l2u2l2u xW1tbW1hhZAiIAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjw8L0xlbmd0aCAxNzYg Pj4Kc3RyZWFtCjAgMCAwIDEgMzcgNTMgZDEKMzcgMCAwIDUyIDAgMSBjbQpCSQovSU0gdHJ1ZS9X IDM3L0ggNTIvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM3Ci9CbGFja0lzMSB0cnVl Cj4+CklEICaghDCwQeg8J6feigb0EH6b0n++n99K/x/ev/9Zfpd/aXDC8GCXH1tcLn0vBgux3//7 3//5Md///+ACACAKRUkKZW5kc3RyZWFtCmVuZG9iagozMyAwIG9iago8PC9MZW5ndGggMTc0ID4+ CnN0cmVhbQowIDAgMCAwIDM2IDUyIGQxCjM2IDAgMCA1MiAwIDAgY20KQkkKL0lNIHRydWUvVyAz Ni9IIDUyL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAzNgovQmxhY2tJczEgdHJ1ZQo+ PgpJRCAmv//vmgF7fe3t97e3t7ew8N7e3t7e3hvb29vfb/b37v5K3gv/f1/bXaW2vDS2Pa6w1sLB hZAiIAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjM0IDAgb2JqCjw8L0xlbmd0aCAxODcgPj4Kc3Ry ZWFtCjAgMCAwIDAgMzcgNTMgZDEKMzcgMCAwIDUzIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDM3L0gg NTMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM3Ci9CbGFja0lzMSB0cnVlCj4+CklE ICaghDCwQeg9PT09FA3oIN9PpN/9P/03Xkccf+utddLCWQwM64XC77yGgjBvfb3/Irvmn//7a/9r tpdrsVtbW1sLDCyDEQAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjw8L0xlbmd0aCAx NjcgPj4Kc3RyZWFtCjAgMCAwIDAgMzcgNTEgZDEKMzcgMCAwIDUxIDAgMCBjbQpCSQovSU0gdHJ1 ZS9XIDM3L0ggNTEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM3Ci9CbGFja0lzMSB0 cnVlCj4+CklEICag3Mx///////4nUN/mYOZjJqn7fv9+37/ft+37/ft+/37fv9+37Hv++/77/vvv +8AEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago8PC9MZW5ndGggMTkzID4+CnN0cmVh bQowIDAgMCAwIDU4IDQ3IGQxCjU4IDAgMCA0NyAwIDAgY20KQkkKL0lNIHRydWUvVyA1OC9IIDQ3 L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAm oE+CwWFgsLBYLCCwQLCBYILBAsILBcIiFwQXggXhAvQXwXwXwX/wfw/g/YPww/DB+DB+GPB8Pgwe GDww8GDww8GHDweHg8PDwcAEAEAKRUkKZW5kc3RyZWFtCmVuZG9iagozNyAwIG9iago8PC9MZW5n dGggMTkxID4+CnN0cmVhbQowIDAgMCAtNTQgNTggLTUgZDEKNTggMCAwIDQ5IDAgLTU0IGNtCkJJ Ci9JTSB0cnVlL1cgNTgvSCA0OS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTgKL0Js YWNrSXMxIHRydWUKPj4KSUQgJqP///kgNfB8HweweDB4MHgweDDwYPBg8GDwYPBg8G4PB4P4LBYJ YIFggWCBYILBAsECwQLCBYIFggWEC4XBcqgb///gAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKMzgg MCBvYmoKPDwvTGVuZ3RoIDE3NyA+PgpzdHJlYW0KMCAwIDAgMCA1OCA0NSBkMQo1OCAwIDAgNDUg MCAwIGNtCkJJCi9JTSB0cnVlL1cgNTgvSCA0NS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt bnMgNTgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqP///88C58G///////////v/7/+/h/fd+g/vufQ frfasPbSb4YVh8U3uw+g3ae0HhoPDCeDBB4vD3ABABAKRUkKZW5kc3RyZWFtCmVuZG9iagozOSAw IG9iago8PC9MZW5ndGggMTQ1ID4+CnN0cmVhbQowIDAgMCAtNDggNTggLTI4IGQxCjU4IDAgMCAy MCAwIC00OCBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggMjAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D b2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICahnPg1fXrXS/S10tLXS0VIN4Wv/4AIAIAK RUkKZW5kc3RyZWFtCmVuZG9iago0MCAwIG9iago8PC9MZW5ndGggMTc1ID4+CnN0cmVhbQowIDAg MCAwIDU4IDM0IGQxCjU4IDAgMCAzNCAwIDAgY20KQkkKL0lNIHRydWUvVyA1OC9IIDM0L0JQQyAx L0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1OAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoG+QYwLC hYVaYWFXrVaBLgl1J1pJekvpekvpdUv19L6Xdfpe0vYS9pdsJeGEuxXrtdrsLhhcMLABABAKRUkK ZW5kc3RyZWFtCmVuZG9iago0MSAwIG9iago8PC9MZW5ndGggMTI2ID4+CnN0cmVhbQowIDAgMCAt MTggMTAgLTEwIGQxCjEwIDAgMCA4IDAgLTE4IGNtCkJJCi9JTSB0cnVlL1cgMTAvSCA4L0JQQyAx L0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAxMAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmv///4AIA IApFSQplbmRzdHJlYW0KZW5kb2JqCjQyIDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0OCAw IDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago0MyAwIG9iago8PC9MZW5ndGggMTc3ID4+CnN0 cmVhbQowIDAgMCAtNTggNTggLTI0IGQxCjU4IDAgMCAzNCAwIC01OCBjbQpCSQovSU0gdHJ1ZS9X IDU4L0ggMzQvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVl Cj4+CklEICajPgqf///8hrdyDURyGZVwXgvC8F4S8IhBeES4fopwX4QLwgvQLwgvQXoLiF1wuF1w uuuuFABABApFSQplbmRzdHJlYW0KZW5kb2JqCjQ0IDAgb2JqCjw8L0xlbmd0aCAxOTEgPj4Kc3Ry ZWFtCjAgMCAwIDAgNTkgMzUgZDEKNTkgMCAwIDM1IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDU5L0gg MzUvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU5Ci9CbGFja0lzMSB0cnVlCj4+CklE ICag3Ng1yDGhDD4QODwnD00Hp3p3p+iQK2+EHB+nboJsP39O+vr/f/3/r/XdL1rbSXtQuw0glwwS BLYo6fYrYW1sLDCwYLIF9YAIAIAKRUkKZW5kc3RyZWFtCmVuZG9iago0NSAwIG9iago8PC9MZW5n dGggMTg5ID4+CnN0cmVhbQowIDAgMCAtNDAgNTkgLTUgZDEKNTkgMCAwIDM1IDAgLTQwIGNtCkJJ Ci9JTSB0cnVlL1cgNTkvSCAzNS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTkKL0Js YWNrSXMxIHRydWUKPj4KSUQgJqCoXBM8JIZnw8goIvIEVw8ggO8jMf34b6D816D8kEm8+Fv6+r// X//+//9ff9e2l8ML9pezqvsV9e17XhhYhhYYKACACApFSQplbmRzdHJlYW0KZW5kb2JqCjQ2IDAg b2JqCjw8L0xlbmd0aCAxMzQgPj4Kc3RyZWFtCjAgMCAwIDAgNTggMzIgZDEKNTggMCAwIDMyIDAg MCBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggMzIvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z IDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICaj///yBJ3///////////4AIAIKRUkKZW5kc3RyZWFt CmVuZG9iago0NyAwIG9iago8PC9MZW5ndGggMTc0ID4+CnN0cmVhbQowIDAgMCAtNDAgNDMgLTUg ZDEKNDMgMCAwIDM1IDAgLTQwIGNtCkJJCi9JTSB0cnVlL1cgNDMvSCAzNS9CUEMgMS9GL0NDRi9E UDw8L0sgLTEKL0NvbHVtbnMgNDMKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDBDBIIiBIQeE9PT09H UnygH6CDfCfpur6++v///39d912l2uwwlwYLsVtbW1tYYWDBQAQAQApFSQplbmRzdHJlYW0KZW5k b2JqCjQ4IDAgb2JqCjw8L0xlbmd0aCAxNzEgPj4Kc3RyZWFtCjAgMCAwIDAgNDMgMzEgZDEKNDMg MCAwIDMxIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQzL0ggMzEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0x Ci9Db2x1bW5zIDQzCi9CbGFja0lzMSB0cnVlCj4+CklEICag0HBZCzh4Qd6d6d6d634fmcw+gnb+ +m/7/+3////bf/3rbb8PS7hhd2P6392sNNYdhYhqACACCkVJCmVuZHN0cmVhbQplbmRvYmoKNDkg MCBvYmoKPDwvTGVuZ3RoIDE3OCA+PgpzdHJlYW0KMCAwIDAgLTQwIDQzIC01IGQxCjQzIDAgMCAz NSAwIC00MCBjbQpCSQovSU0gdHJ1ZS9XIDQzL0ggMzUvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9D b2x1bW5zIDQzCi9CbGFja0lzMSB0cnVlCj4+CklEICahnJweQwnwQeg8J6en3oojz8LDelv1vpbe t/+t//////7/629d/vCWw9eMJb+9b1vWHrDwsHhQAQAQCkVJCmVuZHN0cmVhbQplbmRvYmoKNTAg MCBvYmoKPDwvTGVuZ3RoIDE2NCA+PgpzdHJlYW0KMCAwIDAgMCA1OSAzMyBkMQo1OSAwIDAgMzMg MCAwIGNtCkJJCi9JTSB0cnVlL1cgNTkvSCAzMy9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVt bnMgNTkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDWQwSCB4QeEHp6eno6m+ThjoIN9PpN6f+n///9 /W37S212GEthglkap/f/4AIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjUxIDAgb2JqCjw8L0xlbmd0 aCAxMjggPj4Kc3RyZWFtCjAgMCAwIC0xNiA1OCAtOSBkMQo1OCAwIDAgNyAwIC0xNiBjbQpCSQov SU0gdHJ1ZS9XIDU4L0ggNy9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNTgKL0JsYWNr SXMxIHRydWUKPj4KSUQgJqMzL////+ACACAKRUkKZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iago8 PC9MZW5ndGggMTUyID4+CnN0cmVhbQowIDAgMCAtNTYgNDMgLTI1IGQxCjQzIDAgMCAzMSAwIC01 NiBjbQpCSQovSU0gdHJ1ZS9XIDQzL0ggMzEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5z IDQzCi9CbGFja0lzMSB0cnVlCj4+CklEICamQMXB9999/kGlGDd7+//9fS/SwlkMxGTFv7//ABAB CkVJCmVuZHN0cmVhbQplbmRvYmoKNTMgMCBvYmoKPDwvTGVuZ3RoIDE2NyA+PgpzdHJlYW0KMCAw IDAgMCA0MiA1MSBkMQo0MiAwIDAgNTEgMCAwIGNtCkJJCi9JTSB0cnVlL1cgNDIvSCA1MS9CUEMg MS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDIKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqf//+DI YbKNAyqC0uutev/+/74eyLBv/e8P6JwL0C0Fpf1r1/9/33w9kWDf394eHABABApFSQplbmRzdHJl YW0KZW5kb2JqCjU0IDAgb2JqCjw8L0xlbmd0aCAxNDYgPj4Kc3RyZWFtCjAgMCAwIDAgNTggNDEg ZDEKNTggMCAwIDQxIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDU4L0ggNDEvQlBDIDEvRi9DQ0YvRFA8 PC9LIC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lzMSB0cnVlCj4+CklEICajPgqf//////////lUDf// /58FT/////////8AEAEKRUkKZW5kc3RyZWFtCmVuZG9iago1NSAwIG9iago8PC9MZW5ndGggMTgz ID4+CnN0cmVhbQowIDAgMCAtNTYgNTcgLTIzIGQxCjU3IDAgMCAzMyAwIC01NiBjbQpCSQovSU0g dHJ1ZS9XIDU3L0ggMzMvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU3Ci9CbGFja0lz MSB0cnVlCj4+CklEICagwQwy4IGQ+YQcPCd6DvTvT9EMXfBA2H0EHDem3pP6d+/r/////3/Vbf7S W2qXaS7DBIFwhFdf1wuuCgAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjU2IDAgb2JqCjw8L0xlbmd0 aCAxNDcgPj4Kc3RyZWFtCjAgMCAwIDAgNTggMzEgZDEKNTggMCAwIDMxIDAgMCBjbQpCSQovSU0g dHJ1ZS9XIDU4L0ggMzEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDU4Ci9CbGFja0lz MSB0cnVlCj4+CklEICaj///yBcjRmGXS60utf6//7/vvYfIsG/ve94OACACACkVJCmVuZHN0cmVh bQplbmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDE0NCA+PgpzdHJlYW0KMCAwIDAgLTI0IDUxIC02 IGQxCjUxIDAgMCAxOCAwIC0yNCBjbQpCSQovSU0gdHJ1ZS9XIDUxL0ggMTgvQlBDIDEvRi9DQ0Yv RFA8PC9LIC0xCi9Db2x1bW5zIDUxCi9CbGFja0lzMSB0cnVlCj4+CklEICagh4Gr/+Yq5BKn3rF5 NQQ8Bf3///wAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iago8PC9MZW5ndGggMTk1ID4+ CnN0cmVhbQowIDAgMCAwIDUxIDUwIGQxCjUxIDAgMCA1MCAwIDAgY20KQkkKL0lNIHRydWUvVyA1 MS9IIDUwL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA1MQovQmxhY2tJczEgdHJ1ZQo+ PgpJRCD/zWGkS4NBVhlECBuRICCLA5NclASSKMhCjBhyDAnIbAOQME4PINQyCyBgnIbAOCyDi0hC jJFOcpiRUEImDBAw2EmBggwzSnBrKoG//gAgAgpFSQplbmRzdHJlYW0KZW5kb2JqCjU5IDAgb2Jq Cjw8L0xlbmd0aCAxODggPj4Kc3RyZWFtCjAgMCAwIDAgNjAgNTAgZDEKNjAgMCAwIDUwIDAgMCBj bQpCSQovSU0gdHJ1ZS9XIDYwL0ggNTAvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDYw Ci9CbGFja0lzMSB0cnVlCj4+CklEICagYKcGJDYrwg8IPT0Hp6eunp8jBOjUDD4QfSb4Qf/Sb0/9 P//+/+v//2v7a7S7XbXhhLYMF4ra/a2traw1sLDCwYLIZhEAEAEKRUkKZW5kc3RyZWFtCmVuZG9i ago2MCAwIG9iago8PC9MZW5ndGggMTkyID4+CnN0cmVhbQowIDAgMCAtNDYgNjAgLTQgZDEKNjAg MCAwIDQyIDAgLTQ2IGNtCkJJCi9JTSB0cnVlL1cgNjAvSCA0Mi9CUEMgMS9GL0NDRi9EUDw8L0sg LTEKL0NvbHVtbnMgNjAKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqG0bB8HkGKQ8IOHhB3pp6d6d93r 93qH7B+UO3Sd9W/d///Tb////bf9f+79utv8Ha7bCXx7/tbXu1u+9btYdrBwwsQwoAIAIApFSQpl bmRzdHJlYW0KZW5kb2JqCjYxIDAgb2JqCjw8L0xlbmd0aCAxOTAgPj4Kc3RyZWFtCjAgMCAwIDAg NDkgNTMgZDEKNDkgMCAwIDUzIDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQ5L0ggNTMvQlBDIDEvRi9D Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQ5Ci9CbGFja0lzMSB0cnVlCj4+CklEICahnNQPBB4Qeg9P CfOs9EgK9BB9IN8JvV+r0n9+rr6fzb469f//////3v/9kMu95mtr/tpd+2l2u2EtgwuxW1tYa2Fg wsGCgAgAgApFSQplbmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjw8L0xlbmd0aCAxMzkgPj4Kc3Ry ZWFtCjAgMCAwIDEgMTQgNTIgZDEKMTQgMCAwIDUxIDAgMSBjbQpCSQovSU0gdHJ1ZS9XIDE0L0gg NTEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDE0Ci9CbGFja0lzMSB0cnVlCj4+CklE ICal/////////////////////////ABABApFSQplbmRzdHJlYW0KZW5kb2JqCjYzIDAgb2JqCjw8 L0xlbmd0aCAxNj4+CnN0cmVhbQo1MSAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago2NCAw IG9iago8PC9MZW5ndGggMTY4ID4+CnN0cmVhbQowIDAgMCAxIDQ2IDUzIGQxCjQ2IDAgMCA1MiAw IDEgY20KQkkKL0lNIHRydWUvVyA0Ni9IIDUyL0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1u cyA0NgovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoEHUEggeEHhB6en3okBegg30H6b0vp//uk////// ////////////////////////4AIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjY1IDAgb2JqCjw8L0xl bmd0aCAxNDkgPj4Kc3RyZWFtCjAgMCAwIDEgNDIgNTIgZDEKNDIgMCAwIDUxIDAgMSBjbQpCSQov SU0gdHJ1ZS9XIDQyL0ggNTEvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDQyCi9CbGFj a0lzMSB0cnVlCj4+CklEICagQZgv////////////////////////////8oq///ABABAKRUkKZW5k c3RyZWFtCmVuZG9iago2NiAwIG9iago8PC9MZW5ndGggMTcxID4+CnN0cmVhbQowIDAgMCAxNCAz NyA1MyBkMQozNyAwIDAgMzkgMCAxNCBjbQpCSQovSU0gdHJ1ZS9XIDM3L0ggMzkvQlBDIDEvRi9D Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM3Ci9CbGFja0lzMSB0cnVlCj4+CklEICaghDCwg8IPT09P RQN6CDfT6TfT/9N1/99f////f/r+39Lv3XtLYYXhhLYra2trDCwYKACACApFSQplbmRzdHJlYW0K ZW5kb2JqCjY3IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo0MyAwIDAgMCAwIDAgZDEKZW5k c3RyZWFtCmVuZG9iago2OCAwIG9iago8PC9MZW5ndGggMTUzID4+CnN0cmVhbQowIDAgMCAyIDIw IDUzIGQxCjIwIDAgMCA1MSAwIDIgY20KQkkKL0lNIHRydWUvVyAyMC9IIDUxL0JQQyAxL0YvQ0NG L0RQPDwvSyAtMQovQ29sdW1ucyAyMAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmoRYTrS//0aFr//// ///////////yk////k5//////4fD7wAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjY5IDAgb2JqCjw8 L0xlbmd0aCAxODMgPj4Kc3RyZWFtCjAgMCAwIDE0IDM3IDUzIGQxCjM3IDAgMCAzOSAwIDE0IGNt CkJJCi9JTSB0cnVlL1cgMzcvSCAzOS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzcK L0JsYWNrSXMxIHRydWUKPj4KSUQgJqISBcIHwg60149Lk4vQQf36f39/+/b+32dAnkQ+wfseHw+Q wIyDcPIZc98nnhP9dv9e12DCXHtb4YWGsGCgAgAgCkVJCmVuZHN0cmVhbQplbmRvYmoKNzAgMCBv YmoKPDwvTGVuZ3RoIDEzOSA+PgpzdHJlYW0KMCAwIDAgMSAxMSA1MiBkMQoxMSAwIDAgNTEgMCAx IGNtCkJJCi9JTSB0cnVlL1cgMTEvSCA1MS9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMg MTEKL0JsYWNrSXMxIHRydWUKPj4KSUQgJq/////////////////////////4AIAICkVJCmVuZHN0 cmVhbQplbmRvYmoKNzEgMCBvYmoKPDwvTGVuZ3RoIDE0NyA+PgpzdHJlYW0KMCAwIDAgMSAzNyA1 MiBkMQozNyAwIDAgNTEgMCAxIGNtCkJJCi9JTSB0cnVlL1cgMzcvSCA1MS9CUEMgMS9GL0NDRi9E UDw8L0sgLTEKL0NvbHVtbnMgMzcKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqf//58DH/////////// /////////////////+ACACAKRUkKZW5kc3RyZWFtCmVuZG9iago3MiAwIG9iago8PC9MZW5ndGgg MTY1ID4+CnN0cmVhbQowIDAgMCAwIDQ3IDQ4IGQxCjQ3IDAgMCA0OCAwIDAgY20KQkkKL0lNIHRy dWUvVyA0Ny9IIDQ4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyA0NwovQmxhY2tJczEg dHJ1ZQo+PgpJRCAmoycCP+vX/Xr/r/r1/1/16/6JC9f19L/9L6/r6X1/Xj9ev+vX/X/Xr/r/r1/1 6wAQAQpFSQplbmRzdHJlYW0KZW5kb2JqCjczIDAgb2JqCjw8L0xlbmd0aCAxNjkgPj4Kc3RyZWFt CjAgMCAwIDEyIDQyIDQ5IGQxCjQyIDAgMCAzNyAwIDEyIGNtCkJJCi9JTSB0cnVlL1cgNDIvSCAz Ny9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgNDIKL0JsYWNrSXMxIHRydWUKPj4KSUQg JqBBIDwQeEHhPQen+no6z4QPpN9P1+3S//7//1/+39Ltdte0tgwXitra2trawwsGCgAgAgpFSQpl bmRzdHJlYW0KZW5kb2JqCjc0IDAgb2JqCjw8L0xlbmd0aCAxNjkgPj4Kc3RyZWFtCjAgMCAwIDEy IDM4IDQ5IGQxCjM4IDAgMCAzNyAwIDEyIGNtCkJJCi9JTSB0cnVlL1cgMzgvSCAzNy9CUEMgMS9G L0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMzgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqC5ICQQPCen p6en+iGT6fpulBfLiaH+RIN///8nBP9pb/a9pba8VvtdYa2sMLDBQAQAQApFSQplbmRzdHJlYW0K ZW5kb2JqCjc1IDAgb2JqCjw8L0xlbmd0aCAxNj4+CnN0cmVhbQo2MCAwIDAgMCAwIDAgZDEKZW5k c3RyZWFtCmVuZG9iago3NiAwIG9iago8PC9MZW5ndGggMTUwID4+CnN0cmVhbQowIDAgMCAxMiAz MCA0OCBkMQozMCAwIDAgMzYgMCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDMwL0ggMzYvQlBDIDEvRi9D Q0YvRFA8PC9LIC0xCi9Db2x1bW5zIDMwCi9CbGFja0lzMSB0cnVlCj4+CklEICajJwT///////// ///9//99kn7C8ff/3mi9+8QwoAIAIApFSQplbmRzdHJlYW0KZW5kb2JqCjc3IDAgb2JqCjw8L0xl bmd0aCAxNj4+CnN0cmVhbQozNyAwIDAgMCAwIDAgZDEKZW5kc3RyZWFtCmVuZG9iago3OCAwIG9i ago8PC9MZW5ndGggMTY+PgpzdHJlYW0KMjYgMCAwIDAgMCAwIGQxCmVuZHN0cmVhbQplbmRvYmoK NzkgMCBvYmoKPDwvTGVuZ3RoIDE2Pj4Kc3RyZWFtCjQxIDAgMCAwIDAgMCBkMQplbmRzdHJlYW0K ZW5kb2JqCjgwIDAgb2JqCjw8L0xlbmd0aCAxODEgPj4Kc3RyZWFtCjAgMCAwIDEyIDM4IDQ5IGQx CjM4IDAgMCAzNyAwIDEyIGNtCkJJCi9JTSB0cnVlL1cgMzgvSCAzNy9CUEMgMS9GL0NDRi9EUDw8 L0sgLTEKL0NvbHVtbnMgMzgKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqDnQJBA9B4T09P9HWfBA+k/ XvchYCxBLIEDMg4TBdLCWl1oFwXNYYo6BnwRCv0jS6e2vH1v1tYa2FgwUAEAEApFSQplbmRzdHJl YW0KZW5kb2JqCjgxIDAgb2JqCjw8L0xlbmd0aCAxNjYgPj4Kc3RyZWFtCjAgMCAwIDAgNDkgNDgg ZDEKNDkgMCAwIDQ4IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDQ5L0ggNDgvQlBDIDEvRi9DQ0YvRFA8 PC9LIC0xCi9Db2x1bW5zIDQ5Ci9CbGFja0lzMSB0cnVlCj4+CklEICajJgHwfD77777/lAO/f2/f 3+/f/////77//19f////+v/pf+vpeF4rr+uuuuFwUAEAEApFSQplbmRzdHJlYW0KZW5kb2JqCjgy IDAgb2JqCjw8L0xlbmd0aCAxNzAgPj4Kc3RyZWFtCjAgMCAwIDEyIDU5IDQ4IGQxCjU5IDAgMCAz NiAwIDEyIGNtCkJJCi9JTSB0cnVlL1cgNTkvSCAzNi9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0Nv bHVtbnMgNTkKL0JsYWNrSXMxIHRydWUKPj4KSUQgJqMnCk4X////////////////////////X/tP /7v2mu00uI/65Al5ok17TXhprEMIGCgAgAgKRUkKZW5kc3RyZWFtCmVuZG9iago4MyAwIG9iago8 PC9MZW5ndGggMTU0ID4+CnN0cmVhbQowIDAgMCAxIDI1IDQ5IGQxCjI1IDAgMCA0OCAwIDEgY20K QkkKL0lNIHRydWUvVyAyNS9IIDQ4L0JQQyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAyNQov QmxhY2tJczEgdHJ1ZQo+PgpJRCAmocLQcL6/65IXhD////////////liP////yKf////8Ph8PvAB ABAKRUkKZW5kc3RyZWFtCmVuZG9iago4NCAwIG9iago8PC9MZW5ndGggMTQyID4+CnN0cmVhbQow IDAgMCAwIDE4IDQ4IGQxCjE4IDAgMCA0OCAwIDAgY20KQkkKL0lNIHRydWUvVyAxOC9IIDQ4L0JQ QyAxL0YvQ0NGL0RQPDwvSyAtMQovQ29sdW1ucyAxOAovQmxhY2tJczEgdHJ1ZQo+PgpJRCAmo/// //////////////8gQa/yNH///4AIAIAKRUkKZW5kc3RyZWFtCmVuZG9iago4NSAwIG9iago8PC9M ZW5ndGggMTcwID4+CnN0cmVhbQowIDAgMCAxMiAzOSA0OSBkMQozOSAwIDAgMzcgMCAxMiBjbQpC SQovSU0gdHJ1ZS9XIDM5L0ggMzcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM5Ci9C bGFja0lzMSB0cnVlCj4+CklEICaguQwkIPCD09PT0/0dG+E+k3p/6a1mB8f///9/IIP2jO8HtLbX hhdiv2traw1sLBgoAIAICkVJCmVuZHN0cmVhbQplbmRvYmoKODYgMCBvYmoKPDwvTGVuZ3RoIDEz OCA+PgpzdHJlYW0KMCAwIDAgMCAxOCA0OCBkMQoxOCAwIDAgNDggMCAwIGNtCkJJCi9JTSB0cnVl L1cgMTgvSCA0OC9CUEMgMS9GL0NDRi9EUDw8L0sgLTEKL0NvbHVtbnMgMTgKL0JsYWNrSXMxIHRy dWUKPj4KSUQgJqP///////////////////////wAQAQKRUkKZW5kc3RyZWFtCmVuZG9iago4NyAw IG9iago8PC9MZW5ndGggMTU0ID4+CnN0cmVhbQowIDAgMCAxMiA0MCA0OCBkMQo0MCAwIDAgMzYg MCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDQwL0ggMzYvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1 bW5zIDQwCi9CbGFja0lzMSB0cnVlCj4+CklEICajJwT//////////////3////Xf/a4YXFf/XJ0v a8NYhgoAIAIKRUkKZW5kc3RyZWFtCmVuZG9iago4OCAwIG9iago8PC9MZW5ndGggMTc3ID4+CnN0 cmVhbQowIDAgMCAxMiAzOSA0OSBkMQozOSAwIDAgMzcgMCAxMiBjbQpCSQovSU0gdHJ1ZS9XIDM5 L0ggMzcvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDM5Ci9CbGFja0lzMSB0cnVlCj4+ CklEICahSgGIQZaKDrQ9L9eQ70H6DXT//9/fs6n5GLse+Hw+QXEZDRXkDBG+RPrBfv7C7H+1+1hr YWDBQAQAQApFSQplbmRzdHJlYW0KZW5kb2JqCjg5IDAgb2JqCjw8L0xlbmd0aCAxMzggPj4Kc3Ry ZWFtCjAgMCAwIDAgMTggNDggZDEKMTggMCAwIDQ4IDAgMCBjbQpCSQovSU0gdHJ1ZS9XIDE4L0gg NDgvQlBDIDEvRi9DQ0YvRFA8PC9LIC0xCi9Db2x1bW5zIDE4Ci9CbGFja0lzMSB0cnVlCj4+CklE ICaj///////////////////////8AEAECkVJCmVuZHN0cmVhbQplbmRvYmoKeHJlZgowIDk3CjAw MDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAxMzU2MyAwMDAwMCBuIAowMDAwMDEzNDYzIDAwMDAwIG4g CjAwMDAwMDE1NzYgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxNTU2IDAwMDAw IG4gCjAwMDAwMTMyOTEgMDAwMDAgbiAKMDAwMDAxMzM3NSAwMDAwMCBuIAowMDAwMDAzMzU3IDAw MDAwIG4gCjAwMDAwMDE3MjQgMDAwMDAgbiAKMDAwMDAwMzMzNiAwMDAwMCBuIAowMDAwMDA0OTc0 IDAwMDAwIG4gCjAwMDAwMDM1MDUgMDAwMDAgbiAKMDAwMDAwNDk1MyAwMDAwMCBuIAowMDAwMDA2 MzM2IDAwMDAwIG4gCjAwMDAwMDUxMjQgMDAwMDAgbiAKMDAwMDAwNjMxNSAwMDAwMCBuIAowMDAw MDEzNzA0IDAwMDAwIG4gCjAwMDAwMTgzNjcgMDAwMDAgbiAKMDAwMDAxODM4OCAwMDAwMCBuIAow MDAwMDIzOTI4IDAwMDAwIG4gCjAwMDAwMTMxMzkgMDAwMDAgbiAKMDAwMDAxMzIzMSAwMDAwMCBu IAowMDAwMDA5NTUyIDAwMDAwIG4gCjAwMDAwMDY1NDkgMDAwMDAgbiAKMDAwMDAwOTUzMSAwMDAw MCBuIAowMDAwMDIzOTQ5IDAwMDAwIG4gCjAwMDAwMTIxNzMgMDAwMDAgbiAKMDAwMDAyNTE4NyAw MDAwMCBuIAowMDAwMDI1Mzg4IDAwMDAwIG4gCjAwMDAwMjU1NjEgMDAwMDAgbiAKMDAwMDAyNTYy NSAwMDAwMCBuIAowMDAwMDI1ODU1IDAwMDAwIG4gCjAwMDAwMjYwODEgMDAwMDAgbiAKMDAwMDAy NjMwNSAwMDAwMCBuIAowMDAwMDI2NTQyIDAwMDAwIG4gCjAwMDAwMjY3NTkgMDAwMDAgbiAKMDAw MDAyNzAwMiAwMDAwMCBuIAowMDAwMDI3MjQzIDAwMDAwIG4gCjAwMDAwMjc0NzAgMDAwMDAgbiAK MDAwMDAyNzY2NSAwMDAwMCBuIAowMDAwMDI3ODkwIDAwMDAwIG4gCjAwMDAwMjgwNjYgMDAwMDAg biAKMDAwMDAyODEzMCAwMDAwMCBuIAowMDAwMDI4MzU3IDAwMDAwIG4gCjAwMDAwMjg1OTggMDAw MDAgbiAKMDAwMDAyODgzNyAwMDAwMCBuIAowMDAwMDI5MDIxIDAwMDAwIG4gCjAwMDAwMjkyNDUg MDAwMDAgbiAKMDAwMDAyOTQ2NiAwMDAwMCBuIAowMDAwMDI5Njk0IDAwMDAwIG4gCjAwMDAwMjk5 MDggMDAwMDAgbiAKMDAwMDAzMDA4NiAwMDAwMCBuIAowMDAwMDMwMjg4IDAwMDAwIG4gCjAwMDAw MzA1MDUgMDAwMDAgbiAKMDAwMDAzMDcwMSAwMDAwMCBuIAowMDAwMDMwOTM0IDAwMDAwIG4gCjAw MDAwMzExMzEgMDAwMDAgbiAKMDAwMDAzMTMyNSAwMDAwMCBuIAowMDAwMDMxNTcwIDAwMDAwIG4g CjAwMDAwMzE4MDggMDAwMDAgbiAKMDAwMDAzMjA1MCAwMDAwMCBuIAowMDAwMDMyMjkwIDAwMDAw IG4gCjAwMDAwMzI0NzkgMDAwMDAgbiAKMDAwMDAzMjU0MyAwMDAwMCBuIAowMDAwMDMyNzYxIDAw MDAwIG4gCjAwMDAwMzI5NjAgMDAwMDAgbiAKMDAwMDAzMzE4MSAwMDAwMCBuIAowMDAwMDMzMjQ1 IDAwMDAwIG4gCjAwMDAwMzM0NDggMDAwMDAgbiAKMDAwMDAzMzY4MSAwMDAwMCBuIAowMDAwMDMz ODcwIDAwMDAwIG4gCjAwMDAwMzQwNjcgMDAwMDAgbiAKMDAwMDAzNDI4MiAwMDAwMCBuIAowMDAw MDM0NTAxIDAwMDAwIG4gCjAwMDAwMzQ3MjAgMDAwMDAgbiAKMDAwMDAzNDc4NCAwMDAwMCBuIAow MDAwMDM0OTg0IDAwMDAwIG4gCjAwMDAwMzUwNDggMDAwMDAgbiAKMDAwMDAzNTExMiAwMDAwMCBu IAowMDAwMDM1MTc2IDAwMDAwIG4gCjAwMDAwMzU0MDcgMDAwMDAgbiAKMDAwMDAzNTYyMyAwMDAw MCBuIAowMDAwMDM1ODQzIDAwMDAwIG4gCjAwMDAwMzYwNDcgMDAwMDAgbiAKMDAwMDAzNjIzOSAw MDAwMCBuIAowMDAwMDM2NDU5IDAwMDAwIG4gCjAwMDAwMzY2NDcgMDAwMDAgbiAKMDAwMDAzNjg1 MSAwMDAwMCBuIAowMDAwMDM3MDc4IDAwMDAwIG4gCjAwMDAwMTEzMTYgMDAwMDAgbiAKMDAwMDAw OTczMiAwMDAwMCBuIAowMDAwMDExMjk1IDAwMDAwIG4gCjAwMDAwMTIwMjMgMDAwMDAgbiAKMDAw MDAxMTQ2NiAwMDAwMCBuIAowMDAwMDEyMDAzIDAwMDAwIG4gCjAwMDAwMTM2MTIgMDAwMDAgbiAK dHJhaWxlcgo8PCAvU2l6ZSA5NyAvUm9vdCAxIDAgUiAvSW5mbyA5NiAwIFIKPj4Kc3RhcnR4cmVm CjM3MjY2CiUlRU9GCg== ------_=_NextPart_000_01C064BA.208F49D0 Content-Type: text/plain; name="draft-ietf-ippm-npmps-04.txt" Content-Disposition: attachment; filename="draft-ietf-ippm-npmps-04.txt" Content-Transfer-Encoding: quoted-printable Network Working Group V. = Raisanen INTERNET-DRAFT = Nokia Expiration Date: June 2001 G. = Grotefeld = Motorola December = 2000 Network performance measurement for periodic streams 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at = =20 http://www.ietf.org/ietf/1id-abstracts.txt = =20 The list of Internet-Draft shadow directories can be accessed at = =20 http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Abstract This document describes a sample metric suitable for application- level IP network transport measurement for periodic streams, such as VoIP or streaming multimedia over IP. In this document, the reader is assumed to be familiar with the terminology of the Framework for IP Performance Metrics RFC 2330 [1]. This document is parallel to A One-way Delay Metric for IPPM RFC 2679 [2]. Although this document is based on the delay metrics, other characteristics can be measured with this approach, too. For example, packet loss rate, reordering / out-of sequence, and successive delay variation are all additional metrics which can be built from this baseline set of measurements. Raisanen, Grotefeld expires June 2001 [Page = 1]=0C Internet Draft December = 2000 3. Introduction This document discusses concepts relevant to application-level performance measurements of an IP network. The original driver for this work is Quality of Service of interactive periodic streams such as multimedia conference over IP, but the idea of application-level measurementJune have a wider scope. In the following, interactive multimedia traffic is used as an example to illustrate the concept. A constant bit-rate (CBR), or nearly CBR, streaming (hereinafter called periodic) multimedia bit streamJune be simulated by transmitting uniformly sized packets (or mostly uniformly sized packets) at regular intervals through the network to be evaluated. The "mostly uniformly sized packets"June be found in applications thatJune use smaller packets during a portion of the stream (e.g. digitally coded voice during silence periods). As noted in the framework document [1], a sample metric using regularly spaced singleton tests has some limitations when considered from a general measurement point of view: only part of the network performance spectrum is sampled. However, from the point of view of application-level performance, this is actually good news as explained below. IP delivery service measurements have been discussed within the International Telecommunications Union (ITU). A framework for IP service level measurements (with references to the framework for IP performance [1]) that is intended to be suitable for service = planning has been approved as I.380 [3]. The emphasis in the ITU recommendation is on passive measurements, though not explicitly forbidding active measurements. The present contribution proposes a method that is usable both for service planning and end-user testing purposes, and is based on active measurements. 3.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different = implementations are comparable, and to note instances when an implementation could perturb the network. Raisanen, Grotefeld expires June 2001 [Page = 2]=0C Internet Draft December = 2000 3.2 Considerations related to delay For interactive multimedia sessions, end-to-end delay is an important factor. Too large a delay reduces the quality of the multimedia session as perceived by the participants. One approach = for managing end-to-end delays on an Internet path involving heterogeneous link layer technologies is to use per-domain delay quotas (e.g. 50 ms for a particular IP domain). The 50 ms would then be included into a calculation of an end-to-end delay bound. A practical implementation of such as scheme ought to address issues like possibility of asymmetric delays in a route in different directions, and sensitivity of an application to delay variations in a given domain. There are several alternatives as to which kind of derivative delay metric one ought to use in managing end-to-end QoS. This question, although very interesting, is not within the scope of this draft and is not discussed further here. In the following, a methodology and metric are presented for measuring media stream transport QoS in an IP domain. The measurement resultsJune be used in derivative metrics such as average and maximum delays. A metric is presented that is a standard way for performing a measurement irrespective of the possible QoS mechanism utilized in the core network. As an example, for a QoS mechanism without hard guarantees, measurementsJune be used to ascertain that the "best" class gets the service that has been promised for the traffic class in question. Moreover, an operator could study the quality of a cheap, low-guarantee service implemented using possible slack bandwidth in other classes. Such measurements could be made either in studying the feasibility of a new service, or on a regular basis. The present draft seeks to formalize the measurements in such a way that interoperable results are achieved. 3.3 Protocol level issues The version of the Internet Protocol used in the measurement affects (at least) packet sizes, and should be reported. =20 Fig.1 illustrates measurements on multiple protocol levels that are relevant to this draft. The major focus of the present draft is on transport quality evaluation from application point of view. However, to properly account for quality effects of, e.g., operating system and codec on packet voice, it is beneficial to be able to measure quality at IP level [5]. Link layer monitoring provides a way of accounting for link layer characteristics such as bit error rates. Raisanen, Grotefeld expires June 2001 [Page = 3]=0C Internet Draft December = 2000 --------------- | application | --------------- | transport | <-- --------------- | network | <-- --------------- | link | <-- --------------- | physical | ---------------=20 Fig. 1: Different possibilities for performing measurements: a protocol view. Above, "application" refers to all layers above L4 and is not used in the OSI sense. In general, the results of measurementsJune be influenced by individual application requirements/responses related to the following issues: + Lost packets: ApplicationsJune have varying tolerance to lost=20 packets. Another consideration is the distribution of lost packets (i.e. random or bursty). + Long delays: Many applications will consider packets delayed=20 longer than a certain value to be equivalent to lost packets (i.e. real time applications). + Duplicate packets: Some applicationsJune be perturbed if=20 duplicate packets are received. + Out-of-sequence: Some applicationsJune be perturbed if packets are received out of sequence. ThisJune be in addition to the possibility of exceeding the "long" delay threshold as a result of being out of sequence. An out-of-sequence packet outcome occurs when a single IP packet received at a DST measurement point has a sequence number higher than that which is expected, and therefore, the packet is OOS due to re-ordering.=20 + Corrupt packet header: Most applications will probably treat a packet with a corrupt header as equivalent to a lost packet. + Corrupt packet payload: Some applications (e.g. digital voice=20 codecs)June accept corrupt packet payload. In some cases, the packet payloadJune contain application specific forward error correction (FEC) that can compensate for some level of=20 corruption. + Spurious packet: DstJune receive spurious packets (i.e. packets that are not sent by the Src as part of the metric). Many applicationsJune be perturbed by spurious packets. Depending, e.g., on the observed protocol level, some issues listed aboveJune be indistinguishable from others by the application, it June be important to preserve the distinction for the operators of Src, Dst, and/or the intermediate network(s). Raisanen, Grotefeld expires June 2001 [Page = 4]=0C Internet Draft December = 2000 Because of the possible errors listed above, in most cases it is=20 recommended to use a packet identifier for each packet generated at Src. Identifiers for the metric sampleJune be those used by the underlying transport layer (e.g. RTP sequence number) or the same=20 identifiers used by an application if the application to be modeled=20 by the metric uses an identifier. The possibility of identifier=20 roll-over (reuse if intentional) during a metric collected over a "long" (application dependent) time should be observed. If the application does not use an identifier, itJune still be=20 useful to add identifiers to the packets in the metric sample to=20 help identify possible anomalies such as out of sequence packets. This would be most useful in the case where the application=20 expects to receive packets in sequence, but has no capability to identify the sequence of packets received at Dst. 3.4 Application-level measurement In what follows, a metric is proposed for application-level network performance measurement. In effect, the metric is an emulation of periodic multimedia stream performance. The justification for using realistic application metrics in the measurement: + The results of the measurement are automatically relevant to the performance as perceived by the application in question. + All the packets in the measurement contribute to accuracy of the estimation of performance variation at timescale that is important to the multimedia application (packetization interval). + Effects of elastic traffic (TCP) on measurement packets are different for a sustained stream than for single packets during overloading situations as discussed in [3]. 3.5 Measurement types Delay measurements can be one-way [2,3], paired one-way, or=20 round-trip [6]. Accordingly, the measurementsJune be performed either with synchronized or unsynchronized Src/Dst host clocks. Different possibilities are listed below. The reference measurement setup for all measurement types is shown in Fig. 2. Raisanen, Grotefeld expires June 2001 [Page = 5]=0C Internet Draft December = 2000 ----------------< IP >-------------------- | | | | ------- ------- -------- -------- | Src | | MP | | MP | | Dst | ------- |(Src)| |(Dst) | -------- ------- -------- =20 Fig. 2: Example setup for the metric usage. An example of the use of the metric is a setup with a source host (Src), a destination host (Dst), and corresponding measurement points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate = equipment for measurement pointsJune be used if having Src and/or Dst conduct=20 the measurementJune significantly affect the delay performance to be measured. MP(Src)should be placed/measured close to the egress point = of packets from Src. MP(Dst) should be placed/measure close to=20 the ingress point of packets for Dst. "Close" is defined as a distance sufficiently small so that application-level performance characteristics measured (such as delay) can be expected to follow=20 the corresponding performance characteristic between Src and Dst to=20 an adequate accuracy. Basic principle here is that measurement results between MP(Src) and MP(Dst) should be the same as for a measurement between Src and Dst, within the general error margin target of the measurement (e.g., < 1 ms; number of lost packets is the same). If this is not possible, the difference between MP-MP measurement and Src-Dst measurement should preferably be systematic. =20 The test setup just described fulfills two important criteria: 1) Test is made with realistic stream metrics, emulating - for = example - a full-duplex Voice over IP (VoIP) call. 2) Either one-way or round-trip characteristicsJune be obtained. It is also possible to have intermediate measurement points between=20 MP(Src) and MP(Dst), but that is beyond the scope of this document. 3.5.1 One way measurement In the interests of specifying metrics that are as generally usable as possible, application-level measurements based on one-way delays are used in the example metrics. The implication of = application-level measurement for bi-directional applications such as interactive multimedia conferencing is discussed below. Performing a single one-way measurement only yields information on network behavior in one direction. Moreover, the stream at the network transport level does not emulate accurately a full-duplex multimedia connection. Raisanen, Grotefeld expires June 2001 [Page = 6]=0C Internet Draft December = 2000 3.5.2 Paired one way measurement Paired one way delay refers to two multimedia streams: Src to Dst=20 and Dst to Src for the same Src and Dst. By way of example, for some applications, the delay performance of each one way path is more important than the round trip delay. This is the case for delay-limited signals such as VoIP. Possible reasons for the difference between one-way delays is different routing of streams from Src to Dst vs. Dst to Src. For example, a paired one way measurementJune show that Src to Dst has an average delay of 30ms while Dst to Src has an average delay of 120ms. To a round trip delay measurement, this example would look like an average of 150ms delay. Without the knowledge of the asymmetry, we might miss a problem that the application at either endJune have with delays averaging more than 100ms. Moreover, paired one way delay measurement emulates a full-duplex VoIP call more accurately than a single one-way measurement only. 3.5.3 Round trip measurement From the point of view of periodic multimedia streams, round-trip measurements have two advantages: they avoid the need of host clock synchronization and they allow for a simulation of full-duplex connections. The former aspect means that a measurement is easily performed, since no special equipment or NTP setup is needed. The latter property means that measurement streams are transmitted in both directions. Thus, the measurement provides information on quality of service as experienced by appropriate application. The downsides of round-trip measurement are the need for more bandwidth than an one-way test and more complex accounting of packet loss. Moreover, the stream that is returning towards the original senderJune be more bursty than the one on the first "leg" = of the round-trip journey. The last issue, however, means in practice that returning stream experiences worse QoS than the other one, and the performance estimates thus obtained are pessimistic ones. The possibility of asymmetric routing and queuing must be taken into account during analysis of the results. Please note that with suitable arrangements, round-trip measurements June be performed using paired one way measurements. Raisanen, Grotefeld expires June 2001 [Page = 7]=0C Internet Draft December = 2000 4 Sample metric for multimedia stream simulation The sample metric presented here is similar to the sample metric Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", = as defined in [1] and [2] are not directly used in this document = because certain key results (such as duplicate or out of sequence packets) cannot be identified in the context of a singleton, but only as part of a sample. 4.1 Metric name =20 Type-P-One-way-Delay-Periodic-Stream 4.2 Metric parameters 4.2.1 Global metric parameters These parameters are applicable to the metrics collected in the=20 following sections (4.2.2, 4.2.3, and 4.2.4). + Src, the IP address of a host + Dst, the IP address of a host + IPV, the IP version (IPv4/IPv6) used in the measurement + T0, a time, for starting to generate packets and taking=20 measurements for a sample + Tf, a time, greater than T0, for stopping generation of packets for a sample + incT, nominal duration of inter-packet interval + packet size p(j), the number of bytes in each packet of Type-P of = size j + dTloss, a time interval, used for determining if a packet should be considered lost + Tcons, a time interval [optional] While a number of applications will use one packet size (j =3D = 1), other applicationsJune use packets of different sizes (j > 1).=20 Especially in cases of congestion, itJune be useful to have=20 packets smaller than the maximum or predominant size of packets in the periodic stream. 4.2.2 Metrics collected at MP(Src) + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src) + PktID [i], for each packet [i], an identification number for the the packet sent from Src to Dst. Raisanen, Grotefeld expires June 2001 [Page = 8]=0C Internet Draft December = 2000 + PktSiTy [i], for each packet [i], the packet size and/or type. Some applicationsJune use packets of different size, either=20 because of application requirements or in response to IP=20 performance experienced. 4.2.3 Metrics collected at MP (Dst) + dTstop, a time interval, used to add to time Tf to determine when = to stop collecting metrics for a sample + Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst) + PktID [i], for each packet [i], an identification number for the the packet received at Dst from Src. + PktSiTy [i], for each packet [i], the packet size and/or type. Some applicationsJune use packets of different size, either=20 because of application requirements or in response to IP=20 performance experienced. + PktStatus [i], for each packet [i], the status of the packet received. Possible status includes: OK, packet header corrupt, packet payload corrupt, spurious, duplicate, out-of-sequence. 4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst) are merged These parameters are only available as a complete set when the=20 parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are=20 combined. =20 + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src). This entryJune be blank or noted as N/A for spurious packets received at MP(Dst) + Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst). This entryJune be blank or noted as N/A for packets not received at MP(Dst), received with corrupt=20 packet headers, or for duplicate packets received at MP(Dst). + PktID [i], for each packet [i], an identification number for the the packet received. This identification numberJune be corrupted for certain packets received at MP (Dst). + PktSiTy [i], for each packet [i], the packet size and/or type. + PktStatus [i], for each packet [i], the status of the packet=20 received. Possible status includes: OK, packet header corrupt, packet payload corrupt, spurious, duplicate, out-of-sequence. Raisanen, Grotefeld expires June 2001 [Page = 9]=0C Internet Draft December = 2000 + Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] = -=20 Tstamp(Src)[i]. For the following conditions, it will not be=20 possible to be able to compute delay: Spurious: There will be no Tstamp(Src)[i] time Not received: There will be no Tstamp (Dst) [i] Corrupt packet header: There will be no Tstamp (Dst) [i] Duplicate: Only the first non-corrupt copy of the packet=20 received at Dst should have Delay [i] computed. + SDV[i] [optional] , for each packet [i] except the first one:=20 momentary delay variation between successive packets, i.e., = the=20 time interval Delay[i] - Delay [i-1]. SDV[i]June be negative, = zero, or positive. Delay for both packets i and i+1 must be=20 calculable according to the definition above or SDV[i] is=20 undefined. 4.3 High level description of the procedure to collect a sample Beginning on or after time T0, Type-P packets are generated=20 by Src and sent to Dst until time Tf is reached with a nominal=20 interval between the first bit of successive packets of incT as=20 measured at MP(Src). incTJune be nominal due to a number of = reasons: variation in packet generation at Src, clock issues (see section = 4.6), etc. MP(Src) records the following information only for packets with=20 timestamps between and including T0 and Tf: timestamp,=20 packet identifier, and packet size/type of each packet sent from Src = to Dst that is part of the sample. =20 MP (Dst) records the following information only for packets with=20 time stamps between T0 and (Tf+ dTstop): timestamp, packet = identifier,=20 packet size/type, and received status of each packet received from=20 Src at Dst that is part of the sample. Optionally, at a time Tf +=20 Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive=20 the results of the sample metric.=20 To prevent stopping data collection too soon, dTcons should be = greater than or equal to dTstop. Conversely, to keep data collection=20 reasonably efficient, dTstop should be some reasonable time interval = (seconds/minutes/hours), even if dTloss is infinite or extremely = long. Raisanen, Grotefeld expires June 2001 [Page = 10]=0C Internet Draft December = 2000 4.4 Discussion The sample metric thus defined is intended to probe the delays and the delay variation as experienced by multimedia streams of an application. Due to the definition of the metric, also packet = loss status of packets is recorded. The delay is assumed to be measured = at transport layer level. Since a range of packet sizes and nominal=20 interval between packets is used, the method probes only a specific=20 time scale of network QoS variations. There are a number of factors that should be taken into account when = collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream. + T0 and (Tf + dTloss) should specify a long enough time interval = to=20 represent a reasonable use of the application under test (e.g. do = not provide only a 100 ms time interval for a phone call) + T0 and (Tf + dTloss) should specify a time interval that is not=20 excessively long compared to the usage of the application under = test (e.g. do not provide a one week continuous phone call) + The nominal interval between packets (incT) and the packet = size(s) (p(j)) should not define an equivalent bit rate that is in excess = of the capacity of the egress port of Src, the ingress port of = Dst, or the carrying capacity of the intervening network(s). ThereJune be exceptional cases to test the response of the application to overload conditions in the transport networks, but these cases=20 should be strictly controlled. + Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part = of a stream when trying to discover a distribution of the delay = values of a stream. + Depending on measurement topology, delay valuesJune be as low as 100 usec to 10 msec, whereby itJune be important for Src and Dst = to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary = application of NTPJune allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among = those NTP agents used, and this delay is what we are trying to measure. = A combination of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results, but this is yet to be tested. + Reordering of packets is best discussed in terms of the entire set of measurement packets received, i.e. should be addressed in Sec. 4.9.1. Raisanen, Grotefeld expires June 2001 [Page = 11]=0C Internet Draft December = 2000 + A given methodology will have to include a way to determine whether packet was lost or whether delay is merely very large = (and the packet is yet to arrive at Dst). The global metric parameter dTloss defines a time interval such that delays larger than = dTloss are interpreted as losses.=20 {Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTTJune as well have been lost.} 4.5 Additional Methodology Aspects As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). 4.6 Errors and uncertainties The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document [1] provides general guidance on this point,=20 but we note here the following specifics related to delay metrics: + Error due to variation of incT + Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points. + Errors or uncertainties due to the difference between 'wire time' and 'host time'. 4.6.1. Errors or uncertainties related to Clocks The uncertainty in a measurement of one-way delay is related, in part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the following, we refer to the clock used to measure when the packet was measured at MP(Src) as the MP(Src) clock and we refer to the=20 clock used to measure when the packet was received at MP(Dst) as the MP(Dst) clock. Alluding to the notions of synchronization, = accuracy, resolution, and skew, we note the following: + Any error in the synchronization between the MP(Src) clock and=20 the MP(Dst) clock will contribute to error in the delay measurement. We say that the MP(Src) clock and the MP(Dst) clock have a synchronization error of Tsynch if the MP(Src) clock is Tsynch ahead of the MP(Dst) clock. Thus, if we know the value of Tsynch exactly, we could correct for clock synchronization by adding Tsynch to the uncorrected value of Tstamp(Dst)[i] - Tstamp(Src) [i]. Raisanen, Grotefeld expires June 2001 [Page = 12]=0C Internet Draft December = 2000 + The accuracy of a clock is important only in identifying the time at which a given delay was measured. Accuracy, per se, has no importance to the accuracy of the measurement of delay. When computing delays, we are interested only in the differences between clock values, not the values themselves. + The resolution of a clock adds to uncertainty about any time measured with it. Thus, if the MP(Src) clock has a resolution of 10 msec, then this adds 10 msec of uncertainty to any time value measured with it. We will denote the resolution of the source clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst), respectively. + The skew of a clock is not so much an additional issue as it is a realization of the fact that Tsynch is itself a function of time. Thus, if we attempt to measure or to bound Tsynch, this needs to be done periodically. Over some periods of time, this function can be approximated as a linear function plus some higher order terms; in these cases, one option is to use knowledge of the linear component to correct the clock. Using this correction, = the residual Tsynch is made smaller, but remains a source of uncertainty that must be accounted for. We use the function Esynch(t) to denote an upper bound on the uncertainty in synchronization. Thus, |Tsynch(t)| <=3D Esynch(t). Taking these items together, we note that naive computation=20 Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/-=20 (ResMP(SRc) + ResMP(Dst)). Using the notion of Esynch(t), we note =20 that these clock-related problems introduce a total uncertainty of=20 Esynch(t)+ Rsource + Rdest. This estimate of total clock-related=20 uncertainty should be included in the error/uncertainty analysis of=20 any measurement implementation. 4.6.2. Errors or uncertainties related to Wire-time vs Host-time As we have defined one-way periodic delay, we would like to measure=20 the time between when a packet is measured and time-stamped at MP(Src) and when it arrives and is time-stamped at MP(Dst) and we refer to these as "wire times." If the timings are themselves performed by software on Src and Dst, however, then this software = can only directly measure the time between when Src generates the packet just prior to sending the test packet and when Dst has started to process the packet after having received the test packet, and we = refer to these two points as "host times". To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for wire = time measurements and the corrected value more accurately estimates the desired (host time) metric. Raisanen, Grotefeld expires June 2001 [Page = 13]=0C Internet Draft December = 2000 To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hsource an upper bound on the uncertainty in the difference between wire time of MP(Src) and host time on the Src host, and similarly define Hdest for the difference between the host time on the Dst host and the = wire time of MP(Dst). We then note that these problems introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of=20 any measurement implementation. 4.6.3. Calibration Generally, the measured values can be decomposed as follows: measured value =3D true value + systematic error + random error If the systematic error (the constant bias in measured values) can = be determined, it can be compensated for in the reported results. reported value =3D measured value - systematic error therefore reported value =3D true value + random error The goal of calibration is to determine the systematic and random error generated by the instruments themselves in as much detail as possible. At a minimum, a bound ("e") should be found such that the reported value is in the range (true value - e) to (true value + e) at least 95 percent of the time. We call "e" the calibration error for the measurements. It represents the degree to which the values produced by the measurement instrument are repeatable; that is, how closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95 percent was chosen due to reasons discussed in [2], briefly summarized as (1) some confidence level is desirable to be able to remove outliers, which will be found in measuring any physical property; (2) a particular confidence level should be specified so that the results of independent implementations can be compared.} From the discussion in the previous two sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest. Raisanen, Grotefeld expires June 2001 [Page = 14]=0C Internet Draft December = 2000 However, reasonable bounds on both the clock-related uncertainty captured by the first three terms and the host-related uncertainty captured by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab. For example, the clock-related uncertainties are greatly reduced through the use of a GPS time source. The sum of Esynch(t) +=20 ResMP(Src) + ResMP(Dst) is small, and is also bounded for the=20 duration of the measurement because of the global time source. The host-related uncertainties, Hsource + Hdest, could be bounded by connecting two instruments back-to-back with a high-speed serial = link or isolated LAN segment. In this case, repeated measurements are measuring the same one-way delay. If the test packets are small, such a network connection has a minimal delay thatJune be approximated by zero. The measured delay therefore contains only systematic and random error in the instrumentation. The "average value" of repeated measurements is = the systematic error, and the variation is the random error. One way to compute the systematic error, and the random error to a 95% confidence is to repeat the experiment many times - at least hundreds of tests. The systematic error would then be the median. The random error could then be found by removing the systematic = error from the measured values. The 95% confidence interval would be the range from the 2.5th percentile to the 97.5th percentile of these deviations from the true value. The calibration error "e" could = then be taken to be the largest absolute value of these two numbers, plus the clock-related uncertainty. {Comment: as described, this bound = is relatively loose since the uncertainties are added, and the absolute value of the largest deviation is used. As long as the resulting value is not a significant fraction of the measured values, it is a reasonable bound. If the resulting value is a significant fraction of the measured values, then more exact methods will be needed to compute the calibration error.} Note that random error is a function of measurement load. For example, if many paths will be measured by one instrument, this = might increase interrupts, process scheduling, and disk I/O (for example, recording the measurements), all of whichJune increase the random error in measured singletons. Therefore, in addition to minimal = load measurements to find the systematic error, calibration measurements should be performed with the same measurement load that the instruments will see in the field. Raisanen, Grotefeld expires June 2001 [Page = 15]=0C Internet Draft December = 2000 We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality. 4.7 Reporting the metric The calibration and context in which the metric is measured MUST be carefully considered, and SHOULD always be reported along with = metric results. We now present five items to consider: the Type-P of test packets, the threshold of delay equivalent to loss, error calibration, the path traversed by the test packets, and background=20 conditions at Src, Dst, and the intervening networks during a = sample. This list is not exhaustive; any additional information that could = be=20 useful in interpreting applications of the metrics should also be=20 reported. 4.7.1. Type-P As noted in the Framework document [1], the value of the metricJune depend on the type of IP packets used to make the measurement, or "type-P". The value of Type-P-One-way-Periodic-Delay could change=20 if the protocol (UDP or TCP), port number, size, or arrangement for=20 special treatment (e.g., IP precedence or RSVP) changes. The exact=20 Type-P used to make the measurements MUST be accurately reported. 4.7.2. Threshold for delay equivalent to loss In addition, the threshold for delay equivalent to loss (or=20 methodology to determine this threshold) MUST be reported. 4.7.3. Calibration results + If the systematic error can be determined, it SHOULD be removed from the measured values. + You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.) + If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported. Raisanen, Grotefeld expires June 2001 [Page = 16]=0C Internet Draft December = 2000 4.7.4. Path The path traversed by the packets SHOULD be reported, if possible. In general it is impractical to know the precise path a given packet takes through the network. The precise pathJune be known for certain Type-P packets on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers* on the path support record (or loose-source) route, then the path will be precisely recorded. ThisJune be impractical because the route must be short enough, many routers do not support (or are not configured for) record = route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing. However, partial information is still valuable context. For example, if a host can choose between two links* (and hence two separate routes from Src to Dst), then the initial link used is valuable context. {Comment: For example, with Merit's NetNow setup, a Src on one NAP can reach a Dst on another NAP by either of several different backbone networks.} 4.7.5 Background conditions In many cases, the results of a sampleJune be influenced by = conditions at Src, Dst, and/or any intervening networks. Some things thatJune=20 affect the results of a sample include: traffic levels and/or = bursts=20 during the sample, link and/or host failures, etc. Information = about the background conditionsJune only be available by non-Internet = means (e.g. phone calls, television) andJune only become available days = after samples are taken. 4.8 Single sample vs. a "sample of samples" Because this metric represents a periodic stream as one sample, = there=20 June be value in running multiple tests using this metric to collect a "sample of samples". For example, itJune be more appropriate to=20 test 1,000 two-minute VoIP calls rather than a single 2,000 minute VoIP call. When considering collection of a sample of samples, = issues like the interval between samples (e.g. Poisson vs. periodic, time = of day/day of week), composition of samples (e.g. equal (Tf-T0 = duration, different packet sizes), and network considerations (e.g. run = different samples over different intervening link-host combinations) should be taken into account. For items like the interval between samples, the pattern of use of the application being measured should be=20 considered. Raisanen, Grotefeld expires June 2001 [Page = 17]=0C Internet Draft December = 2000 4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream 4.9.1 Statistics calculable from one sample As a metric based on a sample representative of certain=20 applications, some general purpose statistics (e.g. median and=20 percentile)June be less applicable than ways to characterize the=20 range of delay values recorded during the sample metrics. Example, a sample metric generates 100 packets as measured at = MP(Src) with the following measurements at MP(Dst) + 80 packets received with delay [i] <=3D 20 ms + 8 packets received with delay [i] > 20 ms + 5 packets received with corrupt packet headers + 4 packets from MP(Src) with no matching packet recorded at MP(Dst) (effectively lost) + 3 packets received with corrupt packet payload and and delay [i] <=3D 20 ms + 2 packets that duplicate one of the 80 packets received=20 correctly in the first line For this example, packets are considered acceptable if they are received with less than or equal to 20ms delays and without corrupt packet headers or packet payload. In this case, the percentage of acceptable packets is 80/100 =3D 80%. For a different application which will accept packets with corrupt packet payload and no delay bound (so long as the packet is = received),=20 the percentage of acceptable packets is (80+8+3)/100 =3D 91%. 4.9.2 Statistics calculable from multiple samples For computing statistics, a "sample of samples" series of=20 measurementsJune be performed. As discussed in section 4.8, under=20 these conditions, general purpose statistics (e.g. median, = percentile, etc.)June be more relevant as a more statistically significant number of packets are used. 5. Security Considerations 5.1 Denial of Service Attacks This metric generates a periodic stream of packets from one host = (Src) to another host (Dst) through intervening networks. This metric could be abused for denial of service attacks directed at Dst and/or the intervening network(s). Raisanen, Grotefeld expires June 2001 [Page = 18]=0C Internet Draft December = 2000 Administrators of Src, Dst, and the intervening network(s) should=20 establish bilateral or multi-lateral agreements regarding the = timing, size, and frequency of collection of sample metrics. Use of this metric in excess the terms agreed between the participantsJune BE=20 cause for immediate rejection or discard of packets or other=20 escalation procedures defined between the affected parties. 5.2 User data confidentiality This metric generates packets for a sample metric, rather than taking samples based on user data. Thus, this metric does not=20 threaten user data confidentiality. 5.3 Interference with the metric ItJune be possible to identify that a certain packet or stream of=20 packets are part of a sample metric. With that knowledge at Dst=20 and/or the intervening networks, it is possible to change the=20 processing of the packets (e.g. increasing or decreasing delay)=20 thatJune distort the measured performance. ItJune also be=20 possible to generate additional packets that appear to be part of=20 the sample metric. These additional packets are likely to perturb=20 the results of the sample measurement. To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash,June be used. 6. Acknowledgements The authors wish to thank the chairs of the IPPM WG for comments that have made the present draft clearer and more focused. Howard Stanislevic and Al Morton ahave presented useful comments and questions. The authors have also built on the substantial foundations laid by the authors of the framework for IP performance [1]. Raisanen, Grotefeld expires June 2001 [Page = 19]=0C Internet Draft December = 2000 7. References =20 [1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP = =20 Performance Metrics, IETF RFC 2330,June 1998. [2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric for IPPM, IETF RFC 2679, September 1999. [3] International Telecommunications Union recommendation I.380, February 1999. [4] S. Bradner: Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [5] ETSI TIPHON document TS-101329-5 (to be published in July). [6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay metric for IPPM, IETF RFC 2681. 8. Authors' contact information Vilho Raisanen P.O. Box 407 Communication Systems Laboratory Nokia Research Center FIN-00045 Nokia Group Finland Phone +358 9 4376 1 Fax. +358 9 4376 6852 Glenn Grotefeld Motorola, Inc. 1303 E. Algonquin Road 4th Floor Schaumburg, IL 60196 USA Phone +1 847 576-5992 Fax +1 847 538-7455 EXPIRES June 2001 ------_=_NextPart_000_01C064BA.208F49D0-- From matt@advanced.org Wed Dec 13 02:26:34 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08215 for ; Wed, 13 Dec 2000 02:26:34 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id CAA06180 for ippm-l@advanced.org; Wed, 13 Dec 2000 02:18:14 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id CAA01456 for ; Wed, 13 Dec 2000 02:18:13 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id CAA02060; Wed, 13 Dec 2000 02:18:02 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id D19D87CA; Wed, 13 Dec 2000 02:17:55 -0500 (EST) Sender: shalunov@internet2.edu To: "Cole, Robert G (Bob), ALSVC" Cc: "Henk Uijterwaal (RIPE-NCC)" , ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: Re: on 's model References: From: stanislav shalunov Date: 13 Dec 2000 02:17:55 -0500 In-Reply-To: Message-ID: <877l54zt5o.fsf@cain.internet2.edu> Lines: 23 X-Mailer: Gnus v5.7/Emacs 20.4 "Cole, Robert G (Bob), ALSVC" writes: > Will there be cases where the snmp mgmr and the OWDP source are > within the same AS and the sink is outside, in which case it may be > necessary to have a control protocol between the source and sink to > configure the sink? I think at this point it's agreed that OWDP-Control should stay, and that language should be added to the draft to make clear the fact that it's not the only way to set up OWDP-Test sessions. The remaining question is whether OWDP-Control and OWDP-Test should be in different drafts, or in the same draft. I would say that OWDP-Control should only be made a separate draft if it's clear how to make it applicable to other types of measurement traffic. (The next question, of course, being what set of other types we're talking about.) -- Stanislav Shalunov Internet Engineer, Internet2 "Hey! Who took the cork off my lunch?!" -- W. C. Fields From matt@advanced.org Wed Dec 13 13:10:11 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23628 for ; Wed, 13 Dec 2000 13:10:11 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA12907 for ippm-l@advanced.org; Wed, 13 Dec 2000 12:53:07 -0500 (EST) Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA04226; Wed, 13 Dec 2000 12:53:06 -0500 (EST) Received: from hogpa.mt.att.com ([135.16.74.2]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with SMTP id eBDHqL525598; Wed, 13 Dec 2000 12:52:22 -0500 (EST) Received: from acmortonw by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id MAA16378; Wed, 13 Dec 2000 12:52:18 -0500 Message-Id: <3.0.32.20001213125216.015c98e8@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 13 Dec 2000 12:52:19 -0500 To: ippm@advanced.org From: Al Morton Subject: Re: npmps-04 Cc: matt@advanced.org, kaeo@merike.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id MAA15217 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id MAB12907 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA23628 Vilho, Glenn, all, I agree with your proposed resolution, to indicate that incT is a nominal value and list this deviation in the error section. (I was thinking about it as error when I suggested "incTerror".) I'm not sure if the lone bullet item is sufficient (maybe a short subsection will help explain it, extracted from e-mails). At least, the suggestion below may be helpful. Thanks for addressing this, Al 4.6 Errors and uncertainties The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document [1] provides general guidance on this point, but we note here the following specifics related to >>>_periodic_streams_and_<<<< delay metrics: + Error due to variation of incT + Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points. + others... At 06:06 AM 12/13/00 +0200, vilho.raisanen@nokia.com wrote: >Hello, > >please find attached my (intended) slides, the results document, as well as >the v-04 of the npmps draft. Lacking my slides, I forgot the IP version from >the list of additions to the -03 version of the metric. Moreover, I had read >Glenn's answer to Al sloppily, which I apologize. I now realize that Glenn >was not in favour of including error of incT into the actual metric. > >After some thought, I came to the conclusion that I support Glenn's proposal >of calling incT a nominal duration of the inter-packet interval and >mentioning the possiblility of error in discussion later. If process >scheduling or some other reason causes marked variations in incT, this >should be treated as a deviation from the norm rather than a part of a >normal measurement arrangement. > >The only changes in v-04 to v-03 are as follows: > >- changed definition of incT at p. 8 into > > + incT, nominal duration of inter-packet interval > >- added text on incT error into Sec. 4.6: > > + Error due to variation of incT > >- For clarity, I added a mention of packet loss as the second sentence to to >Sec 4.4, which now reads > > The sample metric thus defined is intended to probe the delays and > the delay variation as experienced by multimedia streams of > an application. Due to the definition of the metric, also packet loss > status of packets is recorded. The delay is assumed to be measured at > transport layer level. Since a range of packet sizes and nominal > interval between packets is used, the method probes only a specific > time scale of network QoS variations. > >For those intested in a computer repair story with a human interest tint, >I'll attach one at the end of the message. For the rest, just read the docs >& the slides and you'll do fine. > > BR, > Vilho > >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Vilho Räisänen > vilho.raisanen@nokia.com > Senior research engineer > Nokia Research Center, Helsinki, Finland >%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > * * * end of real business * * * > >~~ How to boot up a stubborn computer - a small tale of fatherly wisdom ~~ > >At boot, my laptop reported that it was the modem driver that caused the >crash. From previous experience, I knew that the order in which device >drivers are loaded sometimes makes a difference, at least in some operating >systems. Armed with this piece of what I thought of as profound knowledge, I >booted NT with and without my PCMCIA NIC, without CD-ROM drive and >experimenting with all combinations. I even tried the VGA mode. To no avail. > >At this point I remembered my father's tale of a dysfunctional old radio. He >told me having opened the casing, and - lacking training in electronics - >could not do very much more. So he just blew some dust off the valves and >closed it again. Surprise, surprise: now it worked. > >Lacking better ideas, I did just the same: I located the modem, opened a >tiny cover and blew some imaginary dust off the printed board. Reassembly, >boot - succcess. > > >Attachment Converted: "C:\Utilities\Eudora\Attach\npmps-res.ppt" > >Attachment Converted: "C:\Utilities\Eudora\Attach\1kalvo.ppt" > >Attachment Converted: "C:\Utilities\Eudora\Attach\results.pdf" > >Attachment Converted: "C:\Utilities\Eudora\Attach\draft-ietf-ippm-npmps-04.txt" > From matt@advanced.org Wed Dec 13 14:01:57 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03313 for ; Wed, 13 Dec 2000 14:01:56 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id NAA10285 for ippm-l@advanced.org; Wed, 13 Dec 2000 13:58:13 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id NAA25097 for ; Wed, 13 Dec 2000 13:58:12 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id TAA29985; Wed, 13 Dec 2000 19:57:32 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id TAA19747; Wed, 13 Dec 2000 19:57:32 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Wed, 13 Dec 2000 19:57:31 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: "Cole, Robert G (Bob), ALSVC" cc: stanislav shalunov , ippm@advanced.org, "Carl W. Kalbfleisch" , Dan Romascanu , Steve Waldbusser , Russell Dietz Subject: RE: on 's model In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Bob, > [Cole, Robert G (Bob), ALSVC] Will there be cases where the snmp > mgmr and the > OWDP source are within the same AS and the sink is outside, in which > case it may be > necessary to have a control protocol between the source and sink to > configure the sink? Yes, in order to keep this generic, I think we should assume that control, source and sink are in 3 different AS'ses. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Wed Dec 13 19:58:27 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05592 for ; Wed, 13 Dec 2000 19:58:27 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id TAA04521 for ippm-l@advanced.org; Wed, 13 Dec 2000 19:50:44 -0500 (EST) Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id TAA27743 for ; Wed, 13 Dec 2000 19:50:43 -0500 (EST) Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78) id ; Wed, 13 Dec 2000 16:50:40 -0800 Message-ID: <90B65CE19D3DD411895400805F0DAA7A12A72F@mailman.sprintlabs.com> From: Sue Moon To: "'ippm@advanced.org'" Subject: Protocol - OWDP? Date: Wed, 13 Dec 2000 16:50:39 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" I must be asking a very naive question, but couldn't answer it myself. Why do we work on the protocol to run measurement experiments in IPPM working group, whose focus, I believe, is on performance metrics? -Sue From matt@advanced.org Wed Dec 13 20:15:55 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09709 for ; Wed, 13 Dec 2000 20:15:55 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id UAA19294 for ippm-l@advanced.org; Wed, 13 Dec 2000 20:10:15 -0500 (EST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id UAA07193 for ; Wed, 13 Dec 2000 20:10:13 -0500 (EST) Received: from kantoor.ripe.net (kantoor.ripe.net [193.0.1.98]) by birch.ripe.net (8.8.8/8.8.8) with ESMTP id CAA20296; Thu, 14 Dec 2000 02:09:42 +0100 (CET) Received: from localhost (henk@localhost) by kantoor.ripe.net (8.8.8/8.8.5) with ESMTP id CAA17792; Thu, 14 Dec 2000 02:09:42 +0100 (CET) X-Authentication-Warning: kantoor.ripe.net: henk owned process doing -bs Date: Thu, 14 Dec 2000 02:09:42 +0100 (CET) From: "Henk Uijterwaal (RIPE-NCC)" To: Sue Moon cc: "'ippm@advanced.org'" Subject: Re: Protocol - OWDP? In-Reply-To: <90B65CE19D3DD411895400805F0DAA7A12A72F@mailman.sprintlabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 13 Dec 2000, Sue Moon wrote: > Why do we work on the protocol to run measurement experiments in IPPM > working group, whose focus, I believe, is on performance metrics? Making the implementations interoperable is a good thing, as it allows you to measure between sites equiped with measurement hardware from different implementations. The people implementing the metrics follow the IPPM WG, so one might as well discuss the practical details of making the metrics interoperable there. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.535-4414, Fax -4445 1016 AB Amsterdam Home: +31.20.4195305 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ A man can take a train and never reach his destination. (Kerouac, well before RFC2780). From matt@advanced.org Thu Dec 14 00:25:37 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16333 for ; Thu, 14 Dec 2000 00:25:37 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id AAA01456 for ippm-l@advanced.org; Thu, 14 Dec 2000 00:19:37 -0500 (EST) Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id AAA06698; Thu, 14 Dec 2000 00:19:36 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id eBE5JYI22765; Thu, 14 Dec 2000 00:19:34 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: "Sue Moon" , Cc: "Matt Zekauskas" , "Merike Kaeo" Subject: RE: Protocol - OWDP? Date: Thu, 14 Dec 2000 00:25:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <90B65CE19D3DD411895400805F0DAA7A12A72F@mailman.sprintlabs.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit To add to what Henk said, people within the working group thought that making interoperable implementations possible would be a good thing, implementors were already in the group, and it wasn't being done elsewhere. However, it is strictly out of the current charter, but is allowed by the proposed charter (and included in milestones). A revised charter based on comments here and in the working group meeting yesterday will be posted within the next few days to the list. If you feel that some of the activities are not appropriate (or if you have other activities that you feel we should be addressing), please comment on the revised charter. --Matt > -----Original Message----- > From: Sue Moon [mailto:Sbmoon@sprintlabs.com] > Sent: Wednesday, December 13, 2000 7:51 PM > To: 'ippm@advanced.org' > Subject: Protocol - OWDP? > > > I must be asking a very naive question, > but couldn't answer it myself. > Why do we work on the protocol to run measurement > experiments in IPPM working group, whose focus, I believe, > is on performance metrics? > -Sue > From matt@advanced.org Thu Dec 14 00:54:41 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28210 for ; Thu, 14 Dec 2000 00:54:41 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id AAA02594 for ippm-l@advanced.org; Thu, 14 Dec 2000 00:51:11 -0500 (EST) Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id AAA07584; Thu, 14 Dec 2000 00:51:10 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id eBE5p9I23651; Thu, 14 Dec 2000 00:51:09 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Cc: "Matt Zekauskas" , , "William G. Couch" Subject: Recent updates on IP QoS metrics in ITU-T SG 13 Date: Thu, 14 Dec 2000 00:56:37 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit Lubomir Citkusev (copied on this mail) created a short presentation on the U.S. position on IP QoS classes in Y.1541 into the recent ITU-T SG 13 meeting and the results of the meeting on this topic. However, due to the limited time available, we could not fit his presentation into the schedule. The presentation itself has been pdf'ified and put on the ippm web server. http://www.advanced.org/IPPM/Meetings/ietf49/ITU-2000-12-12-Citkusev-IPPM_QoS_Dec00.pdf The three documents it references are available on the web site as well. Temporary Document 4-40 http://www.advanced.org/IPPM/Meetings/ietf49/ITU-2000-12-12-4-40.pdf Temporary Document 4-41 http://www.advanced.org/IPPM/Meetings/ietf49/ITU-2000-12-12-4-41.pdf Temporary Document 4-44 http://www.advanced.org/IPPM/Meetings/ietf49/ITU-2000-12-12-4-44.pdf If anyone has a comment based on our "IETF" perspective, please comment either here, or directly to Lubomir. If you do comment directly, I would appreciate a CC to myself. --Matt From matt@advanced.org Thu Dec 14 12:33:19 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05055 for ; Thu, 14 Dec 2000 12:33:19 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA18378 for ippm-l@advanced.org; Thu, 14 Dec 2000 12:26:36 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA12674 for ; Thu, 14 Dec 2000 12:26:35 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA04194 for ; Thu, 14 Dec 2000 12:26:33 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 30ED57CA; Thu, 14 Dec 2000 12:26:26 -0500 (EST) Resent-Sender: shalunov@internet2.edu Resent-To: ippm@advanced.org Resent-From: stanislav shalunov Resent-Date: 14 Dec 2000 12:26:26 -0500 X-From-Line: bmah@cisco.com Thu Dec 14 03:25:09 2000 Delivered-To: shalunov@localhost.internet2.edu Received: from localhost (localhost [127.0.0.1]) by cain.internet2.edu (Postfix) with ESMTP id 76610580 for ; Thu, 14 Dec 2000 03:25:06 -0500 (EST) Received: from mail.internet2.edu by localhost with POP3 (fetchmail-5.2.0) for shalunov@localhost (single-drop); Thu, 14 Dec 2000 03:25:06 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.CISCO.com [171.69.43.88]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id AAA23797 for ; Thu, 14 Dec 2000 00:30:54 -0500 (EST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id VAA04115; Wed, 13 Dec 2000 21:30:26 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id eBE5UNw59574; Wed, 13 Dec 2000 21:30:23 -0800 (PST) (envelope-from bmah) Message-Id: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: shalunov@internet2.edu, ben@advanced.org, matt@advanced.org Cc: bmah@cisco.com Subject: draft-ietf-ippm-owdp-01.txt comments From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1082595515P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 13 Dec 2000 21:30:23 -0800 Sender: shalunov@internet2.edu Original-Sender: bmah@cisco.com X-UIDL: 1abcfd5a0e52fe2a0a282edde8e7b68d Lines: 78 Resent-Message-Id: <20001214172626.30ED57CA@cain.internet2.edu> --==_Exmh_1082595515P Content-Type: text/plain; charset=us-ascii Hi-- I had a few comments about the latest incarnation of the OWDP draft. Hope these will be helpful, or at least entertaining: 1. In section 4.1, some mention is made of the "modes octet". It looks to me, however, like the modes field in the connection setup message is really 16 bits, or two octets. Thus, the "unused" space is really 14 octets, not 15. 2. As you know, TCP is a bytestream protocol, and thus doesn't guarantee atomic delivery of messages (with message boundaries preserved). This means that either messages need to be fixed sized, or there needs to be some way of determining the end of each message. However, it's not clear, for example, how long a Request-Session (4.3) message is...how long is the zero padding field at the end? 3. What is an implementation supposed to do in the case of partial delivery of a control message (i.e. sender failure)? I didn't see this specified. 4. A number of fields are multi-byte quantities. I didn't see any discussion of byte-ordering. I can probably assume you meant network byte-order, but this really should be mentioned at least once...something to the effect of, "All multi-octet quantities are represented in network byte order." 5. A philosophical statement: I've become a real fan over the years of control protocols that are line-oriented, and use ASCII text for their messages. It makes for greater ease of understanding and debugging. Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you thought about this? 5a. As a side note, I think that if either end of the protocol becomes desynchronized (like due to a faulty implementation), it'll be rather difficult to get resynchronized with respect to where the message boundaries are. 6. Back to the connection setup in 4.1, I note that there isn't a mode *bit* (you used the term "mode value") for unencrypted transfers. Was this an oversight? Also I note that according to the protocol as defined, it's possible for the client to respond with a contradictory set of mode bits...presumably the server should drop the connection or do some similarly drastic thing if this happens. 7. The server's second message in connection setup (does it have a name?) has a field called "Yes/No". I suggest a more descriptive name. It also might be useful to have a way for a server to communicate to a client why an authentication was rejected. (This gets a lot easier if you buy into #5 above.) OK, not quite as organized as I'd like and certainly not a comprehensive analysis. Just a few thoughts I had while reading through this draft over the past couple days. Bruce. --==_Exmh_1082595515P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6OFrv2MoxcVugUsMRAhY0AJ0X7DPMWelcYJNBiy8EpPJlMwG2mQCgkMLa 2zYvCfcftyRwpSsEQwilWl4= =DMcc -----END PGP SIGNATURE----- --==_Exmh_1082595515P-- From matt@advanced.org Thu Dec 14 12:33:40 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05096 for ; Thu, 14 Dec 2000 12:33:39 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA21529 for ippm-l@advanced.org; Thu, 14 Dec 2000 12:29:01 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA17928 for ; Thu, 14 Dec 2000 12:26:44 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA04206 for ; Thu, 14 Dec 2000 12:26:42 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 8EACA7CA; Thu, 14 Dec 2000 12:26:36 -0500 (EST) Resent-Sender: shalunov@internet2.edu Resent-To: ippm@advanced.org Resent-From: stanislav shalunov Resent-Date: 14 Dec 2000 12:26:36 -0500 X-From-Line: shalunov@internet2.edu Thu Dec 14 04:43:21 2000 Delivered-To: shalunov@localhost.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 9B24A7CA; Thu, 14 Dec 2000 04:43:21 -0500 (EST) Sender: shalunov@internet2.edu To: "Bruce A. Mah" Cc: Ben Teitelbaum , Matthew Zekauskas Subject: Re: draft-ietf-ippm-owdp-01.txt comments References: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> From: stanislav shalunov Date: 14 Dec 2000 04:43:21 -0500 In-Reply-To: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> Message-ID: <871yvbxrra.fsf@cain.internet2.edu> X-Mailer: Gnus v5.7/Emacs 20.4 Lines: 125 Resent-Message-Id: <20001214172636.8EACA7CA@cain.internet2.edu> bmah@cisco.com (Bruce A. Mah) writes: > I had a few comments about the latest incarnation of the OWDP draft. > Hope these will be helpful, or at least entertaining: Bruce, Thank you very much for high-quality comments! I'll incorporate fixes before -02 version, which will reflect IPPM session discussion, goes out. Ben, Matt, I would make server drop connection after a possible timeout in (3) and do nothing about (5a) [rationale below]; we can discuss it on the plane if you can think of something smarter to do. > 1. In section 4.1, some mention is made of the "modes octet". It looks to > me, however, like the modes field in the connection setup message is > really 16 bits, or two octets. Thus, the "unused" space is really 14 > octets, not 15. Thanks for noticing it. Initially, I made Modes one octet wide, then decided to add more space for possible future expansion. Someone suggested that 13 spare modes might not be enough, so I'll increase it even further (unused space is there anyway). > 2. As you know, TCP is a bytestream protocol, and thus doesn't > guarantee atomic delivery of messages (with message boundaries > preserved). This means that either messages need to be fixed sized, or > there needs to be some way of determining the end of each message. The intent was to make it possible to discover the size of a message after reading (and, possibly, decrypting) first 16 octets. Each message type has a specific size. > However, it's not clear, for example, how long a Request-Session (4.3) > message is...how long is the zero padding field at the end? Those three lines attempt to say it's 12 octets. I guess we should say it explicitly everywhere. > 3. What is an implementation supposed to do in the case of partial > delivery of a control message (i.e. sender failure)? I didn't see this > specified. We need to specify a timeout, I suppose. Any suggestions of good, currently fashionable values? > 4. A number of fields are multi-byte quantities. I didn't see any > discussion of byte-ordering. I can probably assume you meant > network byte-order, but this really should be mentioned at least > once...something to the effect of, "All multi-octet quantities are > represented in network byte order." OK. > 5. A philosophical statement: I've become a real fan over the years of > control protocols that are line-oriented, and use ASCII text for their > messages. It makes for greater ease of understanding and debugging. > Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you > thought about this? Yes. The trade-off was: easy way to authenticate messages and a way to encrypt them in a mode already standartized by IETF or be line-oriented. A decision was made after some internal discussion to go with the former option. Do you feel the advantages of easy understanding and debugging outweight CBC mode properties? Additional advantage of simple binary protocol is that it's slightly easier to code. (Of course, making reading tcpdump -x output harder at the same time.) > 5a. As a side note, I think that if either end of the protocol > becomes desynchronized (like due to a faulty implementation), > it'll be rather difficult to get resynchronized with respect to > where the message boundaries are. Yes... I don't see how we could easily fix it. On the other hand, there are only four commands, each having a fixed size. Each of the commands is mandatory and will be used even in simple scenarios. I would expect an implementation that desynchronizes sometimes to desynchronize during almost every session (and the bug would thus be noticed and fixed). It's not clear to me what would one do if desynchronization happens, and one later manages to resynchronize. State would not be known... (Do we say "Stop-Sessions" or "Retrieve-Session"?) > 6. Back to the connection setup in 4.1, I note that there isn't a mode > *bit* (you used the term "mode value") for unencrypted transfers. Was > this an oversight? In unauthenticated mode nothing at all is encrypted. Or did you mean something else? > Also I note that according to the protocol as defined, it's possible > for the client to respond with a contradictory set of mode > bits...presumably the server should drop the connection or do some > similarly drastic thing if this happens. The client actually MUST respond with no more than one bit set in Mode field. This needs to be clarified in the draft (oversight). > 7. The server's second message in connection setup (does it have a > name?) has a field called "Yes/No". I suggest a more descriptive > name. "Accept" was used in similar situations elsewhere. Sounds better? > It also might be useful to have a way for a server to communicate to a > client why an authentication was rejected. (This gets a lot easier if > you buy into #5 above.) A negative response is any non-zero value, here and elsewhere. We intended to define a set of error codes once the draft is more mature. Would that be sufficient? -- Stanislav Shalunov Internet Engineer, Internet2 A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt From matt@advanced.org Thu Dec 14 12:33:44 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05125 for ; Thu, 14 Dec 2000 12:33:43 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id MAA11659 for ippm-l@advanced.org; Thu, 14 Dec 2000 12:29:12 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id MAA14809 for ; Thu, 14 Dec 2000 12:27:03 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA04217 for ; Thu, 14 Dec 2000 12:27:01 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 20A307CA; Thu, 14 Dec 2000 12:26:54 -0500 (EST) Resent-Sender: shalunov@internet2.edu Resent-To: ippm@advanced.org Resent-From: stanislav shalunov Resent-Date: 14 Dec 2000 12:26:54 -0500 X-From-Line: bmah@cisco.com Thu Dec 14 12:05:19 2000 Delivered-To: shalunov@localhost.internet2.edu Received: from localhost (localhost [127.0.0.1]) by cain.internet2.edu (Postfix) with ESMTP id DF05E5AB for ; Thu, 14 Dec 2000 12:05:13 -0500 (EST) Received: from mail.internet2.edu by localhost with POP3 (fetchmail-5.2.0) for shalunov@localhost (single-drop); Thu, 14 Dec 2000 12:05:13 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.CISCO.com [171.71.163.11]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA03716 for ; Thu, 14 Dec 2000 12:03:47 -0500 (EST) Received: from bmah-freebsd-0.cisco.com (bmah-freebsd-0.cisco.com [171.70.84.42]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA16235; Thu, 14 Dec 2000 09:02:51 -0800 (PST) Received: (from bmah@localhost) by bmah-freebsd-0.cisco.com (8.11.1/8.11.1) id eBEH2im63987; Thu, 14 Dec 2000 09:02:44 -0800 (PST) (envelope-from bmah) Message-Id: <200012141702.eBEH2im63987@bmah-freebsd-0.cisco.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: stanislav shalunov Cc: "Bruce A. Mah" , Ben Teitelbaum , Matthew Zekauskas Subject: Re: draft-ietf-ippm-owdp-01.txt comments In-Reply-To: <871yvbxrra.fsf@cain.internet2.edu> References: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> <871yvbxrra.fsf@cain.internet2.edu> Comments: In-reply-to stanislav shalunov message dated "14 Dec 2000 04:43:21 -0500." From: bmah@cisco.com (Bruce A. Mah) Reply-To: bmah@cisco.com X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1226217620P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 14 Dec 2000 09:02:44 -0800 Sender: shalunov@internet2.edu Original-Sender: bmah@cisco.com X-UIDL: a2f482d2852387a2ff7c907890c19e41 Lines: 162 Resent-Message-Id: <20001214172654.20A307CA@cain.internet2.edu> --==_Exmh_1226217620P Content-Type: text/plain; charset=us-ascii If memory serves me right, stanislav shalunov wrote: > I'll incorporate fixes before -02 version, which will reflect IPPM > session discussion, goes out. I forgot, for some reason, to CC the ippm list. If you think it's useful, feel free to forward my comments there. [snip] > > 2. As you know, TCP is a bytestream protocol, and thus doesn't > > guarantee atomic delivery of messages (with message boundaries > > preserved). This means that either messages need to be fixed sized, or > > there needs to be some way of determining the end of each message. > > The intent was to make it possible to discover the size of a message > after reading (and, possibly, decrypting) first 16 octets. Each > message type has a specific size. OK, sounds good. Upon reading the draft a little more closely, I now realize that the encryption parameters are meant to apply to subsequent OWDP-Control messages, where I originally thought they applied to the OWDP-Test packets. This raises another question in my mind...what about just using (for example) SSL or some other more established encryption layer to encrypt the entire contents of the TCP connection? That should simplify both the protocol and its implementation at least a little bit (code reuse and all that). > > However, it's not clear, for example, how long a Request-Session (4.3) > > message is...how long is the zero padding field at the end? > > Those three lines attempt to say it's 12 octets. I guess we should > say it explicitly everywhere. I generally assume when I'm reading these things that every diagram is "not to scale". :-) > > 3. What is an implementation supposed to do in the case of partial > > delivery of a control message (i.e. sender failure)? I didn't see this > > specified. > > We need to specify a timeout, I suppose. Any suggestions of good, > currently fashionable values? Hmmm. The only values that come to mind are those that sendmail uses for SMTP conversations. They're highly configurable but I think they're on the order of minutes. I can't remember if SMTP specifies exact values or not. > > 5. A philosophical statement: I've become a real fan over the years of > > control protocols that are line-oriented, and use ASCII text for their > > messages. It makes for greater ease of understanding and debugging. > > Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you > > thought about this? > > Yes. The trade-off was: easy way to authenticate messages and a way > to encrypt them in a mode already standartized by IETF or be > line-oriented. A decision was made after some internal discussion to > go with the former option. Do you feel the advantages of easy > understanding and debugging outweight CBC mode properties? No, not necessarily. (IETF standardized AES in CBC mode? I missed that part, I guess. I have to go look up exactly what cipher block chaining means now.) > Additional advantage of simple binary protocol is that it's slightly > easier to code. (Of course, making reading tcpdump -x output harder > at the same time.) Hmmm. I'll reiterate my preference for ASCII text, line-oriented protocols, and stop there. :-) (Wait, in the cases where you're encrypting, isn't tcpdump -x going to be real hard to read anyways?) > > 5a. As a side note, I think that if either end of the protocol > > becomes desynchronized (like due to a faulty implementation), > > it'll be rather difficult to get resynchronized with respect to > > where the message boundaries are. > > Yes... I don't see how we could easily fix it. On the other hand, > there are only four commands, each having a fixed size. Each of the > commands is mandatory and will be used even in simple scenarios. > I would expect an implementation that desynchronizes sometimes to > desynchronize during almost every session (and the bug would thus be > noticed and fixed). OK, true. It's not like this is the FTP control protocol, which has $DIETY knows how many commands, all with variable sizes. > It's not clear to me what would one do if desynchronization happens, > and one later manages to resynchronize. State would not be known... > (Do we say "Stop-Sessions" or "Retrieve-Session"?) I'm not sure what the right answer for this is, either. This is not a huge problem, it just affects the ability of the protocol to be robust in the face of failures (note that the TCP checksum mechanism isn't 100% reliable). On the other hand, for scenarios where encryption is used, it's likely that any integrity checks in that layer would catch problems like this and deal with them in some way. > > 6. Back to the connection setup in 4.1, I note that there isn't a mode > > *bit* (you used the term "mode value") for unencrypted transfers. Was > > this an oversight? > > In unauthenticated mode nothing at all is encrypted. Or did you mean > something else? What I meant was that there's a bit that means "will accept unauthenticated", a bit that means "will accept authenticated", and a bit that means "will accept encrypted". My thinking is colored by using PGP for many years; in that system, encryption and authentication are orthogonal as you probably know. So I was thinking that there should be a bit that means "will accept unencrypted", for completeness. It sounds from your comment that this is not necessary. [snip] > > 7. The server's second message in connection setup (does it have a > > name?) has a field called "Yes/No". I suggest a more descriptive > > name. > > "Accept" was used in similar situations elsewhere. Sounds better? Much better. :-) > > It also might be useful to have a way for a server to communicate to a > > client why an authentication was rejected. (This gets a lot easier if > > you buy into #5 above.) > > A negative response is any non-zero value, here and elsewhere. We > intended to define a set of error codes once the draft is more mature. > Would that be sufficient? Yeah, that sounds good. You also have those 14 unused bytes to play with; the server can just blat some ASCII text into those bytes. Cheers, Bruce. --==_Exmh_1226217620P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: Exmh version 2.2 06/23/2000 iD8DBQE6OP002MoxcVugUsMRAnbYAKDb+umJLO9MgDtE3P5h5iub6hImeQCg+3qw o4b+XBzCz5+bmb8equCRPxM= =L6mP -----END PGP SIGNATURE----- --==_Exmh_1226217620P-- From matt@advanced.org Fri Dec 15 08:07:31 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00566 for ; Fri, 15 Dec 2000 08:07:30 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id IAA11041 for ippm-l@advanced.org; Fri, 15 Dec 2000 08:03:16 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA08650 for ; Fri, 15 Dec 2000 07:59:39 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id HAA19949 for ; Fri, 15 Dec 2000 07:59:38 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id B10A77CB; Fri, 15 Dec 2000 07:59:31 -0500 (EST) Resent-Sender: shalunov@internet2.edu Resent-To: ippm@advanced.org Resent-From: stanislav shalunov Resent-Date: 15 Dec 2000 07:59:31 -0500 X-From-Line: ben@advanced.org Fri Dec 15 07:57:55 2000 Delivered-To: shalunov@localhost.internet2.edu Received: from localhost (localhost [127.0.0.1]) by cain.internet2.edu (Postfix) with ESMTP id 853627CA for ; Fri, 15 Dec 2000 07:57:55 -0500 (EST) Received: from mail.internet2.edu by localhost with POP3 (fetchmail-5.2.0) for shalunov@localhost (single-drop); Fri, 15 Dec 2000 07:57:55 -0500 (EST) Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id RAA10951 for ; Thu, 14 Dec 2000 17:14:10 -0500 (EST) Received: from mucus.advanced.org (localhost [127.0.0.1]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA01648; Thu, 14 Dec 2000 17:13:57 -0500 (EST) Received: from internet2.edu (localhost [127.0.0.1]) by mucus.advanced.org (Postfix) with ESMTP id 5AA9A10CD; Thu, 14 Dec 2000 17:17:25 -0500 (EST) Sender: shalunov@internet2.edu Original-Sender: ben@advanced.org Message-ID: <3A39224A.CF7942E8@internet2.edu> Date: Thu, 14 Dec 2000 14:40:58 -0500 From: Ben Teitelbaum Organization: Internet2 (UCAID) / Advanced Network & Services X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: stanislav shalunov , "Bruce A. Mah" Cc: Matthew Zekauskas Subject: Re: draft-ietf-ippm-owdp-01.txt comments References: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> <871yvbxrra.fsf@cain.internet2.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-UIDL: 8da5fc8d34d8825dc303abb75903b105 Lines: 163 Resent-Message-Id: <20001215125931.B10A77CB@cain.internet2.edu> Content-Transfer-Encoding: 7bit Bruce, Let me add my thanks to you for your careful reading and thoughtful suggestions. Stas, I agreed with all your responses to Bruce, with the possible exception of your response to issue 2 (finding message boundaries in the TCP byte stream). Let me make sure I'm understanding. I think what you are saying is that we don't need a length field or some sort of message delimiter, because: 1) Each message type is of fixed size; 2) Each command begins with a "Command-Type" octet; 3) Command response messages, though lacking a "Command-Type" octet happen in lock-step with the commands; Is this correct? I think a state machine diagram might help make the lock-step-ness easier to see. I'll try to draw one. PS: Matt and I don't see you on the plane and have concluded that you missed the flight; hope you are OK and find your way to Ann Arbor OK. stanislav shalunov wrote: > > bmah@cisco.com (Bruce A. Mah) writes: > > > I had a few comments about the latest incarnation of the OWDP draft. > > Hope these will be helpful, or at least entertaining: > > Bruce, > > Thank you very much for high-quality comments! > > I'll incorporate fixes before -02 version, which will reflect IPPM > session discussion, goes out. > > Ben, Matt, > > I would make server drop connection after a possible timeout in (3) > and do nothing about (5a) [rationale below]; we can discuss it on the > plane if you can think of something smarter to do. > > > 1. In section 4.1, some mention is made of the "modes octet". It looks to > > me, however, like the modes field in the connection setup message is > > really 16 bits, or two octets. Thus, the "unused" space is really 14 > > octets, not 15. > > Thanks for noticing it. Initially, I made Modes one octet wide, then > decided to add more space for possible future expansion. Someone > suggested that 13 spare modes might not be enough, so I'll increase it > even further (unused space is there anyway). > > > 2. As you know, TCP is a bytestream protocol, and thus doesn't > > guarantee atomic delivery of messages (with message boundaries > > preserved). This means that either messages need to be fixed sized, or > > there needs to be some way of determining the end of each message. > > The intent was to make it possible to discover the size of a message > after reading (and, possibly, decrypting) first 16 octets. Each > message type has a specific size. > > > However, it's not clear, for example, how long a Request-Session (4.3) > > message is...how long is the zero padding field at the end? > > Those three lines attempt to say it's 12 octets. I guess we should > say it explicitly everywhere. > > > 3. What is an implementation supposed to do in the case of partial > > delivery of a control message (i.e. sender failure)? I didn't see this > > specified. > > We need to specify a timeout, I suppose. Any suggestions of good, > currently fashionable values? > > > 4. A number of fields are multi-byte quantities. I didn't see any > > discussion of byte-ordering. I can probably assume you meant > > network byte-order, but this really should be mentioned at least > > once...something to the effect of, "All multi-octet quantities are > > represented in network byte order." > > OK. > > > 5. A philosophical statement: I've become a real fan over the years of > > control protocols that are line-oriented, and use ASCII text for their > > messages. It makes for greater ease of understanding and debugging. > > Examples of protocols like this are SMTP, NNTP, FTP, and HTTP. Have you > > thought about this? > > Yes. The trade-off was: easy way to authenticate messages and a way > to encrypt them in a mode already standartized by IETF or be > line-oriented. A decision was made after some internal discussion to > go with the former option. Do you feel the advantages of easy > understanding and debugging outweight CBC mode properties? > > Additional advantage of simple binary protocol is that it's slightly > easier to code. (Of course, making reading tcpdump -x output harder > at the same time.) > > > 5a. As a side note, I think that if either end of the protocol > > becomes desynchronized (like due to a faulty implementation), > > it'll be rather difficult to get resynchronized with respect to > > where the message boundaries are. > > Yes... I don't see how we could easily fix it. On the other hand, > there are only four commands, each having a fixed size. Each of the > commands is mandatory and will be used even in simple scenarios. > I would expect an implementation that desynchronizes sometimes to > desynchronize during almost every session (and the bug would thus be > noticed and fixed). > > It's not clear to me what would one do if desynchronization happens, > and one later manages to resynchronize. State would not be known... > (Do we say "Stop-Sessions" or "Retrieve-Session"?) > > > 6. Back to the connection setup in 4.1, I note that there isn't a mode > > *bit* (you used the term "mode value") for unencrypted transfers. Was > > this an oversight? > > In unauthenticated mode nothing at all is encrypted. Or did you mean > something else? > > > Also I note that according to the protocol as defined, it's possible > > for the client to respond with a contradictory set of mode > > bits...presumably the server should drop the connection or do some > > similarly drastic thing if this happens. > > The client actually MUST respond with no more than one bit set in Mode > field. This needs to be clarified in the draft (oversight). > > > 7. The server's second message in connection setup (does it have a > > name?) has a field called "Yes/No". I suggest a more descriptive > > name. > > "Accept" was used in similar situations elsewhere. Sounds better? > > > It also might be useful to have a way for a server to communicate to a > > client why an authentication was rejected. (This gets a lot easier if > > you buy into #5 above.) > > A negative response is any non-zero value, here and elsewhere. We > intended to define a set of error codes once the draft is more mature. > Would that be sufficient? > > -- > Stanislav Shalunov Internet Engineer, Internet2 > > A large number of installed systems work by fiat. That is, they work > by being declared to work. -- Anatol Holt -- ,,, `o-o- < Benjamin Teitelbaum - Advanced Network & Services, Inc. . Internet2 From matt@advanced.org Fri Dec 15 08:07:51 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00638 for ; Fri, 15 Dec 2000 08:07:50 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id HAA02307 for ippm-l@advanced.org; Fri, 15 Dec 2000 07:57:57 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA03679 for ; Fri, 15 Dec 2000 07:57:55 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id HAA19918; Fri, 15 Dec 2000 07:57:54 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id E85647CA; Thu, 14 Dec 2000 14:58:50 -0500 (EST) Sender: shalunov@internet2.edu To: "Bruce A. Mah" Cc: ippm@advanced.org Subject: Re: draft-ietf-ippm-owdp-01.txt comments References: <200012140530.eBE5UNw59574@bmah-freebsd-0.cisco.com> <871yvbxrra.fsf@cain.internet2.edu> <200012141702.eBEH2im63987@bmah-freebsd-0.cisco.com> From: stanislav shalunov Date: 14 Dec 2000 14:58:50 -0500 In-Reply-To: <200012141702.eBEH2im63987@bmah-freebsd-0.cisco.com> Message-ID: <87bsuewz9h.fsf@cain.internet2.edu> Lines: 87 X-Mailer: Gnus v5.7/Emacs 20.4 bmah@cisco.com (Bruce A. Mah) writes: > Upon reading the draft a little more closely, I now realize that the > encryption parameters are meant to apply to subsequent OWDP-Control > messages, where I originally thought they applied to the OWDP-Test > packets. Encryption parameters are applied to both OWDP-Control and OWDP-Test. > This raises another question in my mind...what about just using (for > example) SSL or some other more established encryption layer to > encrypt the entire contents of the TCP connection? That should > simplify both the protocol and its implementation at least a little > bit (code reuse and all that). Several reasons: * OWDP-Test needs a way to encrypt/authenticate messages anyway. Once you have your own encryption in OWDP-Test, why not use it in OWDP-Control and depend on just one external library (rather than two: AES + SSL). * SSL doesn't authenticate individual messages. If one highjacks its TCP connection and modifies some bits, all subsequent bits will decypher to garbage, but there's no clear way to check for this. With knowledge of message boundaries of underlying protocol one can authenticate each message. * SSL is complex and solves slightly different problem. OWDP-Control's mechanisms are light-weight. You'd have about the same amount of security-related code in both cases (possibly decrypt after read, possibly encrypt before write), but AES library would be two orders of magnitude smaller than available SSL libraries. > I generally assume when I'm reading these things that every diagram is > "not to scale". :-) Explicitly specified size of all long fields everywhere. > Hmmm. The only values that come to mind are those that sendmail > uses for SMTP conversations. They're highly configurable but I think > they're on the order of minutes. I can't remember if SMTP specifies > exact values or not. Specified 30 minutes for now. It's more than what most TCPs would take to timeout on the other end (if the problem is with network connection). > IETF standardized AES in CBC mode? Not AES, but CBC itself is explained in an IPSec RFC. (I'm disconnected right now, can't provide reference.) > (Wait, in the cases where you're encrypting, isn't tcpdump -x going > to be real hard to read anyways?) That's right. Additional reason why it doesn't matter much if it's block- or line-oriented. And, since block-oriented protocol has these other advantages... > What I meant was that there's a bit that means "will accept > unauthenticated", a bit that means "will accept authenticated", and a > bit that means "will accept encrypted". My thinking is colored by > using PGP for many years; in that system, encryption and authentication > are orthogonal as you probably know. So I was thinking that there > should be a bit that means "will accept unencrypted", for completeness. > It sounds from your comment that this is not necessary. Authenticating in some way and then having a cleartext connection doesn't help against active man-in-the-middle attacks. Since AES encrypting is very cheap, I don't see a reason to have such a mode. > Yeah, that sounds good. You also have those 14 unused bytes to play > with; the server can just blat some ASCII text into those bytes. I thought about it. Until now, there wasn't anything in the protocol that was intended for humans (everything is for computers). I feel that having descriptive error codes would be more convenient for appliances and automated tests. If there's a place to put a human explanation, the implementer could be pushed towards using a more generic error code plus a verbal description of the error condition. -- Stanislav Shalunov Internet Engineer, Internet2 "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijkstra From matt@advanced.org Fri Dec 15 16:30:22 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23098 for ; Fri, 15 Dec 2000 16:30:22 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA14587 for ippm-l@advanced.org; Fri, 15 Dec 2000 16:25:17 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA07472; Fri, 15 Dec 2000 16:25:15 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA07226; Fri, 15 Dec 2000 14:25:14 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA00920; Fri, 15 Dec 2000 14:25:14 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Dec 2000 15:25:12 -0600 Message-ID: From: Grotefeld Glenn-cecl03 To: "'vilho.raisanen@nokia.com'" , ippm@advanced.org Cc: matt@advanced.org, kaeo@merike.com Subject: RE: npmps-04 Date: Fri, 15 Dec 2000 15:25:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id QAA07153 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id QAB14587 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA23098 Vilho, It appears that your text REPLACE command played a trick on you. In a number of places (I won't say every case), where you intended to update the expiration from "May 2001" to "June 2001", it also replaced " may" in the text with "June". I leave it to our chairs to inform us whether we should be using the official IETF file identifiers in a version that is circulated directly rather than sent to the Internet drafts sited and then posted and announced. Do we need to go to -05 for the next version? Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 576-5992 847 538-7455 FAX ~-----Original Message----- ~From: vilho.raisanen@nokia.com [mailto:vilho.raisanen@nokia.com] ~Sent: Tuesday, December 12, 2000 10:07 PM ~To: ippm@advanced.org ~Cc: matt@advanced.org; kaeo@merike.com ~Subject: npmps-04 ~ ~ ~Hello, ~ ~please find attached my (intended) slides, the results ~document, as well as ~the v-04 of the npmps draft. Lacking my slides, I forgot the ~IP version from ~the list of additions to the -03 version of the metric. ~Moreover, I had read ~Glenn's answer to Al sloppily, which I apologize. I now ~realize that Glenn ~was not in favour of including error of incT into the actual metric. ~ ~After some thought, I came to the conclusion that I support ~Glenn's proposal ~of calling incT a nominal duration of the inter-packet interval and ~mentioning the possiblility of error in discussion later. If process ~scheduling or some other reason causes marked variations in incT, this ~should be treated as a deviation from the norm rather than a part of a ~normal measurement arrangement. ~ ~The only changes in v-04 to v-03 are as follows: ~ ~- changed definition of incT at p. 8 into ~ ~ + incT, nominal duration of inter-packet interval ~ ~- added text on incT error into Sec. 4.6: ~ ~ + Error due to variation of incT ~ ~- For clarity, I added a mention of packet loss as the second ~sentence to to ~Sec 4.4, which now reads ~ ~ The sample metric thus defined is intended to probe the delays and ~ the delay variation as experienced by multimedia streams of ~ an application. Due to the definition of the metric, also ~packet loss ~ status of packets is recorded. The delay is assumed to be ~measured at ~ transport layer level. Since a range of packet sizes and nominal ~ interval between packets is used, the method probes only a specific ~ time scale of network QoS variations. ~ ~For those intested in a computer repair story with a human ~interest tint, ~I'll attach one at the end of the message. For the rest, just ~read the docs ~& the slides and you'll do fine. ~ ~ BR, ~ Vilho ~ ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~ Vilho Räisänen ~ vilho.raisanen@nokia.com ~ Senior research engineer ~ Nokia Research Center, Helsinki, Finland ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~ ~ * * * end of real business * * * ~ ~~~ How to boot up a stubborn computer - a small tale of ~fatherly wisdom ~~ ~ ~At boot, my laptop reported that it was the modem driver that ~caused the ~crash. From previous experience, I knew that the order in which device ~drivers are loaded sometimes makes a difference, at least in ~some operating ~systems. Armed with this piece of what I thought of as ~profound knowledge, I ~booted NT with and without my PCMCIA NIC, without CD-ROM drive and ~experimenting with all combinations. I even tried the VGA ~mode. To no avail. ~ ~At this point I remembered my father's tale of a dysfunctional ~old radio. He ~told me having opened the casing, and - lacking training in ~electronics - ~could not do very much more. So he just blew some dust off the ~valves and ~closed it again. Surprise, surprise: now it worked. ~ ~Lacking better ideas, I did just the same: I located the ~modem, opened a ~tiny cover and blew some imaginary dust off the printed board. ~Reassembly, ~boot - succcess. ~ ~ From matt@advanced.org Mon Dec 18 16:19:43 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15776 for ; Mon, 18 Dec 2000 16:19:43 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA05270 for ippm-l@advanced.org; Mon, 18 Dec 2000 16:08:56 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA04766 for ; Mon, 18 Dec 2000 16:08:55 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id QAA18058 for ; Mon, 18 Dec 2000 16:08:54 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id 26AFA7D5; Mon, 18 Dec 2000 16:08:53 -0500 (EST) Sender: shalunov@internet2.edu To: ippm@advanced.org Subject: draft-ietf-ippm-owdp: should it be split? From: stanislav shalunov Date: 18 Dec 2000 16:08:52 -0500 Message-ID: <8766khjv2z.fsf@cain.internet2.edu> Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.4 There was a suggestion made during physical IPPM WG meeting that the draft be split into two: one describing OWDP-Control, the other one describing OWDP-Test. What is everybody's opinion on this suggestion? NOTE: Split or not split, you *can* use OWDP-Test without OWDP-Control. -- Stanislav Shalunov Internet Engineer, Internet2 A fanatic is one who can't change his mind and won't change the subject. -- Winston Churchill From matt@advanced.org Mon Dec 18 17:06:56 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16331 for ; Mon, 18 Dec 2000 17:06:56 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id RAA08150 for ippm-l@advanced.org; Mon, 18 Dec 2000 17:01:18 -0500 (EST) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id RAA28717 for ; Mon, 18 Dec 2000 17:01:17 -0500 (EST) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id RAA19568; Mon, 18 Dec 2000 17:01:16 -0500 (EST) Received: by cain.internet2.edu (Postfix, from userid 1000) id E6FC07D5; Mon, 18 Dec 2000 17:01:15 -0500 (EST) Sender: shalunov@internet2.edu To: ippm@advanced.org Subject: draft-ietf-ippm-owdp: arbitrary packets? From: stanislav shalunov Date: 18 Dec 2000 17:01:15 -0500 Message-ID: <87zohtie38.fsf@cain.internet2.edu> Lines: 44 X-Mailer: Gnus v5.7/Emacs 20.4 There was a suggestion made during physical IPPM WG meeting that the protocol should be modified in such a way as to allow specification of arbitrary packet format, along with an indication of where within these packets the actual timestamp is located. This would address Type-P issue in a rather general way. (But not completely, since one can imagine situations where advance reservations via a bandwidth broker or RSVP would change the results of a measurement.) This suggestion seems appealing, however, there are certain problematic areas that need to be addressed if we want to implement it. * Many OWDP-Test speakers will be Unix or other general purpose computers. These will inevitably have higher losses when listening to raw network traffic. Raw sockets will induce higher loss rate than one would have with UDP measurements. * How would one distinguish between a situation where packets aren't supposed to be routed to the receiver and situation of 100% loss? * Carefully crafted packets could cause disruption to some link-layer protocols. How would an implementer decide what to allow so as not to increase risks? * Suppose an identity of an authenticated user becomes compromised. Now the attacker could use that to run TCP sessions to rlogin port of machines around servers that trust this user to perform measurements (or, less drastically, to send spam from that network). Ability to perform measurements is transformed into ability to generate arbitrary traffic on behalf of all the senders an OWDP-Control server controls. * How do we specify criteria for listening to traffic? Standartizing tcpdump syntax is hardly an option, but what else do we have? Thoughts? Should we just stick with UDP plus possibly a few options for things like PHB/DSCP, TTL, DF, etc.? -- Stanislav Shalunov Internet Engineer, Internet2 Beware of Programmers who carry screwdrivers. -- Leonard Brandwein From matt@advanced.org Tue Dec 19 15:18:07 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23599 for ; Tue, 19 Dec 2000 15:18:07 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id PAA28571 for ippm-l@advanced.org; Tue, 19 Dec 2000 15:13:10 -0500 (EST) Received: from exch-connector.netcomsystems.com (mushroom.netcomsystems.com [12.9.24.195]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id PAA03114; Tue, 19 Dec 2000 15:13:09 -0500 (EST) Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Dec 2000 12:12:37 -0800 Message-ID: <9384475DFC05D2118F9C00805F6F263104762F99@exchange1.netcomsystems.com> From: ANTIGEN_EXCHANGE1 To: "'matt@advanced.org'" , "'ippm@advanced.org'" Subject: Antigen found W32/Navidad virus Date: Tue, 19 Dec 2000 12:12:37 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C069F8.081B32E0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C069F8.081B32E0 Content-Type: text/plain Antigen for Exchange found Navidad.exe infected with W32/Navidad virus. The file is currently Deleted. The message, "Revision to loss pattern draft: Update to author contact info", was sent from Ing. IDJ van der Ven and was discovered in IMC Queues\Inbound located at Netcom Systems/NETCOMSYSTEMS/EXCHANGE1. ------_=_NextPart_001_01C069F8.081B32E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Antigen found W32/Navidad virus

Antigen for Exchange found Navidad.exe infected with = W32/Navidad virus.
The file is currently Deleted.  The message, = "Revision to loss pattern draft: Update to author contact = info", was
sent from Ing. IDJ van der Ven  and was = discovered in IMC Queues\Inbound
located at Netcom = Systems/NETCOMSYSTEMS/EXCHANGE1.

------_=_NextPart_001_01C069F8.081B32E0-- From matt@advanced.org Tue Dec 19 15:35:10 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23930 for ; Tue, 19 Dec 2000 15:35:10 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id PAA01979 for ippm-l@advanced.org; Tue, 19 Dec 2000 15:30:38 -0500 (EST) Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id PAA25449 for ; Tue, 19 Dec 2000 15:30:37 -0500 (EST) Received: from galatea (localhost [127.0.0.1]) by mailhost.advanced.org (8.11.1/8.11.1/Debian 8.11.0-6) with SMTP id eBJKUbC19794 for ; Tue, 19 Dec 2000 15:30:37 -0500 X-Authentication-Warning: mailhost.advanced.org: Host localhost [127.0.0.1] claimed to be galatea From: "Matthew J Zekauskas" To: Subject: [ADMIN] virus warnings from today Date: Tue, 19 Dec 2000 15:36:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 7bit These were stuck in some long-dormant sendmail queue. Sendmail was restarted... and they popped out. As far as I know, there has been no new propogation. --Matt From matt@advanced.org Wed Dec 20 07:29:33 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21058 for ; Wed, 20 Dec 2000 07:29:33 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id HAA04079 for ippm-l@advanced.org; Wed, 20 Dec 2000 07:15:37 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id HAA04094 for ; Wed, 20 Dec 2000 07:15:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20445; Wed, 20 Dec 2000 07:15:34 -0500 (EST) Message-Id: <200012201215.HAA20445@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-owdp-01.txt Date: Wed, 20 Dec 2000 07:15:34 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A One-way Delay Measurement Protocol Author(s) : S. Shalunov, B. Teitelbaum, M. Zekauskas Filename : draft-ietf-ippm-owdp-01.txt Pages : 20 Date : 19-Dec-00 The IETF IP Performance Metrics (IPPM) working group has proposed draft standard metrics for one-way packet delay [RFC2679] and loss [RFC 2680] across Internet paths. Although there are now several measurement platforms that implement collection of these metrics [SURVEYOR], [RIPE], there is to date no standard that would permit initiation of test streams or exchange of packets to collect singleton metrics in an interoperable manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-owdp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-owdp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001219130554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-owdp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-owdp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001219130554.I-D@ietf.org> --OtherAccess-- --NextPart-- From matt@advanced.org Thu Dec 21 07:13:29 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15498 for ; Thu, 21 Dec 2000 07:13:29 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id GAA12287 for ippm-l@advanced.org; Thu, 21 Dec 2000 06:46:54 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id GAA12037 for ; Thu, 21 Dec 2000 06:46:53 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15031; Thu, 21 Dec 2000 06:45:53 -0500 (EST) Message-Id: <200012211145.GAA15031@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ippm@advanced.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ippm-btc-framework-04.txt Date: Thu, 21 Dec 2000 06:45:53 -0500 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Metrics Working Group of the IETF. Title : A Framework for Defining Empirical Bulk Transfer Capacity Metrics Author(s) : M. Mathis, M. Allman Filename : draft-ietf-ippm-btc-framework-04.txt Pages : 9 Date : 20-Dec-00 Bulk Transport Capacity (BTC) is a measure of a network's ability to transfer significant quantities of data with a single congestion-aware transport connection (e.g., TCP). The intuitive definition of BTC is the expected long term average data rate (bits per second) of a single ideal TCP implementation over the path in question. However, there are many congestion control algorithms (and hence transport implementations) permitted by IETF standards. This diversity in transport algorithms creates a difficulty for standardizing BTC metrics because the allowed diversity is sufficient to lead to situations where different implementations will yield non-comparable measures -- and potentially fail the formal tests for being a metric. This document defines a framework for standardizing multiple BTC metrics that parallel the permitted transport diversity. Two approaches are used. First, each BTC metric must be much more tightly specified than the typical IETF protocol. Pseudo-code or reference implementations are expected to be the norm. Second, each BTC methodology is expected to collect some ancillary metrics which are potentially useful to support analytical models of BTC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-btc-framework-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ippm-btc-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ippm-btc-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001220160722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ippm-btc-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ippm-btc-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001220160722.I-D@ietf.org> --OtherAccess-- --NextPart-- From matt@advanced.org Fri Dec 22 05:52:20 2000 Received: from betelgeuse.advanced.org (betelgeuse.advanced.org [209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27965 for ; Fri, 22 Dec 2000 05:52:20 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id FAA09760 for ippm-l@advanced.org; Fri, 22 Dec 2000 05:43:12 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id FAA09132; Fri, 22 Dec 2000 05:43:01 -0500 (EST) From: vilho.raisanen@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eBMAgoB07019; Fri, 22 Dec 2000 12:42:51 +0200 (EET) Received: from esebh12nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.1.2) with ESMTP id ; Fri, 22 Dec 2000 12:42:48 +0200 Received: by esebh12nok with Internet Mail Service (5.5.2652.78) id ; Fri, 22 Dec 2000 12:42:33 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10520A8AC@eseis04nok> To: ippm@advanced.org Cc: acmorton@att.com, g.grotefeld@motorola.com, matt@advanced.org, kaeo@merike.com, vilho.raisanen@nokia.com Subject: npmps-04bis Date: Fri, 22 Dec 2000 12:42:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C06C03.E1303AF0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C06C03.E1303AF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear IPPMers, please find attached the version -04bis of the npmps draft. Thanks to = Al & Glenn for comments. The following changes to -04 have been made: - I got rid of the the spurious month names due to Emacs' = case-insensitive search & replace algorithm. Indeed, these JUNE have caused some = confusion. - I implemented Al's refinement into 4.6. and added some more text into = incT error bullet pt. The section now reads The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document [1] provides general guidance on this point,=20 but we note here the following specifics related to periodic streams and delay metrics: + Error due to variation of incT. The reasons for this can be e.g. uneven process scheduling, possibly due to CPU load. + Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points. + Errors or uncertainties due to the difference between 'wire time' and 'host time'. Earlier during the e-mail thread, Al commented that also real sources = of periodic streams may (and do) exhibit variation in transmission times. = This is true, but incorporation of intentional deviations from periodic = behaviour into the actual measurement metrics would result in a quite complex construct. Basically, a (public domain) source should be cited for definitive research results on "typical" variations due to O/S or application. This should then be mapped into a corresponding metrics description and so forth. Thus, I find it a bit difficult to justify adding a mention of real application behaviour in this context. In my view, the goal should be = that incT is (for practical purposes) negligible. Season's greetings, Vilho %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%=20 Vilho R=E4is=E4nen =20 vilho.raisanen@nokia.com =20 Senior research engineer =20 Nokia Research Center, Helsinki, Finland=20 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ------_=_NextPart_000_01C06C03.E1303AF0 Content-Type: text/plain; name="draft-ietf-ippm-npmps-04bis.txt" Content-Disposition: attachment; filename="draft-ietf-ippm-npmps-04bis.txt" Content-Transfer-Encoding: quoted-printable Network Working Group V. = Raisanen INTERNET-DRAFT = Nokia Expiration Date: June 2001 G. = Grotefeld = Motorola December = 2000 Network performance measurement for periodic streams 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at = =20 http://www.ietf.org/ietf/1id-abstracts.txt = =20 The list of Internet-Draft shadow directories can be accessed at = =20 http://www.ietf.org/shadow.html This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 2. Abstract This document describes a sample metric suitable for application- level IP network transport measurement for periodic streams, such as VoIP or streaming multimedia over IP. In this document, the reader is assumed to be familiar with the terminology of the Framework for IP Performance Metrics RFC 2330 [1]. This document is parallel to A One-way Delay Metric for IPPM RFC 2679 [2]. Although this document is based on the delay metrics, other characteristics can be measured with this approach, too. For example, packet loss rate, reordering / out-of sequence, and successive delay variation are all additional metrics which can be built from this baseline set of measurements. Raisanen, Grotefeld expires June 2001 [Page = 1]=0C Internet Draft December = 2000 3. Introduction This document discusses concepts relevant to application-level performance measurements of an IP network. The original driver for this work is Quality of Service of interactive periodic streams such as multimedia conference over IP, but the idea of application-level measurement may have a wider scope. In the following, interactive multimedia traffic is used as an example to illustrate the concept. A constant bit-rate (CBR), or nearly CBR, streaming (hereinafter called periodic) multimedia bit stream may be simulated by transmitting uniformly sized packets (or mostly uniformly sized packets) at regular intervals through the network to be evaluated. The "mostly uniformly sized packets" may be found in applications that may use smaller packets during a portion of the stream (e.g. digitally coded voice during silence periods). As noted in the framework document [1], a sample metric using regularly spaced singleton tests has some limitations when considered from a general measurement point of view: only part of the network performance spectrum is sampled. However, from the point of view of application-level performance, this is actually good news as explained below. IP delivery service measurements have been discussed within the International Telecommunications Union (ITU). A framework for IP service level measurements (with references to the framework for IP performance [1]) that is intended to be suitable for service = planning has been approved as I.380 [3]. The emphasis in the ITU recommendation is on passive measurements, though not explicitly forbidding active measurements. The present contribution proposes a method that is usable both for service planning and end-user testing purposes, and is based on active measurements. 3.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Although RFC 2119 was written with protocols in mind, the key words are used in this document for similar reasons. They are used to ensure the results of measurements from two different = implementations are comparable, and to note instances when an implementation could perturb the network. Raisanen, Grotefeld expires June 2001 [Page = 2]=0C Internet Draft December = 2000 3.2 Considerations related to delay For interactive multimedia sessions, end-to-end delay is an important factor. Too large a delay reduces the quality of the multimedia session as perceived by the participants. One approach = for managing end-to-end delays on an Internet path involving heterogeneous link layer technologies is to use per-domain delay quotas (e.g. 50 ms for a particular IP domain). The 50 ms would then be included into a calculation of an end-to-end delay bound. A practical implementation of such as scheme ought to address issues like possibility of asymmetric delays in a route in different directions, and sensitivity of an application to delay variations in a given domain. There are several alternatives as to which kind of derivative delay metric one ought to use in managing end-to-end QoS. This question, although very interesting, is not within the scope of this draft and is not discussed further here. In the following, a methodology and metric are presented for measuring media stream transport QoS in an IP domain. The measurement results may be used in derivative metrics such as average and maximum delays. A metric is presented that is a standard way for performing a measurement irrespective of the possible QoS mechanism utilized in the core network. As an example, for a QoS mechanism without hard guarantees, measurements may be used to ascertain that the "best" class gets the service that has been promised for the traffic class in question. Moreover, an operator could study the quality of a cheap, low-guarantee service implemented using possible slack bandwidth in other classes. Such measurements could be made either in studying the feasibility of a new service, or on a regular basis. The present draft seeks to formalize the measurements in such a way that interoperable results are achieved. 3.3 Protocol level issues The version of the Internet Protocol used in the measurement affects (at least) packet sizes, and should be reported. =20 Fig.1 illustrates measurements on multiple protocol levels that are relevant to this draft. The major focus of the present draft is on transport quality evaluation from application point of view. However, to properly account for quality effects of, e.g., operating system and codec on packet voice, it is beneficial to be able to measure quality at IP level [5]. Link layer monitoring provides a way of accounting for link layer characteristics such as bit error rates. Raisanen, Grotefeld expires June 2001 [Page = 3]=0C Internet Draft December = 2000 --------------- | application | --------------- | transport | <-- --------------- | network | <-- --------------- | link | <-- --------------- | physical | ---------------=20 Fig. 1: Different possibilities for performing measurements: a protocol view. Above, "application" refers to all layers above L4 and is not used in the OSI sense. In general, the results of measurements may be influenced by individual application requirements/responses related to the following issues: + Lost packets: Applications may have varying tolerance to lost=20 packets. Another consideration is the distribution of lost packets (i.e. random or bursty). + Long delays: Many applications will consider packets delayed=20 longer than a certain value to be equivalent to lost packets (i.e. real time applications). + Duplicate packets: Some applications may be perturbed if=20 duplicate packets are received. + Out-of-sequence: Some applications may be perturbed if packets are received out of sequence. This may be in addition to the possibility of exceeding the "long" delay threshold as a result of being out of sequence. An out-of-sequence packet outcome occurs when a single IP packet received at a DST measurement point has a sequence number higher than that which is expected, and therefore, the packet is OOS due to re-ordering.=20 + Corrupt packet header: Most applications will probably treat a packet with a corrupt header as equivalent to a lost packet. + Corrupt packet payload: Some applications (e.g. digital voice=20 codecs) may accept corrupt packet payload. In some cases, the packet payload may contain application specific forward error correction (FEC) that can compensate for some level of=20 corruption. + Spurious packet: Dst may receive spurious packets (i.e. packets that are not sent by the Src as part of the metric). Many applications may be perturbed by spurious packets. Depending, e.g., on the observed protocol level, some issues listed above may be indistinguishable from others by the application, it may be important to preserve the distinction for the operators of Src, Dst, and/or the intermediate network(s). Raisanen, Grotefeld expires June 2001 [Page = 4]=0C Internet Draft December = 2000 Because of the possible errors listed above, in most cases it is=20 recommended to use a packet identifier for each packet generated at Src. Identifiers for the metric sample may be those used by the underlying transport layer (e.g. RTP sequence number) or the same=20 identifiers used by an application if the application to be modeled=20 by the metric uses an identifier. The possibility of identifier=20 roll-over (reuse if intentional) during a metric collected over a "long" (application dependent) time should be observed. If the application does not use an identifier, it may still be=20 useful to add identifiers to the packets in the metric sample to=20 help identify possible anomalies such as out of sequence packets. This would be most useful in the case where the application=20 expects to receive packets in sequence, but has no capability to identify the sequence of packets received at Dst. 3.4 Application-level measurement In what follows, a metric is proposed for application-level network performance measurement. In effect, the metric is an emulation of periodic multimedia stream performance. The justification for using realistic application metrics in the measurement: + The results of the measurement are automatically relevant to the performance as perceived by the application in question. + All the packets in the measurement contribute to accuracy of the estimation of performance variation at timescale that is important to the multimedia application (packetization interval). + Effects of elastic traffic (TCP) on measurement packets are different for a sustained stream than for single packets during overloading situations as discussed in [3]. 3.5 Measurement types Delay measurements can be one-way [2,3], paired one-way, or=20 round-trip [6]. Accordingly, the measurements may be performed either with synchronized or unsynchronized Src/Dst host clocks. Different possibilities are listed below. The reference measurement setup for all measurement types is shown in Fig. 2. Raisanen, Grotefeld expires June 2001 [Page = 5]=0C Internet Draft December = 2000 ----------------< IP >-------------------- | | | | ------- ------- -------- -------- | Src | | MP | | MP | | Dst | ------- |(Src)| |(Dst) | -------- ------- -------- =20 Fig. 2: Example setup for the metric usage. An example of the use of the metric is a setup with a source host (Src), a destination host (Dst), and corresponding measurement points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate = equipment for measurement points may be used if having Src and/or Dst conduct=20 the measurement may significantly affect the delay performance to be measured. MP(Src)should be placed/measured close to the egress point = of packets from Src. MP(Dst) should be placed/measure close to=20 the ingress point of packets for Dst. "Close" is defined as a distance sufficiently small so that application-level performance characteristics measured (such as delay) can be expected to follow=20 the corresponding performance characteristic between Src and Dst to=20 an adequate accuracy. Basic principle here is that measurement results between MP(Src) and MP(Dst) should be the same as for a measurement between Src and Dst, within the general error margin target of the measurement (e.g., < 1 ms; number of lost packets is the same). If this is not possible, the difference between MP-MP measurement and Src-Dst measurement should preferably be systematic. =20 The test setup just described fulfills two important criteria: 1) Test is made with realistic stream metrics, emulating - for = example - a full-duplex Voice over IP (VoIP) call. 2) Either one-way or round-trip characteristics may be obtained. It is also possible to have intermediate measurement points between=20 MP(Src) and MP(Dst), but that is beyond the scope of this document. 3.5.1 One way measurement In the interests of specifying metrics that are as generally usable as possible, application-level measurements based on one-way delays are used in the example metrics. The implication of = application-level measurement for bi-directional applications such as interactive multimedia conferencing is discussed below. Performing a single one-way measurement only yields information on network behavior in one direction. Moreover, the stream at the network transport level does not emulate accurately a full-duplex multimedia connection. Raisanen, Grotefeld expires June 2001 [Page = 6]=0C Internet Draft December = 2000 3.5.2 Paired one way measurement Paired one way delay refers to two multimedia streams: Src to Dst=20 and Dst to Src for the same Src and Dst. By way of example, for some applications, the delay performance of each one way path is more important than the round trip delay. This is the case for delay-limited signals such as VoIP. Possible reasons for the difference between one-way delays is different routing of streams from Src to Dst vs. Dst to Src. For example, a paired one way measurement may show that Src to Dst has an average delay of 30ms while Dst to Src has an average delay of 120ms. To a round trip delay measurement, this example would look like an average of 150ms delay. Without the knowledge of the asymmetry, we might miss a problem that the application at either end may have with delays averaging more than 100ms. Moreover, paired one way delay measurement emulates a full-duplex VoIP call more accurately than a single one-way measurement only. 3.5.3 Round trip measurement From the point of view of periodic multimedia streams, round-trip measurements have two advantages: they avoid the need of host clock synchronization and they allow for a simulation of full-duplex connections. The former aspect means that a measurement is easily performed, since no special equipment or NTP setup is needed. The latter property means that measurement streams are transmitted in both directions. Thus, the measurement provides information on quality of service as experienced by appropriate application. The downsides of round-trip measurement are the need for more bandwidth than an one-way test and more complex accounting of packet loss. Moreover, the stream that is returning towards the original sender may be more bursty than the one on the first "leg" = of the round-trip journey. The last issue, however, means in practice that returning stream experiences worse QoS than the other one, and the performance estimates thus obtained are pessimistic ones. The possibility of asymmetric routing and queuing must be taken into account during analysis of the results. Please note that with suitable arrangements, round-trip measurements may be performed using paired one way measurements. Raisanen, Grotefeld expires June 2001 [Page = 7]=0C Internet Draft December = 2000 4 Sample metric for multimedia stream simulation The sample metric presented here is similar to the sample metric Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", = as defined in [1] and [2] are not directly used in this document = because certain key results (such as duplicate or out of sequence packets) cannot be identified in the context of a singleton, but only as part of a sample. 4.1 Metric name =20 Type-P-One-way-Delay-Periodic-Stream 4.2 Metric parameters 4.2.1 Global metric parameters These parameters are applicable to the metrics collected in the=20 following sections (4.2.2, 4.2.3, and 4.2.4). + Src, the IP address of a host + Dst, the IP address of a host + IPV, the IP version (IPv4/IPv6) used in the measurement + T0, a time, for starting to generate packets and taking=20 measurements for a sample + Tf, a time, greater than T0, for stopping generation of packets for a sample + incT, nominal duration of inter-packet interval + packet size p(j), the number of bytes in each packet of Type-P of = size j + dTloss, a time interval, used for determining if a packet should be considered lost + Tcons, a time interval [optional] While a number of applications will use one packet size (j =3D = 1), other applications may use packets of different sizes (j > 1).=20 Especially in cases of congestion, it may be useful to have=20 packets smaller than the maximum or predominant size of packets in the periodic stream. 4.2.2 Metrics collected at MP(Src) + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src) + PktID [i], for each packet [i], an identification number for the the packet sent from Src to Dst. Raisanen, Grotefeld expires June 2001 [Page = 8]=0C Internet Draft December = 2000 + PktSiTy [i], for each packet [i], the packet size and/or type. Some applications may use packets of different size, either=20 because of application requirements or in response to IP=20 performance experienced. 4.2.3 Metrics collected at MP (Dst) + dTstop, a time interval, used to add to time Tf to determine when = to stop collecting metrics for a sample + Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst) + PktID [i], for each packet [i], an identification number for the the packet received at Dst from Src. + PktSiTy [i], for each packet [i], the packet size and/or type. Some applications may use packets of different size, either=20 because of application requirements or in response to IP=20 performance experienced. + PktStatus [i], for each packet [i], the status of the packet received. Possible status includes: OK, packet header corrupt, packet payload corrupt, spurious, duplicate, out-of-sequence. 4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst) are merged These parameters are only available as a complete set when the=20 parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are=20 combined. =20 + Tstamp(Src)[i], for each packet [i], the time of the packet as measured at MP(Src). This entry may be blank or noted as N/A for spurious packets received at MP(Dst) + Tstamp(Dst)[i], for each packet [i], the time of the packet as measured at MP(Dst). This entry may be blank or noted as N/A for packets not received at MP(Dst), received with corrupt=20 packet headers, or for duplicate packets received at MP(Dst). + PktID [i], for each packet [i], an identification number for the the packet received. This identification number may be corrupted for certain packets received at MP (Dst). + PktSiTy [i], for each packet [i], the packet size and/or type. + PktStatus [i], for each packet [i], the status of the packet=20 received. Possible status includes: OK, packet header corrupt, packet payload corrupt, spurious, duplicate, out-of-sequence. Raisanen, Grotefeld expires June 2001 [Page = 9]=0C Internet Draft December = 2000 + Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] = -=20 Tstamp(Src)[i]. For the following conditions, it will not be=20 possible to be able to compute delay: Spurious: There will be no Tstamp(Src)[i] time Not received: There will be no Tstamp (Dst) [i] Corrupt packet header: There will be no Tstamp (Dst) [i] Duplicate: Only the first non-corrupt copy of the packet=20 received at Dst should have Delay [i] computed. + SDV[i] [optional] , for each packet [i] except the first one:=20 momentary delay variation between successive packets, i.e., = the=20 time interval Delay[i] - Delay [i-1]. SDV[i] may be negative, = zero, or positive. Delay for both packets i and i+1 must be=20 calculable according to the definition above or SDV[i] is=20 undefined. 4.3 High level description of the procedure to collect a sample Beginning on or after time T0, Type-P packets are generated=20 by Src and sent to Dst until time Tf is reached with a nominal=20 interval between the first bit of successive packets of incT as=20 measured at MP(Src). incT may be nominal due to a number of = reasons: variation in packet generation at Src, clock issues (see section = 4.6), etc. MP(Src) records the following information only for packets with=20 timestamps between and including T0 and Tf: timestamp,=20 packet identifier, and packet size/type of each packet sent from Src = to Dst that is part of the sample. =20 MP (Dst) records the following information only for packets with=20 time stamps between T0 and (Tf+ dTstop): timestamp, packet = identifier,=20 packet size/type, and received status of each packet received from=20 Src at Dst that is part of the sample. Optionally, at a time Tf +=20 Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive=20 the results of the sample metric.=20 To prevent stopping data collection too soon, dTcons should be = greater than or equal to dTstop. Conversely, to keep data collection=20 reasonably efficient, dTstop should be some reasonable time interval = (seconds/minutes/hours), even if dTloss is infinite or extremely = long. Raisanen, Grotefeld expires June 2001 [Page = 10]=0C Internet Draft December = 2000 4.4 Discussion The sample metric thus defined is intended to probe the delays and the delay variation as experienced by multimedia streams of an application. Due to the definition of the metric, also packet = loss status of packets is recorded. The delay is assumed to be measured = at transport layer level. Since a range of packet sizes and nominal=20 interval between packets is used, the method probes only a specific=20 time scale of network QoS variations. There are a number of factors that should be taken into account when = collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream. + T0 and (Tf + dTloss) should specify a long enough time interval = to=20 represent a reasonable use of the application under test (e.g. do = not provide only a 100 ms time interval for a phone call) + T0 and (Tf + dTloss) should specify a time interval that is not=20 excessively long compared to the usage of the application under = test (e.g. do not provide a one week continuous phone call) + The nominal interval between packets (incT) and the packet = size(s) (p(j)) should not define an equivalent bit rate that is in excess = of the capacity of the egress port of Src, the ingress port of = Dst, or the carrying capacity of the intervening network(s). There may be exceptional cases to test the response of the application to overload conditions in the transport networks, but these cases=20 should be strictly controlled. + Real delay values will be positive. Therefore, it does not make sense to report a negative value as a real delay. However, an individual zero or negative delay value might be useful as part = of a stream when trying to discover a distribution of the delay = values of a stream. + Depending on measurement topology, delay values may be as low as 100 usec to 10 msec, whereby it may be important for Src and Dst = to synchronize very closely. GPS systems afford one way to achieve synchronization to within several 10s of usec. Ordinary = application of NTP may allow synchronization to within several msec, but this depends on the stability and symmetry of delay properties among = those NTP agents used, and this delay is what we are trying to measure. = A combination of some GPS-based NTP servers and a conservatively designed and deployed set of other NTP servers should yield good results, but this is yet to be tested. + Reordering of packets is best discussed in terms of the entire set of measurement packets received, i.e. should be addressed in Sec. 4.9.1. Raisanen, Grotefeld expires June 2001 [Page = 11]=0C Internet Draft December = 2000 + A given methodology will have to include a way to determine whether packet was lost or whether delay is merely very large = (and the packet is yet to arrive at Dst). The global metric parameter dTloss defines a time interval such that delays larger than = dTloss are interpreted as losses.=20 {Comment: Note that, for many applications of these metrics, the harm in treating a large delay as infinite might be zero or very small. A TCP data packet, for example, that arrives only after several multiples of the RTT may as well have been lost.} 4.5 Additional Methodology Aspects As with other Type-P-* metrics, the detailed methodology will depend on the Type-P (e.g., protocol number, UDP/TCP port number, size, precedence). 4.6 Errors and uncertainties The description of any specific measurement method should include an accounting and analysis of various sources of error or uncertainty. The Framework document [1] provides general guidance on this point,=20 but we note here the following specifics related to periodic streams and delay metrics: + Error due to variation of incT. The reasons for this can be e.g. uneven process scheduling, possibly due to CPU load. + Errors or uncertainties due to uncertainties in the clocks of the MP(Src) and MP(Dst) measurement points. + Errors or uncertainties due to the difference between 'wire time' and 'host time'. 4.6.1. Errors or uncertainties related to Clocks The uncertainty in a measurement of one-way delay is related, in part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the following, we refer to the clock used to measure when the packet was measured at MP(Src) as the MP(Src) clock and we refer to the=20 clock used to measure when the packet was received at MP(Dst) as the MP(Dst) clock. Alluding to the notions of synchronization, = accuracy, resolution, and skew, we note the following: + Any error in the synchronization between the MP(Src) clock and=20 the MP(Dst) clock will contribute to error in the delay measurement. We say that the MP(Src) clock and the MP(Dst) clock have a synchronization error of Tsynch if the MP(Src) clock is Tsynch ahead of the MP(Dst) clock. Thus, if we know the value of Tsynch exactly, we could correct for clock synchronization by adding Tsynch to the uncorrected value of Tstamp(Dst)[i] - Tstamp(Src) [i]. Raisanen, Grotefeld expires June 2001 [Page = 12]=0C Internet Draft December = 2000 + The accuracy of a clock is important only in identifying the time at which a given delay was measured. Accuracy, per se, has no importance to the accuracy of the measurement of delay. When computing delays, we are interested only in the differences between clock values, not the values themselves. + The resolution of a clock adds to uncertainty about any time measured with it. Thus, if the MP(Src) clock has a resolution of 10 msec, then this adds 10 msec of uncertainty to any time value measured with it. We will denote the resolution of the source clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst), respectively. + The skew of a clock is not so much an additional issue as it is a realization of the fact that Tsynch is itself a function of time. Thus, if we attempt to measure or to bound Tsynch, this needs to be done periodically. Over some periods of time, this function can be approximated as a linear function plus some higher order terms; in these cases, one option is to use knowledge of the linear component to correct the clock. Using this correction, = the residual Tsynch is made smaller, but remains a source of uncertainty that must be accounted for. We use the function Esynch(t) to denote an upper bound on the uncertainty in synchronization. Thus, |Tsynch(t)| <=3D Esynch(t). Taking these items together, we note that naive computation=20 Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/-=20 (ResMP(SRc) + ResMP(Dst)). Using the notion of Esynch(t), we note =20 that these clock-related problems introduce a total uncertainty of=20 Esynch(t)+ Rsource + Rdest. This estimate of total clock-related=20 uncertainty should be included in the error/uncertainty analysis of=20 any measurement implementation. 4.6.2. Errors or uncertainties related to Wire-time vs Host-time As we have defined one-way periodic delay, we would like to measure=20 the time between when a packet is measured and time-stamped at MP(Src) and when it arrives and is time-stamped at MP(Dst) and we refer to these as "wire times." If the timings are themselves performed by software on Src and Dst, however, then this software = can only directly measure the time between when Src generates the packet just prior to sending the test packet and when Dst has started to process the packet after having received the test packet, and we = refer to these two points as "host times". To the extent that the difference between wire time and host time is accurately known, this knowledge can be used to correct for wire = time measurements and the corrected value more accurately estimates the desired (host time) metric. Raisanen, Grotefeld expires June 2001 [Page = 13]=0C Internet Draft December = 2000 To the extent, however, that the difference between wire time and host time is uncertain, this uncertainty must be accounted for in an analysis of a given measurement method. We denote by Hsource an upper bound on the uncertainty in the difference between wire time of MP(Src) and host time on the Src host, and similarly define Hdest for the difference between the host time on the Dst host and the = wire time of MP(Dst). We then note that these problems introduce a total uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty should be included in the error/uncertainty analysis of=20 any measurement implementation. 4.6.3. Calibration Generally, the measured values can be decomposed as follows: measured value =3D true value + systematic error + random error If the systematic error (the constant bias in measured values) can = be determined, it can be compensated for in the reported results. reported value =3D measured value - systematic error therefore reported value =3D true value + random error The goal of calibration is to determine the systematic and random error generated by the instruments themselves in as much detail as possible. At a minimum, a bound ("e") should be found such that the reported value is in the range (true value - e) to (true value + e) at least 95 percent of the time. We call "e" the calibration error for the measurements. It represents the degree to which the values produced by the measurement instrument are repeatable; that is, how closely an actual delay of 30 ms is reported as 30 ms. {Comment: 95 percent was chosen due to reasons discussed in [2], briefly summarized as (1) some confidence level is desirable to be able to remove outliers, which will be found in measuring any physical property; (2) a particular confidence level should be specified so that the results of independent implementations can be compared.} From the discussion in the previous two sections, the error in measurements could be bounded by determining all the individual uncertainties, and adding them together to form Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest. Raisanen, Grotefeld expires June 2001 [Page = 14]=0C Internet Draft December = 2000 However, reasonable bounds on both the clock-related uncertainty captured by the first three terms and the host-related uncertainty captured by the last two terms should be possible by careful design techniques and calibrating the instruments using a known, isolated, network in a lab. For example, the clock-related uncertainties are greatly reduced through the use of a GPS time source. The sum of Esynch(t) +=20 ResMP(Src) + ResMP(Dst) is small, and is also bounded for the=20 duration of the measurement because of the global time source. The host-related uncertainties, Hsource + Hdest, could be bounded by connecting two instruments back-to-back with a high-speed serial = link or isolated LAN segment. In this case, repeated measurements are measuring the same one-way delay. If the test packets are small, such a network connection has a minimal delay that may be approximated by zero. The measured delay therefore contains only systematic and random error in the instrumentation. The "average value" of repeated measurements is = the systematic error, and the variation is the random error. One way to compute the systematic error, and the random error to a 95% confidence is to repeat the experiment many times - at least hundreds of tests. The systematic error would then be the median. The random error could then be found by removing the systematic = error from the measured values. The 95% confidence interval would be the range from the 2.5th percentile to the 97.5th percentile of these deviations from the true value. The calibration error "e" could = then be taken to be the largest absolute value of these two numbers, plus the clock-related uncertainty. {Comment: as described, this bound = is relatively loose since the uncertainties are added, and the absolute value of the largest deviation is used. As long as the resulting value is not a significant fraction of the measured values, it is a reasonable bound. If the resulting value is a significant fraction of the measured values, then more exact methods will be needed to compute the calibration error.} Note that random error is a function of measurement load. For example, if many paths will be measured by one instrument, this = might increase interrupts, process scheduling, and disk I/O (for example, recording the measurements), all of which may increase the random error in measured singletons. Therefore, in addition to minimal = load measurements to find the systematic error, calibration measurements should be performed with the same measurement load that the instruments will see in the field. Raisanen, Grotefeld expires June 2001 [Page = 15]=0C Internet Draft December = 2000 We wish to reiterate that this statistical treatment refers to the calibration of the instrument; it is used to "calibrate the meter stick" and say how well the meter stick reflects reality. 4.7 Reporting the metric The calibration and context in which the metric is measured MUST be carefully considered, and SHOULD always be reported along with = metric results. We now present five items to consider: the Type-P of test packets, the threshold of delay equivalent to loss, error calibration, the path traversed by the test packets, and background=20 conditions at Src, Dst, and the intervening networks during a = sample. This list is not exhaustive; any additional information that could = be=20 useful in interpreting applications of the metrics should also be=20 reported. 4.7.1. Type-P As noted in the Framework document [1], the value of the metric may depend on the type of IP packets used to make the measurement, or "type-P". The value of Type-P-One-way-Periodic-Delay could change=20 if the protocol (UDP or TCP), port number, size, or arrangement for=20 special treatment (e.g., IP precedence or RSVP) changes. The exact=20 Type-P used to make the measurements MUST be accurately reported. 4.7.2. Threshold for delay equivalent to loss In addition, the threshold for delay equivalent to loss (or=20 methodology to determine this threshold) MUST be reported. 4.7.3. Calibration results + If the systematic error can be determined, it SHOULD be removed from the measured values. + You SHOULD also report the calibration error, e, such that the true value is the reported value plus or minus e, with 95% confidence (see the last section.) + If possible, the conditions under which a test packet with finite delay is reported as lost due to resource exhaustion on the measurement instrument SHOULD be reported. Raisanen, Grotefeld expires June 2001 [Page = 16]=0C Internet Draft December = 2000 4.7.4. Path The path traversed by the packets SHOULD be reported, if possible. In general it is impractical to know the precise path a given packet takes through the network. The precise path may be known for certain Type-P packets on short or stable paths. If Type-P includes the record route (or loose-source route) option in the IP header, and the path is short enough, and all routers* on the path support record (or loose-source) route, then the path will be precisely recorded. This may be impractical because the route must be short enough, many routers do not support (or are not configured for) record = route, and use of this feature would often artificially worsen the performance observed by removing the packet from common-case processing. However, partial information is still valuable context. For example, if a host can choose between two links* (and hence two separate routes from Src to Dst), then the initial link used is valuable context. {Comment: For example, with Merit's NetNow setup, a Src on one NAP can reach a Dst on another NAP by either of several different backbone networks.} 4.7.5 Background conditions In many cases, the results of a sample may be influenced by = conditions at Src, Dst, and/or any intervening networks. Some things that may=20 affect the results of a sample include: traffic levels and/or = bursts=20 during the sample, link and/or host failures, etc. Information = about the background conditions may only be available by non-Internet = means (e.g. phone calls, television) and may only become available days = after samples are taken. 4.8 Single sample vs. a "sample of samples" Because this metric represents a periodic stream as one sample, = there=20 may be value in running multiple tests using this metric to collect a "sample of samples". For example, it may be more appropriate to=20 test 1,000 two-minute VoIP calls rather than a single 2,000 minute VoIP call. When considering collection of a sample of samples, = issues like the interval between samples (e.g. Poisson vs. periodic, time = of day/day of week), composition of samples (e.g. equal (Tf-T0 = duration, different packet sizes), and network considerations (e.g. run = different samples over different intervening link-host combinations) should be taken into account. For items like the interval between samples, the pattern of use of the application being measured should be=20 considered. Raisanen, Grotefeld expires June 2001 [Page = 17]=0C Internet Draft December = 2000 4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream 4.9.1 Statistics calculable from one sample As a metric based on a sample representative of certain=20 applications, some general purpose statistics (e.g. median and=20 percentile) may be less applicable than ways to characterize the=20 range of delay values recorded during the sample metrics. Example, a sample metric generates 100 packets as measured at = MP(Src) with the following measurements at MP(Dst) + 80 packets received with delay [i] <=3D 20 ms + 8 packets received with delay [i] > 20 ms + 5 packets received with corrupt packet headers + 4 packets from MP(Src) with no matching packet recorded at MP(Dst) (effectively lost) + 3 packets received with corrupt packet payload and and delay [i] <=3D 20 ms + 2 packets that duplicate one of the 80 packets received=20 correctly in the first line For this example, packets are considered acceptable if they are received with less than or equal to 20ms delays and without corrupt packet headers or packet payload. In this case, the percentage of acceptable packets is 80/100 =3D 80%. For a different application which will accept packets with corrupt packet payload and no delay bound (so long as the packet is = received),=20 the percentage of acceptable packets is (80+8+3)/100 =3D 91%. 4.9.2 Statistics calculable from multiple samples For computing statistics, a "sample of samples" series of=20 measurements may be performed. As discussed in section 4.8, under=20 these conditions, general purpose statistics (e.g. median, = percentile, etc.) may be more relevant as a more statistically significant number of packets are used. 5. Security Considerations 5.1 Denial of Service Attacks This metric generates a periodic stream of packets from one host = (Src) to another host (Dst) through intervening networks. This metric could be abused for denial of service attacks directed at Dst and/or the intervening network(s). Raisanen, Grotefeld expires June 2001 [Page = 18]=0C Internet Draft December = 2000 Administrators of Src, Dst, and the intervening network(s) should=20 establish bilateral or multi-lateral agreements regarding the = timing, size, and frequency of collection of sample metrics. Use of this metric in excess the terms agreed between the participants may BE=20 cause for immediate rejection or discard of packets or other=20 escalation procedures defined between the affected parties. 5.2 User data confidentiality This metric generates packets for a sample metric, rather than taking samples based on user data. Thus, this metric does not=20 threaten user data confidentiality. 5.3 Interference with the metric It may be possible to identify that a certain packet or stream of=20 packets are part of a sample metric. With that knowledge at Dst=20 and/or the intervening networks, it is possible to change the=20 processing of the packets (e.g. increasing or decreasing delay)=20 that may distort the measured performance. It may also be=20 possible to generate additional packets that appear to be part of=20 the sample metric. These additional packets are likely to perturb=20 the results of the sample measurement. To discourage the kind of interference mentioned above, packet interference checks, such as cryptographic hash, may be used. 6. Acknowledgements The authors wish to thank the chairs of the IPPM WG for comments that have made the present draft clearer and more focused. Howard Stanislevic and Al Morton ahave presented useful comments and questions. The authors have also built on the substantial foundations laid by the authors of the framework for IP performance [1]. Raisanen, Grotefeld expires June 2001 [Page = 19]=0C Internet Draft December = 2000 7. References =20 [1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP = =20 Performance Metrics, IETF RFC 2330, May 1998. [2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric for IPPM, IETF RFC 2679, September 1999. [3] International Telecommunications Union recommendation I.380, February 1999. [4] S. Bradner: Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [5] ETSI TIPHON document TS-101329-5 (to be published in July). [6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay metric for IPPM, IETF RFC 2681. 8. Authors' contact information Vilho Raisanen P.O. Box 407 Communication Systems Laboratory Nokia Research Center FIN-00045 Nokia Group Finland Phone +358 9 4376 1 Fax. +358 9 4376 6852 Glenn Grotefeld Motorola, Inc. 1303 E. Algonquin Road 4th Floor Schaumburg, IL 60196 USA Phone +1 847 576-5992 Fax +1 847 538-7455 EXPIRES June 2001 ------_=_NextPart_000_01C06C03.E1303AF0-- From matt@advanced.org Mon Dec 25 17:06:23 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00554 for ; Mon, 25 Dec 2000 17:06:22 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id QAA20328 for ippm-l@advanced.org; Mon, 25 Dec 2000 16:54:05 -0500 (EST) Received: from web2102.dn.net ([207.153.229.83]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id QAA20073 for ; Mon, 25 Dec 2000 16:54:04 -0500 (EST) From: service@promoteacasino.com Received: from proxy ([63.160.71.89]) by web2102.dn.net with Microsoft SMTPSVC(5.5.1877.197.19); Mon, 25 Dec 2000 18:51:31 -0500 To: ippm@advanced.org Subject: Promote a casino Organization: Casino Message-Id: <51QZQ948.TP8VWJ0H@promoteacasino.com> Date: 25 Dec 2000 18:51:35 -0500 Dear Internet Marketer, Are you in the bulk email/internet marketing business and want to make some serious $$$ by owning your own ONLINE CASINO!! Check out this latest HOT HOT concept at www.promoteacasino.com Sincerely, Promote a casino INC P.S. You have been contacted because your company/you were listed as being in the internet marketing business. If you don't reply back, YOU WILL NEVER BE CONTACTED AGAIN. From matt@advanced.org Wed Dec 27 10:31:42 2000 Received: from betelgeuse.advanced.org ([209.211.239.10]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18174 for ; Wed, 27 Dec 2000 10:31:41 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id KAA20947 for ippm-l@advanced.org; Wed, 27 Dec 2000 10:13:33 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id KAA18966; Wed, 27 Dec 2000 10:13:29 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA04524; Wed, 27 Dec 2000 08:13:28 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [199.5.78.83]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA07607; Wed, 27 Dec 2000 08:10:11 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2651.58) id ; Wed, 27 Dec 2000 09:13:27 -0600 Message-ID: From: Grotefeld Glenn-cecl03 To: "'vilho.raisanen@nokia.com'" , ippm@advanced.org Cc: acmorton@att.com, matt@advanced.org, kaeo@merike.com Subject: RE: npmps-04bis Date: Wed, 27 Dec 2000 09:13:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id KAA20104 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id KAB20947 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA18174 Vilho, Thank you for the update. Unfortunately, I got the to end of your note and found this: "Thus, I find it a bit difficult to justify adding a mention of real application behaviour in this context. In my view, the goal should be that incT is (for practical purposes) negligible." It appears that something may have been left out of this sentence, possibly from the earlier discussion about errors in incT. For Voice over IP (VoIP)and interactive multi-media applications, incT is nominally 20ms with a desired one-way delay on the order of 100ms. On this scale, I would consider incT non-negligible. Glenn Grotefeld Motorola, Inc. g.grotefeld@motorola.com US 847 576-5992 847 538-7455 FAX ~-----Original Message----- ~From: vilho.raisanen@nokia.com [mailto:vilho.raisanen@nokia.com] ~Sent: Friday, December 22, 2000 4:42 AM ~To: ippm@advanced.org ~Cc: acmorton@att.com; G.Grotefeld; matt@advanced.org; kaeo@merike.com; ~vilho.raisanen@nokia.com ~Subject: npmps-04bis ~ ~ ~Dear IPPMers, ~ ~please find attached the version -04bis of the npmps draft. ~Thanks to Al & ~Glenn for comments. The following changes to -04 have been made: ~ ~- I got rid of the the spurious month names due to Emacs' ~case-insensitive ~search & replace algorithm. Indeed, these JUNE have caused ~some confusion. ~- I implemented Al's refinement into 4.6. and added some more ~text into incT ~error bullet pt. The section now reads ~ ~ The description of any specific measurement method should include an ~ accounting and analysis of various sources of error or uncertainty. ~ The Framework document [1] provides general guidance on this point, ~ but we note here the following specifics related to periodic ~ streams and delay metrics: ~ ~ + Error due to variation of incT. The reasons for this can be e.g. ~ uneven process scheduling, possibly due to CPU load. ~ + Errors or uncertainties due to uncertainties in the clocks of the ~ MP(Src) and MP(Dst) measurement points. ~ + Errors or uncertainties due to the difference between 'wire time' ~ and 'host time'. ~ ~Earlier during the e-mail thread, Al commented that also real ~sources of ~periodic streams may (and do) exhibit variation in ~transmission times. This ~is true, but incorporation of intentional deviations from ~periodic behaviour ~into the actual measurement metrics would result in a quite complex ~construct. Basically, a (public domain) source should be cited for ~definitive research results on "typical" variations due to O/S or ~application. This should then be mapped into a corresponding metrics ~description and so forth. ~ ~Thus, I find it a bit difficult to justify adding a mention of real ~application behaviour in this context. In my view, the goal ~should be that ~incT is (for practical purposes) negligible. ~ ~Season's greetings, ~ ~ Vilho ~ ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~ Vilho Räisänen ~ vilho.raisanen@nokia.com ~ Senior research engineer ~ Nokia Research Center, Helsinki, Finland ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ~ ~ From matt@advanced.org Thu Dec 28 04:36:25 2000 Received: from betelgeuse.advanced.org ([209.211.239.230]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14593 for ; Thu, 28 Dec 2000 04:36:25 -0500 (EST) Received: (from guest@localhost) by betelgeuse.advanced.org (8.9.3/8.9.1) id EAA13732 for ippm-l@advanced.org; Thu, 28 Dec 2000 04:26:35 -0500 (EST) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by betelgeuse.advanced.org (8.9.3/8.9.1) with ESMTP id EAA15165; Thu, 28 Dec 2000 04:26:33 -0500 (EST) From: vilho.raisanen@nokia.com Received: from esvir07nok.ntc.nokia.com (esvir07nokt.ntc.nokia.com [172.21.143.39]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eBS9PmB10177; Thu, 28 Dec 2000 11:25:48 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 28 Dec 2000 11:25:47 +0200 Received: by esebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 28 Dec 2000 11:25:47 +0200 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10520A8B1@eseis04nok> To: G.Grotefeld@motorola.com Cc: acmorton@att.com, matt@advanced.org, kaeo@merike.com, vilho.raisanen@nokia.com, ippm@advanced.org Subject: RE: npmps-04bis Date: Thu, 28 Dec 2000 11:25:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by betelgeuse.advanced.org id EAA15461 X-MIME-Autoconverted: from 8bit to quoted-printable by betelgeuse.advanced.org id EAB13732 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA14593 My intention was indeed to say that the _error_ in incT is preferably negligible in a realistic measurement setup. This correction applies to my explanation, and does not - in my understanding - require any changes to the draft. BR, Vilho %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Vilho Räisänen vilho.raisanen@nokia.com Senior research engineer Nokia Research Center, Helsinki, Finland %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > -----Original Message----- > From: EXT Grotefeld Glenn-cecl03 [mailto:G.Grotefeld@motorola.com] > Sent: 27. December 2000 17:13 > To: 'vilho.raisanen@nokia.com'; ippm@advanced.org > Cc: acmorton@att.com; matt@advanced.org; kaeo@merike.com > Subject: RE: npmps-04bis > > > Vilho, > > Thank you for the update. Unfortunately, I got the to end of > your note and found this: > > "Thus, I find it a bit difficult to justify adding a mention of real > application behaviour in this context. In my view, the goal > should be that > incT is (for practical purposes) negligible." > > > It appears that something may have been left out of this > sentence, possibly from the earlier discussion about errors > in incT. For Voice over IP (VoIP)and interactive multi-media > applications, incT is nominally 20ms with a desired one-way > delay on the order of 100ms. On this scale, I would consider > incT non-negligible. > > Glenn Grotefeld > > Motorola, Inc. > g.grotefeld@motorola.com > US 847 576-5992 > 847 538-7455 FAX > > > ~-----Original Message----- > ~From: vilho.raisanen@nokia.com [mailto:vilho.raisanen@nokia.com] > ~Sent: Friday, December 22, 2000 4:42 AM > ~To: ippm@advanced.org > ~Cc: acmorton@att.com; G.Grotefeld; matt@advanced.org; > kaeo@merike.com; > ~vilho.raisanen@nokia.com > ~Subject: npmps-04bis > ~ > ~ > ~Dear IPPMers, > ~ > ~please find attached the version -04bis of the npmps draft. > ~Thanks to Al & > ~Glenn for comments. The following changes to -04 have been made: > ~ > ~- I got rid of the the spurious month names due to Emacs' > ~case-insensitive > ~search & replace algorithm. Indeed, these JUNE have caused > ~some confusion. > ~- I implemented Al's refinement into 4.6. and added some more > ~text into incT > ~error bullet pt. The section now reads > ~ > ~ The description of any specific measurement method should > include an > ~ accounting and analysis of various sources of error or > uncertainty. > ~ The Framework document [1] provides general guidance on > this point, > ~ but we note here the following specifics related to periodic > ~ streams and delay metrics: > ~ > ~ + Error due to variation of incT. The reasons for this > can be e.g. > ~ uneven process scheduling, possibly due to CPU load. > ~ + Errors or uncertainties due to uncertainties in the > clocks of the > ~ MP(Src) and MP(Dst) measurement points. > ~ + Errors or uncertainties due to the difference between > 'wire time' > ~ and 'host time'. > ~ > ~Earlier during the e-mail thread, Al commented that also real > ~sources of > ~periodic streams may (and do) exhibit variation in > ~transmission times. This > ~is true, but incorporation of intentional deviations from > ~periodic behaviour > ~into the actual measurement metrics would result in a quite complex > ~construct. Basically, a (public domain) source should be cited for > ~definitive research results on "typical" variations due to O/S or > ~application. This should then be mapped into a corresponding metrics > ~description and so forth. > ~ > ~Thus, I find it a bit difficult to justify adding a mention of real > ~application behaviour in this context. In my view, the goal > ~should be that > ~incT is (for practical purposes) negligible. > ~ > ~Season's greetings, > ~ > ~ Vilho > ~ > ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > ~ Vilho Räisänen > ~ vilho.raisanen@nokia.com > ~ Senior research engineer > ~ Nokia Research Center, Helsinki, Finland > ~%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > ~ > ~ >