From cct-tq-admin@advanced.org Tue Oct 1 06:50:25 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07158 for ; Tue, 1 Oct 2002 06:50:25 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g91AqKiU009529 for ; Tue, 1 Oct 2002 06:52:20 -0400 Date: Tue, 01 Oct 2002 06:52:20 -0400 Message-ID: <20021001105220.8685.65044.Mailman@mailhost.advanced.org> Subject: advanced.org mailing list memberships reminder From: mailman-owner@advanced.org To: ippm-archive@ietf.org X-No-Archive: yes List-Id: Multiple lists at advanced.org X-Ack: no Sender: cct-tq-admin@advanced.org Errors-To: cct-tq-admin@advanced.org X-BeenThere: cct-tq@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your advanced.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ippm-request@advanced.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@advanced.org. Thanks! Passwords for ippm-archive@lists.ietf.org: List Password // URL ---- -------- ippm@advanced.org jTPE http://mailhost.advanced.org/mailman/options/ippm/ippm-archive%40lists.ietf.org From ippm-admin@advanced.org Tue Oct 1 10:57:40 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20894 for ; Tue, 1 Oct 2002 10:57:39 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g91Em3iU029814; Tue, 1 Oct 2002 10:48:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g91ElKiU029130 for ; Tue, 1 Oct 2002 10:47:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20305; Tue, 1 Oct 2002 10:45:20 -0400 (EDT) Message-Id: <200210011445.KAA20305@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , ippm@advanced.org From: The IESG Subject: [ippm] Protocol Action: Network performance measurement for periodic streams to Proposed Standard Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 01 Oct 2002 10:45:20 -0400 The IESG has approved the Internet-Draft 'Network performance measurement for periodic streams' as a Proposed Standard. This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary The document specifies a metric that introduces packets with repeating periods and length as a particular model. It formalizes periodic stream measurement to achieve comparable results between independent implementations. As noted in the IPPM framework RFC 2330, this type of metric has some limitations, such as probing only a limited part of of the perfomrance spectrum, but it also has strengths, of which just a few: * It can be configured to match particular inelastic media flows. * Measurement of many network impairments (e.g., delay variation, consecutive loss, reordering) are sensitive to the sampling frequency. When the impairments themselves are time-varying (and the variations are somewhat rare, yet important), a constant probing frequency may simplify analysis The specification provides the definition of the metric, and its analysis, a repeatable algorithm for it, and considerations for its security. It also specifies how to avoidcongestion and network synchronization effects that might arise with long running tests: 1. The performance sampled may be synchronized with some other periodic behavior, or the samples may be anticipated and the results manipulated. Unpredictable sampling is preferred. 2. Active measurements of sufficient volume can cause congestion, and periodic sampling might drive congestion-aware senders into a synchronized state, producing atypical results. The total traffic generated by this or any metric should be limited to avoid adverse affects on non-test traffic (random start times, choice of packet size, and test duration should be carefully considered, for instance). Working Group Summary There was good working group consensus on this document and careful review to ensure a correct specification. Protocol Quality The specification was reviewed for the IESG by Allison Mankin. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 2 18:29:55 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10079 for ; Wed, 2 Oct 2002 18:29:55 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g92MU4iU005070; Wed, 2 Oct 2002 18:30:04 -0400 Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g92MTAiU004802 for ; Wed, 2 Oct 2002 18:29:11 -0400 Received: from btmail.net.cn([202.106.196.71]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm4d3d9b8960; Wed, 2 Oct 2002 22:28:07 -0000 Received: from boreas.isi.edu([128.9.160.161]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm743d96afc1; Sun, 29 Sep 2002 04:27:52 -0000 Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.11.6/8.11.2) with ESMTP id g8T2j8C27599; Sat, 28 Sep 2002 19:45:08 -0700 (PDT) Received: by boreas.isi.edu (8.11.6/8.11.2) id g8T2SGR22408 for end2end-interest-mailman; Sat, 28 Sep 2002 19:28:16 -0700 (PDT) Received: from web15101.mail.bjs.yahoo.com (web15101.mail.bjs.yahoo.com [61.135.128.13]) by boreas.isi.edu (8.11.6/8.11.2) with SMTP id g8T2SAC22287 for ; Sat, 28 Sep 2002 19:28:11 -0700 (PDT) Message-ID: <20020929022801.52939.qmail@web15101.mail.bjs.yahoo.com> Received: from [61.174.139.165] by web15101.mail.bjs.yahoo.com via HTTP; Sun, 29 Sep 2002 10:28:01 CST From: =?gb2312?q?Shen=20Jing?= To: end2end-interest@postel.org Cc: ippm@advanced.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit X-AntiVirus: scanned by AMaViS 0.2.1 X-BeenThere: end2end-interest@postel.org X-Mailman-Version: 2.0.1 Precedence: bulk Subject: [ippm] [e2e] Mathematical analysis of e2e lable switching path Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sun, 29 Sep 2002 10:28:01 +0800 (CST) Content-Transfer-Encoding: 8bit Hi there, I've some question on e2e performance analysis of label switching path. There has been many research on e2e performance analysis for IP routing. Nearly all of them take the model of "network of queue", and under assumpiton of Possion Arrival, exponential flow size etc. To my limited knowledge, this is not to the state of Internet which experiences LRD. On the other hand, different router archtecture must have different effect on transmission performance. As MPLS proceeds to be the primary backbone technology, I think there must be something new introduced into the e2e performance in internet. So, I want to know, whether there is some work with methematical modeling of LSP networks? and, are there anyone would do me a favor to recommend some refrence book, web page, research paper or the like ? Thank you very much. Best regards ===== Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 03:58:51 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28565 for ; Thu, 3 Oct 2002 03:58:51 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g937w3iU023300; Thu, 3 Oct 2002 03:58:04 -0400 Received: from smtp.noos.fr (lafontaine.noos.net [212.198.2.72]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g937v9iV022662 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 3 Oct 2002 03:57:10 -0400 Received: (qmail 21421949 invoked by uid 0); 3 Oct 2002 07:57:09 -0000 Received: from unknown (HELO LIP60MU1PINK59) ([212.198.208.249]) (envelope-sender ) by 212.198.2.72 (qmail-ldap-1.03) with SMTP for ; 3 Oct 2002 07:57:09 -0000 From: "=?gb2312?B?S2F2qKYgU2FsYW1hdGlhbg==?=" To: "Shen Jing" , Cc: Subject: RE: [ippm] [e2e] Mathematical analysis of e2e lable switching path Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020929022801.52939.qmail@web15101.mail.bjs.yahoo.com> Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 09:56:39 +0200 Content-Transfer-Encoding: 8bit Dear Shen, first of all I should mention that MPLS deployment is far from being done (I don't think that it has been deployed even in a large network operator) and I largely suspect that it will never be deployed in a large scale to be the primary backbone technology !!!! From the point of view of measurement, LSP networks should not have too much difference from traditional IP networks as nowadays IP routing performance is getting very close to Label switching performance, meaning that the delay of crossing an LSP network should not be significantly larger than an IP network. The difference may come from a simpler traffic engineering in MPLS. Meaning that we should evaluate the effect of traffic engineeringon performance, not the particuliar behaviour of MPLS network. Bests Kv -----Message d'origine----- De?: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]De la part de Shen Jing Envoyé?: dimanche 29 septembre 2002 04:28 à?: end2end-interest@postel.org Cc?: ippm@advanced.org Objet?: [ippm] [e2e] Mathematical analysis of e2e lable switching path Hi there, I've some question on e2e performance analysis of label switching path. There has been many research on e2e performance analysis for IP routing. Nearly all of them take the model of "network of queue", and under assumpiton of Possion Arrival, exponential flow size etc. To my limited knowledge, this is not to the state of Internet which experiences LRD. On the other hand, different router archtecture must have different effect on transmission performance. As MPLS proceeds to be the primary backbone technology, I think there must be something new introduced into the e2e performance in internet. So, I want to know, whether there is some work with methematical modeling of LSP networks? and, are there anyone would do me a favor to recommend some refrence book, web page, research paper or the like ? Thank you very much. Best regards ===== Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _________________________________________________________ Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" http://cn.ent.yahoo.com/star/midautumn/index.html _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 11:11:43 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16201 for ; Thu, 3 Oct 2002 11:11:43 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93FA5iU004399; Thu, 3 Oct 2002 11:10:05 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93ANeiU007544 for ; Thu, 3 Oct 2002 06:23:45 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g93ANdIm021321; Thu, 3 Oct 2002 03:23:39 -0700 (PDT) Received: from cisco.com (ams-rraszuk2-vpn5.cisco.com [10.61.160.14]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAH68678; Thu, 3 Oct 2002 03:22:31 -0700 (PDT) Message-ID: <3D9C1AA3.70E763B8@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Kav=C3=A9?= Salamatian CC: Shen Jing , end2end-interest@postel.org, ippm@advanced.org, MPLS Operations Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [ippm] [Fwd: State of MPLS deployments today] Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 03 Oct 2002 12:23:31 +0200 Content-Transfer-Encoding: 8bit Kava, > first of all I should mention that MPLS deployment is far from being done (I > don't think that it has been deployed even in a large network operator) and > I largely suspect that it will never be deployed in a large scale to be the > primary backbone technology !!!! Would you mind sharing with me your definition of "large network operator" ? For me operators like ATT, BT, DT, FT, TI, Level3, Worldcom, JT, KDDI and many many more are of the size I would considered as "large" on this planet. All of them are using MPLS and MPLS applications in their backbones. Only a very few IP purists who get high blood pressure when one next to them says MPLS don't use it and that is also absolutely fine. Just one more comment: MPLS was never intended to boost network performance but to offer a new paradigm for various applications which benefit from not pure traditional dst based lookup at each hop. Sure IP can emulate it as well with tunnels, but it is obvious that in this case, when talking about production deployements IP is catching up with applications already offered by MPLS today in a scalable way. Rgs, R. > From: Kav茅 Salamatian > To: Shen Jing , end2end-interest@postel.org > Cc: ippm@advanced.org > Subject: RE: [ippm] [e2e] Mathematical analysis of e2e lable switching path > Date: 03 Oct 2002 09:56:39 +0200 > > Dear Shen, > > first of all I should mention that MPLS deployment is far from being done (I > don't think that it has been deployed even in a large network operator) and > I largely suspect that it will never be deployed in a large scale to be the > primary backbone technology !!!! > > >From the point of view of measurement, LSP networks should not have too much > difference from traditional IP networks as nowadays IP routing performance > is getting very close to Label switching performance, meaning that the > delay of crossing an LSP network should not be significantly larger than an > IP network. The difference may come from a simpler traffic engineering in > MPLS. Meaning that we should evaluate the effect of traffic engineeringon > performance, not the particuliar behaviour of MPLS network. > > Bests > > Kv > -----Message d'origine----- > De?: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]De la part de > Shen Jing > Envoy茅?: dimanche 29 septembre 2002 04:28 > 脿?: end2end-interest@postel.org > Cc?: ippm@advanced.org > Objet?: [ippm] [e2e] Mathematical analysis of e2e lable switching path > > > Hi there, > > I've some question on e2e performance analysis of > label switching path. > > There has been many research on e2e performance > analysis for IP routing. Nearly all of them take the > model of "network of queue", and under assumpiton of > Possion Arrival, exponential flow size etc. To my > limited knowledge, this is not to the state of > Internet which experiences LRD. On the other hand, > different router archtecture must have different > effect on transmission performance. > As MPLS proceeds to be the primary backbone > technology, I think there must be something new > introduced into the e2e performance in internet. > > So, I want to know, whether there is some work with > methematical modeling of LSP networks? and, are there > anyone would do me a favor to recommend some refrence > book, web page, research paper or the like ? > > Thank you very much. > > Best regards > > > ===== > Jing Shen > > State Key Lab of CAD&CG > ZheJiang University(YuQuan) > HangZhou, ZheJiang Province 310027 > P.R.China > > _________________________________________________________ > Do You Yahoo!? > "鍙戠煭淇¤耽鎵嬫満,蹇潵鍙傚姞闆呰檸宸ㄦ槦绉!" > http://cn.ent.yahoo.com/star/midautumn/index.html > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 16:02:58 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03164 for ; Thu, 3 Oct 2002 16:02:53 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93K33iU004281; Thu, 3 Oct 2002 16:03:03 -0400 Received: from smtp.noos.fr (aragon.noos.net [212.198.2.75]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93K2GiV004090 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Thu, 3 Oct 2002 16:02:17 -0400 Received: (qmail 16826697 invoked by uid 0); 3 Oct 2002 19:38:28 -0000 Received: from unknown (HELO KAVEMAISON) ([212.198.208.249]) (envelope-sender ) by 212.198.2.75 (qmail-ldap-1.03) with SMTP for ; 3 Oct 2002 19:38:28 -0000 From: =?iso-8859-1?Q?Kav=E9_Salamatian?= To: Cc: "Shen Jing" , , , "MPLS Operations" Subject: RE: [ippm] [Fwd: State of MPLS deployments today] 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.2910.0) In-Reply-To: <3D9C1AA3.70E763B8@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 21:38:31 +0200 Content-Transfer-Encoding: 7bit >> first of all I should mention that MPLS deployment is far from being done (I >> don't think that it has been deployed even in a large network operator) and >> I largely suspect that it will never be deployed in a large scale to be the >> primary backbone technology !!!! >Would you mind sharing with me your definition of "large network >operator" ? For me operators like ATT, BT, DT, FT, TI, Level3, Worldcom, >JT, KDDI and many many more are of the size I would considered as >"large" on this planet. I was saying that today we don't have yet (or at least I have not heard of) a full MPLS large network. I was not meaning that nobody is using MPLS in portion of his network. But obviously there are large full IP network that operate well (at least in their core) and does not seem to believe to an urgent need for MPLS. >All of them are using MPLS and MPLS applications in their backbones. Nice for MPLS constructors >Only a very few IP purists who get high blood pressure when one next to >them says MPLS don't use it and that is also absolutely fine. It seems that the search for purity is not restricted to IPist there are also some MPLS zeloat around :-) sorry to give you high blood pressure. Bests Kv _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 16:53:05 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04646 for ; Thu, 3 Oct 2002 16:53:04 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93Ks3iU020962; Thu, 3 Oct 2002 16:54:03 -0400 Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93KrXiU020846 for ; Thu, 3 Oct 2002 16:53:34 -0400 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17xCyK-000I2Y-00; Thu, 03 Oct 2002 13:53:24 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: =?iso-8859-1?Q?Kav=E9?= Salamatian , Shen Jing , end2end-interest@postel.org, ippm@advanced.org, MPLS Operations Subject: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] References: <3D9CA92F.3701C24B@cisco.com> Message-Id: Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 03 Oct 2002 13:53:24 -0700 Content-Transfer-Encoding: 7bit >> I was saying that today we don't have yet (or at least I have not heard of) >> a full MPLS large network. I was not meaning that nobody is using MPLS in >> portion of his network. > It is quite known that university professors are pretty much out of > touch with real networks and reality. as opposed to out of touch with manners or clue? _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 18:19:47 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06969 for ; Thu, 3 Oct 2002 18:19:46 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93MI3iU010581; Thu, 3 Oct 2002 18:18:03 -0400 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93MHDiU010298 for ; Thu, 3 Oct 2002 18:17:13 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g93KwXfw024778 for ; Thu, 3 Oct 2002 17:17:13 -0500 (CDT) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh3i.attrh.att.com (6.5.019) id 3D8B5605004274C4; Thu, 3 Oct 2002 18:17:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ippm] metric requirements Message-ID: <456FD0E7B215B24ABBAD711614E4A7A201842467@OCCLUST03EVS1.ugd.att.com> Thread-Topic: [ippm] metric requirements Thread-Index: AcJotpHfTeGH3GMnSkmI2ngAmxHKowCcOhQQ From: "Dvorak, Charles A (Chuck), ALASO" To: , "stanislav shalunov" , Cc: , "Ash, Gerald R (Jerry), ALASO" , "Tarapore, Percy S, ALASO" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g93MHDiU010298 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 18:17:10 -0400 Content-Transfer-Encoding: 8bit Further comments on packet loss: Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, NI-to-NI. All classes except best effort have a 0.1% packet loss objective, measured over an interval of a minute. One reason for this objective is an acknowledgment that in real networks, packets occur in bursts. So the "several percent packet loss" tolerance that many people have stated is really only for the unrealistic, uniformly distributed random case. When this 0.1% objective is met, speech quality will almost always be acceptable--as long as they don't all occur in just one or two bursts. Just FYI, AT&T Labs proposed a new approach (not adopted yet) that took a three-pronged approach to setting objectives for loss packets: One objective keeps the quality as good as a PSTN call; the second objective allows a few bursts spread out causing some, but not serious, degradation; the third objective limits the maximum sequential loss, so as to not have any bursts that in and of themselves cause an unacceptably annoying impairment during the minute interval. Finally, the E-model of G.107 was recently modified to accommodate (albeit crudely) the effects on speech quality of bursty packet loss, which should dispel the notion that the E-model is not for VoIP use. It is! Anyway a key message here is that (supporting Alan's message) during high burtsy losses, one goes from very good speech quality to unusable moments. Unlike random losses, bursts make you fall off a cliff. Chuck Dvorak AT&T Labs -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Monday, September 30, 2002 3:19 PM To: 'stanislav shalunov'; h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: RE: [ippm] metric requirements Fortunately many codecs behave in a consistent way and don't generate triple the amount of traffic in order to improve resilience!! Work done within ITU SG12, ETSI TIPHON and a few other groups has characterized the behavior of a wide range of codecs under packet loss conditions up to 20-30%. It can however be a little tricky deducing if packet loss concealment is in use from the info available in RTP headers! One key point when considering the effects of packet loss on VoIP is the distribution of packet loss. This does not behave, as many would suggest, as a simple burst channel exhibiting only consecutive loss. Bursts of loss are often sparse (e.g. 20%) and extend for periods of seconds - largely caused by periods of congestion. You may also see the extreme case of bursts of consecutive loss extending for hundreds of packets, due to link failures. The effect of this is that call quality will be fine for some period of time, and then experience several seconds of badly degraded quality before improving again. Alan Clark -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of stanislav shalunov Sent: Monday, September 30, 2002 12:10 PM To: h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: Re: [ippm] metric requirements "H.E.Holland" writes: > Where might I find quantitative metric requirements for services > such as VoIP? E.g. what are recommended values for one-way delay and > packet loss for a VoIP service? While others pointed out the ITU documents for one-way delay, I don't think we answered the `loss' part of the question. There can possibly be no answer, because codecs have various degrees of tolerance and redundancy. Relevant gedanken Experiment: Imagine that your favorite codec were to send all its packets in triplicate; that would change the threshold of tolerance for loss, wouldn't it? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 18:56:08 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07767 for ; Thu, 3 Oct 2002 18:56:08 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93MvAiU020227; Thu, 3 Oct 2002 18:57:10 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93L6NiU023447 for ; Thu, 3 Oct 2002 17:06:24 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g93L6NIm016209; Thu, 3 Oct 2002 14:06:23 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI17485; Thu, 3 Oct 2002 14:04:05 -0700 (PDT) Message-ID: <3D9CB14A.3ADB96C9@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: =?iso-8859-1?Q?Kav=E9?= Salamatian , Shen Jing , end2end-interest@postel.org, ippm@advanced.org, MPLS Operations Subject: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] References: <3D9CA92F.3701C24B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 03 Oct 2002 23:06:18 +0200 Content-Transfer-Encoding: 7bit Hi Randy, As far as the clue part I would recommed to wait for VPRN presentation to go public at next nanog so everybody can judge who is clufull or clueless reg MPLS applications especially 2547bin :-). R. > Randy Bush wrote: > > >> I was saying that today we don't have yet (or at least I have not heard of) > >> a full MPLS large network. I was not meaning that nobody is using MPLS in > >> portion of his network. > > It is quite known that university professors are pretty much out of > > touch with real networks and reality. > > as opposed to out of touch with manners or clue? > > _______________________________________________ > ippm mailing list > ippm@advanced.org > http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 19:56:04 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07768 for ; Thu, 3 Oct 2002 18:56:08 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93Mv3iU019871; Thu, 3 Oct 2002 18:57:03 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93KVmiU014438 for ; Thu, 3 Oct 2002 16:31:49 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g93KVeaW003023; Thu, 3 Oct 2002 13:31:40 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI15911; Thu, 3 Oct 2002 13:29:29 -0700 (PDT) Message-ID: <3D9CA92F.3701C24B@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: =?iso-8859-1?Q?Kav=E9?= Salamatian CC: Shen Jing , end2end-interest@postel.org, ippm@advanced.org, MPLS Operations Subject: Re: [ippm] [Fwd: State of MPLS deployments today] References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 03 Oct 2002 22:31:43 +0200 Content-Transfer-Encoding: 8bit Dear Prof. Kav Salamatian, > I was saying that today we don't have yet (or at least I have not heard of) > a full MPLS large network. I was not meaning that nobody is using MPLS in > portion of his network. It is quite known that university professors are pretty much out of touch with real networks and reality. To help you overcome this I guess we need to step back to MPLS 101 with you and find out what "MPLS" really means. Let me ask you a basic question - why would anyone run TDP & LDP only in partion of his network ? That is one of few MPLS forwarding mechanisms used very widely today across multiple world scale providers. Just as a tiny reference not related to any vendor take a look at the folowing URL and download "MPLS Unofficial List": http://cellstream.com/MPLS_List.htm or just click on http://www.mplsrc.com/faq3.shtml and browse to all MPLS-VPN providers. Keep in mind that 99% of MPLS-VPN providers use TDP or LDP in their ENTIRE backbone. > It seems that the search for purity is not restricted to IPist there are > also some MPLS zeloat around :-) sorry to give you high blood pressure. He he he - I am not effected by this at all, I just try to make sure that the information on the public lists are correct :). R. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 21:24:28 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10256 for ; Thu, 3 Oct 2002 21:24:28 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941O3iU015184; Thu, 3 Oct 2002 21:24:03 -0400 Received: from telchemy.com ([66.155.69.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941NGiU014747 for ; Thu, 3 Oct 2002 21:23:16 -0400 Received: from alansnotebook [66.156.10.213] by telchemy.com with ESMTP (SMTPD32-7.11) id ADAC50703EC; Thu, 03 Oct 2002 21:23:56 -0400 From: "Telchemy Standards Tracking" To: "Dvorak, Charles A \(Chuck\), ALASO" , "stanislav shalunov" , Cc: , "Ash, Gerald R \(Jerry\), ALASO" , "Tarapore, Percy S, ALASO" , , Subject: RE: [ippm] metric requirements 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 In-Reply-To: <456FD0E7B215B24ABBAD711614E4A7A201842467@OCCLUST03EVS1.ugd.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 21:26:54 -0400 Content-Transfer-Encoding: 7bit This may be getting into too much detail (however is my favorite subject!!!) We recently compared the burst parameters of multiple large traces using both the consecutive loss and a Gilbert model. In addition to analyzing pure packet loss we also looked at the distribution of discards due to jitter. The result showed clearly that bursts of both loss and loss/discard were typically 20-200 packets in length with loss densities of 20-30%, whereas the consecutive loss model would have suggested bursts averaging 1.5 packets!!! This is an easy experiment to duplicate and can be performed with Sue Moon or Wenyu Jiang's trace files. For those able to make measurements on core IP networks then it is quite possible that loss would primarily occur to to route changes or link failures and hence that loss may often be consecutive, this should not however be used to infer that loss is always consecutive. I agree with Chuck that a multi-pronged approach is essential however I would suggest that a Gilbert/ Gilbert-Elliott or 3/4-state Markov model based approach would be preferable to a consecutive loss model. We use a 4-state Markov model which combines the ability of Gilbert-Elliott to capture long sparse bursts with the ability of a 2-state model to capture consecutive loss, this is computationally efficient and produces all the statistics needed. The E Model modifications that were made to support bursty loss unfortunately focus only on consecutive loss - this is a definite improvement however still does not reflect conditions that appear quite common on some networks (including both Enterprise IP networks and the Internet). If the E model is used for planning (it's original purpose) then you don't know what the distribution of packet loss is - hence the current E model provides a good approach. In a monitoring (or simulated) enviroment then it may be possible to see what actually happened in which case a more sophisticated approach may be justified. Regards Alan Clark Telchemy -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of Dvorak, Charles A (Chuck), ALASO Sent: Thursday, October 03, 2002 6:17 PM To: alan@telchemy.com; stanislav shalunov; h.e.holland@student.utwente.nl Cc: ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Subject: RE: [ippm] metric requirements Further comments on packet loss: Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, NI-to-NI. All classes except best effort have a 0.1% packet loss objective, measured over an interval of a minute. One reason for this objective is an acknowledgment that in real networks, packets occur in bursts. So the "several percent packet loss" tolerance that many people have stated is really only for the unrealistic, uniformly distributed random case. When this 0.1% objective is met, speech quality will almost always be acceptable--as long as they don't all occur in just one or two bursts. Just FYI, AT&T Labs proposed a new approach (not adopted yet) that took a three-pronged approach to setting objectives for loss packets: One objective keeps the quality as good as a PSTN call; the second objective allows a few bursts spread out causing some, but not serious, degradation; the third objective limits the maximum sequential loss, so as to not have any bursts that in and of themselves cause an unacceptably annoying impairment during the minute interval. Finally, the E-model of G.107 was recently modified to accommodate (albeit crudely) the effects on speech quality of bursty packet loss, which should dispel the notion that the E-model is not for VoIP use. It is! Anyway a key message here is that (supporting Alan's message) during high burtsy losses, one goes from very good speech quality to unusable moments. Unlike random losses, bursts make you fall off a cliff. Chuck Dvorak AT&T Labs -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Monday, September 30, 2002 3:19 PM To: 'stanislav shalunov'; h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: RE: [ippm] metric requirements Fortunately many codecs behave in a consistent way and don't generate triple the amount of traffic in order to improve resilience!! Work done within ITU SG12, ETSI TIPHON and a few other groups has characterized the behavior of a wide range of codecs under packet loss conditions up to 20-30%. It can however be a little tricky deducing if packet loss concealment is in use from the info available in RTP headers! One key point when considering the effects of packet loss on VoIP is the distribution of packet loss. This does not behave, as many would suggest, as a simple burst channel exhibiting only consecutive loss. Bursts of loss are often sparse (e.g. 20%) and extend for periods of seconds - largely caused by periods of congestion. You may also see the extreme case of bursts of consecutive loss extending for hundreds of packets, due to link failures. The effect of this is that call quality will be fine for some period of time, and then experience several seconds of badly degraded quality before improving again. Alan Clark -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of stanislav shalunov Sent: Monday, September 30, 2002 12:10 PM To: h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: Re: [ippm] metric requirements "H.E.Holland" writes: > Where might I find quantitative metric requirements for services > such as VoIP? E.g. what are recommended values for one-way delay and > packet loss for a VoIP service? While others pointed out the ITU documents for one-way delay, I don't think we answered the `loss' part of the question. There can possibly be no answer, because codecs have various degrees of tolerance and redundancy. Relevant gedanken Experiment: Imagine that your favorite codec were to send all its packets in triplicate; that would change the threshold of tolerance for loss, wouldn't it? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 21:31:34 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10327 for ; Thu, 3 Oct 2002 21:31:33 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941W3iU017628; Thu, 3 Oct 2002 21:32:03 -0400 Received: from telchemy.com ([66.155.69.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941VBiU017433 for ; Thu, 3 Oct 2002 21:31:11 -0400 Received: from alansnotebook [66.156.10.213] by telchemy.com with ESMTP (SMTPD32-7.11) id AF8749D03FC; Thu, 03 Oct 2002 21:31:51 -0400 From: "Alan Clark" To: "Dvorak, Charles A \(Chuck\), ALASO" , "stanislav shalunov" , Cc: , "Ash, Gerald R \(Jerry\), ALASO" , "Tarapore, Percy S, ALASO" , , Subject: RE: [ippm] metric requirements 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 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 21:34:50 -0400 Content-Transfer-Encoding: 7bit This may be getting into too much detail (however is my favorite subject!!!) We recently compared the burst parameters of multiple large traces using both the consecutive loss and a Gilbert model. In addition to analyzing pure packet loss we also looked at the distribution of discards due to jitter. The result showed clearly that bursts of both loss and loss/discard were typically 20-200 packets in length with loss densities of 20-30%, whereas the consecutive loss model would have suggested bursts averaging 1.5 packets!!! This is an easy experiment to duplicate and can be performed with Sue Moon or Wenyu Jiang's trace files. For those able to make measurements on core IP networks then it is quite possible that loss would primarily occur to to route changes or link failures and hence that loss may often be consecutive, this should not however be used to infer that loss is always consecutive. I agree with Chuck that a multi-pronged approach is essential however I would suggest that a Gilbert/ Gilbert-Elliott or 3/4-state Markov model based approach would be preferable to a consecutive loss model. We use a 4-state Markov model which combines the ability of Gilbert-Elliott to capture long sparse bursts with the ability of a 2-state model to capture consecutive loss, this is computationally efficient and produces all the statistics needed. The E Model modifications that were made to support bursty loss unfortunately focus only on consecutive loss - this is a definite improvement however still does not reflect conditions that appear quite common on some networks (including both Enterprise IP networks and the Internet). If the E model is used for planning (it's original purpose) then you don't know what the distribution of packet loss is - hence the current E model provides a good approach. In a monitoring (or simulated) enviroment then it may be possible to see what actually happened in which case a more sophisticated approach may be justified. Regards Alan Clark Telchemy -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of Dvorak, Charles A (Chuck), ALASO Sent: Thursday, October 03, 2002 6:17 PM To: alan@telchemy.com; stanislav shalunov; h.e.holland@student.utwente.nl Cc: ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Subject: RE: [ippm] metric requirements Further comments on packet loss: Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, NI-to-NI. All classes except best effort have a 0.1% packet loss objective, measured over an interval of a minute. One reason for this objective is an acknowledgment that in real networks, packets occur in bursts. So the "several percent packet loss" tolerance that many people have stated is really only for the unrealistic, uniformly distributed random case. When this 0.1% objective is met, speech quality will almost always be acceptable--as long as they don't all occur in just one or two bursts. Just FYI, AT&T Labs proposed a new approach (not adopted yet) that took a three-pronged approach to setting objectives for loss packets: One objective keeps the quality as good as a PSTN call; the second objective allows a few bursts spread out causing some, but not serious, degradation; the third objective limits the maximum sequential loss, so as to not have any bursts that in and of themselves cause an unacceptably annoying impairment during the minute interval. Finally, the E-model of G.107 was recently modified to accommodate (albeit crudely) the effects on speech quality of bursty packet loss, which should dispel the notion that the E-model is not for VoIP use. It is! Anyway a key message here is that (supporting Alan's message) during high burtsy losses, one goes from very good speech quality to unusable moments. Unlike random losses, bursts make you fall off a cliff. Chuck Dvorak AT&T Labs -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Monday, September 30, 2002 3:19 PM To: 'stanislav shalunov'; h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: RE: [ippm] metric requirements Fortunately many codecs behave in a consistent way and don't generate triple the amount of traffic in order to improve resilience!! Work done within ITU SG12, ETSI TIPHON and a few other groups has characterized the behavior of a wide range of codecs under packet loss conditions up to 20-30%. It can however be a little tricky deducing if packet loss concealment is in use from the info available in RTP headers! One key point when considering the effects of packet loss on VoIP is the distribution of packet loss. This does not behave, as many would suggest, as a simple burst channel exhibiting only consecutive loss. Bursts of loss are often sparse (e.g. 20%) and extend for periods of seconds - largely caused by periods of congestion. You may also see the extreme case of bursts of consecutive loss extending for hundreds of packets, due to link failures. The effect of this is that call quality will be fine for some period of time, and then experience several seconds of badly degraded quality before improving again. Alan Clark -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of stanislav shalunov Sent: Monday, September 30, 2002 12:10 PM To: h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: Re: [ippm] metric requirements "H.E.Holland" writes: > Where might I find quantitative metric requirements for services > such as VoIP? E.g. what are recommended values for one-way delay and > packet loss for a VoIP service? While others pointed out the ITU documents for one-way delay, I don't think we answered the `loss' part of the question. There can possibly be no answer, because codecs have various degrees of tolerance and redundancy. Relevant gedanken Experiment: Imagine that your favorite codec were to send all its packets in triplicate; that would change the threshold of tolerance for loss, wouldn't it? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 3 21:36:19 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10532 for ; Thu, 3 Oct 2002 21:36:19 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941b3iU018902; Thu, 3 Oct 2002 21:37:03 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g941aoiU018805 for ; Thu, 3 Oct 2002 21:36:54 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g940xfNg016936 for ; Thu, 3 Oct 2002 21:36:50 -0400 (EDT) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh3i.attrh.att.com (6.5.019) id 3D8B560500431775; Thu, 3 Oct 2002 21:36:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ippm] metric requirements Message-ID: <456FD0E7B215B24ABBAD711614E4A7A2016095F8@OCCLUST03EVS1.ugd.att.com> Thread-Topic: [ippm] metric requirements Thread-Index: AcJrRL0bfWwIvwrYTUWwdFIfsZ/qtAAAPiWQ From: "Dvorak, Charles A (Chuck), ALASO" To: "Telchemy Standards Tracking" , "stanislav shalunov" , Cc: , "Ash, Gerald R (Jerry), ALASO" , "Tarapore, Percy S, ALASO" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g941aoiU018805 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 21:36:48 -0400 Content-Transfer-Encoding: 8bit Just for clarity, we are not advocating a focus on consecutive loss! But one does want to know, as a function of codec type, how much consecutive loss you can have before just one such occurrence on a VoIP call makes it unacceptable. Chuck Dvorak AT&T Labs -----Original Message----- From: Telchemy Standards Tracking [mailto:standards@telchemy.com] Sent: Thursday, October 03, 2002 9:27 PM To: Dvorak, Charles A (Chuck), ALASO; stanislav shalunov; h.e.holland@student.utwente.nl Cc: ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Subject: RE: [ippm] metric requirements This may be getting into too much detail (however is my favorite subject!!!) We recently compared the burst parameters of multiple large traces using both the consecutive loss and a Gilbert model. In addition to analyzing pure packet loss we also looked at the distribution of discards due to jitter. The result showed clearly that bursts of both loss and loss/discard were typically 20-200 packets in length with loss densities of 20-30%, whereas the consecutive loss model would have suggested bursts averaging 1.5 packets!!! This is an easy experiment to duplicate and can be performed with Sue Moon or Wenyu Jiang's trace files. For those able to make measurements on core IP networks then it is quite possible that loss would primarily occur to to route changes or link failures and hence that loss may often be consecutive, this should not however be used to infer that loss is always consecutive. I agree with Chuck that a multi-pronged approach is essential however I would suggest that a Gilbert/ Gilbert-Elliott or 3/4-state Markov model based approach would be preferable to a consecutive loss model. We use a 4-state Markov model which combines the ability of Gilbert-Elliott to capture long sparse bursts with the ability of a 2-state model to capture consecutive loss, this is computationally efficient and produces all the statistics needed. The E Model modifications that were made to support bursty loss unfortunately focus only on consecutive loss - this is a definite improvement however still does not reflect conditions that appear quite common on some networks (including both Enterprise IP networks and the Internet). If the E model is used for planning (it's original purpose) then you don't know what the distribution of packet loss is - hence the current E model provides a good approach. In a monitoring (or simulated) enviroment then it may be possible to see what actually happened in which case a more sophisticated approach may be justified. Regards Alan Clark Telchemy -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of Dvorak, Charles A (Chuck), ALASO Sent: Thursday, October 03, 2002 6:17 PM To: alan@telchemy.com; stanislav shalunov; h.e.holland@student.utwente.nl Cc: ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Subject: RE: [ippm] metric requirements Further comments on packet loss: Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, NI-to-NI. All classes except best effort have a 0.1% packet loss objective, measured over an interval of a minute. One reason for this objective is an acknowledgment that in real networks, packets occur in bursts. So the "several percent packet loss" tolerance that many people have stated is really only for the unrealistic, uniformly distributed random case. When this 0.1% objective is met, speech quality will almost always be acceptable--as long as they don't all occur in just one or two bursts. Just FYI, AT&T Labs proposed a new approach (not adopted yet) that took a three-pronged approach to setting objectives for loss packets: One objective keeps the quality as good as a PSTN call; the second objective allows a few bursts spread out causing some, but not serious, degradation; the third objective limits the maximum sequential loss, so as to not have any bursts that in and of themselves cause an unacceptably annoying impairment during the minute interval. Finally, the E-model of G.107 was recently modified to accommodate (albeit crudely) the effects on speech quality of bursty packet loss, which should dispel the notion that the E-model is not for VoIP use. It is! Anyway a key message here is that (supporting Alan's message) during high burtsy losses, one goes from very good speech quality to unusable moments. Unlike random losses, bursts make you fall off a cliff. Chuck Dvorak AT&T Labs -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Monday, September 30, 2002 3:19 PM To: 'stanislav shalunov'; h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: RE: [ippm] metric requirements Fortunately many codecs behave in a consistent way and don't generate triple the amount of traffic in order to improve resilience!! Work done within ITU SG12, ETSI TIPHON and a few other groups has characterized the behavior of a wide range of codecs under packet loss conditions up to 20-30%. It can however be a little tricky deducing if packet loss concealment is in use from the info available in RTP headers! One key point when considering the effects of packet loss on VoIP is the distribution of packet loss. This does not behave, as many would suggest, as a simple burst channel exhibiting only consecutive loss. Bursts of loss are often sparse (e.g. 20%) and extend for periods of seconds - largely caused by periods of congestion. You may also see the extreme case of bursts of consecutive loss extending for hundreds of packets, due to link failures. The effect of this is that call quality will be fine for some period of time, and then experience several seconds of badly degraded quality before improving again. Alan Clark -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of stanislav shalunov Sent: Monday, September 30, 2002 12:10 PM To: h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: Re: [ippm] metric requirements "H.E.Holland" writes: > Where might I find quantitative metric requirements for services > such as VoIP? E.g. what are recommended values for one-way delay and > packet loss for a VoIP service? While others pointed out the ITU documents for one-way delay, I don't think we answered the `loss' part of the question. There can possibly be no answer, because codecs have various degrees of tolerance and redundancy. Relevant gedanken Experiment: Imagine that your favorite codec were to send all its packets in triplicate; that would change the threshold of tolerance for loss, wouldn't it? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 04:55:24 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26391 for ; Fri, 4 Oct 2002 04:55:23 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g948s4iU011137; Fri, 4 Oct 2002 04:54:04 -0400 Received: from web15104.mail.bjs.yahoo.com (web15104.mail.bjs.yahoo.com [61.135.128.16]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g948rIiU010992 for ; Fri, 4 Oct 2002 04:53:19 -0400 Message-ID: <20021004085316.69524.qmail@web15104.mail.bjs.yahoo.com> Received: from [61.174.154.214] by web15104.mail.bjs.yahoo.com via HTTP; Fri, 04 Oct 2002 16:53:16 CST From: =?gb2312?q?Jing=20Shen?= Subject: RE: [ippm] [e2e] Mathematical analysis of e2e lable switching path To: "Kavé" Salamatian , end2end-interest@postel.org Cc: ippm@advanced.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-139865788-1033721596=:69030" Content-Transfer-Encoding: 8bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 4 Oct 2002 16:53:16 +0800 (CST) --0-139865788-1033721596=:69030 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 8bit Thanks for all those response. To my limited knowledge on MPLS implementation, many Telecommunication Cooperation have adopted MPLS in their service network, such as UUnet, AT&T. In China, ChinaTelecom has built up a experimental MPLS backbone accross multiple provinces, and China Unicom also built up a backbone alike. In deed, it seems MPLS network is not put directly to commercial usage in China but some of stuff in ChinaTelecom told me that they do care the VPN capacity, TE capacity and high performance promised by MPLS. The problem is the operators seem could not catch up with the complex configuration so fast. So, I don't understand why MPLS will not be used in large scale networks? To the performance difference between MPLS network and IP network, I totally agree with you IP router have achieve the same performance with MPLS. But, to our experiments with comparation between LSP and IP routing , there do exist some difference between LSP and IP routing. We've built a very small testbed to compare difference between LSP& IP routing, and we found that LSP shows lower jitter and packet loss rate under resource reservation scheme and best-effort service under low load. This is the reason why I asked the question. Best regards Kavé Salamatian 的正文： Dear Shen, first of all I should mention that MPLS deployment is far from being done (I don't think that it has been deployed even in a large network operator) and I largely suspect that it will never be deployed in a large scale to be the primary backbone technology !!!! From the point of view of measurement, LSP networks should not have too much difference from traditional IP networks as nowadays IP routing performance is getting very close to Label switching performance, meaning that the delay of crossing an LSP network should not be significantly larger than an IP network. The difference may come from a simpler traffic engineering in MPLS. Meaning that we should evaluate the effect of traffic engineeringon performance, not the particuliar behaviour of MPLS network. Bests Kv -----Message d'origine----- De?: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]De la part de Shen Jing Envoyé?: dimanche 29 septembre 2002 04:28 à?: end2end-interest@postel.org Cc?: ippm@advanced.org Objet?: [ippm] [e2e] Mathematical analysis of e2e lable switching path Hi there, I've some question on e2e performance analysis of label switching path. There has been many research on e2e performance analysis for IP routing. Nearly all of them take the model of "network of queue", and under assumpiton of Possion Arrival, exponential flow size etc. To my limited knowledge, this is not to the state of Internet which experiences LRD. On the other hand, different router archtecture must have different effect on transmission performance. As MPLS proceeds to be the primary backbone technology, I think there must be something new introduced into the e2e performance in internet. So, I want to know, whether there is some work with methematical modeling of LSP networks? and, are there anyone would do me a favor to recommend some refrence book, web page, research paper or the like ? Thank you very much. Best regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China --------------------------------- Do You Yahoo!? "发短信赢手机,快来参加雅虎巨星秀!" --0-139865788-1033721596=:69030 Content-Type: text/html; charset=gb2312 Content-Transfer-Encoding: 8bit

Thanks for all those response.

To my limited knowledge on MPLS implementation, many Telecommunication Cooperation

have adopted MPLS in their service network, such as UUnet,  AT&T. In China, ChinaTelecom has built up

a experimental MPLS backbone accross multiple provinces, and China Unicom also built up a backbone alike.

In deed, it seems MPLS network is not put directly to commercial usage in China but some of stuff in ChinaTelecom

told me that they do care the VPN capacity,  TE capacity and high performance promised by MPLS. The problem is

the operators seem could not catch up with the complex configuration so fast.  So, I don't understand

why MPLS will not be used in large scale networks?

To the performance difference between MPLS network and IP network, I totally agree with you IP router have achieve

the same performance with MPLS. But, to our experiments with comparation between LSP and IP routing , there do exist

some difference between LSP and IP routing. We've built a very small testbed to compare difference between LSP& IP routing,

and we found that LSP shows lower jitter and packet loss rate under resource reservation scheme and best-effort service under low

load. This is the reason why I asked the question.

Best regards

 

  Kavé Salamatian <salamat@rp.lip6.fr> 的正文：

Dear Shen,

first of all I should mention that MPLS deployment is far from being done (I
don't think that it has been deployed even in a large network operator) and
I largely suspect that it will never be deployed in a large scale to be the
primary backbone technology !!!!

From the point of view of measurement, LSP networks should not have too much
difference from traditional IP networks as nowadays IP routing performance
is getting very close to Label switching performance, meaning that the
delay of crossing an LSP network should not be significantly larger than an
IP network. The difference may come from a simpler traffic engineering in
MPLS. Meaning that we should evaluate the effect of traffic engineeringon
performance, not the particuliar behaviour of MPLS network.

Bests

Kv
-----Message d'origine-----
De?: ippm-admin@advance! d.org [mailto:ippm-admin@advanced.org]De la part de
Shen Jing
Envoyé?: dimanche 29 septembre 2002 04:28
à?: end2end-interest@postel.org
Cc?: ippm@advanced.org
Objet?: [ippm] [e2e] Mathematical analysis of e2e lable switching path


Hi there,

I've some question on e2e performance analysis of
label switching path.

There has been many research on e2e performance
analysis for IP routing. Nearly all of them take the
model of "network of queue", and under assumpiton of
Possion Arrival, exponential flow size etc. To my
limited knowledge, this is not to the state of
Internet which experiences LRD. On the other hand,
different router archtecture must have different
effect on transmission performance.
As MPLS proceeds to be the primary backbone
technology, I think there must be something new
introduced into the e2e performance in internet.

So, I want to know, whether there is some work with
methematical! modeling of LSP networks? and, are there
anyone would do me a favor to recommend some refrence
book, web page, research paper or the like ?

Thank you very much.

Best regards



Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China


Do You Yahoo!?
"发短信赢手机,快来参加雅虎巨星秀!" --0-139865788-1033721596=:69030-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 06:55:49 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28115 for ; Fri, 4 Oct 2002 06:55:49 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94Aq3iU029616; Fri, 4 Oct 2002 06:52:03 -0400 Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94ApZiU029522 for ; Fri, 4 Oct 2002 06:51:35 -0400 Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17xQ3S-000OWq-00; Fri, 04 Oct 2002 03:51:34 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Bob Braden , salamat@rp.lip6.Fr, jshen_cad@yahoo.com.cn, end2end-interest@postel.org, ippm@advanced.org Subject: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] References: <200210032311.XAA18588@gra.isi.edu> <3D9D41A3.75F47473@cisco.com> Message-Id: Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 04 Oct 2002 03:51:34 -0700 Content-Transfer-Encoding: 7bit > I just couldn't resist to address his comments after last few years > dedicated to deploying various MPLS applications around the world to > numerous production networks of large operators. it would be more useful to hear from the actual operators themselves how they have deployed such technologies in the core of their networks, as opposed to hearing from their official spokes-company from san jose. randy _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 09:15:10 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02567 for ; Fri, 4 Oct 2002 09:15:10 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94DG4iU023756; Fri, 4 Oct 2002 09:16:04 -0400 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g93NBViU023231 for ; Thu, 3 Oct 2002 19:11:31 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g93NBNQ11737; Thu, 3 Oct 2002 16:11:23 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id XAA18588; Thu, 3 Oct 2002 23:11:23 GMT Message-Id: <200210032311.XAA18588@gra.isi.edu> To: salamat@rp.lip6.Fr, raszuk@cisco.com Subject: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] Cc: jshen_cad@yahoo.com.cn, end2end-interest@postel.org, ippm@advanced.org, mpls-ops@mplsrc.com X-Sun-Charset: US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 3 Oct 2002 23:11:23 GMT *> *> It is quite known that university professors are pretty much out of *> touch with real networks and reality Then please remove the end2end-interest list from this discussion. This list includes quite a number of university professors; if you are not interested in their contributions, you are wasting their time as well as insulting them. What company did you say you work for? Bob Braden _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 09:15:13 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02582 for ; Fri, 4 Oct 2002 09:15:13 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94DGAiU023987; Fri, 4 Oct 2002 09:16:10 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g947MMiU000879 for ; Fri, 4 Oct 2002 03:22:23 -0400 Received: from mira-sjcm-3.cisco.com (IDENT:mirapoint@mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g947MHIm004476; Fri, 4 Oct 2002 00:22:17 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjcm-3.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with ESMTP id AAI32074; Fri, 4 Oct 2002 00:19:59 -0700 (PDT) Message-ID: <3D9D41A3.75F47473@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Braden CC: salamat@rp.lip6.Fr, jshen_cad@yahoo.com.cn, end2end-interest@postel.org, ippm@advanced.org, mpls-ops@mplsrc.com Subject: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] References: <200210032311.XAA18588@gra.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 04 Oct 2002 09:22:11 +0200 Content-Transfer-Encoding: 7bit Bob, I did generalized that statement what is not correct. I meant to say that _a_few_ university folks don't relly keep track of the way large networks worldwide are operated today - yet they issue a statements which simply don't have any backup in facts. I apologize for the tone of my mail - I did not intended to insult anyone on this list including Prof Kave himself. In fact I have been looking into his COST works and I do greatly appreciate his papers there ! I just couldn't resist to address his comments after last few years dedicated to deploying various MPLS applications around the world to numerous production networks of large operators. Sincerely, R. > Bob Braden wrote: > > *> > *> It is quite known that university professors are pretty much out of > *> touch with real networks and reality > > Then please remove the end2end-interest list from this discussion. > This list includes quite a number of university professors; if you > are not interested in their contributions, you are wasting their time > as well as insulting them. What company did you say you work for? > > Bob Braden _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 09:17:46 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02685 for ; Fri, 4 Oct 2002 09:17:45 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94DGHiU024390; Fri, 4 Oct 2002 09:16:17 -0400 Received: from maties1.sun.ac.za (maties1.sun.ac.za [146.232.128.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g949dViU017631 for ; Fri, 4 Oct 2002 05:39:32 -0400 Received: from erwin.cs.sun.ac.za ([146.232.212.13]) by maties1.sun.ac.za with esmtp (Exim 4.05) id 17xOvL-0002aV-00; Fri, 04 Oct 2002 11:39:07 +0200 Received: from bagula (helo=localhost) by erwin.cs.sun.ac.za with local-esmtp (Exim 3.35 #1 (Debian)) id 17xOvL-0005JE-00; Fri, 04 Oct 2002 11:39:07 +0200 From: Antoine Bagula To: Robert Raszuk cc: Randy Bush , =?iso-8859-1?Q?Kav=E9?= Salamatian , Shen Jing , , , MPLS Operations Subject: Re: [MPLS-OPS]: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] In-Reply-To: <3D9CB14A.3ADB96C9@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *17xOvL-0002aV-00*mEDfAc87.rw* Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 4 Oct 2002 11:39:07 +0200 (SAST) I have the impression that Robert's type of answer is typical on this list when pros and cons MPLS is concerned. Thanks to Randy and Bob for their interventions which i hope will help us avoid agressive answers on the list in the future. I also think that as far as MPLS efficiency, utility or whatever people should call as synonym of efficiency, several questions stand unanswered: 1) Can people express their opinion on the list concerning limitations of MPLS ? 2) Can those who have solutions to these limitations also propose these solutions ? 3) Did someone on the list gave an answer to the concern of professor Kave : what is the effect of traffic engineering on network performance? BA. Bagula. On Thu, 3 Oct 2002, Robert Raszuk wrote: > Hi Randy, > > As far as the clue part I would recommed to wait for VPRN presentation > to go public at next nanog so everybody can judge who is clufull or > clueless reg MPLS applications especially 2547bin :-). > > R. > > > Randy Bush wrote: > > > > >> I was saying that today we don't have yet (or at least I have not heard of) > > >> a full MPLS large network. I was not meaning that nobody is using MPLS in > > >> portion of his network. > > > It is quite known that university professors are pretty much out of > > > touch with real networks and reality. > > > > as opposed to out of touch with manners or clue? > > > > _______________________________________________ > > ippm mailing list > > ippm@advanced.org > > http://mailhost.advanced.org/mailman/listinfo/ippm > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 11:35:08 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08251 for ; Fri, 4 Oct 2002 11:35:07 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94FaAiU031086; Fri, 4 Oct 2002 11:36:10 -0400 Received: from cisco.com ([64.102.17.77]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94FCPiU023752 for ; Fri, 4 Oct 2002 11:12:26 -0400 Received: from asimha-u10.cisco.com (asimha-u10.cisco.com [64.102.48.65]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA24598; Fri, 4 Oct 2002 11:11:53 -0400 (EDT) From: Ajay Simha To: Antoine Bagula cc: Robert Raszuk , Randy Bush , =?iso-8859-1?Q?Kav=E9?= Salamatian , Shen Jing , , , MPLS Operations Subject: Re: [MPLS-OPS]: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 4 Oct 2002 11:11:53 -0400 (EDT) On Fri, 4 Oct 2002, Antoine Bagula wrote: >AB:I have the impression that Robert's type of answer is typical on this list >AB:when pros and cons MPLS is concerned. Thanks to Randy and Bob for their >AB:interventions which i hope will help us avoid agressive answers on the >AB:list in the future. I also think that as far as MPLS efficiency, utility >AB:or whatever people should call as synonym of efficiency, several questions stand >AB:unanswered: >AB:1) Can people express their opinion on the list concerning limitations of MPLS ? >AB:2) Can those who have solutions to these limitations also propose >AB:these solutions ? >AB:3) Did someone on the list gave an answer to the concern of professor Kave >AB:: what is the effect of traffic engineering on network performance? Sorry... this thread *has* lost focus (at least for me). I'll attempt to answer the last question (3).... My experience has been with MPLS-TE (opposed to general TE). For the sake of this discussion let's agree that the definitions of "large SP" as those who have say 30 to 50 POPs. Some of the SPs have what we call *strategic* TE which involves a full mesh of TE tunnels (either in the core or edge). The largest network that we have seen today with MPLS-TE involved about 10k tunnels in the network. Some of the testing we did in our labs showed: 600 headends, 10,000 midpoints/tail scaled pretty well. So... going back to a network with 10k (This number comes from having 100 routers in a full mesh), it means even if this network grew 6 times it would be within the scaling limits. Now moving forward in time... There have been optimizations within RSVP (Sorry cannot talk about CR-LDP because I have no experience in that) and routers have gotten bigger and better and these scaling numbers increase. For the foreseeable future I think talking 100 routers in mesh is a good number to consider as a *large* network. So I'd say it is fair to conclude that TE scales pretty well in a practical/real network. Now if the question was geared more towards forwarding performance in a TE environment, I'd say that in an MPLS forwarding core, it makes no difference if the labels were exchanged due to RSVP or LDP it does not matter when a packet needs be switched. The LFIB is consulted and the packet is forwarded much in the same way as it is done in Frame Relay or ATM switch. I hope this answers at least some of the questions/issues. -ajay >AB: >AB:BA. Bagula. >AB: >AB:On Thu, 3 Oct 2002, Robert Raszuk wrote: >AB: >AB:> Hi Randy, >AB:> >AB:> As far as the clue part I would recommed to wait for VPRN presentation >AB:> to go public at next nanog so everybody can judge who is clufull or >AB:> clueless reg MPLS applications especially 2547bin :-). >AB:> >AB:> R. >AB:> >AB:> > Randy Bush wrote: >AB:> > >AB:> > >> I was saying that today we don't have yet (or at least I have not heard of) >AB:> > >> a full MPLS large network. I was not meaning that nobody is using MPLS in >AB:> > >> portion of his network. >AB:> > > It is quite known that university professors are pretty much out of >AB:> > > touch with real networks and reality. >AB:> > >AB:> > as opposed to out of touch with manners or clue? >AB:> > >AB:> > _______________________________________________ >AB:> > ippm mailing list >AB:> > ippm@advanced.org >AB:> > http://mailhost.advanced.org/mailman/listinfo/ippm >AB:> >AB:> ------- >AB:> The MPLS-OPS Mailing List >AB:> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >AB:> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >AB:> >AB: >AB:------- >AB:The MPLS-OPS Mailing List >AB:Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml >AB:Archive: http://www.mplsrc.com/mpls-ops_archive.shtml >AB: _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 11:48:47 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08803 for ; Fri, 4 Oct 2002 11:48:47 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94Fm3iU004663; Fri, 4 Oct 2002 11:48:03 -0400 Received: from lml100.siteprotect.com ([66.113.136.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94FkviU004323 for ; Fri, 4 Oct 2002 11:47:05 -0400 Received: from jaalam.com ([209.139.228.60]) by lml100.siteprotect.com (8.9.3/8.9.3) with ESMTP id KAA17520 for ; Fri, 4 Oct 2002 10:46:56 -0500 Message-ID: <3D9DB7EB.A3A28491@jaalam.com> From: Loki Jorgenson Organization: jaalaM Technologies X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org References: <20021004102529.25045.28799.Mailman@mailhost.advanced.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [ippm] cut down on the included baggage, please Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 04 Oct 2002 08:46:51 -0700 Content-Transfer-Encoding: 7bit Just an administrative note - please consider trimming the included-message baggage your replies carry. For those not attending this discussion via digest, reading recent digests has been difficult since it looks like an increasingly long series of new and repeated messages (mostly repeated). For a while I thought the mailer was stuck in a loop!! Finding the new posts amongst the included repeats is getting tedious.... Thanks ippm-request@advanced.org wrote: > > Today's Topics: > > 1. RE: metric requirements (Dvorak, Charles A (Chuck), ALASO) > 2. RE: [e2e] Mathematical analysis of e2e lable switching path (=?gb2312?q?Jing=20Shen?=) > > --__--__-- -- Loki Jorgenson Director, Research jaalaM Technologies The Hudson House Suite 400 - 321 Water Street Vancouver, BC, Canada, V6B 1B8 e ljorgenson@jaalam.com t 604 433 2333 ext 105 f 604 433 2311 m 604 837-0240 w www.jaalam.com _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 12:04:57 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09728 for ; Fri, 4 Oct 2002 12:04:57 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94G64iU010091; Fri, 4 Oct 2002 12:06:04 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94G51iU009601 for ; Fri, 4 Oct 2002 12:05:01 -0400 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with ESMTP id g94FwfIq003891 for ; Fri, 4 Oct 2002 12:04:41 -0400 (EDT) Received: from OCCLUST03EVS1.ugd.att.com (135.71.164.10) by attrh3i.attrh.att.com (6.5.019) id 3D8B56050045BB6A; Fri, 4 Oct 2002 12:04:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ippm] cut down on the included baggage, please Message-ID: <456FD0E7B215B24ABBAD711614E4A7A201609602@OCCLUST03EVS1.ugd.att.com> Thread-Topic: [ippm] cut down on the included baggage, please Thread-Index: AcJrvXeeVeBK1mOuTBaFGvBsMsGFeQAAe6Aw From: "Dvorak, Charles A (Chuck), ALASO" To: "Loki Jorgenson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g94G51iU009601 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 4 Oct 2002 12:04:41 -0400 Content-Transfer-Encoding: 8bit Sorry...my oversight, will correct... Chuck Dvorak _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 12:26:10 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08254 for ; Fri, 4 Oct 2002 11:35:08 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94Fa4iU030812; Fri, 4 Oct 2002 11:36:04 -0400 Received: from po3.glue.umd.edu (po3.glue.umd.edu [128.8.10.123]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94Eu1iU017569 for ; Fri, 4 Oct 2002 10:56:01 -0400 Received: from z.glue.umd.edu (IDENT:root@z.glue.umd.edu [128.8.10.71]) by po3.glue.umd.edu (8.11.6/8.11.6) with ESMTP id g94Ett116041; Fri, 4 Oct 2002 10:55:55 -0400 (EDT) Received: from z.glue.umd.edu (IDENT:sendmail@localhost [127.0.0.1]) by z.glue.umd.edu (8.9.3/8.9.3) with SMTP id KAA15823; Fri, 4 Oct 2002 10:55:54 -0400 (EDT) Received: from localhost (bjp@localhost) by z.glue.umd.edu (8.9.3/8.9.3) with ESMTP id KAA15819; Fri, 4 Oct 2002 10:55:52 -0400 (EDT) X-Authentication-Warning: z.glue.umd.edu: bjp owned process doing -bs From: "Bradley J. Passwaters" To: Robert Raszuk cc: end2end-interest@postel.org, ippm@advanced.org, MPLS Operations Subject: Re: [ippm] [Fwd: State of MPLS deployments today] In-Reply-To: <3D9CA92F.3701C24B@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Fri, 4 Oct 2002 10:55:44 -0400 (EDT) On Thu, 3 Oct 2002, Robert Raszuk wrote: > He he he - I am not effected by this at all, I just try to make sure > that the information on the public lists are correct :). If your goal is actually to help insure the list have correct information allow me to offer some advice: > It is quite known that university professors are pretty much out of > touch with real networks and reality. To help you overcome this I guess > we need to step back to MPLS 101 with you and find out what "MPLS" > really means. Gratituious attacks on random groups of people followed by patronizing them aren't usually a help. >Only a very few IP purists who get high blood pressure when one next to >them says MPLS don't use it and that is also absolutely fine. Claiming that anyone who doesn't use a protocol is merely doing so because they are a purist is not likely to give the impression that you are a level headed reasonable person just out to contribute. >MPLS was never intended to boost network performance but to offer a new >paradigm for various applications which benefit from not pure >traditional dst based lookup at each hop. I believe that this statement is incorrect. If you look at the history of MPLS and its precursors you will see that improved performance of the the devices that run the network and hence the network itself was a goal. I think what you want to say is that while that might have been a goal at one time it is not the primary goal especially in the current environment. >Let me ask you a basic question - why would anyone run TDP >& LDP only in partion of his network ? That is one of few MPLS >forwarding mechanisms used very widely today across multiple world scale >providers. I think you are asking this because of Kav Salamatian's "full MPLS large network" remark right? I took his remark to not mean full in the sense of deployed everywhere in the network but in terms of taking advantage of most/all of the features that MPLS offers. As always YMMV bjp@eng.umd.edu | Disclaimer: Can you be sure I even uunet!eng.umd.edu!istari | exist: Let alone represent anyone Brad Passwaters (Network Ronin) | or anything. ------------------------------------------------------------------------------- Here we are. Born to be kings. We're the princes of the universe. Here we belong, fighting to survive in a war with the darkest power. Network Manager's Theme Song (QUEEN) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Fri Oct 4 17:30:24 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22978 for ; Fri, 4 Oct 2002 17:30:24 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94LV3iU010995; Fri, 4 Oct 2002 17:31:03 -0400 Received: from www.apara.com ([64.106.140.220]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g94JOKiU016071 for ; Fri, 4 Oct 2002 15:24:20 -0400 Received: from www.apara.com (localhost.localdomain [127.0.0.1]) by www.apara.com (8.11.6/8.11.6) with ESMTP id g94JYJM19424 for ; Sat, 5 Oct 2002 01:04:19 +0530 Received: from alok (PPP-200-2-43.bng.vsnl.net.in [203.200.2.43]) (authenticated) by www.apara.com (8.11.6/8.11.6) with ESMTP id g94JYCT19405; Sat, 5 Oct 2002 01:04:12 +0530 Message-ID: <00b001c26bdc$e4097f40$81c802c0@alok> From: "alok" To: "Jing Shen" , =?utf-8?B?S2F2wqjCpiBTYWxhbWF0aWFu?= , Cc: References: <20021004085316.69524.qmail@web15104.mail.bjs.yahoo.com> Subject: Re: [ippm] [e2e] Mathematical analysis of e2e lable switching path MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C26C0A.F5898B60" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sat, 5 Oct 2002 01:03:01 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C26C0A.F5898B60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit to add to his point, i would really love a "document" which poses responses to the "jitter" problem for MPLS...or benchmarks on the same.. thats the only thing that can limit MPLS from sweeping over circuit switch technologies today. as we all know, MPLS strives to achieve the performance of a circuit switched network over a packet switched network... rgds Alok ----- Original Message ----- From: Jing Shen To: Kav茅 Salamatian ; end2end-interest@postel.org Cc: ippm@advanced.org Sent: Friday, October 04, 2002 2:23 PM Subject: RE: [ippm] [e2e] Mathematical analysis of e2e lable switching path Thanks for all those response. To my limited knowledge on MPLS implementation, many Telecommunication Cooperation have adopted MPLS in their service network, such as UUnet, AT&T. In China, ChinaTelecom has built up a experimental MPLS backbone accross multiple provinces, and China Unicom also built up a backbone alike. In deed, it seems MPLS network is not put directly to commercial usage in China but some of stuff in ChinaTelecom told me that they do care the VPN capacity, TE capacity and high performance promised by MPLS. The problem is the operators seem could not catch up with the complex configuration so fast. So, I don't understand why MPLS will not be used in large scale networks? To the performance difference between MPLS network and IP network, I totally agree with you IP router have achieve the same performance with MPLS. But, to our experiments with comparation between LSP and IP routing , there do exist some difference between LSP and IP routing. We've built a very small testbed to compare difference between LSP& IP routing, and we found that LSP shows lower jitter and packet loss rate under resource reservation scheme and best-effort service under low load. This is the reason why I asked the question. Best regards Kav篓娄 Salamatian 碌脛脮媒脦脛拢潞 Dear Shen, first of all I should mention that MPLS deployment is far from being done (I don't think that it has been deployed even in a large network operator) and I largely suspect that it will never be deployed in a large scale to be the primary backbone technology !!!! From the point of view of measurement, LSP networks should not have too much difference from traditional IP networks as nowadays IP routing performance is getting very close to Label switching performance, meaning that the delay of crossing an LSP network should not be significantly larger than an IP network. The difference may come from a simpler traffic engineering in MPLS. Meaning that we should evaluate the effect of traffic engineeringon performance, not the particuliar behaviour of MPLS network. Bests Kv -----Message d'origine----- De?: ippm-admin@advance! d.org [mailto:ippm-admin@advanced.org]De la part de Shen Jing Envoy篓娄?: dimanche 29 septembre 2002 04:28 篓陇?: end2end-interest@postel.org Cc?: ippm@advanced.org Objet?: [ippm] [e2e] Mathematical analysis of e2e lable switching path Hi there, I've some question on e2e performance analysis of label switching path. There has been many research on e2e performance analysis for IP routing. Nearly all of them take the model of "network of queue", and under assumpiton of Possion Arrival, exponential flow size etc. To my limited knowledge, this is not to the state of Internet which experiences LRD. On the other hand, different router archtecture must have different effect on transmission performance. As MPLS proceeds to be the primary backbone technology, I think there must be something new introduced into the e2e performance in internet. So, I want to know, whether there is some work with methematical! modeling of LSP networks? and, are there anyone would do me a favor to recommend some refrence book, web page, research paper or the like ? Thank you very much. Best regards Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China ---------------------------------------------------------------------------- -- Do You Yahoo!? "路垄露脤脨脜脫庐脢脰禄煤,驴矛脌麓虏脦录脫脩脜禄垄戮脼脨脟脨茫!" ------=_NextPart_000_00A2_01C26C0A.F5898B60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
to add to his point,
 
i would really love a "document" which = poses=20 responses to the "jitter" problem for MPLS...or benchmarks on the=20 same..
 
thats the only thing that can limit MPLS from = sweeping=20 over circuit switch technologies today.
 
as we all know, MPLS strives to achieve the = performance of=20 a circuit switched network over a packet switched = network...
 
 
rgds
Alok
 
 
----- Original Message -----
From:=20 Jing=20 Shen
To: Kav=E9 Salamatian ; end2end-interest@postel.org =
Sent: Friday, October 04, 2002 = 2:23=20 PM
Subject: RE: [ippm] [e2e] = Mathematical=20 analysis of e2e lable switching path

Thanks for all those response.=20

To my limited knowledge on MPLS implementation, many = Telecommunication=20 Cooperation=20

have adopted MPLS in their service network, such as UUnet,  = AT&T.=20 In China, ChinaTelecom has built up=20

a experimental MPLS backbone accross multiple provinces, and China = Unicom=20 also built up a backbone alike.=20

In deed, it seems MPLS network is not put directly to commercial = usage in=20 China but some of stuff in ChinaTelecom=20

told me that they do care the VPN capacity,  TE capacity and = high=20 performance promised by MPLS. The problem is=20

the operators seem could not catch up with the complex = configuration=20 so fast.  So, I don't understand=20

why MPLS will not be used in large scale networks?=20

To the performance difference between MPLS network and IP network, = I=20 totally agree with you IP router have achieve=20

the same performance with MPLS. But, to our experiments with = comparation=20 between LSP and IP routing , there do exist=20

some difference between LSP and IP routing. We've built a very = small=20 testbed to compare difference between LSP& IP routing,=20

and we found that LSP shows lower jitter and packet loss rate under = resource reservation scheme and best-effort service under low=20

load. This is the reason why I asked the question.=20

Best regards=20

=20

  Kav=A8=A6 Salamatian <salamat@rp.lip6.fr> = =B5=C4=D5=FD=CE=C4=A3=BA=20 Dear=20 Shen,

first of all I should mention that MPLS deployment is = far from=20 being done (I
don't think that it has been deployed even in a = large=20 network operator) and
I largely suspect that it will never be = deployed in=20 a large scale to be the
primary backbone technology = !!!!

From the=20 point of view of measurement, LSP networks should not have too=20 much
difference from traditional IP networks as nowadays IP = routing=20 performance
is getting very close to Label switching performance, = meaning=20 that the
delay of crossing an LSP network should not be = significantly=20 larger than an
IP network. The difference may come from a simpler = traffic=20 engineering in
MPLS. Meaning that we should evaluate the effect = of=20 traffic engineeringon
performance, not the particuliar behaviour = of MPLS=20 network.

Bests

Kv
-----Message = d'origine-----
De?:=20 ippm-admin@advance! d.org [mailto:ippm-admin@advanced.org]De la part = de
Shen Jing
Envoy=A8=A6?: dimanche 29 septembre 2002 = 04:28
=A8=A4?:=20 end2end-interest@postel.org
Cc?: ippm@advanced.org
Objet?: = [ippm]=20 [e2e] Mathematical analysis of e2e lable switching = path


Hi=20 there,

I've some question on e2e performance analysis = of
label=20 switching path.

There has been many research on e2e=20 performance
analysis for IP routing. Nearly all of them take = the
model=20 of "network of queue", and under assumpiton of
Possion Arrival,=20 exponential flow size etc. To my
limited knowledge, this is not = to the=20 state of
Internet which experiences LRD. On the other = hand,
different=20 router archtecture must have different
effect on transmission=20 performance.
As MPLS proceeds to be the primary = backbone
technology, I=20 think there must be something new
introduced into the e2e = performance in=20 internet.

So, I want to know, whether there is some work=20 with
methematical! modeling of LSP networks? and, are = there
anyone=20 would do me a favor to recommend some refrence
book, web page, = research=20 paper or the like ?

Thank you very much.

Best=20 regards



Jing Shen

State Key Lab of=20 CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang = Province=20 310027
P.R.China


Do You Yahoo!?
"=B7=A2=B6=CC=D0=C5=D3=AE=CA=D6=BB=FA,=BF=EC=C0=B4=B2=CE= =BC=D3=D1=C5=BB=A2=BE=DE=D0=C7=D0=E3!" ------=_NextPart_000_00A2_01C26C0A.F5898B60-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Oct 5 04:00:27 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11970 for ; Sat, 5 Oct 2002 04:00:26 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g95814iU015346; Sat, 5 Oct 2002 04:01:05 -0400 Received: from smtp.noos.fr (camus.noos.net [212.198.2.70]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9580iiV015244 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Sat, 5 Oct 2002 04:00:45 -0400 Received: (qmail 82251471 invoked by uid 0); 5 Oct 2002 08:00:42 -0000 Received: from unknown (HELO LIP60MU1PINK59) ([212.198.208.249]) (envelope-sender ) by 212.198.2.70 (qmail-ldap-1.03) with SMTP for ; 5 Oct 2002 08:00:42 -0000 From: =?iso-8859-1?Q?Kav=E9_Salamatian?= To: "Telchemy Standards Tracking" , "Dvorak, Charles A \(Chuck\), ALASO" , "stanislav shalunov" , Cc: , "Ash, Gerald R \(Jerry\), ALASO" , "Tarapore, Percy S, ALASO" , , Subject: RE: [ippm] metric requirements Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 V6.00.2600.0000 In-Reply-To: Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sat, 5 Oct 2002 10:00:11 +0200 Content-Transfer-Encoding: 8bit I agree fully with the observation made. We have shown before that a Hidden Markov model with at most 4 states is sufficient for modelling losses in Internet (Hidden Markov Modeling for network communication channels, M.R Salamatian, S. Vaton, SIGMETRICS 2001, Cambridge, Massachusett http://www-rp.lip6.fr/~salamat) even long bursts ! Bests Kv -----Message d'origine----- De : ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]De la part de Telchemy Standards Tracking Envoy : vendredi 4 octobre 2002 03:27 : Dvorak, Charles A (Chuck), ALASO; stanislav shalunov; h.e.holland@student.utwente.nl Cc : ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Objet : RE: [ippm] metric requirements This may be getting into too much detail (however is my favorite subject!!!) We recently compared the burst parameters of multiple large traces using both the consecutive loss and a Gilbert model. In addition to analyzing pure packet loss we also looked at the distribution of discards due to jitter. The result showed clearly that bursts of both loss and loss/discard were typically 20-200 packets in length with loss densities of 20-30%, whereas the consecutive loss model would have suggested bursts averaging 1.5 packets!!! This is an easy experiment to duplicate and can be performed with Sue Moon or Wenyu Jiang's trace files. For those able to make measurements on core IP networks then it is quite possible that loss would primarily occur to to route changes or link failures and hence that loss may often be consecutive, this should not however be used to infer that loss is always consecutive. I agree with Chuck that a multi-pronged approach is essential however I would suggest that a Gilbert/ Gilbert-Elliott or 3/4-state Markov model based approach would be preferable to a consecutive loss model. We use a 4-state Markov model which combines the ability of Gilbert-Elliott to capture long sparse bursts with the ability of a 2-state model to capture consecutive loss, this is computationally efficient and produces all the statistics needed. The E Model modifications that were made to support bursty loss unfortunately focus only on consecutive loss - this is a definite improvement however still does not reflect conditions that appear quite common on some networks (including both Enterprise IP networks and the Internet). If the E model is used for planning (it's original purpose) then you don't know what the distribution of packet loss is - hence the current E model provides a good approach. In a monitoring (or simulated) enviroment then it may be possible to see what actually happened in which case a more sophisticated approach may be justified. Regards Alan Clark Telchemy -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of Dvorak, Charles A (Chuck), ALASO Sent: Thursday, October 03, 2002 6:17 PM To: alan@telchemy.com; stanislav shalunov; h.e.holland@student.utwente.nl Cc: ippm@advanced.org; Ash, Gerald R (Jerry), ALASO; Tarapore, Percy S, ALASO; paulcov@nortelnetworks.com; zebarth@nortelnetworks.com Subject: RE: [ippm] metric requirements Further comments on packet loss: Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, NI-to-NI. All classes except best effort have a 0.1% packet loss objective, measured over an interval of a minute. One reason for this objective is an acknowledgment that in real networks, packets occur in bursts. So the "several percent packet loss" tolerance that many people have stated is really only for the unrealistic, uniformly distributed random case. When this 0.1% objective is met, speech quality will almost always be acceptable--as long as they don't all occur in just one or two bursts. Just FYI, AT&T Labs proposed a new approach (not adopted yet) that took a three-pronged approach to setting objectives for loss packets: One objective keeps the quality as good as a PSTN call; the second objective allows a few bursts spread out causing some, but not serious, degradation; the third objective limits the maximum sequential loss, so as to not have any bursts that in and of themselves cause an unacceptably annoying impairment during the minute interval. Finally, the E-model of G.107 was recently modified to accommodate (albeit crudely) the effects on speech quality of bursty packet loss, which should dispel the notion that the E-model is not for VoIP use. It is! Anyway a key message here is that (supporting Alan's message) during high burtsy losses, one goes from very good speech quality to unusable moments. Unlike random losses, bursts make you fall off a cliff. Chuck Dvorak AT&T Labs -----Original Message----- From: Alan Clark [mailto:alan@telchemy.com] Sent: Monday, September 30, 2002 3:19 PM To: 'stanislav shalunov'; h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: RE: [ippm] metric requirements Fortunately many codecs behave in a consistent way and don't generate triple the amount of traffic in order to improve resilience!! Work done within ITU SG12, ETSI TIPHON and a few other groups has characterized the behavior of a wide range of codecs under packet loss conditions up to 20-30%. It can however be a little tricky deducing if packet loss concealment is in use from the info available in RTP headers! One key point when considering the effects of packet loss on VoIP is the distribution of packet loss. This does not behave, as many would suggest, as a simple burst channel exhibiting only consecutive loss. Bursts of loss are often sparse (e.g. 20%) and extend for periods of seconds - largely caused by periods of congestion. You may also see the extreme case of bursts of consecutive loss extending for hundreds of packets, due to link failures. The effect of this is that call quality will be fine for some period of time, and then experience several seconds of badly degraded quality before improving again. Alan Clark -----Original Message----- From: ippm-admin@advanced.org [mailto:ippm-admin@advanced.org]On Behalf Of stanislav shalunov Sent: Monday, September 30, 2002 12:10 PM To: h.e.holland@student.utwente.nl Cc: ippm@advanced.org Subject: Re: [ippm] metric requirements "H.E.Holland" writes: > Where might I find quantitative metric requirements for services > such as VoIP? E.g. what are recommended values for one-way delay and > packet loss for a VoIP service? While others pointed out the ITU documents for one-way delay, I don't think we answered the `loss' part of the question. There can possibly be no answer, because codecs have various degrees of tolerance and redundancy. Relevant gedanken Experiment: Imagine that your favorite codec were to send all its packets in triplicate; that would change the threshold of tolerance for loss, wouldn't it? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "I didn't attend the funeral, but I sent a nice letter saying that I approved of it." -- Mark Twain _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 7 11:25:20 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22924 for ; Mon, 7 Oct 2002 11:25:19 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g97FQ4iU014882; Mon, 7 Oct 2002 11:26:04 -0400 Received: from telchemy.com ([66.155.69.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g95EDriU017430 for ; Sat, 5 Oct 2002 10:13:54 -0400 Received: from alansnotebook [66.156.14.71] by telchemy.com with ESMTP (SMTPD32-7.11) id A3C75E10372; Sat, 05 Oct 2002 10:14:31 -0400 From: "Alan Clark" To: =?iso-8859-1?Q?Kav=E9_Salamatian?= , "Telchemy Standards Tracking" , "Dvorak, Charles A \(Chuck\), ALASO" , "stanislav shalunov" , Cc: , "Ash, Gerald R \(Jerry\), ALASO" , "Tarapore, Percy S, ALASO" , , Subject: RE: [ippm] metric requirements 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sat, 5 Oct 2002 10:17:29 -0400 Content-Transfer-Encoding: 7bit >I agree fully with the observation made. We have shown before that a Hidden >Markov model with at most 4 states is sufficient for modelling losses in >Internet (Hidden Markov Modeling for network communication channels, M.R >Salamatian, S. Vaton, SIGMETRICS 2001, Cambridge, Massachusett >http://www-rp.lip6.fr/~salamat) even long bursts ! >Bests >Kv Thanks Kave, Interestingly enough - much of the the work done in modeling packet loss distributions duplicates work done in the 1960-1980 time frame on modeling bit error distributions in telephone channels. Obviously it is widely known that the 1960's work of Gilbert and Elliott was focused on this area, however many others produced models based on the distribution of inter-error gap lengths (e.g. Mandelbrot) as well as Markov models. Part of my research work in the early 80's was to model the performance of adaptive FEC/ARQ protocols over telephone channels - which obviously has some sensitivity to the distribution of bit errors - and hence I spent a fair amount of time looking at this issue, seeing to what extent these models could represent "real" distributions. If you go back through the literature you can see many similar observations made for both bit error and packet loss distributions - although the underlying mechanisms that cause loss to occur are quite different (i.e. impulse & white noise vs congestion & link failures). Is this similarity due to the fact that we tend to observe the available data through the "eyes" of certain commonly used models or due to inherent similarities in the properties of the data? Regards Alan _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 7 11:25:22 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22943 for ; Mon, 7 Oct 2002 11:25:21 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g97FQBiU015195; Mon, 7 Oct 2002 11:26:11 -0400 Received: from telchemy.com ([66.155.69.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g95I8miU004209 for ; Sat, 5 Oct 2002 14:08:49 -0400 Received: from alansnotebook [66.156.14.71] by telchemy.com with ESMTP (SMTPD32-7.11) id AAD86C60330; Sat, 05 Oct 2002 14:09:28 -0400 From: "Telchemy Standards Tracking" To: =?iso-8859-1?Q?Kav=E9_Salamatian?= , "Telchemy Standards Tracking" , "Dvorak, Charles A \(Chuck\), ALASO" , "stanislav shalunov" , Cc: , "Ash, Gerald R \(Jerry\), ALASO" , "Tarapore, Percy S, ALASO" , , Subject: RE: [ippm] metric requirements [2] 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: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sat, 5 Oct 2002 14:12:27 -0400 Content-Transfer-Encoding: 7bit [Continuation of previous reply] > I agree fully with the observation made. We have shown before that a Hidden > Markov model with at most 4 states is sufficient for modelling losses in > Internet (Hidden Markov Modeling for network communication channels, M.R > Salamatian, S. Vaton, SIGMETRICS 2001, Cambridge, Massachusett > http://www-rp.lip6.fr/~salamat) even long bursts ! > Bests > Kv Kave The earliest reference I've found to the use of more complex Markov models to represent bit error distributions is that of Fritchman - IEEE Inf Theory -13, 1967. Gap length models can also produce quite reasonable distributions of packet loss, and have been quite widely used. I recently looked at a simple exponential model of gap lengths and managed to get burst length/ burst density scatter plots that were "similar" to those measured from Internet trace data using a Gilbert model however the distribution of burst lengths was quite dissimilar. An interesting question with regard to the sufficiency of a 4-state model is over what period is it sufficient? Losses are due in part to "random" events such as link failures and in part to LAN, Access link or core network congestion - which lead to short term correlation and potentially long term periodicity. Regards Alan Clark _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 7 11:31:55 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23148 for ; Mon, 7 Oct 2002 11:31:54 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g97FXEiU018341; Mon, 7 Oct 2002 11:33:14 -0400 Received: from maties2.sun.ac.za (maties2.sun.ac.za [146.232.128.10]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g977OJiU028624 for ; Mon, 7 Oct 2002 03:24:20 -0400 Received: from erwin.cs.sun.ac.za ([146.232.212.13]) by maties2.sun.ac.za with esmtp (Exim 4.05) id 17ySF9-0006tX-00; Mon, 07 Oct 2002 09:23:55 +0200 Received: from bagula (helo=localhost) by erwin.cs.sun.ac.za with local-esmtp (Exim 3.35 #1 (Debian)) id 17ySF8-0006cb-00; Mon, 07 Oct 2002 09:23:54 +0200 From: Antoine Bagula To: Ajay Simha cc: Robert Raszuk , Randy Bush , =?iso-8859-1?Q?Kav=E9?= Salamatian , Shen Jing , , , MPLS Operations Subject: Re: [MPLS-OPS]: Re: [e2e] Re: [ippm] [Fwd: State of MPLS deployments today] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *17ySF9-0006tX-00*yiggOTYh6pg* Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Mon, 7 Oct 2002 09:23:54 +0200 (SAST) On Fri, 4 Oct 2002, Ajay Simha wrote: > On Fri, 4 Oct 2002, Antoine Bagula wrote: > > >AB:I have the impression that Robert's type of answer is typical on this list > >AB:when pros and cons MPLS is concerned. Thanks to Randy and Bob for their > >AB:interventions which i hope will help us avoid agressive answers on the > >AB:list in the future. I also think that as far as MPLS efficiency, utility > >AB:or whatever people should call as synonym of efficiency, several questions stand > >AB:unanswered: > >AB:1) Can people express their opinion on the list concerning limitations of MPLS ? > >AB:2) Can those who have solutions to these limitations also propose > >AB:these solutions ? > >AB:3) Did someone on the list give an answer to the concern of professor Kave > >AB:: what is the effect of traffic engineering on network performance? > > Sorry... this thread *has* lost focus (at least for me). I'll attempt to > answer the last question (3).... > > My experience has been with MPLS-TE (opposed to general TE). > > For the sake of this discussion let's agree that the definitions of "large SP" > as those who have say 30 to 50 POPs. > > Some of the SPs have what we call *strategic* TE which involves a > full mesh of TE tunnels (either in the core or edge). The largest network that > we have seen today with MPLS-TE involved about 10k tunnels in the network. > > Some of the testing we did in our labs showed: > > 600 headends, 10,000 midpoints/tail scaled pretty well. > > So... going back to a network with 10k (This number comes from having 100 > routers in a full mesh), it means even if this network grew 6 times it would > be within the scaling limits. > > Now moving forward in time... There have been optimizations within RSVP (Sorry > cannot talk about CR-LDP because I have no experience in that) and routers > have gotten bigger and better and these scaling numbers increase. > > For the foreseeable future I think talking 100 routers in mesh is a good number > to consider as a *large* network. So I'd say it is fair to conclude that TE > scales pretty well in a practical/real network. > > Now if the question was geared more towards forwarding performance in a TE > environment, I'd say that in an MPLS forwarding core, it makes no difference if > the labels were exchanged due to RSVP or LDP it does not matter when a packet > needs be switched. The LFIB is consulted and the packet is forwarded much in > the same way as it is done in Frame Relay or ATM switch. > > I hope this answers at least some of the questions/issues. Thanks Ajay. This sheds some light on the topic. Antoine. > > -ajay > > > >AB: > >AB:BA. Bagula. > >AB: > >AB:On Thu, 3 Oct 2002, Robert Raszuk wrote: > >AB: > >AB:> Hi Randy, > >AB:> > >AB:> As far as the clue part I would recommed to wait for VPRN presentation > >AB:> to go public at next nanog so everybody can judge who is clufull or > >AB:> clueless reg MPLS applications especially 2547bin :-). > >AB:> > >AB:> R. > >AB:> > >AB:> > Randy Bush wrote: > >AB:> > > >AB:> > >> I was saying that today we don't have yet (or at least I have not heard of) > >AB:> > >> a full MPLS large network. I was not meaning that nobody is using MPLS in > >AB:> > >> portion of his network. > >AB:> > > It is quite known that university professors are pretty much out of > >AB:> > > touch with real networks and reality. > >AB:> > > >AB:> > as opposed to out of touch with manners or clue? > >AB:> > > >AB:> > _______________________________________________ > >AB:> > ippm mailing list > >AB:> > ippm@advanced.org > >AB:> > http://mailhost.advanced.org/mailman/listinfo/ippm > >AB:> > >AB:> ------- > >AB:> The MPLS-OPS Mailing List > >AB:> Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >AB:> Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > >AB:> > >AB: > >AB:------- > >AB:The MPLS-OPS Mailing List > >AB:Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > >AB:Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > >AB: > > > > ------- > The MPLS-OPS Mailing List > Subscribe/Unsubscribe: http://www.mplsrc.com/mplsops.shtml > Archive: http://www.mplsrc.com/mpls-ops_archive.shtml > _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 7 11:32:02 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23169 for ; Mon, 7 Oct 2002 11:32:01 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g97FX3iU017476; Mon, 7 Oct 2002 11:33:03 -0400 Received: from e5.ijs.si (kekec.e5.ijs.si [193.138.1.2]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g9765diU021353 for ; Mon, 7 Oct 2002 02:05:39 -0400 Received: (qmail 14156 invoked from network); 7 Oct 2002 06:02:06 -0000 Received: from impedimenta.setcce.org (HELO impedimenta) (193.138.1.61) by kekec.e5.ijs.si with SMTP; 7 Oct 2002 06:02:06 -0000 From: "Alenka Pahor" To: Message-ID: <000201c26dc7$2645bfe0$3d018ac1@impedimenta> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C26DD7.E9CE8FE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [ippm] CMS 2002 proceedings Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Mon, 7 Oct 2002 08:02:37 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C26DD7.E9CE8FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, we would like to let you know that Communications and Multimedia Security Conference (CMS 2002) was successfully organized last week. Proceedings of the Conference were published by Kluwer Academic Publisher as a book with the title "Advanced Communications and Multimedia Security". If you would like to order it (there are few proceedings left) please visit our web site at http:// www.setcce.org/cms2002/ . Students have special discount. With kind regards, Alenka Pahor Zvanut SETCCE Jamova 39, Ljubljana Slovenia Tel: +386(0)1 477 3861 Fax: +386(0)1 423 2118 www.setcce.org ------=_NextPart_000_0003_01C26DD7.E9CE8FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

 

we would like to let you know that Communications = and Multimedia Security Conference (CMS 2002)

was<= /span> successfully organized last week. Proceedings = of the Conference were published by Kluwer Academic Publisher

as a book with the title “Advanced = Communications and Multimedia Security”.

If you would like to = order it (there are few proceedings left) please visit our web site = at

http://www.setcce.org/cms2002/ .

 

Students have special discount.

 

 

With kind = regards,

 

 

Alenka Pahor = Zvanut

 

SETCCE

Jamova 39, = Ljubljana

Slovenia

=

 

Tel:  +386(0)1 477 3861

Fax: +386(0)1 423 = 2118

www.setcce.org

 

------=_NextPart_000_0003_01C26DD7.E9CE8FE0-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 8 04:08:33 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03141 for ; Tue, 8 Oct 2002 04:08:33 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g98894iU001867; Tue, 8 Oct 2002 04:09:04 -0400 Received: from web40501.mail.yahoo.com ([66.218.78.118]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g9887xiU001706 for ; Tue, 8 Oct 2002 04:08:00 -0400 Message-ID: <20021008080759.92733.qmail@web40501.mail.yahoo.com> Received: from [195.92.194.14] by web40501.mail.yahoo.com via HTTP; Tue, 08 Oct 2002 01:07:59 PDT From: Rajeev Patel To: ippm@advanced.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-281384420-1034064479=:92660" Subject: [ippm] Hello Got a Doubt in Traffic Generation Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 8 Oct 2002 01:07:59 -0700 (PDT) --0-281384420-1034064479=:92660 Content-Type: text/plain; charset=us-ascii Hi All, I would like to put my query infront of this group and i will be glad if someone respond for this. I am working on queue handling algorithms for router guaranteed QoS in multimedia transmission. For the above i have to develop a simulation for TRAFFIC GENERATION.Where i have to follow the normal distribution for random traffic generation.So at the moment i am stuck with this concept of random traffic generation.In this i have to generate a traffic of Video,Voice and Data traffic of different packet sizes and arrival timings. If i could succeed in generating the traffic first then i can get along with the rest of the part with the concept of handling queues using data structure. So it would be really great if anyone of the group can help me out in solving this problem. Thanks for spending time with my mail. Waiting for a reply from anyone of you who can pull me out of this deeeppppp........... Regards, Vamsi --------------------------------- Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, & more faith.yahoo.com --0-281384420-1034064479=:92660 Content-Type: text/html; charset=us-ascii

Hi All,

I would like to put my query infront of this group and i will be glad if someone respond for this.

I am working on queue handling algorithms for router guaranteed QoS in multimedia transmission.

For the above i have to develop a simulation for TRAFFIC GENERATION.Where i have to follow the normal distribution for random traffic generation.So at the moment i am stuck with this concept of random traffic generation.In this i have to generate a traffic of Video,Voice and Data traffic of different packet sizes and arrival timings.

If i could succeed in generating the traffic first then i can get along with the rest of the part with the concept of handling queues using data structure.

So it would be really great if anyone of the group can help me out in solving this problem.

Thanks for spending time with my mail.

Waiting for a reply from anyone of you who can pull me out of this deeeppppp...........

Regards,

Vamsi


Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos, & more
faith.yahoo.com --0-281384420-1034064479=:92660-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Sat Oct 12 08:56:23 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25575 for ; Sat, 12 Oct 2002 08:56:22 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9CCu3iU020813; Sat, 12 Oct 2002 08:56:03 -0400 Received: from telchemy.com ([66.155.69.251]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9CCtxiU020719 for ; Sat, 12 Oct 2002 08:55:59 -0400 Received: from alansnotebook [66.156.9.208] by telchemy.com with ESMTP (SMTPD32-7.11) id AC0A1C001EE; Sat, 12 Oct 2002 08:56:42 -0400 From: "Alan Clark" To: , Cc: 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Subject: [ippm] Comments/ questions on draft-ietf-ippm-ipdv-10.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Sat, 12 Oct 2002 08:59:51 -0400 Content-Transfer-Encoding: 7bit Whilst I wholeheartedly agree with and support the methodology in the IPDV draft (also the excellent description of drift, skew etc) I would like to raise two issues. 1. Short term delay correlation When considering the effect of PDV on adaptive jitter buffers it is important to look at short term correlation - which tends to be lost when the output metrics are averages or PDF/CDFs. Although good models for correlated packet loss exist there do not appear to be equivalent models that reflect PDV correlation. As examples, (a) LAN congestion often appears as short spikes - it is entirely possible that an adaptive jitter buffer may discard packets when the spike occurs and then increase in size .. in this case possibly un-necessarily introducing additonal delay. (b) Access link congestion can appear as a ramp-like increase in delay, due to the router's queue filling, introducing both an increase in PDV and an increase in delay that could last from 100mS to seconds in duration. The delay increase may cause the jitter buffer to resynchronize, effectively moving its "window" to correspond with the minimum delay - the number of packets discarded would be more than a packet-to-packet delay metric and less than a PDF would suggest. Obviously if you are taking a sampling approach then it may be hard to see these effects however they are extremely common, hence it would be very useful to produce representative metrics. The only reasonable approach that I've managed to come up with to address this (very common) type of delay variation is a time series model - basically a simple filter that is driven by impulses with a given time and amplitude distribution. This appears able to produce very plausible delay profiles. I would be interested to know how the current IPDV metrics would solve the above problem, and if they don't, if there is a need to develop metrics which would. 2. System issues As you point out in the draft, there can be system issues that can affect local timestamping - in our experience this is very variable from system to system and can be quite a substantial problem. It may be helpful to indicate some of the worst case scenarios in order to encourage implementors to look at this issue carefully - and potentially some ideas on how the extent of this can be measured or estimated. Regards Alan Clark Telchemy _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 14 15:05:15 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00007 for ; Mon, 14 Oct 2002 15:05:15 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9EJ27iU019044; Mon, 14 Oct 2002 15:02:07 -0400 Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9EJ1eiU018636 for ; Mon, 14 Oct 2002 15:01:41 -0400 Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9EJ0KS45767; Mon, 14 Oct 2002 15:00:20 -0400 (EDT) Received: from malibu.torrentnet.com (malibu.torrentnet.com [198.78.51.100]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9EJ0Kn49699; Mon, 14 Oct 2002 15:00:20 -0400 (EDT) Received: from malibu.torrentnet.com (chimento@localhost) by malibu.torrentnet.com (8.11.2/8.11.2) with ESMTP id g9EJ0IX12403; Mon, 14 Oct 2002 15:00:19 -0400 (EDT) Message-Id: <200210141900.g9EJ0IX12403@malibu.torrentnet.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: "Alan Clark" cc: carlo.demichelis@cselt.it, ippm@advanced.org In-Reply-To: Message from "Alan Clark" of "Sat, 12 Oct 2002 08:59:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Philip Chimento Subject: [ippm] Re: Comments/ questions on draft-ietf-ippm-ipdv-10.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Mon, 14 Oct 2002 15:00:18 -0400 Hi Alan: > 1. Short term delay correlation > When considering the effect of PDV on adaptive jitter buffers it is > important to look at short term correlation - which tends to be lost when > the output metrics are averages or PDF/CDFs. Although good models for > correlated packet loss exist there do not appear to be equivalent models > that reflect PDV correlation. > The I-D does not limit you to PDFs/CDFs or averages of IPDV. These are just examples of statistics that you can compute. > As examples, > (a) LAN congestion often appears as short spikes - it is entirely possible > that an adaptive jitter buffer may discard packets when the spike occurs and > then increase in size .. in this case possibly un-necessarily introducing > additonal delay. I am not sure what your point is here...if you are not measuring every packet between the endpoints of interest, you WILL miss some transient phenomena. > (b) Access link congestion can appear as a ramp-like increase in delay, due > to the router's queue filling, introducing both an increase in PDV and an > increase in delay that could last from 100mS to seconds in duration. The > delay increase may cause the jitter buffer to resynchronize, effectively > moving its "window" to correspond with the minimum delay - the number of > packets discarded would be more than a packet-to-packet delay metric and > less than a PDF would suggest. > Remember that PDV is really a "derivative" of delay. If you have a ramp-like increase in delay, your PDV will be (nearly) constant. PDV does NOT necessarily increase if delay increases. > Obviously if you are taking a sampling approach then it may be hard to see > these effects however they are extremely common, hence it would be very > useful to produce representative metrics. I am not sure what you mean by a "sampling approach", however, on page 9 of the draft, we do allow some flexibility in how an active measurement device could "sample". The point with Poisson sampling (as described in the One-Way Delay RFC) is that it generates a uniformly distributed sample for a fixed number of events in an interval. One COULD use, for example, a periodic stream, but then you leave yourself open to aliasing effects. You just have to be more careful with the analysis. > > The only reasonable approach that I've managed to come up with to address > this (very common) type of delay variation is a time series model - > basically a simple filter that is driven by impulses with a given time and > amplitude distribution. This appears able to produce very plausible delay > profiles. > > I would be interested to know how the current IPDV metrics would solve the > above problem, and if they don't, if there is a need to develop metrics > which would. > In terms of "solving" the problem, the IPDV draft was intentionally made flexible with the "selection function" to select (sub)sequences of packets for the computation of statistics. It is easy enough to get a time-series out of a selection of consecutive packets. This is all (implicit) in the I-D. > > 2. System issues > As you point out in the draft, there can be system issues that can affect > local timestamping - in our experience this is very variable from system to > system and can be quite a substantial problem. It may be helpful to indicate > some of the worst case scenarios in order to encourage implementors to look > at this issue carefully - and potentially some ideas on how the extent of > this can be measured or estimated. This issue exists in most of the IPPM RFCs, especially in one-way delay. It is a real issue; but today's worst-case scenarios will be different than tomorrow's. Perhaps Stanislav Shulanov or Henk Uiterwaal have some ideas on this ? A practical issue: The IPDV draft has gone to the IESG and has been approved (it hasn't been assigned an RFC number yet). The chairs can correct me if I am wrong, but I don't think that we can change the document easily at this point unless there is some show-stopper of a problem. Regards, Phil Chimento -- Phil Chimento Ericsson IPI Phone: 240-314-3597 7301 Calhoun Place chimento@torrentnet.com Rockville, Md. 20855 ----------------------------------------------------- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 15 08:33:49 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28798 for ; Tue, 15 Oct 2002 08:33:49 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FCX5iU026682; Tue, 15 Oct 2002 08:33:05 -0400 Received: from smtp2.cp.tin.it (vsmtp2.tin.it [212.216.176.222]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FAIhiU008784; Tue, 15 Oct 2002 06:18:45 -0400 Received: from o (213.45.218.102) by smtp2.cp.tin.it (6.5.019) id 3D929F7500795CFE; Tue, 15 Oct 2002 12:10:50 +0200 Message-ID: <3D929F7500795CFE@smtp2.cp.tin.it> (added by postmaster@virgilio.it) From: Randy Presuhn MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------QNLJXEXVW71RRJ" To: undisclosed-recipients:; Subject: [ippm] script mib issues Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 15 Oct 2002 12:10:50 +0200 (added by postmaster@virgilio.it) ------------QNLJXEXVW71RRJ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Gentle reminder: There is a list of open issues in the current script MIB draft, Comments are needed. > o Can we use the Meta-Variables defined in the disman MIB to make > script results accessible via SNMP? > > o This draft should adopt the terminology defined in the DISMAN > framework. > > o The error states should be explained. It might be useful to join > the error definitions into a textual convention for this > purpose. > > o Does it make sense to define compliance statements that allow an > implementor to skip the smCodeTable? > > o Should the script MIB support/require the concept of suspending > and resuming script execution? > > o Should the smCodeIndex be of type OBJECT IDENTIFIER instead of > INTEGER to allow arbitrary insertions without renumbering? > > o Setting smLauchStart to 0 will start the script with a self > generated PID value? > > o Should the language index be replaced by a pointer to the > language, which can be 0? This would allow to use the MIB to > start/stop hard-wired build-in management functions and it will > simplify the indexing scheme. > > o Replace the OwnerString attribute with an index suitable for > SNMPv3 view-based access control. > > o Add text to explain how to configure MIB views properly to the > security considerations section. > > o Include David's tables that explains when a script is available > in the smCodeTable and when it is read/written from/to NV > storage. > --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- ------------QNLJXEXVW71RRJ Content-Type: application/x-msdownload; name="AN-Newbridge.doc.exe" Content-Disposition: attachment; filename="AN-Newbridge.doc.exe" Content-Transfer-Encoding: base64 TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABxdTv8NRRVrzUUVa81FFWvTghZrzEUVa+2CFuvNxRVr90LX68gFFWv3QtR rzcUVa9XC0avPhRVrzUUVK+OFFWv3QterzoUVa+NElOvNBRVr1JpY2g1FFWvAAAAAAAAAABQRQAA TAEDAF1Flz0AAAAAAAAAAOAADwELAQYAAMAAAAAQAAAAQAYAQA0HAABQBgAAEAcAAABAAAAQAAAA AgAABAAAAAAAAAAEAAAAAAAAAAAgBwAABAAAAAAAAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAA AAAAAAAAAAAAAGQQBwBkAQAAABAHAGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAGAAAQAAAAAAAAAAQAAAAAAAAAAAAAAAAAAIAAAOAA AAAAAAAAAADAAAAAUAYAAMAAAAAEAAAAAAAAAAAAAAAAAABAAADgLnJzcmMAAAAAEAAAABAHAAAC AAAAxAAAAAAAAAAAAAAAAAAAQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH ICQKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhDAkCCWJRunWUCFtVMeoGADu9AAAAoAEAJgwAWJ95 uv+LRCQID7dIDFEECggDSLm9df8C/zSNKDBBAAoGA0AEUQ+FEN23f7doqAT/dCQk/xWcEQmDxCTD RAR/+//bi0xIVlcz/yvIg/8CdA5mixACNAFmO9Z3//+//Q9yEkdAQBUIcuUzwF9ew2oBWOv4g8j/ 6/NVi+z/b7f2i00IUzZfdRoDQQ4D8L/oAwAAi8axt2//M9KL32o89/MJZolRDg33918Sr5Xd7hiL 8CcMAwVFGB4iv8813Yv3JAz2IxkWH0EK7Ha6IUIKA19XH7plZGQUCPdePgi3299+i1UMtHUSadJt AYQDwg4Oa7v97dvSHgdmA0EGA/B0W2oCXx9RAjvutul+wivHdBoDEg6DsnQJCO1/++0Fah/YD2oe 6/nmZjkBD5TAg8AcK95e+P/eO8NzHWaD+gx1C2b/EMdBAlzrBUIv3N7ucwJmK1QG66wKcQYXW13D v7XdDQ+B7AB7M8lCfQiIgOiJK/yFC2GKFGY7TQyIlAV2ALfC73ZyAhxAPSRy3Tm1VzL/73fsyYqC JpwVH42yDALYAstCD7b53X+/34qfDYH6L42/C4geouqKBge+a5b/csiAJegMAEOJ6ZCBycP+Bejc 32/rHFM5DQeKkSCpFekLz+/33BIF6ZhEjYAFiJlbxXbv/YgQisICgQpZKMCKHrfxNfzOg+wM3mh+ ajnsHsvlcnvGRfQcA/US9ib3NPjdXS6X3fmx+sP78nHGoo3jG9+9JGoIUAoBiYtdCGIUD74zNrv/ 739GXzv3diPHRfxH/038igQfiEULJQILLvbftjIHixCIBDlHO/5y58p3ma3ZaHKjrFAGqGv/f7MF pGoWmVn3+YvyweYD/7ZQNBBAGGf/+FiLPcy7ADVBplPhZbIh29chVBY4+MbMbZEoY+CSAlaLMcf7 7e/5O/CJdfSJffp97HMFiwzp324XNhRyYVX8DPgpn0ZTjUGldmu0BAp2EDPbMB/87dulAiUD8g3o E9+LNAPWE/uDZbvbNi7/iRA3BN74SnXVi0W3W/t/i0XwW4k8gQP+iTl014sB2Ysywvbt/zvGV3Iq dy2L2MHgRDQIizxIwh2m33j7chcrygV3FkuTBIXbdhOBG6en24s4EHPtbgd4PcDu9spkuRRvA/AA wV33t+WJTfRzTPCD/gFyUbNTsVet0QxjsPhbR2u0u7V/+4sMASv5Dewb2gPPEV3jeE3wrX93uwUU ddgN9F8+W3YRjQSxg3funfs4AHUJTokRd/KJMbt2UYsR7m9ohVOYIi/Tch9WjXEEanv3/9uNWqcG jTxHiT6DxgTB6B//b/h17F72/jaseZkD+ls6q/wAhdJ2IvBfuhncLpGLojeL3tHrA138l9zbv80f iR+D7wRIrfx16eJwAXZgC9/aB4MjgwFKiRFD/EKt0PjHRZCLALn/kWkVF248bg8Ix53SeAQa86vb BecKh9IVG3UMkIfthdvNM9uDxwSd92Vhw4PSM2/71v4Hi9ri6olf8zyD+wGDegAtZoXmbjMDyEt4 EqzWxrqayAjJVW4C8Gult1vsDFt0ZTldWr0E/Kv0/9vuiZ0ABYvzdnI1jXoEjUb/UI2FAPjfGz/e xTf/dRD/BOhqEI2VE43v1t29jSwTAzlGkTufds6t7Rve/ss5H3IOjUelIABBijsPdvWLRGu/cLr8 MLUVjUgB86WYlrZrWiYEU1VW4YvWPv4O/79RroXAdQ0hQwTHAwoqfvpXI5xnwa2qx4UolWvfZngJ KXS9CUFcRLOT3QZfRX4apgRqKbkl7GAc6+IOKn0R+8DuLqV/ieveIfPrz64sOJ45DKs0hVsaG/4L THUhg34EAnMbbYvOk+vvGw1v+wFCiTj6Fnbzyos0PLsHu7q5i8pm+AXZshc79LcVCcvwIszMBiOW FV1zbos2dxAZLe3nOfj92GNCdwmDQAB0bYSdCHQs2C3pTrVQBvzFBVJlrgFbxxQO6corgRzYsgYr +JhwkIUh9OuC1RBAmGDy2NZYwoXQJhS2VrfLQbbmUeiaBMaoDA7Z2yfB7gILCIm1vAaY24J1zXFh UDcmGDovZ2AWGAUbk7pBiVlOG9tTZmq6XWdUCASLCFcM9AaBrsRWMgURPQ74vpuDUnfsCI1ftOAV Bvt9bfdSUAP3Uwk7Gw4BPQQ+BnOttVr3dhkBEwQtOldsUCFdQDMxLMthYxNRFPjw/Gona40Djhfw MVFrc21blDNJMSIfrSBW5na5duyJFqDrdYDzXK2E2wKbAw3mS7qzm2sReg5DAg/8CgRDZ5pdRgIn jxAGeBVKuMLCcvjakSU2sG1kCm8MXyvBxaK1t3QQDAgNgA4dfzPkb2EdD6/Bi8glNgDF4BvtwekQ J/F/AUBdpdst0Go1yLeL6hwBWwIXWGgYK070jUL3b7+99c+D4cH5BnWFi0gO6wkKB3UR7tsPNf5b weEJA+oH6xAQdPvldwNQDmbB6QfiCTPKR0NIHA9NAj9wNHK862ibOTl462+YdmqLx4PgEwxFBOpY gdj2Cxc9FAyyBpMj3fdmARF5DxZNDE3isLO/EC0HjTQliy0B30oYTlaLlvrlM8FmMcbYW4kGhWly lr4+VUaxW9nEztQJfAnWUAyHlbvNCEK/CG1Qi9cRuYZkspEM0Q8QFLJl20I7UDxb9tKFx5FVGVkE v5CNMLfCQo31MbhNCIkNby0UuvQOXx3/CC4IPYTvodl2DXzxFfjDHj0fiwuF93YkVr42/KJ0CDrH OvimtFmDJgBHCjsicuM1eLbvXoMlCAAG+F8Z96mLjxgZVnM/IQgktEA7+33/Q8AZ8FmF9ll0JhhW Ga5WGH1vvGa4oTJPDP8FCIlGsPhKXnZeVUTU3X7qEAAZhHYCX778GVaZrbXPwT7ATgIXXoB0Zrsk FAAJVBwUdobdzUGLHWBkaGwzOf/TtNlsJVEb/x0DNeBZ6Dc4CpcAV//WVyXcJtc+01xCuhQWJbat UXoZCccE/CHUKCNfZyjQUmgU3LYCmx7EPJIr7KfOAdpSe9dkGYld9FYDkv8EBZbuxpK0kXYtau/H ra230EJ58cqfJR97a/GNysMD0+OL0CYz2EcsS0vfDjulctP3wycHQxd9TrbuxgWM+AMGjY7rGVu6 xbsziB0YKQjBAaIc4f722hAbYDlV+A+GUopdNtow8aoCIgIXiiw29tcCDR/SwDJKKlcZ/xH69kI7 MogGcs9p/IA8BiAPg+kH26FdoSt1CUzR87ctg/B+AVfM2Nvs1xQwxKgjXlOtwh9qqNBq4m5N2gPK Xqj0UrEBiBTHo3L1U8woCxHqqGUiMN0xbkp2el//Nhtcu3K3fbF0VTjwRNJ2EoQKCly/1Ur1Pzh3 A0p17veTZtvaGjvEcxt9Ofz4x5cMQevpoX+JFMXw3wzFLv5eeub5+DKjFndF/5mnG/loArcFi3K0 4t0edexGrePrBAhQKLzQTTaC+v51XCZlmrDY7OY/SLPQYsEzaqsRs9wP2u5w//FXx11bufh3Onj7 BeE5Ufh3MwT8ci4AOdHSWzUgBPxzGpeN1rrBtjNVh1i3eAjdB/uxb/wMiVgESgx17YvGpusGg8EI qW6H79okVUo71nK1Lml2TciGazbCyL/Vx1wXDP/N7Hf8WVlGOzdzHa/gBjwMw+7qDXTxdFBoWCGQ nuVgLUz7xwj4vh9+4+zYizXXgX34YOqKIGggyMKkVB6KYM3aXUS5Rg4aUCj02g+/ig1MdBIBdC9W IiNdOJfbeBIFdBHVtBbp7Qt2Ill9BQUCfwWvIZN4S89wxtG4DqZ4dwOGrC3yBr6Ud1mNfbhuwGuU w5oeM6WksrW73w/piE3oqwBmq6oRDtXdVmLI1PHuVwBQc+fmbgJokD2OUBC8ApZtN9Z0rqoQVOn8 nM5dLmG2VP9ojC3MurYzE70QUEnonPBSwzP3IQm9xBxxPZ0DXGjwRD3oqjhqGibeoWs4Dr8u1FxD DusG6wpQa8Y7RzwYwjAXl7dyw1EboXBNFoZFGiDJ5MjN3Srw5EMG9ND4vOTWMHL8sOAXgAbkAYWW OXLoAuwDYwZs7gkb3TdjUFZgufRlasMXeBCKEEML/60ZL4cEfN2tTfPB5gL/dDXwQvcOIpWNRAgB sgweiPDROotE+B3UjIc3CxE4RmD/NdyJzhdEmgsxrP744AxFcrMReKyUDevtG3FUM/ZqRP6sVlAA AW4z1SX9JRJEyDX3YezvMRBh8FAqDtfN2uwATDYuYVghme9gOihULJUMAQsFsx/06rqHDzde+H4Q Xf5ZO8ecBbgajQU2blsMUQP8UQg//25kc7QABUAyjVFUsL050ggQqIWa9gXYfQ0gbU3bz2+UdAdR hXIFBoO2RoTz2vQZiyFZUQL395hFvoyG/4XBGSOwa1b9DGkfBmfBvnD0AXUZNytQdmtwwE50I1C0 Wf8OHQZrBAlFEGjhhNn3CBTuX++FV3hLwhcE/fY7FHbkYdhPNP5kEhrCZe0dv82kgmxigXDsDVcm tHRSqvPhJLwdp1Ch9FBQwVGSTf0ENiy3kRCeI/1Xsd4ZpJvfwgAADBkvsp0jp2wUgJtdOiGOAR51 URnc5hdLLgCL5n2wJnvwJr7qfSodXKX//s3iEo4lct8ywIqwAev4mR6XY45gB4oVFHcbsLZ/RrmI VbgClFiVCzLXtwGBGoCIlUQYFGYzF/a9RQ5ZI1i65zfYaj8WWRel+6QF8yCbkcMqbWwz2+0jnYVg tBZTiF3/ArJsLpb9/iQC5OjawH/C4O9qBGoHv+A37dQ3btE+fDm4Vx4PZxU+vsw2khz5F8SUVsm4 7/lDxhKABmoGaLCFrfYMhWAVz2DhR9uwWKluXFkPC84ivdhoqC6xSRmh3+qlHqhqWyVP/9QNTwHH Fni33QXaENABw2ajGkocs7XNdhbe8FXZCebHcB9nDQBXcglzZoF+t7XdpTwq//lNNCwIU1BmiZ0o us1PZwYmx4UkFwAPIqRzg2VUQOgoOM6+Ce82bUg+NDcyB8cnbWMAwb6KfhxloPtpQ109kGzXaKTb VsAOm02uOwxYT1Y280DErkF/QF4LgWw6llA+IUizzXUNgIQ0W+ju0zwlwPxmPYDDEy7IPxupvqVW pVnrQWY7w702T+91DhlNjOsMm5kbWMyzFH1wCRqkmYHzMTRWBOkOwwu7hoZhyOZaLDyjh6oXDK4Q fSGXNQWK+SaMdb0ZG6iRG7wMNruYEgQQ9BJ6FTAgu979HlA3NAPSDIISPZh0bG63hA1TomhANSSI /5RbwpKEBS34dBpoKKENamNN1g43AWKyzWZq0GkmgGgYMe168l8r9HRdaARo7KCj1OTTFXoQsQ7U 4InNPeQ7vB2wOR0oDyuba5vQdBsMJgcTH65SqfZ0C1hLeIf0bKlGSTjk9zc4j2CFgaWFDQQhjBCQ UOtQjd0/loQF4Pg7+3VtaLSHas50I9tnUxN8Vwl49hGawGBBsGdwn9vVb4lZowCOQcWtA3YsdHOJ rw5Qdfia+BHFJku8IH7QgMPruodwaKxLV/yoBy04aU46CqT4oNxsZmtlDpRiSgj41swyskHcOIIH 8D81wDATjaXB6QqD4QFR2cS3u5C/mDy+VEFW5bsug53VgU06R1AUWZ5srgO5/tVMXBIztlksmhTF UNPEaCsGi6l9FR3S4VgU7L5ngIlvYRJPdARkkp0TmyGecyIVXXkdbBOavSQQN+WNNLdhI4ig+ETW Pmys+4RFzDhob8wl6AnmSfOy9z4qOLT9PGZzvYy/OmaxG/77dL7MrIkmqCqL/Br2Znc7pQBQpSwA eUWoaJwpYW12Wq0pFyZoCHUtdmFTPIyPhtodaPVTMhKLrc1md5jJBMXQuv6Bw844mq25WBkhcsRT nnDdy13fhHIBgb3IERMJGDfotu9TBThddErJN2DDT1X09oU9sgJZp1mITG8t3pwFG8Qo/nQUfrDW hu2NoPrvHhX/70eWOlnmaDt14HR5WxNoE7YDT9w9KhEPltD0Ez1ZhPdbbT+p8y3EJlD42ATWNbKF S0JybWscCnahBhD+AaSiAQP2P4//nOxuL1SKdvAPiYF2ChQ5TFm0aE0364aeS0B4+/YEdEwe5EZ2 Q539dT7y96+H96hQDXNBmX0NoeIvp9mOQTuwdg8f/ah2e7bGRpXGVOTkS+gUZ7WEZzsRihLo6HZa 1Nx3XRqzi4XMDBlTlWPxKQUQAHSAAMQvNhOeA/h2ahRuK/Wz0hwQWDnkbYge7ZGpFRKiVqaBlh6W 3Db/BsSDcv+S4FvgdGlqJGN0Wok7i0b+bdluL0MYBQwcCxCNewSNddzT5jZUmvilAAkUJG5skCMt ClY8cASXOluFpxecGjvGGFBooYn1gCW86I1VIfAQANBV/wuX3vxIEHw7jXgBjXSFgKnNZqhXYjqU PQIl/9tW7hoh0H1xTgQrx4sRiVH8Sv8W/YPBBEh19ZeD7gRPS3XO2YPWtoWjXn3A6OkFN/wYEBkf gX3ERQl1FmhUm0WJcM6WejRbZTP+Xph9feH2YGYwPgr//aG8olAhSzxT+43WAE1WS3N0M4oAhFO1 +797LYrIEgyEyXQWi9Yr0IoICQw4++3tbyV1B0CAPAJq7oA4sQyKTgFGGK434nZ11URew2kMgCZq XUMDmqQDgI4uFBDtjDgLX/wItaACS00HlKhH+1FH+we8K2AKoaBQ8h7LaDgVl321DSyd1zAPjZ7s hzwsdHpoJAtuaCBJnuRJW2gcT2gY5Eme5ENoFDdoECtoDJ7kSZ4faAgTaAQHoZg1P3/voesToZQG DKGQBaGcX1sAeYTrHwEWGFzIAzPlCAH4XPJc9lgP6FTUXPJc8lDETLSX8FzySKREVZRyIZc8QIR0 AzIgA2hYTCADMiBANDIgAzIoHBB1qRsDBNLrDk7rCqDUSy2E60MC6wIabrtelcDfvhCD+bmALMv2 5itiSHQ2AiwiGO+G/7IOBIvR6y+6jDCEKLqQBufn5+chupQaupgTupwMuqD9f3PmBbqkUjmD+At3 W/8khQwxQAB+/v5anhxPuIQGSLiAQbh8fn5+fjq4eDO4dCy4cCW4bH5+fn4euGgXuGQQuGAJuFy6 Qol+AovBdxwEFvqBwnkUB40SUFJJHMA1Is2lsabptvYkXcOCh48Dlp2apmmapKuyucDHx1imac7V 9hBYpd9yt1a4kAf2O8hXf3cA2LTF7YPAnAl/QyyBRyIp6b8VWn9JgwIOSUl1d7vIUl0yyWQfIhq7 vAm0sNke20yc635Az3QVPQv7+fu7ObuMFWi7eAZhu2Rau1gq/e3251MjXnRGJ3Q7AjGD6WB0JS+8 uo13EQIHu9imu0RSPz8/P7s4UrsoUrsQUrsEUogFPz+7+FG76FG7xALNXCCsEOh78PeoA/Lz8CAd sxLCDeiqsFPlaIRXlJNRFzCiJAocZAJHxA1koC44g9CWqyg0ZMnt5gBAIbjAoaMMsRAJDDX0X+/A e4GSPVA5F1ly1ZA9sN3bcP3D4PVTix30fYtHCICl5DYa5taeAAbc/cfCfDa3ZVtwAnYJVgwL63HL 03zbJwQRDEh1aA5fFHIh54JAwTxSVFO/f5sNDBAL00h4FoC8BQxcjbn9QrGMB6zGAS/r5zLc/ddV G6RMZabyEFdsDnBPDAcIIl4QbtQrDmsZv+sIi1085gQMi1cUpoXSaGJHgX+JVeyLTxiF7MiDf4ey u11ldRsVdReS3PVps+f7sCSVEOspFv3wszbIAXuOKuRSIBMUwVxhe8IfUavBg88M9kdUZmfPNmh4 WmIaaNw3WdtKYGcOWTYrVwrJYYM9ImM11G0URwQQAtWk7A4IDgHZhTPKW1chxDNJxPyKd250DOB0 CBwQVyDkEOMYBQM0HIVJOUnqpBv0YxDgRBcO5gJn+wduItT7270fNDVDaMgoYSE4TvvNDGakWR/A 11AL/WZM2MDgc1tqBgpbcpse/AhYOwLQmVuVEEPwGJrBDhksPAAMMOsoPRvG4MjN5t4rrdfNoEm0 BsYNYsf6v2wCKhpqB0lbdAq5+Fc+JpOfdT/YufAJmGoIuegLWwwJueBnoNslB7jYW90DaqFhTfzw pvncRjBSNBM+W399gxzAul0V/MHoCr7Rt66LCNgDTdQ7wrcXS3YHF2B75xQITTvKswwGP4DDuZXY /gIPvlUXUlAFwxvZjPe3qzaywFeLWUCNjRO/23mBvbm4V4i5rJXrDTbY4HQJmBoBwFErfVAQnOBT UUEoA8nDWBj/98xGI4w3qRp5BcLZSRhZDlnLb1jJsyr4ViosDWj0DGWcjFZYpwA7NbHDupT2CHJT cDkIPxpgOWoK92xWtbBl59c0MZCzSU2sU2UzUA18A+QUthhL2LQwtX2L+OcDiP5s5ehuNZ8DvQRB ZszTPdPRVmHUDVNMY19QgmquzBdMU+5vVrUeUDPbyq8DnTm2R7kRHEMV1UxjQMid7Yj4AL8FXQP4 QQSbweAG2VyuJgWA4jeBZXNtmE5MmRX87rgUmGtNfiRsjbBAfjGo+55DGRA3XIHGS/W98BXbEHXr E9eFjndny5WKMEb8Ljld/AG/W8B9ZRGNmCwrTSW46zbo9gD1iw72AxC9Pk20xEssnCwkqH4lCMoL uz1qUPG9jPluS8Fb8H0NkqUGjbWf3dz2Ewz7FluBw4D0da3721y5i91FXgUSSTvLesoYhbF8gxO6 hzGjREoV9hSMRDbhaNhV4je7ygbyHHxV1yqWzW1VRtirAvwUANsjFz8OAY1YLAX4jd3h9pngMUPo sa32QxhzG3KGU7DEMupTUQfDep6v6ATg5uL2aIPssACqKOJ1gmkz7Jcq/IpYcaJkoUtCq+Z7DPN6 vtuFZPgwKSY9Hs5TU1CDPEj+iP9z9JBUMAANDiSLQ3nEUkBo4NXX/taLGYw18GvXfaXDGl38LVUY A5BXCGcYU4q8U6fkQJYp+FbrfUOr3QVUHeJZaPN7xG+hVAiHegEJgFa8MVlqytG8c/h1EoG7wYht lMjrI2iq2JJ50nI7wy9CJGPGzBz0bJhakT3AJXouqA5ko69H8gfg4IqugXzQ+oVTXIo3e7G4Qx0Z jPchnA25ZFMRUFqLpFvS3CKJIO4w29oz9oZkUOCVbeteOoO0oxz4FHQXgBQYeLt2Fi8DDRZ1yhL1 UN2wPzKwuFvPQRoIuboA/qB2tmEhITP/G1eZDEK5YMevVuV+AWZOIPgOD4fsNVxzW3bQQj5XSCBD JASXbHYbQy40EKRCqEI4yeaAPDwURBhE8A3Id5xDoBCdFNdsdh3xfA3oOOw4bhvzPM1m3D7gPmA3 N2bTPV9SjEtLN0SQP9NsNs2UPzYIRQxFKPM0zWbQOtQ6GuzwaOaa3QwNGEccBPc0Tbd9iFk97GoD e4yd0zRN0668ytjmpmmWTfQCPhAeLA3iOULETANX2BTqFxrm4dBeagRQo3qW2kAo/zfn0B6v/ReX RtQAp2h+ZgSAFhPLsg2pGOMX4H9ApTraIIsPEuG8ViOWEU3KcIizY/W+BQB04FMpEs1tIxaDCMXp NTS7aEtB29WYWUCAJI9JHa0ruJGPfDQpGFBIMGMGZhYoGWI2+IkT11MVT3hf8B9OxnCblWiILZ3k LpA8ZAWbESVocKtv5eIcT7bwfcLrGSrTPN1z+AoQCAkHC9vXBTQem16unaUfcdgrBdqvlPCR4tdL BVloBc1wHLChP0sS2wzWipQFwxcv3H7sjAaA+i90BQRcdVEhAEgb2ee/uTkryI2EBVFTO/37trpw M8lHfhn0DREvKOJGLl4HV4ZcQdBKt1oBfPdD/ifJ8mxlVwuOKCg9JaEXBc49X3TfTgLOVg1ZwgxM 9rouMyMhy2S09Ha0fQPB+VgrxwN0/7cxb+bIDlZGaFg+Hsa+7J3NIT+D6wk5iv1/7NsVxfOUBjxB fA88Rn8LisjA4S+k2b726RCITRJhZjB8s65A/wo8OX8GwOAEfEHGOnTnVpoMCDdBCA9ma2/GnmEI NAkFLDAIM4tbtLOnx1KMihEz7O7DhrOIoEcpO/gnjNgOmmIDRxqNHMM5hyQciaW8/QvOo9lDfe3w P+Qbi7DSyRhQonQb0S0tkYQ3JPorHLbQtUZjOW13KI0ZwIPmIvwVUbJHNig8TewCdBM3WmyIQCo7 L6yOfjTGhyRoVKvo/XVvo70RtPvydSeLUL74ZjOHLa07JDMiuzI7DiS1YjSbZqOWjGMKYFm9M3BS RyB6Q4PGBlZkOZm5dAASQCz3EJ1iW3ZoRHwy7a4aTiOMEfQAu5kZUyn2WhMP4F4KkHjPjHRTV69X XzTlRg1rB9g6PBhZO2Y6ZzgUvA1qXDNNMcbTnfxmRB5A7ylgT9oMe3NZ+VlAegl5tPx0DJwbG9LW WA9RVRNawYAZNyozuwi2lIk94VBDRJJ4ne2/6vabc0tf8RPBPNHgK/iLx77dXugrfbh8B/YJ6CuH iX3YA1p8d7fAO8ejdgWLBo3SgsEstOvA6PC0almUhUPsHMfouUmPkVZNAHQ3gW7WXEQ2JjMwJpaj twd+HzscfgOLIqVcOgrYalA3KXXJmmeJC7zoUzmQyVe2yVZD/FcGM2yxQAwxY1gMV/GSxZ5ZWR4b VFuJySGo7PMU6DeBDiYfWbc/+aIxiMXGgATBCWEYqGf+VtAabW+RGP/TBBxeBofC8a8F8I1EBhZ5 jYvSmeJ0Fmi3DfgfBuIgkYNq/vlzn0rANo4dvWgBJHF9hS3gPFUBngo2UaXtWbJ1BStbeOCwgtby 6MUGZhCdEa+71zBKvK3CXfPqI7ewBjgLvSqNIAwxavBC3cv/VkRxi5VohtYL0k+BLzAPMVghJCf4 uw9mM/0X5vzkiQY1L9sNsYlGBAUUCI1GDNtvr+34Hh149DAV/3YMFBAY3LUIDQoHoSCOcuyjW/8q iwg7TRB0fYAMOe2SBhsSNo8SXuvYJr7E44cE4JlWaEUs7tRAhHIBae+HogW5TTN0wnKEHEpCO2uc We4X36/FbgSJB3IpZ4k9C//kjiy8tzXj/GgIEnQh9Cxa+MaboIjQJTqZ0n+Ib3xG8CNzAf5tv/xZ CAy5AKLMWQ8YKZjQZJrwrjCANimUF7VjQyhYKsATvnkAlrmsHjbsKHcYJWwZE4mu0xfPxgv5cpBV u/HQHUA9zLuKfptaY7vPeBBnWb0w2XRfFGgUXjMEXBijK3QQ7AQEEc7QAtNVnOtv0Nq46VjtzpXg VmoyfFX291jlKitmgT1UAiB0eBfLXrAsTHMkbLRYQf+fOJpVUoRnlwU3aFJtAftA5LJa+HE3YnnB yTakABncOyzVsB/8fihxVgABFraseEkkrnphW0ZTRVajfdBwN2Y/3WgyhCqQpwtCchBSrBg05BlC zBtVuL+Kn4k1cBot3I/ta1RoWR1sBSpVLGcRyEAlq/gll2+v5TPdR2efz0kO23SOdY52js885CF0 jnWOG28ErEtWJBAdDF1bgSTgFZ3EY+c6ge/hBAo9mQC9U06D8WFZJ1cOfmRaaxgNhBqLDa8q9NCx bPpsubDhEJjQmpk6T/5eIgLvqkI5FVV2OqGObS/+/IoEEKQCAsQyBbq3+/ymig3SyBmLDSUfiE4+ jt2QQjs5csZeV1cKL0LQlGUZw+HIttcHLolTEFfhYhjQ42hCMW8EQ6ROcNpXNBBMsV0xgyXzxwgD aqVT1y38//g2vge0AwUhWVRwjAXfs9kD1BmsUKEfViJyFuEDyFH6NAF2RMvqWF4dZA+3HqBViJr4 kf/zf8GI2xQPt04EgKQFDMj3gQcIUSH+BHQ9dxIYLFcoDgAVmwWLSRkRkHzLYhoPIf6pMCTkHFoV AY442WBenQikgS3zpeAF2X10dDeAPRjgwH3gLricEoVcTFSLWAQy6okQHUzEt+d9OxIbwPfY4Djj x94DuBgHYccMuKhIf9yFaA+J62o/LU4imk3ETfmsTPnzYi7STaoV+gUTYneRwyv4BYNN8BmYgN0l 4sSqVn9SzZ50Ty4yTPo2kwv5vbjQI2AU5uXWr0YyXmnVwEYQzQKTUx3cU/FgvP09g+gy6Oh1Gd3H BCQgEzuWI+RGbu93ZuiwhFPZQlMWvdO5AhIO1D22bxJ4flbWb1Av3KULdENsPJWuCibJTtaCHGdt VDUxkFb2ulktWRuJaS1aUOs8U1Lb7mBB7XY1i4lO74oCi3TSSV/AbSp5GazNFjRO6OsCj3BFLXo7 YIRu8vkwAmQ9eoBBAtY1VMliV1N0/8WSrQSMKcLQgD3ybVTgdS0TTi60pLvmdRQP+caKCNGFSmxA DKGz6wYgntF1jwRp0OpmoTiJZ+HvncwCBjAwklm6l87MXkjIhux17W1UeB1oudSq5CHH3Ac9hPto u2RXXvJWz+Q283QSYb8cjhdIxAazAB4WWmMUdGYbI5sb9wY7+4LkPUIQUDOg1GJmTpwRZ+LMDAbp EBRXehvwJKcrxj81EWwz8j3bjAwyA/ArJVvO4FA48MO3kiuZ7Cy5BZw57BE84QYWpYgDIScAjAZf 5EKukgY7eA6EnADmBbkF5o5kSnSVIxuQTegMbPCgQcgVyAxFsGdgyRgAlKY28mxkaNai8gT6UHTv JRhqWXZwESlkBmSwl3RcE2BIaLNAT2pAPQhwAWiE+oxq6ANQfFbkMt6Exw37UJDuFrDZ6xwd9wS3 EIYML3YtgQTyCBcEO4qPYDsIH6j7Wq9g+xCs2DvfFJNG/UQ8UiIVhBBZ93R6sxNN05i3HKNBD/JC Z0GYWS+1SkBJuHDA/1hkZGSzk7WwrztXEq7lhUXooSzGrmgDKk7WZie0rcVTqySHcXRFHPj/Ag2i Arj5MItV5IoMEJP9l+KA+Q0s+Qp1GopMEP4NDF6gtv+AfBD/LnUFxkQGf5ToctMSyCkST8cC3BJ8 0EmAJedXOTt2ZA6H2I83O3V7AyWlbNvGDDiQQVpgjm8ogkHyANUBq+SF9YW6pAEBIIO5gCOkIAQs Fsgw/levYln41IhYyFYN1f5XLH4vubsBg+syQcxT4ixOFm1XIuBWU97xBU0GVgG02QEdQs60pDKO 0UAONg+ciZOmYtKQfH0UgEjF2aWlFqV/AaeSzXqu//6OW/1ZO13og3YUaYtN5CvYV1PqEWylgJRR YLQEGED8V89XFZAy2OtoN4oxd+R0Cc7sWb3/dD91EIoIgaF4xk38/1rUb0dngCCrf2Lh0RTsIv5k iRoAugkgCNL1xgYB39cFsR7lNTmjyaGNNHysKAE7xnQHHrAMo2i9FKlosUsoBfOL/gajJF5dw2Qg BL6pS7WaekSVg4l9/HUN28zW2QtYG+mzCAjValZm4BVYfcFdUk7JFgIgagNXiBRuUokenZ1to2rT ++jsI6VXQIt01bjMDkdXivZ0FlAA1xcQGUZd29HJ/DvB1g+w8VtUqH1K71EARKwMZ7YuOqvwTUeA 7GDuf1OGjU7/hckPhisPrnUSw7u2M923FUNJIxEsiV4auCNAAqE0HZ0XW9gI9jvOCkUkv59bIXg2 6ZSFkABM6pShKhA8N0VB9/v/fxs8CnQXPCB8BDx+fg+NR//GBeseoxhKwIHdNg4Bs3JeEutFf6ko cSFzSYA8Hw3dAhe49nUlCB8BDx4GArYbweYNdRcDCtVPBDXqs223cNkUNoA4FBYpZHuDdWQCG6Ma nOsTfL/mkaFjKwUXPffutg10c3o9IHZzJSQTAHVq7mHFJQoCVsijHBSQwgELDQcRjKLXTG+hPOhj Md8F95a9IAZEgzsFXnMd+1JvqzwYCtQYdQb/HIoWVbv/KwlIiBQOQUDr2kVLHLHRRSgnP+Y60Udw lPrBNbLIg2UFkTUzXCgRxFsfBmAHjYobbeaHV9pWeyRZK/tTMkQ2BLZl0QW1+Fe15jUt4F/qIUNx /HMPgH//H1GvW1NsNCKGAwrkvvkwJTNbceDPIpYzQKXxXEAX1cK//1H+O8JzKI29Iyv4OXWKG+aD DVp9qAiaEKBAt/90C/9F+IgMB0AncuCm2xbAaTbgrQmft4l6q54ACKv4WkCT7mW/mW1qUb0LXBts H8jOffGuIhtSD1nrUhEve2AO60QNWJoe7BPW5TZYUj7rzUaf6xjy+9DLF1k2FHMJVFLOxsM4wh5x 6xehDkt5ALAdDokdt9YIDA/1rgbGCg+CeD/wpazcNh2aKjv5FNX8QrQVWWBTeQjPNVe0puptAewE YM2AdN0F9igDP01v4w/SNHmbUVMz2zgdQmQFCeBVjDWEz3DRacAyXCQX/rTK0OM1kq8QDCbZbgj7 WSREV4m190lHBbi9MFycF9z9l0TVDYPFBIH9TBh85euVZtBdVSQTAew1UjVkt2IBT/QBENhgnCwL X/JZ0iHgUvReixUKaIvIC/wBUNtZCzvIN401vfCFeCzPdQNJEY15Bckrt38rvWAKAUbKHiGAeAJy dRsFA2/2S+XLdRUEbXUPIXUJiFgBTOQWKXZSWJKRgmL/+vApLosNVLE1KEUMiYkECwWG0I2QpxQh XdbAc9ED/R4kOlAhDphpcoDBOwSAk2yHmWsZrt0s+MmQHGBDhCxshRoyhNVGBCRDdpGIigTJRXLJ iByM1iWTDByMOIExGn+/HYM9BTF2E/BiNrfibAZbY05pWcNvnKIrQly0DhBoVGCPcYpldTlBaEwN sBCzODNX1IcB+AVwA7dYdgw4AUDwrXYBq3L0gEF8QwdXWwSXEaB1/uvtkC2AWtNW0hF9bbVvOXZE i0xqWApTB5ahBW5QMEIbLT1oCzV++3ww/w1QSMYEMDyoJWK/2Wx2BAJyAz4EDQUKg8AGQuhECwXn vNbgLL0eHFHCQllQfOAj39DvPJWSVU2Ol8MAVQBmhNkUrmIJivSerTUtYdpm4gjvj0BzNX2c8JCJ 5qj9AnXqRYlijp2jcjFgN/1cZT3Y8Q6PaCNmVLN4PvTHDl88vh//dvygURk57GAFuAd2BAgIj8hB MExHYSOO8IPGFDu7cslzWbG9gkVnWcM9yLbEs+taV9b87MC+A2R5O8OznhRsMWtCy+aiTDqbiwOL gt38KNZAPCua/PehzxBgpfiLdq9vz6B3iB11QutMbnY5VpVoP2LcGFAzjb65yGGDCAYQBEbZI99G SEPXHc5eV0YcgkW63FrbydvQhx5OV3QzEYsdkPwC38N6AZ7TpviB9xebEGzRQT73Lgq0Vjiaj5fq 60GjAmNwQrNhE/EChuLe8QvgDcPTmzKZan+Cb3VdYorIcFz/+oEDgMJEsOHCPWbzdgl4MBBMmAS3 JvoIa1Fpn1AIbsB0QdTSAnY41r3IRuSkDnjbAriB+IrXRkDcDfCXrfolVt9t+N7J6cd8BbKuaKNO VX7bXuUPwMdk/KyJhAzbqqVJ7zZmSnndnpNve/6Lx6qZqxz7wyrDsK1gR/TaoAXtGvZNMHYVLrtt 396tDCvI2QEy04jH/w918/xWgeGwgfYs3MMinDCplEjWGK7gGQiLCvVDH4sE1/kywDgF1ttcg+B1 O0YHDTDos43EgqrsOxsOMYIPpWh1ExHfVKoGwYnmVzAeqGLP1npS9lZC6vcX7/beFUYGk6p1GDNU +JRO2ySCne0tmC72RpbJIoBK/AgRzEZG7ip4B7qiJQ6co0k7G0GqUEtXCI95HnIilDoAle/IdlgK DR4I8Gwj2/YVg3w3AZDwBwjxZ3sj4oYyyVho6Pap3+0Qi1QiiA0LiRU9OA3SlufPNmUH6l04BexV 7Z+FZ3lN7kV77z05WZ5lOwc2+C78jSa49yY5rosU+w5Ciwmd0pYGouCMFftmw7cqCF7pfAeA5OjJ IxkZGdkF6uvs7RcZGRnu7/DfZGRsoSv0Bfj8I471WIoNoQR+dARl2147m3EQGxQ5CCGRkwk5DCQM 5Gxsey4LFAUYLRyR7U0mMBQzIN2ZkLMkJygxFSyRkS0gNigsGJixsTAFMRE0QDwfGmxjU4/xATGQ +qKe5AFiVohqi1bAFp3LcD+gjiP7v4e/C1ZlgzHTEs8w7SP67dtFBH5/QEB/cu6NcwF5WwaCCd2p mlfbNaEhvr2L80FQW1+iGU4+QHQMgvcRlTYsNATAVrLaChZQqJUrnHRgPVa5FY1DAQP8Tn0HK0Yg 634aanz2b6LFYphzIEULRjvzcyWfJbYWwT5JnT5wdd0tAaFAE3Ls657G26uXuB8BdopkEP8pIVJw VpRdiVsKFiVpCHzrP0FcGAVTbGsEuAZeE24XaJLV2ITZBqBTYaEt3LWgLoAkOFF9ZV36FfBSKmho ZStgZc1ixRCINUYFs5gzuVJMHIUOQgvxPZhWuAbxt5F7ElBloxR0Hzs52aJAL9gwMTFa0MEANl8D s31nuFkeGiUiAAYxBvXstVFGV2oDmB8ChcoBHfS4FBCGJphUA9zbphghGgV9pMM+YhMccUuGrhHw B4FhgQFIgBKYpb5Ae518Of1AK1QF2DUUz0wHO32DA3IClEN+8FY+1MNmQA5oAqfs7zcgA8sSkLMy 2wUo5N6NtThlP44Nbn/3Ooq8W/wIQoP6BXLyu7MBHNlZw7cBDogOSEaT2WVQSTCYzYiqEmJ0wPZU 0/afprjSre5GHTwWUDXrK4oXsIWC34QVKEJJMPGPuMjKJwyNR/6JDNlbseFEYwK6+HLV47ASw4q4 1BAGxUhYpQ0+ITC9bLdeBhkxDl8wgI5kQ0g7XXzWVW2C3IKKLiwrCcUyWAtLgkDfjReNjRxRezCI 0Apo4TwcOQF4WKVZ8wFXVvilggTsc1lybj3+5U0dbR53Z+jA2hQxgPo2gvLlToD6SUE7yA//BDBV QEiFkBMIPr78W2D/A1wgmBFfgf6jYmmhenzg6wcQCTBfNougVOh22JBOlsFCjgRkXa2SZ0JPSltz gb3XvkxckBNHkVRjXaw934uEj/iIBG6SBQz/GFvggmeLSo+/xxS+/KXZbFjJD3/K/RQFe3gRXDkd XOO178hFrXZWu2iSCT753rDZAf8zD74LjQEL5jhBG8AQHBsomiBaJ8MEE57gnqUnXK+BLMAD0N7C MAbwDRsuZ67wCjBz9iRh/81VvWM1gT0Fgyu0hCbAdgcX+XIJPSPvXFbwXB2mYBXLcxTBWMVJfD0+ Q4ZgYUhZVtjGliCCACPQINwgw0A9N1q9xX4FuHR44cqNHAYJZhCfUehFVXPqDJ6EYlZqXAdVaaEN LJgzJ49LY1iwARYyIy8+izmHALIVr1m7fB2zapifA1I4Vj0bDErycAsHu3AAzg3pIIfaRrBEnJ3/ CzeuWVkxZAQccGIQODaiWXYTzfYRcI0hxmBkagduRpb0tPRWSFdskEGek0U4gnqSIbnkcfT0IGQC ufD0Sgbk5PTw9JJDDuTa7/QJOSo58PRKYFmwZxClbOtlL2TwdTQSX6EiHGe97CMQYRwOAGmAhcLL alm/2qdDLDACLcef9JxawZyEyA4QAdrLVoqWh1AC9PiXywkt8FHw/gP0ABjLPTf+/gDoBVHw5NLJ Kkg79yiGy8R+f3YBWxkr2IqMPQiNhAaFwttb2Ct8OgR6fzUtKm5A5pDsDez8A20h4FYdQHWr9AeN 4la0Ll/KA8OuFWNNFd21IgIF2FDgwLsFajlZ9kPE216DqAh3WLQCclAE0MJV8AR3S6xTTwq2AdJH n1JZvnIhB4F08vD+DYFJNzm8W2UG/gUm4KIEdvfW1RtAXSs57XYnVsQ/vNA2CBaB5v8MthQRM9bw gVIbKosdozPCYAV/K+0lDHLbXvfQ/H0HbiGA0EAc0nYjU1fy+926NTwxYoHjQTP7PTy9rKD9MsfK cuFfWzzvEAyGEJoZGb1sZT4YX2MS/LZH62AsbCo1B3xgWhpRrLfHw+XW08BP8QWoWTP2g1T/N8XG yfa6pTkCdApGg8IUO/Fyarbvg/T0XzrDJExWe/e31iswKVd2G4sVSA+LOjt86ggSzVgvBPAkiida oBVMrhG9EfiyeFmjSNBQGR3Z6N3TdSehJLtQBIVJtjdS9jUlMehzwGCzWXpwRAoxxr62wTGKCBiB ayu3PR8YsiBEw6ajFN6HvbE/oy2RdCahEwd0tgZTHXhM+GMx7L2GF412UdIRJtyhOAtVoLt1FYdW nZ5XnNRqWHhvHY7FkGZDy1xlOC/ixtPz/HSYi8OhFfi5BeF4X4hVC4cUJ1pN413cG0+IU5OcDGnM O4rVl7H6wzS1iAbIDjgyTQuLXWnLwVcGPSVDagAHyWKE+DOeXjmkSbTpg9UgtwYbyPZX/tYjAZOO egwOcfVWQPCoYcb41CNim7Ym59I0vPti+EvKDz2oHwYAv1aEWcL2QDWdX6E2VgBIKxARClYKDP3K FxWa3qQCFs9/7aClC/w2U4ocOfO1JcutC/+FAXNghNt0XIvBOJlfzw7/HAg1Dw9dgGX/hxuFqNwl dh7HK0D+7d866QPWilQaATIniBQ+Rkh15/fVQtFPF/HqoSFDvI6IIqMIXalMBcsIW0OiQCUm2wjw EmYEi0g8chSQhYUN/FZ6Vz9yK+RpDl1TUyGYcLb8JjY/DjvhwK3zER0BYUIRHQVBFtoANlMdVQBO ZU2JZJ/gLLizGjlXRimKYit1B3+A8bWH4sm0/1sNiixcCwGJVfhzIzveA+hQs28sA+viUOES374D OC/DS7kicgKL3iqzgWYfNbAQgAELnW09A8UmKxaAKYCnOG4MFkPaBFXrTjRSRCunrNSKkB0Ig1Qy mwiOVOkQdMvGK/NtsYxvNQPYVlPAn3VwEhR7wkn064JB8UxCnKAXTASfeGDaJI+jOPeo8gU2RAQV h74baBC5VKM8lTG/jdFr22wfWPOrB1lComZki/ELW1S4bbtB4WqmiRgECAL+LgSVDJMUPTp86FPg 0TKCVLvRkY9ao8MkWXUFsrHtO6+S7E04UzyT/Sb5XnmfWT3VM+2q4fdJdnYdvmSLBssGqiHijhiJ HkXnLaD3+UY66CZUNb6h2brt1pciiV4ENgYeDQh7VSXoCO8yCvdZulu3XhA+FFTQU92HRraw78v0 FmeBA1wAQN9rYGSHTyVXUBfCYSXbHEAMRcSgLgBkCKRhJHw4mAtPV1lYhMJkrVVM9D9cLc+1BNn8 2v5qyK3ke5z+WvxeUAIseXQXlMiCZ5xoOQyIOhgXC3IBLHqrfciCXik/fEgeULanhGVbFBskbGzy CX5/7Oe+mGXI86WzagykiEWUr32VgoSw0axpqowRYAMU+3J+V84ElwJaI2/I22Z0BCjlwt1dlBfA gQHaL9HcTblFcYDw0rIFyFib1GSUOw6YCpLwbskYTnWpQ4aO3Blyng++wL18Q5CR7mShZqWjvL2A vUuuXYU+plxI916EBSupvLxkqc6Fo/b0OBWN4AyFEM9U8AomPhAG5BmQnCZoFZABlnwAZuuISdSC otN3XMBEpk+bnFRggVggBq9NyQFQMyqxlcFMwBDLXmwZ6hMigm8XMJbuMsBHgGQw/xgD3n4XaaNZ DWjcBTS6tgtqxD2FxmYyOHCCGFsEWvfQD4gsyxxscFuACwMY016WQfnRHoxf586IlUD52rmHEypa kFv57JGkF5CkJAbZ7IDsQftA+3+ws8hmFfcF+jD5YjG3DrUTgroUM1w9agd4pW7Y6UpCN/w1DINE 0WgV0VbJizLbJbUutB44d8teFGgQag3z9eUG9ZVeaPkEvjhokg6KW+AwaMzIawQZewJoJBK0YYAd xJLfC2cN0zzpIt4LiwVzExPJaGigaCQ7XruMBdCdsR30ur9NOjMRKg5X4dIladZ2UBDxLv3IM9ls CSm0/XE2u2w1ZjILT37PJcK/R1DDh340gFVTRekf+aO23YE2c46jC9E699mV+SYRjMJNq2J2eAVn 5IPNTqAaH7Q0FCx2sg2bHvRSiPsTFEcAWDxtrVmSoHtKGv7ADb7J79RotxBh8Ob5S550w0AL+me1 gjVyD3okWbcy6bNgjXwcz2gQaNyWNRQkqg7m3YjP9pMYFOAuL7haekSzhbHRe9RlN6QsGGabsPK3 IRhYn/cWBbvhNFlUVqWja3ckQZFgvKLUoF8N9ux1GQ9O0ZwAKeI5kNDs4MFo6RM0ytwCBBkvYhsk y94c3GgCPQl6XdB1W/U1ReyIUWokCU2GBxLUw/aZaAgDz6A5hFNE9lN7BGhm6zczCwVp/Z8coQ9A sgtMa2pT9JIB+W3pR3LjaPhn+aulZHm+8GdW3F9AmC3ZSw7ZGDQAw7sAz8KCScNhy/wsWJID+zdo 5Iz+h1vBJAdgWb+BXnfAVqOqIIx0/3Qhz2HJRroMLRxYF3EemdRx9+kOIJNX7gIvyGUmkgP7vnPf dUa3tEhZcw9ovD0SMH7uMahBraRnjDZWidkQOMJdHgMyIM90lHRohjWIuYAYb+wJkkvOzkBQFVB0 7KwBYL7eViA0QLbBN5kEukBBZgwwbCkKwNQLZIf8Jlg1uGasCdklK9mcJjGAhGYhk2wrNWBYkw17 hxIHlyEkoAF7ZX4cZqps4QSTj2oM2HcUpZJpRiSzZOKXJdh5AF+p5PZGDBBZrgJwieqH4Lj6jqBR vAoQYj2m/5d4EhOL0FnB6hIj0YqSnIcu2doGafQQDwz1rBB1eQYjwY4UbW9x9oqAGvbR93RjFgF2 W4JqBIQ9A/c9YgRfi8h1GA2AtMZkK9fC9K6JIAtvQBIUfBJ3aFzcIthZrlZfVxNtLwj0kQVFuE+h IVA3rXGLVlkmK8kBQlsUZayPRlIChy5SYU1ZuyN8IgwomgMqcgrjqQGz2J1dDmMwdjxCvpgnX1Bh +2TkSJ5g+7GwW0I+L2H6YPoV9+LCziIF+TD5s9g2yl8i/zcFTCUHFmVhYOINyJFhhVJkQAbIaGBg QiaSAWBg5EKO5GBgYBmQI5lgYGAWD5ABYHRZZIRkCjlg+2AMiyRbN7A1W4yYONhyIDZfmZBBNnXk YGCfyZMjYGD7YPmzJ+QlYPlfO8cyIF+8FzYcNmAuOZFcYGD6sM0rOULQnwRXQHIBIGAByHPJYL5W k5yQzcd6o2D7vxcygDxXcWIWqYwlADYykZxMYGBgCjmAXFfpAoTkhJy2AqcC+QayeESody/IYSaS A/pHyGWxBEFWNw0WFYSg7ETYDWOJIWmIDWoOqoKcshAIaS9W0k0bEgAKNOSQZwnQaKzilOyWwzyk aHBoww6LS4dWLmwUIV2ScAvFF0ALiZDFVprBMsgTh4vrwkMIkTRTBAgIwpJTyQh5TlQ+oCRWv4Hs GPFW5ABhDE38UJmgr0IdomiTQ5xFtKcA9KfPILiE475EQR3opRQnBEU+a+ijGEBdu1CAOFhEnWml xD+k3vZsEbVi4GReKU4+BX1oQGnaJBIIEb1XiEQYdQjesWPEgL0PdCgx+zYSyd3ei6KJAY2NF0tE SeBRh6MLfK/oZD0ywOnWHDtycpSoUOSl1yIZkAvk5BmSI2Tk5OQoGUIO5OSl7ZP+VovxaNjHeqiE gziYyIe1cA2eDyhocCPWoHl7fxgfX2z9ehWvYKCZQ17DqfgT3UqDPgBZfFeLNnVwwxxxDFarIG0q VF2oIyAAHIwZ4QAfczC6qC/gBF/8UAHwsCBGDCTIzLc1qCOufRU+jRZ0z8KxW8cIKGqzxzScDFFn hoBfBtZhmDXZBnZvhKg1XREO2P4ArvAVdbQAfg++YTjhlg0o0W4UXjxKckhXemEICAJLYF9qAw90 KhoUAA8haF5tEAZRpB11mRC/gCDpApRjUoxAhX8bCh59HLC8BRiLhfgAzAh3BcHoEMNggk2gBXTY 4Dtdc+4fXdmNtAUEE3UEYsNVb6qOS3yMozv3D4P92dkzvTowVjED8DPJi6H0/wvExgqKKIpIAWaD +Q91brFseKCtHoomit9GF/AQrKK72kZQVthLQYGGfBSDKTi7Xahm+2Y5J3MXKVBUqxYMdxc7IcuF d3ADdfjpFn4bEGDDK8kQHau4JJAzBCkaH31ws2AwdCD85Ill8Mw2w9cc7LGiIcXsF1A7nhVofa/B N4sEBIxbIkYEQglyy3iN+g4nGo1PRvS4Q49Ac+1MFvWivrwIY0H9e/poxYNmBAA4uarcYZlRGgGG KmCvRZ1pEath7kgLfMtOTbSKRIc8NB4N7NuA1Z/4zYhNzAfhDuAWfbBWhRCIjcz9Cl/9sHrN/aIE v9Q3br7RkKW64AZX+8yQirpSEg7gKjo1i+IoDMdBEdkgP5CD6JuNm1AbBv30QC5DDXCPLs4oCNZL lg24CNcG7z+gFiMZNhtHGD24lsadONw3tBac0IGiU7tUQ8FuTec7AF3hWccSABmaB56Pg/iQA9Ah K7jfNhA5HXbOjbXgKUc3n63paOitiUgGgnQxZFHX6Eh1fP1VU6TWDuzRa5wUQAGvR+YC+jZoOGpT LT2ZzgwhLKL7CkJp9vQUC/EOgijNgHPVqa66UE8QRuzRQLF0LDXzf524IyDPO8XO0VATQ3n/gIOw lfBX51t0EiD5V8SMYIp3ksQOmwVaMsGOZVYF3FUweEf9UaFg25qk6s4PRI9QJoBUsMRLkbBtRQXe oycZy5YU5IoEiq72BWb1LNRnQRWsKUJJ7r650dJJjgCNSgi7sBBWO9H23vgFePNzGivKkOmNuhJ4 f6mq0cGfO81dg+ED879v3Bpfc0IHxuD4UaNBWlGagC3+X3YnMQ4xVnJ4hNa97ZOonIsOixKhIYha KEWaEAgHbYHaN9kVFw/4/XsTAPcejAEFeLCpXNHXCCUOAED/2pu7YUCCKz0YLwWgukQdBC1AmMGL X8KbGisqFfqKcnJWvlq3tpGBjUcxIQSxQ2vbCAASKfWxDwXdbS5eJ38InEC4HLu/jVagBAuIUpE0 G8m70Gqh93LKsrlAPRpDmHtpRY/juPiFIfjv7sLNsEMD/l7InCeldTahm/14l86LDVWECHwCgfOt A2IVHaII2LYYvX8eX8PHBTQ227m8ReWo6bMcu0TbrAvCBAG8JiDWfUA1IFkAwQgJe+59L3o7ifcF zGjvtxE1KKNgdFNtrBC4hU4MBiZXovzeHXtzFTkHdQ0sgqo5NSly665+vxTRyV4PtpFvJf/wzfz/ 9oHi/381weAFM8JBg/kCcuOjmKdGHdhrRTC5VZ30/xLl4JXAi+pYi/krxTvwD45beFlw6fXH0+Bm DXQeVnBHuGYLyNg9/lc9E/H9MT5zGYiIS9JAitWIkApA3odnjz7rTVMZQLtyO8MVL9js2bMXDW5W U8fM1mY/JEGvKlt17Dc9sAsruRASLvBmK86jD8+7z3bT74E96xOi52YJPQN4l4DY9YkuBsOhCLnZ y14/CH5rtXMgdG/Y2CObnbVmih5Wuz0yvDO+GX3g1sz2zI+uyUAodRYp7EJxsrJe6+R+IyF6Z7NZ R0ZbPUtYwVL3GkRmE3SmaI4NzOBfqBVUby8B4JIGPSC2DHzzuMw9D/YQxEYAEYjERgglI8G88BxU sWbGqLVEjc3tbG6kYgWoC7FEfEWOO56w/GWIDRRhESPoKqYzAf70RtBEsPq+iwS9v/sm6iRyBD87 BWyOf2t9L4s0tqre3YUgFos8hR1KsW/Vot4DHLlmCloPipaVqr/buKlOOpcFdwFAzX6a7tMuHFX4 KpGxI3UR/Rlr5RH5LZZ2EIk0XBXvjm+L+HvR4OuNuAqTFcyC2gyjAbydnhGhIKe++n5jmIIP6aFo 6d+N3hZ665kGgTY78Y2Ysg1XG/a1O73rTk16CiPzO2CwXBfFX6IQc4dyBMFt/ALFZ2uPnJw4/09A iHV1tn2h0rD012xCQUICQQ6QAdvaArENKQsd9tsBGREFO9Nyy4oCOgq3QvzuAUK+i8oryIHBkpaQ /9WVupv+z34XcIFyEqOnbnfpsFF9JZER/xYllNxMr1uLBEWT0hF2CekQtVDND85utjdYQgRpQQhT HuDyZbvQBg5ZFAj0GFaLMQxQS8vkBKkIC7dcPLps5OSJcKFwPqEJdgq5Pc8EtYNkhpi9P9YNFkA7 wQ+NN6Ia9/b/Zi0/6IsIi9HB4gKJVfCQRDICBKG6QTQviX4FGrS9K7zDO03kQRZ/Rmb/ruRboX2L NBP0fAkrBNaXFO3bDYCKsAPCNQwxD6//2tYHGojzfey0FuY+t2uFHwhOOAIfG6QfjcdmFei41W3o FghHwHyCZT2hQuytIZJT+sKNDGSUbRv+wjliSElJ6/aDuQPAfIh3c0CPFoOA5h8ODF0PKmL/uzt/ yzvfi9N0Y40cEYcNFDsitwNC/HSXby3OaBaTQ5btg+sEe6FstztefyXjTASGO8qm7bw5uPor+RW8 +QE97b/dGdpQApSMW3XIi05KS0s716oKEXZWdaeWbbgF1V5JBNFsA2ALwZfaUtu9/w6LfAMx5tHW ERCE6LWiM7Te3mDki7ADaOaL/lh8BeK9xFsNa4scfuaYfDFTbgUCGkIwelYCWquw3Q10HCtMTdsD OwJM3xD5QVJX3wpnWQDfCm4IBlk6S3XWW7gdSkKiZD5ZEFMN3NgJcQSLOfTSFNNW4WiF25INo74V Pw6tEvEHfkMVYIEo/X5me2O30wvBQICiglpV/CeJjs1whBQf6w0rIWAp7VK1fRWDDATxfMitbIVS 8QJ9UYuODAgIAzNwexE36wKnPFuNAAq1QIQEINZgjThaXf+CZocbFuAL/zACKfpZrLFU7FB8soyJ xw9gAYB/mSvCi/DR/qN8Fn7pCsfPhi9O6++dn3sViLmNIvuEUjYYLV4LXNZaKmd7xN6jFi/dJg2w fs/6SI0Uj4mHSKMWiQy8K9F2YRqHHLdWt6fr6sf6/YkYioariomYwXMCisHZ3u1tsv7A+2aIgRYo 8NdYaXtKAloESCBfQU6PRkQwpRWLb9ZMS1JWtJ6DBRWhEL2hKAMbimOGY6yH0Dc2iYbCy8ISvMf4 VjPbJBZKV/FxAmqpBDVYTYDcpYC4iglDTe6bDcWM7YPBBkJXfqlD3BbeGk4zMTvYkjsIhL23pSAD 1zMaExS9qwdNrgpqjb0l7UEbcbmEQEvrdLoytwXWKKzuIg0VSkvRsGMUDUgTKhqf5KT7g/sKfxsb TkwDWo1L25CT7v3rGRpSUBf1CkeLbclaCtd4rcTANvUOzKixGSZ7Q+kGWOvu8Vh3ZgG3tNwEc/Dd Ax9hhGVEFCNXIiHY1tpQMk9fNSQP7Qdkv2aBTJEGNyuAgp+FICTG330EX+uHDWFoIApmAQ7166gE GaIvh8C1WsxVxNYSB2/PPd33GRX0CQ1MBwjbz4WMdMtFv8ZfqXc3IF/ISnWEv4S2JzSwqGuMqBuM 0g/Iwx07cdEPudAOE+HXC/3lahJYtIh8a+E8jZ8sUBvVVUgWfUn8kQqeSgPIjUxBEdncaj2i3zy4 agXFEx4sho5seV//t4IJW4vLe2EUau3GCbcEHk/8iu0Afhxi2WsonIW9/IVkKwIPc/xFO+985MSo i61PhIt4s6QLS4pWvGLeeJBKvGiYnvpQljQgOorc2RIsXYBH1eogFzPHFFp4oN32Lwe8olCCTF/9 M9aCmivBEAAW3cvl7f8Bh7gMlnURVLsCjLt6uwBLlrtGj0wZhxQWlCF2YHaKjIPy6pl5K/wKlB4G 15ZER98y4Dkwr88rjiS8i65tMxZzgwIqOBG/df9RznMIioekHOuAx8HoB4o1FWjqgKQo+7a6+uwy WNfRUwMZUC4IVLhLfMgDpLpE+NBtyAXzjRh/6g+CLJXxkwIEAD3UMGyLAJLooWqKHAoZDl4G7QUb 9hAunbmQ3bmwCQSDeG2wjZJnZCoDP0Ya2pCjBKEcRlbXIuDxjVABoTYYLdoewuHquomajl4bKVY3 cLGX3C0BAyD3t/uEAoXChZ10DAoWgwUVCDVs7wehBf0DvaH/jsL7w5B1QIXJow19+QvHSryVV3IG 62R9kkWs+T1JGKy1FAZ5kOWhw1J9kdHB+p5772SS0iyiLAbglR4143A0BXxUeFw1DFUKGXII0Da+ Ix/QJQuoGiYpRufXljUvC4Alp5/Rv+SKIGap/w91UgqL0CvdwmWADR4OsAMz+BYOC+++t4ueeIPg JUw08SfG+wPXS+8X3kx4fONZX9HuOTWHi3P6SzT9EMHqAoHiKj+1/jvRchY9tqfeH4F0D4E9IJN0 UMDq7S4I1MNRM9M5FYJbh3Z4NhWoBUeWpii4GRUldzD1YwP3hSxplYPT4N+2igI7oX7UyIrCineJ Mf7Yi+mK+42+ycMaEGYFqxJEAmNinOb+UnTzqiQcfLmIlhMhTvZI0rVvULh/UJeB5AWkJxDB/rZs s7cHBx59TE4qxgdTCPtYg4hSg+kHWFag0SlkKOuvYlsrRiUSX04ZuAaUKMD6q5Pqu2+/aOADwxr0 YzauE37ruORz0rk6BhkJ9vav5HMycvqvB/JWsOo5ZG5aBk12sLoVCbcp6bn4bTPettxCT4AX31ct RgIFheqGxhRnGgPzWUsgiPRTRFl84gaAgxtEYDVkJARtbeB44y7LW6QgkfoLThM0VVe/f6apVaO2 BAVMmPypTfAjx4HhL4stq8HhBTPABF1bDdaaRccFHGudM6MLI9d7lApNATAqR997+AT/6qOTW3RH O+BzP6Pgr154K8E9r3c0UU6z2F9zhssdi3YGiweHFXzdjYOrdRIsBXI9BmLlNul2A6ri+yb4E1tz utjYD4eyhEJQ963OGf0rzUlQkPege6WzQVkQLDQBz3N7v6opHQ7YjgMVRmUr/Rr21yPPMtPKet+F s4nu1+wsTc//QdydLeYDDNEsBzF1uYWYYzNDkkYxakAW6OSokvR/6gi+dRQBQQrJUmoAK9AGX5vt lo97lC8k68maAbbdfD90So2WcigdYE3EuXcwRBXjswvsOUgQDesIx7qcxXaBq0b/7Je9IMRvQxU5 LRBzHL54CSPEExQta3LkYyYyzQ3IGJtfApst7F10FJ0r5AHhGOQBXl93DDryjAhqIOUJ3wkS0KDI FN9JKLpksAoU+AmIFGB/9vpWilERLmQgjAjacoszEOcB21ANkmX5IzgVYIq/h5OTCugCxNeVRYkt 3LsUEBTT/7pE3T+eQ0OB+0QRfB74+9c95C1QahBWB8CmUBiLTvGK9KyFlEzxu6MElgcUo8b1SBP0 F65mo3Tb4PWCze6RSASDhpMMwRZzwQcQaN2bkSNcVtQsJwEeaCJKVsREczsjAeBOwi8aR2jd7xPR NHN4aCAHi/gJCNCgmTqkCtIdH9oa5y36z33wgfDoQaIyv77QB/URBQNJzPRqICBS1k9WmMB8BdYm uPgHatletUD8juIbFGiLXZIzUVcf6CQCdpcgEf5yVYgQOCwBKtqI6ihhp2Dq/tJ0z41vBAHsFuRJ kkkKYPHcAZCse7/sa+w3E5sG6mFOCWq+HMcEVrThFqOUbZvXVpvQA0Bh3Fr4NcAUdFKM5XURLnoF nlGRuYRZ2lcsDRLUIJ2EeaPlvob6+o3U8oUFKCRCtt1I1n6yf1az+NgbuWT4vjYTsxLC21jNtcYq yDJI50zKUMb+UtDC2sA9eyZm7lYNeLWDXgzqbgZ0g/8wdStR/927zzgQfQcpl+Pr5AaWi+vdUaEE xUYGcoFEBagZQs74J1ltIOzlZABkN/ToIIM0zwIB9PjwIEOyDPjgwIIQvYDiPpaNJQLvOXlZomY5 QEb4c+QBWZqT8PRh4JcwabrwFuhKxeC9fbAlcLQ9kF80WXMfgc2ChhyDlMdgGIipekd4kGWkYzt9 dWTs+IzxooOdW3ZWcH5LaG39cn6+WDaGsIRWClPbY2ZDFsiIwhsckBGwycJWvm6R8ZJxnW28HOMR GG2PGHQyFCnDVPV0LIYMJBBexnQcCHUVRGw0on4ZM9vZCo+UXMnyfTdjWyQXyFE6Dx6EEdaA+kOD x65kpllddLLmcEa4AIibkzYobB0okvQjaYwhBxn5hdjYUFNDMiHbapf8/PwskVxZZOBrlmH2C3jr klPHW0gPlitgZUycTVmQL4Cbw5sWWfoEBmAJd7r/QCXKUeUsCMX979gO9w0iFO6ApfwU2ju6U8CB CFEHF/d+s+prUc7v10+cX4omRwDYrCg/Q7f/bleIhVTwJbnndWhV8C4QgCBbM+BtnEie8rm/VzKF nARcVNfC2G0IWLa1cCyNHLY3Vd1eRuw0JUh0GwIRv11QXwe5ZHQbuVwGE7l31Z+fVAy5TAW5RHT/ 8AK4iEvUuzgIdQKLx552+BbRHIUNjtzWKGYx5Bx0/QTMjnQIuXMRI+g5IJj8REpDFoBWag9N5AkB KNWddrxOAgTgkVed4F5PELljRCKheIwRgWsulCwScAxn7ibi9aYPaGwOCwMBFAgMMeMLxP8PeAaI DkZA6/SAfv9caQZnVfD2XEZqBwV+Rl9bGrey/TeAwmGIFkZPdesZLgR0RiSq3WwDbXCAZpsSMsjz GUx8dLQAJgFNwNzO3ck0+8KioGoUXmmHRLUj/rTbBQ/4HPIvJ/Tw323w3E34tHElE7Lc3FaCDyAG 4A9gCioMK7k+UAAa4cg7fRiqZkU1CoKWZlTX3FMg3MKQr0roF+3CqFjDVcc0G6wPqms+VyBWVTEs gLbURFvp3ExWkOH4psV/Ocmy+Qn7CPt/wf0CESygwNUGk6reORAAK+QX8GIBrRKsi5qdzcAsdg2n aSDPLhREAAL6dIAcWT4YxsjZi1RnRCUMBJyR29OMnP0spV0BH1Et/3QtTAmCf0s/IQQVLVYNkfzc /fQAdk9o9HUGE2jsDGjki52I/gVo3HVmjHcQuCE71oBZpTVCMNbsxwaUszCRg41QjhOU2HXpZLZN IaKLjBjSzycnZwdozHjArJRm71uydf84D7eFFHMQxmbfBXgQ/QUMEmF8k+1AdOH5HGewBrGkg/gh eFiE7Hy9HM1lbGsPsNtFwNgDINXZWv3hNEtF1MHohAbQOQhvO8grxAmkQHWBCtAAxGVejgBAcewY uwBY4J09AF4nU7mphmwAcsD9Oo9gW1i4auBqkTGCkcu7ca3C0bJsAiQXCqVkJeip1qROCQcbMskY DFu4V6olxyKJCPs4cRIt3dD01HICAMuVkzPbAwDtD68ci+QDTSYmW4PoYkP063BsCQvwdI466xzQ LDToYqTtdA5Wxt1rmX8IaLR0WwQjYRK8EZDiUqVqxg8bhb9ebpj7W6Q7GgcDAaEYBJ8Us9eBB6p4 4buZQ+aJA1XUMdLQh0WgcqVEDtbZy0IAVs9cdQ0SWAXMPovL6yAMj4WoZa5XMWLBIs+TBND+DF6b nc0AxMaQIT7CHUamzIspPKGC1iu9MS4G2WBygHadFBCDYfZODRYUB5YXaXINGSvi9GDz70/FqH7w RKggB/FBqAI+f/798kj2xAgY80OoAfRSqAT1U5Hd9lkB9lRO2J2U/U02Vb0o3ItF2DmqJkVg/g+6 Y1T7amQG4G3Twfh2B+ZSFOIqwP6cALmyz7BoSM0wAEFowEki5r4YAnATF0kQMGEEM8S/U0LBRsLJ L2WyEB8ATMJ1EZNRUushmRuwDxBEkzmmMB0kLKLkZagmEE0CM5CXbJM2GalAdg9irJmP9lMQGM94 S366iPwLbYf8JAfkIIj8iPwdegt5iPx12jDD2ZsXygnXV2sIZsfjEI1HpFxilWAgByXKnNVlQf4J e7yWcK4jwwjHC8WZXK0uFUR2O/NC2ZrrajmRAo8gCMKzkeWSX/ARVpCOLPbuWmVBiJw1DmpBXGw1 06RBSitD6DDXAkYYnte2Xm9raEYvBQ2BIlrLPj8IQxQS6xErjOhhURsA91j3MIoOU9o7w1zawkVA dVwEUGBEbSMV5KMTAI8o2OahY9FTlKsp8SYIKaoNRpAIQ4/TnYa3qpZt4bAL+Ap6y2KMdswRAH5V Q9wuO/spaPYtSsdTK8Yu0kH8maQImjv3fNxFh509IlMjVyQSOZjZTo4mc22UWSvA5xlcjSvBvVzq YfIxs5B6i7I3gqMBcAUVG8tOiF47NBpYWRfBkgwYWS6bUJyiA3oRoSVEMIfQQTWEdwW8/K6CFxv2 pECEIgsHEwkhaAGJiE1Egvh6N/wr3FaBgbjgjIZkirEobVHTLeHMFO2bUxBXRHPxOvy6FUaZbBZB +InaALZzzJwWNhxH67YniJsoSH6QXlYbH8UsfyrUt5C02dtcrQNTAEcfMvjKApdYJlo+Gz1E/FOK XQtiMwc78WBAHYUItQWKGGgLiFb7aXR4oeguSQyIGB5H69tEGd4gHwW4wCA+Q/Kz813olQETOfx3 IFFHOPyqLcTyOSE3FCz/3f7c/jlhnxON/Yz9Psn3IZ8T8sj3GfkY+X4X8jlJ+0j7+CnI+C5kZELp 6FnBBfmig1heyrUhz9lu+LgSeyHPrRZZufl4efgUQp4T8vj6+fqofC9k5KkICfrXaLqQ74Vp+a2Y mdLwRp7IP16PUv2CU0AsBXVnSQaLe33pSTzkJJ/ySPJI80nz0tUJ+cj1yfU0H2pBxl7J9iT2GkM1 sr1gVff3XCh9ckjU1bmnYSjzQD5Humr+av6J/No22YHjOJFFkByNbEmAkl/09HPI54WLSfVI9Qeg UB2qxu+FSsmivRypVB+gSfKTFL96yfoiVTdXGQ2sN4Fn+GKKCywDLDslZCDsXLchgEfsVgBQAyhE DCBEvFbRVg1NgXYYkgmBE7jw1FZAcAZR9fAaMLFs4Ay6a9qkeaCBQVbbptRmkQeaZaikU3wqWfc7 34IMx8iSnvWe8wxAkltvGblUNbVeR/DPGKxJODoywYP7J59wCAY0uYx1VM1mbQpnJPVry4wa1/CA UFvRhl0zUJ8brv0NaPi/qExC4wYC6wuCw70VpkC4OwAa2DSBIHFq9I6ts9RJWBI6iI7inVsQ04j8 BgTAraNPBQR+fusdC7gRIEdNctxA2xdhstRh3FgLUT5Rih8+qpvkyoJ0QzguGFPJATkBLP8Cm0oO 2F9XMNz+Ay5mU8gBjP1TDCp52KOaXcj3TCUHbAUuGPkGsKnkgEj7B4wGZCo7+F0I6MkBu0oJ6lj6 q2wgUwqMTCUHhAumuPkMsKnkgHj4DbsG7CoZ+A4uqJIBuUoPCKtkwK4Q6mhOQwaEEaaYKYrKhgpX 8HaRipoTURgSMjgBatIK1B6rx5eZ2oqM+BcUC7LdQKpEhyF2DRF7yx7bHVn+Px0QyCF52R3I98j3 yV5IDhj5EFnkQA7JSPtI+/iOZMCO+Dvo6HLIHkuYlVj6DuTIBlkYuMgO5MizuHg75MgO5Hj4d/gO 5MgOqB2oCMgO5EgIaJU5Eg7kaJgNmJAPTiwsZPZJ4i059xk4wNTXSlEBNo8jShPQ12wJBf+qoFkE ANcukyIKcBscv6R7pmogmFYaVDxGHZn4ngVZaFBzUSEcABElFpka2fuVbLQY5W5IQBsNRy57KggR JDrXWnruYDB1oAmcEd/JXpJvlAzrH0kAs8MgYFatDFM6A3JJNuwMW3ISr411bOUSVhIHdVqQAFyS MFFbkL4dIibxC5K42WKmlVSoOzp9J4zsxPdZP15yCQmSBDnzJA/IRt/YA0cncFOdOiXXIsKS7moV NjCKPofwubEcUIwcRwNdyMOwqavodSSXPWCmp5JZJ+TwyAE/fGighgEgtJxyswh2CxJEXbBsSOBO nhyM2TJmI0YPSWaotpYYa2hzEHMTFhtlNKJ/lmB7SC7gOmpEFBivqWEleSoOjYG5JyLexwUVOQgI SUSMjSNQAFEiZBfyslQgURXMXEIkKoIb3IBbyZBoGF8VLFhRFguaQijh5VnrBZj5WRgH9hXCUdjG nPpZJzYphFzU4ycwzpBc0FeJFsbBtEgW2I4qVZg+JTqQNC3BdCQxIGH4giNGpD+my3Tl1pBcEDVV ABIrCQ+KuPF5/z53H1gKaMh2WX4+QDTCD4dswk/EwVO/QlfgngYYscJ+uYiUMJSDV3+TKrQsW5Ht K+h9VhmF7/OFQ2EED9U6XDSY5EAO4LpcCHVyQop4+P352hoxGZcIkGVWSRPAjFjQAQLgIWKCNxAH IHbwPZUrONkmaSMMBnvAuxREoo21IWGAGhJdSw6BHAkZLtB39M4TTZkAQ0LQgg5YUTF/SVQtUSgT gDw3LtAkBfB1AUNWOe0hgBNGxEP+fTaseC+7tQwdKchlZxNLDVMn/nCm2QsLOgynfsQZcA6NQA64 TChiEgDh7FoWAEdzTeir7pYBpgGw/Aq+/8aFDdUMcr2cYZhqrAkQmI8GQkqgEmOzFxVO/LhFxbfs 6YtHDLl0fya6QVC+2zQGUzjjPR9SqNyUSnJUvAELiw40bBHwWyg8BgB1yRUCquOLEIknbN4RBsfZ g+6pYnn4Vz580Y2YqjAH9lkOkeLn3FmUJTZ+yAUDoDCw9jm/aB6xhAHJwdeH0xE/ij9ZvwFnkW0Z BZsV/SL2oHAFFBpIBmSDGf395JIIuGM8/SZbZjjgFUksNhpCVcITeYNidinHdhsaMu9dxivrHki8 nwsZLNJlHwy3+kjNJlGT97jUxIHcIMIOpCx4s2h2qDwaWcpxBgXFXyoCHjshUvYlEHRUCMzWldMI LhwkAr1gyXpeG2tLCHTJ/PyfHNkOEy++s1VjwEBGs9SaDVlHxbRUDvQOME8kwY2YnJ2HpIwYHEAG +yJMeBMUkAEZZGQMUMlBBmQEPPx3yIAMcij0FOHLXjLsdA2wRt9ZX+cmiwZX1LAcDsCAAEXE5kTI IcuAMkC8vUDJuHu/lJ2+UHhz3jLcCEW2+nY2DUjzEOm8/UgYmDAsRvwm6V1z4XDd79bs/nT37LBn Qj5AeOw4EwM7MBkUFxNLECx7YOp8p6E1SAWKBi0VWsN8VNvsyXk237L2GDoaCw0Yd4HDGSCBbBeK wRhS4tpqjhCEjJTwmffeVNGiKZkD0GnS9jCDD9pS21xWM6hyDqBmBSFwUcidyL9Q5QPx6xXGuBBW NQHI7T/nsEKQsjymPbCsITgEpFc9dkc0rEk8OA+VwEGJgHJUlCG0SQQMGDIkAh4E6hz5AcUg+UgG ekDxC+2IVeyxsye6DHe5yrgFE8SERPq5aegyc8i4uR37A/klG/S4+9mIVdiUkB3Buf21uP0uJIlO eo/zIBIBiK5lF9HM9KmIJNB2/8SXKCwojzv7dF+kq4hZagZXI0e691ej/gzU4Im8sIo4YxmwAAA6 OTkdFQ3ws4rYXgkC6weAJWTIgoh0G+yCwgTFlEG4QkGPEgeyYHJkMtg3MygSf8Bhix2MELi40tmB z7j+074oDla3IFsVbmlpuMlmky4u/QkpBgBDntj9lPGyU8AUDz7BvsuCjQEKJCcZEwwBw2TAa5Xw tUYpaWVCaijq2/6oiFCvwoKESOxii4DDWmZk+/5JNBIFHvyLIc9lbw2nuPzGgBiwnv4flptgziAv BDYx/OqDDWaD+gJ1hXLoBE72jmqIckfCQBvVzEVAE+jIRr+YJOjFCtFgHpmQR8rSYP8lmDIysjmN BeTg3DI2MjLY1NAjzDIyMjLIxMC8MjIyMriEsKwyMjIyqKSgnM/n8zkkEaAQPBAwETgZmzyfETQR LAWwGRkZGbzE2GRd8xwZeAQSDMwAUS8APEUdjWlyFIHQsd8NHdbuLRCFARdz7APgtgU+xAyL4csz sl1oQLDDzD8QGLB9JALFyJj2RD0BiSAGsUxWts91mc1VNSEoc2rocuEWHRNBWcTYZKEAdBZ6mFCg Jdqo7ip0hIll6AJd/bNRorBkcIMNSMpGqbqdrT8GTBSEEf2RkW3DiYkIDXxszzWI3qGADLgoiG6r g6W/vbgzdSLAbFCJ72xO7Biq7L+/0kSYCA6koWg/RZSwuR9A9TVkDAmcXju2A28DoBNMEk27UAz5 MgCDoUgWirr7v4swiXWMgD4idTpGCIoGOh6Qb1uaPA3yEgQgdvIbBIXa1NDc8yCuIhY2RdAiEeir pc/b6w4rIHbY6/VQWNXP2gBF2CQQNxPMDaXXbZeYM0Rr+HYJdCPo+4lNiFBRhJ48i2XYCNsWwIgf PIU4BVcC3shAHLS3BMdH0NgBtMaJw78YAbhnbBFoBTYGgDaKMRguHelhRLnJnHd+CASwRLWbLpom ednrZhcm/ywozC5EEAOoXe5XP5HJHjpwzzVZNI4gs0FZywu7o2CD2CvGB9vJ9o3qgR2LwQ4PtiQJ YHv/tkADweEIC8oEHWb9BbaKnjkg1d0uVMO2iCTDERfqGNkg29YSBkAHEAgikzqEovpXC3hgHxGC ULHLM5nb0QvxznQazyYXkU+51XDJ7gJLhYMgAI1fq2BIASI7mwL49ot9CPeNFAddVfxaFwJusAhA 2YXJWHR7AdByigz2wfc/FTTO6v50DDvyD4PeC5ntOwrXjRwxO9oOzwJAH9gwhqjkXgMob65UuTa3 SQWITRPowRFsU8FdQYkjWwv6ORE0RJlcAA89+0ZHQ+tYxc+xX0ZcgV1DEH+NamQYIB1vjQUbRkEk ioC894gwt9u6BhiZElk2i8IIFtuf7hYSmUMQgusIO3VFOb6CcO2KRRMaKg5pYCXiGRLsMud3uZkt FxrZdQhzCNVI0BK3B3IXAyekx4Pp4vbqsUw8CDQZAJcoccdAYAB4ICj3GAsRHOBmfU678BqC2Arz 4ghegkXL5opF7gyv4FIAXx4fR4XbqAAQoVcnzbf9hvUj0XRKO9GGjilFhdxvhjCjQYvIK89Bpdve +NY3EOM/weNC2ANdFcMmKrTdVsliK3Nde9pv/V+ACCtNCDlN/H1O6zDlMwE7Lt/u/k0Uc0ONPAN3 czuLF4geRlMZAdMFtZWFS/w0qHMdb7upA/NaGEDpQGvadCNoRBsF3jjAXgKhUS0E+pEWxjKRkDxg tNOMdG4lKIxznARiCM3mrBwFqA1DPfgUPwHQohqGLV8q6KklcRhzylcPvoVoo2qzayRnHZqFt0wi jXoBMve928ei4ER9tFNV0P6XBfFbK8VrwGSL2DsC9hqo8n/vlCAAaJGoziQlh22UebhDJcnm5j4y twPYgfvWaI+nW7d7Uc2pIIuOO4AkbXg3C6aQiB9HqdGFZjtY1N/j61aD+1x1Cmnr4w4V/sJWadFp K8FIqMB1sdSqWr87JHNciAF/OwW/W0OdiUgUR1Hruf1+4c+mV3M8gHRHK/qB/3x/LtrIYU+2QkEg GivGgQzWQy0OfrZUj6IQsh2lJW3YWfcBtgjgov5J/TP2A8c71iqg7iCgoK4niwJoriAawsYhJraV Nqg4MmkLEHGZ3LeCKzkwdfkL1xvhqirioeHb5A1dHZ2oIM42jVwDAW3b+Di+z8Z3AasFIoWtEVsS 22EHHitYik3UdENOdD22UvYDfq1mrs/G431YULV264I1Imn8OWXp7gMBzfiE/X0OtWy7E0HhfoMg 4MPmGgssDl+YO+y3hTGaoepzU0jO3W57R2zTCLTbjXQeeynq0o/f9OuHjU8V+HMti9C+tsH6yq3A 1sLKRRdA/rNixW4E/AxAiBHrLeF2I5rvAsF1TfRjTQWU+IFopAwGVouLBzsB3CJt8HMmzeEQQH6N xm8LFYvyI/EJyxpy6hDCd9s0Ow0HQAx2pCMUHbbXB6Z46K1VFKAimEwIgOXl7Qp0EgQNdA0FdAgc 3VU1DGjQIH4LDALu/QZ/fQQRGNdNrw2T6wXup5dqNOLygTHddfQ+Rt8GQawbhs+6esHL8lbjO8qY Xw6D5+f5tz/wgwMN69ceO/l1PSx2K9i9GV4idAYGUEa10IUjthBQRLr4ClPdUNpBHzvB3J1PddV1 rd4QHnWaOA5sB5Lb1Qhwes9dz9Lz0AbDA+sKXkLrC9tjA+sPVvv4QXzo+MsoaOFafwPrIK0E0RdB 14AiGg29gvYFaAsBq65de52RaZdj0WGLIGJQmfzw2cQk4VUhUyLnQI61C/0kO/t/OvsqIovrOP2q U7OgthfdeBSx+fIlEH0HaPrr2BRRiNiedRWrgcpAhzdmuXMLvUB7NYsGE/rgDysMHL7mk6BIR/sq APkGDAwbts1Cr/xv6BasFSKnpKbMfNmhqqMdiS3XmnD2HtM8TD5TLotdW1mzCICKvHQQSf+LUlQd bZTCA/JA61Bs/e3sO8dE9HYNgHj/egcuVf0JXDvzdSVXEdQbJwRiUSGO0Jeqtf0zakSh9MuNgxgb ELklzRTYuCwYVEFwLEidOnsk4NNJao8OAZXwWwnOZn5n8Im/Drba3WfTgHUbUtL6OYIbmNxtzWYW aQK0iww5BdQQ9GvCIb4HdHtMyMt2xHV1a/82os3x8lH0zIE4TUlEWPgw2IMAfS0ddCZ7CVulKFeC 16g1A4MtuqcliT0EAvX/yhW1bIMIFAGDQWEgyFQRDmHL1k+FevAZ5n8rvHZ01B4DBUTrGBsJOvE0 4vwLLOoJACth+trciAAQhNop0CfhZuCZdQ3aA1DraJMR9VEiPjPwbEd/91mB/gE4fUlOeCKAPKQc Vj29R7bgVxnwgKQ1EQsWdbuATomN60n1t1sUxJo/CeUB+1rG31k9R1l8D+liMiWCE7mZUDZcMWB0 w3H4HBb8CA+BhhVnBAQ96IJaeBBWz3fqyJEwS5iLNyw2WFFHvWMTllA4swXVCnTdSKi6e4j8UBmA ZfsHYNLFl978GvC+jwQWe4sdQCS9Gm8J4G1RtQb1SKdWCzbxOAF+DLhqCBV65Vwr6usRDhYRv0Qb b0GKBEGxCGgFRjgGdTMX7onQYzHm1mTMDbJEqpAt4XqoUkeNgotWOxaapGNf6VvB1as1KMpkeg7J dmEnh3wSRn3SfNoWbOp0uQGKBzcvImRKRsa2OcDADN/EBwNH68vMgCV0yUZIJCzAER6+dLZW+wIq BbyNUK6lGLAjUw1W7ThUbNRoGWBTXFGu9qgzyFAMjIqDZ3VgKJsBOlHn0y9EGJACMts3KaDZqcEg xmsVjiaoDckPVEKg3hU3tCQILkHrDy4rNSoHCqiOV5yMZtSrMpgGi1Au92xf+6SniYgglKeHX0OO P9hWOR1gaEgFBwXhBdlMuBFkBxt13xuSXhIIwPVm/e/dsyXQC1DZg2ajDFZqNYkddMwizNYIZidw nm+29iqB6bskcliD4fG393rHaOTOC8ijbJcdBR3wrw3MMOE3vvCp90uY0X9X7JUz/zgdGt2/X7fm iTXMutgnN4H67Adz1lBAiS8SNCgEoUvx8iB0GQl0FMwViWHoDCjaOLTrPL/9F5yIGF9AOBh1yS5f Ost0FRBbwMD3Cz0G39rnIxYpeHaJGmt1NAiLijU8as69HxTtA5OtB1DtCkCr915rCZYApNulSaIL 74M97cB1McvZgU7V1a5YZRQPOaMi7QpZaMzWl6TY/WUNTniI0IL2G2femykSOKrLRY0Ap+iWBZUA +t7YgjfxigY8IEAJ9Ubr8w5R3CjtAHlZq9P0k4UsjUYGlgD6sQtPeFl/E6wzyKUPMQp24WNbyYMH D+spav34eDwSAeledBgQ8AN0Te3rgA21IHKQC3YHh4Jfs3Tvk4Vzl7lvjsPDoQeSbwZWf3GxxDDU vTn2dGk9ClgSt3j8Fjcciw5XukoiOQrARWFruRlbxPS60d4KCV91ORtoweCGiz0WxIifTg1zvIwN 5IBgFuGJgWKYoF5D9wUPhUCwAnD32GqiTVOrAOlF9ZSireCKF3QC+ESDxQs1ORyhogMsJVOlbgMB s3CKGFNAIRzI1kYhBGrXwwDHV4ME88V1BJgu7q6A+zAhCr0110qjS05ME3h0Dmg2UbEEWBj0CA/3 ZROoPiGAczdteGT7ulbzcAltVg2hTNSIbI+taXDCHbiiMOkylNDv1mATAOu880p1cEH2qDiQawxn RLLuXXIPJRVGP9vbDyBbagIC99gbwAYgPBXwRjFBK/CQCp+oWjR9C5kg2iNoAViAgIYljjl7jsot +4PItCYOVLvYbgTUiQHWKdnCCGZzW1w0nSWiUUQ3hFwICKB3foECRysvwcH4AkBYOmqoVmYPOiDb pxK3kkaBp6V3UyPkNmOXapViRegF7OsmFQak+Rz/NhACqzqyjBb/HxgJewfoxIeSCppUGCWJogbI TlJBJ2DCJ1WrzfilpYsVWQljhf4IvIx+MbkAi3H8Zjt1oFuAaLoVCf7yYDFUEKW2rQ8K9FlHqsQj 6kZ0fNkTW8PRhPZTDGY0Q32DJ/UEjXMMAg+3ushIhcnwJKANwH5pWAIEJAEdOhZHVCmiVOp8U6/N Ns+2/3oYd0mFyTlGRlY8+ApZRlojtwWhWUsqIVcSDjYWFkCrFgi2uxBh/01Lf5ftkgP7vsr2/vGi CDsX2hbUDFnuh5Nd1GwFeI1IDBAOhGaK6MMM5sc7+HXINhRaDk9Nx35ky+RBDmQMTAx3QhtyDaU4 Rkw8RlDILRoWWYncEmtaaKc4xO+c7Qi6nWnC6AMubIIhUz2XXlYNRciYuCAOaCtgGDOKCR23eojt DJtqFq3m9KmKs9kvAtd1CQANby6e8ct0J6FUPFPx3quhPkfIGQ8O2aF6WC/qD50/Tbk22ggVbwyl j9giI7WpfirYAaFk4F2qmrfMMEwnHreR75dq1A+OfggebNwOTAaYDlZPUNwDi8F6aurqSGrTZRrg GYWjIHejqIUPJdLVouSigN7Qn+hmNEbWDHEJCJl6E6qdH3pcqgxAXFrZBdv9y608wgdGg/4qD40z e+vD+AIqVQd0LJB7ixAU84sL3Is172wwrMHx8Vg1fHZIVR4GHDl92KBQrlC27KAET4ZuJWgIcG2D ar1mK3zuHq1uW6H+Dig587B89shE4IBRxB9XA6MICGBu4LfYRgeae5uhiLKRNRdNeC3c5kiMB8N8 RhglOnEfQiKlThAU4slmhMitFF+IJFiJTbDOCWTbKaCskg20R6LYQO7pbxjfwQI6ES1UhIIEbw1E V4kYc2rLUUhRxBysLA0dBM11JjkGk459tdGWbSkjvWbAdhZ4rlVYNIOPyDCYrVWsIUuFAOBUxsmL kkbGIXyYfiNoElMaDZiiSF5fybHZped+WG2CfpdmS6ZsyXQxnBW77AOIdUApi2QQgjdtgaJbs4BI AgLY3uj9KhRmLVNGZj2LdjlX2DmYqeKz0adEyD63mmjYmP3oUGxjV6FAsCSpTejadNsdVPHB67IG yKaLa2pBLN0GH1eVcqJOOpjodQ1FIHIjc9Eg+/WNRgO9FVSOWX4D9w1lp4JkOMEgfVOiMGInwd+w FewHizHcr+BA7+cSJEgt4IBLcuxGyYACPTbTPdXMCezbzCXxOX7cR+RcoTODz4PQdCsg1j1QKAMF PwaDMQiVXseIxHZkc3fIgyV4NQY9dGsnbCYgAmckn8KrPj6lPUSsAg8tjlzXMNek1+VIF9sBwiCY mBJZ/DjNcLNlPfZaWM7R+vyLnf8VaNkMnIy/9wI1364evHCooRCR1NPgPcDF6AVxCpn3hAtti9Nl 4nzAnMQpQBXeeDzgwFGJ2YKxhcrKdJQHQMbDey4sCilj/EvMCEc4fRJvPRRVJU7wbi1u7W0CpQJg O1TNrF1mvAkaFSMuh+/j+SZbqxBN9vSIN7d9aOMk+Awq0AhRjEbB5/kwOU0BdT4ziAIjEQSkP+CB 98HbvbInFldmcAWY/ngMOFG9uMUYtIjLFLWEvDJ+7HVIcwj/FKoxxtZvx261XsYpYG2qb+KSQsmC 5mWS8r47pJ+/BgR0BwV1SsMtWbHFlggg8Hb47fvciGpL8MtUoEiop1baYIKF6wj2QaC0DBJY3VYM qCJKG7IpFkQZ3llcB5uBAf+1AjtOLJurhmS0vxHU1Poc8bNkjRECVz0wCoI9SlfrqOrnMnjFMHoJ jGmU7GaYTOWGgYYaZ+l09RjSXoU1ExBDAC54lp/jaAw0MubnHG7jMJBDbQ4KRkZ2yBcidBSdzDTh oBhrOEurD6UOdRKA9sS8GAOEbRcEAWlKI7AOcgl0M7o3gggI8mV12NtasGi4FQgN3FDEZ53gaWd1 OTWEBQRg8r84N05NljD3vIQBojULtElCG0gaQthtf7l9fevNCniF63a/hMWekR/rUgYlEjMWaHk0 lslXvCmC2H3QAL4TFjUYdHQBTmALyyUMcrEKB2GhoCCMIfAtXXQYg2AL6EREnM0eSJJew38NwxCB bUnSSg0wdFLnIWclfIJQKFWiIMB9BgZWPKTrDlAg8LemNk0kdPG3KAx862oMrYglVGzEx4DvqdCo oQVQMw673d5BE5r/6CPLg20xC8hf2LZ3R4vQgeETh4LitWW0AMG9Urf64hMLyo2kiQ73frHh7bcW QB/+8BgKC9GLiRaASAEsqbCtRwdRrZ2qeF5y6V9q52I0HI1DCzlFKHdf/2Nh6KhKV9KYR+Br53wK EKQJeYUodqn0V1MTT9XUhWoWyg9T8FeetThYUwP7FLZOBKLbc+Wyyoh1C8Hi5naFMXLpPMMZiPG6 jgc6SUV+sEMoaQweejqKC/ckM89WvpXtIQP4jXkQZlYLFxIZM9sXOQHtsLfbiQ50cwcYdG5ci9sh 3UK1K1BFUGMYSN6T7TvDYG5qCu3JZANsU+zZCNTDRh0IEMZQZY4snSJ+GXN0CFmIdy6gsDJN+GnJ JCgRm7GJSAnGRHsEEYy8bG7Jsd+IQ+VXADhA0EbPFJQQqRC9pqAu435ooxUQpdvt3+6LBolV9I1V 5BjwUgb4Ur9I8URsCezq6MFa353EDATlanU1aMDUdMUq6DW6O9lYBXUQCh/eT/AC6BgDwC0IJQG+ AH58m4vDXlbJWALz0YmrAa8CLG2Wu9YN0TBeDL8vUwqFs+Kr6Md1Bs8VEUO53qwQfCilOMi2azUi vxdqOxlY6RZoTQXaEhs9ECbf3QojC3QNPgoEKATVFZXMZq1rNWmb04gxVOMI+22oTE+Fv4nBDNwj DaEDzjvZD4dANcrYJgEULJdFbI5lMUkgxuDxgFiiD6SiHO+GEgPY687BuSAcnxns/J8efTcesIfM eA0MBlfOOYD3kJUCQ0MWaxSQA5YRKe0I2MmfjeRb6umbaaKIgM6E879RDxMR4LWFJSiwl2rkAQyk 1TYGfIE3clB4HuiM57gsd1mwJa5qMCcTZjslKjOIRlBDJpmF0BZ2jSkXRgCCAYVBvoSbYuFEIKwj fRiK1ICNEAKZ9AkfVHzQ1BO9DvkcsLipYUaJS3hOYtAGBO0nJcCGkeCfImJ8E410BghuF925THdj DwLrEa5C8MGxF+4CE/CWgX1HpWxlfyRLebJzwctwzxsWLzLrByREXy2GBQLGBQMgF4/s0oNU5EfC +MhXUVBRQ3RS7n24KGdb4Wah9iYuXOviy8OCDcE0Eo0EPlmGOAUTTG2iQUUpUiR+/ZyZoISQV9jb fBoi+ChGCkQHAbxVFDCpG41Iwav4u7kYfHESA8eJXVgbAnEUv1ZI8KCBuBvxO0EEe+1fu0mkoHYL CwZZori8HRxSMGHzVcYVxI7JJAuM8nfJfmALESxltCTgHgZDCWBgbYJXoXhv97wk2BiLHW471RAY JoRD1VQjF9bpMA4sSNCdkKyjDP8YDxCrcFSM30ZcZWmMxlcUBFqeV+NrpMMJiy2SVASzfGsEZ9VS y2QPjzJzgYsSk59dDz8EdGkiVLQCtEsEQTYyS3wjHCYJ553DiL6vPQSxVgCDK3QEfgRTmgq2V6pv 8bsOBxFAjSiPeNsLihsFsuI9lCBiJOY3WoLZXthbEFf5aKB9Z4kFA6qVgFUjbgvu7d0PGH43O0MU czEVWZzeLiNwJN4HRFz/1W23BdfVGz5GCf9M+1nWle3WfRwef8kbIjscH8U+Hd5zIUPfTVdrjN1A u2eLXPlC234vYSn3lh6AWUsqzVkTHMTyMOskDYuKIGzusw7T6+TbIFf7Z3jygR/tvIQfExikCCLN 2FBee2GCOwQa4l5bA/MKobkRNgdOCkebbLYwWQJQaQwYFcIRsvJtUXEu4CC2hCEQUY4Zglvo4AcV TQ8JGW7BcABLSXXLYZYqu9jwGf9mGFlh8EmIsOBkXmw12xXYCLc1ZX4xdytd+GwHws/TGyIg66Yx R9vA5w8DvhoD1xxNwyvcgO9KFhVbQB7GkLNhRTm8Hq4H14ALwldGrXBOAQaCr9E2AkwH5wMBCBay JbhWMQcwHpBBZeQY6zIA7H1QLJEgmxvWoaILD0LVuSWep0TSBVAyERYINyFuiwofHLSBWCB+KIMg AHKPYNhaA8HcaCRzV7uAa9V9OEb2BID1SLkjG1tIEvWUWccWOyNiVz9ZV3n0E3MAMVd7lvVb4Z3j chTRGP8ZQRwHdbdwWeRhuyRyqSAp3Bz851jo+o2EJDzLRr0azpmOgVtoNEb2A4So9TeCCq8gTHgG 1ZuOk6nGg+A/0XC5N4A0hDQwOPPXLgBhwMV85CNcQNwFYfP6XO8wRlASxcK3Gkaf/cLYcK7b7Yz5 WVQ7XJ50A20WOyEd4gqNjJCPnNy+PFGLTCvIA0yOUVDwlxW68Ntofh7YihxjA/MlQzvezAhNgYNw p4jT3woNw7odNAi1vFYuLizwGSkQtyplpIn9gbcsUENmgAgMS+zcwsp5CiHvMdxAZ7/I3QBiA7sB QQs+AAdirjk7YBuCAhNqPwvPHea6qiM+FwvcAxtrtoN9C61LeAMDG8MTnbyymV8HEwLhHv0GwgMa GXQdVr7s/xA9QauFZVY4HqiGZJSkJwoeCBSZM9JqiYims34qMX+pgi3vQq189IA+KnVwFReIBdUB Sj5O9WaWmDAai8JeswhKUYZ6gBTdIlrNAmiGxK3+jVjjxl+KDopWAUbxJX7hFj9GituIXQqK2cOt gP63Agf8gOEDitqA4g9r+m8XaBAJy4oaiE39isvA4gJC8W9RDt3RsUCA4z84t4v+f/td/3NgB/1z YTrRc2M62XNlO33CinftdC0BuR52ioloFXtguzf9DBhAEP1HDspHHNsbkAn/R6tHXGWGdxGxG/8l jA4FoFILbsMIORZ661okCJ+iCQIIdhcK2iiaKo2a0W6bom7spYvK96SKGIrRvHy/7dbA6t9V/IpV CdrqyopVy+Zaizoc7t7qysk2e6uA1EByBmUL/V37T3b5Co1QBDtVFHdGuE2St2QzY8YUDf3Eybbd WwGjig2pD+sJG8ngii14ZxNA6vFykSpKv/cEgEZL2eyCbmGUEi+0EogSFhSTp4yQlNu5DdXpa7j4 RgnG0hNrQCV7uIAWC7MJPNmWvXzLuNgTM+gAF0VQYYMAABeIVjSAUFs/4NUHdVPeHNdAnnwnAHZL TZADLyZP0n0NaAsXAAMLiCAD0gwEhHxL9ibN/3g7AAu56brudBdsAwJTaFx9Qa4ZuRtYRzh9QTQY A5dNd7oFRxALBvx86Hw0TdMsB+TcCNjTNE3TxAnAtApN0zRNrKQLoIAMaZqme6cLaA1gTKZpmqYO RDAPLHTda5ocEBgHAxGDDCzNZtn4exLwe3sTpmma7gvMFMS0l69pmhWwqBaDe5B7pjvZLBeEexgL gE3TNMt0exlwbBpoNU3TNFQbTCgcWZ6l2Y8ge3sdewDuLM2mHvx6eh8LmqZpmrQgrIwhiGmapml0 ImxQ+6ZpmqZILPwkFMtm2b39Xwvoef7gecg0TdM0ZMCgZZym6V7ThGbLC2gjc4dhmmBID0ALAPT/ /wNBQkNERUZHSElKS0xNTk9QUVJTVP///0tjWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1duzZ//93 eHl6MDEyMzQ1Njc4OSsvAD1HoHhXhT3ssbsLsBVvsC8k3QETyDvQE2AL+X0gBZMZIxgWWzZhj30Q B0FHCGpBbwRn0w1kQxgfAmNAn3sDWCBnYBeHI6AvZbOzFmuwJ+MHt2RsZN/jFodAMtnd6CcOj0Df +FfIw8wwJyAXRKiqJCjPQVQANgM0TdP8pDBBAKCcmJSQ0zRN04yIhIB8TdM0TXh0cGxoZP9/0zRg XERlYwBOb3YAT2N0AFNlcLnbN/8AQXVnAEp1bG4ATWF5D3ByB//tsr0DRmViE2FTYSdGcmkAVGh1 AP+dW/5XZWQAVHVlbxcvJXMgJTIuMnUgiICdfQh1CzoF+v//QaMUELJrTQYiupdEG2y3ztbUfhfV VZp/9/+m2xDwLUgfEbuGGQhsqScSEKBtQhIK/7f/l6ArZKXW1ZVoXMIADRNqQF8Fs5JWRW2hd/// u84jGqhvRS4YsJJ3EmKs1duVZVbbN7kxAv//L/scA7uSGRMaHu90RR0OvYtQA2G9+tnCdFzy/7f/ 11aV8CVKKg8BLw6sd1xfD6uMUgpvptXMP/b/Pw8fs2dAGQ2lvloHMurU0c8bIxeh0FoO/////3C3 29PSaF7TVJD2MwFnAwMZEQ6iNxlGW5KbTwhqsN+aj/z/7thpVJcFrHtcGBaz0FITYK3O0RMXtg+w //90TQURvZB3Dnun08DeKFrZVycYDv+/Rf21ZloUAbqea63J9N5+Wt9OkrE+C/+FF9gkAFcVESdL HgCzmlIFQ/xH2P+hwtfSclyYWZjyg6BgQwEN58b//zaUFtN3TR8Mt4x3Bnq239XXZFa3n0D4zhSU 8DArFBizal+0vpv/Pwj/WStgpdTV32fPIxSvYUMEDLbQVAptpf//397e1StD7TQQIAMNGFalyiAN scAEEA6kcUsP3d+2GI/MZ2KnlNfUazcPa1wbFPzLD6oKYOrZ29YYHkn/EP7/Q1XhyHcNYq3I0chz UMBIDwsbsi1PAZj9/9sLvWMEbhAHszAbRxOSh1YDbKtLv/2fwAsQCfUwGURX5L5Sc63WmtJyW+GP NQ3XB7+fXgctA7sRtwsv/w6lcEgXEbS+b6jXE2dKEwcX4e3u/7RwWF8DoRMfrntE775DDrPS0clD 4//u/xsJpGJPGQeg04fq18aVaUzCWJv+Jx///18YE89qTxoOq75bBGSt1JrLYxfdSAsRrt3///9k RR9MopsZAHEQC6hyWRQis5lQAma3lNvJYY8K/2/42xymHxQR/JFFDIusMRxBU5KTVgJv6d0gSNj5 0clnV8L7hP8vNeoXAg28vkQCbaPX1dJqg/EuRRoRL1OQUOumc1Wcm9BQA/hN0zTLDDEcMERgdDRN 0zSEoLTI3GmaZdPwDDIgOEymaZqmYHSMoLiazm2a3PAAM1sDKDxpmqZpUGR0iJCmaZqmpMDU4PQt 0zTLADQYJDxOsBB0AEcClwRAC8FCgwZvCGFrHZXud85XY2fZlrutLQAKExR193QXcrr8L7B0NRcN Cg0KUHJvamUgVC/bu9X39W9zEjNkYzpcBaSwgAAR/w/2v7tLRVlfVVNFUlMLTE9DQUxfTUFDSEnG fiPYTkUTz1JSRU5UJwDub4XDE0zlDlNfUk9PVBMH9gXaUmVTenRfJVgLINy6Q/dLaWxsBz0WpyIH IizOGUgJa4Ot4yPdm7lzCQcRD1xTC7x9+09GVFdBgVxNaWPmc29mEFeB7X/7aW5kb3cfQ3VycmVu dFZl0mnZ395qf1xFeHBsbxBUU2hleCBGb2y7wfe6ZBlcQ5F1M2ZrAwsXluZmb2cgdytEaLsg/Pdm bm0Aw2FzR2V0SU5JbnJ3m+xmb0EXRWZyeRxwZXI588O24UEvQ29ubmCb3WKvXxUXLHVtGEjs7Qvd FlItQVBJM+5ETEwjbdtWeGVnaSVKUwJ21WUtLLjNVwRz7FpSdkwS3hCWJ0ALnxK2hrbnDHfZZRrw 2g2uUvRPbmNHvTkWjg95cylnQxYyMDCdr73dB3BjcwN0LmRuEzPP3W3vDC9acRsuZXg9Bcu/FHwT /OdHSUY4OWEQxMuyfQHY8ADv4N+Wf74s0M///8+fz89gwLDLsnxZoJ/Pn5CAcGDM8nZzGA5gnwWf nzAwdyRf6nb/BJ/PAIAsBNL/L71rVoEgII4iZJJoCTWJcqalC/z//0nsoihXCknSjCgLwiJHelQm kshjUUxL/////w4GRbl5MBaHwxOywD42gWpWO4IMAoPFdykIkB9w64LBF4j4/3hYCANA7lGmMxES FQZ1Ny7/0v//VwcIDRkZGyJ8F5IXcIoNko+F2xoiN5MumRB82P//caSlmQAbqaqrqTCuJCEAO+IB /yAAIGRzk4P//wD8z6y7fHaf//mvr5D/n/2f/xaXZRtgAF9QMP/fbGW7tSj4nyAAH/yfQ2u1t4D/ IOkLiL/ZXrL/a///Y2OeaJqS3+D//6zYEEgsz7T8eG2Zj0Lv94gHBJdIegSCIP////+5VDKfwuGu ESB0rtisFhYltoxWjBiTIWc2541aEIRIi/7//0JyBVOp2+1nrtvLAnfGFQsFg4QceW1vXwb//7e3 f3d3HAWGG3qJfQECjQyamwwcSlv8//+HXVNxjQQkSRcFoJOIfCR+dKYiSQYgof////97o4yxSbS1 GWmUriWXjXa2yGe4la9VHcDQ0cpqwlPOWij8///YWNVFlwMEA+Dh4uKtUzA16DNdEEUQbv8L/+8n 8fT1HhANFjke/P3+8fFBuNDHjcGDCP+/8f8TumnghuCrJr18GTAsogIHDkw8iDKwD4EJGv9/6f98 ybCowIIFWxY2Z4BYQiQCkhVVNFBpkCUAlf+Fv8U4c/ZZs0SCiBAvBcqwYwk2HmD/LwHAJEW40gZP oxIoarMBUqSX+N/6SgU4JeCp1Kke2DR8pTSGf2iZ+P///yKAutbDC4ZVg0acO3HiSAVw+8jcu9fo K4WAAdscgdzYICw75wgEsizbyPf+AP3891G2M8ry9uUA4cuXv/v8498A3O/c3N3c2tnZ2tnYtSi/ LNfW7tbW1aL/35bfBM/Oz8/Oys4Ayc7Myc3NysnIx8jF/Mvyz8jHvMbDxsXEw8DDw764wpfl/7/B wb/BwMG9s7O66rq5r6+3trTu8+VfmrSxsKywr+2vraurqqiW/3NzpqaloKWko6Sbm6Kbm6Ce5ma5 WZ2YnZyZjpmXZfmf5pSXlZOQkKaNjZqNivLl8peJiIeIh4mHioeGho2GdP/ly4WEpKSEgo+Pfn6e fX0Cm/ayfbuDfHN8fJV2AHV0dL0CFfgt12t2gG1ybnJxRQVa33KZbGducXGBagV2Nfhtamxzbohc rGyJL/2uwWxglhJqW2lkaWkSaGhnLS//dABmWWVhZmRgbWBhrduWvhlnX2VlMF4CUwReAPz/0vxd XVJcdFxbWn5aWVlkWGFjWFhjWHL5X75XY2BXVF9bVFRSUVFP1U/z8i/LTUtERLw+hj49NX41+5fl fzIvMjF+MSwqXiYlILi4HT1OGTaNb39hFggPSUkEBPcC8QQB8wRXvkH7ygDS0gDjk7QAGNsCSFAJ QNTGX2rxEocI7eke8MBFHNb///8/aYbcETCwIYAJLEalEtVjEUOHAiWoCIXqE5X/b0T8FzFeuIFF JIswChSgIQ8cOmj/////9AgioZKACAorPjTBAQaIygE5Dlma4+nSJBgqATgIQoTUvlGr0tBDKhjB YUb//xssPpj2UCHDBhQQApyAwkgRlzpHGrX/JS7wSMEmEfN/DO2kilUlPGAiFPAG/v8xAWpVKzeD DnToc4pUJDknCMHJVC/9/y+rgA7USOJFi5JHNBnsmLIlyxLknqh5g3/7/zOGjJ0rACKUMdNGzBqE FsywYMSJDQLa4P9/SjR4gUGKkCpUzmzao6mTpC9cEGXQ9Te+qFMmSjoCDa7zf9nAQDPzZGmqrk/r vq5S////+Ch0bdPP9qxAq982jEbhmwFvRSLspfyprxj8+v9oTrSpWq9Wnna7CgG/oQKnsmWLHNUC gGCzZVu22K0CMAAK/wfv2Aaz37nP8Ly2Xiw2g7myvc65s7nmRQPU10BR2Uqzsilg2rEFYFzZlp0A MF8wHTBgc81twfIaMBgDjQLBIdZcdQV7BIlERpv+HX8H/xsUHgb/QFH+GgEMROnILHpe/v///9BX KgQoGBCHZfOI8Tg8KJQspQo9CgesdjvseE6n9yt/6f8NL6lWIbSaLXRH4xko9jI0LHlpa3+D//9N HRAnUR4fbjCEIistZ3uLHpRQDhFQcTL/v9X/EiozNi1oWVtxrJRRoxUzNTYuGgVKTayeLf7//wtR MS8oFSk1tC2omUaNoQqcL78ywjV3PP8vVeLHqkfOhyid0CqEMywkN9aK/1/i/0QdDieuUSgeC3Uy JMa410YOKR4RMTC/MP////8V4hGrdYOavXNDHIzyIKNfjBQgUKgYdspEwRYMLtwrMlJbQLQCOWpU zL/BL/GDhSVzqRHYyFG9GSBHyqP/////xQJlQVsELiAkMmKFisYaMiz8HNjCRc2CI3KyNNKzRk/f Cvz/k8VaFGRRFI1ONgMKsBgPe4IpXRTxf4v/CKBx55ABBwwUl8LGqaIpqx4oy6YU8P9vJQsN1Faz uffMBbp8ShyYm7/A/78SCRPOFPg72OyREoIJI8AyRxbHTSAP////hSaQwoTGmAOXWElhA2Q+qAGQ 3pC6iYHXrxkci7/9b+2gdoLWQl6vPEAkbMQbNky2YP+3+H/t4OMFkiOeMLk5gjTYTBAg4Lh1584n +P8v/WyILn069SsnUyhNgjvq5eiXj99uvkgQKTIh/aYAZ1uiQC+QJYddE78DNNVSEfwIutwgMMo+ +P///79Zwvhg+G2dOAAEipIB5XKB47ByQ9fLjT/wrug4YI23su7/5HoRjsikMuVjJABteGsAId1g J4RxgGv//9+KYCrcrnDFOMi0Uw0JcT4A9f//4NFllKh45GBKAhRqKyYIB12I6mj/CxWwU8frMAz8 Rj8fDwgAMNf//xE2udyJBJFyqNbnYMvtrnxgZUN76mpyLTZ4n0zPwDdDdj3nRWsQHvdIL/D/vxuY 6Uz5YBFFinGd6CUUk5m9sHWAG8v/////OG3fg6xjsJ5w1QIGcbPiayhM1gJM5MDpCVlBnIN2y+XG Akj3Ur5gcHty7oD9DxBGgGM/CLHcC1DFCY3+/79foBQyRrQZ5hGAB2kaJkTrc6qZsFIo/v///6bM e1E05li52o4S9DkUDyGIN1Eif0kMsymd6m5YLCBCAIGxg/A3b8BgTWA9hgA1IciAMZ+MrcyV7V8A UDmtX6YQeCM3dYpRc5V/g///10imonRdLgukqNjMFMJeZjRWweNCmVgA/////45ZqoGoXIREowMB FFkolcOQ0nAEHDIrRUv0glWARgOixf9f4Gav1V6IUEggEOxwmvqGRF5oafpfarASBrs7f4E3hIaI imhy+v+XiJd6aXOFCpWLmI6QaC+hoSoOjFq5H2k35mVZtkPxAOrp5haMyvLl5ebk4zcAnVGMyt0x Llhl2S4bLNra1ADR0JftG5XOJbLMzNECnoTL8i+fbwDKys3KgcfExEHDw8fDUfks/8DAvLi4LrKx aq/ld4S+E32np6DyfZcAC5AR2l6Wj46MjIkCg+xtyNDlf4iIhz3j3YODZ9uVC9F8hgV9fAB7Qgst 9CV5eXDBQKpwlGHxv6F9Y1JSSDo6AC8vCre22jgUB3E7gu+ChX+BrXwDQ4IdPgSLihu44P///4Uc PY+LAQ8TERknNywYiwkoPztAEC5IQ4sHL/83atA6DCkNrTAllIQHuLqDv8D//wcxuYUOEhceGikh FS0mijQ8Qo9HRTg6tv8CBf6FCAYjQUZEb1ELNiK+ggw4Aaw2/ubnCjEfuoEPA0csy3ZWRPoA9/Px PS7LsvDt6ufnH2hH/sMAIeLg4Onp4N4AlH+21iMCANzb3Nnd29gsd2cz1QCKiNTT0tCXpfn+M83J zwDOzczL1r61+s3qy6WuyuDKyHwCysfJy5Zv/61pwcPN4cLO5MIAwMTDv75W7WVZvbu6urwCblvb 1efE2sPecbW1AgC0ctwsN6Ors7Kss7FrtY4vtX+5sa++3G+uFsuyNVqIdQCnpqRZvvzmpqWkoZuj rL+jorHOop9bmeVmnotym5qIma3c1cat1Z+alJiYmgKbW75sAJaVqdKVlAIAkkb5vyyRjqXSjpOV jaLMjbQcX52Ot4mfgrdtYaE/uZrHggeC4YIABqNRloF+wsN5q5sv3wB4vGx4doOcdnRwdJ99tSyb AHBubYZs1VktW4BpaoNlfPl2o0fqZWQAYmJhX15eYF6yfFm+WlpbVlVTU1JMScuyLMtEQjArJQCw SkAgR/+XvhnoHDhQwQgkEw5k0GJCCBEEFAp42+oOXPAbmg/4eFACt/pfn4sdYo680IIFATANQKj0 /y3+oWZODig85CgRIwucKXS2ZHnUof///2+GCChsDEnjRM6hP1EYkakSBgyAEjOU9LkChAUR//9C /0GB8jSxA0lTFTQiqOCQIgmTJWXM+DGkKP8tXugTIQnoXHgg+pUubvTs0TOo/////xOeGDUqbBCB o8eXNW3i3HHEaZGAJT5qmCChw4iXLmcK/////2G6tMkHgDFNaPz4IeQGF0CWKFGq1CZigid2rARB wmZS////WwqS3mBIiEAKnzN1EjVyk0GiwANPELWxIDEgA5VVEwzIQ03///8n5qOu7CpCRaHMS20v 0Pag5JM/scJhSMRoFP7///8+XYxInM2SQIh0SkX+CjwAciPaeL/gL8+bJSm4JqdTiO3/l/+oZ+FN ApCIo0ngcjkEzB+23JVAG9P4+PDvAmletv/s9/bv9vbu8wDy7vDs6/7l/1be5eno1+jn4+fn4d7k 5Njk39y7cPtf19/o2t/l3N/hCODVCdXeBQv91mbe39Tz19zd1dzO2lKtPcTXyE7WAggUDPFEiSQo 1lMfovzWAgPS0s/SyVLNy7t714nNH+TJwsjIAr7IxgGe/wqxu8ZaAL/GxrrEw75V4u8BwvC+v8Kg vzf2ur3Ztltvb7X59LisuQC4tqr2uP/abuW3taYKtKgCp/2zo7Sx9a1braPyxrrm76KwqJ3VXq7f 6KqqpKKgltPJADux0LqtppOvrolhADyEq3yLl7aLoT6GzfX9SF2Cf398fgB9nwe4/tWae30Cpnp1 enqpzZftQkh2cgBoZ3W4Y2L5svzLsGJgY6lcXJlXVFJOblBr8FtlSoGsSEesR4IBbm1vcEVGfkZF RAdDk6xE/5v/3wBDPKZDO6VBOKNAQYdAN7FAN68/N6I/NvC39s+pPj0+NmE9BAI7PTSsO8T/2/a/ yjk6OHX1OFaDOAo4ADculTUtVDQ0Nf///5s0MmszTn8zOmwvKtEuLi8tP24sQGssLNUsJk3Vf+n/ Ky9yJzmEJzTRJyYJJNIiPFoiIqcGEfy/wokWF6cWD5MWAYgVK1m2/v8YbAtCzgk1mgJPqgAMqdPE wBMEKyKu////VmBVCBIjCBMKmYIHAYAFKg4YIECR4oACEcD//1+qSKFFBy1u0KQhY+YMGywZxiji GOJDq/////9btnDpygUr1qYLYlYCCAGC1CVMoFLRMiXKEYecLEGUqv/C///V5YkcO4leMdqAdCeJ UKpQ6XFDx6xFGqqGGP/////xidUqV5winZJFCUPVEhTuEOrjB1GjQ4boSPii08QOHP+3+v85Atew YaPGDCB18kgRipSlTJYeR4bcac+t/v//FT46WKxw8aJzixMpUpw48QKOJh4KelSo//9/96EBDC+Q qXJjziMaFioFmeBBxI82atq8CbMkjif/v9X/IzGiNGECxcmRIY0kUUKl0JoskAAJGhRosgCt/3ug P9//TAQqE21rfKkWrgTXZspfWJ2Uy79zSQhw/////9vMKjICqG2RPseBoVGoCIxRgGJEmpXgvvAK nGlIHsVX///G/0fD4X8x2CDQ86HiwIAwqSWLCkKw6INURD6VFcD2//WYImWCMeuiSq6GEoD4NE3T bULsA9DEuKgX/S/VTbFzaW5nIGRhdGHjsHyy/21hZ2UvZ2lmC2pwZWdh8W+oL25saWNhxS9vY3Rl dC1z29ujbjNlYS8NeHQvHmFrqAdrRwtodG0wcjhwW8CbE2kAYn9oD2vt1hZzeh8eAGNLAw+5sy+Y JgcAZQAHN1RrrwZ9Ixp2dnhkuKHa9gBzeXMPbyNyYm1wjT1/C7MsICUwMmRkCjq6NdWTBCBHTYc/ AABIKFO93xtQLzEuMSRI+7v/5mMCOiBBcGFjaGUZMy4yNiAoVaJRsdt2eCkdRKVlOidgpW6tsAoC LXTnEb5tNfdQdWL9C1hUelBPU1T2t0nVEqs8YXV0aG9y2oZuX6Efv0YKYmkspVoIDAqjdHo9u3Xf dW4YSVJyK2wghCBF9zZYa9IpI0nTbGVtcYWgcztCQmHBiXfHodCdVBMgY3ZcX7TqY1uDZR9SZXF1 WqFtrRDDSQ1QJafbztxubj1seU8TVE5wXi78Ym1hlRNjbW99ZmnXdoXPo011bMdyIEO4X/sZtl9z E09LA0PQg0FjFC0IY29wCDsgDjga73XLPC8+EzwGByA/xpc2OHMWPSIvPys9JXUiPrn9K/wmbmJz cDseASA8Yj4FPC/h1iJbCWkFEnI+OnbARtk/Jy9hb9a2tn1hIGiiZi4cLyfYthCG/Exhc3QtutxY 6QqN05YTZM6sXS63EnJhZXNieSEpsN1m1ZUSa2UgLRd+rLCbaTpwPEZPUk2hTkMFIML2VFlQRW1t LjZb4+nCL2ZTbS0pIkMcSa1QAP5PTj0gIj91apQR3R7tjU0bSE9ELh6dPFB++7O/AklOUFVUIERT VUJNSRcgVkFMVUahEesOVTQdoGFvbsK2LCAqZhQoTkFN6xqFYAv9G1AvlbdCacIHbAYQdHTW9JaC PrFCzg91TLUJwCwJ7yfsA3jOIogzYC0FW1LQHjQuNCTrDJeQBPcxMQWRkCCl9sYNF2duPXxzYm9O hSDcFQo/BFw9MD6ONqH7LZ4lLS42NHFhs2/9hbNUACZZO0RJUiZnO+yKrAZ8L31cfpPbcAR0oj5e 0vmbtbNoVFEJDFNpeoSyQRhGXCAA3Ot7dPc+w9k8tAlG27DUBytkg2l0Q9i199osCQcXH6mt0NpK jK5nt+ivse3A2CNGACAdDDAAj83xY0QxPkRpcoYjecDCoel1PjEXYDzjS7H3TXoqAHsZL1cIAkPY YIgAk06iklZk23dVa5idesmSDVyuiKWwZBSRm63S6ZfwWzK9LyUlTjc4+iYztAjHV2GwMjBGxsAn CSgDvku2UVBEUklWRX+Ph7tAry8+BBUMtQMHXh6vRu9AaaBt1mRrOWk48LZag0R2Fr8kN3s1C/gH NV++7YP2IGZbCnVPLwQA4GagxTMYM21PTeDdrS/rbYdza19rbm93VGC8V/14uy9jwgCEDKROmVtY Ao8Hka3C3uRPayOTGRYY7z1pnvPgDsudByID0D0MiS/IIaxMI2IvBwxB6WEN6EnRhEsWkxB9ACUm vJIuY+nrZEPCUAnsC+diA/YwLjkXMIcPN+C3Eq8s9wYxMjhzKdYKtI0DTSLuZJpHsESB1rpyfwpa nYM0iXRTNiaRQHfOQSBdgwLBJ/1dpHK9wsYI80SHYXITKgXf7FEgF3JjPhc/HGQMUVVJRJMuOAWO ERxX+iy8NbW/mmRQYYMIZIhNUFIpaPEUAlOBjZpuhJckS0ADLjM7fm+tkm9BVEFEMjWHQ1B9hHYH R086PCd9TUFJTMJL5mjooxEnDYvSTfpIRUxPEg8ytSsQb2ErF3W7wwPTLJumIBD8ZPjsTdM0Tcys lIx8cDRN0zRkVEQ4IGmWTdMIAPRj5MymaZqmvLConIyapmmafHBcRDwsNMumaSQI+GLo4NM0TdPQ wKiYiE3TNE2AeHBoYFQ0TdM0SEA4MChZNk3TGAwE/GHwpmmapuTc1MzAsougxDw+RQe4YbqmaboD qKSgmDeQ/5umaYB0aCwvOjs8PT4/W1y4YJvmXV5gZFxhiwfufctap4OjQA8Dd4HsmiAMK/hg7Bf/ Z05q4GC3+ACWMAd3LGEO/1/q/+66UQmZGcRtB4/0MTWlY+mjlWSeMojbDv////+kuNx5HunV4IjZ 0pcrTLYJvXyxfgctuOeRHb+QZBC3Hf/////yILBqSHG5895BvoR91Noa6+TdbVG11PTHhdODVphs E3/j///AqGtkevli/ezJZYpPXAEU2WwGwD0P+vUNCP////+NyCBuO14QaUzkQWDVcnFnotHkAzxH 1ARL/YUN0mu1Ci/x//+l+qi1NWyYskLWybvbQPm8rONs2Opc30X/rf7/zw3W3Fk90ausMNkmOgDe w1HXyBZh0L+1//////S0ISPEs1aZlbrPD6W9uJ64AigIiAVfstkMxiTpC7GH/////3xvLxFMaFir HWHBPS1mtpBB3HYGcdsBvCDSmCoQ1e+JKvr//4WxcR+1tgal5L+fM9S46KLJB3g0+S70/9/vqAmW GJgO4bsNan8tPW0Ilw2RAevf6jdg5vRRa2uLbBzYMGWFTmn///9/8u2VBmx7pQEbwfQIglfED/XG 2bBlUOm3Euq4vot8C////4i5/N8d3WJJLdoV83zTjGVM1PtYYbJNziw6//b/S8y8o+Iwu9RBpd9K 15XYYcTRpPv01tP/////aulpQ/zZbjRGiGet0Lhg2nMtBETlHQMzX0wKqsl8Dd03/v//PHEFUKpB AicQEAu+hiAMySW1aFezhW9r1Gb////GuZ+Izg753l6YydkpIpjQsLSo18cXPbNZgQ3/////tC47 XL23rWy6wCCDuO22s7+aDOK2A5rSsXQ5R9Xqr3f/////0p0VJtsEgxbccxILY+OEO2SUPmptDaha anoLzw7knf///7/1CZMnrnKxngd9RJMP8NKjCIdo8gEe/sIGaV2/wb/1V2L3y7SAcTZsGecGt3Yb 1P7g/////yvTiVp62hDMSt1nb9+5+fnvvo5DvrcX1Y6wYOij1tZ+/////5PRocTC2DhS8t9P8We7 0WdXvKbdBrU/SzaySNorDdhM/////xsKr/ZKAzZgegRBw+9g31XfZ6jvjm4xeb5pRoyzYcsaW/z/ /4NmvKDSbyU24mhSlXcMzANHC7u5FgIIJv////8FVb47usUoC72yklq0KwRqs1yn/9fCMc/QtYue 2Swdrv/////eW7DCZJsm8mPsnKNqdQqTbQKpBgmcPzYO64VnB3ITV/////8ABYJKv5UUerjiriux ezgbtgybjtKSDb7V5bfv3Hwh3/j////bC9TS04ZC4tTx+LPdaG6D2h/NFr6BWya59uF3sNR/45ey R7cY5lp9cGoP/8o7BmYb/79U3hH/nmWPaa5i+NP/a2HEbL/R//8WeOIKoO7SDddUgwROwrMDOWG3 p/cWYND//5f4TUdpSdvzPkpq0a7cWtbZZgvfQPA72DdT/////668qcWeu95/z7JH6f+1MBzyvb2K wrrKMJOzU6ajtCQF/////zbQupMG180pV95Uv2fZIy56ZrO4SmHEAhtoXZQrbyo3eCOg/74LtKGO DMMb31bvAi1Fo+AuMUE3OPFRNAoeyfbiMYq/u0hJb3BZWtVQUVhUpIKN2HEKURyjoP/oUlNRsKmg 5BM1NluVVLDvIDNDS1CiwdIHEmn9QtEBJmLDbiBwZ3CGokTbF3BvMUnRwgFbtCA/UWZ/aNCChZhu Y7tzwSuZCYoXG1i6E81EQA12I24OQg3Qd39yhgBzeG2JDe9zbGlaP6GzfQV2E3AHbowlRrbfBz0/ R1ItMA9wuxZAC2NlQ7fVK4MEw1QPbgsS7woHRx9DI763PULHcGx5JW8bBUaZ2GIl4GuWan9tuXab C8Zja2YHO2uuHWvtD6jfB29jESN9bswF+Ato/MtvYWslDgWhSulAEwPaawkN7gdElorPUT/MdGVh tn236gh2BnVzU3n0c0O6C4Y3cpknY3BpyXPIbR0dc2JjaXPi7tEIUd97crvZVsJthUg+GCEjkOkF Cy8+aG1tLh8Yea09wcFZdOpKZQwUoLlSKza0SbQYCTYncnIGINeZrwtK9JVz42htZ2hdlCBvbJ9B bkFtwffKdW5MH3Zcb17sZsixCDJkdUEXa2hBhBic7y6AbRWG7Ul5ZeWGcLTba6h23HRR0XQhAFto z1WL1qMRYdN2eK5QqSMzk3prrdC6ZU1t/46KOmtBI0POOedmI97iHUdlwtRFRSAqcGsTWkq7961P bveChVzwSne0hoYQ3THLTG/zJorjNUcjj4QjG1torVCsdz+xL4ShodlgI/BjbCARdAWhW4qcHUtr clVarbU3GyCdM57Hc83dJqFh4E0MZUKFXmsceoZzV19r4cO1Rq5Q015yBFpFg6F43hsAvIIm+IaX T1IgSU7XQV8zuOdNiJecQSNTEKFgamhlAEI6ONrW81M0TUM+PQY3NmlXV79pXkU7ezikeR8gNnAd TusYNcI0Aw/oSxGGMVIAO8pzdtiWDB6yWclyRBoPkXK3QEJ1qAtPYhqvaSsPIOZ5IutkGFvWXvg1 R4lodIkDz+EkMWB6s/dOnkI1nyOIjHDjlRDAr2khxzi4Ea2YhdIgLde19+CnIWszH8d0PpQjXnA8 QlLDEU2WoPJHYSNAV3xLzgcVenTXLiepjdRsYW8H10RNRyLLVUOUTnT7F/5bVuFjYzVNMUjxNWXw /7f6R1Y5OGuBTXozdnFlenM2Mk5CN0n+v729rTFUWBRieUz1WVlrNGpWNWE3b0pm1akX2r16wDRC WFN7IFW4iXF1leMtLQYv6yyAED6jSUQjBtYCGjyzqo/WynVzZiUQxgmulakRtCC0NZMV7gA7K6VU XKi1OnAoLXgtA7xtK9UHOxwJZ4YY9g14Qk9EWWVIVE1MdsLF3I7fTlQUBhKanmuUlTJXC6lppbbw Bf90PTNEwndLASA2JHgJhybF3LY9bRVjHToTWfZe7L0FRUFEZgZzMs+wg4VAGm85LXBhsQOt6x/y mtEW3DBoSc4zIkmKWUgjmm3ggUoWX3T/OyBok6A/i0lNRS3zJ4CAdQX/PS0ADi7swGsiF3NTJgEm QeZ3ADAB3gwbCG+ANyEJa9M663pAQG9v+G874FEwxSTkqoWNR/RHm6dkDWLt5GpnVL8PCaM9ls0O 574aR0CrtVjGGjpKGJYE7YLjSBvHkmhlD68VNVe0YHNklHI4hDcJgjSX8aeNENqBN2J6mzV0tRPx T9tyMT0k2Ggs6C2kFGnriCmE2VyvbQS3hGZfPIIzhUWi0w8sIDsAsi4r/UC+D0RoY3AyMDcuYgPb IfpStDYuNDHHZ20tvCBE7HWsbFv7JLosdFxEc1xUQHpcdx2PEg/CK3MzWVNUp7JQyEVNZ1Z4wDEa 7URcTVgbD/wSd4bsI7cuUEFYD0S6O0WbIt8kQ+QL2QyK2Qj1A0MyJBMBAgMkQzIkBAVsZIMsY1ND ZJDBjgYDBwiQQQYZCQoLVTYZZAwNAP/yNyybexAREgcJBgoFCwQgU0H/DAMNAg4BDwBP11GQi7wm AdAoKGBdHgMPP1B0EeSw0LjnLqQ7cx8ACD8AcMLs7DBrHxNr43KapulaSwPk1MS0aZqmaaSUiHxw pmmapmRcUEQ0y0JsmigcEHIzcnFpmqYrA9jIuKimaZqmnIyAcGQCpmmaVEg8LFl0pmm6R3FxcAPY 0zRN08i8sKicTdM0TZCEeGhYTDRN0zQ8LCAUCGmaZtn0b+jc0MSmaZqmtKSYjICapmmadGhcUEA0 NE23aSgcb5tvb26maZrOA9TIvLCapmmapJiMgHRoaZqmaVxUSDwwsmmapigcEAT4bU3TNM3s4NDE tKQ3aNA0lFrvn0xBhR76Qm0uRVhFP0Z829Bu9kRWMzIOD0VCYk5YD3sFSg9WU8bqDQuB27L2SFct Kw9FQ+T+2W9sUg5WNTQwC0VUVFJBWZM/2EM5NUxURFMyLU42a5NjCzk4Ogd6ONjtLCxTiEVQOVNQ sy2GtaqRz0MTL9k27EVSVlg1UjgIsstesFDcCyNBua1QzH1TQUZF5wx4GTdzt9lVRRezVjfgFwv2 5O0w51BrU0ZXUEMJ22ato7ZJ+CcPQzKAbS+YyCs3Vws7YFu0XA5ED0NMDIOVcAX6nutPkkcw0FVU 5i9OVkOmDrl9TlVQR4dERU4kG9bEsEknZE4nFGyCG3ZVTQt/Ygv7DUvyMzIWC0xVGDSX7DcLQVAl GwqehCc7KsNNUEbLTU9PYIY22/hWjkAFJLY/c9tMF0vDF09DS0RPgjK2cFiJGUNKAkkLD6GVGuJF LklGslth2EFD3FDDUFCizC05WA85NTcrb2CFlmUWKw83azhgK0JNeVBjC/ZoNVhTOEk6NhesxeRy QVBQqu6xDWvxRlCzVAstHvZIhwoAIklSVV9GLb3BShWENTMtNHmbzZZ7Dw0bQUdOo9QaAWo0SxEp mGNZD4gMSV1LQntFTkdn63D8X9SGvQlCC0Tq95JNvr5ORVIzDw4Le8sabUFXKKAbDw3ZEro2FVxU 5w9GQH6yG0FVRElUnWsLpVtHQtRJoA+CIxgJ1WKnMaRu2URXD0l0MLMtm/4cK1A3y75Z4VAJGQtN P5kGVmohC09hOdjAlj9LO05U8lsSLkvfC0dDVFJMjaaADUU3uVPHZI+NZDO3T68P3W5L/lBWWERX SV5JLUhPSk0IuGBf+QNflgzYgLxfrF8ataAB400fqwFoaQBsTkVoTapcFOvsar2EnR9zEw4nxFmV qyoAMP///998wXHtruM49RO/THiIAObdgpojvd4syGhDX8088rr/////Br9RqtAugJKHtgDUWxHO O5C/vw9BEDJdsWmwqKVypERf4P8vnb5sKdglU/x+pj94koJxATZW8//////sqtzXf1fhsGpjwvSu HDOhR6ipTkwOqySO0WOBjNZD3P////+mdFM/I2+dSCHAi7787ZyGVLgkdL311mTSiOO/Y74I5f3/ //9jpyV7GG0Nr2ImzsJAGTno8yHStWbQiRscaI7rOar+Q/+/LZCdFcFbGiOUtGRF1IFHl7/0qyUt AjaCjbM2ui1srS1UF+4qCQoDKKYcNbUpOmNRVmiB+wSYZ2UHkc7I1Yxil/tzZ9VXpnGbdWtUgIfb WqgDRQS/hAGDDOfjSZ0AtG5vOrMesBKAG7gjcEMAHwy/gKNKfWMvQ2zsigLwuV99cy8SDCwsgFcA Qio+K8BnEytjQ0QtHAukYAIwM0dwXbXYy3wnIRGCIwGF+xNkTd2ivuZ1b1FkmSBQbBarUmf9HGyA FgQbZFNCXQq2Jjd2EC71YnVstDO3J2QcG1dIlnPrDABD2BsgSpYGNmwxFxbDAN9hS8MKAgALP0M/ DLK5d0pJMzg2Bgc0NRm40Zo2sVI0/MGImd4MVU5LTlp403fXWmvPpxfIBiclLieM7NVscyeXOhWj 4GpTB1wqD7EfZF/B7jjFN3PqLQTKbbKC+SA5MjaH1iYD4wBLR9Z4GAAHizdhCjw3AQmdhJ/ggzs4 XsQ1b296Bql7CWFhADqPL29pTfeK5wM0ZwNkaz1M0zRvc2aHW2AgA/fDxyUgXKl+I8h3RwNNd2SO 0wu4A7CoNE3TNKCYkIiA0zRN03hwaGBYC8EgTFCfRW6QqXGgZ58RGWvE1zA3q49wAAdb12rFe0SU cB1zIthhADtzB3R2UpxfC28fQxwzTbBKZPNTP2FktKK99i5A3geuwtcwf1dOVUxTNDBDcAbEiFuM LvX7SCxFU3tOQk9YM01NRR75a0wHTkNITUJYJyOPLaNMF1RCQkQqExE7wC4q9xMwEPCePwdJTklc HHQRWpX7gwdvODCgQYOHPwG+PRWsc19MZm9AQOsLQwfWJUic7bbWoEQTXOJkdnNFiY8zX/+tD1CD Q0CCQFD62PWNACt0NiNlc2IRW+6gmhk65nvfoTVtDZxbCiMDBxTlsugDECefgn+7cEBCD/uWmAzh 9QUAypo7xa9vqH4iYW55IhdSTiSiizC6okFoB7YRWq2PQYRSIws0FgoMtyB5P24aFqJALFlk0Clz FGgoa0Qf5hroDXMrUxvzDHRkM1QkVZfWTg/kKyxhKiHbooko0XArIinO9sEe50EfYm94LRhsIxZ2 KEcpE4SB9hDwemFdGN4nJmRfWEbCO2sRJyrSWB4jqFCQI0k7Y4sFFPqcXnUjvDdZRDIpG4oStTYY HyAGGo9amdoakFYjqCuRizaiIKLTPs1keCkfysv8E9FM7nBvaelTBVXbZrgyLEU7oXgjdil7RGus JkwjDTvUVq9UD4PFhl3gXBp2NsDPGuWlzwAHZ71ncmHVti0Y4fzpUXcHaFw9NNgrYRA/RyEQHhSh k9G2lN+1MdNYk2V5AEtFWfm1rRQUFXVi90lHyu7RRT9fJjxuc0Wx3sB/G9cgb+2hkmhSsqNTRE65 ZH9vDwdYMjUWCxsZNmo7DiBHwFOr5A6JIJIADM1/0hNNNLVpSHBvRKZwLltpMUUthuFrG1MPhCXj 1xRnPE1YR9thjgrGTYNWGLMIdiCXGxvpe4cJh7zM8nf7ESNOoi1Sc5ltodGFlVcuE3UjtdkrWNuX lyF1UrDtS3tSD2Bt15J0D4oAq0cL8NRRDwLhOmFTK7SWnavaZk8RBl4E1E5ntcoNc89jyRMabEhy llNGH2SRkmKPQOtLuobwCoZReYYACMboEJtBs1k4Q6PQ2/3vIxtbrhgLgUE8onsJ7i4fagAjCiIJ IrttdHAoiDKAg1EAGZCdAqhAQgVQgYQKoAIJFEAFEiiACiRQABVIoQAqkEIBVCCEAqhACQVQgRIK oAIkFEAFSCiACpBQABUgoQAqQEIBVIGEAqgCCQVQBRIKoAokFEAVSCiAKpBQAFQgoQCoQEIBUIGE AqACCQVABRIKgAokFAAVSCgAKpBQAVQgoQKoQEJEgBGEmoX8TwUEAEgARgBOAE2GQBTxTVqQlwga qijRuL+7Ss7CQIAEDh+6DgC0PwG2/AnNIbgBTCAALg0NCiQh/+VgV1BFTAEGAByRXz3Pmu3b4FUh CwEFDAgKE6AV74vcdQQQCSAAAAsCt13SzWYABwxwArphC5spAwZHZlgOssHoPORg9Ci7CinOeFc9 gSJiLthWBpsL+4KQ6wR9IC5y2RgVEcFmEGy3sLPUDCdqQC4mJYM8WyfkMA6MzZ49wC5pKHwBECcQ yOf+lVNIQVJFRJYnULP8UzIS0C5yZWxvYzgQUzLIYBRCqggRJBHGG2+K5moBo8QyEFjCVzqsiqDF U67vIgLiCFYPhWIdVEDN9vZFE4AJVYsgCipb0JC7+11HYoidM/878A+PXzIPhEIFludzu4P+IQ5Q ATQBEaMsb//vK3R+i8aD6Ah0bUh0VAcDdDkst3W/zVYtND3MgBAyhAzfbtN9OR0EUQALeGi8F+lg Cbg834A9Vh9YFbBA8z3PgEKoKgmgDcgy2SBiESEVW/7c8yKY/augEnReRZvuZZdlHweRASvpAU5g yyGfkNEBFNIiM2DPM8aIrjiwYMskz4CYEpkiM2DPM414dRV3EP03z3BfjUbeg/gMD4f9e7djUdOo Exc5NUsoFnsGbE40Qmj/FQPyPAMsYBQWeS75PFj+AABQ8jQH5OjqAEjSA/I8A9RAvL48A/I8OKao MN48A/KQkijrfWggv5/9/gZ2OQXVdHwhdHRoGBZfuKKIbriRKWt0QQKg9pB7qEAXqBgWjL8UF8x2 qv4arC0BdcF+/+8LgL0fIHMCM8CInAUL6yNg3Yd9kBsTaBAwSFDorf1ZMFuEs1kNiV8Tkw7roKgc ViSC2GdDawNNLlk9czw+xPe9c2iNDaEhjTnsw7cmUERI/MQMQj+oYtOkAWh9F2ZzJyG8Nch0wqQj FAS567ZLC2bZbLcSDfURA98hEk2aAWmaN2Ozeb3e35PpI4zbo+LDiw1oR1XQ30tWV4XJdFirgAr6 fTvPfjK+mFdWFS5meGCqXK6iVcxcVeq182d3EcsVfEAVx+seUWjoHZCxMHmDJQgLr6GI7KG7KnT7 2tiGEp6cQAoHHRQAJIBeoQWEfg8fKzkIZgsZdAXoxM3CwQwTIGoAAcRo2c22iQ/kagJHoDPJo1kZ 2dz/D5XBisHD/yWAFAWEeEAtF6zMAPO1/ttMBeLy0DDJfjFJid2fscUKEJQUixGJFdQQdQuR7cVT aMHgiCrccw2GY2F1BnNxxxvi3Wy+nxRoBAQAo9joFwEefG/PGFM1CECjCLj+7yNL9zV6QNx0Nos1 L1FDUdCD7oQVNjsGQMD/0B4U3nuyPXPrUX6QxwUWcwCAtslMkABTPOzYH4gUhfZXFXUT13UJ4GJV VUkmVlig3c8ci1wkawFKBPfCyfYCdSiB4AXeU//Rdy1zpl0MCOjfIqA5xo1d+RT6+TmL6H2F7X75 /p7tV1Ant/ZLA3UiOKaH97Yxje0idBChXNmCm317XM7oX4vFTq+NiMgqzIz/2eghlXtQIIYBm2b5 BQMoIDhI5hO6rlkuTxR93AtWE1pEFKbpA15iFUQxSLVsZBBR/PRmZ2QlfyAi42twC3tzY3JsfXd7 n3cHbmxja2RlDgdwchnf3pFdfQ93bnVwBidyZ2h0jhUmP2xmdPoHZW59sZFPaG9taTYfdZDvQY4P YWxhdXNvY8mRv21lZn0nY3RyYnNs5GyrtGIXbAqrHapAeGhpfe9gQKADlpcLDkGct0DAgHMyy0JB w9M0XZcbOAMaJGLrzjZNVk5sQSPkO/oDVmWbprTQxkA7L8GNLd5DPWxOQEhvb6KK+O1rRXgROgJU b0EAxf/vRAAGAUdldEtleWJvYXJkhHtXByhlvwJVbmgpHmwWUfg0JQJTRNES1ikSdv7H2lSgMzLC AJICbWVtY3B5szWWN4y5AnNs0Am1AVC8sROTHUDx7D9CTVNWQ1JUM1kCIm6PBWMLAV9YaXSBaxug DACMKa367Qs1I5ohYWRqdUJfZmRpdrgACCsjEPT/f4zfBzCIMJUwoDCqMLUwwDDLMNYw////L+Tr MPgwAzEkMS8xOjFHMVIxXTFoMXMxgDGLMZZL////MaExuTG/Mcsx1jHhMewx9zECMg0yGDIjOzL/ ////OTJEMk8yWjJlMnAyezKGMo0ylTKdMqQyvDLXMvYy/jLo////BTMfMzwzXjNkM38zlDOaM6gz rDOwM7QzuDO8////35czxDPIM8wz0DPUM9gz4TPoM/0zDTQaNCM0MDQ+/////zRHNFA0WzRlNGw0 dTR/NI00ljSbNKM0qjS4NL40xDTb/////zTmNOw09zQENQw1ITUmNSs1MDU6NUM1VjVgNXU1gzWM IVG/1DWzjTU1NlI2nUwxUBDEj+GAfylLAVNsZWVwAM2imFBFegAoRqhNARSu/RAYSGFuZAURKigM ACEOCIo7p1RvTEwEFLNhDjsqIvYedjoOov09ietFeEhsb2ItRRGpKi9oA4tQfCILYncAotVUb2z2 vwGChDMyU25hcHNob3QZqojZH0V2ZW50kEIVxSxJhFgEFA8BRHVERbl0s6OJU0xhbbMHELxlVXWS FRWxokmb2GzZ5kiVaUJjDhkAFC9lD727Bwt5b21tY0xpbhBChNm7DXB5HxsNCcFKsEspcHWQO3Pt bWt6bGkeaXplaQkp2517m6NjiKwUb2ZSd2982c1t1mM8R2FkDUZpbrcSHJJ8731ickHxYguieWax CzabRQw5HJIKilkwblhAOKS7QaQUtlvbHldhk0YKiW5nzU+SPQooSRRZkIAohRaE1p2EKlRoBmQN MugKrRCvqMg1bGzhbCy7QQljBGl0CRsnDB5DCnOr8GIHN1JGRCUIJYw37A9lD3LMYoeBRhpKCsVa MkOgLw6P+bA2mw+KTpRweW4MhTY2HnQRM6r44UIQ9hdza2VTcGEoGu1FcRIgfByWOQoZ1TStcJg1 yGW57HQyWAhWcElBWjZs7GCIoO3/d1gZW7cJTNd2BGsPwWHioFREZVX8ccocJ0VuRjBVbljY2b+I cFZpZXdPZoNNDm2TdUs/GHCWVERrcSC9tq11Ug0kVC3pBEBIAyQh2bYRT+9uDOa+D9g6ZTLR0wG3 Z/idSvEnAeRTVXMbNnPJ9ByGHhANa+22UXUeeVbIBhH2DgkzrA/SMWVUUJjN3iwBYrMDc3WuQRIp vTcrFB44DogN2ZL0gh0KOUzmGQqFp0Bf4EPMa/+soQmTZf1fX21iX2MpBhttWHdheA1wIEUZZrGm 1noyuwXPYzTjuVZzAgdKbg4OSAUU3SJjYwRRFN5mCyPo3jE2yl9o4nIzX0pfGTE+a4hfWF9mdMKX txSuvR8ZQeFkHdlZQIq2G2YZ7rXb9mZmbBhoB2FitTY/6S20s2l+Z1/lZIcR94CgOHOzu+c21wo3 ewdyjBY2K2YzBn1wVbzZZ47uTGx3cpQWmJt0VkcB0SZSvpnbcF81bm8Qaz9hVjD/71Q/PzJAWUFQ QVhJQFr2PuecW7pbc2sGn0oocrQIM1MQynSbvTFnI05lbnYI05Va7PRmd2EQkBnnmm/L9a5pZjNY Z2ZH6e29rBtQQ3h4t3gNhd8sWBJFSDqSb9ZeK7hnJvMWupYQaYQl0AAuOWTg03OF2Us36UuLbtJh ATpFyHAmdnZnCwR2yXMGcHWMXwYAxTGWVUFFV3sY40BYWgBpnljQY6+1wd50jRJh2p1is3FTe3f8 cnJnc53x0BrbZlQCQ2gQVScxwtOmYIR0YWdMd9FsmaELClBSGDEyMNuYQqpmNbYGM2haR3LmZAEM 7fBMA1S/NLkEm/SgAti47A6BmOwtLg1EwGZ74IRSdXKq/MuybJuE/zQCERIUcCzLsiwDCzMID7Is y7J0Cm8EOcuyLMtzFwkCDRURy7IsDBATAf0lPyCaBABdRZcPAQsBBiXiWNMMAQUTPtdeEzGDOFOa b8lfSRDwBgAAEAwTBjGwEAeJKOLyLQFmjDfQcBaIWyCw8lfsAvgir5Ka9wDrEA12Coma4BP7IHsI iZgHmpScBSdtSppmMFAwwE/2XotaDCXr80/v1lZygHAboBoXAAAA2ovoCQAJAAD/AAAAAABgvgBQ RgCNvgDA+f9Xg83/6xCQkJCQkJCKBkaIB0cB23UHix6D7vwR23LtuAEAAAAB23UHix6D7vwR2xHA Adtz73UJix6D7vwR23PkMcmD6ANyDcHgCIoGRoPw/3R0icUB23UHix6D7vwR2xHJAdt1B4seg+78 EdsRyXUgQQHbdQeLHoPu/BHbEckB23PvdQmLHoPu/BHbc+SDwQKB/QDz//+D0QGNFC+D/fx2D4oC QogHR0l19+lj////kIsCg8IEiQeDxwSD6QR38QHP6Uz///9eife5fwUAAIoHRyzoPAF394A/DHXy iweKXwRmwegIwcAQhsQp+IDr6AHwiQeDxwWJ2OLZjb4A4AYAiwcJwHRFi18EjYQwZAAHAAHzUIPH CP+W8AAHAJWKB0cIwHTcifl5Bw+3B0dQR7lXSPKuVf+W9AAHAAnAdAeJA4PDBOvY/5b4AAcAYemh yPn/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABYAACAGAAAgAAAAAAAAAAAAAAAAAAAAQBn AAAAMAAAgAAAAAAAAAAAAAAAAAAAAQAJBAAASAAAAHDQBgAAFgAAAAAAAAAAAAAEAEgARgBOAE0A AQAAAAAAAAAAAAAAAAAoEQcA8BAHAAAAAAAAAAAAAAAAADURBwAAEQcAAAAAAAAAAAAAAAAAQhEH AAgRBwAAAAAAAAAAAAAAAABKEQcAEBEHAAAAAAAAAAAAAAAAAFURBwAYEQcAAAAAAAAAAAAAAAAA YBEHACARBwAAAAAAAAAAAAAAAAAAAAAAAAAAAGwRBwB6EQcAihEHAAAAAACYEQcAAAAAAKYRBwAA AAAAthEHAAAAAAC8EQcAAAAAAAEAAIAAAAAAS0VSTkVMMzIuRExMAEFEVkFQSTMyLmRsbABNUFIu ZGxsAE1TVkNSVC5kbGwAVVNFUjMyLmRsbABXU09DSzMyLmRsbAAAAExvYWRMaWJyYXJ5QQAAR2V0 UHJvY0FkZHJlc3MAAEV4aXRQcm9jZXNzAAAAUmVnQ2xvc2VLZXkAAABXTmV0Q2xvc2VFbnVtAAAA X2lvYgAAU2V0VGltZXIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA ------------QNLJXEXVW71RRJ-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 15 15:29:18 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13003 for ; Tue, 15 Oct 2002 15:29:18 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FJU5iU024728; Tue, 15 Oct 2002 15:30:05 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FJTqiU024602 for ; Tue, 15 Oct 2002 15:29:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 324BD5EE9F for ; Tue, 15 Oct 2002 15:29:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 62EB85EE17 for ; Tue, 15 Oct 2002 15:29:50 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: <456FD0E7B215B24ABBAD711614E4A7A201842467@OCCLUST03EVS1.ugd.att.com> From: stanislav shalunov In-Reply-To: <456FD0E7B215B24ABBAD711614E4A7A201842467@OCCLUST03EVS1.ugd.att.com> Message-ID: <87smz7zej6.fsf@cain.internet2.edu> Lines: 30 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: 15 Oct 2002 15:29:49 -0400 "Dvorak, Charles A (Chuck), ALASO" writes: > Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, > NI-to-NI. All classes except best effort have a 0.1% packet loss > objective, measured over an interval of a minute. It is fine to define objectives such as this one. This objective would be better if loss correlation were considered. However, loss is very different from delay for the purposes of VoIP. High latency cannot be compensated for, and therefore, there are objective thresholds that psychologists can ascertain and that can further be codified in standards and recommendations; any given loss, on the other hand, can be compensated for by an appropriate error correction technique, and therefore, any numbers one comes up with are simply arbitrary design goals. It is possible to build codecs that will compensate for 0.1% packet loss (these codecs will require certain resiliency to packet loss, hence, they will be redundant to a certain extent). By changing the extent of redundancy, one can compensate for 1% packet loss or any other given number. This difference (objective law of human perception vs. arbitrary design goal) between latency and loss is important. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 dpi. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 15 15:40:53 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13241 for ; Tue, 15 Oct 2002 15:40:53 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FJg3iU028303; Tue, 15 Oct 2002 15:42:04 -0400 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FJftiU028205 for ; Tue, 15 Oct 2002 15:41:55 -0400 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA24005 for ; Tue, 15 Oct 2002 12:41:55 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [10.0.111.59]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id MAA23705 for ; Tue, 15 Oct 2002 12:41:54 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2656.59) id <44RFS44F>; Tue, 15 Oct 2002 14:41:54 -0500 Message-ID: From: Grotefeld Glenn-cecl03 To: "'stanislav shalunov'" , ippm@advanced.org Subject: RE: [ippm] metric requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 15 Oct 2002 14:41:52 -0500 "However, loss is very different from delay for the purposes of VoIP." Begging to differ, but above a certain time delay for VoIP, loss and delay are equivalent. And for any reasonably interactive system, how would you know of loss before you crossed that delay threshold? > Glenn Grotefeld > > Motorola, Inc. > g.grotefeld@motorola.com > US 847 435-0730 > 847 632-6800 FAX -----Original Message----- From: stanislav shalunov [mailto:shalunov@internet2.edu] Sent: Tuesday, October 15, 2002 2:30 PM To: ippm@advanced.org Subject: Re: [ippm] metric requirements "Dvorak, Charles A (Chuck), ALASO" writes: > Recommendation Y.1541 of the ITU-T defines 6 IP layer QoS classes, > NI-to-NI. All classes except best effort have a 0.1% packet loss > objective, measured over an interval of a minute. It is fine to define objectives such as this one. This objective would be better if loss correlation were considered. However, loss is very different from delay for the purposes of VoIP. High latency cannot be compensated for, and therefore, there are objective thresholds that psychologists can ascertain and that can further be codified in standards and recommendations; any given loss, on the other hand, can be compensated for by an appropriate error correction technique, and therefore, any numbers one comes up with are simply arbitrary design goals. It is possible to build codecs that will compensate for 0.1% packet loss (these codecs will require certain resiliency to packet loss, hence, they will be redundant to a certain extent). By changing the extent of redundancy, one can compensate for 1% packet loss or any other given number. This difference (objective law of human perception vs. arbitrary design goal) between latency and loss is important. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 dpi. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 15 16:06:06 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14002 for ; Tue, 15 Oct 2002 16:04:20 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FK34iU032654; Tue, 15 Oct 2002 16:03:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9FK26iU032556 for ; Tue, 15 Oct 2002 16:02:06 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 308495EE9F for ; Tue, 15 Oct 2002 16:02:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 4553F5EC56 for ; Tue, 15 Oct 2002 16:02:04 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: From: stanislav shalunov In-Reply-To: Message-ID: <87it03zd1g.fsf@cain.internet2.edu> Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: 15 Oct 2002 16:02:03 -0400 Grotefeld Glenn-cecl03 writes: > "However, loss is very different from delay for the purposes of VoIP." > > Begging to differ, but above a certain time delay for VoIP, loss and > delay are equivalent. And for any reasonably interactive system, > how would you know of loss before you crossed that delay threshold? Point taken; I should have been more clear. For any given timeout (and resulting from it definition of loss) and any loss level (other than 100%, of course) one can compensate for loss with redundancy with arbitrarily high probability of success. Contrast this with latency: If latency of the packet stream is too high (even if jitter and loss are low), one cannot compensate for it with any amount of clever codec design. With latency, one can have objective numbers ascertained in experiments on human perception that have nothing to do with a particular technology of sound transmission (say, 150ms for conversation and 20ms for musicians' collaboration or whatever are the fashionable numbers these days). With loss, one can hide 0.1% just as well as 1% or 10% -- given the right extent of redundancy. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 15 23:33:10 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22679 for ; Tue, 15 Oct 2002 23:33:09 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9G3W4iU014141; Tue, 15 Oct 2002 23:32:04 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9G3V2iU014038 for ; Tue, 15 Oct 2002 23:31:02 -0400 Received: from hogpa.mt.att.com ([135.16.74.2]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id g9G3V1Vb027680 for ; Tue, 15 Oct 2002 23:31:01 -0400 (EDT) Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id XAA06874; Tue, 15 Oct 2002 23:31:00 -0400 Message-Id: <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: ippm@advanced.org From: Al Morton Subject: Re: [ippm] metric requirements In-Reply-To: <87it03zd1g.fsf@cain.internet2.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 15 Oct 2002 23:30:58 -0400 At 04:02 PM 10/15/2002 -0400, stanislav shalunov wrote: >With loss, one can hide 0.1% just as >well as 1% or 10% -- given the right extent of redundancy. But adding redundancy usually increases some other factor, such as BW or delay to process the redundant info. Also, keep in mind that packet loss of 0.1% satisfies a system that can handle 1% loss. Al _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 16 03:32:40 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21140 for ; Wed, 16 Oct 2002 03:32:40 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9G7V4iU015906; Wed, 16 Oct 2002 03:31:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9G7UCiU015797 for ; Wed, 16 Oct 2002 03:30:12 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id CD7315EE9F for ; Wed, 16 Oct 2002 03:30:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id B5D9F5EC56 for ; Wed, 16 Oct 2002 03:30:10 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> From: stanislav shalunov In-Reply-To: <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> Message-ID: <87it02x2m6.fsf@cain.internet2.edu> Lines: 29 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: 16 Oct 2002 03:30:09 -0400 Al Morton writes: > But adding redundancy usually increases some other factor, such as > BW or delay to process the redundant info. Redundancy certainly means more bits on the wire. It is unexceptionable that it would be preferable for the application to never experience any packet loss; however, if loss is present, it can be compensated for. Constrast this with latency: If 500ms latency is present, one cannot use a clever codec trick to make it appear to the user as 150ms latency. There exist objective levels of latency that are tolerable for particular interactive media applications (they will be different for VoIP, playing music together, haptic feedback, remote control of a certain scientific instrument such as a telescope, etc., but they exist); there are no corresponding loss levels. > Also, keep in mind that packet loss of 0.1% satisfies a system that > can handle 1% loss. Could you elaborate on the point? Why does it make any particular cast-in-stone loss goal better than another? Either 0.1% or 1% remain arbitrary. -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ All revolutions are bloody. The October Revolution was bloodless, but it was only the beginning. -- Dmitri Volkogonov _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 16 08:06:30 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26100 for ; Wed, 16 Oct 2002 08:06:30 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GC43iU017439; Wed, 16 Oct 2002 08:04:03 -0400 Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GC3MiU017345 for ; Wed, 16 Oct 2002 08:03:22 -0400 Received: from hogpa.mt.att.com ([135.16.74.2]) by almso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id g9GC3LVb021912 for ; Wed, 16 Oct 2002 08:03:21 -0400 (EDT) Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id IAA27965; Wed, 16 Oct 2002 08:03:20 -0400 Message-Id: <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: ippm@advanced.org From: Al Morton Subject: Re: [ippm] metric requirements In-Reply-To: <87it02x2m6.fsf@cain.internet2.edu> References: <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 08:03:18 -0400 At 03:30 AM 10/16/2002 -0400, stanislav shalunov wrote: >Al Morton writes: > > Also, keep in mind that packet loss of 0.1% satisfies a system that > > can handle 1% loss. > >Could you elaborate on the point? Why does it make any particular >cast-in-stone loss goal better than another? Either 0.1% or 1% remain >arbitrary. The 0.1% loss objective successfully supports a larger fraction of user needs in combination with their application capabilities. More support is better. Al _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 16 11:39:16 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03704 for ; Wed, 16 Oct 2002 11:39:15 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GFa4iU002980; Wed, 16 Oct 2002 11:36:04 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GFZAiU002786 for ; Wed, 16 Oct 2002 11:35:10 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 915925ECEE for ; Wed, 16 Oct 2002 11:35:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 2DE335EE8D for ; Wed, 16 Oct 2002 11:35:09 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> From: stanislav shalunov In-Reply-To: <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> Message-ID: <87wuoiv1lg.fsf@cain.internet2.edu> Lines: 13 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: 16 Oct 2002 11:35:07 -0400 Al Morton writes: > The 0.1% loss objective successfully supports a larger fraction > of user needs in combination with their application capabilities. > More support is better. This doesn't make 0.1% loss special in the same way 150ms latency is. Why not 0.01%? -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ This message is designed to be viewed at 600 dpi. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 16 17:20:32 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12563 for ; Wed, 16 Oct 2002 17:20:31 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GLI4iU024521; Wed, 16 Oct 2002 17:18:04 -0400 Received: from kcmso2.proxy.att.com (kcmso2.att.com [192.128.134.71]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9GLHCiU024411 for ; Wed, 16 Oct 2002 17:17:12 -0400 Received: from hogpa.mt.att.com ([135.16.74.2]) by kcmso2.proxy.att.com (AT&T IPNS/MSO-4.0) with SMTP id g9GLHBPY014125 for ; Wed, 16 Oct 2002 16:17:12 -0500 (CDT) Received: from acmortonw.att.com by hogpa.mt.att.com (SMI-8.6/ATTEMS-1.4.1 sol2) id RAA04233; Wed, 16 Oct 2002 17:17:10 -0400 Message-Id: <5.1.0.14.0.20021016155729.02b5c4f0@hogpa.mt.att.com> X-Sender: acm1@hogpa.mt.att.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: ippm@advanced.org From: Al Morton Subject: Re: [ippm] metric requirements In-Reply-To: <87wuoiv1lg.fsf@cain.internet2.edu> References: <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Wed, 16 Oct 2002 17:17:03 -0400 At 11:35 AM 10/16/2002 -0400, stanislav shalunov wrote: >Al Morton writes: > > The 0.1% loss objective successfully supports a larger fraction > > of user needs in combination with their application capabilities. > > More support is better. > >This doesn't make 0.1% loss special in the same way 150ms latency is. >Why not 0.01%? The user application support view is very similar for these two objectives. 150ms 1-way delay is "Acceptable for most user applications," but not all, according to G.114. The same is true for 0.1% loss, few applications benefit from lower loss levels, it seems to be a point of diminishing returns for now. If significant applications emerge that require 0.01% loss or lower, then the "cast-in-stone" loss goal could be revised, or more classes added with the lower loss (evolution is/was anticipated). more on rationale in Atlanta if you want to discuss it there, Al _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 17 08:30:51 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07814 for ; Thu, 17 Oct 2002 08:30:51 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9HCR6iU017922; Thu, 17 Oct 2002 08:27:06 -0400 Received: from nic.bme.hu (nic.bme.hu [152.66.115.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9HCQWiU017462 for ; Thu, 17 Oct 2002 08:26:34 -0400 Received: from heanet.ie (unknown [152.66.249.218]) by nic.bme.hu (Postfix) with ESMTP id 46CF24888C for ; Thu, 17 Oct 2002 14:26:29 +0200 (CEST) Message-ID: <3DAEAC6D.AF94CEA4@heanet.ie> From: Victor Reijs X-Mailer: Mozilla 4.77 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> <5.1.0.14.0.20021016155729.02b5c4f0@hogpa.mt.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 17 Oct 2002 13:26:22 +0100 Content-Transfer-Encoding: 7bit Hello all of you, Al Morton wrote: > > At 11:35 AM 10/16/2002 -0400, stanislav shalunov wrote: > >Al Morton writes: > > > The 0.1% loss objective successfully supports a larger fraction > > > of user needs in combination with their application capabilities. > > > More support is better. > > > >This doesn't make 0.1% loss special in the same way 150ms latency is. > >Why not 0.01%? > > The user application support view is very similar for these two objectives. > 150ms 1-way delay is "Acceptable for most user applications," but not all, > according to G.114. The same is true for 0.1% loss, few applications benefit > from lower loss levels, it seems to be a point of diminishing returns > for now. If significant applications emerge that require 0.01% loss > or lower, then the "cast-in-stone" loss goal could be revised, > or more classes added with the lower loss (evolution is/was anticipated). Looking at Y.1541 (ftp://ftp.t1.org/Pub/T1S1/T1S1.0/2002/2s101490.pdf) it is always talking about PER=10^-4. The Packet loss Rate (PLR) is 10^-3, but I think we should take the smallest figure of the two for a service like voice or tcp (a ping e.g. answers to both and I think a owe way active measurement will both look at the contant and the losses). So I would stimulate the figure 10^-4 instead of 10^-2 (or 10^-3) looking fro general IP networks (so oke for voice). Remember also that an tcp session is much more depending on the PER/PLR than voice... Using the formula of Padhye (http://www.heanet.ie/Heanet/projects/nat_infrastruct/tcpcalculations.htm) an error rate of 10^-3 (buffersize 64 kByte) or 10^-6 (biffersize 2 MByte) will redure the goodput of an TCP with 50% (over a intercontinental link, say RTT=100 msec). All the best, Victor _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Thu Oct 17 12:18:51 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16284 for ; Thu, 17 Oct 2002 12:18:51 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9HGK5UA031143; Thu, 17 Oct 2002 12:20:05 -0400 Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9HGJGUA030805 for ; Thu, 17 Oct 2002 12:19:16 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 5139E5EEA3 for ; Thu, 17 Oct 2002 12:19:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.internet2.edu (Postfix) with ESMTP id 5A0E15ED24 for ; Thu, 17 Oct 2002 12:19:15 -0400 (EDT) To: ippm@advanced.org Subject: Re: [ippm] metric requirements References: <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021015232050.02b66470@hogpa.mt.att.com> <5.1.0.14.0.20021016075727.02b83dd0@hogpa.mt.att.com> <5.1.0.14.0.20021016155729.02b5c4f0@hogpa.mt.att.com> From: stanislav shalunov In-Reply-To: <5.1.0.14.0.20021016155729.02b5c4f0@hogpa.mt.att.com> Message-ID: <87of9tt4vx.fsf@cain.internet2.edu> Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: 17 Oct 2002 12:19:14 -0400 Al Morton writes: > 150ms 1-way delay is "Acceptable for most user applications," but > not all, according to G.114. The quoted statement is true only if your view of the world is telephone-centric. Plenty of applications (games, remote equipment control, etc.) benefit from lower latency. Some classes of applications require it. > The same is true for 0.1% loss, few applications benefit from lower > loss levels, it seems to be a point of diminishing returns for now. You forgot TCP. (Performance of TCP on a path with RTT of 70ms and MSS of 1460B would be limited to 3-5Mb/s -- lower than even low-performance end-attachments of corporate and campus users and woefully inadequate for end stations connected at 100Mb/s.) But TCP is only a minor `application' on the Internet, right? http://netflow.internet2.edu/weekly/longit/perc-protocols6-octets.png -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ Religion is the opium of them asses. --Karlm Arx _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 21 10:55:24 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01741 for ; Mon, 21 Oct 2002 10:55:23 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9LEs4q4005658; Mon, 21 Oct 2002 10:54:04 -0400 Received: from web12408.mail.yahoo.com (web12408.mail.yahoo.com [216.136.173.135]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with SMTP id g9LCR5q4004646 for ; Mon, 21 Oct 2002 08:27:06 -0400 Message-ID: <20021021122705.52631.qmail@web12408.mail.yahoo.com> Received: from [203.76.110.150] by web12408.mail.yahoo.com via HTTP; Mon, 21 Oct 2002 05:27:05 PDT From: Sayed Ahmed Reply-To: idispatch94@yahoo.com To: ippm@advanced.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [ippm] (no subject) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 05:27:05 -0700 (PDT) Dear Sir, We have a dedicated 64 kbps radio link.How I am able to sure that they are ensuring 64 kbps. Sincerely Yours Sayed Ahmed Asian University of Bangladesh __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Mon Oct 21 13:31:07 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07166 for ; Mon, 21 Oct 2002 13:31:06 -0400 (EDT) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9LHW4q4018032; Mon, 21 Oct 2002 13:32:04 -0400 Received: from mail.topsy.net (pc-3536.ethz.ch [129.132.66.115]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9LG7jq4030458 for ; Mon, 21 Oct 2002 12:07:45 -0400 Received: by mail.topsy.net (Postfix) id ACD2D1B89C; Mon, 21 Oct 2002 18:07:33 +0200 (CEST) Delivered-To: info-list@topsy.net From: Lukas Ruf To: info@iwan2002.org Message-ID: <20021021160732.GA4287@maremma.ch> Mail-Followup-To: info@iwan2002.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4i Organization: TIK, ETH Zurich X-GPG: 0xED6F778D -- visit http://www.ch.pgp.net Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mailhost.advanced.org id g9LG7jq4030458 Subject: [ippm] "[IWAN: info]" Call for Participation IWAN 2002 Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Mon, 21 Oct 2002 18:07:32 +0200 Content-Transfer-Encoding: 8bit Call for Participation and Final Program --------------------------------------------------------------------- 4th International Working Conference on Active Networking (IWAN 2002) ETH Z黵ich, Z黵ich, Switzerland, December 4-6, 2002 http://www.iwan2002.org/ --------------------------------------------------------------------- Note: Hotel bookings should be done before November 1, 2002, to take advantage of negotiated conference rates. For registration details please go to the conference web page. Program ------- Wednesday 04.12.2002: Tutorials Tutorial 1: Active Networking: Introduction to a novel approach in computer networking Tutorial 2: Hands On Programming And Use Of Active Networking Thursday, 05.12.2002, 09.00h - 17.30h Welcome Address Keynote 1: Doug Maughan, DARPA Session 1: Node Operating Systems - Snow on Silk: A NodeOS in the Linux Kernel - PromethOS: A Dynamically Extensible Router Architecture Supporting Explicit Routing - The OKE Corral: Code Organisation and Reconfiguration at Runtime using Active Linking - Lightweight Thread Tunnelling in Network Applications Session 2: Active Service Discovery And Deployment - RADAR: Ring-based Adaptive Discovery of Active Neighbour Routers - Integrated Service Deployment for Active Networks - Component-based Deployment and Management of Services in Active Networks Session 3: Active Monitoring and Management - ANQL -- An Active Networks Query Language - Predictable, Lightweight Management Agents - Open Packet Monitoring on FLAME: Safety, Performance and Applications Session 4: Mobile Wireless Active Networking - Active Networks for 4G Mobile Communication: Motivation, Architecture and Application Scenarios - Evolution in Action: Using Active Networking to Evolve Network Support for Mobility Social Event and Banquet Friday, 06.12.2002, 09.00h - 17.00h Session 5: System Architecture - AMnet 2.0: An Improved Architecture for Programmable Networks - Design and Implementation of a Python-Based Active Network Platform for Network Management and Control - Designing Service-Specific Execution Environments - ROSA: Realistic Open Security Architecture for Active Networks Session 6: Peer-to-peer And Group Communication - A Flexible Concast-based Grouping Service - Programmable Resource Discovery using Peer-to-Peer Networks Session 7: Active Service Composition - Feature Interaction Detection in Active Networks - Flexible, Dynamic and Scalable Service Composition for Active Routers Session 8: Panel: Future of Active Networks Closing Address Visit the conference web page at http://www.iwan2002.org/! /* Distribution of this call for participation is highly appreciated. * Please accept our apologies if you receive this call for participation * multiple times. */ - For further information, please visit http://www.iwan2002.org To unsubscribe, send an email to majordomo@iwan2002.org with unsubscribe info in the body and not in the subject field. _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Tue Oct 29 06:21:04 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28446 for ; Tue, 29 Oct 2002 06:21:03 -0500 (EST) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9TBK4q4006979; Tue, 29 Oct 2002 06:20:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9TBJ5q4006574 for ; Tue, 29 Oct 2002 06:19:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27597; Tue, 29 Oct 2002 06:16:42 -0500 (EST) Message-Id: <200210291116.GAA27597@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: [ippm] I-D ACTION:draft-anjali-ippm-avail-band-measurement-00.txt Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Tue, 29 Oct 2002 06:16:41 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Available Bandwidth Measurement in IP Networks Author(s) : T. Anjali et al. Filename : draft-anjali-ippm-avail-band-measurement-00.txt Pages : 8 Date : 2002-10-28 Available bandwidth along a path is an important metric that can be useful to provide insight into the state and performance of the network. Some methods have been proposed in literature for measurement of available bandwidth but they face the problems of scalability and high intrusiveness. In this draft, we propose a method to measure path available bandwidth using an active approach that probes the path. The probing mechanism used is based on TCP New Reno. Once the samples for the available bandwidth measurement are obtained, more accurate results are calculated using a prediction filter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-anjali-ippm-avail-band-measurement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-anjali-ippm-avail-band-measurement-00.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-anjali-ippm-avail-band-measurement-00.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: <2002-10-28163003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-anjali-ippm-avail-band-measurement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-anjali-ippm-avail-band-measurement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-28163003.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm From ippm-admin@advanced.org Wed Oct 30 18:40:58 2002 Received: from mailhost.advanced.org (root@mailhost.advanced.org [209.211.239.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18939 for ; Wed, 30 Oct 2002 18:40:58 -0500 (EST) Received: from mailhost.advanced.org (localhost [127.0.0.1]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9UNb5iV013034; Wed, 30 Oct 2002 18:37:05 -0500 Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by mailhost.advanced.org (8.12.4/8.12.4/Debian-4) with ESMTP id g9UNaPiV012841 for ; Wed, 30 Oct 2002 18:36:26 -0500 Received: from cow.ripe.net (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.5/8.11.6) with ESMTP id g9UNaPnZ030525 for ; Thu, 31 Oct 2002 00:36:25 +0100 Received: from localhost (henk@localhost) by cow.ripe.net (8.11.6/8.10.2) with ESMTP id g9UNaOK32717 for ; Thu, 31 Oct 2002 00:36:25 +0100 X-Authentication-Warning: cow.ripe.net: henk owned process doing -bs From: "Henk Uijterwaal (RIPE-NCC)" To: ippm@advanced.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-RIPE-Spam-Status: NONE ; -997 Subject: [ippm] Active measurements BCP Internet Draft (fwd) Sender: ippm-admin@advanced.org Errors-To: ippm-admin@advanced.org X-BeenThere: ippm@advanced.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF IP Performance Metrics Working Group List List-Unsubscribe: , List-Archive: Date: Thu, 31 Oct 2002 00:36:24 +0100 (CET) Folks, I've put the latest version of the Active Measurements BCP Internet Draft online at: http://www.ripe.net/home/henk/draft-ietf-ippm-owmetric-as-01.txt Comments from Victor and Stanislav have been included. The draft is still very rough, more comments are welcome. This draft will be submitted on Monday. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal@ripe.net RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk Singel 258 Phone: +31.20.5354414 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ That problem that we weren't having yesterday, is it better? (Big ISP NOC) _______________________________________________ ippm mailing list ippm@advanced.org http://mailhost.advanced.org/mailman/listinfo/ippm