From jsaldana@unizar.es Mon Apr 2 00:26:46 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F88821F8471; Mon, 2 Apr 2012 00:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-nUX6veFEDf; Mon, 2 Apr 2012 00:26:45 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 529D421F8569; Mon, 2 Apr 2012 00:26:33 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q327QPnj001673; Mon, 2 Apr 2012 09:26:26 +0200 From: "Jose Saldana" To: , References: In-Reply-To: Subject: RE: TSV draft notes Paris (Draft) Date: Mon, 2 Apr 2012 09:26:24 +0200 Message-ID: <002901cd10a1$e9701bf0$bc5053d0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHYzKkLGjeHpgv6MiRwq1bn+2kapZZvqlnQ Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg-chairs@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 07:26:46 -0000 The notes are ok for me, Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de gorry@erg.abdn.ac.uk Enviado el: viernes, 30 de marzo de 2012 10:54 Para: tsvwg@ietf.org CC: tsvwg-chairs@ietf.org Asunto: TSV draft notes Paris (Draft) The draft notes from this week's TSVWG meeting have been uploaded here: http://www.ietf.org/proceedings/83/minutes/minutes-83-tsvwg.txt - Please send comment/corrections to the chairs or mailing list. Gorry & James (tsvwg co-chairs) From jsaldana@unizar.es Mon Apr 2 01:15:20 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591AA21F894F for ; Mon, 2 Apr 2012 01:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.405 X-Spam-Level: X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[AWL=0.406, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSaSsd5ZIytw for ; Mon, 2 Apr 2012 01:15:19 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id A830D21F894E for ; Mon, 2 Apr 2012 01:15:17 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q328ExrX018089; Mon, 2 Apr 2012 10:14:59 +0200 From: "Jose Saldana" To: "'Wesley Eddy'" , "Gorry Fairhurst" , "James Polk" , "Gonzalo Camarillo" , "Muthu Arul Mozhi Perumal \(mperumal\)" , "Dan Wing" , =?iso-8859-1?Q?Juli=E1n_Fern=E1ndez_Navajas?= , =?iso-8859-1?Q?Jos=E9_Ruiz_Mas?= , "Michael Ramalho \(mramalho\)" Subject: Some thoughts about draft-saldana-tsvwg-tcmtf-02 Date: Mon, 2 Apr 2012 10:14:58 +0200 Message-ID: <004a01cd10a8$b6550df0$22ff29d0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0Qo3s41mACIi4zRaeKqHUV/ot42Q== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 08:15:20 -0000 In this message I try to answer some of the questions that have been sent to the list. I think the main questions are: 1) Does the draft intend to obsolete RFC4170? 2) The name of the draft 3) Agreement between the ends Let's go with question 1) Wes says: >Hi Jose; by my understanding, your proposal is significantly different from 4170, and not just a set of changes to it, >so I don't think it would strictly be a "bis" document to 4170. >This is just my opinion :) James says: >"bis" named documents are intended to replace existing RFC(s) (i.e., make an existing RFC obsolete (if, and) when > this new draft is published as an RFC. This -rfcXXXbis- designation is intended to give context to what >this new draft is about, but does not indicate any changes in solution/direction/whatever this new draft is attempting to achieve. >A good example from TSVWG is when the original SCTP base spec RFC >(2960) was rewritten to update and correct any known errors (mistakes or omissions) that draft was draft-*-tsvwg- >2960bis-... when in WG draft form. This draft reached consensus within this WG and the community to become RFC >4960, which is a proposed standard currently. >If, and when, SCTP needs to progress towards Internet Standard (IS) along the standards track, it (likely) will start >with a filename with "...-tsvwg-4960bis-..." in it. >Does this make sense? >If you follow that (and no one disagrees with it), do you believe your draft qualifies as an intended rewrite of RFC >4170? It is important what you as an author believes about this, as well as what the WG believes about this. If >consensus is reached whether (or not) this draft should be considered a rewrite of RFC 4170, the filename can >change then (usually at the direction of the WG chairs). The draft title does not need to change, and in fact often >does not. My opinion: The idea of the draft is to widen the scope of RFC4170 (TCRTP), which only includes RTP traffic, and a single option for each layer - RTP traffic - ECRTP compression - PPPMux multiplexing - L2TPv3 tunneling The new draft would include - RTP, UDP and TCP traffic - ECRTP, ROHC, IPHC, no compression - PPPMux or other multiplexing options. In this layer I don't know if there exists any other suitable multiplexing protocol - L2TPv3 of GRE tunneling So the draft includes all the options of RFC4170, as one of its possible uses. Would it be necessary to obsolete RFC4170? -------------------------- Question 2): The name of the draft In my opinion, we can leave the name of the draft as it is now. The name is not the most important thing. ------------------------- Question 3) Signaling Wes says: >I have a related question on the document. Since it allows for multiple options at each "layer" of the tunneling and >compression, how do you get agreement at each end about what it's okay to use, and what actually is used? Is it >just assumed to be a matter of management out of band? My opinion: The main idea is to do something similar to RFC4170. If you look at section 4 (http://tools.ietf.org/html/rfc4170#section-4), there is a "Example implementation of TCRTP". the ways to deploy the PPP and L2TP negotiations are suggested there: LCP negotiation, IPCP negotiation, tunnel establishment, session establishment and tunnel tear down. The negotiations are the ones described on each of the RFCs of the protocols corresponding of each layer. The idea of the new draft could be similar. So there are two options: a) First, the ends would have to negotiate which protocols are they going to use at each layer. And then, each of the protocols would have its own negotiation. In this case, the new draft would have to consider a first negotiation of each layer. b) Other option is that in each scenario only one option is considered: if the best option for my scenario is e.g. UDP-ROHC-PPPMux-GRE, then I will always use it, and I do not need to negotiate anything. In this case, the draft would not have to include a specific negotiation of the protocols to use for each layer. -------------------- I would appreciate if you could send me some feedback. Best regards, and thank you for your questions, Jose From pasi.sarolahti@iki.fi Mon Apr 2 02:47:36 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331F921F866C for ; Mon, 2 Apr 2012 02:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.392 X-Spam-Level: X-Spam-Status: No, score=-105.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0levC0WQs8sP for ; Mon, 2 Apr 2012 02:47:35 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by ietfa.amsl.com (Postfix) with ESMTP id B4E6321F894F for ; Mon, 2 Apr 2012 02:47:32 -0700 (PDT) Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q329lVWI012572 for ; Mon, 2 Apr 2012 12:47:31 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 08689-45 for ; Mon, 2 Apr 2012 12:47:31 +0300 (EEST) Received: from smtp.netlab.hut.fi (luuri.netlab.hut.fi [130.233.154.177]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id q329lL5L012563 for ; Mon, 2 Apr 2012 12:47:21 +0300 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 0910C1E172 for ; Mon, 2 Apr 2012 12:47:21 +0300 (EEST) X-Virus-Scanned: by amavisd-new at luuri.netlab.hut.fi Received: from smtp.netlab.hut.fi ([127.0.0.1]) by localhost (luuri.netlab.hut.fi [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sfA-KSZy5MYn for ; Mon, 2 Apr 2012 12:47:17 +0300 (EEST) Received: from pc112.netlab.hut.fi (pc112.netlab.hut.fi [130.233.154.112]) by smtp.netlab.hut.fi (Postfix) with ESMTPSA id 7172C1E155 for ; Mon, 2 Apr 2012 12:47:17 +0300 (EEST) From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: [dccp] WGLC for draft-ietf-dccp-udpencap-10 Date: Mon, 2 Apr 2012 12:47:19 +0300 References: <20731_1333359735_4F797477_20731_2375_1_EC220417-FEDF-443A-88F1-9DF9CA60158D@iki.fi> To: tsvwg IETF list Message-Id: <298D28FE-6A29-4EDF-A34B-49CCF8E47319@iki.fi> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 09:47:36 -0000 Hi, For information, because this, and similar topics have also been = discussed in TSVWG: the DCCP working group has started a new WGLC on = draft-ietf-dccp-udpencap-10. The mail below gives more information. = Please send comments to dccp mailing list. Thanks! - Pasi Begin forwarded message: > From: Pasi Sarolahti > Subject: [dccp] WGLC for draft-ietf-dccp-udpencap-10 > Date: April 2, 2012 12:41:46 PM GMT+03:00 > To: DCCP WG >=20 > Hi, >=20 > As people have noticed, not much has happened in DCCP WG for the = several past months. However, we still should finish the last (recently = updated) WG document, after which the working group is expected to be = done. >=20 > So: this Email starts the working group last call for "Datagram = Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal = (DCCP-UDP)" (draft-ietf-dccp-udpencap-10). The WGLC lasts two weeks and = ends on Monday, April 16th. Please send possible comments to the dccp = mailing list. >=20 > For the udpencap document the last remaining issue, from the previous = WGLC, has related to the text that speaks about negotiating the use of = DCCP-UDP encapsulation, particularly in ICE. After discussing this with = the authors, we concluded that coming up with a solid negotiation = specification would still require significant amount of work and review = cycles, and this is not worth delaying the document (and the WG) any = further. Therefore, ICE negotiation is left for future work. If there is = interest and energy, negotiation can be specified in a separate = document, probably in a different working group. >=20 > - Pasi >=20 From jsaldana@unizar.es Mon Apr 2 03:17:19 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C5921F8916 for ; Mon, 2 Apr 2012 03:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxibcSwNPhMA for ; Mon, 2 Apr 2012 03:17:16 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 66AF521F8911 for ; Mon, 2 Apr 2012 03:17:15 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q32AH4Zw004633; Mon, 2 Apr 2012 12:17:06 +0200 From: "Jose Saldana" To: "James Polk" Subject: About draft-polk-tsvwg-rfc4594-update-00.txt Date: Mon, 2 Apr 2012 12:17:04 +0200 Message-ID: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007C_01CD10CA.85552380" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0QswrUcdKO8YSgQz25+qTVCCxQ4g== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:17:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_007C_01CD10CA.85552380 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit James, After returning home from IETF 83, I have been reading your draft. I find it interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online games are at least as real-time as VoIP is. In most cases, the gamers are a very difficult people to deal with. If the latency is high, they leave and never return (this statement is not mine, it can be corroborated in the references I put below). This has been studied by many research groups, with empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the authors proposed the use of an adaptation of RTP in order to manage gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. World of Warcraft: They normally use TCP, even though some of them use UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or UDP - Sports games: Since there is a big variety, they have not been deeply studied in the literature Some research papers supporting this classification, and also the real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf - In this paper from my research group, 8 FPS games were analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP (packets of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It is only based on delay and jitter, since packet loss has vevy little influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana ------=_NextPart_000_007C_01CD10CA.85552380 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 

After returning home from IETF 83, I have been reading your = draft. I find it interesting to standardize the service classes. = Otherwise, if each one classifies each traffic according to different = criteria, Diffserv becomes less useful.

 

Regarding “Real-time = interactive” service class, which refers to online gaming (my main = research field), I find it really interesting: online games are at least = as real-time as VoIP is. In most cases, the gamers are a very difficult = people to deal with. If the latency is high, they leave and never return = (this statement is not mine, it can be corroborated in the references I = put below). This has been studied by many research groups, with = empirical tests using real gamers and adding delay, jitter, packet = loss.

 

Other question: in the draft it is said that online games = use RTP/UDP streams. This can be a little confusing. In fact, the vast = majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf= , the authors proposed the use of an adaptation of RTP in order to = manage gaming traffic. But as far as I know, this approach is not used = by commercial games.

 

 

A typical classification of today’s games = is:

 

-          = FPS (First Person = Shooters) e.g. Counter Strike, Halo, Call of Duty: They use = UDP

-          = MMORPG (Massively = Multiplayer Online Role-playing Games), e.g. World of Warcraft: They = normally use TCP, even though some of them use = UDP

-          = RTS (Real-time = strategy) e.g. Age of Empires: They may use TCP or = UDP

-          = Sports games: Since = there is a big variety, they have not been deeply studied in the = literature

 

Some research papers supporting this classification, and = also the real-time requirements of the games:

 

First Person = Shooters

 

-          = A survey of traffic = models for 17 First Person Shooters can be found here. All of them use = UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_I= EEE-IC.pdf

 

-          = In this paper from my = research group, 8 FPS games were analyzed in order to compress and = multiplex their traffic. Figure 5 shows their histograms (inter-packet = time and packet size). It can be seen that they generate real-time = flows, with characteristics very similar to VoIP (packets of 60-80 bytes = every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.p= df

 

-          = Another paper about = FPS using UDP. Section V presents some interesting conclusions about = routing infrastructure. h= ttp://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf

 

-          = In this paper the = network factors annoying the gamers are analyzed. There are also some = calculations of the MOS. Above 150 ms the quality is bad (something = similar to what happens with VoIP) http://= www.research.ibm.com/netgames2005/papers/dick.pdf

 

-          = In this one, a MOS = model for a FPS (Quake IV) is deployed. It is only based on delay and = jitter, since packet loss has vevy little influence (for this concrete = game). Delay above 140 ms produces MOS below 3 htt= p://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf<= /span>

 

-          = In this paper, it is = found that some FPS work properly even with 30% packet loss, whereas = others stop working with 4%. RTT above 300 ms (150 OWD) makes MOS go = above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf=

 

MMORPGs:

-          = A traffic model for = World of Warcraft: http://publik.= tuwien.ac.at/files/pub-et_12119.pdf

 

-          = This one presents a = MOS for World of Warcraft. When added delay is above 160ms, the MOS is = roughly 3.: http://publik= .tuwien.ac.at/files/PubDat_170202.pdf

 

Best regards,

 

Jose = Saldana

------=_NextPart_000_007C_01CD10CA.85552380-- From philip.eardley@bt.com Mon Apr 2 09:49:38 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF821F8710 for ; Mon, 2 Apr 2012 09:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57Rq0txyS1ru for ; Mon, 2 Apr 2012 09:49:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8695021F8711 for ; Mon, 2 Apr 2012 09:49:37 -0700 (PDT) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 17:49:35 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.191]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Mon, 2 Apr 2012 17:49:35 +0100 From: To: , Date: Mon, 2 Apr 2012 17:49:46 +0100 Subject: RE: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 Thread-Topic: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 Thread-Index: Ac0M4vKqnp7S76aSSPemhojy7VLG0AEAz1CA Message-ID: <9510D26531EF184D9017DF24659BB87F332793C419@EMV65-UKRD.domain1.systemhost.net> References: <4F605902.40009@erg.abdn.ac.uk> <4F730BAC.4040602@erg.abdn.ac.uk> In-Reply-To: <4F730BAC.4040602@erg.abdn.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:49:38 -0000 Hi, Sorry these comments are late. S2.2 I thought the numbered bullets could be better phrased, something like= this:- 1. AQM algorithms such as RED SHOULD use packet-mode drop, ie they SHOUL= D NOT use byte-mode drop. The latter=20 is more complex, it creates the perverse incentive to fragment segments into tiny pieces and it is vulnerable to floods of small- packets. 2. If a vendor has implemented byte-mode drop, and an operator has turned it on, it is RECOMMENDED to turn it off, after establishing i= f there are any implications on=20 the relative performance of applications using different packet sizes. 3. RED SHOULD NOT be turned off. Without RED, a drop tail queue biases against large packets. =20 Nit - the following paragraph shouldn't be indented (Note well that RED's..= .) S3.3 The section could be slightly clearer. Starting with the second para, where= you start talking about something you don't recommend (ie you have to reme= mber that you're talking about the consequences of not following your recom= mendation). S3.3 o Also, if the network biases congestion notification by packet size it has to assume a baseline packet size--all proposed algorithms use the local MTU. Then transports have to guess which link was congested and what its local MTU was, in order to know how to tailor their congestion response to that link. So you're saying that for byte-mode drop, the network element has to compar= e the size of the current pkt with the MTU, and if it's 25* smaller then re= duce the pkt loss probably by 25*? And if the MTU was bigger, then the curr= ent pkt would be dropped with greater probability? And both of these things= are hard to do. S3.4 (& knock-on effect on 3.3) I think this could be better.=20 I agree with your arguments in S3.1 & 3.2 that dropping or marking should b= e independent of pkt size.=20 You now go into a couple of pages, which I think could be boiled down to a = paragraph, saying something like:-=20 * the overall system (network + transport) has to be packet-size dependent = in order to drive out the right amount of traffic so the resource becomes u= ncongested (since we assume all resources are in practice byte rather than = packet limited) * from S3.1 and S3.2 the IETF is convinced that the network should notify i= ndependent of packet-size. * therefore the transport must act dependent on packet-size. It seems to me this is a necessary consequence of your earlier assumptions = /arguments. [On the other hand, if someone disagrees with the arguments and thinks that= the network should notify dependent on packet-size, then it follows that t= he transport can act independent of packet-size.] I think in S3.3 you're trying to make another argument (?):- * we can either do packet-size biasing in the network element or on the end= host transport (see argument above) * packet-size biasing in the network is quite tricky, because then both the= network element & the transport have to make some guesses about MTU - wher= eas with packet-size biasing in the transport, neither network element nor = transport needs to know what the MTU is. * it is also easier to implement packet-size biasing in the transport than = in the network. On the last bullet, I didn't really follow your argument in S3.5. Might be = easier to follow if S3.5 also talked about how a network element would take= account of pkt size? Also, does the following argument also apply?:=20 * if pkt-size biasing is done in the transport, then the work (to do the bi= asing) is spread over many end hosts,=20 * whereas if pkt-size biasing is done in the network, then the work is conc= entrated in just the congested network element, which has to operate on all= the traffic at line speed. =09 Nits Page 5, line 3 - less control packets /fewer control packets Page 7, RED terminology - In RED /In RED [ref] Best wishes, phil -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of G= orry Fairhurst Sent: 28 March 2012 14:02 To: tsvwg@ietf.org Subject: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 Please respond to the WGLC that ends on Friday 30th March 2012. Notes to the list would be helpful to complete the WGCC. Gorry & James -------- Original Message -------- Subject: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 This email announces the start of a working group last call for draft-ietf-tsvwg-byte-pkt-congest-07, "Byte and Packet Congestion Notification". This document is now thought to be ready to proceed to be published as a BCP. Please send any comments to the TSVWG list. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-byte-pkt-congest-07 The last call will run for TWO weeks, ending Friday 30th March 2012. Emails saying "I support" or "I don't support" publication are also most=20 helpful in judging the WG consensus. Please let us know if this draft is=20 useful and seems to provide the correct advice. James and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org From p.ohanlon@gmail.com Tue Apr 3 08:16:24 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693621F84E6; Tue, 3 Apr 2012 08:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eiqQFVw+35H; Tue, 3 Apr 2012 08:16:24 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8D21F84E7; Tue, 3 Apr 2012 08:16:23 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so3429124wib.1 for ; Tue, 03 Apr 2012 08:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2+VV9n8L5sNkdAeSG56BdGrful1E/A/wAoOBgiCtQdU=; b=0yM3icONHvqs1yUaaUueAcgl6Iso+h+si+/HBw6B+WbgWO6qTxqXMy2apWY2D0fxdy bhNi1OrXCp8fiaB/vKxf/BG2DjmfUvFEEfJXIIi+6fF+AAUhGUYN4hpQSDNJUO2NPsBV WGfF+P6Kux4OUONhx6nNtHCO6ZujG8aRSZuLoh0ShQcNYa8BV5RnS8UbpTpJIW9iI1LQ dmSpyJT9bVHxig2jXBrw1gnfoXeCUAYp8w715jMT/c4vWWG1Z/7SW58zGnF4ugGYIhJC kJm1EKJDYpdMTlltL3dY/TfbB2dBnnPCvNw+uHfjWSvIjf48toxJ4ZypPh5qbUnhdSkH JQAA== Received: by 10.180.102.101 with SMTP id fn5mr37368223wib.6.1333466182518; Tue, 03 Apr 2012 08:16:22 -0700 (PDT) Received: from black.lan (94-194-17-167.zone8.bethere.co.uk. [94.194.17.167]) by mx.google.com with ESMTPS id k6sm43509297wie.9.2012.04.03.08.16.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Apr 2012 08:16:21 -0700 (PDT) Subject: Re: TSV draft notes Paris (Draft) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Piers O'Hanlon In-Reply-To: Date: Tue, 3 Apr 2012 16:16:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6BB9D2DD-822C-4C1A-BE8F-9096C97028D1@gmail.com> References: To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1257) Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:16:24 -0000 Hi Gorry, The minutes look fine in general. A few comments: 1) "Georgios - RSVP support for PCN" Garbled text at end of first paragraph 2) "Randy - ECN for SCTP" Although this error originated in the schedule I guess that it should be = "Randall" not "Randy" 3) "James - Proposed update to RFC 4594" Rudediger -> Ruediger 4) "Piers - Reactions to Signaling from ECN Support for RTP/RTCP" - A small nit - my name was spelled correctly in the title but not in = the minuted discussions. - Data-limited discussion addition: "Piers: Can Gorry clarify his comments on the list regarding DCCP and = the newer version of TFRC RFC? Gorry: I was mainly talking about the data-limited behaviours that were = improved in the latest version of TFRC RFC. These benefit periods of = temporarily low rate operation, for example as a result of silence or = comfort noise. Piers: Right ok we were aware of these changes but will add more = information into the draft." Piers On 30 Mar 2012, at 09:54, gorry@erg.abdn.ac.uk wrote: >=20 > The draft notes from this week's TSVWG meeting have been uploaded = here: >=20 > http://www.ietf.org/proceedings/83/minutes/minutes-83-tsvwg.txt >=20 > - Please send comment/corrections to the chairs or mailing list. >=20 > Gorry & James > (tsvwg co-chairs) From jsaldana@unizar.es Tue Apr 3 23:19:05 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE55621F85E1 for ; Tue, 3 Apr 2012 23:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.133 X-Spam-Level: X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkEuuwXTaOJ4 for ; Tue, 3 Apr 2012 23:19:04 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA3D21F85F2 for ; Tue, 3 Apr 2012 23:19:03 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q346IuUm008772 for ; Wed, 4 Apr 2012 08:18:57 +0200 From: "Jose Saldana" To: References: In-Reply-To: Subject: Some comments about draft-polk-tsvwg-rfc4594-update-00 Date: Wed, 4 Apr 2012 08:18:58 +0200 Message-ID: <002101cd122a$d28a5560$779f0020$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD123B.961436D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0RhwGI/kslb9TST4qt9YiH0nPVZQAo1kNQ Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 06:19:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CD123B.961436D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit James, I have been reading the draft, and I have found some small errors, which may be corrected in the next version. Best regards, Jose Saldana -------- - Page 3, first paragraph of the introduction: There is something wrong in this sentence: >Local administrators are who configuration each router for which Differentiated Services Code >Points (DSCP) are to be treated differently, ... - Page 4: There is something missing in this sentence: >[ID-DSCP] goes further to explain that may layer 2 technologies fewer bits for marking and prioritization. - Page 15: It is said that >Conversational service group consists of five service classes: But only three classes appear - Page 16, Real-time paragraph. Games do not use RTP, but only bare UDP an TCP. >Real-Time Interactive, which includes both 'admitted' and 'unadmitted' Realtime-Interactive >service class, is for bidirectional variable rate inelastic applications that require low >jitter and loss and very low delay, such as interactive gaming applications that use >RTP/UDP streams for game control commands, - Page 20: You say that real-time interactive service has to work with very low loss rate. This may be true or not. In a reference I sent yesterday, it was shown that Microsoft's game "Halo" stops working with 4% packet loss, whereas Quake III works well with 30%, and players do not notice - Page 42, first paragraph: >Interactive gaming applications that do not have the ability to change encoding rates >or to mark packets with different importance indications is one good example of such an >application. I think that talking about encoding rates for games is a bit confusing. The games I have studied do not modify encoding rates, since they do not transmit audio or video. They only transmit the game status or the actions of the player. The game is rendered in the local machine. One exception: games including a voice channel in order to coordinate the different players. ------=_NextPart_000_0022_01CD123B.961436D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

James,

 

I have been reading the = draft, and I have found some small errors, which may be corrected in the = next version.

 

Best = regards,

 

Jose = Saldana

 

--------

 

- Page 3, first = paragraph of the introduction: There is something wrong in this = sentence:

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>Local = administrators are who configuration each router for which = Differentiated Services Code

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>Points = (DSCP) are to be treated differently, ...

 

 

- Page 4: There is = something missing in this sentence:

><= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Courier'>[ID-DSCP] goes further to = explain that may layer 2 technologies fewer bits for marking and = prioritization.

 

 

- Page 15: It is said = that

><= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Courier'>Conversational service = group consists of five service classes:

 

But only three classes appear

 

 

 

- Page 16, Real-time = paragraph. Games do not use RTP, but only bare UDP an = TCP.

><= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Courier'>Real-Time Interactive, = which includes both ’admitted’ and ’unadmitted’ = Realtime-Interactive

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>service = class, is for bidirectional variable rate inelastic applications that = require low

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>jitter = and loss and very low delay, such as interactive gaming applications = that use

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>RTP/UDP = streams for game control commands,

 

 

- Page 20: You say that = real-time interactive service has = to work with very low loss rate. This may be true or not. In a reference = I sent yesterday, it was shown that Microsoft’s game = “Halo” stops working with 4% packet loss, whereas Quake III = works well with 30%, and players do not notice

 

 

- Page 42, first = paragraph:

><= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Courier'>Interactive gaming = applications that do not have the ability to change encoding rates

><= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:Courier'>or to = mark packets with different importance indications is one good example = of such an

><= span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:Courier'>application.

 

I think that talking about encoding rates for games is a = bit confusing. The games I have studied do not modify encoding rates, = since they do not transmit audio or video. They only transmit the game = status or the actions of the player. The game is rendered in the local = machine. One exception: games including a voice channel in order to = coordinate the different players.

 

------=_NextPart_000_0022_01CD123B.961436D0-- From jmpolk@cisco.com Wed Apr 4 14:35:37 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971D811E80EC for ; Wed, 4 Apr 2012 14:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0Z-4M2quTzL for ; Wed, 4 Apr 2012 14:35:36 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA9B811E80D9 for ; Wed, 4 Apr 2012 14:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2265; q=dns/txt; s=iport; t=1333575336; x=1334784936; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=rFAd+J/poJpSxOfrjf5EAJ40xR7BqPu9iGhdqunoo2g=; b=J8K4oa+ber7mxy/e0Meqnwmz6hUIAqOpgNuEMLYR9Hs0oiksfEWZ5SqD K/bgiesg4YvzM2GRh69jK0B35UPw/uCoHzBDkqKXfJVX711S/dNycq6XC PZr6kq4YFGJFhztD7h0R+cux/+XJdUIQpyNCtl28ompas+XV8h+EqDKJV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACm+fE+rRDoJ/2dsb2JhbABFuCqBB4IJAQEBBBIBJQJPBwQOCh4QGT4GATSHZps0nluQTwSIWJtSgWmDBQ X-IronPort-AV: E=Sophos;i="4.75,370,1330905600"; d="scan'208";a="35981799" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 04 Apr 2012 21:35:36 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q34LZZW0022804; Wed, 4 Apr 2012 21:35:36 GMT Message-Id: <201204042135.q34LZZW0022804@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 04 Apr 2012 16:35:35 -0500 To: "Jose Saldana" , From: "James M. Polk" Subject: Re: Some comments about draft-polk-tsvwg-rfc4594-update-00 In-Reply-To: <002101cd122a$d28a5560$779f0020$@unizar.es> References: <002101cd122a$d28a5560$779f0020$@unizar.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 21:35:37 -0000 Jose Thanks for catching these, I'll fix each of them in the upcoming revision. James At 01:18 AM 4/4/2012, Jose Saldana wrote: >James, > >I have been reading the draft, and I have found some small errors, >which may be corrected in the next version. > >Best regards, > >Jose Saldana > >-------- > >- Page 3, first paragraph of the introduction: There is something >wrong in this sentence: > >Local administrators are who configuration each router for which > Differentiated Services Code > >Points (DSCP) are to be treated differently, ... > > >- Page 4: There is something missing in this sentence: > >[ID-DSCP] goes further to explain that may layer 2 technologies > fewer bits for marking and prioritization. > > >- Page 15: It is said that > >Conversational service group consists of five service classes: > >But only three classes appear > > > >- Page 16, Real-time paragraph. Games do not use RTP, but only bare >UDP an TCP. > >Real-Time Interactive, which includes both 'admitted' and > 'unadmitted' Realtime-Interactive > >service class, is for bidirectional variable rate inelastic > applications that require low > >jitter and loss and very low delay, such as interactive gaming > applications that use > >RTP/UDP streams for game control commands, > > >- Page 20: You say that real-time interactive service has to work >with very low loss rate. This may be true or not. In a reference I >sent yesterday, it was shown that Microsoft's game "Halo" stops >working with 4% packet loss, whereas Quake III works well with 30%, >and players do not notice > > >- Page 42, first paragraph: > >Interactive gaming applications that do not have the ability to > change encoding rates > >or to mark packets with different importance indications is one > good example of such an > >application. > >I think that talking about encoding rates for games is a bit >confusing. The games I have studied do not modify encoding rates, >since they do not transmit audio or video. They only transmit the >game status or the actions of the player. The game is rendered in >the local machine. One exception: games including a voice channel in >order to coordinate the different players. > From Ruediger.Geib@telekom.de Thu Apr 5 00:48:47 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D6C21F86EA for ; Thu, 5 Apr 2012 00:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OTpApc8THG9 for ; Thu, 5 Apr 2012 00:48:46 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 52AD021F86A6 for ; Thu, 5 Apr 2012 00:48:44 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 05 Apr 2012 09:48:39 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 5 Apr 2012 09:48:39 +0200 From: To: Date: Thu, 5 Apr 2012 09:48:37 +0200 Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: Ac0QswrUcdKO8YSgQz25+qTVCCxQ4gCRp9ew Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> In-Reply-To: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 07:48:48 -0000 Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to code= point mapping as well as codepoint to class properties. You observe that so= me games are using TCP while others use UDP, which I think is a useful leve= l of QoS requirement abstraction. There's no need to have like 25+ QoS (sub= )classes, I think. But one class optimised to transport "UDP" and one for = "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a point = in standardising class properties, and certainly not to standardise applica= tion mappings to classes (recommending them may however be useful). My take= would be to standardise four classes/properties (in brackets example usage= ): a) for traffic which doesn't support re-transmits, requiring lowest delay a= nd jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traf= fic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using TCP= , like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best Effort) -= this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 cla= sses, having properties as described above. It is useful to recommend codep= oints matching to these classes. Standardising these codepoints requires ag= reement between those having deplyed them. Straightforward for a) EF and d)= 000000, probably easy for c) being used to transport Network Management (C= S 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, this = may depend on the implemented application transport. Further details may be= discussed. Everything else could be reserved, but shouldn't be recommended. Carriers h= ave deployed differing schemes on codepoints and classes. They need coding = reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as = well as in DSCP space if they should converge to a standardised codepoint/c= lass scheme. I object to any approach standardising a match of classes and applications = with codepoints as a requirement and I also object to standards leaving no = spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP = precedence). Bob Briscoe mentioned the difference between classes and queues and above p= roperties can be mapped to queues. If end to end QoS is desired, the same c= lass properties must be negotiated end to end. The lower the number of clas= ses and codepoints being deployed, the higher the probability of getting en= d to end QoS. I don't support an approach requiring 8 three bit classes and= 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of J= ose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I find i= t interesting to standardize the service classes. Otherwise, if each one cl= assifies each traffic according to different criteria, Diffserv becomes les= s useful. Regarding "Real-time interactive" service class, which refers to online gam= ing (my main research field), I find it really interesting: online games ar= e at least as real-time as VoIP is. In most cases, the gamers are a very di= fficult people to deal with. If the latency is high, they leave and never r= eturn (this statement is not mine, it can be corroborated in the references= I put below). This has been studied by many research groups, with empirica= l tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP strea= ms. This can be a little confusing. In fact, the vast majority of online ga= mes do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseld= orf.de/publications/library/Mauve2001a.pdf, the authors proposed the use of= an adaptation of RTP in order to manage gaming traffic. But as far as I kn= ow, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of D= uty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. W= orld of Warcraft: They normally use TCP, even though some of them use UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP o= r UDP - Sports games: Since there is a big variety, they have not been d= eeply studied in the literature Some research papers supporting this classification, and also the real-time= requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can be f= ound here. All of them use UDP http://www.discover.uottawa.ca/publications/= files/MMOG-Survey_IEEE-IC.pdf - In this paper from my research group, 8 FPS games were analyzed = in order to compress and multiplex their traffic. Figure 5 shows their hist= ograms (inter-packet time and packet size). It can be seen that they genera= te real-time flows, with characteristics very similar to VoIP (packets of 6= 0-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag= _nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some inter= esting conclusions about routing infrastructure. http://www.thefengs.com/wu= chang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyz= ed. There are also some calculations of the MOS. Above 150 ms the quality i= s bad (something similar to what happens with VoIP) http://www.research.ibm= .com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It is= only based on delay and jitter, since packet loss has vevy little influenc= e (for this concrete game). Delay above 140 ms produces MOS below 3 http://= www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even with= 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (15= 0 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-arm= itage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.a= t/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added delay = is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/Pub= Dat_170202.pdf Best regards, Jose Saldana From jsaldana@unizar.es Thu Apr 5 02:28:43 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6675421F86DC for ; Thu, 5 Apr 2012 02:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[AWL=1.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTVQm-Sw+iIX for ; Thu, 5 Apr 2012 02:28:41 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 52AEE21F86AF for ; Thu, 5 Apr 2012 02:28:39 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q359SULc013659; Thu, 5 Apr 2012 11:28:30 +0200 From: "Jose Saldana" To: References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Date: Thu, 5 Apr 2012 11:28:32 +0200 Message-ID: <000b01cd130e$78c48f70$6a4dae50$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000C_01CD131F.3C4DFBB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYlnLYVxA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 09:28:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000C_01CD131F.3C4DFBB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and after talking to James, I thought that the idea of standardizing the traffic classification fits well with my proposal. I would like to know your opinion about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the waiting time in the multiplexer. So another use is to provide flexibility: if you are a game provider, you may over provision your network in order to be able to manage traffic peaks. But perhaps using this, you may be able to have a smaller network, and use compression when necessary (rush hour, first days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct priority. I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-War craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find the history of the problems of World of Warcraft for Virgin Media users. The problem was caused by a modification in the traffic, and the provider did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe that some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ QoS (sub)classes, I think. But one class optimised to transport "UDP" and one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be useful). My take would be to standardise four classes/properties (in brackets example usage): a) for traffic which doesn't support re-transmits, requiring lowest delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using TCP, like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward for a) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, this may depend on the implemented application transport. Further details may be discussed. Everything else could be reserved, but shouldn't be recommended. Carriers have deployed differing schemes on codepoints and classes. They need coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and applications with codepoints as a requirement and I also object to standards leaving no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP precedence). Bob Briscoe mentioned the difference between classes and queues and above properties can be mapped to queues. If end to end QoS is desired, the same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of getting end to end QoS. I don't support an approach requiring 8 three bit classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I find it interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online games are at least as real-time as VoIP is. In most cases, the gamers are a very difficult people to deal with. If the latency is high, they leave and never return (this statement is not mine, it can be corroborated in the references I put below). This has been studied by many research groups, with empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the authors proposed the use of an adaptation of RTP in order to manage gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. World of Warcraft: They normally use TCP, even though some of them use UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or UDP - Sports games: Since there is a big variety, they have not been deeply studied in the literature Some research papers supporting this classification, and also the real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf - In this paper from my research group, 8 FPS games were analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP (packets of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It is only based on delay and jitter, since packet loss has vevy little influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana ------=_NextPart_000_000C_01CD131F.3C4DFBB0 Content-Type: application/pdf; name="TCMTF_and_carriers.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TCMTF_and_carriers.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlcy1FUykgL1N0cnVjdFRyZWVSb290IDE3MiAwIFIvT3V0bGluZXMgMTY5IDAgUi9NYXJrSW5m bzw8L01hcmtlZCB0cnVlPj4+Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50 IDEvS2lkc1sgMyAwIFJdID4+DQplbmRvYmoNCjMgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQg MiAwIFIvUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvR1M1IDUgMCBSL0dTNiA2IDAgUi9HUzcyIDcy IDAgUi9HUzE1MCAxNTAgMCBSL0dTMTUxIDE1MSAwIFI+Pi9Gb250PDwvRjEgNyAwIFIvRjIgOSAw IFI+Pi9QYXR0ZXJuPDwvUDEyIDEyIDAgUi9QMTQgMTQgMCBSL1AxNiAxNiAwIFIvUDE4IDE4IDAg Ui9QMjAgMjAgMCBSL1AyMSAyMSAwIFIvUDI0IDI0IDAgUi9QMjYgMjYgMCBSL1AyNyAyNyAwIFIv UDMwIDMwIDAgUi9QMzIgMzIgMCBSL1AzNCAzNCAwIFIvUDM2IDM2IDAgUi9QMzggMzggMCBSL1A0 MCA0MCAwIFIvUDQxIDQxIDAgUi9QNDQgNDQgMCBSL1A0NiA0NiAwIFIvUDQ3IDQ3IDAgUi9QNDkg NDkgMCBSL1A1MSA1MSAwIFIvUDUyIDUyIDAgUi9QNTUgNTUgMCBSL1A1NiA1NiAwIFIvUDU5IDU5 IDAgUi9QNjAgNjAgMCBSL1A2MiA2MiAwIFIvUDY0IDY0IDAgUi9QNjcgNjcgMCBSL1A2OCA2OCAw IFIvUDcwIDcwIDAgUi9QNzQgNzQgMCBSL1A4MCA4MCAwIFIvUDgyIDgyIDAgUi9QODggODggMCBS L1A5MCA5MCAwIFIvUDk2IDk2IDAgUi9QOTcgOTcgMCBSL1AxMDAgMTAwIDAgUi9QMTAxIDEwMSAw IFIvUDEwMyAxMDMgMCBSL1AxMDYgMTA2IDAgUi9QMTEyIDExMiAwIFIvUDExMyAxMTMgMCBSL1Ax MTUgMTE1IDAgUi9QMTE2IDExNiAwIFIvUDExNyAxMTcgMCBSL1AxMTkgMTE5IDAgUi9QMTI1IDEy NSAwIFIvUDEyNyAxMjcgMCBSL1AxMzMgMTMzIDAgUi9QMTM1IDEzNSAwIFIvUDE0MSAxNDEgMCBS L1AxNDMgMTQzIDAgUi9QMTQ5IDE0OSAwIFIvUDE1MyAxNTMgMCBSL1AxNTQgMTU0IDAgUi9QMTU2 IDE1NiAwIFIvUDE1NyAxNTcgMCBSL1AxNjAgMTYwIDAgUi9QMTYxIDE2MSAwIFIvUDE2MiAxNjIg MCBSL1AxNjMgMTYzIDAgUi9QMTY1IDE2NSAwIFIvUDE2NiAxNjYgMCBSL1AxNjcgMTY3IDAgUj4+ L1hPYmplY3Q8PC9JbWFnZTIyIDIyIDAgUi9JbWFnZTI4IDI4IDAgUi9JbWFnZTQyIDQyIDAgUi9J bWFnZTUzIDUzIDAgUi9JbWFnZTU3IDU3IDAgUi9JbWFnZTYxIDYxIDAgUi9JbWFnZTYzIDYzIDAg Ui9JbWFnZTY1IDY1IDAgUi9JbWFnZTY5IDY5IDAgUi9JbWFnZTcxIDcxIDAgUi9JbWFnZTk4IDk4 IDAgUi9JbWFnZTEwMiAxMDIgMCBSL0ltYWdlMTA0IDEwNCAwIFIvSW1hZ2UxNTggMTU4IDAgUj4+ L1Byb2NTZXRbL1BERi9UZXh0L0ltYWdlQi9JbWFnZUMvSW1hZ2VJXSA+Pi9NZWRpYUJveFsgMCAw IDExNTUgODQzXSAvQ29udGVudHMgNCAwIFIvR3JvdXA8PC9UeXBlL0dyb3VwL1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQj4+L1RhYnMvUy9TdHJ1Y3RQYXJlbnRzIDA+Pg0KZW5kb2JqDQo0IDAg b2JqDQo8PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDIwNDkzPj4NCnN0cmVhbQ0KeJzsfVuv Zclt3nsD8x/W48iBt+p+AQw/aCQLCaBEcneQPOTF6YxmIpyWI40M++e7yI9kVa2z9u4ezUSjMTYa 6LNZq26LZLFIVpHr+Omvj7/7u5/+6ov//PPD/f3fHz/7+RfHT3/5Nh9fffPZG3989dmb7OMttSPl dOvp+DAKQj1SC7fYjpzbrQ2oh1svR27pVvKRarvlerwfNXu89QGPDvxRnL+NhyXfUhpAuaXxKOdb 4aoluJsvXNfno6R0ywTlWx6Vi7v1URl/qHIpt+JH63Jz4SjV3ep4nPotjaajBzfGSYH+UOXub44e 11srR/XulkbPsd8cQeNB8DfPc6gh3nI80pibp2fl1uIRW7/1cFQXb7EPKN5CR2VHPcQxxRCPGiq9 VhxIioG6JbTEWG65cWUfbmU8HuUDQaWPWn5A/lbGfCvhLvomsygDQzUfoWVqXKKndwyl3+rAmqNJ hIF8we/A9ADHtI/cC/UdBg0GsvMYoiXuZEBUtUTuNVdCePaVOg9lvPrAQHe3PMYY1IqFKqdaCHmh JkI/IXbgPVRPPaQ4KD86rkQnqjvwUP1oXG8hHMnnm6cXjfQ2aQxTBwrD4BJUHjwQxssG7jG2dqsD SqNNYEQTvkug9xiV45hWGwhutzII5sKtjUqDmIn7JfwOtpMJu8RtBz7GrOhPodETE34884NZAuOZ K/dbJg7xhKIUEhM9NUJtipV4l7inMN6ooDUuSKM8tltgYFCZgOwZ8uh4/ApgcepqvEinlTKqDKLQ n0FqF7nmwJYbzwaCxyJyld+QmDod+3Ibdb/+7M1v/2asxTHwv372ZqzNwmvTHb/87M3hj/9yjP9+ dzyX6XOZPpfpD7tM344F+YtffXEcy57qZU+NtHjfEN7DQBYtK1qjpXnGPMMv3EMC/ULvNEmfmR8G igbwxy8hCl4NEmSQn70bAuIf/EFrtAzUvvstLYDDjX/jD/U8Vl4kEh3vPpAIGdv757/5ybvfjd8D +WGwhDve/XwU/rMUulZb91r6VktrGWwphYcWxlqqlf5JS4fsCVb6L7PbPHAppb//FqVfWmnos98X m0MbeHpY9f9w6S/eXaAxLmicaMuDf5xf0Pb5397vIl13MXi49LWL94ZJN9jtMdY/KIFinAT6f5fY +aNhvXn3EUR8o6Ul+1Yel35rVOZLPJBgbJ+IyXKnh0QLfOniEjvXfPZv90erMhprvLEGXnS9ycLb l5+jh7SaH9S7EgVNRQGaBR9mm32EN4+rXHXeT52Hsac97vuyxqUIU7ugjN2EWjo/ZdKp88dVLnv3 p96HkJZ2tF++6vn148tew6nXsZV9ZMqXNS77jpu4HbxJtXdZG3umrS8MNWboIVPYfqHc2lx+JWz9 2ErTWfxthSZVh24yJfCXV1X/TQunQPzTff7314KL1LAh08PAdfBYb3+1b5BfUeVqExybFOlSYWjE FYT5/Fc2eGs2+H+3wV00AfI/bfgdTaz15K3T/3S3aif9dq36xdVQ/80Ke7FJXc701w9wckeIDkUg xm0OP7+awy9MM/C+PpzDt8JWHcurlE/CVh1K/yDhnzfT/4941e3iD8MuG0ojdNwx8geCPRsKQwMe GqqvnewY0pGHxuuHZjkWDSnUrLX6wYxjecUhgeJBQCSgkKVCUCJtmxV1qTsWAhVkUhVp3MzjBoaH /vk//ub4/eD9X//Tn/705R9/f7z/Zsx5aOzfvP89NWcTLo5WQ+kdVkob5spQjMeuaaLwN5+90Rci hb6Sus9vFMkKiVCL/bBqyIQaUCHIs74P7f89Xj8zXGWaDJM9ZjAZE6MgJi1ohSc2JKX23tjWoJHJ AqN3juh9oJnhQdEhgcjkI2gIDcJ0424yJjKm0GEJjkoERQzrmQydcBHEOOICsiEdWRwMeX6HDqjh 7WPSyjVzgbwSGdJsYeoruwEle2Gmk9W+R6ekdBpoH1OpbOSRsTPQMdSAPrjrTKfMDEGMEkEnRgsV VKLMeAyiEaqGBdNB0wpEDiLjMTFbYwuSIc9QlMpeK28v3BwwMKHK7z9sJSmIkVEw+IgglxmKHpDn 16sNfTuGJubIhLaOqe4oGMozI3rYowwnpj7/9J07DZEhp53eYkUBxszyODA0WJWbal2DX+b6HXDz zIFkCVc2vRkR9C6eMKGYsQKhdm9cMBBqJAoYOaOvQM/eCwULv35bKmdigJ267+/zTVG+6US7WBot o0KLcqCtDEZ4zTWepVNMyjQBBcOcJ4iINSBSaolJIGNct9dtEHbJ+IQg4CYkVI4L15iAUq7pTqEi bpuuBb5zAcQmfoeAlV3ghjCWaW1hGcxTOESESfFaQIPSVBt6AiSsKAKiKycQG1FB5MfiSeoJPBS4 5aCkVJ4FKsdQUCG5PCRVAqYSS/a5+gwWrmkoYM5mEg2ggyvY61LpkTAN98wSVqHOi2wj7gOeaZNn XIVwJpYhQ4aZ5vWWgBVNtGnMNSTyAk9i4M5DUtAcMzauyG9erjcugW3RSwNaBVELmuc1NHYKGsrz CjRRsq5zgqbQnXIDEqdUZQLesngb0bceo9ASlW2CtjPbNuDOahVPK28MvH03Fg2D0iloZWa3wNKB hvGMzgy5F7Hh+qgc48CbEbNo2K9KAdSxlYXJ42ndUYzj1+UwpWLrytOFgSRTMLLd54fgFh2hsQwZ zQbnxkHBMNav2xhi7LopsAXs2QftyAftjt8d4fjVk1X+47DKWyZ1hLNjOWlgQY79XrYQByqNOUAP YyzxdrDu93/Wdo9dHB2RHKRt2ptwLkyB9zzXfcP5cLXh8N5lkOfXFYymyaGGs4gpawGrPwxVyO50 QYzKakPEEQu/EvaEUF+T+a3p2yLhxyuJvl1lN2isEWM8B3W7wkaItmf1jM0CaKG6jSsGrLoWVS+f BRdQBJS0cgF6eI9hVz/bMJ13tlxxDJDWzayTs93jxamrAIiUWdq8tKrAsR8XkKHhgbDyIqyI6yAq hlU9kDCYcex+fWjAm6zyhfzhcSCeNux+/PErmBHkRWx8GPIBBTztilcMOFIS5TjAkKj0gu9BHycF GTt90g2aIYi3YnUxUklrVwXDdFQuTa2bCk4r/DSjLtmRNGNMKXetG8P6OKBlEkjMymqV8T5gqNj0 5XdUAO1MYqyApAyZGsQKVBusltKgH1ewjtcXDlBPGpjF4QSpQ5l28izrvHrS1oaPBg3KnsnmQK3L OgsfdZkyJGxns2DQ+2lFNtoLePqAvNVNmKMHATP6DQIpJhQ56LhEtfYbUJO6WcNUP6yQmJlUIBNJ hzWtbGY2VrkZMlPXgaQd2BAu6+ANj1HdtIu7vD+TH5iLqBuzzlCZQagJJozyRoBELtRgHaepbQaa OUNML8XEPKZ2gzf+9Wrd/eMvWUQ/F95z4T0X3ve88KBIBOqgFKo/EBQcu9xiNn8hHAolTZiIU3jD ViOUtH/2zLEngB57MFDmZVqcqnEFALcMLhCxsleA1lL2hPwXTIR8JNmxj5wO8CJDdFnBZWINqgwH Hz2u3Jf2HTym7ZYCQswoGCtdCmi9jgJyFQ+IXHlj3nQ1IoC4A8qMVi4o/JKD5xgCTmqfTT/icgnq qmu4HzJehak+uHssiKGIDSLv9nPwTn1ETJmk9gfhpkN1blULSBWrjBfCJXmPK1OGDtVoYZInLQFZ awGRsBdYL54U/A73aGH/JZO7gdxd/QizQBkkgEE6XAl4zMs8k1uJoOBPrR0qs4ctQUkVMzKZ7bUW 8FCNiEd3SAamPV0WqUxAUkY734yJuZPMpNY9gZG7OJIWbN73p4YyiUQiNJOv+wiktZPafhuW464n Jpd8xNZFCvTgrk5nSDVl3rp2K/dJ0O9AUJFWPsBtzL7RDyggY2kUjOrBezYHKstMOkdll7SX2zZU wC5o+N46H2nzMgccuasBp6QVCqQCTQhnDDS9xhDZhQMSMd1xCWwU0F7SIc4KjJ+OnZIgrWuw0Msz syW6F9B5i86FemDSB5bHuPC2Fwir0MaTE9/UGhD5KjPfSSK5SOTJLLRFUM4CrArel8fYg0mC5/Nn IkhOLNkKCzbfVAqSfYcCkaFkx44COhiUjWSQmB9khnrVpozqqgKUDg4GFCBAeUupQungee9jM52n RHitjhbkTv4HwrbKOu6wfDO5biNRjph4cEM8uabEXzF+jVVAxnGk/z30zyfT/eiZrn7PTDekEctx GC2JeCYmMl3S0LL+cb9jS8jlk1And2wJnV3cjHBI9qqnR132BnbG02yciXRyUhb2GpImS50mvG1B jYQalbSSD+iUa2TiHeEsD9wOonGNjBp0UVEOI4j1KmNYLAnm5UBem7UGW1xrDT6ZW2tE4qS1BrPK izgIwyDMQFam/8vQd8m/QutIVU1ZZKzDRdXhPJtFtn0QnKGVdc9U4nUTqZCghMbQEKmzzrCrvGLJ sCts3xFU0RInlzqRqMxa92k4vpZHBcbOvEhlHmTM8haJmzwF6nL2JgwKdEce2OGNKqBQlq35a+ID PiQuBUzRgRAosA5LtmTTpzt2X75aTFBhYOgRBCTs6bI0tDE7X2mULiMXhuQRVobMQSyA4HCQXbIq VrjhSgWxaQFt3TqRChUhE/cTxCLM1jd1Bz4eCkZweJYwqQC9GteAGR2Zp9JMhYKnv1SdGwsFhoMW YE1EMiIKX2YgfR831HkpiA4lLQsRiiAXVKenUWn90zMRh5hGMcwnFTQTxjS8FZA6qfNI4JcK4Zkg w9muFHGJ4xSfYOpg3QfPUICQ8tFwEoUrzIST2RQbGo99tMmBOh1zqaBOwVRAyKQzSZAgHhP1gFyE zEdDr9PemCLcljmw/FhZFc4SnYOs40IiWS1BwnbRzad7pRWN68EkDTtPkmcTIcIU2bhEOHbh4AQ9 NBVjaVmzYFgy+wsf6DJ3QziUqgzLamoEl/LmwnKmMN90NE3K3avkEL5Z4VZXiTYKSpgTyVgrzCDM hdC9W1cu7EIPcHQAORLYWx7NtSPSI0K4qlQzCeZZHsIIYLklezJEGuOH9w+CmFxs44tMSwwXqD/k QipsXtOgDc+q1p26j0qWYEzTmPPZxaHPUYEiGBzfyCeIrSD2ebDQDiqmmlDC88AeZIsQhhHPwlm0 etltFD1uEacRDoIetECULb6r2m8wVhJGo9PK4iRYgBsXtl466jpAjWUc+5lylxsEOhO34mROA6eT GEiYtWMaxTP/dYzcITM93C86jwY5j6t7ikEPpDRIKb8iRThU1s1GHByaEjF0HlIhYpl4ELo3rAOw SA0qXhtGTp0fA/UJsjagpTpzZP0al+QTl/AVJWJGE2g9z4kkIIRZmep6QD3qoglN2Ya7xs7t+5Tz qgd8PeWY6iQurXIkQnYmVU3H2KgAYQlJQHE7LsJHFOWUipvKUAVSDBBb+3DJErNq3TCXqkwoLqJU BJDMweP9EzsKGiRGhFLvABWvcjXgdciN5QJ4I/FFUxLC8qwZKryOKxrqIkBoKKC56qwcLHu4Lzxi fxJmJeTyXd0XFRKjF36cAPFawRlj8bZW/MYKOEPeCjwUO1GKOxYLzYMBP5HulEKy2TkslQjBJbe/ IlQi0dqixL59rawQpjNnM+uCxCxhcQnXilwUxpNVTZqfw/Uvck6axdSwqnkfSCpdAgMBLWOY+64z r9EuPCJ8OVOGBRyOyyyCej0T+E6WcJ2M11XQq0NWV3g0ohlCWB5OyeFUTET44Uw5hCgssrkCIptM 9uUBuaRbLTm7MwtMFjiwGiuUuQoPXau21eY2FcHd+0dhf0FHEnp0hhN22oaReaDC7uXixF3PvUUj QIH24IgOrFNil/ALZ8Ab3U/MMWeXxfTOBkc8j5hMwmOHbZ/GzmzWiQTjV+WTJNXfCAKjoG5R3sDA dWqqGxR5y8xqZVJBwUQCVLwChPNIfH0m4lK1sEcHBUSR5Hny5UnVHGHhm/zAEnEmQsK674kSyOqD Ko2yTUIrbKBXFvEE52BUUZaBcVaFYDjmhsMC2Hq5q3Un81h4w89Z4GLEeFaDFtQ5Cbn0yZKCoAYV QE4JnIfVgJhJEl3gkwqnraxhM+58b0CIXT0hm/5YXENi0PE1JSmoplsR1LDJ0rHngAqG6+IAN52k ioNHxi8Ue4T92el9Wp2KSg6v5x/mnoCPKnYtKHVOpEIxYsFOUEuLfEdX7BujYYI4fDkCCqI+TAuP /ByLVkadhX1e4tRwsnZ4OIjDhrGrrlyeFyhfcf5EjcGjdDGrV+VYOgnu7DbiZ1Z5EyHkLanGrwR1 yATftKAsM5lHX4mhljfigHB09DMGFhWNbj7Z+8Oq+tq4YpEm7izbHN+tIVHYtECXKri2Q7jITgaR 6nXXo2WXK7Zb6bpCJXD8s9v2uIoSZRkVaspTmXVMreB1Fh5hu7JECRKBG71yqxPSgFm70kKXAUT1 ppZhMuux5SraHORi7FoQIRtDYGFGyn0usCWwTQ6oRBVtrLAXaKhyNlnILuahUTmZfZoZNnEiQtc0 o6wjSUHBRBwUHHIQ5YqRcOKcq00EB49EHsg1PG15OmkrTe7iKsXZxSau7KeP7eljO54+tqeP7elj e/rY5PnTx/b0sT19bE8f29PH9vSxPX1swkhPH9vTx/b0sT19bE8f29PHtvjY3so9ZFEnWAVlY0+c Gwl3GmXxZnidEORbitq3W4G63XBFMEUtcCjIZi1WpKOofRpbXdw5TcKBFujlPMuXu9dlo4Ry0/Yv 7kC67U23zvtBWU9aXu/Ljqn50d+/sj/xx4aHIHh4+5kmR+WcqG/2OA56kwBGoRuWkS+MikOJr51i DytVnRBUULXgBa+GC5y4TtpwnZTaUlqsptHnjAUEZVXdg9jp2viWJammnrMZ8WXjyLY/8XoNixnc JHdIV7WYlG4kUlGNw3OsAS86JFnpxZxCdQsGOEf3iDofcaPfiaUQLqJ7FliUi1chPRTGQCE9xZRs CukBxGqSF0thoBsqA21fLyhIEq8Dasi+7OJVvE4wE0SfXQfr0O1UBOfPyEISBpQAB7F3HMnPKjRH gEWO3M8S0GBZibxdfm2I1Q4IkOM4PMtKhBRFFmlY8bAiZwoHxGUOJqfoEwoPY5X4vQRZIZw7tTXT h2XyQHCjUGEWvCwFEqY3M39YT50zfGpjhaUtbd90ix6VI1K1IEhbsrR6S2pTqgbS8yugsuQGCnjm LLSuIN1VQvB8RKS4v8h2tcAvgAOiIyvuJFeYBxQM2pAdApgK16kiZsHLZ9e5IbAWOTtDRQIkyc7Q 4TnsN4va70g94CSdEJ465IFhHUrtLGYNpCGqiELl+B4Hgl4kCOqIIciS1Kc8zgeU9Ma1QQm5eCwf ULAFHmayJ3h1atWw+yTJnSxvT0B+J4nRd0Ufb+vmPaQp52XQYwNAqtzW1STyFdFOuen1d07tIBoR AREQJzSLN6gFMIgYRgGFs9YINYBTMRPU8Ezyc6VFZeBUR1RX6I6dJ0fV+6tEQPCJE0HkPMdjzd6Q 403TJ1g/rezWn0dOBX45kQkcpMy64eER40tACQwliYMQoVBvmzrc2uam8wg+ZWdCtIJmZgGii1nZ 7wyJ/yRJsFaBDYFwqyY6ceAY1KJOTU3PUNZhyzopReQp3UquKgKnAt883F9sx0uB+HcRQ9vM+8sR tYf4Td9DEu/vLnDXjiSEIpjojUU2XMloURqSzUmGEI2o/aSD0ic3P7n5x8LNb6+STbaZbLInFtMz 22RPOCtFtsmeoCIh22RPTuP2Gc89dklGEI8e2830Egag0SDXZI/IacMvyGPmj2eajJJpknrjkPiZ aTJeZ5qknuMxE032xIFsyDNJbyb6WwFEYVSWZ5IKeD/URJNaYJkmuaAdM9Mk94E8SmPf0/6h0/WU kTJAM03S44KCQb6eoqalHKzbk4Tua65JwntGOqceGO8NA3sGWANU7YoLaJ7sk2EI+TO7QMdMNUlw XhIvKpztnRGCaMkmlVYfyzYZk9KKv3TwCdkmqWcOnVOjigrYWmEFhB8L7QpDCRD8vDwvvFlAZVVA CEOQTJZu8tVLEPazRlgTQO4OSzdJSGhZrSSCSNYg3SRD8ZjpJg1j8bZh0LJQaQvLQkUFCdpgKuhQ 0lD1Y2ntrHvRDZ1nrtEkZIEhPouXxJMb/DKXMhJPEkNWMZcDMFYXvXIvEMpD8czpMGIFDFzRleqZ VsB5J60yGwU7nd/f5yCJryfWZyv+I3knqd8SlsSTPFDUxJM8/aqJJ5kDypJ4kgq85p1UhkHeSYJq WfJOUsEqroR7kPeLkU6rT9NOMgkPZJ1UUiPtJK9ypOuoK+tocjWD08I6Il+K14IAIzKCMzX9FwNF JEa33tMhyScJ6vI4gY/SMZNP7gUq2lBQIcwKbKMk6ArHzD7JYrcckm1SCYN0kwxZUh2pXKLmIVEI 6SZ3mj7glTZ5JcvHWR7mm9QlbUkEqaXkPxnoYqklOXmweeXFMtw3LwlpFQBVzUTkHTGqv4aka+El Z1JkW9jVdnmTIlNk1CWJIG/DRZMI6lsjiaBuFZpEkGHNIUgAbxayf3t4HTSHIBUwgwXIBHhAkENQ JY8ll+NZgRsjGAr8USDEOBNPNn66YOUzr9taWIQiZxK0kdjlvNPuPlMkN9WFcHynnJNPdvmPxS5v 7ySe5K0/HDPzJI8LVFaoZRnu0pC2rf877PySbxoCG24g700+b/knt43nwxxh2XkmECB06dopY6sY t07cRZu4pg3LeAzN3adr0nAez4RdFa8Ep90rmr8VYVtU5CP/JBWEoj5K2kwC9gfRyuMx80+yYgx/ ZofCgyxW/LNiCbaoNWfBBQT+aUm1b04y1rHrZL61gwSUND2HLKZaWTY4zkDJqkI9JAMlv1w+LAPl Asd+XECGiAeSy+t2Fvh08M9KQcnmB3ydQYwfvCTMcoIiZsYKc4Z9oZnweIc33zBDRTdthiRBXdHK ktCupLWvgnEkvV1pWllS2KErzdZbYTEBP7krlVpaH8vHDBIgAMrFuKSDVHjclb78jgrgnYksCd1k qVsGOppVlwxo4M+KDGzN6xtUaCwNL1jgNO/QqiXJXMtaWXoWpTuJsoNx5JlsFQlXTOc0JNVprICE 7WwWlgmPzUt07Nr6Aj4oV0p+Pl/A4Og4CGSYUOwkzalcorkBDkk1Z8pgw3owSA3QBBHRYMuiZYX9 yRl0LRUew6BiR0/CZr2A3MfMhDdh1KzAXETNVnV2UhUUy5itZN8tgEQu1GB2eJn6J5vckgdvR8OF P/AyB+Vz5T1X3nPlff8rT7SJpvEUctmkI7LA3LJdggnMa9HickzNnqNDclCyU0BOqWnMhru7ThW6 tlx1smG8QW05se5jPk5OrMfL0E2AfEgSyl5wyVKvVPcCb7emoOwtrQO1qNfakH+S3tjjgHuwIUEJ 7mGykJGS3I6zu2QjxIk2Q0VPtBlKy4n2PfVDfXcJHz79ePrJXkX11YSFHdRRg4RGrEvOwo7QE8lZ 2It80oRzFnbEgcychXsBtc5iNlHOwp6jXrZo8OvIpWpz6xgs1JeL1MyfVUKreJVLnIkmLJxtXWfe YE9bgpIKk1LTFfZBStf0gIGm1OHeJ9Uz86WQmZ2w57ocKuyou+9QTeYOk3u131+uySf1vgX1RAhV RH5Zmr9e5QNHbC51OqxLmuaP8Mv+Z03zZwiHay3n9Zopg7i+mZIWeFSg+SS9KkoIy3wJw5L8MWy3 0QmSK6+kdmRsgJrkb4OFLgVXERMJMEQBIMsf0zgdM8vfXiA8QdsJsvx1hA9Klj8WhsdM8rfBsgTk mjNtRbUh0IedyV2S9luAYpec/pbkr+NDx5Lkj+Wh5fkjKOLSGAItu9wuQXLJLvcUkOeP5G5DmKAs 1Ob1/KzztPDpD7ZZN/o/EKWSXJLIFo/vmFvyyXQ/fqar3zPTvf3s05NL9oKQI0suSfhL4lWE/7E4 PSHqshPgZoEll2SC4b4kkktyp4gPRXLJjhsKM7kkdeoQx4ort8ROBTGjSC5JnTqoKU0PGzy2iNbV gGJm1uSSVkOTS1oNTS5pNTS5pNX4aHLJjlsZGmTWt3BzWnPNdo8XbAUOGhfpkFXWDYe9U+UuQZBY g0ljWV3lpxJBSUoizlhnuNsswDDxts/DwtKqMXQvcx5B4s7YMVeRUt/i3rm1XHXkpxkvXAFJGJ2F RvTqZtx75zhP0LpKrJidF9eAjZYXJkEeUbBk6UIUzah3aw3navUaBkwu4eo1tbScq1ZJ066KvUwp mx7lcNipYe+dmNji7xk6JOqd667LuzrEQbAA6TgRlbh3gsTcsKgI0d/tyk/nkCOJNu+lIbhAg95p aI+s2mTQE8TLg386i6R+vzTlqHeCsqnrHeefM+q9l7YEmr/MWdk8qgbjq4VS5yQkILRCcFZNB9uz 2icRRybkAi6SI4Bj3glqkE8W895LOVZ7rCwB7x1icAa887xAFzJLC9/Q4Hh3ngfYRXVHmSa7KgiS xAakxBW+vGnx7jaqMYTYazoNfLpycio6tWnIIuaYdzXuLOadBWVUSrH+e0jIOwFyTbhOfPRjxrt3 HACsnHvMYHfjPb5L0nHvW4LdOy6TzmB35mLkuiDWxEGCBLsTlNAU98xtXBMZyjFrQeyrLAPFdTIE HRLvznUlILUr/yUhR+XH1QLeCRLCWcA7xEYUCbIEq7KoQjyqqPk1atRohlojQUqkslUEkli0uwk6 DnfnXR3XuchCqDj3sHB3zEF1HpUodo5PXy1GdDIC3qlAYqrJKVQlPQgHvHNryVISVEBFoYbnxwW4 jqjc8CxMmernNS8Tq+YEqF5TcPegWNIQ1cxvJvFjCcIeYady0Z/HQzwPMTfd2ZBwysoQOY0s3t0m 4la5OifiNI4qeS1ImEjxzKKSdVwEqyQk14k4DZGLcWLQK1IEARMpxqJTrhp5Cg5HNeKd4CzxahGL QdIgQNwnsIn4mrQxH2h2XJiRkHfmXbn1J/6ZvrCJiNU5jQpOD4tAS3XOowIhzM3s+QHUzfVj8e40 sMOWTbqySvgl3t2EmOoipSyChKTVMePdO+RV5NVaLE0GxL1m3+kqLHWoAhEmyXgapBuaCuaKrdSS dh0EOoIFu7Otn2QCoiAnyKakeXeKV1Ve8+50SF+8ScN0RCLagW2Xl9EdJs2EQATIqu3VZglzHv6I AvIlmRVI5bvOI0JedExTPklDCwXjzWB3K5isEDcIUbAa7E5wKjaPoNKZMW7JkWSjC1gmHOxO4zgR +4UhSZFgwe6giR0DC4cuDBttXUmBCEVmuqoLmrQ9aauh7txYLq42fiqCJTAXVYmoDNuW64T7VrFB XJRW+UVbaJ+TyOrETGC5suanoALJT9Gx8bs6l3Yxkm37rds2W6ciosHb1kxJRBBzke0VcpEsMdqW LdadWyJimi6ckaiBsVihwuHycqsmLjTuskuIa7AdtiQdQgpS0OhJhg6Jc+e6xwxzZ7GUDflwSQVs 9AFbg18YYo9xVxdzmzwhdna2Aok1j6Bzxys5KHx6tbubv7ofEuMuKhuHuDODoGrZeMKuhV8WxK5j SYHHVAL0Oi8zryC2IN4kl1jtkGvy1s6bUrsGuduSdSY68rrZqdqnUe4duqcEmDOXIq49i1yCKzAq kzoLoe2wniTKvcPSmlHuIrIWxogbn+KSg8W586IPcx5ykZMD3TvE+Ax0pwIJwq6obHHuLNEkO81c LW6Pc+9lv3DOJj3gapIsTq0KweMS6M6NjxlKzY3tOIM9OjJ+YSjZ3Liy35UNnZrNRLQLjXTvRRKK yEwcdCIPbnDQ9qZwd2pfM487iK+gribJXTLNutx3jay409ycHMtYQcSrS/dCFbZOHGKDNdadW4MB yMGUuzIunerSH4uvfj8nMrklLymJOpxlM9SdCuY8siUoIlMlN/iijDwZH0tGsHvHupJgdxpWtCKL dlfeWARLPLGxw2IW306JtmDBiwliJ8pOBpnqlW8lKJy3W1y1gtTpRcK6Jd7d5jHFiN8FnLevcHkt CHFOxCMWRdYqVHULd+fOhDr8tHklhy6GNdzdjgLrSaoss8s3xIlHkysNFQJ2Pw6VKTgywVZp4e7m 1izQTuWkkcPdWeigcjLTlIcuRhJIGtOF2CdajD5wiyHcnSHIch4paUy+TkQ+bVZFk6p4ygec4ov9 Vikln561p2ft6Vl7etaenrWnZ+3pWXt61p6etadn7elZe3rWnp61p2ft6Vl7etaenrWnZ+3pWXvt WXsrl46reM+QP5FuBzYU0BXGJguY8yfSNUL5ooYYuFuBuNtwGTBFhXHVMJutiLQzzDVqZ/XpxdEE invBy2miL/cvx3a5HFu6Zl//xFSSP0ZM3EsmafEclvcEEdKSTJIuiIpDKQJKljuSXybiZTSZJL18 xxRwfzTiVdhIzLc1mSTBJKMsmSS7WA/JJUlY8LhtSk6yysSZuST3AjGj5WP2gjaxlCy5ZIenKlZ4 hTiNXYJ1AGXBkkvuBdT0MowHen5EThFNhh6u4ngmrP6rPXYnI3W2g5Ukqcwd5lYh0STbJCE84wYz sk3yfV6JzsFVYNnCXbyMzsmWb1KfzuAcYwOedbEce0EvsJLMQL5JDpDqh+Sb5MCvfMx8k0tuIm/3 YSNiszklTj6WxEQdQcZFx0VqD052g2/0INkk54RBOskgc6waK54QvqGJPg5L66HZJveCl6VAIvJm 4o/ZlaWb3AukNce++xuiP8gW7ZaOhmbVZ0YkZCJD4DxHc2fNN8nZXfqSb5IvDjfNN0lJDehQAgkn XyW8WmGaVIT2YQknqSAgynL0yfkegKBB2YtEEWvBy2fX+SE4PwHM6ITPxFTJzhDgYewapSh2cUcE jHxBoiMCBgmVLeUkhwoiP6WEw3OogFOyvkoNlBFakCWfT3ucCqjoPWyDkmbhkVRAQety8lvL+JSq LgCmmiR46sqnFTmeIh7npo/3tfOeha6lY7CzBS1QlTie7amIwCdL10cFLpgiFTOy7iGON8oXDTRh HxdAuyD3aUTSOSTsIyjiWda6dVM1kl9y9mkaDsvZxzmRpAC5IsjhngXFkMOas09fU7vqt+0dU9dM fOKoHgWSJpxI0JHmn6M0CJL0hcja17M7a9Nut3cGnOBfkK01OxGIZFZk+TZRQHKEDh+bZu2jAi8F CNqq4rRkQLyhmqGh7bSUD1coNokwawYW0eGQuKlY+oxa1BUgElP0fUSnJvMaMwR9Pk5xu42flpx9 XB1xFqHpWK3pJi05LZC0z5KEfKsUlE/mfjL3j5S5315lpOwzIyVlRx89pBBoU+C08UzfFJgZKSP6 YNQU2MEjH10kKMgX3zJtwClwGhj56FIKmbiXc5rXAXn7ZhnHBiVf9MuRY99LntPWUV74wWXJV0lh yZnaOxfQd/A8u+vSmCx9YMqz1y95zTnELzFaB4fKHPBPAws0X/D9XXMpe82872nXpHnR5xgo72E7 aHZjK9+iCWuwdFZ/VVjMfyksvpXvL0Q0kc+YslVPrZiZFY6aC5KrR/s04mx835DNkpiUv3IaeMKk jY7ZUUZdOonakl1+zzPCW8rnPRKtzaBfORpqYUqsifEH+EYvnb9zGskeoi71i4H7AK/Gz6T2p1j0 c2LeMWESf1+BP900SJgivi/q6E+iJCfgBpaaBHNn8p2ShDDTewjNQCh/6abw3DxlI761wR30VYO2 ZSD48b78TrvQlCXo80qVVxh/lIS3ZGLtEO0FgpPPH2z88IpXlpd9wRcgaIHFfptfxSMsJXwEZiLx /Xm2CuG05R7hyk44rARPN0EGdij2tm8yimXTj/P12Y/DgbdXL+BuPK+Kz5l50jBI1PJn1fhMWqTn e/n4BT2O+PgNsyy9LT4qUwpkazTZmiBb8elPlyBbC8vWMRrL1mCyFcK24vsqLkK2QtJ2iCoTrUPI 0rD0HVfPxjjNmL4eJksgVDn+2Qu+6yLZEf9yXg4vEqm77Wa6rsJt/QaTEAffi2Z+0eZ/wCcKqNQh SXsHNe3bkUBq0GU6ILkMMds9YHvxZNKnDgjh7POmz5LQ57jIY5d2cfU9TcWkBw2J73MttfeOAGk+ RW1z/5WKmyuZFonnDzAOfs5DJRhavwvpLIK/4yxoQR1fIem64aYAN5JUvd4WQB9pZ9IMnWld/XAZ 8smvtfsGtW0LXltrf1LDPg7HHVh9oeGEF/7b22p/0iICY27jWN89WiDXvTyN21BRe9K69o22sL5Z D/vMergaZ3lRbaDqie9JUIcWGxZ7vOWr0Rb1hFt4PeSSr7ZJATcptx3OK8n7+mx+pC/5atPr3F6+ IwQ54OdX0eTp5Lil+Yt8vEwaFZkjZYZdWdajyVLwarxyMcO8yybjerQ3jQATXNb7bK0dVnmpubhe Va9zPclPa6S9AM9NuaSeMSU92ffjpMKZUG2ZWD7Totzy6xnYCFsHe2vtMe6TBOu9amJwOs8xvppj MGEizHmurZwWNr4LmzDp5zXhtzWxr7h9Te2NrcOz+F9m5VYpd2qsLfXt3Fw8uvYndl69rz+jy21r b1n+C03jaQWlM1njTtZwQda0cfDO8Hnj4OuxzhxX7IWFyaaCvfVdbpdj7ctV1+aHZRWkdXGm8xrZ Rkvri2LAtM0tnhdr2tZHOq2PNF92ShGb+qvaBufT3E5SRPnsvLa2+uXEGW3n4XVhYYucrMdW/Ln+ 6Xsu+0a+8h1cnHkowF8tXD+/xHreH0/wtinuzT9xl3y0gv+MXXKHTrvit9gmz5Jv2SbvQp8k7T8m nF8Le9tpzrvuCTjtsPsW9fWJeI+Un8fa0EbcsJHiIwrQhUK0EcJod0/7uVKE1mpfnwl2SdGz3nOt B+1UXan2abv4nV19k85Kvvvq1GPl6rEildUQ2LWqk+Z0pUotTS56e6WVXalpq6RflfwLDX4FTgr7 2T74FJ1ggy628QsJEPat/LziXxdsGsjOKdeK1Kud1fjitIm/1qMe63obkM8S4ErTqzuvvNJrN2hV Zvemq0J1h7Bn0+zCVFsluxHuo4re5aYxJUA4S4Br/fOxPrpTdaHaNVnvbBtnhXklbFlX/2MF/s6m MSV7e0TRfX1emS7fzow6FVxoZ2dTam/zUePsBJyqLl4GkwEnNeeV02FzK2ytVz6+YxhcFCwC5sIs MDbZrYIVcCcOdK/W/T17YOXgyRAn5f/PsAY2KG3r/p41YDry2Rg4w/nMgvnMITvNLki6u40unUg7 PU9C4LG5d2X7ncyz+3Q9LfWr7WKj7EK714S9t2Gczb6NsLtAv0R1vYTOa38h3F0r747Jt1f9qIV3 go6zd3Kz7qzyJ5iKd0xHs+5eezmXhb27PcvFz08wwVZgN7guDDDjtskPZwPxBJ9swr2DlSMm6l/Z sK8LjpNFuklbQ8s11jb38KWveBWztow+YrleSd1tHaUTsz42rC8F3MqtK04+zfK/4wn4Fo6JVwWL K+K1X2Kt/SmOjku3R5y8R8b/PKFZFCY7Hrh/DLI1erl/nBH2Exo+zaBzM1foQDmmdHEu+T3NZz0p bGon0oGeGL90KheS3J6h48EGywUBDlagd6EJgyQHvLcvwJobVGa3jfJiFyHmKdmHeUrGFQSYJ6fr AdvL1vQBjpMeGXW64kt6TuDzr8CHiLdaLi+ofH/zest3K7T50pfacffODbW7q7tIwS1fxw207lOW lMMs4pOTzhHfTQ9f7KFcVrdmD5CnmcIDfSuCTqhbGp3TlTw6hU3buTlOQb+n2UhwSepTQkjjYAkw LjqbI1nLB29nH2hs4F0OHqC7OgOgz0tsr/c9TkZebsMUgNnf2uRVf59Auuo20j1+N3dBuu8yofGC P/3l27GSvvqGOv8Kl9Izn8XLTVAIXEm8oND8qjHXTvOjxrP1lM7fe6dv7XN2KdpnJwDrQbhcph+L nx8KJMG+0mGypuCRZgPCGl8qiHmuOVzonlaM+jZhe4Jh50MMPMnDW0gMskELvDxPipsPE9Jrl8sD KrWcKrhyvyJDzkFnDWDHQvXTYnwbduptx5Zd2VzW0IIvC8FU9MwKqzsDCCoTV27FlD3YFSXFi2Vr SZtTyRCjCRjS7psAfuxhXjRLw83ExcnDJHeO+T6jIEQK5K6zWwhMgFE/up36Ak/qRr9TH/DyPAj1 rUJYGSBGYwD6Ockb44kBpGCpkfblAnguF7m55nTmeeIXKNnxofhb0IVbbwu6uDNFWPKGrrghyx6g jX0rHKiB6JqoWp4DM0sFwZ19HzXyTpgNXcDqiq5mLyQFswbQNSsADhuy2ooqfVbmg6IIX7CU8m1H Ul+QlJ0haYo/xZOF+mqBJlwRTLXbiqj5VPBkjwX2ExkDqhMT+zMMVVcsScIZoEQfpX2jEaSkYpPO C7kUUcvjMlGxqLy0YZE2mIN+MUIKgmq4tMUVaLg+6A7P9/+shhSgj6UJkiK9fHYa5Z4q50WV408j vaFYuIbPkrOiUQN/TUIKXnRvzby18tWk1CQvB+8zHpzs+X/d4l8PGmTQn70b3f0DfZvDlzLUvXe/ pSEPN/7R9b+G2Dp8X/3dB9nMP//iJ+9+R7qya62NRu549/NR+qKlsY2xpfCftLD2FpOWfqOlJZP7 4GHpYd3WUpuW/lcp9a7mvlf9xburN47LG883zAGBAvMNP/9fnz/oJd3phb+6t/byG52fD95e+58N b7V1r6VvDUUlt8dv/Uctzc07w/GX1m0YLKelf5iD5WLY/JfL0v97RbpvM9gHfd0Y5+teV/395Qz+ ZIPlNut+84AU+ZIUhW6h9p2gP3nQS5FeWPbRAqyu30wfapRIp943w6q0HhNADPEntGnaJlQkOUAz +a70o5YagPKG1HCZ4Zzuy7ytSFEX2GM9HC4fEQfRnXH5t+Brx9KPVdj4w67/S+pFf2fe0Z/m/bm3 KY+tJX5K3+Fe35ykZe37kcSIr+SOdJM4C+fazZcPenkld7SXzl9hXnq5Pejl1ZKRXsYGdZrLVw96 Kfd6obwkr6dC18GD44ofxXm90zUlSExb3//7UopcS5xrvrqWONdy97rf31oPjhb9w9Jr0X8tYv/0 AEPtGkPF81ezNq58IPZivxZCKljuSKCkcmJIK9IDo2PFcunjXkN/2RA+5ujUTrlsquvwTWmsP0p1 kn3w136kfTQZvVX/uKROaQn4w3fXafbixdMCirIPDekbeyBHEqGDUkoAotAEirdM9jgjsBEtFQiS vUALKieg1ZaUXtL6ZYCqyqh4KPORdtt074fvVfGOhozPu1aHlCU30tfhLbofvffjRwnvl6Q40BfW AhzUYx/GywiknoPAHxieEGWYwBUk4f4W7RmSfTX1BzcOwW12CWgONJ1Z/Dlby7/yw83l7dJJxeLm zEvWQcEimnDV1oHzKfFnlvGEyO/wkxNaNb21MAdYvHl/+WGXd63qZAj8KW81VBVdOioy5zRn2GOp Z5U5uLlOEtW+j1w1gO/8zn/54endC2LHm7o6tEC6APYUEO3UQhAVmYhhk7TZZ3Ihx84+0Pr6P+QM 5Pwpp8lYHyZc1Gur0gfJW9eCwJHGIo4yp/5ReQRoEUjyWGSQNFWoSdrkveARJJW3eQKeC30Vd0uB SsNVUJ6l6CZid+l7Fs53Npbm9o1Fv7+JjWV05eL1sduTHN+VHIub6y++Rc/X+ysm00aHS8UvT8Uv OWQmNBRaAWdL70h4BRyJ784wyB8jD/aUkqd2baiAYlALQFdtySRXl6Cwg47JsM4GzfbJPlidcvGA E+Cnb6f2/egR8pZawGUK9cogVaigSyxwhy5S8RD7kKlYokzZUo9dVK5izW20e/reDzyht0svVZxR S/taVlEGtUIa05e7TfWK+GgJlC/al031Wnpftv+/8JjLW5q+hdpT4zJcGe7cojXEXm+ryhV7UfVE SKQq1z7QxTv/IDN4y8hD96pyaYF2Yibxv7f3JLu17MbtDfgftHzZKJyawzaTkZ0RPSTr+Dr2SyDZ gOMkQL4+rIms6ma3jt7VleQbrc4hm2MVWSwWa4ilqtoDmp5Slh1ndBGzZbvQc3+fvonR44glg7OQ 9DixheCMI2tk4LkjFIjOJCZB48QSGkQZQnao5kjJIWQzrlJc2IxTMmT+lsapDKacmjruKaehqpbg 7unx2VFS7VFyK6P3iY6vRodi9N76UP6ASDEwX3J1WXF18Jhd8CG+4TOKZKREbl0i+COBt3F0DEV+ qCiF3SV0H0UZcJqC2JSqSiqKW/qRgVEepGrA4B/SMqWgZe6YP8soqaoZ8/mObHz1im2Dl2rUIkm3 MnffCVweoEoWJRD6K9wPK+SojMCKD4k+p6kyQALqqUPGWptTi0J6OWPs3mMUD1w9JZKxR9Ijkcac acpVpXuRHClYiWsopm161M5qeUhH6pR/p75l1kO7jnXNj2CbGaQWNv1qscYUv4CwltPUtRGcDc1f 1eEeAO86jAcEn1KdolTQYOSUy0b9iZqq9DfYVec20bFSjet5v2mXzNWhJzZRp8KU6JYJgQliciAZ HqMXCMUhBR+hOJRSFIc/M43hqpyilr9MKhmSqMudpbhwUDpwkp6zNgRNZxC9s7TwQCoNJbVU9kCE z46QbI8Q0h6+gan7xMZXYkPzdG9/Fn9E5MyMFTKWjF5RjB4R2+hZAZXToQz2HfW/Q833Khn9jlhT /cfzDcOGEqDbnP0dPNRED6Y8uYB3u/saygXT9fpjFOJIooQg6pD7koeWIL5BHDtW1z6fu3eD4Yzo cdk1cId/ZibyDUZlZhuaGKkd4bjr6NCWbeJqyt5MmfEdQLac78DJsj+aV3yj8SmKARcsuH718huJ 1CgDyqcgPcCzQZH7G8I64doKSWUA9PlM7lwaxCmIkzboXh4F/EAWQDwPQ2zE+GDkyNDwUganPvjN bBh4IzmyR2kSZic5hzEdXKLbIEWh7CsJOFtHEbDAxyoRnN4WqFt6jPSEdnNYtkYy4euJjX1TAuvc QN0Er5zk1zfAqUYkcw6YyC90DAD36giLYQrfYBR1/HVF8ESRfXuagrdABoTdcejPGhoF9cD+U+jy 6gGHGDyELq+YKrMP5+bfyPRY58KY55ACubeEbRKan5sGV2bPoMCJyIRBCXQBDpN39LTSCDABy4YB NRiin7ePUBWHRo9bmMSlSU/P8xLDWgWTV520i9M8ZI9Rk0M/bVqVDOA0nCOvoRS30qETUjhfwIV7 Rz4vA+Ksp/oPNw7YDzbDm+EBXsx37/cVyv0kPT5YmEaAnRdWFhyJe1QihnW6UQr8lDoMggqFybs6 X3AgY1MXnugH2+/ordNzSi3FK1IUhRRh+IpQ0Xk7bE4MTQJre8WqfW7Xz+36uV2/6XZd8qZVPy1T DEFXOGKYZPQZNJLQQkBZ8kIPsk3YY5T6Qi8dECmCP2cMWiVVOUUto9yWMzDyH1cFPELUBmqZU3gb CEQJMGOMEqvaMZ/fIMGEnd8FMLYTbGIMM7yWQsrT8vcBkAeWdQOVEzZsw4VmH2hnBrzxkZmR6MeO ZxB4FR1bhh9+xwaY3TyeCCDfaSAPowEf6JXTm50KwZaCJgb82sctcMynsfk4zpMaKD0IuybVR2eP +q31HUcwIeDEqaC8XO6hONN1RxFBAIM13KhBVwI+XBh/QiBNh0dAvOtA8O2Zjn4xvpW00/DkBAX7 Gg1Ig/ToBA/FCm+MSDp6dR8aBO/Tt7w9bwreTyNDMQZEj4D7aklnVI5zRgSqUmReJlCUUgSKMpgk cVVJUctfBlHljKvUFznW5jj5mJtnuCF/OoMIq6GcR8Jq6a6lyXuSfXbS+GBPmr7PMarR8y/Qn0h5 DaSYZ+i3PsA/JG4M7JdcoAollUltR4R/lJwyoULPYIMj5/SUjun6F9dEz9dEKO7KCyWUrz9GoouZ A4APUeCu4LEhSIko0Na+mjtH7skUcP05AeXrj8rMdgoA93Dc9XNoyTZwNeFsJnyTePKbjE7RBvgM ltZDOMkZUzgJHdSghJMAaLgwD+EkZ0zhZC4Ye3cKJ20vjwP0/YDvl7wp7cglwwsCSztywRBwLO3I nfWDcQxpR84YvYalHZiKIu3AwpuSdmBbWaQd2M8Qd+AwspJ35IryWBZ4YGoTgYcdM9HazFpSQ+KR OVD6EHpkPtVI7iEpYXohnbISfUAGGMyQ6AOaz01EHxni43kl+sik9DSlH6N5Z1KRUuH4bZ5ZI6PI DprCEMBqCUoYAlCEcGokDAHApCrCELAKzFlJQ9hMkMUhkqq8XiqlWCCSK8lHoiSLEobkmiZNwwQP FqJfVyUGgYwaRQwCbcL5RWKQXB19EzFINgxkxlvVpnoc0g8YzGCo8cu4bVE5wSnSomBhN4UesB7x mEWhByzXVkXoAUsZ3gOH0AMy1KVHkiLyyMTgev6o1+IVNeLHsQxBKdPNEsrPPfu5Zz/37LffsysG dVP+BUv0qNkLHeI+HBkN9kEJOJAY8PUfbKxhVwdRDigA0iQZuWHUO646UpEjr0qGw7jqUtWhYqq0 7ERvVTrmzzwormrGfHV55CBp0DOEnnUU2PdSTPm9AOQBqgDV25gwYWpQpeKLTrEsfjC9Yk0/BGKF jPllHRZ5zC6jhdHX44mw8l2H86AaERWm4oMRmBanmyT9xdlI4TeAMUh8Jvc0GjJA9XJFMj1NeLzz EBQMnETtLvxuM8jVAKUMwlcjCy6kvjgJZgkiaRmIHHcp09sCDu83DICFvPmIezvJmG0yUGcGajfO hgaUx7C9N4JlxOeQItseNTw+xFD4NoVyGXZGmFEKI5ZpTLAgI3qTEYH3YwrWT3bgWZiCcWpSMPlM NEuqSqqxDMdmXKW4MLIuMlDOmHM3BFJlMP20tPVAeg1ltlT7QNTPzqKwmbMIxFEt3SDI/ETH16JD iSne4XAfc/zI2DLIWLKMXrGM4Ml1U+ZIIwOsikoMCDUyOBIHh8MeCSaG2rH0Ge5dYsg0EmKPJBlk JCU10X5qOE5k4yrplT7yeLieGe7VDuWbbOksPug9vMRu+juACZyIcRMrZfrb5mlrUvR6Sra36Bxv mCcXVLUe9nKy84d1snRxyiS+9RAepHoRh5xBV/ZJJ+jdlOrKiSy2ynLekrFyIbOPYa8sfehD/827 lbkO8+QS2BxZbowDWNI3+beeFreF7FKmjXIhU49YJpbESFn1tZ/2e40AWWCvjJQxJQxT0+3QDaPM G0UUG+USjPciRBYZKKu2Dbf7hj0SE4fMnljfYiLP9xyiIHkK4jkDbTWFpJAdp9CUYeYpRIU/Mx3h qpISy02bcZXiwsEMlDPGrA3RUhlM0wy529NCQygtDd2T2LPzIUZ7PtxqDP2Ji6/ChWbf3vqU/Yh4 mRkrPCyZt6CYt4Am3dPuSDLIeAgokt/EsAjcz8ai7I4yxJhqkpFBHLxJVUkNu6ORgcCSqmQrJS0P UyrpmD/LKLGqHfPVDh13LHf/Qtvo7wUuD3JYsF2yJAbzw0a7KiNTBr/BksPhNpgLZSxXxKp5clrS 0yk7925jeRgNkLUyC9Nmc47ieYwGSeGXG8hNOd7HdN0N1VH8h2GvPDszcp13HMGEwDBXLmKruwej ymBjvcmFSHQJSnHEBb/DYdzsKA520x9jKA8ASIzTNkyZJR00UCUVVHVpjvguVw3qCJWMKdWBgsB7 dCwiPT9X2tNIi1WsEKRhiCkZZOUpFIosQIVCDQNRoVD8mWkSVZXUsPm0GVcpLMwRVJJw83m3QgwB 1BlEHy3t3JNWS3n3VHlHtM+OnOTNkXOrLfUnRl4DI5o1fPvz++MhR2eskLFkDuNkDis8xmuPkiMD uOQKArHhUbJmrxwL9e7rNvRP4XM/mKN4lBwJ4a8lg7h+qYkXAmlXbgvSK33k8XA9M9yrTco3t5pI E+Qlkr3vACYPUCOKWI3+iiCtsuNdlVGUZA2dqA/JWs1BiyFqblayJr2ccYPvMYoHqV7IKby9x9bN +veq26ZkbTVVI2urqSlZW92KkbVJN+rIf5eeZcZDxgbLx8jYBsgGCLOVsVV2LD5kbNUEARB0iZhN dbef/DsO4gHBpiRvmOLKDEFJsQSxjCXmRfRWN+PqV9BG0jfVvp74W/dKXF5Fr2wsZ8LEEN8IbRly g5GBQgkhNiSwEGoz5BlCbvgzUxiuKikRUdiMqxQWbnqUpakpG0KmMoTOaRK4p4+GeFq6uie7p2dG s2fGrdK+Tyz8TCwoZu7Nz9yPh5Ed2Jecm0QwyQC0v/7Vg98cxWS9Dy7dufsEsdPua///T2iAmzbS fHX3FOAU2F18OnewwlMnRxuZe0NwuAwRdShV0PQFCA6mW7rbPHnCAVa3pyKpNIChPZrJbJ20b6CP WfFzLQhFhy1m78hMw4mGY/D0nO+gToZbL42iM+Ipky2/A83dLxIez2/+ZJ4Q6QPCEraE6qdVHLFs 1GEh43s4WwOqztBha2pMOp4TxiWCcnSlAFXNRCMlk4aEcbKxXpWMWWO2dESd+CDHA42wl3lOqUDA PogV1795Ql3YHAZnBr3USqEUPBQBe6TSqVG5px2QC7pbbwUXfEBkgMpAJcm8I28MFQp7dIoQUNkY jOUzuQvNEcgciE5hEfgA3mEgLGTHHETT62ODVUPY2Cqq0KYtgo0H6CJ36KTOx8SAQvECvpyCKDBs 7EOrgOlWqeh4Acd8V/sdqSGzB7QBln8gJzTgGfiuxnaP7A3tyACtdz4InFLhTvHwDyxYe1GI2Ehq Ic2RMMjnuW62NYQxPIwA2MEQAMARg/6Bl4GElBBiHcC9rY81B8rQVSayK6i9BLrSUZRS8G1B/reo Zus4SA3DqVOGrXK1bsTLKQW24bWR5DmFgkqCnjOov/XVClrxcKeNaGIHT4Ut09Unws0QtjUEd6aH jeRx18PLRf/c6yTQDY+qMEZHo6eMVHBfw07uiO3rLkMI1YSpmug6uoGj287I9CUEKC7kQhZwUxH5 EBigMHpUpJ6+gMDTA7gcprAGCWkOnSOPVACDJGwceNPWmOBrYKZXcOU31PZpEB8+z5YaaNORV9zE GbrGFSKUF7LgkZ4AtXOI8CCOKwIa45FHtb7x7oIjXIAOOV7ZA2xoVvbvXwN62wXKuGFqK6jTHhuV xe0HBhIdoME7cuGCZDT4hI6ewPARpQxBvKtENIPrA3Kk698ipuCnbxkOm+CRVkBXDtqqpCBUqKqe 3AW/tPEdOzgPGx8G1tcBKOSmChEKIWrhebSpDwLC7a1ASBx7nxe2QcFQvLa/4BR7HICCU1VzVnu8 wIcE//I4IbCk6SPu3A1QPw+MhjEJfa2x0MR8n2sh3TjSswPIw5YH6h8QiR61nhshF7V1PSDly7ED 2/mGHEGfFBkNAhJhXp4A3xcDmxBWwD9SedCX3grhn+7gQ4Eax7nhOK+BySaXvmMU9TEdHHUwmb4m wNCon/8amH/B87cIdHgQ4wQwzDGyYn1lOzRTCfjgwBOAVZCrTGCsicNyUZOFjA4K1HlPqAvp6JSi 3W+h+OU4XEk7iSp+ir9i8MebAdxRAZvaGRbfjjazf7kwUFepxSQcGcuh2BOoNSrXoufNAJwDk08i a1CKDO8801Mia/0sh1RmRwN+UNckFnxIXclCDMwCwdip4jcmxUBdkZ4SaSWzukaEFu0ANyDOTFoL XSZcw885kscCSNF2oHF/mfuDMr56w1joP+73BV3MdkcZ7zE/gr5xhhiOBQ+4mSZ7vOFqut8mAfYV 5X1ThTq4pOzxPPqCE7mRrnuxCTJ78vRoXAd2dBWA35deuwPl35IsDXvVEQ2ywgZ8T/sqtrnASyeo xvMz0/Nzj3vQlN6Ame6c3davTPk+u5D2NPo1xvLAUZkh9qwCViZgyVOMr0UDZHzPA2DZgEvKi5MC X9nQczTQTO2qjmtTV5obBZ6kMpdlrJbZahlj1q3+pAvzq6Vvzixl31jxf2ZQgTpGrRrgRkcdajHo ebWgR9fCsq/REBcWHLRkQdZMIhoYmcrSnvaX4NvGGKXi6LN3ole+mr6SniWZubYgg2v3knwcNGKk 5XO05/T4/pOqIobHwaEogpoTg9uxhP2iM78Yn1ckay561bYMTW18qSlNFTsw3DGL8ppyzImXxdgY 2NQYFziAJpn6Fk0TpVQ2yrbiAvveZ+N5hwfdgDQa9fDSvgW7bvjzXDhxN8JgFl3YkREpPtJht+7C nV13suMGIZFtY2rMbeANIdGVR4OLM2GOx1ky1+zwRmWZrdOgCxNMwQDN74Hm9kDbozVatB6QoqBu a0uLae7HJ9nPc8VuZjfS131nQU1zU5trLvG5+r1ebIdu5s6qsief5sKvzdIMt98Yqh+np0hux5vM kEZV626fzuaLpQm6AU0x5/h4+LsKKr2ZAW67AcrimVhNBnAWVmpJ2Jr2QB1bC5eiLT4P67pbcLry o3rc3vq97/dXB6Me2zxXd6fgzzgWz/fszcfi3E37czLseJOXno27lD0n9+eiIrBr8n5Ckg2BN1t3 fdLOldIsbbAn6+KkNfg7IvfA8pzwQAa5A4HP8zwHDkhTY427NXLPOSCL9p8M5m7geE44oEmUNeIu T+5njnKD3Im8BW73bNQZW3UzFzX/7limFQ8l5Z/nxVbM2SDyC1Z98vmKcbcs/xmrfn7u79L7s355 +J9wJ/bMnrzJaeoGtun6yN5zTepAXrF1u+S2X3f2PL9gYtWRPSa241iXLCwjboVRe/+yKUPHFcJu YOSWR4Te6xpdC2zuGc0TxtNgVOPsFmZ4yRqb7Z7vr9Badrv75KjQaK2nOD3cSlbXlJdcmXYZB37M Mne2/DOXsBVpMqzTc9KDfdpKDJYShEu+f5Fx9xK2P5p1m44s3YtZ/l0y7Lf8BdM/14ddADaVdotP V96RJcv3zwVhLwI7bnjH+2uU3SAQWoqHtHyp7bb/2VXuuaudIQDhFKvLk2KH8Z8s3m66yJ0cE+by dYXS/SZf3ewMSgfO1ijdnxJHRN9wkTukD12Yi5wqftO9cH1P1Be5Z2SZxwy9MNaSzHS8dc2/9no1 q+wW69lN0KT2l7/lbXB5U50QO9xcz1M/7QFyk/h3LQ22gps10PTWWVPduZeSWauL2/MFXZtrVQNj Ca39tf7kmv8i4cMhwwgbVrIHXeNSoPGchGMU4Gu+ep2ZzJJ6BLh8+jA1Hy9eL4J9nMHHC7/dQ6gN D++NafFA+Zqj0m+GdVwNk1x48YEOrWOQ5xiKbznrDHAAmQWWQAhgNFl65Jsp2bGZTh6HRoR+LHs6 PpZRenj2so9tj7v6V+CO8ljUyMEnehQGA0JU37gveamt8urje0DNC9WGbvPYwtOiyaVqqApE04Ly nAZKUInoP7/JNPYgKa/T9DkGoZam+hVE2fa6hXKfsXlQnzvxwk1Ppa8/MlpE3E6RgBjUUN9T563O TnXdq+myRkhLFRc6qSGSLRH4Sth5HX/lIfE89/DDtDS6q7Vv9Fa0FoPW62m6NVq/bliku9n3Hypv gri1JcWa4rrZsWEjo1CKAih4AadlbMVq49VbfcBGzUEnSfHR1+KOs5GMQbil3VGA0kLlW/LzGvI0 01VsZloKiv3FlP6m2N+nmSGoIl6alFhT1EhM9q4qGcNTb0v28zZd+vaE4VdHenxnGCmAFfHHO+Aj bkQlo7QxKdlZE1qlaVhVA6nhAZ9gk8aQg/1G3arP1G2517CqUeaEyfmVwRMGoCmj5DFq+xm/GWgF DSv+FjNzNAQJTg0yEp3GLaQm6qPboZ4zGMHRK9RTQr4ExVRKauIdjGMm3iE18Bqjxbukx/dktgon 51bZLIM3MmaJrGCBIFNAkuvMBNoExR1rtQiYxlVhgEl9NhdEAVSVxik5vjKwxmcB3ug7qoOfUuob dVU0tIgvZ+DIp2QYbgHMEP+MjFkim895MsEMHlYnU/AaLA5AaDpupZQQwcgh/cq9htaMK0XwmUF5 JD2/s4vyWUD7LAcAgYPXJ/nrFKDmB4WyAasZG0rAJSdO3AxHN4A1vmf9MStIKJYZzq1IBxcp4XMG 7Iyc5aDD4NGoAcenPns35xKUwW3MKpFcPz7+ctfLGe/XdrYl7r55sHVIEcxk3LApiZ5C/wY2bwkd 053qRWDa+j1ywyDhcdvAtj2AMUFF7X4yggcyU8lQCkJdVgojDJZQpAWJDrI8KNWBVQkYwfeGSY8f YopU+ul55G7fi02VtdTYDxztA/owHY2b/KoEcEJQRGsPeObOq/ShdUTy7cTUmEd+BOcx4OAzgMlR byluicJEotZ5Lxj76RLJdztdY2yV2dQBC1l8rP+ibKgWCUjbcBGVwmGTKqiBln6UA7ACqqSWvuwq jpScc1ZyaxojujKqngKiJDTIACsZcNyZYKVC2Yju9wEJwd9VsuiAsFcbmKNltArq+COzGRAdAHYD mMU1QnxED6RgnQFFAxp1EUpKb7Owk1V2vEU+7PtGJV89W8RKfqR1hQmnBur70BUqh+I+IZOMgTyw yYCl1PNpzZsaVxAXF6V/82NfQ/8AJj4+9nne/fg7MEZB+5L+s0EgGzLs6YvxxyfmKZF1/eH+r378 j1/+4u97A9DIoRJYz3ClZ4v2bX0sehx0MIMOMOicO9NtB+0dmjCgCVGjRv8FG+3FtxLBeObHv+uZ /8aZrvUNGyX3N8vcO8lNuaPpuuyfJHfrS5jz/rgs+T8yrOD6vubM/5Sita+xfD3YP10AKypgTeC0 vpYrusv5xrB5+TQsxP77lcCQ1mDoJx6YE0Cwskxw+NVARuu3Nm75X5f9PUnRvmXS9dA+NnC2JXC8 gzMTTdk6W4jA+WeZsYcYNpeL+h+XM/71qoE1cL4sJ/coubG40CT335e5a0D8YZn75wvw5BPwoNJ9 Px7+P8OmrPdV7lwZsX0+Enh+v2z6G22sjwOfOhhLn0ka2jmOTlh85xgrsgXg3cNvkkEMKphvgiw7 AT1W/NosNEr0k96bDKyiGLaCsXK44BMFJnZBNTVKSE1bZTaFOvt06/EQtx4aAX5ZpFnH2bcje7E4 qaHJDnmfMPjRYC9++NuBxVpzOSyZzvfFsTomeazebde5E+M1bAeE134a1OsG7s4RXtxyQwBniPAa U/zBXzQibBkGaK9NrRZweNy5Q7NagC+DJ4+xWg4oHiUEo7bKRDH4D0xZrZaCwsXZ0iggFW2N3WIB LwGFVgtcMML23IopYQk+aKfG4wr59UBa9i4Iev5r5JYtj93/m2Xu42otLBfIoCnFpXKkz7HkUi8b +MNyAH+e53qd6+4lq3Hd7rqFdW/rSQy21DefLme2bvWn5bjWfQ1OKG/wGH7Z7poArKHw22XuS0jI uoUlGP53TqLGZ1C5bnYNnPXKW67c9czW0F3nLmf2uwEa2Gk/Y5usx7XG77LZP0541eYt0tc0NA5h QqcasSgaWiveiw0Nhcv5lhQNPRA+KSB0ztaYhA/80NSiSGiF24VXTY0SUtNW2dHQQhoLt524ZX3P gTbyd3LAri8rvSMQzugDNthG/g9wT02yDQplbmRzdHJlYW0NCmVuZG9iag0KNSAwIG9iag0KPDwv VHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDE+Pg0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBl L0V4dEdTdGF0ZS9CTS9Ob3JtYWwvQ0EgMT4+DQplbmRvYmoNCjcgMCBvYmoNCjw8L1R5cGUvRm9u dC9TdWJ0eXBlL1RydWVUeXBlL05hbWUvRjEvQmFzZUZvbnQvQUJDREVFK0NBTElCUkkvRW5jb2Rp bmcvV2luQW5zaUVuY29kaW5nL0ZvbnREZXNjcmlwdG9yIDggMCBSL0ZpcnN0Q2hhciAzMi9MYXN0 Q2hhciAxMjIvV2lkdGhzIDIzMSAwIFI+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PC9UeXBlL0ZvbnRE ZXNjcmlwdG9yL0ZvbnROYW1lL0FCQ0RFRStDQUxJQlJJL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAv QXNjZW50IDc1MC9EZXNjZW50IC0yNTAvQ2FwSGVpZ2h0IDc1MC9BdmdXaWR0aCA1MjEvTWF4V2lk dGggMTc0My9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9TdGVtViA1Mi9Gb250QkJveFsgLTUw MyAtMjUwIDEyNDAgNzUwXSAvRm9udEZpbGUyIDIzMiAwIFI+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8 PC9UeXBlL0ZvbnQvU3VidHlwZS9UcnVlVHlwZS9OYW1lL0YyL0Jhc2VGb250L0FyaWFsL0VuY29k aW5nL1dpbkFuc2lFbmNvZGluZy9Gb250RGVzY3JpcHRvciAxMCAwIFIvRmlyc3RDaGFyIDMyL0xh c3RDaGFyIDEyMC9XaWR0aHMgMjMzIDAgUj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PC9UeXBlL0Zv bnREZXNjcmlwdG9yL0ZvbnROYW1lL0FyaWFsL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50 IDkwNS9EZXNjZW50IC0yMTAvQ2FwSGVpZ2h0IDcyOC9BdmdXaWR0aCA0NDEvTWF4V2lkdGggMjY2 NS9Gb250V2VpZ2h0IDQwMC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDMzL1N0ZW1WIDQ0L0ZvbnRCQm94 WyAtNjY1IC0yMTAgMjAwMCA3MjhdID4+DQplbmRvYmoNCjExIDAgb2JqDQo8PC9GdW5jdGlvblR5 cGUgMi9Eb21haW5bIDAgMV0gL0MwWyAwLjg5MDIgMC45NTY4NiAwLjk3NjQ3XSAvQzFbIDAuNDgy MzUgMC43MDU4OCAwLjgyMzUzXSAvTiAxPj4NCmVuZG9iag0KMTIgMCBvYmoNCjw8L1BhdHRlcm5U eXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRz WyAxNzUuNjcgMzg4LjY1IDE4NS40NSAzODguNjVdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0 aW9uIDExIDAgUj4+Pj4NCmVuZG9iag0KMTMgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFp blsgMCAxXSAvQzBbIDAuNDgyMzUgMC43MDU4OCAwLjgyMzUzXSAvQzFbIDAuMTYwNzggMC4zMzcy NSAwLjUyOTQxXSAvTiAxPj4NCmVuZG9iag0KMTQgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hh ZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyAxNzcuMTMg Mzc5LjgyIDE4NS41MyAzNzkuODJdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDEzIDAg Uj4+Pj4NCmVuZG9iag0KMTUgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAv QzBbIDAuNDgyMzUgMC43MDU4OCAwLjgyMzUzXSAvQzFbIDAuMTYwNzggMC4zMzcyNSAwLjUyOTQx XSAvTiAxPj4NCmVuZG9iag0KMTYgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0Nv bG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyAxNzkuMjEgMzczLjEyIDE4 Ni4wMyAzNzMuMTJdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDE1IDAgUj4+Pj4NCmVu ZG9iag0KMTcgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzBbIDAuNDgy MzUgMC43MDU4OCAwLjgyMzUzXSAvQzFbIDAuMTYwNzggMC4zMzcyNSAwLjUyOTQxXSAvTiAxPj4N CmVuZG9iag0KMTggMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2Uv RGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyAxNzkuMDcgMzg4LjA0IDE4NS44OSAzODgu MDRdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDE3IDAgUj4+Pj4NCmVuZG9iag0KMTkg MCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzBbIDAuODkwMiAwLjk1Njg2 IDAuOTc2NDddIC9DMVsgMC40ODIzNSAwLjcwNTg4IDAuODIzNTNdIC9OIDE+Pg0KZW5kb2JqDQoy MCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv U2hhZGluZ1R5cGUgMi9Db29yZHNbIDE3NS42OCAzNzkuNDMgMTgxLjEyIDM3OS40M10gL0V4dGVu ZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMTkgMCBSPj4+Pg0KZW5kb2JqDQoyMSAwIG9iag0KPDwv VHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JCb3hb IDAgMCA4IDhdIC9NYXRyaXhbIDAuODc1MTIgMCAwIC0wLjkxODExIDE3OS4xNyAzODQuNDRdIC9Y U3RlcCA4L1lTdGVwIDgvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlMjIgMjIgMCBSPj4+Pi9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM0Pj4NCnN0cmVhbQ0KeJwrVLDQMwADBRBE4STn6nvm JqanGhkpuOQrBAIAwrIJqA0KZW5kc3RyZWFtDQplbmRvYmoNCjIyIDAgb2JqDQo8PC9UeXBlL1hP YmplY3QvU3VidHlwZS9JbWFnZS9XaWR0aCA4L0hlaWdodCA4L0NvbG9yU3BhY2UvRGV2aWNlUkdC L0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUv TGVuZ3RoIDY3Pj4NCnN0cmVhbQ0KeJxjYMAHqrdcQkZwwdqtlyccvDXt6B0gCWRDpIAkkLvh6rO9 d14DSSAbrhGoEij4+MtPIAlk41GPx3ys7gEAHq5i6g0KZW5kc3RyZWFtDQplbmRvYmoNCjIzIDAg b2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MwWyAwLjQ4MjM1IDAuNzA1ODgg MC44MjM1M10gL0MxWyAwLjE2MDc4IDAuMzM3MjUgMC41Mjk0MV0gL04gMT4+DQplbmRvYmoNCjI0 IDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9T aGFkaW5nVHlwZSAyL0Nvb3Jkc1sgMTg0LjMxIDM1OC43MSAyMjIuNzMgMzU4LjcxXSAvRXh0ZW5k WyB0cnVlIHRydWVdIC9GdW5jdGlvbiAyMyAwIFI+Pj4+DQplbmRvYmoNCjI1IDAgb2JqDQo8PC9G dW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MwWyAwLjcxNzY1IDAuODk0MTIgMC45MzMzM10g L0MxWyAwLjQ4MjM1IDAuNzA1ODggMC44MjM1M10gL04gMT4+DQplbmRvYmoNCjI2IDAgb2JqDQo8 PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFkaW5nVHlw ZSAyL0Nvb3Jkc1sgMTg0LjQ4IDM2Ny4xMiAyMTAuNjMgMzY3LjEyXSAvRXh0ZW5kWyB0cnVlIHRy dWVdIC9GdW5jdGlvbiAyNSAwIFI+Pj4+DQplbmRvYmoNCjI3IDAgb2JqDQo8PC9UeXBlL1BhdHRl cm4vUGF0dGVyblR5cGUgMS9QYWludFR5cGUgMS9UaWxpbmdUeXBlIDIvQkJveFsgMCAwIDIyIDEz XSAvTWF0cml4WyAxLjQwNCAwIDAgLTEuNDU3MSAxOTEuNzggMzU0LjFdIC9YU3RlcCAyMi9ZU3Rl cCAxMy9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2UyOCAyOCAwIFI+Pj4+L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMzc+Pg0Kc3RyZWFtDQp4nCtUMDLSMwADBRA0NEbmJefqe+YmpqcaWSi4 5CsEAgDSqwoGDQplbmRzdHJlYW0NCmVuZG9iag0KMjggMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9T dWJ0eXBlL0ltYWdlL1dpZHRoIDIyL0hlaWdodCAxMy9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRz UGVyQ29tcG9uZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAxNTU+Pg0Kc3RyZWFtDQp4nKvecqmaMtS88yolqH7ble59N8hDnXuvt+66BjRh8uHbZKDe/Tfh Jsw+cY8kNP3oXTQTFp99SCRaePrB3JP3MU1YfekJMWjpuUe4TNh87Tl+tP7KM/wm7L79Chfaeesl MSYcfvAWEx28/2bv3ddEmnD66Qc0dPzxe5JMuPzqMxxdfPmJDBNuv/8GRDfffb36+gt5JgAAd42I Mg0KZW5kc3RyZWFtDQplbmRvYmoNCjI5IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5b IDAgMV0gL0MwWyAwLjM4ODI0IDAuNTkyMTYgMC43NDUxXSAvQzFbIDAuNDgyMzUgMC43MDU4OCAw LjgyMzUzXSAvTiAxPj4NCmVuZG9iag0KMzAgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hhZGlu Zzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyAyMDcuMjUgMzY3 LjM1IDIxOS43MiAzNjcuMzVdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDI5IDAgUj4+ Pj4NCmVuZG9iag0KMzEgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzBb IDAuODkwMiAwLjk1Njg2IDAuOTc2NDddIC9DMVsgMC40ODIzNSAwLjcwNTg4IDAuODIzNTNdIC9O IDE+Pg0KZW5kb2JqDQozMiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JT cGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDkzOC4xOSAzODguNjUgOTQ3Ljk3 IDM4OC42NV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMzEgMCBSPj4+Pg0KZW5kb2Jq DQozMyAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMC40ODIzNSAw LjcwNTg4IDAuODIzNTNdIC9DMVsgMC4xNjA3OCAwLjMzNzI1IDAuNTI5NDFdIC9OIDE+Pg0KZW5k b2JqDQozNCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZp Y2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDkzOS42NSAzNzkuODIgOTQ4LjA1IDM3OS44Ml0g L0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMzMgMCBSPj4+Pg0KZW5kb2JqDQozNSAwIG9i ag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMC40ODIzNSAwLjcwNTg4IDAu ODIzNTNdIC9DMVsgMC4xNjA3OCAwLjMzNzI1IDAuNTI5NDFdIC9OIDE+Pg0KZW5kb2JqDQozNiAw IG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hh ZGluZ1R5cGUgMi9Db29yZHNbIDk0MS43MyAzNzMuMTIgOTQ4LjU1IDM3My4xMl0gL0V4dGVuZFsg dHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMzUgMCBSPj4+Pg0KZW5kb2JqDQozNyAwIG9iag0KPDwvRnVu Y3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMC40ODIzNSAwLjcwNTg4IDAuODIzNTNdIC9D MVsgMC4xNjA3OCAwLjMzNzI1IDAuNTI5NDFdIC9OIDE+Pg0KZW5kb2JqDQozOCAwIG9iag0KPDwv UGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUg Mi9Db29yZHNbIDk0MS41OSAzODguMDQgOTQ4LjQxIDM4OC4wNF0gL0V4dGVuZFsgdHJ1ZSB0cnVl XSAvRnVuY3Rpb24gMzcgMCBSPj4+Pg0KZW5kb2JqDQozOSAwIG9iag0KPDwvRnVuY3Rpb25UeXBl IDIvRG9tYWluWyAwIDFdIC9DMFsgMC44OTAyIDAuOTU2ODYgMC45NzY0N10gL0MxWyAwLjQ4MjM1 IDAuNzA1ODggMC44MjM1M10gL04gMT4+DQplbmRvYmoNCjQwIDAgb2JqDQo8PC9QYXR0ZXJuVHlw ZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sg OTM4LjIgMzc5LjQzIDk0My42NCAzNzkuNDNdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9u IDM5IDAgUj4+Pj4NCmVuZG9iag0KNDEgMCBvYmoNCjw8L1R5cGUvUGF0dGVybi9QYXR0ZXJuVHlw ZSAxL1BhaW50VHlwZSAxL1RpbGluZ1R5cGUgMi9CQm94WyAwIDAgOCA4XSAvTWF0cml4WyAwLjg3 NTEyIDAgMCAtMC45MTgxMSA5NDEuNjkgMzg0LjQ0XSAvWFN0ZXAgOC9ZU3RlcCA4L1Jlc291cmNl czw8L1hPYmplY3Q8PC9JbWFnZTQyIDQyIDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAzND4+DQpzdHJlYW0NCnicK1Sw0DMAAwUQROEk5+p75iamp5oYKbjkKwQCAMLACaoNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo0MiAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lk dGggOC9IZWlnaHQgOC9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50IDgvSW50 ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA2Nz4+DQpzdHJlYW0NCnic Y2DAB6q3XEJGcMHarZcnHLw17egdIAlkQ6SAJJC74eqzvXdeA0kgG64RqBIo+PjLTyAJZONRj8d8 rO4BAB6uYuoNCmVuZHN0cmVhbQ0KZW5kb2JqDQo0MyAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIv RG9tYWluWyAwIDFdIC9DMFsgMC40ODIzNSAwLjcwNTg4IDAuODIzNTNdIC9DMVsgMC4xNjA3OCAw LjMzNzI1IDAuNTI5NDFdIC9OIDE+Pg0KZW5kb2JqDQo0NCAwIG9iag0KPDwvUGF0dGVyblR5cGUg Mi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDk0 Ni44MyAzNTguNzEgOTg1LjI1IDM1OC43MV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24g NDMgMCBSPj4+Pg0KZW5kb2JqDQo0NSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAw IDFdIC9DMFsgMC43MTc2NSAwLjg5NDEyIDAuOTMzMzNdIC9DMVsgMC40ODIzNSAwLjcwNTg4IDAu ODIzNTNdIC9OIDE+Pg0KZW5kb2JqDQo0NiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5n PDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDk0NyAzNjcuMTIg OTczLjE0IDM2Ny4xMl0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gNDUgMCBSPj4+Pg0K ZW5kb2JqDQo0NyAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBl IDEvVGlsaW5nVHlwZSAyL0JCb3hbIDAgMCAyMiAxM10gL01hdHJpeFsgMS40MDQgMCAwIC0xLjQ1 NzEgOTU0LjMgMzU0LjFdIC9YU3RlcCAyMi9ZU3RlcCAxMy9SZXNvdXJjZXM8PC9YT2JqZWN0PDwv SW1hZ2UyOCAyOCAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzc+Pg0Kc3RyZWFt DQp4nCtUMDLSMwADBRA0NEbmJefqe+YmpqcaWSi45CsEAgDSqwoGDQplbmRzdHJlYW0NCmVuZG9i ag0KNDggMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzBbIDAuMzg4MjQg MC41OTIxNiAwLjc0NTFdIC9DMVsgMC40ODIzNSAwLjcwNTg4IDAuODIzNTNdIC9OIDE+Pg0KZW5k b2JqDQo0OSAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZp Y2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDk2OS43NyAzNjcuMzUgOTgyLjI0IDM2Ny4zNV0g L0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gNDggMCBSPj4+Pg0KZW5kb2JqDQo1MCAwIG9i ag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1 MSAwLjg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQo1MSAwIG9iag0KPDwvUGF0dGVyblR5 cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNb IDIxMC4zOSA0MTUuNTcgMjEwLjM5IDQzMC4wN10gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rp b24gNTAgMCBSPj4+Pg0KZW5kb2JqDQo1MiAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5U eXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JCb3hbIDAgMCA4IDEzXSAvTWF0cml4WyAw LjQxODM5IDAgMCAtMS4zODk3IDIxMi40MiA0MTkuNjVdIC9YU3RlcCA4L1lTdGVwIDEzL1Jlc291 cmNlczw8L1hPYmplY3Q8PC9JbWFnZTUzIDUzIDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aCAzNj4+DQpzdHJlYW0NCnicK1Sw0DMAAwUQNDRG5iXn6nvmJqanmhoruOQrBAIAyqYJ2A0K ZW5kc3RyZWFtDQplbmRvYmoNCjUzIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3VidHlwZS9JbWFn ZS9XaWR0aCA4L0hlaWdodCAxMy9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9uZW50 IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA4Mj4+DQpzdHJl YW0NCnicW74cO1iLA2zFBjZt2rQbGwCKH8YA+/btA4qfxAAQ8fOoAC5+HQlcunQJLn4XCSCLP4YB NPHXYPDixQs08Y9ggCn+8+fPL1++YIoDAKyQ8CUNCmVuZHN0cmVhbQ0KZW5kb2JqDQo1NCAwIG9i ag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1 MSAwLjg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQo1NSAwIG9iag0KPDwvUGF0dGVyblR5 cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNb IDIwNi44NiA0MzUuMTYgMjA2Ljg2IDQ0Ni4wNV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rp b24gNTQgMCBSPj4+Pg0KZW5kb2JqDQo1NiAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5U eXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JCb3hbIDAgMCAxMSAxOF0gL01hdHJpeFsg MS40NTA3IDAgMCAtMS40MDY2IDE5Ny45NiA0MTkuNjVdIC9YU3RlcCAxMS9ZU3RlcCAxOC9SZXNv dXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1NyA1NyAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMzc+Pg0Kc3RyZWFtDQp4nCtUMDTUMwADBRA0tEDmJefqe+Ympqeamiu45CsEAgDS8QoL DQplbmRzdHJlYW0NCmVuZG9iag0KNTcgMCBvYmoNCjw8L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0lt YWdlL1dpZHRoIDExL0hlaWdodCAxOC9Db2xvclNwYWNlL0RldmljZVJHQi9CaXRzUGVyQ29tcG9u ZW50IDgvSW50ZXJwb2xhdGUgZmFsc2UvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAxMDU+Pg0K c3RyZWFtDQp4nIXK0QaAMBQA0P//qxGLjIhMNLHIRMSM7a00y23bvZ3nw9i/hnQHznmLi6HDxSCE 6BFvGBAwjDUwSCmnQhbmQhaUUstXGbTWK1ANG1ANxpg9wcKREOF8EMFa65yjg/eeDiGECyfE6SsN CmVuZHN0cmVhbQ0KZW5kb2JqDQo1OCAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAw IDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5k b2JqDQo1OSAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZp Y2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDE5NC4wMyA0MTEuNTUgMTk0LjAzIDQyNS4wM10g L0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gNTggMCBSPj4+Pg0KZW5kb2JqDQo2MCAwIG9i ag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAy L0JCb3hbIDAgMCA4IDhdIC9NYXRyaXhbIDAuOTMxNTkgMCAwIC0wLjgyNTMgMTk3LjExIDQxMC41 M10gL1hTdGVwIDgvWVN0ZXAgOC9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U2MSA2MSAwIFI+ Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzQ+Pg0Kc3RyZWFtDQp4nCtUsNAzAAMFEETh JOfqe+YmpqeaGSq45CsEAgDCyAmrDQplbmRzdHJlYW0NCmVuZG9iag0KNjEgMCBvYmoNCjw8L1R5 cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDgvSGVpZ2h0IDgvQ29sb3JTcGFjZS9EZXZp Y2VSR0IvQml0c1BlckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggNDM+Pg0Kc3RyZWFtDQp4nFu+HDvYhAPswwaA4icxAET8IiqAi99FAsjiL2AA TfwLGGCKAwAQ/JLdDQplbmRzdHJlYW0NCmVuZG9iag0KNjIgMCBvYmoNCjw8L1R5cGUvUGF0dGVy bi9QYXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGluZ1R5cGUgMi9CQm94WyAwIDAgMTEgOF0g L01hdHJpeFsgMS4zNzMzIDAgMCAtMS4yOTMgMTgzLjUgNDEwLjUzXSAvWFN0ZXAgMTEvWVN0ZXAg OC9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U2MyA2MyAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGggMzY+Pg0Kc3RyZWFtDQp4nCtUMDTUMwADBRC0QOYk5+p75iamp5oZK7jkKwQC AMpRCdcNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2MyAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5 cGUvSW1hZ2UvV2lkdGggMTEvSGVpZ2h0IDgvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1BlckNv bXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggNzU+ Pg0Kc3RyZWFtDQp4nDtwgDA4fvz4yZMnj+MAEAWnT5++gAPAFVy6dOk6NoCm4O7duw9QAaaCR48e PUMCWBW8fPny7du378EAj4IvX758+/YNAL+F2DQNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2NCAwIG9i ag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAy L0JCb3hbIDAgMCA5IDE1XSAvTWF0cml4WyAxLjQ2NjggMCAwIC0xLjQ1MDkgMTk5LjM1IDQyMS4y OV0gL1hTdGVwIDkvWVN0ZXAgMTUvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlNjUgNjUgMCBS Pj4+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM2Pj4NCnN0cmVhbQ0KeJwrVLDUMwADBRA0 NEXmJefqe+YmpqeamSq45CsEAgDLGwneDQplbmRzdHJlYW0NCmVuZG9iag0KNjUgMCBvYmoNCjw8 L1R5cGUvWE9iamVjdC9TdWJ0eXBlL0ltYWdlL1dpZHRoIDkvSGVpZ2h0IDE1L0NvbG9yU3BhY2Uv RGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDg4Pj4NCnN0cmVhbQ0KeJw7dvHxMdzo3I3nWBFQ6vKdl1fvvkJDQEGI 1N3H79AQXOrBsw9PX32CIyAXWer1+69whCn15dtPIMIq9ePXHyAiVQqPgbicgcvxeLyMK6BwBS8A 3f9lKg0KZW5kc3RyZWFtDQplbmRvYmoNCjY2IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21h aW5bIDAgMV0gL0MwWyAxIDEgMV0gL0MxWyAwLjg3NDUxIDAuODc0NTEgMC44NzQ1MV0gL04gMT4+ DQplbmRvYmoNCjY3IDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNl L0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sgOTQ5LjYxIDQzOS44NCA5NDkuNjEgNDY1 Ljg5XSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiA2NiAwIFI+Pj4+DQplbmRvYmoNCjY4 IDAgb2JqDQo8PC9UeXBlL1BhdHRlcm4vUGF0dGVyblR5cGUgMS9QYWludFR5cGUgMS9UaWxpbmdU eXBlIDIvQkJveFsgMCAwIDE2IDMwXSAvTWF0cml4WyAxLjQyMjUgMCAwIC0xLjM0MTYgOTQ4Ljg2 IDQxMy4zN10gL1hTdGVwIDE2L1lTdGVwIDMwL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTY5 IDY5IDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNz4+DQpzdHJlYW0NCnicK1Qw NNMzAAMFEDQ2QOYl5+p75iamp5pZKrjkKwQCANMwCg0NCmVuZHN0cmVhbQ0KZW5kb2JqDQo2OSAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTYvSGVpZ2h0IDMwL0Nv bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE2Nj4+DQpzdHJlYW0NCniclcrBCsIgGADg93+SQRhE EBhhhwwSIogOQQQG2SEZSYcIEg+NjQ236e/vd/6KIs8k0zQHIWSWo/rzHNVfoDV/iUMpbf4Kp/tr BMZY9zcI/t+mcM79v0sZ/D1ICDH4B9D4H+OC/xQX/OeI2L9ExP41BPi3ESkl8O8j8H/0KaXg/+xL /tKjtU7+lwfz3y1jDOZ/Wsj/reH/r4b/zjlrLf7/AfocU1INCmVuZHN0cmVhbQ0KZW5kb2JqDQo3 MCAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5n VHlwZSAyL0JCb3hbIDAgMCAxNiAzMF0gL01hdHJpeFsgMS40MjI1IDAgMCAtMS4zNDE2IDkyNy42 IDQxMy4zN10gL1hTdGVwIDE2L1lTdGVwIDMwL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTcx IDcxIDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNz4+DQpzdHJlYW0NCnicK1Qw NNMzAAMFEDQ2QOYl5+p75iamp5obKrjkKwQCANMHCgYNCmVuZHN0cmVhbQ0KZW5kb2JqDQo3MSAw IG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTYvSGVpZ2h0IDMwL0Nv bG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE2Mz4+DQpzdHJlYW0NCnicldDRCsIgFIDh93+rERYR RkFGUkQShZFBkUFMb4qNDTc9x+N//V39VVXcpKS/Z4xNybV+Rq71c3K9X9DqPed8SSj0K0KhXxMa +U2ukRdCbNFiv0OLvZRyD5f0BzjIH4EgfwKCvFLqnArxl1S4v0bhXmt9G5b192FZb4x5BFH8Mwj5 H/pXF9G/u4jeWvtpovtvU5Gv67rIO+eKvPf+B/WBpf8NCmVuZHN0cmVhbQ0KZW5kb2JqDQo3MiAw IG9iag0KPDwvVHlwZS9FeHRHU3RhdGUvQk0vTm9ybWFsL2NhIDAuMjUwOTg+Pg0KZW5kb2JqDQo3 MyAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsg MC44NzQ1MSAwLjg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQo3NCAwIG9iag0KPDwvUGF0 dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9D b29yZHNbIDI3Mi4xMyAzNzAuODUgMjcyLjEzIDM5My42MV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAv RnVuY3Rpb24gNzMgMCBSPj4+Pg0KZW5kb2JqDQo3NSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDMv RG9tYWluWyAwIDFdIC9Cb3VuZHNbIDAuMjUgMC41IDAuNzVdIC9FbmNvZGVbIDEgMCAxIDAgMSAw IDEgMF0gL0Z1bmN0aW9uc1sgNzYgMCBSIDc3IDAgUiA3OCAwIFIgNzkgMCBSXSA+Pg0KZW5kb2Jq DQo3NiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMVsgMC43NTI5NCAw Ljc1Mjk0IDAuNzUyOTRdIC9DMFsgMSAxIDFdIC9OIDE+Pg0KZW5kb2JqDQo3NyAwIG9iag0KPDwv RnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMVsgMSAxIDFdIC9DMFsgMC43NTI5NCAwLjc1 Mjk0IDAuNzUyOTRdIC9OIDE+Pg0KZW5kb2JqDQo3OCAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIv RG9tYWluWyAwIDFdIC9DMVsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9DMFsgMSAxIDFdIC9O IDE+Pg0KZW5kb2JqDQo3OSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9D MVsgMSAxIDFdIC9DMFsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9OIDE+Pg0KZW5kb2JqDQo4 MCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0Iv U2hhZGluZ1R5cGUgMi9Db29yZHNbIDIxNi43MyAzNjkuODMgMjkwLjU5IDM2OS44M10gL0V4dGVu ZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gNzUgMCBSPj4+Pg0KZW5kb2JqDQo4MSAwIG9iag0KPDwv RnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3 NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQo4MiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9T aGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM4NC44 IDM3MC44NSAzODQuOCAzOTMuNjFdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDgxIDAg Uj4+Pj4NCmVuZG9iag0KODMgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAzL0RvbWFpblsgMCAxXSAv Qm91bmRzWyAwLjI1IDAuNSAwLjc1XSAvRW5jb2RlWyAxIDAgMSAwIDEgMCAxIDBdIC9GdW5jdGlv bnNbIDg0IDAgUiA4NSAwIFIgODYgMCBSIDg3IDAgUl0gPj4NCmVuZG9iag0KODQgMCBvYmoNCjw8 L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0 XSAvQzBbIDEgMSAxXSAvTiAxPj4NCmVuZG9iag0KODUgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAy L0RvbWFpblsgMCAxXSAvQzFbIDEgMSAxXSAvQzBbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAv TiAxPj4NCmVuZG9iag0KODYgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAv QzFbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAvQzBbIDEgMSAxXSAvTiAxPj4NCmVuZG9iag0K ODcgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDEgMSAxXSAvQzBb IDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAvTiAxPj4NCmVuZG9iag0KODggMCBvYmoNCjw8L1Bh dHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIv Q29vcmRzWyAzMjkuNCAzNjkuODMgNDAzLjI3IDM2OS44M10gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAv RnVuY3Rpb24gODMgMCBSPj4+Pg0KZW5kb2JqDQo4OSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIv RG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3NDUxIDAuODc0NTFdIC9O IDE+Pg0KZW5kb2JqDQo5MCAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JT cGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDQxMy44NiA0MjcuNTQgNDEzLjg2 IDQ1MC4zXSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiA4OSAwIFI+Pj4+DQplbmRvYmoN CjkxIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMy9Eb21haW5bIDAgMV0gL0JvdW5kc1sgMC4yNSAw LjUgMC43NV0gL0VuY29kZVsgMSAwIDEgMCAxIDAgMSAwXSAvRnVuY3Rpb25zWyA5MiAwIFIgOTMg MCBSIDk0IDAgUiA5NSAwIFJdID4+DQplbmRvYmoNCjkyIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUg Mi9Eb21haW5bIDAgMV0gL0MxWyAwLjc1Mjk0IDAuNzUyOTQgMC43NTI5NF0gL0MwWyAxIDEgMV0g L04gMT4+DQplbmRvYmoNCjkzIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0g L0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAuNzUyOTQgMC43NTI5NF0gL04gMT4+DQplbmRvYmoN Cjk0IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAwLjc1Mjk0IDAu NzUyOTQgMC43NTI5NF0gL0MwWyAxIDEgMV0gL04gMT4+DQplbmRvYmoNCjk1IDAgb2JqDQo8PC9G dW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAuNzUy OTQgMC43NTI5NF0gL04gMT4+DQplbmRvYmoNCjk2IDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1No YWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sgMzU4LjQ2 IDQyNi41MiA0MzIuMzIgNDI2LjUyXSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiA5MSAw IFI+Pj4+DQplbmRvYmoNCjk3IDAgb2JqDQo8PC9UeXBlL1BhdHRlcm4vUGF0dGVyblR5cGUgMS9Q YWludFR5cGUgMS9UaWxpbmdUeXBlIDIvQkJveFsgMCAwIDExIDMwXSAvTWF0cml4WyAxLjQyNDgg MCAwIC0xLjM5NDIgNDIxLjYxIDI3Ny4zMV0gL1hTdGVwIDExL1lTdGVwIDMwL1Jlc291cmNlczw8 L1hPYmplY3Q8PC9JbWFnZTk4IDk4IDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAz Nz4+DQpzdHJlYW0NCnicK1QwNNQzAAMFEDQ2QOYl5+p75iamp1paKLjkKwQCANJtCgoNCmVuZHN0 cmVhbQ0KZW5kb2JqDQo5OCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lk dGggMTEvSGVpZ2h0IDMwL0NvbG9yU3BhY2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9J bnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0ND4+DQpzdHJlYW0N CnichcpNBwJBGADg//9LlkiHJbMklugQzbLsSIeISGSiQ4w5NGbteGfej3nOT9NUrGrWNZuaVhTC VhRCx1NKhbDjzWHPm0PPSOHASOHISOFEgeFMgWFAtNYwjEgRJqQIl5wxpgjXHA63HA53gAwPgAxP gAyvBRfeCy58ImstF76REH6REJxzcvDey+EPwg77/A0KZW5kc3RyZWFtDQplbmRvYmoNCjk5IDAg b2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MwWyAxIDEgMV0gL0MxWyAwLjg3 NDUxIDAuODc0NTEgMC44NzQ1MV0gL04gMT4+DQplbmRvYmoNCjEwMCAwIG9iag0KPDwvUGF0dGVy blR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29y ZHNbIDQxNS4yOCAzMDkuNDUgNDE1LjI4IDMzNS41XSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5j dGlvbiA5OSAwIFI+Pj4+DQplbmRvYmoNCjEwMSAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRl cm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JCb3hbIDAgMCAyMSAzN10gL01hdHJp eFsgMS40MjEzIDAgMCAtMS4zNTE2IDM5My4yNyAyNzcuMzFdIC9YU3RlcCAyMS9ZU3RlcCAzNy9S ZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2UxMDIgMTAyIDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVj b2RlL0xlbmd0aCAzOD4+DQpzdHJlYW0NCnicK1QwMtQzAAMFEDQ2R+Yl5+p75iampxoaGCm45CsE AgDc3go0DQplbmRzdHJlYW0NCmVuZG9iag0KMTAyIDAgb2JqDQo8PC9UeXBlL1hPYmplY3QvU3Vi dHlwZS9JbWFnZS9XaWR0aCAyMS9IZWlnaHQgMzcvQ29sb3JTcGFjZS9EZXZpY2VSR0IvQml0c1Bl ckNvbXBvbmVudCA4L0ludGVycG9sYXRlIGZhbHNlL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGgg MTgxPj4NCnN0cmVhbQ0KeJyly28LwUAYAPDv/62mYyKRiUSOiUQ7kchue0HWdNv9e57nfu9/URSq E+DbGWNdqqr3qKoex3Gf5N8HJGof4ql9hNfqY6RWnyDpfYqh9yRJZmDGPgez9QWMrS9hHH0F4Ohr AHff+Lg753zr5O07J29P03RvB+kHO2A/WgD7yQLezybwfjFB9UyD6kKIaxO235oI/a4g9IeC1p81 Wn/VyP39Q+55nkspQ3pRFCG9LMsPaf6JXg0KZW5kc3RyZWFtDQplbmRvYmoNCjEwMyAwIG9iag0K PDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5UeXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JC b3hbIDAgMCAxOSAyOV0gL01hdHJpeFsgMS4zOTggMCAwIC0xLjM3MjEgMzk0Ljk4IDI4Mi40M10g L1hTdGVwIDE5L1lTdGVwIDI5L1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTEwNCAxMDQgMCBS Pj4+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM3Pj4NCnN0cmVhbQ0KeJwrVDC01DMAAwUQ NELhJefqe+YmpqcaGpgouOQrBAIA3jIKPg0KZW5kc3RyZWFtDQplbmRvYmoNCjEwNCAwIG9iag0K PDwvVHlwZS9YT2JqZWN0L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTkvSGVpZ2h0IDI5L0NvbG9yU3Bh Y2UvRGV2aWNlUkdCL0JpdHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDE1NT4+DQpzdHJlYW0NCnicnctdC0ExGADg//+vThplJzMlkzSW ZFIm2Sntho6cxr7ed8/90zT1RlXekRAyxvvECd4Qp0hDpJS2GH6cYfiRMTYH+4uc8wVMGJcw0bgC iEYhxLokFTclmbjNykQp5S4tH/dp+aiUOiQU4zEBEk8xkKi1PgeA8RKAx+sveDTG3DyoePdg4+ML G621Xa8iPnt10TlXHV8MzFcLDQplbmRzdHJlYW0NCmVuZG9iag0KMTA1IDAgb2JqDQo8PC9GdW5j dGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MwWyAxIDEgMV0gL0MxWyAwLjg3NDUxIDAuODc0NTEg MC44NzQ1MV0gL04gMT4+DQplbmRvYmoNCjEwNiAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFk aW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDM4Mi42OCAy OTUuNzMgMzgyLjY4IDMxOC40OV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMTA1IDAg Uj4+Pj4NCmVuZG9iag0KMTA3IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMy9Eb21haW5bIDAgMV0g L0JvdW5kc1sgMC4yNSAwLjUgMC43NV0gL0VuY29kZVsgMSAwIDEgMCAxIDAgMSAwXSAvRnVuY3Rp b25zWyAxMDggMCBSIDEwOSAwIFIgMTEwIDAgUiAxMTEgMCBSXSA+Pg0KZW5kb2JqDQoxMDggMCBv YmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDAuNzUyOTQgMC43NTI5NCAw Ljc1Mjk0XSAvQzBbIDEgMSAxXSAvTiAxPj4NCmVuZG9iag0KMTA5IDAgb2JqDQo8PC9GdW5jdGlv blR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAuNzUyOTQgMC43 NTI5NF0gL04gMT4+DQplbmRvYmoNCjExMCAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWlu WyAwIDFdIC9DMVsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9DMFsgMSAxIDFdIC9OIDE+Pg0K ZW5kb2JqDQoxMTEgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDEg MSAxXSAvQzBbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAvTiAxPj4NCmVuZG9iag0KMTEyIDAg b2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFk aW5nVHlwZSAyL0Nvb3Jkc1sgMzI3LjI4IDI5NC43MSA0MDEuMTQgMjk0LjcxXSAvRXh0ZW5kWyB0 cnVlIHRydWVdIC9GdW5jdGlvbiAxMDcgMCBSPj4+Pg0KZW5kb2JqDQoxMTMgMCBvYmoNCjw8L1R5 cGUvUGF0dGVybi9QYXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGluZ1R5cGUgMi9CQm94WyAw IDAgMTEgMzBdIC9NYXRyaXhbIDEuNDI0OCAwIDAgLTEuMzk0MiA2ODguMDcgMjc3LjMxXSAvWFN0 ZXAgMTEvWVN0ZXAgMzAvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlOTggOTggMCBSPj4+Pi9G aWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDM3Pj4NCnN0cmVhbQ0KeJwrVDA01DMAAwUQNDZA5iXn 6nvmJqanWloouOQrBAIA0m0KCg0KZW5kc3RyZWFtDQplbmRvYmoNCjExNCAwIG9iag0KPDwvRnVu Y3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3NDUx IDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQoxMTUgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hh ZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyA2ODEuNzMg MzA5LjQ1IDY4MS43MyAzMzUuNV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMTE0IDAg Uj4+Pj4NCmVuZG9iag0KMTE2IDAgb2JqDQo8PC9UeXBlL1BhdHRlcm4vUGF0dGVyblR5cGUgMS9Q YWludFR5cGUgMS9UaWxpbmdUeXBlIDIvQkJveFsgMCAwIDIxIDM3XSAvTWF0cml4WyAxLjQyMTMg MCAwIC0xLjM1MTYgNjU5LjcyIDI3Ny4zMV0gL1hTdGVwIDIxL1lTdGVwIDM3L1Jlc291cmNlczw8 L1hPYmplY3Q8PC9JbWFnZTEwMiAxMDIgMCBSPj4+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3Ro IDM4Pj4NCnN0cmVhbQ0KeJwrVDAy1DMAAwUQNDZH5iXn6nvmJqanGhoYKbjkKwQCANzeCjQNCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxMTcgMCBvYmoNCjw8L1R5cGUvUGF0dGVybi9QYXR0ZXJuVHlwZSAx L1BhaW50VHlwZSAxL1RpbGluZ1R5cGUgMi9CQm94WyAwIDAgMTkgMjldIC9NYXRyaXhbIDEuMzk4 IDAgMCAtMS4zNzIxIDY2MS40NCAyODIuNDNdIC9YU3RlcCAxOS9ZU3RlcCAyOS9SZXNvdXJjZXM8 PC9YT2JqZWN0PDwvSW1hZ2UxMDQgMTA0IDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0 aCAzNz4+DQpzdHJlYW0NCnicK1QwtNQzAAMFEDRC4SXn6nvmJqanGhqYKLjkKwQCAN4yCj4NCmVu ZHN0cmVhbQ0KZW5kb2JqDQoxMTggMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAx XSAvQzBbIDEgMSAxXSAvQzFbIDAuODc0NTEgMC44NzQ1MSAwLjg3NDUxXSAvTiAxPj4NCmVuZG9i ag0KMTE5IDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0Rldmlj ZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sgNzEzLjYyIDMwMi4xMSA3MTMuNjIgMzI0Ljg3XSAv RXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiAxMTggMCBSPj4+Pg0KZW5kb2JqDQoxMjAgMCBv YmoNCjw8L0Z1bmN0aW9uVHlwZSAzL0RvbWFpblsgMCAxXSAvQm91bmRzWyAwLjI1IDAuNSAwLjc1 XSAvRW5jb2RlWyAxIDAgMSAwIDEgMCAxIDBdIC9GdW5jdGlvbnNbIDEyMSAwIFIgMTIyIDAgUiAx MjMgMCBSIDEyNCAwIFJdID4+DQplbmRvYmoNCjEyMSAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIv RG9tYWluWyAwIDFdIC9DMVsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9DMFsgMSAxIDFdIC9O IDE+Pg0KZW5kb2JqDQoxMjIgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAv QzFbIDEgMSAxXSAvQzBbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAvTiAxPj4NCmVuZG9iag0K MTIzIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAwLjc1Mjk0IDAu NzUyOTQgMC43NTI5NF0gL0MwWyAxIDEgMV0gL04gMT4+DQplbmRvYmoNCjEyNCAwIG9iag0KPDwv RnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMVsgMSAxIDFdIC9DMFsgMC43NTI5NCAwLjc1 Mjk0IDAuNzUyOTRdIC9OIDE+Pg0KZW5kb2JqDQoxMjUgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIv U2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyA2NTgu MjIgMzAxLjA5IDczMi4wOSAzMDEuMDldIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDEy MCAwIFI+Pj4+DQplbmRvYmoNCjEyNiAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAw IDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5k b2JqDQoxMjcgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2 aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyA3MjIuODMgMzcwLjg1IDcyMi44MyAzOTMuNjFd IC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDEyNiAwIFI+Pj4+DQplbmRvYmoNCjEyOCAw IG9iag0KPDwvRnVuY3Rpb25UeXBlIDMvRG9tYWluWyAwIDFdIC9Cb3VuZHNbIDAuMjUgMC41IDAu NzVdIC9FbmNvZGVbIDEgMCAxIDAgMSAwIDEgMF0gL0Z1bmN0aW9uc1sgMTI5IDAgUiAxMzAgMCBS IDEzMSAwIFIgMTMyIDAgUl0gPj4NCmVuZG9iag0KMTI5IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUg Mi9Eb21haW5bIDAgMV0gL0MxWyAwLjc1Mjk0IDAuNzUyOTQgMC43NTI5NF0gL0MwWyAxIDEgMV0g L04gMT4+DQplbmRvYmoNCjEzMCAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFd IC9DMVsgMSAxIDFdIC9DMFsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9OIDE+Pg0KZW5kb2Jq DQoxMzEgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDAuNzUyOTQg MC43NTI5NCAwLjc1Mjk0XSAvQzBbIDEgMSAxXSAvTiAxPj4NCmVuZG9iag0KMTMyIDAgb2JqDQo8 PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAu NzUyOTQgMC43NTI5NF0gL04gMT4+DQplbmRvYmoNCjEzMyAwIG9iag0KPDwvUGF0dGVyblR5cGUg Mi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDY2 Ny40NCAzNjkuODMgNzQxLjMgMzY5LjgzXSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiAx MjggMCBSPj4+Pg0KZW5kb2JqDQoxMzQgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsg MCAxXSAvQzBbIDEgMSAxXSAvQzFbIDAuODc0NTEgMC44NzQ1MSAwLjg3NDUxXSAvTiAxPj4NCmVu ZG9iag0KMTM1IDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0Rl dmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sgNzA5LjM3IDQyNy41NCA3MDkuMzcgNDUwLjNd IC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9uIDEzNCAwIFI+Pj4+DQplbmRvYmoNCjEzNiAw IG9iag0KPDwvRnVuY3Rpb25UeXBlIDMvRG9tYWluWyAwIDFdIC9Cb3VuZHNbIDAuMjUgMC41IDAu NzVdIC9FbmNvZGVbIDEgMCAxIDAgMSAwIDEgMF0gL0Z1bmN0aW9uc1sgMTM3IDAgUiAxMzggMCBS IDEzOSAwIFIgMTQwIDAgUl0gPj4NCmVuZG9iag0KMTM3IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUg Mi9Eb21haW5bIDAgMV0gL0MxWyAwLjc1Mjk0IDAuNzUyOTQgMC43NTI5NF0gL0MwWyAxIDEgMV0g L04gMT4+DQplbmRvYmoNCjEzOCAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFd IC9DMVsgMSAxIDFdIC9DMFsgMC43NTI5NCAwLjc1Mjk0IDAuNzUyOTRdIC9OIDE+Pg0KZW5kb2Jq DQoxMzkgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDAuNzUyOTQg MC43NTI5NCAwLjc1Mjk0XSAvQzBbIDEgMSAxXSAvTiAxPj4NCmVuZG9iag0KMTQwIDAgb2JqDQo8 PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAgMV0gL0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAu NzUyOTQgMC43NTI5NF0gL04gMT4+DQplbmRvYmoNCjE0MSAwIG9iag0KPDwvUGF0dGVyblR5cGUg Mi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9EZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDY1 My45NyA0MjYuNTIgNzI3Ljg0IDQyNi41Ml0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24g MTM2IDAgUj4+Pj4NCmVuZG9iag0KMTQyIDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5b IDAgMV0gL0MwWyAxIDEgMV0gL0MxWyAwLjg3NDUxIDAuODc0NTEgMC44NzQ1MV0gL04gMT4+DQpl bmRvYmoNCjE0MyAwIG9iag0KPDwvUGF0dGVyblR5cGUgMi9TaGFkaW5nPDwvQ29sb3JTcGFjZS9E ZXZpY2VSR0IvU2hhZGluZ1R5cGUgMi9Db29yZHNbIDg2MS4wMiAzNzAuODUgODYxLjAyIDM5My42 MV0gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMTQyIDAgUj4+Pj4NCmVuZG9iag0KMTQ0 IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMy9Eb21haW5bIDAgMV0gL0JvdW5kc1sgMC4yNSAwLjUg MC43NV0gL0VuY29kZVsgMSAwIDEgMCAxIDAgMSAwXSAvRnVuY3Rpb25zWyAxNDUgMCBSIDE0NiAw IFIgMTQ3IDAgUiAxNDggMCBSXSA+Pg0KZW5kb2JqDQoxNDUgMCBvYmoNCjw8L0Z1bmN0aW9uVHlw ZSAyL0RvbWFpblsgMCAxXSAvQzFbIDAuNzUyOTQgMC43NTI5NCAwLjc1Mjk0XSAvQzBbIDEgMSAx XSAvTiAxPj4NCmVuZG9iag0KMTQ2IDAgb2JqDQo8PC9GdW5jdGlvblR5cGUgMi9Eb21haW5bIDAg MV0gL0MxWyAxIDEgMV0gL0MwWyAwLjc1Mjk0IDAuNzUyOTQgMC43NTI5NF0gL04gMT4+DQplbmRv YmoNCjE0NyAwIG9iag0KPDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMVsgMC43NTI5 NCAwLjc1Mjk0IDAuNzUyOTRdIC9DMFsgMSAxIDFdIC9OIDE+Pg0KZW5kb2JqDQoxNDggMCBvYmoN Cjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzFbIDEgMSAxXSAvQzBbIDAuNzUyOTQg MC43NTI5NCAwLjc1Mjk0XSAvTiAxPj4NCmVuZG9iag0KMTQ5IDAgb2JqDQo8PC9QYXR0ZXJuVHlw ZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sg ODA1LjYyIDM2OS44MyA4NzkuNDkgMzY5LjgzXSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlv biAxNDQgMCBSPj4+Pg0KZW5kb2JqDQoxNTAgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRlL0JNL05v cm1hbC9DQSAwLjg+Pg0KZW5kb2JqDQoxNTEgMCBvYmoNCjw8L1R5cGUvRXh0R1N0YXRlL0JNL05v cm1hbC9jYSAwLjg+Pg0KZW5kb2JqDQoxNTIgMCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFp blsgMCAxXSAvQzBbIDEgMSAxXSAvQzFbIDAuODc0NTEgMC44NzQ1MSAwLjg3NDUxXSAvTiAxPj4N CmVuZG9iag0KMTUzIDAgb2JqDQo8PC9QYXR0ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNl L0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nvb3Jkc1sgMjEwLjM5IDI5MC44NCAyMTAuMzkgMzA1 LjM0XSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9GdW5jdGlvbiAxNTIgMCBSPj4+Pg0KZW5kb2JqDQox NTQgMCBvYmoNCjw8L1R5cGUvUGF0dGVybi9QYXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGlu Z1R5cGUgMi9CQm94WyAwIDAgOCAxM10gL01hdHJpeFsgMC40MTgzOSAwIDAgLTEuMzg5NyAyMTIu NDIgMjk0LjkzXSAvWFN0ZXAgOC9ZU3RlcCAxMy9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U1 MyA1MyAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzY+Pg0Kc3RyZWFtDQp4nCtU sNAzAAMFEDQ0RuYl5+p75iamp5oaK7jkKwQCAMqmCdgNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNTUg MCBvYmoNCjw8L0Z1bmN0aW9uVHlwZSAyL0RvbWFpblsgMCAxXSAvQzBbIDEgMSAxXSAvQzFbIDAu ODc0NTEgMC44NzQ1MSAwLjg3NDUxXSAvTiAxPj4NCmVuZG9iag0KMTU2IDAgb2JqDQo8PC9QYXR0 ZXJuVHlwZSAyL1NoYWRpbmc8PC9Db2xvclNwYWNlL0RldmljZVJHQi9TaGFkaW5nVHlwZSAyL0Nv b3Jkc1sgMjA2Ljg2IDMxMC40NCAyMDYuODYgMzIxLjMyXSAvRXh0ZW5kWyB0cnVlIHRydWVdIC9G dW5jdGlvbiAxNTUgMCBSPj4+Pg0KZW5kb2JqDQoxNTcgMCBvYmoNCjw8L1R5cGUvUGF0dGVybi9Q YXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGluZ1R5cGUgMi9CQm94WyAwIDAgMTEgMThdIC9N YXRyaXhbIDEuNDUwNyAwIDAgLTEuNDA2NiAxOTcuOTYgMjk0LjkzXSAvWFN0ZXAgMTEvWVN0ZXAg MTgvUmVzb3VyY2VzPDwvWE9iamVjdDw8L0ltYWdlMTU4IDE1OCAwIFI+Pj4+L0ZpbHRlci9GbGF0 ZURlY29kZS9MZW5ndGggMzg+Pg0Kc3RyZWFtDQp4nCtUMDTUMwADBRA0tEDmJefqe+Ympqcamloo uOQrBAIA3NoKPQ0KZW5kc3RyZWFtDQplbmRvYmoNCjE1OCAwIG9iag0KPDwvVHlwZS9YT2JqZWN0 L1N1YnR5cGUvSW1hZ2UvV2lkdGggMTEvSGVpZ2h0IDE4L0NvbG9yU3BhY2UvRGV2aWNlUkdCL0Jp dHNQZXJDb21wb25lbnQgOC9JbnRlcnBvbGF0ZSBmYWxzZS9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDEwNT4+DQpzdHJlYW0NCnichcrRBoAwFADQ//+rEYuMiEw0schExIztrTTLbdu9nefD2L+G dAfOeYuLocPFIIToEW8YEDCMNTBIKadCFuZCFpRSy1cZtNYrUA0bUA3GmD3BwpEQ4XwQwVrrnKOD 954OIYQLJ8TpKw0KZW5kc3RyZWFtDQplbmRvYmoNCjE1OSAwIG9iag0KPDwvRnVuY3Rpb25UeXBl IDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAwLjg3NDUxIDAuODc0NTFd IC9OIDE+Pg0KZW5kb2JqDQoxNjAgMCBvYmoNCjw8L1BhdHRlcm5UeXBlIDIvU2hhZGluZzw8L0Nv bG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyAxOTQuMDMgMjg2LjgzIDE5 NC4wMyAzMDAuM10gL0V4dGVuZFsgdHJ1ZSB0cnVlXSAvRnVuY3Rpb24gMTU5IDAgUj4+Pj4NCmVu ZG9iag0KMTYxIDAgb2JqDQo8PC9UeXBlL1BhdHRlcm4vUGF0dGVyblR5cGUgMS9QYWludFR5cGUg MS9UaWxpbmdUeXBlIDIvQkJveFsgMCAwIDggOF0gL01hdHJpeFsgMC45MzE1OSAwIDAgLTAuODI1 MyAxOTcuMTEgMjg1LjgxXSAvWFN0ZXAgOC9ZU3RlcCA4L1Jlc291cmNlczw8L1hPYmplY3Q8PC9J bWFnZTYxIDYxIDAgUj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzND4+DQpzdHJlYW0N CnicK1Sw0DMAAwUQROEk5+p75iamp5oZKrjkKwQCAMLICasNCmVuZHN0cmVhbQ0KZW5kb2JqDQox NjIgMCBvYmoNCjw8L1R5cGUvUGF0dGVybi9QYXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGlu Z1R5cGUgMi9CQm94WyAwIDAgMTEgOF0gL01hdHJpeFsgMS4zNzMzIDAgMCAtMS4yOTMgMTgzLjUg Mjg1LjgxXSAvWFN0ZXAgMTEvWVN0ZXAgOC9SZXNvdXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U2MyA2 MyAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMzY+Pg0Kc3RyZWFtDQp4nCtUMDTU MwADBRC0QOYk5+p75iamp5oZK7jkKwQCAMpRCdcNCmVuZHN0cmVhbQ0KZW5kb2JqDQoxNjMgMCBv YmoNCjw8L1R5cGUvUGF0dGVybi9QYXR0ZXJuVHlwZSAxL1BhaW50VHlwZSAxL1RpbGluZ1R5cGUg Mi9CQm94WyAwIDAgOSAxNV0gL01hdHJpeFsgMS40NjY4IDAgMCAtMS40NTA5IDE5OS4zNSAyOTYu NTddIC9YU3RlcCA5L1lTdGVwIDE1L1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbWFnZTY1IDY1IDAg Uj4+Pj4vRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNj4+DQpzdHJlYW0NCnicK1Sw1DMAAwUQ NDRF5iXn6nvmJqanmpkquOQrBAIAyxsJ3g0KZW5kc3RyZWFtDQplbmRvYmoNCjE2NCAwIG9iag0K PDwvRnVuY3Rpb25UeXBlIDIvRG9tYWluWyAwIDFdIC9DMFsgMSAxIDFdIC9DMVsgMC44NzQ1MSAw Ljg3NDUxIDAuODc0NTFdIC9OIDE+Pg0KZW5kb2JqDQoxNjUgMCBvYmoNCjw8L1BhdHRlcm5UeXBl IDIvU2hhZGluZzw8L0NvbG9yU3BhY2UvRGV2aWNlUkdCL1NoYWRpbmdUeXBlIDIvQ29vcmRzWyA5 NDkuNjEgMjk4LjExIDk0OS42MSAzMjQuMTZdIC9FeHRlbmRbIHRydWUgdHJ1ZV0gL0Z1bmN0aW9u IDE2NCAwIFI+Pj4+DQplbmRvYmoNCjE2NiAwIG9iag0KPDwvVHlwZS9QYXR0ZXJuL1BhdHRlcm5U eXBlIDEvUGFpbnRUeXBlIDEvVGlsaW5nVHlwZSAyL0JCb3hbIDAgMCAxNiAzMF0gL01hdHJpeFsg MS40MjI1IDAgMCAtMS4zNDE2IDk0OC44NiAyNzEuNjRdIC9YU3RlcCAxNi9ZU3RlcCAzMC9SZXNv dXJjZXM8PC9YT2JqZWN0PDwvSW1hZ2U2OSA2OSAwIFI+Pj4+L0ZpbHRlci9GbGF0ZURlY29kZS9M ZW5ndGggMzc+Pg0Kc3RyZWFtDQp4nCtUMDTTMwADBRA0NkDmJefqe+YmpqeaWSq45CsEAgDTMAoN DQplbmRzdHJlYW0NCmVuZG9iag0KMTY3IDAgb2JqDQo8PC9UeXBlL1BhdHRlcm4vUGF0dGVyblR5 cGUgMS9QYWludFR5cGUgMS9UaWxpbmdUeXBlIDIvQkJveFsgMCAwIDE2IDMwXSAvTWF0cml4WyAx LjQyMjUgMCAwIC0xLjM0MTYgOTI3LjYgMjcxLjY0XSAvWFN0ZXAgMTYvWVN0ZXAgMzAvUmVzb3Vy Y2VzPDwvWE9iamVjdDw8L0ltYWdlNzEgNzEgMCBSPj4+Pi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVu Z3RoIDM3Pj4NCnN0cmVhbQ0KeJwrVDA00zMAAwUQNDZA5iXn6nvmJqanmhsquOQrBAIA0wcKBg0K ZW5kc3RyZWFtDQplbmRvYmoNCjE2OCAwIG9iag0KPDwvVGl0bGUoKSAvQXV0aG9yKGpzYWxkYW5h KSAvU3ViamVjdCgpIC9LZXl3b3JkcygpIC9DcmVhdGlvbkRhdGUoRDoyMDEyMDQwNTExMTM1NSsw MicwMCcpIC9Nb2REYXRlKEQ6MjAxMjA0MDUxMTEzNTUrMDInMDAnKSAvUHJvZHVjZXIo/v8ATQBp AGMAcgBvAHMAbwBmAHQArgAgAFYAaQBzAGkAbwCuACAAMgAwADEAMCkgL0NyZWF0b3Io/v8ATQBp AGMAcgBvAHMAbwBmAHQArgAgAFYAaQBzAGkAbwCuACAAMgAwADEAMCkgPj4NCmVuZG9iag0KMTY5 IDAgb2JqDQo8PC9UeXBlL091dGxpbmVzL0ZpcnN0IDE3MCAwIFIvTGFzdCAxNzEgMCBSPj4NCmVu ZG9iag0KMTcwIDAgb2JqDQo8PC9UaXRsZShUQ01URl9hbmRfY2FycmllcnMudnNkKSAvUGFyZW50 IDE2OSAwIFIvRmlyc3QgMTcxIDAgUi9MYXN0IDE3MSAwIFIvQ291bnQgLTEvRGVzdFsgMyAwIFIv WFlaIDAgODQxIDBdID4+DQplbmRvYmoNCjE3MSAwIG9iag0KPDwvVGl0bGUo/v8AUADhAGcAaQBu AGEALQAxKSAvUGFyZW50IDE3MCAwIFIvRGVzdFsgMyAwIFIvWFlaIDAgODQxIDBdID4+DQplbmRv YmoNCjE3OCAwIG9iag0KPDwvVHlwZS9PYmpTdG0vTiA1OC9GaXJzdCA1MDUvRmlsdGVyL0ZsYXRl RGVjb2RlL0xlbmd0aCAxMTkwPj4NCnN0cmVhbQ0KeJzlmE2P2zYQhnUOkP/AY3uxxOGXCAQBguwG LdIsFusFeghy0NrMrhHbCrRykPzu3tu8lGe7aiLGklCghx7kIUecRyOSM0NLOisKIZ0XjoQs0VQa UgoqHCQJirpSCWUUpBaaot4IU0hIK4wzkE5YKiFLYcuoBy5yfCEc7kkvRektJJ5RRLAHrABFeoyi AmqPDtl4y0YfAPHoaBnHgKyBlB6XsR6+wSerFRoY56QTHcL56HZ00xo04vNVHBw73RiLy5vu1Ui6 aF4KIltGtSClcV8WgjSeThKXkVBLzIHx0QIGFm9LUgtymA6Cc1RSvAVLX0QrdHwky1KowgAGhJJ4 L6JCKNLQkBRKRRgRGhamhOnV8Vmk0cBCEBlMOH7gHRouuumEsgqPwDwri4UgAtnFSVAguzg3cE6V BrMFhAZaxJfUWsUFxspZFzVOaIf5e/Ysv+wsCnGVL/NXm9tDE/IX2/ani8NNWBgqfhb59ZePIV+2 zWHVnm/DLn/9VhTvRH55K1S0e/786ZNvOJdDNvAaBloYYX9s3fNieRdCu5AFDbvhJoPUMKicDNLD ID8Z5IZB8sQUD5DKBElOJvkEieYsu5pjpOcYmTlG4zfjn39lv2XbrMp2uNa4RNZmAZqQvc/+yPbZ JltBu8hsllrU8Rt29MNk5rJElMrx2/riED7VYvOmWi3IJmjj9zacfwlH93C5gZNbOL9GX8DlGtpd dsCdCr1N9yqLzKdegeZkGooJEhkRSRxZe+LuJ5NINjQ1bZFJZBuamrfIJNINnVjh4elByUCxQAGK pQe1BsUF1QTlA4Vjaq6QCc/U5ExICZKenAnLRP7SkzOhSgSyPpEJvyd5mSCdSI890vm+ObTVum4w Vym/TuTNYZpORLweHzs9mkzRJsRPaD5tABPrIFb17rDfrKrVpt6H+4W0iaDS44OqP5EpZycEwg+c NSaBHx8dPWdtIjOZ8RHySFOUOC+Y8VHySMO5OUEbHyk9mk4sshkfLce4U0WisJjxkfKQCxJbxUyt MIlMYMbHR79aJ2CTThrTirXMUjtnavVIRZ+ZWjxS+dDOOT7YEwEwbDTnbGznnI3tnLOxnXM2tid2 5LDRiZ03bFQK/KN3c1bLSeHmzD3+FOPvsEvMCz2YVrdBDh/l4yeTq+6jSSfLgqVkSSwVS83SsGT7 0rEsWTLPM88zzzPPM88zzzPPM88zzzPPH3nxa8lRSpbEUrHULA1Ly9KxLFkyTzJPMk8yTzJPMk8y TzJPMk8yTzKPmEfMI+YR84h5xDxiHjGPmEfMUx3v+9XtreV1E8JVXbf5Vb0Nb6qP3ZeSuO6XVRP2 3e3um0lUdUtuHpB/378In9vX4YuQTH8F3L5uQ34Rf87368fONYbe1J/zZVi1+S+hWofm2I42D+1f 99vNPizvquhkVLzYg1C1OE9wv2k37ys0ut7vdfPhpq4/5Gf16rCDT53mPubE6GSbo0Q0da//8g6/ vf7ZptrWtz3FcrtZh97Y43Mw7Lapdg+J9xgVZ5tP/NYXh939W1F035W6GYr6gRgZK/+zWDolT8Xa vyX/bzH7rfT/lKoYku/E0ydfAQZAwJMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMzEgMCBvYmoNClsg MjI2IDAgMCAwIDAgMCAwIDAgMzAzIDMwMyAwIDAgMCAzMDYgMjUyIDAgMCA1MDcgNTA3IDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgNjQ2IDAg NTE3IDY3MyAwIDQ1OSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDQ3OSA1MjUgNDIzIDUyNSA0 OTggMzA1IDQ3MSA1MjUgMjMwIDAgMCAyMzAgNzk5IDUyNSA1MjcgNTI1IDUyNSAzNDkgMzkxIDMz NSA1MjUgMCA3MTUgNDMzIDAgMzk1XSANCmVuZG9iag0KMjMyIDAgb2JqDQo8PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDg1MzUyL0xlbmd0aDEgMTgyOTg4Pj4NCnN0cmVhbQ0KeJzsewdgVFXa 9jl3aqZkZpJM2iSZSYY00kghJBDIkEoLEJKBBAgkJDQVCIEIIk1R0CCKigUrurYVy2QQDWJBxd67 u5bFVVdXxbW7Fsj/nPvOweC6frv7+f377f/nJM88z3lPuee+95z3vsGRccaYEx9aNrWqYXzt96u+ HMKU26sYc51VXVHVuH/Ye4cZ238dY5aq6opJlU+vm76asTvPYUwXW1tVXfP+Q1/8wJTdjYxpPqmd OqVhcceo0xl79APGr7DUNvgrHn7rnX6mtH/JWO2cKQ15Bd+++9oHjPHXcNXW9iVtnbPK72hhLGM2 xve1n7zSE7j84AuMNfswf8KCzoVLvv66zsJYdhRjYfEL21Z0sgTmxfXXYrx94UmnLKja8mwhY3Mw PiNq0fy2jj+lHh2N+VFnxYtgsN5qyEd9B+pDFi1ZufqcK+2XMKaUMJY25MT5XUvfzn9rO2PX9eH6 PScta29764NXjIxt7mQsqWZJ2+rO5Jwh12A82plnaduS+Wkn1+NeboJ/wqM7l61Y2e9im7EecT1P Z9f8zhNvV44yNnwYLmdnwre6q/oaL99SPtdW9hWLw9Qo+z9a+5Tgh1MuXfP9d0e2hn1suBPVMKYw KhinZ0cZP2ja9f133+0K+1idaUDRfCosthTWynSqQWF2lsfmM+bYjuuqXbRZfDtajbqdOniIJxFr nmObFWZkik2nKIpWo2jfZkq/j93Sr64Apa7B42Hwv8dOazBcpaR5GL9anfQuXbi4U8we/uNq+LPs Xy7aKtb2r4/+31P0r7JbdEPZLb/GXNoUmkc3j7X/tE1zK6v9Na4xWAbLr1E0L7PZ/+wYbRHbqZnH Zv6DfVuPu973rOUfGacsZ6n/7Lr+bxbNQTb8H+knfCU1f4Wd+WtcG/Ps/Dm7voPtHHi9v1lLyT/2 zI71D80lnqHyxPHzapJZ/T8yh3IbS/5nrvnfKVjnjn+mv67vb5+hZhXL/Lm+mkzW/K+ua7AMlsEy WAbLf15RLuemf2mcjl3ya6/lZ6+zglX/U/2XsDOBNf9T6xFFM5xt/Z+c///Xgr/ZbwO6/t3rGCyD ZbAMlsEyWAbLYBksg2WwDJbBMlgGy2AZLINlsAyWwfIfXzQhJIS+wfYlalDKIaZl4juAQ5gHSgtl ZSksk+WyAlbJJrN61sAWs262mq1hu9itHnt/vzreiv4ZLIflo1cdm4pebewktmpAL97/FS45Hbin /9n+bzDGTEvh0/rblYffmRdaiQdICa0ySUWu+NbbjyvXTNBcounSNLEZrJkr3MbtPJ4n8Qw+lc/k LXwZ7+Yn83X8bL6Vn8O388v4Xv4Af4Tp+cfq+M9++p091JXQN/wU9suF/7iCAQtar9kQUmJVgg9r PvkvZmIs4mdsVep/85mhfiNhzi8s42/uWrX+zJ3DKu6d8af+y/X8e4vmV53t/9E97KvtmDunZfas mc1N/saGafVTp0yumzRxwvhxtTXVVZUVY33lY0aXjRpZWjKieHhebk52RlrqEG+KOzbKYbdZzaYw o0Gv02oUzrKrvTWtnkBaa0Cb5h03LkfUvW0wtA0wtAY8MNUc3yfgaVW7eY7v6UPPBT/p6aOevmM9 ud1Txspysj3VXk/g6Sqvp4/PrG+C3lblbfYEDqu6TtXaNLViRSU5GSM81bGLqjwB3uqpDtScvKin urUK8/WaTZXeyvmmnGzWazJDmqECGd7OXp4xhqtCyage2aswo1VcNqBJrW7rCEytb6quciUnN6s2 VqnOFdBXBgzqXJ7FYs1sq6c3+0DPOX12Nq81y9Lh7Wib3RTQtGFQj6a6p2dLwJEVyPRWBTLXvBuL W54fyPZWVQeyvJhs4rRjF+ABXard6+n5imHx3sMfH29pC1n0qfavmJDiFo+5Ce1SM6wNK8T9JSeL tWzt87F5qAQ21jdR3cPmuYLMl5fVHFBaRcsB2eL0i5aNsuXY8FZvsnhU1a2h35MXxQY2zvPkZMP7 6m8qftHuCWjSWue1LxLcNr/HW1VFfmtsCviqIHxtoXut7h2Wh/5trbiJxcIN9U2BPG9nIMpbQR1g 8IhnsLihSR0SGhaIqgyw1vbQqEBedZVYl6e6p7WKFijm8tY37WOF/Yd6izyuPYWsiDWLdQSiK/FQ 0qp7mjoWBNytrg7szwWeJldywNcM9zV7m+Y3i6fktQcyD+FyyeoV1VG4t5/0lp3FnRtSjZ4mxaVp Fk8LBk8NPrwVZWiw43GpVfFEK8o8TdzFZDdcJdRDqOPmQUWTWjlONGnE0MpxruTmZCq/sCRXaE26 1IBxwFx2GI6tia7zd5dGvcWCMj3V86sGLPC4SXWhBYZm+/l1KsIXoQtjhFE8znGySZOKkwubgmlU k3iKsZ4Am+pp8s73Nnuxh3xTm8S9CV+rz3dig3di/cwm9WmHdknjcTVqL6FagCWjWVaUSuzBmiyX fKxqvVatH6uO+0nzeNns6TF6Jzb0iMm9oQmZBycIN61PG9+2tSSiCEezBtHNW9Pm9dg9NT1tff0b 5/X0+nw9ndWti0aKObzjO3q8DU1lLnWt05rWudaIS0WwiXxiY0VONmJPRa+Xn1Xf6+NnNcxs2mfH 2+GsxqagwpXK1orm3iFoa9qHF4ZPtSrCKoyi4hEVMdM0VIxqf9c+vEc2qq1a1aDW2/s4U21GaeOs vU8hm13aFNi0ZPOpNlHwkGIXwcUIt9WeDvF41jYv6mltFoeLReNR4pcHuHcMCyjeMb1c0VsCJu/8 ioDZWyHs5cJeTna9sBuwMXg0h3NETOpp9SJOYUM1MRenragRU3r6+vsbm5Kfdh1uTsZWmw3MbAqE ZSH261InoF+tQCvMtYGN7W1iHczfJMYaUse3N2PbygnRZXwgDDOEhWZAjxp1jNiOGNSOZ4MHqI7f iEpgY3OgOUtctGlxs7qd7QE2zjsSj53m1KWJC+U190R4C9SziaNgSt0iKAxrYw1NZHGhios1k5MM Fqy83Yum9lYPvK1l7Q3Y6hRLTS6yzEdI1KbNV2FyhRqZuC1NqtlqCoTlYkL8Cm3OFUdSl2pobqbF q7UtoQ64tj1gxorSBrgyNADeQdN4sRb8bsFSRdcHxDT1fWyadzUii1i0OpMBzQFr6vg2BH8ab4bF WyIHG0WMMIfmOEhWg7hzC/yuSW3s67/Re0rygJKT7RUvB7ExmWsfNjZr7vmpITArKyfb+FOrVTX3 9BitPz+A/GW0HmNh9FTjrcFYMEzj6VPOuCMslk+A2CTF6VKcJsVGKTZIsV6KdVKsleJUKdZIcYoU q6VYJcXJUnRLsVKKFVIsl6JTimVSLJViiRQnSXGiFCdIsViKRVIslGKBFPOl6JCiXYp5UrRJ0SrF XCnmSNEixWwpZkkxU4pmKZqkmCHFdCn8UjRK0SDFNCnqpZgqxRQpJktRJ8UkKSZKMUGK8VKMk6JW ihopqqWokqJSigopxkrhk6JcijFSjJaiTIpRUoyUolSKEilGSFEsxXApiqQolKJAinwphkmRJ0Wu FDlSZEuRJcVQKTKlyJAiXYo0KVKlGCKFV4oUKZKl8EjhliJJikQpEqRwSREvRZwUsVLESBEthVOK KCkipYiQwiGFXQqbFOFSWKWwSGGWwiRFmBRGKQxS6KXQSaGVQiOFIgWXgoUE75fiqBRHpPhBiu+l +E6Kb6X4qxTfSPG1FF9J8aUUX0jxuRSfSfGpFH+R4hMpDkvxsRQfSfGhFH+W4gMp3pfiT1K8J8W7 UrwjxR+leFuKQ1L8QYq3pHhTijekeF2K30vxOylek+JVKV6R4mUpXpLiRSlekOJ5KZ6T4lkpnpHi aSmekuJJKZ6Q4nEpHpPiUSkekeJhKQ5K8ZAUD0rxgBQHpLhfivukuFeKe6TYL8XdUuyTok+Ku6S4 U4q9UtwhxR4pglL0ShGQ4nYpbpPiVilukWK3FDdL8VspbpLiRilukOJ6Ka6T4jdSXCvFNVLskuJq Ka6S4koprpDicikuk2KnFJdKcYkUF0txkRQ7pLhQigukOF+K7VKcJ8W5UmyT4hwptkrRI8XZUpwl xRYpNktxphQy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy7eEy 7eEy7eFdUsj8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8 h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8v8h8u0h8u0h8u0h8ts h8tsh8tsh8tsh8tsh8tsh8tsh8tsh8tsh1fuEQJZczBpjBs5czDJCTqdaqcFk0aCNlJtA9H6YJIF tI5qa4lOJVpDdEowcSxodTCxErSK6GSibmpbSbUVRF1kXB5MrAB1Ei0jWkpdlhCdRHRiMKEadALR YqJFRAuJFgQTqkDzqdZB1E40j6iNqJVoLtEcGtdCtdlEs4hmEjUTNRHNIJpO5CdqJGogmkZUTzSV aArRZKI6oklEE4kmBF3jQeOJxgVdE0C1RDVB10RQddA1CVRFVElUQW1jaZyPqJzGjSEaTVRGPUcR jaThpUQlRCOIiomG02RFRIU0SwFRPtEwmiyPKJfG5RBlE2URDSXKJMogSqep04hSac4hRF6iFJo6 mchD49xESUSJRAlELqL4YPxkUBxRbDB+CiiGKJqMTqIoMkYSRRA5qM1OZCNjOJGVyEJtZiITURi1 GYkMRPpg3FSQLhhXD9ISacioUI0TMZV4P9FRtQs/QrUfiL4n+o7avqXaX4m+Ifqa6KtgbCPoy2Bs A+gLqn1O9BnRp9T2F6p9QnSY6GNq+4joQzL+megDoveJ/kRd3qPau1R7h2p/JHqb6BC1/YHoLTK+ SfQG0etEv6cuv6Paa0SvBmNmgF4JxkwHvUz0EhlfJHqB6Hmi56jLs0TPkPFpoqeIniR6gro8TvQY GR8leoToYaKDRA9Rzwep9gDRAaL7qe0+onvJeA/RfqK7ifYR9VHPu6h2J9FeojuI9gSjy0HBYPQs UC9RgOh2otuIbiW6hWg30c3BaMRr/lua5SaiG6ntBqLria4j+g3RtUTXEO0iupomu4pmuZLoCmq7 nOgyop1El9KAS6h2MdFFRDuo7UKa5QKi86ltO9F5ROcSbSM6h3pupVoP0dlEZxFtIdocdLaBzgw6 54HOINoUdC4AnU50WtDpB20MOhGM+Yagsxi0nmgdDV9L404lWhN0doBOoeGriVYRnUzUTbSSaAVN 3UXDlxN1Bp3toGU02VLquYToJKITiU4gWkzjFhEtpJUtoOHziTqoZzvRPKI2olaiuURz6KZbaGWz iWbRTc+kqZvpQk1EM2i50+lCfpqlkaiBaBpRfTDKB5oajBJXmBKMEtt7cjBqE6guGJUDmkRdJhJN CEYhL+DjqTaOqJaMNcGo9aDqYNQWUFUwagOoMhi1EVQRjKgBjSXyEZUTjQlG4P3OR1OtLOhoBo0i Ghl0iK1RSlQSdNSCRgQdTaDioGMmaDi1FREVBh3ZoALqmR90iBsbFnSIs5lHlEvDc+gK2URZNNlQ okyaLIMonSiNKDXoEF4aQuSlOVNozmSazEOzuImSaFwiUQKRiyieKC5obwHFBu1zQDFB+1xQNJGT KIookiiCBjhogJ2MNqJwIiuRhXqaqaeJjGFERiIDkZ566qinlowaIoWIEzFfv22eW+Cord19xNbh /gH6e+A74FvY/grbN8DXwFfAl7B/AXyOts9Q/xT4C/AJcBj2j4GP0PYh6n8GPgDeB/4UvtD9Xvgi 97vAO8AfgbdhOwT+A/AW8Cbqb4BfB34P/A54zXqi+1VrvvsV8MvWk9wvWdPcLwIvQD9vzXI/BzwL PIP2p2F7yrrE/ST0E9CPQz9mPcH9qHWx+xHrIvfD1oXugxj7EOZ7EHgA8PUfwOf9wH3AvZbl7nss Xe79lhXuuy0r3fuAPuAu2O8E9qLtDrTtgS0I9AIB4HbzKe7bzGvct5rXum8xr3PvNq933wz8FrgJ uBG4AbjenOO+Dvwb4FqMuQa8y3yi+2roq6CvBK6AvhxzXYa5dmKuS2G7BLgYuAjYAVwIXIBx52O+ 7abJ7vNMU9znmha6t5mud59jutF9pibVfYamxL2Jl7hP92/0n7Z7o3+Df51//e51fvM6bl7nWjdx 3anrdq97fZ0vQm9a61/jP3X3Gv8p/lX+1btX+e9WNrMFypm+Mv/Ju7v92u6o7pXdmi+7+e5uXtXN h3VzhXXbuz3dGstKf5d/xe4uP+ua2rWxK9ClHRXoOtSlsC5u6us/sKfLlVQD9q3tstprlvuX+Tt3 L/MvXbDEfwIWuLhkoX/R7oX+BSUd/vm7O/ztJfP8bSWt/rklLf45u1v8s0tm+mftnulvLmnyz0D/ 6SWNfv/uRn9DSb1/2u56/5SSyf7JsNeVTPRP2j3RP6FknH/87nH+2pIafzVuniXYEzwJGrtYwOQE rIS5eMUwl891yPWpS8tcAdcBlybCFu+OVzJtcbxyShxfFrch7rw4jS322VjFF5uZXWOLeTbmDzF/ idFG+mIyc2tYtD3aE61xinuLrmusUbm8ijh/uHqvddHetBqbk9ucbqdS7XZy5jjk+NShcd5vf9au 2GzcZuu3KT4butvC3eGK+OgP1/jC80fU2KxuqyI++q2aaJ8VFjFjumVqY43N7DYr/nLzFLPiM5dX 1vjMOcNqmIZ7OGfcDtIYxSq4012Dc70nmus43ue9jQ1ZWRP7jGzaxIBx6qwAPyuQ2iA+ffUzA/qz Asw/c1ZTL+fnNvdypbIxECX+i61aP3PbNlaRODGQ2NAU2JXYPDGwEcInRD8ES+yNZhXNWXNWdK/I ylo5Bx9zVqzMUn9R492iliWM4nfFStTFT7daZ1m/WKgbaO4KlJXSuPKXR/1vL/zfvYD//NLLxJcM xvYrZ7AOZRNwOnAasBHYAKwH1gFrgVOBNcApwGpgFXAy0A2sBFYAy4FOYBmwFFgCnAScCJwALAYW AQuBBcB8oANoB+YBbUArMBeYA7QAs4FZwEygGWgCZgDTAT/QCDQA04B6YCowBZgM1AGTgInABGA8 MA6oBWqAaqAKqAQqgLGADygHxgCjgTJgFDASKAVKgBFAMTAcKAIKgQIgHxgG5AG5QA6QDWQBQ4FM IANIB9KAVGAI4AVSgGTAA7iBJCARSABcQDwQB8QCMUA04ASigEggAnAAdsAGhANWwAKYARMQBhgB A6AHdIB2bD8+NYACcICxDg4bPwocAX4Avge+A74F/gp8A3wNfAV8CXwBfA58BnwK/AX4BDgMfAx8 BHwI/Bn4AHgf+BPwHvAu8A7wR+Bt4BDwB+At4E3gDeB14PfA74DXgFeBV4CXgZeAF4EXgOeB54Bn gWeAp4GngCeBJ4DHgceAR4FHgIeBg8BDwIPAA8AB4H7gPuBe4B5gP3A3sA/oA+4C7gT2AncAe4Ag 0AsEgNuB24BbgVuA3cDNwG+Bm4AbgRuA64HrgN8A1wLXALuAq4GrgCuBK4DLgcuAncClwCXAxcBF wA7gQuAC4HxgO3AecC6wDTgH2Ar0AGcDZwFbgM3Amaxj7EaO889x/jnOP8f55zj/HOef4/xznH+O 889x/jnOP8f55zj/HOef4/xznH+O889x/nkXgBjAEQM4YgBHDOCIARwxgCMGcMQAjhjAEQM4YgBH DOCIARwxgCMGcMQAjhjAEQM4YgBHDOCIARwxgCMGcMQAjhjAEQM4YgBHDOCIARwxgCMGcMQAjvPP cf45zj/H2ec4+xxnn+Psc5x9jrPPcfY5zj7H2ec4+//uOPwfXpr/3Qv4Dy+xc+cwZriKsaMXHve9 8KnsBLaCbcTPZraNXcjuZ6+zeWwT1E62i93AfssC7AH2OHv1v/0N9AHl6Cm6JcyiuYvpWSRj/d/1 Hz56A9CnCx9guRC1SK3nR0u/vf+Tn9g+OXphv/1onz6CmdSxVuUFWL/gR/q/w/sV9f5iUVe2QNvU EZ8Zrjp6+9Ebf+KDejaTzWKzWQtrZW24/w62iC2GZ05kJ7ElbKlaW4q2hfhcgNpc9EIsUfWPvZax TqCLrWTd7GT8dEKvCNVE23K13s1W4Wc1O4WtYaeytWxd6HOValmrfgdf1FcD69kGPJnT2OmqkkyW TewMdiae2hZ2Fjv7F2tnH1M9bCs7B8/5XHbe39Xbjqttx8/57ALshx3sInYxuxT74nJ2xU+sl6j2 y9hV7GrsGdF2ESxXq0q03sMeYXvZbex2dqfqy3Z4jTwi/bJA9WEnfLAWd7hpwIrJf6uOeWs97l3c W0/oTlfDfvqAESeH/Ch6bkJPmoWeg5hl3U88sR33QPrHO6LaRer9/2gd6JVfskp/XDHAM5erNaF+ av17+mJ2JU7gNfgUXhXqWmhSV6t6oP2qY313qfXfsOvY9XgWN6pKMllugL6R3YSzfTPbzW7Bz496 oCK+jd2qPrkA62VBtofdgSd5J7uL9an2X2r7OfuekD14zLKP3c32Y4fcxw4g0jyIH2m5F7b7Q9aD qo3qD7KHUBe9qPYIexQR6gn2JHuKPcseRu0Z9fMx1J5jL7AX2avcCvU8+zM+j7DndO+ycDaWMd3d 8PMVbA5+dIhKKzQvIIpomIGVsjo2mc26h1nxuo9mI/nevc6qKmOO4T68yhXmQTJgZJxX+mxaxXpX fHy5967h+m0ax/g+nnNHuWEb0tzyI28deSbvyFuHI0rzDvO8N99+6237Z884SvMK337p7fxh3JHs UBEVrhgMUXpvSq4yPD2tuLCwYIwyvCjNmxKuqLai4hFjNIUFSYomSlrGKKLONS/8MFMz5YheWe8t n16oS4q3RVn1OiUhNiKnLNXeMCu1LDfRoDHoNTqjIWNERcrEk6pTfm9wJDqjEyOMxojEaGeiw3Dk dV34d5/rwr+v1J70/Q6NftTs8iGaS01GRavX9yXFxg0dlTx+ui3SrjVH2h3RRkOEw5JRNfvIZmeC mCPB6aS5jtQxztr6P9VadEnw3rw9CWxUVl//B3vsvA786R6byh/vsar8yR6Lyh/sMYPvw9824SyW 57Fklsazg5EN2v18KBvOhvHc3rDpcOVLhwV43tvqu8z+ysH8YalR4foB7tA7Q+4RjnNGJSnCj8JN WouiM0b55p46fv2T59U1XPz8hpITZta4jDqN1mg2hhdMWT5l+raOEcPbt8+qW1FfZDOY9Jq77LER 4VGZ6a7G6z678pofbp/t9Ax1hUfGR0QlRIal56VXb35g7an3bhiblpemdyThzm/p/06fhb1Txm7x 2VvHdI5RrMOGxeTlmXJjY+NDbogPuUFlq8pfCzfEh9wQ36c4fElD8i0WUyy6m+w28YGOJhN6mWLR xXQ3/vpi/Qd8caiwIcX15tgYa15sfq7enVHv9kf4dX5WjhIRU+ooLOd5L2WRwwochfZjylE6Oq+w 0FGYP6wlVW4ph5eHa4RK517HMWOR2I1JSgwv5NiCQjr1WcYod1xMcqRROVqoMTsTo5xJUWblaC03 RnniYj2RhmzXIs+wIbFhfJWObzbHu9PilthckZZ4o8Wg0xksRu3C73cYTAaNFo7Gltt5zH7D0CGW +AzXDzM0NyQNjTOHRSY6ybPa9ToHG83O3JNus0WFnKmyLcRWlT8VzowKOTNKdWaSKTe3QDizINYm PtCxwG4RCl0KRBc7SyqZZsq1pWvjUurj/PpGRu4Tzvsb3+UVqttO8ZKn0tLSvdHRzp/xV5ImpjAt DQbagk7teqsz3joiPt3rdR5d5BmboCiKMdIdG+uOMGbHT0tMdyc6+MjE4oL8WK5wtMRFeyKMtVE4 Y+bEgnTlUOm6UeMunvDDFwarcJbVoL05I8UUk+k+8lhRe2tL3pTdU5T7DJYwrTbMYhD/zya8pnkU +zGBZbLVvUP0Ia/pQ1tQH9qC+tAW1Ie8phcuiXEkCpcliv2XaLdY+aRED9oSxdcamCO1j5v26PUW bx8373HWW8SGC4U4cph0FkKc6qrj3JNckKQ1FOUKszifmkd9q25dfWFYZHJcXHKUcWg8dw6tW7xk UubeUTNasq++fPLCmiGaC9uuWFp2NPfYPsGtG2LKZ58yY8oJReFHvs2obRd33N4/VrdFl8zS2Sh2 ri/RlByRIe4iQ9xFRhTuNSMCN5ohHnwG7sRnYp6EYQkbEzQJBSHnFIScUxAKUwWhMFUQck6B+O5x RLLJmtPHM++IaUjVjujjWb1WxKfDLz0tnFAqA9RLLQdJwJY/TBfyQLp+YMBSRMAyJOl40fExC3dh suijmleeMSb/4vYLXt5aNWHHWzu2vnjeuMjMMUPHLx2XEWU8ekv6rEs7Oy+dm5k285Ku5ZfNyeiK cTv0yeUzy5Kyp9/wza7Lvr197vTrP7+yfscZnTlllSm2SK9yaOk9Wyc3bLt7Udf959Q1nnev+H93 a/sPa9rhtfHs/X1sbP8Hd9jsfNLY0O5Q2R5ii8qqI8b2Kdm+rAJfZBSfVOBz8LohBUMKLK5YMdYl ApbLbhcfGOIS/nbdreSLqLXHhaAl/rk7LsRRxHfaHPgj2pK7n6ezEczE03xmh2cEH+EzW/gkh/i3 dJNQIxwjHNFlfdyyd6xLl9kQjafQqxPOL4eXDztKS/PysrJa7IftYisK5x97BKKBKqFNmZKrlU+B Xre5+r/zGtFr2itXXdMydtmMUTFmrdFiDC+cunxCSUvlkIJpi5cumlY4avH5jVkz6soi9VpFozcb zHlVLSOLpxbFFzScsPSEhkJ+4qxz2wuiPSmxqW68dw0pGd6kEVMLR0welV84pnH5lPoN03Nsce5I syM2MgJvlwRvYuKwitTiyWUFhaMblmNnz8YzKtc8wQqZjwV8HluFuyKvQmMOiymywMNFwuFFws1F dvEAivr4N75wlp5uY9zCxO5nI0PPb2QoVo4MPUfB6gMf2acYfVGOmIdZkb1IGXWgiLMiXlSUO3Zo H3f5bM+l8JQUbeKHuRNGv2Gp07I8uFwc+ZbDDvG5fE6LfDMfzJrTUppHEaAAO38O3jBi0yMWDh+w +QuHh/Z8yKJVj4OBXB5dWFA8QlNuT3DFu8NHnV9fu6I+Z8zKmxavjc6fXDq6bXy+xYhAZ3BVTF9Q 1HZWY9p126o6KtzNU8cuGx1rsSAyWWaW16TWLBg7qXNCak3R1OGuRG+i0R5ni0uM9yZGZvvXNx6M ySnPrGmoqIJ3d8K7L+uWs6HiDbO3vJybkotDUbE4dA6KQ/4SddVfxX38rz6XM0tElCyPyGiE/7NE vMmyq4mOYvKFMaepeHiyVjesj+vuTJvgqrFPKoXs1dWJPSuiZkzpsbfMjz5r4TJcOH+MnKGI4aBM 0BByn8ERHa2G0ZcL27e3ZI2vqUk3RriceG3oDZGe2Di8QzImjhuXMW/rjIzbnEXTfZ4xvur0qrWV Y5pGxPH3u/efUeNIG5m5FKFVq0Vo1ZVgg2vFLj/yXmaJ1z55U6C7+vSO0RFDKwqO7myYUdZ+KmLG THjMo3kc6dnZvQnqObar5/iQ8BUTe0okJ+mhqJoeiqrpoWiaHnIm+EMxIL1PMfuseeE8PO59t89k Hece0seVOyInaD7Kx9x3hFnH5Wf3cX1vWJ3IA7MOqx88r4X8dpBeNX+bDOrpEOsHpoIaj6IzxJVN bMpru3j+8LHLdzZn1VcNjw3TKxFWW3qZf+SqDcm+lrLS6eVZFpGiXOuIc1jjUhMjfKfu6T7z/jWj 7PEpseGRsRHp7uSM5Ltum7GpKWtIltcYmSjeQK3wyxW6JSwN+e9Wn7t8FDe7SsXpLBX5W6mIiaVi d5SKzVK6n3/LGMsjr+WFnJUXclZe6MTmhZyVJzaUKTK5xlya7tKGDxVfE4idgKOu3RNep5skXsHq dio/9gIKvYRLByZ5A49gQXTMsV2lSUsb+AIaobnC4EiIEgl+7c5Z7efMyCiYd/7cKZt8hii32FNh N1SuqyrHDsKOGps82leTHic30Kq66XWbeuet3H9GbXWlYpbZypFq7J15a31Vp8/HXqrMF95qgbd2 IqplsSJ2m29oXnF58bJiTaQ4TZEeuCAyMjlbvEGyhbeyhRuz1fiGvfDt3qqs67IU8WfFXnHairSh zacN7TG1blaZApxW+C85OfvRjdrtWuWAlj+n5VptQt4baRNiP2wN7wxXwsM+TFA3WEsoti3vkkGt 4M0s2mwwizcIDqjemzxgWzmP33yKM71YdahBszM97kgwqaaz3tcxPs9iMOs1isZgLp6+3Lfsxq6R Zct3tZ9wUWvODZpTVo2ePSYFSWF68sTV03Od8U5DeFyENdJmMcfFRo5Z07dm5b7TqqtWXN4UefqO 3EnzR4h3d2r/d8pm3Wr8zdERjLaLA6gePFcoarlktHKFwpkrtJlc4guRw4am9vU/54uw49Wbajpc XBufdnjYOM8k+ziRAB8uKMfdZx0s/IzOWOHBYy9OejE66b71A9M7hHkZ3VU/aJXNWp1Rb3AmZbpS izzhjxvNYboI2+NGhKb/w963wEdVnfuutfe8X5lHksk7O+T9mgTCI4QYBgiPhGBiLAgomCEvgnkM kwmE94hog9KaejhWObZFrlXrz+O7+Di2JwjNoRa8HItIrdocWrVaUNpaRAqZ819r75lMQmhtb++9 v/u72Z/59nqv//q+b33rMeOAg4Juh9XKXM2O9EUd1elzM0w6UR3lcFrUeqM+ruSGsjVaW4IjQ7r8 O5zSVOyoJsZIGY4Em3bV6q8vyzVHmRyJ7Dcypg3/k7hbPEoqcF6/lZxwx9gLF7JZtlCHIS+UrA5a s7Bk9kvBi0wEs5X5hffQQZY1W1uLoNscZac1tYmqqGKxRKtl1mPl8hpwmxEoLNEmJmpLClVMxu6p TMjLWRfLJSuqLc/LdBvxzowq1oql1e+YbvxtTExDqfhx+aI8ae4vSqtv/oVUS+QlczZfMc+dkl1/ fslxJlwn9idsh2JDovV4Pv7LDzEmdcgYhwwu5SzsILFAOp0pYkzEZcAMLK9Tp3Muz+y0KbF0alZ4 Oa0QHFOzsrMtohITdzuibk9PmrIqcP2MxkS7c870383z1rum3vbo+o4H1xRY0yZLk4umZKZmTL3l 9prchanUarMNDzevKl5Y5Gy+efKiIueNt97wsZQbp9+1YXFzRaLoT0/NuKno+t4bC5Jj7a6UdJdg ENKuWzGrwrt0cqZ7xdS0itKS+PiagusasjJXzV2y+WuFel3a8O9vaZVKq3JWtKTOWHRlddlsQRdf mJsTM2decnEFs+8HcYbZj5V5Ctn0wuypNM+h2K8jZNgOxbAdisU72LLsTDEyd2tkHsPIfIeRuw0j yzMQN7IITpdWrCgvFlZnLIiv4e6Tn2EotBBxhBnlO218ydVobVevydOny150v84ur7lxrqriiq2V iPIDcWgpXthftXJLTVp8yJ6FqCWrKzOWL71yTyglcv1dXHVdy24P85R3Bi/RG9RFJIakkT0vzk6v Te9KF2OVvVysIgMed/A3N95YxdJjFaHF/puwHqfBGFlSMUqtGCU3JiTSGIjpoCHVjZrsq4EvxFur uHxOnctXvKGysuSPFo4iCwdbdpkxwgppxVgBOApmleWzv7AIxF1aecBaWlyWlzsTf4rmaQU0H0Pc L8521jq7nCJRdEwU5ERBTkLICfvfAA3WBRyugnVcjFfjir9a/goK9QmsUHXkE3ei3cosj9lTlpUd RrLjGPfW0wURVhg2T6YBh6IBh7LR4daZkhKLYErKFPlOh9/u8IsdbqQGeOYX69iJqq4iW2k2Yr90 fsx+igsk+9/oRUwRK9U8t7gaWyeN2zynumJBYWlVYU3YuHEGYg4otDuYqdwL2WYqBs9tnX/B5y8Z /LVmQIw8A5zy5jRGfUKeCA5ddEGla2b3fObwnWkObWzBPNdMf3heaOxJzthkq7bm3qrSFZXF1sIb Fi/MuGlDVerIDEmfOWaGXJ0i7sKyIop6o27j0tqEojk5kyvzHJg6NSEPAg1OIXvdUbIGGVOcyVgt KT5krDbZVj/FyHZvsk9hnl92Mdy7IP9Fxa0wp+I2FFbnxWdUhUTPfH7Yr4TuRhRpfwXnEvPXnEtY iN9e8lecyyhBQUANzLewvfz7kJCDZJPH3Umzc2mOnebaaJaZZplolo5maWmeSHMFmqJsUVMUgaUo e64UZc+VoggshW21UooM1BDNzkPRTFzRbFcXzU5L0Uxm0a8IBnYf8GIUWeKFmuLZN1ujqtOx71cO R2x/r4gstNGHyEIPHXMRrh1zgyK+X9b9r76u73dOn9n9ZDfeM55KrFhXW9VWmZY4e13tonWVEv2g 8+W7Fs/d/oIP72q8t1btXDNz6q07l1Tv9MycunonOxkO7xXfgmzYyTDAToZp0w2KlRgUKzGEvI9B Gb2BL0Ex8qGQHw/5rYh8Phz3VFhlrb3mqXC8Q+E4NnLtQ+F9q3Mq57gzIowlOibRrs2tWXJD4Zq7 2aGwhB8KF2RXbp5XsWJGAv14w6t3LLROmpo+XBHyhaqPYTOiCOvZlFeRG1Oz6+me+bc3lTty500e 3nfj8vKmrfz0A2k9pEjrLncixJVqzGcTJt9gCh2QuZPLZyefPFIim02JYk4lipcsUcysRBFoCT/5 xGRWGa/LT1VZXezkk1Bdyk4+1iXq2mudfEbJbJpNvtsO2Ytz2rVPPno2zVKjtbnVi6qymYimNH7r 1pwF8xfmsQ87opNs2qtOP8MvhCRFj+fOTI8KnYBsmbNyO0KiG/6TfASSj9M4AnHvJDzG73UaX/BO o1lRilFFKUOPChlXlGJ1Ucy47MSNZZ6wRYIwKyMJsLlMtz6/OisqRqqKYV6Hu3tadCR0BxYpDNlE rmFEGuExQaPX6ZzJGTHxxdPK0se6mcw5ZTOTzWkZySaVSMU1sSk2vV6vi3bVzLjyzNWO5o7pldlR os5g0FsS2Yp6Q/Cc8AZGXEXecJuKFs9eXLt4x+KnF6sjLhwvKBeN3CjmsMsFx5iLSH4BSd91p8q3 jvy+kZmYcunIDjjM5yS+Qi/wj0oM7ArM5Ea6iW3os9DebNPTJsHkem+G4Xe2OluDzWsT5cvFX7Kb xerY38qTMXytqFwqroJ1RV4qjuyE/tZLReGNktU7ry++aX5xrEHFLg3zZy8rzauckpjtrlt6gzs7 t35LfcaistwYrSiKWoNGP2l6VVGeOzcmx12/9EZ3NrXMb4e+nfHRGamOBKs2UUq0p0/PzJqakzop v2JZ+TRPVYHJHmM1RcVabfFWbWx8rCO9OCl7Wo40Ka/8a0wXacHPhA7Vv5IycssLucSWXqjIvFDR RaGii0JlQhYqVlnIjNDkNBeeS1+UbD7nXDQZc/FZrey2jzOzK1HuHo4fkS9mVOMfD0cfImNDh2mh Q2eVcl3OBU3u5O1RdrXOrNsW2qh9xG7+7FEfzVjozEiK1qn1atXNyZOsFr0mc3H39YJFPh+eCn0Q cko+QQ4bVt2qN+jVljg27r3slkZ8FXuC+9yp2AkYs5kFZTMLytaxfRZ3UtlWvuWiXx6UZ1qqIpVU RSp4X+RzkwWYWFJDkzVVsVFsn7906x2FVdlGdXwVNmbqkasaNj9D/ipsUuNe1YycMriLmj5j5NLm Ia09OcaZbNMsuZ8v/dpo+VjtLFpUXLFlvjY6FTPXrg/vCDYuvb68dfcaYVJodl75vPbWeZnLlwo9 oRQmn2nY9e6CfOaT918mCzFhroNRlLLDdG4pncHemS6alUazJJqVSrNSaFYyzU6iOSqaK9KyWXRW GZ1VSMvZLxvG0CVW5TjC3m4DBGiV0II1Sklmb7eJuTaWHDWnipdj1z+zrbXWLusOq8rqtscuspZU ZVaV9RfQApZXwOax1RG7qLVgY4EwH6nOGj2T7FurMEVXHZk9+3j+qnxImG0f5BlK+L4hvINAdj5O 1trQh55itlYMff4ZOkZjnXA4ZzjkxTUiqN6lUg9/IZqdOSmpefEm8UeC8LRoTshNSc1GbPhLtQr7 XWfSJLtO/IUg/Iegt0MRqXad8LZATwl6R1pCXLJNK35PGx11+QdGi05U6SwG4Rt6/ZXuUEy8KSpa qzdqBVFr1l9J0OuFD/VmuAIclq7EhWKCzsD0lYs97mLoq4jc9TKZDMHY2H0hs2QXs+FZLhoHizzI Ph+Io07FWmNDSbFUj6A7j52kWJ1yQkvT6XQjNUpsw8u0YjROLs6tSjfakqts4U3tzNk2O5WvwwgT bH4+/28VO0HERsvGmy1ymWZlTZ9BIVXlkODgYoyNhfDFeTpHdmpKeoxRdfptlTFmUlJypo3qadzw FzrqyJaS06MNquMnVAZbamJypl3QD39ZYHGY1KLWqKXNw/+Cl6g2OSz0RfqYxWFWiRqDdvhZWqth ny4bo6OGV0M+K7A5eVt8keSTWS8TK8Yayz7RzOKfaxYhf6q+Ui/oM23YfD4fvygqm29CFxN+BTYF Pv/4qsnFylY9DR6M37fQNMWXpXE3xj7HoywovK3RWXRXTsUkMi3SbwzvsDpUerNeUBltJi1LG+6h j+rMes0CR6JNm5Q2yRIbG28V1qVl2hHXWGJtkiXOmWC9cr/WihVToIbgBfquejVOwrnE8kN1ZuIS 6wJo4L03Ru7jpolZ4dP3mC+I/EjLvqCRZNfaqC4mPSkxPUZn0cfnpKbmworiclNTc+L1tCe0exFf MdlNao3JZvrzzLT8RKMxMT8trTDeaIwvhJy+HfyCdpIhYiTOZ4mGfWrHPjfWizCI45hph5irjzj8 dxZVlLvYX8fCItd8/DFbnU9fEFzCdSSKWF4gWuM5FWEfGyu3XGlyXS5Hl902vNqOhx6AtNT0y+yU 1KysFI0tAa3cOfwY/aP6HpJOJrljRGbkIlvwRa5SMSbVeCeZXYRlSP64T4MVxu6Evck26RK5BuWp TD+7ddWtN6upJTnenuAwidPrS5NSZ9aXUL01KdaZZBXUa346vOLU28Mrf2ayGdWCRqdu+c/T761f /+4v3mxVaTQwOCsb12Yg+giI0kjJy8Qu+3+7sp6y9w8ZMjv/qNPId2wywvwp4U8ktaGZMt0+baqQ rWjUGWunHyWV3jBdNDkS7AnJZqq+ZfXq1SrBmuSMSbLphNYeIX79e6f/s0Wt0whqGNnr9LG3T9HH fqq3GoBOozo+XIu9+T1ii7BP3ROyosSshdaFsKLjUyKtKHSYGpMSGyPcobE67fa4KI3TEJ3mjEuL 1tPhr49KK84S7wpvgv9nKDQ8eXSa1QpZPUWI+D21k7jIB+6MjBSakUwzkmh6Is1IoBnxNCuOZjlp Lj+E2pkPKua3sFHCkoZiStj3EEiusiPJVSScq6zNucranKs4uVz2ZQZLShyrFGdk3Ghj6w6q4H3y ebRpUz69ikgfYE3YmFPUo8Z+G7U57C/R2c+n1+fifK99ln1DBL7hynG+H2TPcXZBzi/K83/CNoP5 JH9kpVmleA5lVqZhlmvkFWZGpnJfYuMfTX1PYzBrr9yiNRk1Gr1ZRy2X2F24qDHqaZ7KZI+zYzHX fIL5q65kOz6tNcFhT7DpxdP/bFCZU5y2OKtJ8++iSkVVWqPmz/fqMVUgbR+k/ZA6jVSQvW5z7nSa n0Jzk9mq7WZidTKxumksO6jH8ukTK/HVQSg8WJIJIjMVWc98RdhBjLJwjGyNNrJbEFvpTEmamfgS dR0sidW4brTiJJsTkpC8ey7i34pg55DjbMvMT7RcRnw1HiUctsCO+WBYE/6ehJb5BQxFH6W/Ms0S E6UVDVGmP9/UNtOeNK1uKv9YGMuBSlDr4matuG3W6m+scsUuvKvruFCiizKqq9kn61prSmx0itNp poZb7utdk5+/pGzSpJxJOntKDLbJlpiM9Lhpt2yeX7Hl3qd9p/T2RPbN4If/OtGU/wP0M6HlK9Cv hF+Jm0Okqpmgfwj9+Vqk3quRxqEXZdIuH4d++Y8l3dGrSV/D6Sd/nQy6CPrYuDmSTLpr0PdM3zOX mp+VybJxHPrj30NRd4xP1pvD9LsRslVP0AT9f0r3/gV69u+gk+OTPdne8TfS8//vkGNdtGGCJmiC JmiCJmiCJmiCJmiCJmiCJmiCJmiCJmiCJmiCJujvJ/4LU5QQ8S727UOREC3pJXayIvgpuYkKwZPg 1uBb4AnB98FTgm+D5xAT+DYevoen9weHwPexdHH58J/BfcHDZAWtI7PAB0kqWSHuIClkNT0U/Iys Ru4XVKA5wc/B9wXPgR8K/gF8EOEopH8G3h+8AL4PJaOQy8KDwbfBjwV/Q63A9hn4NvAUlP8UfF/w T+CsZApK/hf4seBZmoOSp8GtwZ+DJwR/Bp4SPA6ew3PrgkfAtwXfAr+H5/YHPwA/RDTgvAVxebAX 3Bf8KThGQevQ5jvgVuCvQ5vnwFOApA7jdYBvw1jq0BpL3wckK/lIV/KRruQjXclH2sPTe3h6D0/v 4ekbePoGnr6Bp2/g6dsQvgg+iBFtA7YP6G4uq91cVru5rHZzCezmstrNZXUPUBnoHmA+BW4NngFP QPoeYP4AvI6HtwV/BX4PD/cH3wM/RIx0D8Y+BdwHKfWjr3Ps37YOfgzOeulHL5+AH4P896H9j8Ct nCegzD60/wn4NshwH1pmKfuCv6b70NohegjlPwa3IvcQyn8KnsJ5DiR/CKhYeBt6PIS6LNzP+T6i Aj9EdODHMPZDQAi5oM236CDa/CW4NfgmeELwJHhK8HXwbdDdINphKf2Q7SDa0YD/EL0Pou5r9Bjq vg/O7OQY6r4JnsJ5DkZ6DHg+A9/Gc+/h6f0Y3TG0wHIPBT8RlxN78B3wFSyMWqfB60gs+L7gSfBD wVfBjxGDuBw93iv6mN2CD6LWdqYjPhcLBfbvkMv/unoT5yKfoRYeY2GBWESVEhZJsWhXwqqIMmoS J85VwpqIdC25JK5UwjqSJ55Qwnoiqb6mhA3C/nB5I1mm8ithE8lTva6EzcIDqs+VsIW0a/co/446 IVO0F5UwJVpdnhIWiFa/WQmLJE5/uxJWRZRRE5P+QSWsiUjXkm367ythHYnRDylhPbEaJilhA60L lzeSfMMUJWwiMYZVSthMaww+JWwh040/BhKq0itylsOynOWwLGc5LMtZDqsiyshylsOaiHRZznJY lrMcluUsh2U5y2FZznJYlrMcluUsh2U5/4BIZAopBpUitIT/Wp2PdJFu/LUQP9Lm8V/5k3/rz4OU NoQ6iQs5c0g7SCL1SGsla5HXzWPNeDej9AbwJpSch3rtKLMGaW0o0cbLefDXgbaaeNlOxLqR1snz 5PptQCDhz4NybWhhE2IbEfKjL4n/tuAahNtRVuKYe1C7if92YStvpUtp1Y8SHUqfrISEMXbxPpv5 bxSysVTxsbYgxcN/O8/HRyHxt4ePkvUrj6MROQW85Q6e0s5b9EBGcnqolw60084l5lVQdiKlg/cq t8nG6Y9AwHr08rGEfltRlraMnfXUBQlI/FcFW7kU2vjvCLLfZ/TzGBuxP6wPWWZyLxLH3qmMq4vL dg0vOYI4ckRMar28njzq2xB3cXuI1GY2b62Dt7CJy6FH0XykvJnG5PE3c/xs/LJefNwa2Fvukela Qhve8GhkjK1KmW7ENiut+zEKWUMbwlrycBvxILVj1LhC1twIJB7ef6PSv4tbbCvXFcu5eg6UXTXq svCsmUaWKVbUptjbNLQ4HbnjW32zYr/yaDwK/laeK+NpViTGMDZxy2WobuM6C9UZP7flb5rBI9Yi 62YpYm0cA+v/Rm7t/lF6LFIQdEWMoFGZd34+ymZuyzVIaSQ5XMe5KNPE21/IUcl1/SAvpFgE2sjJ xef4aOQu3noHyvhhWwx/Kx+BFy1sQirTYAsfC5s5o1sNpbfwXzj1cfsNtbeCY5atdhO3tm6O0M/n VTf3A3JtiY+BzclmblFtvA9ZQmt43ZD05kN+NfCIcl1fRI48n5u4TEbm6Ebll0HXXqNfOc7KNsKK ergMm8I238TzvdxiN0XYuZePtFOxdLmtZs7ZzB07bpYve4gc1Mrl1tmBcTWH5+zVqDqvavmry2ik 9ZCXlhQ/K1tP4yh/d/XYR+x1NK5ZERJgI5HHInv9kNX7witIE/ehndyXeq45UlnOnlEybVasf+wc YFJlltfDazZxf8RG0xxuh5Vs5z7tL2noHzUvRuZEEUfD5oC8Erm4rryk9wfSlOLiUmlJW6Ovq7ur xS/N6/J5u3wef1tXp0ua094u1be1rvV3S/XN3c2+Dc1Nrnme9rY1vjaprVvySB1dTc2+Tqnb09kt Ib+tRWrxdLS1b5I2tvnXSt09a/ztzZKvq6ezqa2ztVvqQlF/cwdqdjZJjV2+zmZft0uq8kstzR5/ j6+5W/I1e9qlNj/6aOwukLo7PEDQ6PEizKp09LT727xosrOno9mHkt3Nft5At+T1dQE3g43W29u7 NkprAVxq6/B6Gv1SW6fkZ+MAMlSR2ts60VdXi7SmrZU3LHfkb+71o3Lbbc0uSRlmdrfU4encJDX2 YPAybv9a9N+8UfJ5MBZfG4aNip4OqcfLukGLrUjpbtuM4v4uDGgDG5JH2ujxdch9MTE3rvX4AKzZ 56pvbu1p9/jCGigLdV3GVDNtGUSEQUnTXNOnRIi+GfJFNx6039rGcDQDmM/T1Nzh8d0mdbGciGjL +ArmYsFolna2+VH/Rr/HL4+xCA108Q4aoTu/r62521XT05jj6c6Vmpqlhb4u5Pr93rKioo0bN7o6 Qo27Grs6ivybvF2tPo937aaiRn9LV6e/WynKwi0eDOA2Vm5FVw9Eu0nq6W4GCAyJZUseaLLZ19Hm Z4DWbOLw5i+tmYNcH49Az009skY3rm1rXBtRF++2zsb2niYmiy6pqa3b244OmMy9vjYUaESp5k6/ Swr13dUJg8hpy5WaO9awSiNNdYYKj4uIF2cmDfF3QzyNst2Fe+dyVdqaxQHktKEXmD4TvY9NkKau jZ3tXZ7IToHZIyOF4MMa6Orxe3v8EPuGtsZmVmZtc7t3zIC+ii64Joqamls8mEQuT7e3N3weJME4 ctc4P1jOzloizhYG4iDaYJBE4ewin6IITtOEPC7f8fyFxy5+ajJRlKEnvmp5s5mVF3q/avmoKFZe lL5qeauVlz/6VcvbbKy8yvtVyzscKI83YadKFS/PTtUZhJ2nK4kZO4QEchP2yyvIVLKazKUCqaVR ZCW1klaaQHw0heyAdO/Gyf3bdCV5hK4iz9Iu8mPaQ35GN5BTdBv5L7qbnKX3kC/pHqqh/dRG99Ek +kN2u0RL6CCtpMdorVhNV4rLaavoox3idtot7qA7xW/Tb4nn6IPip/RRDOX50Tjpi2NwTgLOIuAs B85q4LwJONcApxc4twDnbuDcC5wHgPNp4PwRcL4OnKeB89fA+SlwfknvAcY91AGcKcCZC5zTgXMO cNYD5yrgXAucG4BzK3DuBM77gPMAcD4BnMBEj4zGKW6JwGkBzkzgLAHOOcC5EjjXAqcfOO8AznuB 87vA+QRwvgycR4HzbeD8ADjZXZiWbgO23TQVOF3AeR1wVgHnUuBsBM4u4NwJnN8Ezn3A+QPgfAY4 DwLnUeB8Bzh/DZy/B87gaJzqzRE4o4AzBzhnAOcC4PQApxc4twLnHuB8ADgfB84XgPMIcP4cOH8N nL+nPZQCZzRwSsBZAJyzgLMaOJcB5xrg9ALnVuC8Fzj/BTgfA84XgfPHwHkEON8Gzk+A84/ipwJm sGAbjVN7TwROK3DmA+cC4FwGnN3AeQdw9gPnw8D5FHD+O3AeA873gPMccA5DSmbgTAHOEuB0A+cS 4FwFnB3AuRk4vw6c9wPn/wDOl4DzJ8D5JnD+Gjg/Ac7z4g5BJX5biBPPCWnAORk454zGqT8WgTMZ OMuA8ybgXAucu4FzH3A+DpyvAOdR4HwHOH8LnJfoSmoEmmTgLALOOcC5HDhbgNMPnHcC5/3A+Qhw PgecrwHnCeD8CDj/JFYLorhciBF9QpK4XZgEnDOAswY4lwFnK/dVkKpOTXUab18AT59Xp6M6w+HD 38fz4IM6DdXpjhx55JG9e/fs4cXO9/X1nUdBvRY5vbv406vRqZDV0B9wS9b+Bo2aarTndb19fb2s ijYQYJX6zmtUVKP2sl68PF3HiqAQL+/tuxgI9OpURKcqdp93sweFNJre/v6GgLfvvNLSM0dZFR2l OlWABPgjR5RHo6Maw8Gf7sbDm5XLKz3gYT0DXJ88Ch6RQeh0GpFqVENyK0Cq8QYGiq1DWhXRqmRA xbwZVvqBtRo90ej7An2BpTg0TQJp1Pivr06S6vpYQ+ohye0ODEVgIwFMBioGqEhUqiGDgAyU4I/b zaMswJ5AQBSpTr1//36dmkCs+yX2XOQRb59OZ5XcF5litKWVrHZlqU5PdcZDgUOBA6C9IAbsKtVp w6qDhvWllTvxVJaL11KdXk31EHiE7jSy7niGLqw8ltHQf55lqIgeyhtPe6HGxlGfnlJ9WH3/S/pj 5vXMwBj9cYtyf0UFaq5SYCS60Ro0CsgJaRCa4/GQCmUd6mUdQvQjOkQkpENMIb2ufC6vP7dcb6B6 0wCeh90Pu+/jtAcEZekNhx5++Fu7d9955x16DapcxJS7yCoZ9MgrJ3PJ7WGaSyoIDXBxswmN2dzn 1aqplnXai2EbNNSgQ9WXjqCRIy+xLHnm93l5lkql8u9B1h6/VkO1bIJfDgS2GlTEoA5r1o2SWu1W po0ACvSOanPXLllkinYDBkoNI+oNaPVUa3qeHOMmKhPvSKkb6nSX3KySfuQl1hCLKtiAUquiWkXb ARZmxtlgtQ4xI1SHkBbz9nhzGJCBaI2V7kp3XoCRjdgIl0xfXZ1UV9fHGzlvZVo/b6CCQR3WekCg VMAYqEhV6iGzSA1qKULxEk9hAflBlkpFDZp+PFwRivKli4paoH2mfoOOGvQVc+Rm5lQYjNRgHmgY aIDN7P+W9C3pbtAuECvHLUA2AS5tZgKyDRgN1GCswP4hEPHMIbMJGTCoqYFbQYOVm4EsW9VWyMKo oUamskg70Cp2wPNU4xuCUUWMzBDClqBF3namrcDWnTu3jm52rCkYKTVGmML/JltgI+nlln/+H2IL RioYQ7ZwlTFYRGqMMAZmBDxpxBoUczByczCoBYNOCtsDVyU0ouL+4LJRR436FI/cmNuTYjRTY9RA 3EDc/pz9Of2L+hcxz3Wn7k7dTp1RT43GgcB+UD+oL7ALtBN0e8CoRSsXd8G5ywZiMqBoEmkcZSJz EE+GiXCF9e5Cd8VQ+a5evmhwG4GQTFpq0svaZGvFkZdGLTo8V8BTtoDlLijjdUsrmZ0gV01M6tIR Q3Eb2X4hbCk7t45pfOdO2VGEMeLoZYo0loDOSHWWlwcG+ZwIkQ6t6kMt8IiyrpUaR3K4yfB4CCr7 1xzYsqfYTEBxy2yiwA9i2mjc7osy7lLeqtwBxmgkOhPruNpd7Q5ZDq/NLIeZDo9chD4ld+CiiQom TXgEo4xHrR6KEqmJGc+IK3FLPI2HQtbDzcekZebDVVtc12+Vn2Ee792F0aiYAQ2b9NRkSCXeQAMZ iKAGpKQSk4WarENJQ0nny08UnG4/3X605tixI3v+Y89h02ETjMRkGho4P3Bi4DToGGgQ9NrA4YFD AyYdmr08ePjw4cHLbIEasJioyZxK1sNbMYcVooaB9QOpATJEirlyy1sGBoZ6kywazbFettTptw5q NNsHB9/YYNZRs4E19O6Hh9nz4bvyUtjCW28p5/kinlmtPL91FlsF0eDg4PDAwJpys4aaNeUNDQ0X G5THxPJ3DOLZOrAdNbaP7eLwYbNAzaqBARh96FFSIh69ieqj3h36qHhwFPE1ONwQj5W38HBLuSki 78N30QZPCAPHILjXPz0U6oKt4L1HmGRMe3qNaniGkXGU8raVfjBqC9FbmHoa41ofaHpg6jPl5+Ma 4hr0OqLXHW5pKY8rb2k5zBu8bIqLK4YCLpsFwawZGRAGy6aoemCAqqgaLk0FyaFgQ6gAgsU8kYeU h+WrIWPdMfZw9Zf2no5TniBP2DqIoWk0JnQb5DcFBnJAWE7Exk2+dhLd6mu+jZS1e/ydpAY59Mb6 uRKJIyQY5DcKGpzRo5UYJVqchGN4upwi4NQURWJBYlVd3SKSUV+7RCLFX6tfLGF3I5dhdztW4uQx ET3Ywq1jhcI5K16JwQ0RB0kgiY3ebi95hPMnOH+G84Ocv8r5a7c1+zrJUc7f4Pwk5+9wPsT5h5yf ZXeT5A+MUw3nCZy7OJ/L+TLO13Xc1nEb3c75XZx/k/P7Of8u549y/lT4huavcfoVuQ6SxFaVfXMA YfaJ+v+9NAF6MP/NbwtJ4Z9tsk+/dpL7yAHyHHmNvEnOkD/gzKznI9Upoz1L2PcKRNSLJklIwbmW lsnvvrvk93cuRtSBvX16YFScmi6PjluyRsdt9tFxx77R8czh0fGcMfl5CaPjU4uJXoiMfx6RryF0 YfnoeM3deBtg0zmkjn0XA3V2QlTFQh3ZITwivE32i98Rv0NOqvyqh8lb6p9r+qhouNHgoS8bvo7N 11GT1TRfmGe62fRdYZO5ybxO+JF5h3mPcMQiWHTCm5YvLF8Iv8Dp4QKTjeaU+eC4dAL0jvk3EfSJ QifGoc8tk8KUAyoDVYLWcXpgLJlPWA5YXrDer9D+CHqCEVtuxyGDrS5Md9v2humCTPakccgFmhq9 L4IekYnnjKHo56KPhumNmCHQh4xiVeOR3RVrj81x3h1Bezm9Ni6dcF4KUVx0XEKYKhWqHpfqOC1T 3qMpoHBWbpDTyTDJtd+POx+fF98U/934xxmNbT3+qfFIbj3+pfgzCn0+QqyX+Eu8rwD7S65JLwtT TXp9mJoUWgcKpK9jPwqa4c50ZVamrwN3Zb6WdTT7FKfPc1aCvLlZoILcM7kX8XcmdzjvaP53GeWe yX81/5P8TwpUBZaC6IJXQCddFaA618qihxT68eRASVbJb6feN30qqGJG3IyVM3pLn1Po1dLB0pNl eaDSsrtmvXudhlP/da9xulwxveJJhQ5edxnxJyvO89j52cJsoeLJ2QXub7pfneOavxz0/sK11/XL pfE+L5eqqmDlqmqqJ1UXV1dUP744i1Pd4nWcehfftfgh8N7Fr4OGajbXBGreX+IF3X99A0rVXf/G 9W8sfh38XRYCnbn+7PWXagOcHq09xun92rP4e7/2Qp2q9gLyz9atrHu37swNftB99RLKPVp7Qc6p 31x7of439Z8urVs2uHz5KvuqpFVZrarWla2nWy+F3msLQM91WjsneXu9O70D3jPes94L61Xrp6yv XN+y3rt+8/q+9fevf3L9wfVH1r/p8/ru8z3u+0M36bZ3L+pe0/1q9yn/VP8a/0M9y3r6en7c8/kG zYaCDQs2PLnhw42VGy/1JvUu6G3o9fU+1PtU7+lNkzbdsungptObLm02bY7dXLp57uamzY9uPr0l b0vlltVbHtjyxJZ3t1zY6t66eeur2zTb3Nt8257ZNrjt8vaE7Wu3P7r97I6yHb07ngrUXcNXHRzr j0Z7m8CGEWJ+hJ+nFJI9yDXmXvXYGTd6nsiWPq7XCXmeCBrtOwKDI8S8Q+DkCMl+gflQ6xNxg869 8MPvVJyH1+Q+mL/hb2118K8PWA5Y7zefCPtMlLVdSG9idc0HLQ+M+E5ZSvDOldz/yqUmWQ6EpMdS mS/mZd9h+by8IkG0e9D8G3jyA6jxDm/tBNDdj/c7nEZWh0/GrAqVEevAyEpwgOG+yvs/cZX3Nyg+ /27u77mX5+2gtqUS4QdCnhD6eFzRF3yT7H9k/6boET4RHpBprSnsHUMahY+Lqw6cYTVGdJxeHzgT OIPWWKnPkVcXfya9/mqbgB88GeFRx/GzkX71ap+qeO5Bbk2yF60J+U/m15GCXgNn4x9HSn1c3fSp 178Rq5LXMf7GmuW8FDMEq7KHVp/QqmJPilWNrECyVbK1jZdWsRKo+1qsneWwFFaKpduTzCdClhqX YE/CCmhn9VlYTh1ZRyNXUoaFr5rKuhmxctrRwth1cu+o1fGEsjJGh9Aj/5LcO+t/cV3MUFwl8IyS PpMakzE0FTFjQzKWZyKTpmwp6U2QdzXTJpNEXF30Pq7vx5luImZ1WfxTGGtohT0ptxo4GxcInJWJ 9cDe6fVMKywkWxp7/zdvdwIdd1n2ffyfmTRJkwlQdihQwr7IvikFWZRaQMomiOADkU3DJgJl00JL WESWouziIyhll4LEPopALFCkpASaNklDEhuadEg6TNIkzUyGUrjfzwyRw6PH8/i857zvmfNlZv7L nfv6/a7ruu9/oGVmesc9d9j3Mz5b4XbYt7AqfeGVX+E+W90K6+P/5auwpn7h9c9XFFbaL7zGVtzP X/98R36l/d+9Cmvxv/36fMX+F69/VCr/+nwd/xevwsr+b78Ku41/8/WP6hT2KF94/bN+hb3LF175 vP/M6f/d659H/p9n9++9PtM5v3dZ77eHlhyz3aHrKtvzu57C667CkZL8Tqfw7a5jtsvvgcbOedlB fTm/a/rsaL735z/lX4Xd0WmFnVV+DzX41cHC/sjuyKfXDr2rsDuZ+fkuJv96/PiZ0zqPn5nfwRS+ PT62z/ns8+N2Qd35I/kdTf6+aWOvwo7nisLeyLWFs4/n/7nFXFc/nt9N6RY7Tess7LuuHnudUDiy U37XVfh2wrTOfF8aO+dl57a3vVp+h5a/7+bCJ6/CPu3Swn7OtYWd2uf7tWNPOCxWUGRdXosTr/hM iUNLCvGY8WczPbahMHb+J91cGKsw7n+vxH929It5sHPrZ9+ikqL5oT1+XHg5fkq0fvy0KBG/LAzF 66ODopgzi31LFj6l46eElVGRf45GMf98K35aWOwJ/ZmwLloQ1hVVRxsVfS86qejsaIuic6KqonOj CUUXRhNcub8rD4tfFP4SFRmnJyp2bcK1E1ybcG15Ybykqwai8UVnRls5v73zpzi/tfPbG2tHY1W5 +yHzWR5V+PSC+U6I/8Q8ZoQ/mu/B8Z5wf3xltHc8Ge0b7412j68KTfGUp9386IuN3h0V+xTL/5kq s7mn8Keqro7Wj46JNsDB0a7RZJwbmqLzcD4uD73RFWEkmo4rcRWuxjVRIro2LIl+jJ9gBq5Drftv xE24Gbfgp7gVP8NtuB0vRkdGf0bO508Rol2LIhThhGhy0Yk4CSfjW6iJjs//uS8R18RPjQ6JnxGV xc/CRdFP83+GKj4r2jZeG21T/HBYUvwIfoMl0a7FS9GMFrRiGdrwHtrRgU78Ldp13Aahadz7Ycm4 D6PEuLTP/RgMS0rGRceU7Op9v2jXkgO9XxSaSi7GJfghpofekitBmxLalNCm5FrQpuS5aHLJ8/gj RqPJpbtFk0p3x1nRrqXVOBs/wmW4BjMxCzQqvQs/x8P4TXRk6TPe+zGAQQxhGKOgYdk5OBfnYXo0 aXwUTR6/cTSpkLsfyOvywqdV+T8tF20ia+tkbZ1s20m2HSHbbpBtJ8u2s2Xb0bLtcFfPkS97xk8N d8a/Ha6VQQfIm3uNUB2vD4/He+RZMorHP5CDq6IzCnm20lWdtpl/r4ozo72+MP5U419p/KOMf5Cr Tzf2Pcb+o7v2M/Z9xn7IeC8b79RoPaOsNspqo2xglJ2NcolR9jLKXkbZ3Sg7m+VyI+1ipHPzf77M CE8WIn3Lp+eizY3xF2P8xRi7FJ0V/mycvYxzlnH2N87JxjmsqCa8a6y9ih4If3LnS8YrNt6VZna+ MTcys1qj3RbvDiNm1xDvU62roj3iqbGKnWDU3YxaY9SDjHqUUXcw4i5GW+rOpSrvOFGeElWMdZhP dJJ8Z3kwqg3p6EbchJtxC36KW/Ez3Ibb0RBy0SK8jUa8g3exGE1YgqVoRgva8LcQouXowvtYgW70 hEXRSiQxHDqiNep8BBlkMYqc7vaR82vxMdbhE3xqLiGkiyIUFbpiT/x0GfbdsDp+pvfqsLp4SUgX L0UzWtCKZWjDe2hHBzrxN/SFXPEqpPAh0ujHAFZjEEMYxhqMwFyKP0UIi8ZtGBaVHh5ypUfhGByL aaG39FveT8Hpzp+BM3FWSJdW42xc6NyPvF+GK3y+ClfjGt9/4n2m91m42edbwIfS2d7v8v5z3O3z PbgX9+F+4z/s+G99nuPzMz4/5/NL4FEpj0p5VMqj0o4QSjvBo1IelfKo9H33rEA3eFS6KnSUpvCh WNLoD4tLB7DauUFjD2EYI77zrjTrfdR3HpWdg3NxHr9i0Z3RxoWVKx7dKXdPkcP51Wucb8/6doxv R8vyBfF3o92jIkez0ddlZofM7JCZHTKzQ2Z2yMwOmdkhMztkZofM7HB1r0zLybScTMvJtJxMy8m0 nCxKy5isjMnKmKyMyfp58/28jvh/ROPi38PZMuic0CNrOmRNh6zpkDUdsqZD1nTImg5Z0yFrOmRN h6zpkDUdnMxyMsvJLBc7uNjBuSzXOrjWwa0sp7Kc6uBKBzc6qJ6jeo7qOarnqJ6japqqaYpmKZql aJaKHVTMUrGDih1U7ChUbHtUSssjVHKZtfcVa++8+GJrbZNVyGpT0DclwiYRrijo+xPfNvdtK/re YIRl0WnWySrrZJV1sso6WWWdrLJOVlknq6yTVVH+79e/HXdGB1ord7BW7qBmm9Vss5ptVrMr1GxG zWbUbEbNZtRsxnq6oZpNqtmkmk2q2aSa5Xd0rHVzf3W6Qp12qdMV6rQrfna0U/wcXBTdaB2dZB2d ZB2daO2ssnZWWTurrJ1V1s4qa2eVtbPK2lll7ayydlZZO6usnVVqMakWk2oxqRab1V5GzTWruWY1 l7TGVVnjqqxvVda3KutalVpJWtuqrG07qJWk9a1K/jfL/2b53yz/m+X/Cvm/Qv5n5H/G+reh9W9D +Z+U881yPiPnk9bAKutflfWvyvpXlc/3MEzrYfuzO8NNHJiqn6/Qz6dzYionHnP2dtl+VHyJnVRz +DTeEp1dcK/D1e2uarNi3hmu8+1s9y5x71JHD3fvne59073HuLfZfd+JSsbq6NuubHFlsyuPKeyv 8jnzRGGk85w/zPl3nG91frKRbnX2eSMdaaQGI+1duP69wj5xeeGf2ai8aP1oUtHpuAgX44e4FD/C ZbgCP7PSTyiaH1X6KTfk/4x5/k+YF/ZGj0SbxV+KDoi/yv/uaHur9sl2iRtaube0S9w+3qczrDKD lGMfRgdYzy8Lr7pjU3vK7fJruvsvio62gp0u58+Ijo6fWdh9HR2tZ2YTzWyimU00s4lmNtHMJprZ RDObaGYTzWyiOzd25yXu3NidlxTurHRnpTsr3Vnpzkp3Vrqz0p2V7qx0Z6U7d3LnPu7cyZ37FO5M uDPhzoQ7E+5MuDPhzoQ7E+5MuDMxduf+Y3fuL5Izot182q2gcV1hjzBKrY78n/fFiTgJJ+NbUbm9 W7m9W7m9W7m9W/n4/L+nLabwRu45YWynsaDg0YqouWiX0F20K3bD7vgS9sCe2At7Yx/si/2wPw7A gTgIX8ZXcDAm4xAciq/iMByOI3Akvoav4yhMwTcwFUfjGByLb+I4TMPx+CUewq/wazyMR/Ab/BaP Yg4ew+N4Ak/iKTyNZ/A7PIu5eA7P4/d4AXX4A+bZrc33/mpoL3oNr2MB3sBfHX8ztBQtxFtowCK8 HT4oasQ7eNcO4nRPK2eGxcVv2En8FW9iId5CAxbhbTSGluJ38G5oGTchdI/bGJtgU2yGzbFF6C6Z jQdBg5Jfhw9KHg+rS57Ak3gKT+MPjr/u3W6z5A2fF4eWkqWub/M5G7pLt8Y2mIRtURVWl26H7bED dsROoaV0Z+wS2kt3hVwolQulfC/d1/f9nJscPig9xPtJYXVZLHSXxVGMcShBKcowHuWoQAKVWA/r YwOIt2xDbARxl4m7TNxl4i4Td5m4y7bERGwF8y8z/zLzLzP/sipsh+2xA3bETua0b/igbD98JbSU HYzJjh2OKfgGznLd2d7Pd+77rvsBanABpjs3A9fheszEbMcfdf0Trn8ytJc95fvTGHYsE7rHF0Gs 4zcKLePFMX6T8MH4beXQj4uoU0SdIuoUUaeIOkXUKaJOkTuKqFNEnSLKFP6eiAnYEBthY2yCTbEZ NscW2NKedRtMwraownbYHjtgR+yEnfN/U4en7F2xG3bHl7AH9sRe2Bv7YF/sh/1xAA7EQfgyvoKD MRmH4FB8FYfhcByBI/E1fB1HYQq+gak4GsfgWHwzyv8fYSqKpuF45P+mjRNxEk7Gt3CKeZ+Kb+M0 fAf5v/XiOlyPmZiFG1CLG3ETbsYt+Ck8bxTdFUaLfo5f4G7cg3txH/L/d6Rf6pEP4Vf4NR7GI/gN fotHMQeP4XFYAYuexFN4Gs/gd3gWc6HXFum1Rb/HC6jDHzBfL38Vr+F1LMAbeBML8RYasAj/2EVO Cd/TpU+zDqyv8x9iHVhf9z9E124q1vGKdbxiHa9YxyvW8Yp1vGIdr1jHK9bxinW8Yh2vWMcrnusZ 5Tk8j9/jBdThD5iHP4X+4hfxZ7yEl/EK6vEXzMereA2vYwEao0TxO3g3SoybEJWP2ziqGLcJNsVm 2BxbRBUlt4f+kjtCumS2z/f5/EDoLXnQmsSDQjd7xDmxlDzmnDmXmHOJOZfo0iXPhZUlz+MF5+qQ 73L/5fo/Ovai83/GS76/DPMsMc9C93vT9wbnFnl/27FGvIN3sThKlCz1sz3blXi2K2l1bFkYLXTK dnPzPFfS617PLCVpn+2uS+yuS1bDM0uJZ5YSzywlazCCDLJiGw0rS9cL/aXrYwNMwOZhtHQLbImJ 2ApbR+Wl22AStsVOUaJ0Z+yCXbGPY/t63w9W2VKr62ddN0qUxaKKsjiKMQ4lKEUZxqMcFUigEuth fWyACdgQG2HjqLxsE2yKzbA5tsCWmIitYJ5l5llmnmXmWVaF7bA9dsCO2Dn0l+3uGe1L2AN7+m6n ULaPz3/vxPv7fCAOwpfxFXEcjG/6fBw855Yd774TwoKyE3ESvhNGy84yz/Nd949d2vNumefdsqsw wxyuw/WY6fpb/Wz1X+ja93l/wLgP4pd4CE8Y70n8vYs/4xgPyzLu/TiMjo/CyvFF9kplIT2enuPL vU9wfKMoUejsVqjxmzm2ObaAfjx+q/zvJfOVPravmpH/23cKe7TXPj9+iePXFH6Pkt9vDUTjYlPD d+PHhdftTsvzv9tyrj/6UmzvkIrtj4NwGKaGptjRYVHsWBxnV35KWG530Wl30Vl+WlhUfjpuCany n+JW/Ay34XbcAc9y5bNxF36OX+Bu3IN7cR/uxwN4EL/EQ/gV/hO/xsN4BL/Bb/Eo5oRUYveQiuJm mo2d5pn4Ms/Qk80/Y/6Z2MEhaf6Z2Ne83xpWxH7m2eWMaA/9aw9XLio/OSTLv4VT8V2cE1aUX4CL cAkuxRW4JWTElhFbRmwZsWXElhFbRmwZsWXElhFbRmwZsWXElhFbRmwZsWXElhFbRmwZsWXElhFb RmwZsWXElhFbRmwZsWXElqk4JqyoOBbfxHGYhuNxAk4MK8Se4eFBYRmH3o4VfAwLC785nCT2J8X9 ZOyMMDd2Li7GrWE+Debnn7/F/qTYnxT7k2J/UuzzxT5f7PPFPl/s88U+v/zqMLf8GvwYs3BTmGte 881rvnnNN6/55jXfvOab13zzmh8dwYEaDtSYWw8HasxvVAaNyKAR8+wykzYzaYuf8ulI/LRPM1aX Ss7sZXWp5M5eY8/4C2TXiOwaMbs2s2szuzazazO7NrNr40wNZ2o4U8OZGs7UcKaGMzWcqeFMDWdq OFPDmRrO1HCmhjM1nKnhTA1najhTw5kaztRwpoYzNZyp4UwNZ2o4U8OZGs7UcKaGAm0UaKNAGwXa KNBGgTYKtFGgjTM10deoUE2Fal68RYVqfrwVmxptLfppop829vvW28aep3ejwqZU2I8Km1Jhv7Hf En+HV2/x6i1evcWrt6gxjRrTqDGNGtOoMY0a06hRTY1qalRTo5oa1dSopkY1NaqpUU2NampUU6Oa GtXUqKZGNTWqqVFNjWpqVFOjmhrV1KimRjU1qqlRTY1qalRTo5oa1dSopsY0akyjxjRqTKPGNGpM o8Y0akyjRnVUKhdGRJwQ8c9FfKWINxThdSK8KtqCRgvos4A2rbRppcOGNNjQ2bvFv0D8C8S/QPwL xN8q/lbxt4q/Vfyt4m81j1bzaDWPVvNoNY9W82g1j1bzaFUrNeGJf+h3I9EesRP1uNNQo89doMdd iItgbDN+//NeN0PPuD4sqvhxSFX8BDNwHa7HTMzCDajFjbgJN0NvrNAbK/TGCr2xQm+s0Bsr9MYK vbFCb6zQGyv0xQp9sUJfrNAXK/TFCn2xQl+s0BfXG49yVOh5+c6eKsw9o8aTajypxpN0yz+n7+Ts ErWbVLtJtZtUu0m1mzT3jLlnzD1j7hlzz5h7xtwz5p4x94y5Z8w9Y+4Zc8+Ye8bcM+aeMfeMuWfM PWPuGXPPmHvG3DPmnjH3jLlnzD1j7hlzz5h7xtwz5p4x93zPOi28R+23Kfzq5z0rH1FXtK+I6pzv dn6UG+u4sY4b61zb5doy11aolHKR7qlSykW759jvgP7KoXUcWifKOlHWibJOlHWirBNlnSjrRFkn yjpR1omyTpR1oqwTZZ0o60RZJ8o6UdaJsk6UdaKsE2WdKOtEWSfKOlHWibJOlHWirBNlnSjrRFkn yrroAJHU8mYhbxbGaqKt+LNQBOeogI9UQFYkN4pks7HfzGyW/82MSO7P/zaLdwt5t5B3C3m3kHcL RVUrqlpR1YqqVlS1oqoVVa2oakVVK6paUdWKqlZUtaKqFVWtqGpFVSuqWlHViqpWVLWiqhVVrahq RVUrqlpR1YqqVlS1oqoVVa2oakVVq45PK9Txl0Xx7ti/c5pi1neb9QtRhXgbxdso1kZxbSKmTZy5 VzyN4mkUT6N4GsXTGJXEpvP1yvBR7KrwQexGeXFHGIjdm/9Nu6NrYzeGbFTknx9Fu7oiG7taRlyD G0NL7OaoLHaLu28PfbH78n8nW/g49mD4uML+tsL+tmJrbINJ2BZV2A7nuuY8nI/v4weowQW4EBfh YlyCH+JS/AiX4XJcgem4ElfhalyDa8PHhXjWmmlPbEboFcvK2D1hdcyTXnR67DLZfjmmO3q1KK/B 9WFxbCZm4QbcGG0Suzk8F5vturvC+7Gf4xe4Gw+EF8X3YkUsvF0RRzHGoQSlKMN4lKMCCVRiPayP DTABG2IjbIxNsCk2w+bYAltiYhig4QANB2g4QMMBGg7QcICGAxUHh8UVk3EIDsVXcRgOxxE4El/D 13EUpuAbmIqjca44zsP5+D5+gBpcgAtxES7GJfghLsWPcBkuxxWYjitxFa7GNbg2vBgVy5zlVFxK xRWx+8KQXLoxDMuT0egELuS4kOPAWg7kM2yFFSdrxcm6IkvlHJVzVpisFSZrhclaYbJWmKwVJkv9 HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPVz1M9RP0f9HPXX Un8t9ddSfy3111J/LfXXUn+tVS5rlcta5bJWuaxVLmuVy1rlsla5LHVz1M1RN0fdHHVz1M1RN0fd HHVz1M1RN0fdHHVz1M1RN0fdHHVz1M1RN0fdHHVz1M1RN6fmrpTd+VqcQdPrZPeN0XrU7qF2N7VX R5fSuJ7G9TK9z5ULad1D657Ytb7PCKvcNSzz0zI/LfPTMj/Nh0/4UM+Hej4Mxe4Mb6qAZSpgmQpY pgKWqaW39Ya/8qiFRy08qudRPY/qeVTPo3oe1fOonkf1PKrnUT2P6nlUz6N6HtXzqJ5H9Tyq51E9 j+p5VM+jeh7V86ieR/U8qudRPY/qeVTPo3oe1fOonkc9POrhUQ+PenjUw6MeHvXwqEeFpFVIWoWk VUhahaRVSFqFpFVIWoWkVUhahaRVSFqFpFVIWoWkVUiax/U8rudxPY/reVzP43oe1/O4nsctPG7h cQuPW3jcwuMWHrfwuIXHLTxu4XELj1t43MLjFh638LiFxy08buFxC49beNzC4xYet0Q1HExyMMnB Nfx+jYurOdfOuQ85N8C5Ac4NcG6A/wn+v8C9NPfSsdscu4PTs8OzHOzjYB8H+zjYx8F+Dg7Jk1e4 2MXFLi6muZjmYpqLaS6muZjmYpKLSS4muZjkYpKLSS4muZjkYpKLSS4muZjkYpKLSS4muZjkYpKL SS4muZjkYpKLSS4muZjkYpJLA1wa4NIAlwa4NMClAS4NcGmASwNcGuDSAJcGuDTApQEuDXBpgEtp LqW5lOZSmktpLqW5lOZSmktdXOriUheXurjUxaUuLnVxqYtLXVzq4lIXl7q41MWlLi51camLS11c 6uJSF5e6uNTFpS4udUV7cynLpWyhGj9zYYQLQ1wY4kCWA/nnpiHqDlF3iLpD1B2i7hB1s9TNUjdL 3Sx1s9TNUjdL3Sx1s9TNUjdL3Sx1s9TNUjdL3Sx1s9TNUjdL3Sx1s9TNUjdL3Sx1s9QZos4QdYao M0SdIeoMUWeIOkPRbjrDOp1hnepPW8/LY7eJ4nZRFGbv8314wHr/oHV7ol3dVtga22AStkUVtsO5 rjkP5+P7+AHsIGk9SutRWo/SepTWo7QepfUorUdpPUrrUVqP0nqU1qO0HqX1KK1HaT0a/YDWfbTu M+O0GadVQUoVpFRBShWkCvr/vQLo/k+Zbwcfy/9m419nex8/+vjRx48+fvTxo48fffzo40cfP/r4 0cePPn708aOPH3386ONHHz/6+NHHjz5+9PGjjx99/OjjRx8F0xRMUzBNwTQF0xRMUzBNwbRqSKmG lGpIqYaUakiphpRqSKmGlGpIqYaUakiphpRqSKmGlGpIqYbUv1ENKQ6lOJTiUIpDKQ6lOJTiUIpD KQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJTiUIpDKQ6lOJQqrPGDhX8LeSCv0rxK6zZp3SZJ+zTt8xqn aZymcZrGaRqnaZymcZrGaRqnaZymcZrGaRqnaZymcZrGaRqnaZymcZrGaRqnaZymcZrGaRrnY0yL MS3GtBjTYkyLMS3GtBjTYkyLMS3GtBjTYkyLMS3GtBjTFflcmI4rcRXkmxjTYkxHG+jFmf9eMzLt tkKlZ/XU7P9UI/buV9qjejJVbQnVVqLaVqi0TVRaeTTt844y3Wo8A9d5Lr/Rz7o1DMrsQVfn1Oag 1XnEXXtSOEvhkS/smgZl96DsHpTdg7J7UHYP/n/qNoOyb1D2Dcq+Qdk3KPsGZd+g7Bv8f7oryj+t 5Cj15ufPLSNRfOxYjksfR6fQtoG2Dfzr518/bfNPNu2cGEffXvr2FvrfbN/v8Yxwr53SA449GHrp 2kvXXrr20rWXrr107aVrA10b6NpA1wa6NtC1ga4NdG2gawNdG+jaQNcGujbQtYGuDXRtoGsDXRvo 2kDXBro20LWBrg10baBrg5zql1P9cqpfTvXLqX451S+n+uVUP9176d5L916699K9l+69dO+ley/d e+neS/deuvfSvZfuvXTvpXsv3Xvp3kv3Xrr30r2X7r1076V7b0U+zum4ElfhalyDa0NvQeOPxioh F20UmxdtGnvVjvM1efl6mBl7MzwZW2OfkQmzYx+FxXGdM76Hp9e9wnPx/UPy8/9a+dRog/i3o8TY f1PYl+gI73BsjnHn4jUV8Hpoji2Q6W/gTT9zofdFoSP2jifdZj+txXsr+qLxsVUqNWOPm7UTGsXa MBSPwvvxUpRhC0//e4We+D5hTXxf7IcDQjY+OXQnqkM6cV5oTFwIPSLxQ++Xho7Ej6AnJH7sfYb3 62APnaiFFTNxB1RlYrbzdzum9yXu9/0B/MoYc8JHiaeM/xyeD2sSv8cLjtX5/qJ3MSUWO9aEJVjm exs6fO7E+67rD+8n1mA0vF+5cRio3ASbwtNhpafDyh0cvyA0VtrTV5pX5S1hpPKOsKbyXjyIR8NA dMyYqu18ylF1GVX7qdpP1XVUXUnVNqouo+oaqi6j6jJqZqk5TM1hSg5TcpiSw1T8iIoZKmaomKFg PwXbKbiMgsso2E7BZRRso2AbBdsp2PYPCrZTsJ+C/RTsp2AbBdsp2E7Bfgr2U3AZ9fqp10+9DPUy lOunWIZiGYplKJWhVIZS/ZQaptQwpYYpNUypYUoNU2qYUsOUGqbUsjGl2inVT6kMpTKUylBqONou 9nT4cWxeeJ5S9XLwYwo9TpUPY8vD9+XZ9Niq8LDsPjU2Yqf9UfiqPPtrPB4WxEvCnfFEuES2t8Q3 DlXxSdH58R3DFTJ/u/ie4UiqPSr7p8i5h+JfDdfFjwhnjP3XWV3xb4dH4qeFC+I14ZX8f78kqj/r Sa9aJV7Hm+FvfuIH/FjuJyb9hFVGHTRitxFXq6XJaulQT4RPc+zV0OSufL28XaiRvmgbdy9x51vu XGluSXOrMEJzoR72D83ufDW85a4P3PVf7tjIHSv8vK5C/XqqLtTwJHW6h+97heXuet8sF0Rby6w1 hTsXyKw3sFDGLHL3O7Kq2S6yxXtrWCk7VsqOlTJjpcxYITNWyIoVsmKNrFgjK9bIiJyMyMmInIxY IRNyMiEnE1ZybiXn1nAt3/n7ovXMp8TM5/h5T/u5fxLri1gY1tK1k57JxNUha/xh4w8bfzjxoO+/ DlnjDEfF7hox88vc0Z3Pezvhp/WSeWJ5PSx2tCPWpI/kNVweUnRrMu4y4y6LTvNTZ7t6pprqKWTL n8IMP32GO4cosZYSa43QQ4lAiZGxuhqhxEisLcw1Yp1MWhxLy55ybBzOi2/Kjc2wObYPl8d3wI7h w/gufN4Ve3CP7vHDnD+i8N8u72M2+6i9HuqOUHdE7fVQeITCgcJB7fVQYQalAyVmU2I2JWarvx5q r6X2WmqvpXZQfz3qr4fqa6m+llozKD9CsRmJZ3WiuXgpXJ5Y4P1tNOIdvId2/M25Lu8rjNEdLq+M wl8rx4W5lSUoRZXvO+ECHWpWmK0Ge7i5tvK+0F15Px7AL/GfYW5UISOHZWM3p/fTfT7RfT7RfT7h +kEq/ROV/olK/0RVfxJtxY+8l1naD9J+0F0letSQHjWkRw2JfUTsI2IfEfeguAfFPSjWQbEO6i9D +suQ3jKktwzpLUPye0hvGTLXEfMc1CuG9IohvWKoqNxPnCUD7uP+fO7/gvu/iL3C0Xq8Gt6MLbAq voE3w6Oy4OPYEseb5VZbmB57L7wca0cHOvE3LA+3xLq8d6PHmCu9J9GLvmiWbKmLpXz+EGmZ1+99 AKvD5bFBDPk8jDWhRm9arHO36dxtKvhUPeqd2MfOrcMn4ZXYp96DVbgIMeT7V7FsG+dziT5VHmbG K3xOhIsL/Wx97xtgAjbExmGybJ0qW6fK1qnW1pvjW4ar4hOd2wr5/8dRlfftsL2etwN2DN+N7+T7 ztjF912xm89fwh7ha3rk93SWZ7k2i2uzuDZLth+nX94RP9A1B+HL4Yb4V7wfjMnh+vgh3g/FV8N/ qIqp8cN9PiJcpjJOHfsvZp9VIVfFT482j5+JmvCu/vq7RE1YnLgAl4aPVcnHKuQXKuRjWTJLlsyS JbMSs5y/AT/FrfgZbo82TdyBOzHb9fc6dh/u9/0BPGich3z/tfeHw8WJ3+BRzAk3Jx4LV1nNrk88 7fsz+B2eDVNU1RQr3PUycJYMnGV/cLNV7vrEH8INiXn4L9e96NhLrnvZ51dQ7/gC3990fKFxGxxb hLcda8Q7WGysJizBUtcvc20b3nOuHbq37J6laqckloeXVe4Uq+j1qneq6p2S6HFMDibkYOIDyMNE H1aF+Ql5mJCHiTTkYGI1BjGkAwwj63MuvJL4CGt9/gRyLiHndIWZlfKuUt5VxsMrlcXex4XpusR0 XWJ6ZZnv43WPcsjBykSYX1mJ9XxeHxs4PgEbYiPHNw5tVvo2K31b5WbG29w1W2BLTMRW2Nq1k5zf FlV+/naO6bC60czK68NiFT6r8pZo00peV/K6kteVt+F23OHc3eEqlT9Lp5qiU03RqaboArN0qymV DxnnP837YWM+avw5vj+Gx/FEuDyq0iUu0yV+X1iZXyus52/oBL0qfrbK/g+VPU/VPqdq37LmZlTs X1Rsj6psUo0NqvAVVbhU1R2lss5USc+pmDtUzBsqpleV3KtKlqqCetn/mOw/XvbPl/35P6lwoIx/ Nzpbv3rKTH5nxVoSe84qNU9P+JNjL+I169zrzi0Irbpnq5Vrvp7Vb+WaZw3sN9tVVq95Vq95+tcc M39Dn1pl5u/oRQvMuk2/6dZvus28V79uNvPVenaznt2snyww+2f1gmf1gmfN8mOzPCm/57F6LUl8 T6c9L8yzgs2zgi2xgs1Tm/1qs98KtkR9PqU++9XnU+rzKfX5lBVsSeJG992E23B7aNXVW3X1VrXZ bzVbYjVbosO36vCtavMpq9k8tfmUWnpW3j8rz5+V06usJ83Wk2Z5u8qa0ixXV8nTBfJyjrycIy/n yMVVcq1brnXLtW65tUpurZJX3fKqW14tsBY1y6kFVrh5cuopK9wSK0er/JgjP1bJj247yFfkQT1e tUN7M/yJ0iutDk1y4UjdvFM375QPi6j6PlUXU3WxnPijzr2csgt16k7KLqTsQrnxodz4QDdeqhsv 1Y2XypEvyZFRXbZdl22XK+/Jk6TO2qizNuqsjXKmRTd9Txdt0zmX6ohNOmIT1VdSfSW1V+qATTpg kw7YpAM26YBNlF2p6zXpek06XZOO1qaLteti7bpYmy7WqIs16mBtOth7Oth7utV7ulW77tSuO7Xr Tu26U6Pu1Kg7NepO7+lK7bpS+1hXatSN2nWjNt1oKXcW6iydOksnlxZyaKHuslx3Wa6DLNctOnWL Tp2hU2fo1Bk6ObWYU4s5tVhXWK4DdHJqMacWq/xOTi1U+U0qvknFN6n4JhXfpOKbVHyjam9U7e2q vV21t6v2RtXerto7ubhYlXeq8k5V3qnKOz0T99kd5/fV+4d10QGqLP+cdaGKekBFPaCiXuPzTFXz EV8f52sdX+tUS4qvPXydy9O5PJ2rInKq4P8Qdy7gUVTn/z8zZ3Zmdna5CCFc5X73wkXUimKsTb1U wFLFIihoQSk0QVBAIATQeqmiclEhchGsiBF+BUqsysUrpdRLIJAFhg3BCATIZplwSUhC4p7fZ9a0 f9t/f/8+7a/P8394Ps/szJ455z3vOfO+33efsFvDWsxjLebxBNSwHvPY8TXs8hx2eQ67PIe1mMcu r2GX17DLc9jlOezmWvy1AT9tYDfX4qsN+OoYvjrGrq7FX8fYybX4Jw//5OGfPPxzjN1cy26uxUd5 +CgP/2xg99awe3PYubXMOY857lAvsmOrmcGHnJ3H9iq1jr15RLRhZuc5K2VmZcysjJmdYVb5xIEY M8tnZvlYdx7r8rEuH+vOY10+Vp3HovNYVIZFZVhUhjXnseY81pRhTRnW5GOFX8uWiQ6MVMVIhxip lJFKGekUPvRr1AJGq2S0AkYrYLQqRitgtAJGq2K0AnxxDl+cY9QqfHGOkasYuZSRSxm5FF+cY/Qq Rq9i9FJGL2X0Akb368NSaoQjxMvzag+z3sPIlYx4mFi2hYh7kIjr1wfvJyOuSavKhhoq1vB/mPrI EaJ/0nMlvHOYd0qSZ35tV5f0Y6DhrnOcxen/AP2fRQ27aNo4Hr7IPB08ISCAJjXBgk6cd4eV6gx9 HEmuzF5aF5FFfBsrRXf62Mk7H+C/c/S1lRYn/lLfJ/ONIL5YYIOjtjKrYcxmLH48hx+P4Mcj+NGv r4/gv3PYsBUbdmLDTmzYiS//tu5uC+2+V393on1XnsXuHFfSfhXX/JpbY86eaIl9Z7HpLDaVY1N5 wyc4FVhfhl0V2FWBHRXYUYENFYx9lrHPMvZZxi1n3HLGLWe8csYrZ6wKxjnLGOWiK71vY/Z/YuZ/ /l6UjeDn3zHShWRUdZJ/KfJ0w1oeYvYT/L/o+Uv0YcZ/ZtRtjLqNUbf9w8jjR5pOtPOjTHeOfsRY Sdu/jxjBZBY9jw6opbY2WdfhanLDX3fsYeR7k38x2h+7j9DyfVYtn7rgAPZ/jJc2fi+C+JnBxVMr WWs/757AWyvx1krm8zG9zqe3DaxiPtrtAB5ciQdXspL5eHElT4TLE+GyovnM72OeCpc5HmGOR5jj EVY1Hw12AA12AL114O8ih8sq57PK+X+NHJ3oo6taydw/Zt5HWOX8ZPRoi9eL8HpR8tOIKqJIrdqB 1afxfBEWn8Zi/zOc03i7CG8XYeVpLDyNl4vwchFeLsLLRXi5CC8X4eEiRjqNh4vwbhHeLcK7RXi3 iKeqiqh7kezH7mGHVamPhU4WvIhSqhUSNbKLs7OcnRSdOPOoYWrQJx76xCNTVpMpq8mU1Q2fEcbQ LGfQ8TVkvBiZLkamqybTVaPXa8h2MTR6DbrCQ5PXkN2qyW7VZLdqdHcNuruGzFZNZqtGd3hkthja wyPTVJNpqsku1SJILq/FkhXkbo+c7eu6E4zqsYJvsoJvJqNKkGxfKVOIJFeoODMoo1VcXi2aEGGo eUQ/xnGFQT/H6cf/zLXGnwEzDic/QYj57fFECs/T1aqG6/6nsrTgvqOiBWf+7CuZfSWzr0zOfCRa YbTa/72ZVzLzyuSsCzjuhX1QBIeB2TGzSmZWycwqRUdG241/q/DvQfx78PuVOWPHGaUU31YxQikj lP61Gt+c/MSvFN9W4duD+Lbqbyr0g5y7yU8Bk5U6vj3I6KX49uD3q3WhMfMq0VU24lWKWoVa8lBL HmrJw6b3sOk9vFWFYipDMfmfrp3GT+UoI48VqGcF1rMC66kjm1FH+n8d6aueMlRPGXa9h7opQ92U oW7KUDdlqJky1EwZ9ryHkilDxXjY9B6KogxFUYaiKENNlAkLa37PyOcZsYYRzzNaLaN9yWhfii68 +w1+O4mNh7DxEC0vNHyG/X9W6GqU3fXs6x/ihzXqJD68iA8v/nWVNnMtj/MtHLehtHZx/P6qHeTc hb+sXjFtSmh/VB36m1VMxWsleK0Er5XgqRI8VYLdXzd8JlWCR0rwSAneKMEbJXijBG+U4I0SvFGC J0rwRAleKMELJXihBC+UiDbMs5g5FjPHYuZYwRwjzLGQORYyx0KUqr/rCplPIaoyhqqMMZdilKW/ AwuZSyFzKURJxphHIfMoZB7FzKGYORQyh0LmUJj8X5Rd5BjRReSIceo18RA8DI+p1WKWWiSyYDZk wxw4pnLEcSiFc7SpVQvFRaiDevhW+b8EXKD1gt5wGVwOV8CV0Af6Qj/oD1fBALgaroFr4QdwHQyE 6+EGGAQ3QhrcBD+Em+FHkA4/hlvgVrgNboefwB0wGIbAULgTJoiW2ifqY+1T9b72GeyAP8JO2KU+ 1P4Mn8MX8KX60FilFhmr4Q3I53w37AHmaiRAqYWBpuq1QDOVE0BlB1DZAVR2oCW0gtZQohYF4rQ5 DWfUIrMXXAMZ6jUzEybBIzBNrTanA343F6gCs0B9aFLxWN3Vh1YP6Knet3pBf7iK8xtgpMqxRsFo tdBaCmughPNv4CiwZlaZWm3FoIL3Kjm/oBbauiqwJRgQABNQijZK0Q6CAyEIQyNoDE2gKVwCzaA5 XKc+tAfCGF4/zHEex7c55qr37SpVEKSvYHP08f2imdotmgPRT7SAVGgJPaAn9ILecBncAYNhCAyF O+GnMAx+BnfBPXAvjFMr2Lkr2Lkr2LlzxFS1UkyD6fA4zIBZKpfdnMtuzmU357Kbc43n1W5jPrwA L8JLsAAWwiJYDC/DK/AqLIFV3Lca3lC5rPqKwEG1O3AYiuFrKOH6CY4nIc77p+EM175Vu00TLAiC A62gNXSD7oAfTPzA7sg1B3C8huP1HG+F+2E0jIEHIEOtYOesYOesYOesYOfMYefMMZmvyXzZQbn2 I75vxCJVIBbDy/AKvApLYC28DbnwDqyDL+BL+AryYTfsgQLYC/ugECKwH1w4pjYTEzYTEzYTEz4X 56ESquACVEOt2kic2Eic2Eic2Eic2GicUgVGGcSgHOJAdWJ4UAFn4CycAyoWoxL8+xKg1Eaet80W scDi2bd41i2edYvn3BqqPrfu5jgcRtJmFIxWG61fcT4VpsHjMANmwzPwLPC8WfjIwkcWPrLwEc/T Ruu3HNdw3MhxG+AHCz9Y+MHCDzxrm3nWNvOsbeZZ28yz9jnP2udWOcShgnsruY4/eO42alcKQ1wi AmD6v7bgf28+BMH/9u4QhP2vmITGMFCkiuthnMpij2exx7PY49PY4xPZ4xPZ4xPZ4xPZ4xPFTHqY pTLZ55ns80z2eSb7PFP8WjQRT8HT8Aw8C7+B5+B5mA8vwBbRXmyFY2oWKzqLFZ3Fir7Ciuayorms aC4rmsuK5gr/G6RrVTarms2qZrOq2axqtrZM7deWwwp4HVbBangDfgtvwhp4C9bC25AL78A6WA// Bb+DDbARNsHvYTPkwbtqv95XNNH7iVR9AMc0uE1l6berx/Q7YBjnE9QT+kSVof8KMlQGmu0OOUpN RbfdIcdwnKq+kNPUXlkgAnKvSJGFqN79VOUHhCOPqVx5HC1SKnrKExxP+t8NxLFcNDOmikuMaTAd HocZMBNmQRbMhmyYA3NhlcokXmQSLzKNfaKJUQgR2A8H4CC4cAiiUASHoRjwJ7s9m92eTazJClyi 9rPrZxFjMgPlwiG+ZBFfsogvmYE6cYkpgb1lNoPm0AV6qUyzN8d+cJVIJaZkmtfyOkNlET+yiB9Z xI8s4sc04sc04sdE4sdEk71kzgL2kvma2m8uS/4P+v3WpdAeOkBH6AdDVS5P2iyetFk8adnWFNHE ehTmwROwCJZyfRXHN0R7nqZsaz2vS2j/DRwF9hxPzis8Oa/w5OTy5ORap0XQ8qCC9pW8z/7jCcq2 qkUTO0Xtt1tAKrSEVtAa2kBbaAfYamOrja02ttqdoDN0ga7QDcbS1zh4CLI5nwNz1f6gpvY7I9Rj zkjIVhnOXOC5cXhuHJ4bh+fG4blxeG6cF+ElWAALgfk6i+FleAVehSWwFHLgNVgGy2EFrITXAf84 q+EN+C28CWtEk1AWzIZsmANzAd+G8G3oSeD5DvF8h3i+QzzfIewMYWcIO0PYGcLOEHaGsDOEnSHs DGFnCBtD2BjCxhA2hrAxhI0hbAxhY/gy0aRxEBwI+b8cKffwpBwjGvmv/O8eaak/TjQLJ39dwAQL bPB/qd6BEIST32AfJpqFUQBRFEAUBRBFAURRAFEUQBQFEEUBRFEAURRAFAUQJfI1J/I1RwnEUAIx lEAMJRBDCcRQAjGUQAwlEEMJxFACMZRAjCg5nig5nig5XvxSeWICTIRfQQZkwiR4BCbDFHgUHlMT iKiTiaiTiaiTiaiTiaiTiabpRNN0omk60TSdaJpONHWIpg7R1CGaOkRTh2jqEE0doqlDNHWIpg55 9zB59zB59zB59zB59zB59zB597DwP+/IhXdgHWwRrYm8rcm/HvnXI/965F+P/OuRfz3yr0f+9ci/ HvnXI/965F+P/OsRracQracQraeIk9Syp6AMYlAOcTgNHlTAGTgL59RSIvtaIvtaIvtaIvtaIvta ovpMovpMovpMovpMovpMNL2LpnfR9C6a3kXTu2h6F03vouldNL2LpnfR9C6a3kXTu2h6F03vould NL2LpnfR9C6a3kXTu2h6F03vouldNL2LpnfR9C6a3kXTu2h6F03vouldNL2LpnfR9C6a3kXTu2h6 F03vould7aciVRsGP4O74G5YpiJkogiZKEImipCJImSiCJkoQiaKkIkiZKIImShCJoqQiSJkogiZ KEImipCJImSiCJkoQiaKkIkiZKIImShCJoqQiSJkogi1RB61xHZqie3UEtupJbZTS2ynlsijlsij lsijlsijlsjTvhKOlg+7YY9wyGJhsliYLBbWB/r/R5XjjzjepuaSzYaSzYYms9koFdfHwQSy2/ey mp6p4mS2QWS2iWS2QWS2idTiC+Rj6ndym/pMfiQay0/Jfnuo5/dSpxeKlmS5GFlOyoPU999lugCZ rmvyOyZjXC8n80wVYbJcmCwXJsuFyXJhslyYLBcmy4XJcmGyXJgsFybLhVHSMZR0DCUdQ0nHUNIx lHQMJR1DScdQ0jGUdAwlHUNJx1DSMWOp8owceA2WwXJYASvhdVil0smc6WTOdOquPOquPOquPLKo QxZ1yKIOWdQhizpkUYcs6pBFHbKoQxZ1yKIOWdRBZ3roTA+d6aEzPXSmh8700JkeOtNDZ3roTA+d 6aEzPXSmZ1SpuHEBqqEGauEi1EE98EyQmWeSmWeSmceTmSNk5inUfy71n0v951L/udR/LvWfS5UQ pUqIUiXEqBKiZPD0wHHlUSlEqRSiZPLxZPLxAWwKYBMZPZ2MHqZqiAYSnCvlmQI00EGKMJk+TEUR paKIUlFEqSiiZP4wmT9MZRGlsoia7Wh7KXThWjfOuwOxliojijJIRxmEzb68zx5EHTSn6oiiENJR CGEqjyiVR5TKI0rlEaXyiFJ5RFEO41EO41EO41EO403iqEkcNYmj5mMwFaapCaiJCaiJyaiJyaiI dOpZFyURQUlEzNeT38iUam6Cd5PfypRq7uRYoPJQGRGTtaTudc1qkYriiKA4IiiOCIojQi2cRy2c Ry28nVp4OwokQj28nXo4z7peONTEedQFHnWBR13gURd41AWHUSlrqQs86gIPtTIFtTLFuk/Frfth tJpJfeBZGbzmmbImwSMwGabQ56PAvKgdDlM7eNQOHrWDh8JxUDgONYRHDeFZz9N+fvJbBT1Uj0M9 4VFPeNQTHvWEhwqaiQpyUEGtqSs8lNBMlJBDbeFRW3jUFh61hUdt4VFbeCikKSikKSikKSikKdZx +i6FE0Cst4j1qKalqKalqKa1qKa1qKWZqKUpqKW1qKWZqCWHWt+l1nep9V1qfZda36XWd6n1XWp9 l1rfpdZ3qfVdan2XWt+l1nep9V1qfZda36XWd1FdEVRXBNUVQXVFUF0RVFcE1RVBdUVQXRFUVwTV FUF1RVBdEVRXBNUVQXVFUF0RVFfE7o9NV8F1Ks8eCGPoeyzn4+AheJhr4zn+EibARHhExVBoERRa BIUWsedxzwKuv03bXLXdfofX66BKuUEhUlFwkSBzCzZXecEWwnHuUsecu+EeGKGGouyGOvfxeoaK OzMhC/6i9J7g9dPwrAij+MIovjCKL4ziC6P4wii+MIovjOILo/jCKL4wii+M4guj+MIovjCKL4zi C6P4wii+MIovjOILo/jCKL4wii+M4guj+MIovjCKL4ziC6P4wv8fFV/4bxRfC/GSukEbLYZoD4i7 tAfFDO0X4sfaWHGDNk78XL9NjNAniHvkcHWzHKF+KLeqtfIjNUQeVZ+jDVMkEU6eUIvkKbVLlom2 Mka9Va4uiA7ipcQOsV7tE39U++j9xoZvg72G3i+j98vo/SZtgrpAbi1lFKo5qrLhaiCjDGKUaXK7 2iY/hI8ScfmJ+gM57qD8TO2UO9RLjP4UI9fIUnWS0Qcy+gJGl4z+OqPvELbcrdbIAmyikpf71FhZ qLbICHcdUEVkxWJ06nr1J2z7Ey3vJXfupvVSWmfJfYkErd+g9e3k0T9wx+PcsSz53Y59sDabbH4p 2ft2fQiZfIKaoE8SUl+HTt6hfqHvUjn6EXG1XkVGThFNZB/1ltwuwmTpPszg94y0i3pUyn3UmvvV u2TpAL0nmFGETJ3VkKllQ00qmdlJWcasYlwvV6e1nwtDbREBMMECG4LgQAjC0AgaQxO1TTSFgapI XA+/VpvEU/A0PAPPwm/gOXge5sML8BI+3KL2iq1qr6arIk2CAQEwwQIbguBACBpBU7gEmkFzSIEW kAotoRW0hvbQATpCJ+gMXaArdIPu0AN+qoq1YfAzuAvuhmyYA3NhHjwBT8Kv4Sl4Gp6BZ+E3sFAd 0hbBYngZXoFXYQksVYf0vmqTPgDSYJj6QH9ORfXnVZRdPpxVibPP6tljm1iJOHvsTvZYvbyQOCWr eSJqlCVrE9XyYqJI1ilT1idOym9VmkxwXanWRiBxyjDVzYalLMNOVBvBRJHhKNMIJU4aYZVmNOJ6 Y9pNVVuMaTAdHocZMBNmQRbMhmyYA3Pht6rIeBPWwFuwFt6GXHgH1sF6+C/4HWyAjbAJfg+bIQ/e hT/AB6rY2AJbYRtshw/hI/gYPoFP4TPYAX+EfWqTUQgR2A8H4CC4cAiiUASHoVhtCtSpLaYE9q8Z UNvMZhybQxfoDf3gKlVkXsvxBVVsLoEczpmn+RavmY/JfEzmYzIfcyPXNsFmyIP3YQvXt8I22A7Y bmK7+QWvv4SveJ0Pu2EPHICD6pAZ5b2TUA5n4Rych0qogmpVbDWGJtAULoFW6pDVGtpAW2gHA1SR dS1MUZusR2EePAGLYBW8ofZa6zlWq012D1VsX6aK7Cs59uU4FO7k9b3qkD2W98fBQ/Ac13O4/hos g+WwHurUoaBQxcFLOPJ8BXmugm2gnSpyxqqoMxEyYBJMhqnA8+7wvDs87w7Pu8Pz7vC8Oy/CS7AA FgL2OovhZXgFXoUlsBRy4DVYBsthBayE14E5OqvhDfgtvAlr1KbQT1Q0dAcMhiEwFO6En8IwyFIf hGZDNsyBuTAPnoAn4dfwFDwNz8Cz8Bt4Dp6H+fACvAgvwQJYCIvhZXgFXoUlsBRy4DX1Qfgytalx UH3Q2IGQ+kAY5IpNRP6Y3C+uJC7Xi1fFLLVcZMFsyIY5UKui1M9R6uco9XOU+jlK/exRP3vUzx71 s0f97FE/e9TPHvWzR/3sUT971M8e9bNH/exRP3vUzx71s0f97FE/e9TPHvWzR/3sUT971M8e9bNH /exRP3vUzx71s0f97FE/e9TPHvWzR/3sUT971M8e9bNH/exRP3vUzx71s+d/C5f2J+zcpeLUrHFq 1jg1a5yaNU4dmkMdmkPdWUjdWUjdWaivUaeSfx/53V8dfaNXq2/IZi5ZbLncIzqQL0vIYC9Qwy2n hltODbecGi5ODRenhvPrpyj1U5T6KUrN5FEzedRMHjWTR83kUTN51EjLqYOWU6cspyZZTg2xnBrC o0aIUxt41AFx6oC41VtFrcuS38cZR/v7Wj6Kzo6iraNo4SgaOIr+9dC/HvrXQ/966F8P/euhfz30 r4f+9dC/HvrXQ/966F8P/euhfz30r4f+9dC/Hno1jl6No1c9NGrcnkbf83j9tv+tacpDb3rozXgw hedphMpBY+agKQvRlIXhbHUqPAfmqlONUtQ3jVpAKnSAjvAE199U3widrPJf5HV0nNwqrpPbxP3y YzFAfiJa4d/35WcoqR2ih9wthuLrodT1ARTDjdT2zWRE9MfvX6Mc2qNzjnL1mOiNXhiKXuguT4lb 6Pezhs+yL2OkT9V62r+cHHMT701EVWwTjbn2OWd7/O+l/L+/S1ebINL+8ffpYk8/no4bGHUw+fB2 bPjuSj+yZTVXbyZbbiNbxpLfUVzu/xolV9txdmPyM8WWtO2GDf5vEZwQV9DiSs72iDRmmMJ77Zmr /61vI1S+nCoGYv9nxiD0ms6VP3P2Ja3JTWjCCs6KOcsQjTi7yNmfRQ9hiDQRABMssCEIDoQgDI2g MSMOFy3kSDTeaMhgTtvQgZ+gMz9Ve42pIs2YBtPhcZgBM2EWZMFsyIY5MFekUcunUbOnUbOnUaOn UaOnUZOnUX+nUXunUW+nJX//ohHqtpKRipnFCfkxK+n/msmn6j3UbTlzn4pPtmLXh7Ritsy9kWim FYgu2l7RF8+Mxg8/kiNpNUqMkqOT3zE3SmaoT/1vJZLT1VG5RFwjl4prGcdjpbuhZDYY14n+xkDR F2+NEu25oz3jDGA1p4qOjHTaHz85UqOG3zXZJe/j7vtp/wDHBzlOZYcVqENo5Dj6uDa5fw4Im7uk MP1fQqF1Ki1TaRmkpUeLCpEqjhFF0VCiFN30KCP5azpdFaK746x6EyLu3mR/EVZwP3fRp6+IA81U PTV8PTV8PTVyPTVyPTVyPTVyPbVvPWMOV6f8//FEj715Uqxkb/tVpWj5N2PeR8x6ADKZ21SU+B51 FusqmIfHjmvB2FXctZNxQ4xb80/HDTHuUf+3WeitGeMG6LGKHuP0WEmPQXo72zCLep6z4Vz1vy/w PpT8A/Ao70wVrbkziMUmd17gznrubIQtCd9r3FnHU3FM3CqOQynUsrMvQh3Uw7dEh+FULiNUX3kf 0eJ+MUY+wPFBjpnUPo9iz3T1ppzNvlgifsB+uAGPFzDiwOTa7FMrk6NF1AGeuRSqnIsNe6S/Qd9G ApToEWgmbrVGwigYLXpYS2ENlHD+DRwF7LQquFbJ8QK2+d//WIFltcy5Fst6M+9aLOvNvNswbz9i 2MzXYa4n5UHRNLnrtnPHZ9xxnDvacMdx7mjDHT+gdVNsPpHceftUHXbXcOfx5F2R5O8SjGS8Uezk 0RzHcJxGVDwqOhPxKogxDpGxNZHxEuLd9uQv6vjrF6WV5EoF6zCcVyOSz4b/bXip8jF21ePkuxPY fYoRy5SX3G8l3Hec+xx6t+lZ552oaC3GqbPiIXgYHmP1h7OeI7FrNExjZ/qtj7FLTuDpk9hURn0Z o5dy8uQg0TLQVJ0NxOG0OmtmQCZMgkdgGkyn38YNvwnk0nOUnqPyMWY1jZh/lHU8xi46zhOUnC1x +BQ+KlNfJWvxlthXh3112FfXMHv/M+Uj9HKEXnR66Y2NTemlml4S9OJ/07xND9/4v0eEfXXYV4d9 ddhXh3112FeHfXXiCjFODBYPwcMwS6SLLJgN2TBHpDNiE0a8nJgVwMPDiFkBvDyMmPU2nt6Mpz9k n+5in97OPh0s16lFzOlLMkT376whb/nWnEJNXCcGskcHGoOUa6wS6cZqeEOkB5qKwYESjnGOp+GM SDd7wTWQIQabmTAJHgHfPhurLjTsG71h3+jJtfI9WKZOJj+N2IDdaxtapTa0SsVuj5b9k59AlKlC dkZGYge14GlqvxJqvdPUdiVGz0Qpey0j4XG1gisVRk91I71mJI7IC/i5jrvriQ3fqt1GQFVTF9YY IVVJy920vCV576e8u5cre7niJO/15EXGq8Mr36r91JgJIyhM7k3Qaj+1ZIKWacSljMQJRklQpVZi WVzWcqxj1Hp25nd31jNqguq0Eovjhs3RwYoQ17/rqZ4ZVLHrMqhrq4VGLxX0kqAXRQ+nkmObQuPu Cu5OcLfizlMNNvTy/ZRYiA1HubsLdxdx9wV5kSfWt76effwtOy6BTlDqW2w5Sm9d6K2I3i4YQRVJ zirEOodFUyrlGD1/i02/87Oo0umxBjuKZULo3FXD2MVGI173VJ38Fok9tDjJeL6norQ4SZ++l6L0 cQbv/t16sfoN68Td/2R9km2T60Lbf7IezPF/uQ7E03/R/0SZ/7DfmeP/4O/kO//Qz6KxkSKCRgvs ayUcow29teWedmiGS3ndnvc68F5n3uvKeTfe6857PcgHhpHKCG15tyPHbqxJ2EjhjBrCaMn4bRih LSP5fbXnegeud+J6V6534zr9sAp+a3/ktg0t/JH8vpphl867pUYqV1pCK9Ee+5rRspQ+22Ofjn06 d5UaHXm/E3TmelfadONad1738H+VnF6KsdWfoW60xtY2ItDQi393Mfb7M9SNLrzXlfe+u1tnvinQ gr2Xis2t6LcNc2nL6rdjrEv9efF+B97vyPudeb8r17rxfnfe78H8mAVr04J+U7naElqpA9iQwDtH jXas5aXMuT1tOtCmI+93gs606UKbrrTpTpseZDZ/ncJJv7YSKdjhe6wGO1KwI4Qd4aRvO3PeNenB GmxIwYaQvypCJufepsHP31nve08m5/3dHRUNVuuiyb+7J3hqPfz3d/uCp72PaPSv7g3u6ius/2l/ 8G430fw/tUfo7XJm/W/uE+7uKS753+4VernOn9F/Zr+wEl8k1/Hf2jPJ3NDoX903yajeU15IlBFJ HyDitCOqDZEXExVEtR/L+kSM6DOOqNaRqDbQCCTKiKgPEI3aEdWGGMFEBVHtx0YoESMyjSOqdSSq DTRSEhfwyBV4pBce6WW04ry1uhyPNMaqfnilO17pZrTnegfadaRNJ+jMeRfadaVdN9p1p10Pdk2Q yi1MzZUm/d/12SGao3ZTULpdURU/QCvsRO01Sf620FZttLhee0Dcoj0o5mu/4DiWyn24WiHvoRb5 udqK8liR/KW6Xv+PVjuTrfzfQDqYvPqXs01/PdOp5D/SPlGbkq/8X7c7yqsmVMlXCCEGUpP2Fj/k X19xh7hL9BP3iJ9z9V603A3il+IF8RPxklgnHhFbxUecfcK/ReILcUAsFi7/VoliqpPV4iQ9vqO1 1dqKfVp77QpRqA3Whohj2p3a3aJUG6ndJ8q1MdoY4WkPauNEhZahTRLntWlajrigLeNfG20F/9pq r/OvnfaOtk67VPtE26N10Pvq/bU++gD9Wq2/PlAfqF2j36inadfqP9LTtev0W/RbtOv12/Q7tBv0 IfoQ7SZ9mH6X9kP9Hn2Elq6P0kdpt+pj9DHabfo4/SHtdn28Pl67Q5+gT9IG64/q07Wf6TP0Z7Wf 68/pL2rj9QX6Ei1Dz9Ff06bqa/Tfa9P1PH2n9pS+Sz+gLdVd/Zj2tl6ml2t5eoV+RntPP6dXax/o tXqd9pGupNA+lbqU2g5pyUbaTtlENtO+kikyRSuQqbKNtld2kp21A7Kr7Ka5sofspUXl5fIKrVj2 kX20r2U/2V8rkQPkNdpROVBer5XKQfJG7aS8Sd6klcmb5c1aTKbLdK1cDpF3anF5txyhVciRcqxW KTNkppaQj8rHdSFny9m6KefIOboll8ilui03yA26I9+V7+oh+b58Xw/LLXKH3kjulgf1VvKoLNc7 ywtS6ZcbAaOxfo2RYvTUbzIGGYP04cZU41n9HuN54w/6ROMD4yN9iZFv7NFXGvuMUn21ccpQ+rsB J+DoXwXCgbCeH2gaaKbvDhQGDul7A4cDJbobOBY4phcHTgRO6EcCpwJl+teB8sAZ/ZvAucA5/WSg KlCtnwrUBmr18kBdoE6PB741A/pp0zIb6xfMpmZTPWE2M1voymxltpfS7GReJR3zavNqeal5rXmr bG/eaQ6Xfcz7zSflNeZT5jPyPvM5c74cYy4wF8hfmIvMxXKs+ar5qnzIXGqukA+bq83VMsN803xT ZppvmW/JSeZ6M08+Yr5nbpczzI/Nz+Rc80/mLvlr83Nzv3zaPGi6crEZNaPyFfOI+bV81TxpxuRS 86xZL5dbwtLl25ZldZTrrO7WAPlH6zprkCy0brJukq71I+tWecj6iTVUHrGGWcPkMetu62553LrH ukeWWiOtMfKENdYaJ+PWBGuC9KxfWTNkhTXLmiO/teZZTxi69Yz1rGFYz1vzDdNaYOUYtrXMWmY0 s1ZYK4zm1uvWKiPFWmOtMVKt9dY2o6W1w/rc6GnttQ4Yfawi65xxtVVpXTSGWPWWMu62u9vdjRF2 T7u3ca99pd3HuM8eYA8wRtvX2QONMfYN9iDjQfsm+yZjrH2b/RNjnD3YHmyMt4fadxq/tO+yhxsT 7Xvte41Me6w93phkP2JPMR6zZ9mzjOl2tp1tPG7Ps580ZtjP2s8ZWfZ8+wVjjr3AXmDMsxfbi40n 7CX2cuNJ+2071/iNvd5ebzxvb7A3GPPtc/Z54wW7yq4yXrJr7BpjQZDAZywMGkHDWBy0go7xcjAc bGksDbYO/jd13wEmRbF2/XZ1d3XPTPVmYANLziASFySDgAoqGPGiKEbMIiIqgoheFRUFRQE/kWxA EIwgoKBXMEeQKDkISJCcpf5T78yuu+7C7gJX79/zTG11daWZqTp1Toezac6EUEaojDMxVC5Uznkj fEm4qzMp3D3c3XknfEP4Bufd8M3hW5z3wreFb3M+CN8RvtOZHu4Z7ul8GO4T7uPMDPcN93VmhfuF Bzizw0+Epzhzw5+Ev3Q2hheFVzg7wqvCG5394UORdOdYpGJkqFsu8nxknPtsZHpkjjs68kNkt/u6 8lSq+42qqdq5K9UV6mb3oLpN9ZQh1Uv1lvGqj7pfJqm+qq8sofqpx2RJNUg9K8upoWqorKqeVy/I amq4GitrqvFqvMxSE9UU2UhNU+/LVmqGmi3bq4/Vx7KjmqvmyvPVp+pLeYH6Vi2Ql6mf1c/yKrVY LZXd1HK1WnZXa9VOeZPaow7KPuqwOir7qWMByQGBCIR8JHACKR8N/CCQjwcJQUk5OEgNUuWwID0o LV8IygSV5IigSlBFjg4GBAPkmGBg8JgcGwwKnpGvBs8Fw+Tk4MVguJwavBS8JN8OXg5elu8ErwTj 5LvBhOB1OSNOxMXJj+KS4krJr+Iy4jLlD3EH4g7LBSTC4O9Eqk1iZ6pG5eg0bXqWXq9/pTp6M+K/ FJjjmH5ZT8Prd/0U9jrrK1FmPmKbY8c3698Qro3t7c9X3hz9Te/F689jXgHt7MH7hUL7+yDeH+dJ WYUWSppWjrtBeSHfMn0EcYWV/CoKsL8+bx+zP00BbX6r1+gd+jvUsA6fdlNhfSzC5qPW4bHaN+ht er7eGNvbna/1rXiv1Kv1Qn1Qd6AQvrsaVD7X8WOFNab34bfbixr+7Dm+fzCW6NFX9auk8M75Df9S ejveG/Vy1LEKuy54VhVqgVhZPjpPf68XY/xg7EC3F9z+m3q8Ho2/g/BuqWvre3VvxHJ9j9mfHrFt +Uof05/rTRhBn+tv0A/8Dubby1sqJ++3hXwVBJ1KFMexZ2MpO1D3d9ljM/eoiKXsxSffje/+F70H fD8eSQ3wK+S0rrfyL7Q1O3e+8tv0FsyxHdnfuDkzyn9X5M5TWL9j+Zbn2bs7z96XRasDW13OHxtp egl+P18vKaTlA7nmdl1qXEjuKfoNM6P150XuU97yv5rRYcZsviOLilAan0w/zrHpf53P+roilMcY 0e8zbq0yv1txNz2J0XQSvtf8m1+kGn7Xsxg1izguCqhhd9FHVQGlYwirF5xU6bc5XGKQ47Rv9YvQ /q/RtUwfwTjaU+wW1AmPVsX7Ym4le8VbG33FjpctoEx1vMriVT1PL1+L/f0h+jpB+boFlo99uxgl +4BO+47XYeDndr0LCLaG55QZ1Qc5fRgfLqM/0XP0z2ZFP075o7niT1Ma8L8LdTIzJJa2EmvD7PxY nFPmSK74UKw88XQedUd8aixtPb69n46/qma3zyP6JZQPAX16xZDcpL+rp5GtZxy3/F9HoQv21APp z8SOf6m/wPf/dWwvP34fzhV/CqXT6AIyTKhlLO1jPRM1vHXc9jcUnH4Mv5jBR32RvlDfoDvFco/J V/4RoNir+i39o/45V7KgbvQoDUbsWRpinpmhKRi5U2kG2OFsmkP1+KxCFn1Gi6kRLaON1JE2WRZd YXW3utM9UPQXU2+j5amPUfF0n7hV3EEPQI8vpf7iF7GeHhKbxWZ6QvwmttIgo83pKbFfHKDB4og4 Qs8abU5DjDan56DNIzTMLmuXpZH2VXY3esnubl9LLzvTnelkVK2m0W6Sm0Tfyg/kB/Sd/FjOoe/l L3IF/Si11LTAaDpaaDQdLfU6exfRSqPpaDU0XRdaYzQdrTOajjYbTUe/GU1HW42mo0NG09ExaLqn LYKae86S3jBvpBUyms6KN5rOSjCazkr0JngTrWSj6awSRtNZVaDpdltnQM1pq5Nv+651pe/7Yetq X/lx1rV+op9s3eCX8EtZPfx0v7R1q1/GL2fd4Vf0K1s9/RZ+S+seqLYbrXuhzgZZ90OdPW31NfrL etBoIquf0URW/8iDkaHWQKN0rBEqQaVas9UUNcWap9arndZ8ozWshUZrWMuM1rBWGK1hrTZaw1pj tIa13mgNa4vRGtZOozWsXUZrWHuN1rCOGB1hHTU6wvrD6Agh4kJxEeHFlYgrJcJxB+MOC3NNYQmP GItHjMCIGQ5FMYL+D2P6ZZqIlFfx8ug1ehOr1GSMJ8njSWI8fYRZ9zFGVZhHVRij6iukf00/U4QW 4SUwyhaDVS+jFWBXK2kd5th6jLnytIl2YcbvxqsC7aEDVJEO4lWJDtEfVJmOYUQm8ojM5BFp84hU PCIVRuTtlCDuwLhUPC6TMC5XUkmxSqyiZLFarKVSYp1YR6liPcZraR6vGTxeU3m8luDxms7jNVlo oSnZBv2nFIxagRAblcDY9RDHj09pdgjjOIXHcQbG8VVUxe6G0VwVo7k74tdiTFflMZ2JMb2SLGeV s5GE86uziaSz2dlBEed3Zy+VcfY5+yneOeAcpbLOHxj9lXn0l+fRn8mjP5NHfyaP/kyM/rMpxWvr taWI185rR47XHvPBxXzogJSOXkeknO+dT553gXcB+d6FmCcVMU86o+xFmC0hni0RcwaEAq8L5kwc 5syVVN67yutG8d7V3tVU2bsGsyiRZ1EizyILs+g2lLrd64k8d3u9kHKPdw8Jr7d3L1rp4/VBzfdh pkUw0x5EqX5eP6T39/oj/0OYewHPPcucT0GeQd6TaPcp72kcHeINQcpQbyhKPec9hzzDvOFIGeGN QE9GeiORgvlJYTM/Uc9obzRKjfHGIH2CNwH1TPQmIudkbzJSpnhTUXaaNw3fw9ve+/hmPvBmop+z vFn4TmZ7s9Grz7z56O3n3leo8ycPI9Nb5GFMeku85ajtF281lfPWeOvxnWzwNqOtLd5vVMHb6m3D N7nd20GVvN+939HiTm83+rzX24uc+7x9OLrf24/0A94B9OSgdwj1H/YOo+Yj3hHUfNQ7SsneH94f aP2YdwxltafN/1f1Xco0aIIQaIIQaIIQaIIQaIIQaIIQaIIQaIIQaEIW0OQJhIP8QSQMppBjMIUs gymkgCn9EPYPD6AEgyxkA1kWk4osiSylILIsspsSDMqQbVCG0oAy6ylZbVAbKEVtVBspUL+qX6mk 2qQ24ehmtZlS1Ra1hUqr39R2xHeoHcj/u/odeXaqncizR+1BfK/aR+lqv9qPPAfUQeQ5rA7j6BF1 lCLqmNKUGhhpnWzwC6ETOAjdQFISUMynUkEoCFOJIBJEkFMFAZUGriUjJSUoSekG3agk0C0dYUZQ GnnKBGUpJSgXlEM95YMKiFcMKiJ/paAS4sA+pAP7kPJKMBqtjAnGotS4YBxqnhBMRJ2vBq9TCYOG ZBs0pASDhpQAxHonhoZD8bIZDV2g4UjEXwYO2oyDEig4BfGp9CHCmYTRBjT8BPH/AANtmg8ctIGD i4CYi4GvNp+/9xkHbcbBEoyDJRkHw4yDpRgHUxkH0xgH0xkHlRVvxVNgdbW6IrzdugPhXVYvhL2t 3gifsp6iACh5EQlGyRBQ8gaEBiUjjJIhRsk4xsQUsU1so0TGwSTGwWTxh/iD4hkBE2zHdigJ2Ocj HrbDlGh3tbtSaftKvpPNYF8mY19Z+2r7aqRfw3e3GRzMZBwsa19nX08ZOTi4iWwg4F7ygX1HKcyo l86oV9KctcX8bO21xuxt47UhmzHO984BxjnAuI6IG3SzGd0ko1uq18nrhBSDbrZ3iXcJwku9y5DT YJzD6FaS0S3M6JYOdOtOyrvOuw7h9d71yH+jdyPCHl4PhAbpfEa6cAzpenu9kXIvkE4yxvneA94D KNvX64v82Ug3APEoxj3iPYq4QTqfkc5mpAt7g73BKPWM9yxSDOr5jHoqhnrPe88j3WCfz9iXzqhn M+o53itAPTuGemO9sYiP88YB0cZ745Hf4KDNOJieCwdtxkEfODgL8Sj2feR9ivhn3o8IDfb5wL7l iBvUK8GoV5JRL8yoV4pRL5VRL41RL51RT3l7vD0oZbCvJGNfKmNfegz7jgLjbMY45Vu+RXYUrcL3 hx+gUPjB8IMI+4f7UyQ8ANgUCQ8MD0TKY+HHKMQ4JSLPR14iwYiTorYDaxLULrWbkhhfEhhZUoAs BxA/qA5RPDDlGOa5wZTEwA5sigeaeBTHOJLEOJICBElC3CBIclAqKIU8BjtSgswgE+llY9hRHjUY 7Ehi7Ehg7Ehk7EgCdryCOscEY1BqQjAB+ScCNZIYNQSJejvNmddGv56dRR3oiuPx/P8/Nr1ZbzHv 2N6agnSXOc/D5/qKW/cGc4aLlfcnvP9Ldpsc/hhTn9uM/mQtulyv05vyntEpvN3sM3S6Z/F7eHo3 3RHK0/w9rvbOV2IzlPYXJ39eJqeebX/d07s4jKVDK+7FN7tO78A758xeLiWakqv0cuRaSua8RynE YmcYs9X137SFc3qTu11F/+K0rQWdXdC/5T83p3frtXoZjuS7CnGyW/ZZ8rx7Zv7ERnWu8wXou50T 33a8X1mvzn9W83RtBV/BKbTURD2O/x7ls+Ffmrc5P6QnIfZVLE/2yDIzeJ/+ITu9WO1s4DG67s99 cxZMr8yV4xk+H2TOla/m2Ab0JjdCxb7fov6+fNZ6XeH5ir9hpOWqV+/XR/E+bM516T/y5DvRdan/ se1vnvNF2PSoUyjcuYD61lE1jMEyp1DribdqxNhq8JQxtcAN2FDka4invlb8pb48vco994pY/l09 R78duz6QosfoOZy63qzuuVfvk+IPS4GNa5g/bGJuwmhm1iS9Bn8nx3Lt4OttX+M9H69Nec9cM5Kl Ufa52XlYC77SP+E9Cqkd9EL9Daf/HGURfEX7X8Xvab6eb8mzx2uofidXyq16gr5DP2nO8uteOalN kfahmXf5rzqSueaa/1rob/oTfJblp2+mZo8Hs44BwbJ54VcUuz6buw/A5ZxrI+YaSyE1f3e6+niy G76lgP8+Z6435zvaW8/Lkzf6dyVWt/VmhJxEe4vMqGe+xd+TiWF9WxP71hDqW/T3/HsfILuANSyg Ovnq3IF5sD12dckGcmRfdToQPXrq69uf16HzXq/MZimGe/G6vQGvHfm452rmngXMdszm04xdBW1/ wbOF+Y4f/WtKLP3ugtOpONfRi73pm4pZIHqPxSD9GP/9nRHgPfNG7A09PRrjY9n8jK934peaeRK9 e1d/CMT8ILY3T79J5v6gGSaON5ATKDYPKJHNgn8H+n4Tw4no9bO4fHV+oT/Qc2N1ppi9WHoedNC6 +L3lcpilelnOXrZ2WWti2boyysQZ0b4y4yN6j0hs/uxmRO6mO/PeXDJX83rifR9iQ/VIrHX3xWrJ dW8LvoHZuu9J9PZa3V+P13cg9h/M6vG6B+PDM1iNxuN7nqtH6Zuxtv5urgHyJ5ulp+qx0ZZjq0a6 /s9f6tykF0NVRmduw5xYjHfqQ9F30Rlznrr38nzPuSso7yrF63SO8mXmu4bve8h9x0XtvHes/F1b 3qu4fAfT9sJ7wp8o3/1Xf8eWV8mabxVjeE9h+Mm/zmlTusXZcvMPzAajspbg73GudOfk/O3U+6tf 0f30v/UIjv+A8T7O3CkTW4eifHGffh/vOafWDtdUJ3onyynVsV7/ipWQ10f8pr9iHOZw7uivrneC c+wsiAEWu62T4Ny5Sn8T/VXRF4OD38X2VsfmT6zX/8x8LmjTN+kb9Ud6Ogne66/7AK27RxmBnqEP Ym+wvlufpSsCRxvo+/Qtp9BWlD+WO6X+xjApqmlz7jccl/fo6dz0xNNQhxm9i6OoDn6b79fn4+v0 gj9X4X92Q29+wZzjc54Yw0Yp5iiVKNPF0S/wPs69qn/3hv4+m3vmgl/N+if7c/wNs6234U7RO131 PWBHP2P2RY/N5fAXPVNfqZ9EbIheEU07yba+OPX+FrPFvbnv8/rf3XI47u5Tv7uyoHvdT+cWZYfg 3xux6p2GMxaF3aN8wrJFHFF6Gp/b33ryLeXa0k5LLUXawIVOmbnq505HTwppI4Z0YLenfF7+NP1K hbWyHsz2vzxTTt8G1rP3tH0zSafQj9Mx3//G6xEnMxrBe9ZFS8ae7Mg+L/I9X2f4/oSF74zlfbv4 7f7d28k8A5GvjuNeDTlBGT5bb84URZVw9IxOzrXg8In0MZ/bTaM7SBa/XS5/Ek956U28dvz5LFn2 ObmiarsInVP8Vv/RreTJFiz+lScydzWY69I5yl7P5nA78LnQqxH/axt4/77jPzORK9/B/35firYV DSFPdlUv8FmpQtviOwj+fHaQr1jkjKxwgYWy85pzVaXpSsy5f2DLy92jqAH1VAjO8pWYf+B8n951 GutaS7EzygU+cVSdn3IyV9B/KOBoYXWb56jWZpfMjvEZ/rWxlOw2m3Jbf+lXrr0n/qwzuy/mea18 vTJPZdU1V2lORrXrUfo1PSvnObBYzDCC2DnNH3L6UTdff18rfnt5yp/EnUJ6AV+V+Dpnn+8BAt+U Rb7SV4Sn947TdoHPJhdS5lc+a2VWcsYC3puHuRdFhvCJ+CWvKPHUomjPaxZQ/mTuf1honrfk9/7o Poexs+YnRofYZymd934jjK9d+id+j6JS4KRbYleT1kTnNI+1W4vf00I+R/QKWy61rrvr+/TrejT7 BuTc06M76neLWfO8v4cxmz4evx19rKCrytErin9J21X4VZyT3fgemRgy693gE7vBj5bq5X8ikd6G NHPNuLG+nPffwwhYrLvp+WZfz9Uv6M/NGXM+NixP3Suz04vVo076Dj1Qd4jtcQwjsAfHX9MTdC+M g1Fga7Ow8poc0/UH+v3Yqm3OzpekOnzN+X59O6dF70ccDV79ivk9jEtCzl1Aec4F6UPZT/MXq78v 6UnQav8X2/ue2x7FOP89fwfm6uvbeq/+lDNEn9qP3WEQG8UNi9/qP7X9V57Gzt/K2mzEil53/qe2 k7lOhV96O+U665DjkFCUtSeZzP07l3C8NDWA9izHZTeCdWzk1SSD6utFmKHmtVKv0mdhvvQgpaPr ekynYnZGNVWp2P67sSsVgnKemOb0KSf4HHxvhe6LdS52BlK31tfg3VHfRMk6ugZne2j0x7udbqov 07EnG/SXegXfLWFm7G9Yk9bG9GtNqsYrZ03OdeKzGwX3a5yegHBSzv4so+Xy3FlxaSxyJV1Mjake +8RU5iO5P3v42AIdOXaAV8qP9G36PbOG6Yf0oyaGWp/K02z0HrDbTqK/t+u78Pnv4h0fsdsZNx/l lfon/JabjkWfpJ/BriDZG3+z+p5YHUXQeAW2vaXwPPnKbOM7AgxP4NHEo3ke9h0+rE7Id0ypeGqG 3gtaWIiPXdeYj90jdJ4lrBJ0A7vT3c/udIPYne4pq6vVjYZat1i30AvsS/eida/1FI20BlsjaKpx p6NZxp2OZht3OvrIuNPRx9an1g80V9QRdel70UBk0Y/GnY4WipaiJf1s3OlokThPdKQlope4h5aL +8UDtEIMFcNolZgoJtI68bqYSuvFdDGDtoqZYiZtFx+JObRDzBPzaZf4SnxFe8R34nvaK34UP9F+ sVAspINisVhMh2xlB3TYTrCT6KhxmCPNDnPEDnOuXcmuZHnsMOezq1zEzrKzrIBd5eLYVS6BXeWS 2E8u2e5qX2ml2Ffb11glzbNyVqpxfbPSjeubVduZ4cyxuhrXN+s64/Rm3Wic3qyb3AQ30erhprhp 1i3G7826y13hrrX6GL83q5/xe7P6G7836yHj92Y9bPzerMfdfe4R6wnj8WY9azzerBHG480aYzze rLHG482aaDzerMnG482aYzzerLnG4836UXaTj1tLjLubsIy7m3CMu5twjbub8Iy7m/DlWDlBxBlf N5FkfN1EsvF1E6WNr5uoaHzdRFX5lVwqqhtHN3GWcXQTTeQmuVU0M45uorVxdBMXGEc30dk4uolb jaObeMA8Hyce8oUvxABf+p542I/4EfGIH+8niEf9FD9FPOan+mnicT/TzxSD/PJ+BfGkcVwTTxvH NTHYOK6JIX5dv654zviuieeN75oYZnzXxIt+K7+1GGF818RLxndNjDK+a+IV47smxhjfNTHev8nv ISYY3zXxqt/b7y3eMO5rYpJxXxNvGvc1Mdl/0n9STPUH+4PFNH+IP1S8bdzXxLvGfU28Z9zXxEzj viZm++/5c8RH/if+QvGlv9hfIlb4y/xfxCp/pb9JrPW3+HvENuPKJg4YVzZx0NchSxwyrmziqHFl E38YVzbbCqWFytiB8WOzk0MVQtXslFDNUG07I1QvVM8uG2oYamiXCzUKNbXLh5qH2thVQm1Dbe1a ofahc+0zQh1CHe06oQtCnex6oS6hK+yGoTtDvexG4XLhSnYz4+5mtzbubvZ5xq3N7mDc2uyexq3N fsC4tdkDjVub/WTk0sj19mTz1J4927i12Z8pT8Xb3xqfNnuRulLdbO80Pm32MePT5jjGp83xjE+b EzY+bU7E+LQ5JYxPm1Pa+LQ5mcanzSlnfNqcmmqimuzUMj5tTgPj0+Y0MT5tTkvj0+a0Mj5tTmvj 0+acZ3zanM7Gp825yPi0OZeqtWqd09W4rDlXGZc1p5txWXOuMy5rzs3GZc25zbisOXfEiTjfuTNO xcU598YlxaU49xtnNefBuANxB5yH4inecgaQsNYB9eKg+OIpgSxKxMumJKzDDqVi7XaxqldGehW8 PKqKVdCnWkDJEPCwKSngofk/Dy34P2AYxIxjxIwHYl6OUl3wSgRudkONV9P11IpuAIa2Bob2AnO4 B6821JvupxL0AF4lqS89hJYHAGFTgbCK0qzAiqN0fkI4w0oA5p4BzK2KlGpWNapjVbdqIL2mVRPx WsDiNMbiusDiTgg7A5HbsV9omtUNuFyPcbke43J94HI/pPe3nqAG1iBrEOp8EkidAaQeQlnWUOtF amQNB2rXZdSuy6hdl1G7DlB7EuJvArvrALvnYz343PqcmlpfWN9QM+tboHlzRnMBNG+AsCEwXTKm JzCmC8b0BMb0FMb0sxnTz2RMb8yYXhqYPonKijfFm5QpJou3qLyYCpSvwChfgVG+HFD+I4QfA+vL MNZXYqzPBNZ/h/B7IH45IP6PCH8C7pdh3C/DuF8RuK+osh0A/asw+ldj9K8K9E+lGnaanUY17XQ7 ndqalQBxrARUHStBVYTV7OoohfWAapn1AKWa2E0QNrWb4mhzuznCFnYL5MHagBBrA1LMs9bn8LPW 5/Lz1efw89Xn8jPV7bFODKAWzsPOE2RhtRhK8c5zznA6yxnhjKRk5yVnNDVxxjjjqJQz3nmL0pyp zgeUjhVlBtUzbqLUwKwr1MysK6TMuoIwwU2g1m6im0h1zepC9bC6/Ey2u8hdROXcxe5iineXuEvI cZe6y8jFqrMCKSvdlUhZ5a4iz13tribfXeOuoRLuWnctRcyaRIFZk5Bzs7uZEt0t7hZKwsq0lSx3 m7sdLe5wf6dkd6e7k0qZtQot7nP3Uaq7391Pzd0D7gH07aB7EP055B5C/LB7GPEj7hFq4f7h/oGa j0lBydKWDrWQrnTJwgrnERYL6VMgQzJM8TIiI2RLJRWlykAG1FzGyTjkwSpo/qu7TEbZFFkCZVNl GvKnywxKkqVlJmouI8uQcUAtj7CCrIAaKsqKyF9JVkL+yrIa8leX1amUrCFrIL2mrEmOrCVrUZw8 Q9ZG/WfKM1G2jqyD2urKushTT9ZD2fqyPimz4qKtRrIR0hvLJsjZVDZFDc1kK3Jla9kOOdvL9uTJ c+Q56HMneRE+18XyMtTfTXZH69fK69DK9fIm1NND3kat5O3yLmote8reaPFe2YfayPsk0EM+IPtS SfmgfBC97ScfwmcZIB9GPQPlQNTwiHwENTwqH6WI/Lf8N1p5TD6GPI/Lx9EKGABlGAZAdcAAnqMG 8nn5PNU3PIDSwANG4OhIOZLS5UsSOCBfli9TMzlKjsK3PVaORThOjqd6xgMW+cEVUMNkORnhFIlR KqfKqSg7Tb5N7eQ78h3U/K58D0eny+koO0POQPqHchZyzpYfIedc+QmOfir/Q1lgGJ8j/Qv5BdUG z/gK+b+WXyPlG/kNcn4rf0DOH+WP6M9PcgHyLJQL0cOf5SL0ebFcTGfIJXIJNZJL5VKUBUdBqVVy FWpeLVej1Ca5CbVtlr8h/1a5Ffl3yX3Is1/ux7dxQB5A3w7Ko5RmeAzVB48JEI/zEqmBl+QlU4aX 4pWiLC/VK02NvEyvHNUFy6lKzbxqXnU6z6vh1aSmXi2vFlLO8M6k5l4drw5qqOvVRc56Xj3kqe/V x9EGHrQjuNFZ1NBr4jVBW029psjfzGuGo8295mjLeApYhjNRPcOZEIIzIQRnQgjOhBCcCSE4E0Jw JoTgTJRuOBNlGM6EEJyJzjCcCXFwJmpmOBOlGa9aqu239lujFJgTUsCckAfMCSGYE2UZ5kSNwJyg BPwefg9qDv50F8X7Pf27kQcsCmXBopAOFoWcD/sPo56B/kDEH/EfQToYFfoDRoX8Q/wh1MAf6g9F KfAqqg9eNRwpI3yMOn+k/zLir/uvo603/DfoPMO0kAKmRWHDtBCCaSEE00IIpoVwi7+LWvq7/d1o ZY+/B/WAdVEdw7oQ1742/3srRNQuZIUsSjMMjDLAwDyEfsinhiFsVCcUDoURV6E4hPEhrL+hhFAC ZYUSQ0lISQ4lU7NQSiiF6odKhEpQ81DJUCmkp4XSqEEoPZROZ4QyQhmIlw6VRiuZoUwcLRMqgxRw O8TB7dATcDuE4HYIwe0QgtshBLdDCG6HENwOIbgdQnA7hOB2CMHtKGy4HbUEt7uEEsKXhi8lGb4s fBnil4cvR7xLuAviV4S7Uophfkh5IjyRRPjV8BTEwf8QB/9DHvA/5DkUsUhERCSdzjYskBpHvRsM CyRhWCBCsECEV6orKVNdpa6icqqb6kaJ6mp1NZVV16hrqKLqrrpTBXWtupZsdZ26EfGb1E3I30P1 QJ6b1c3Ic5u6DfHb1R1USd2p7kSeu1RP5OmleuHoPao3lQGzvA/p96v7kQ5+ibCf6oewv3qISqsB 6mEqrwaqR5DzUfUocv5bPYYWB6mnkTJYPYuawUHRyvPqeYTD1AvIM1yNQJ9HqpGo5yX1f4i/rF5G /lFqFOKvqFdQ52g1GkfHqDFUVY1VY6m6Ya5UDcx1ItVUr6pXqa16TU1C/E31JvJMVpNxdJqahvBt 9Q7VUu+qd3H0PfU+js5QH1INNVPNQspsNRsp4LsIwXcRfqr+Q5XVZ2oe8sxXn1MV9YX6Ajm/VF+i lW/VD0j5US1AnWDDqH+xWoxwiVqKPMvVLzi6Qq1APSvVKsRXq9XUACx5LWpbp9ZRVcOVqQy48iNU Ong0+DdVCB4L8C2BNw+iWsGTAb6rYHAwmMoGzwTPIOW54HmqGQwLhlFbw6eRAj5NtQyfphTDp0kY Po0QfBoh+DSlGD5N9cDsWjGfbs98WjCTjvLmbMZs+HEc8+M4+hdeccyMz2Vm3IGZcRIz4/OZGZdk ZlyKmXEqM+O0XP49Lvv3+Ozf47J/j8v+PWH273HZv8dl/56A/Xtc9u9x2b/HZf+eePbvcdm/J579 e1z27zmP/Xs6sn9PMvv3XMD+PReyf08n9u/pzP496WDqEfDmwAqYo6dRQyvdSgeHNky9MZh6J2rC XPwS6zLrX0g3XLypdZN1Exj2vda9CPtYfcGb+4GRNwIjH0TNwcWfRPxp62nkN4y8ERj5CGoFLj6K WoOFv4/wA+sDamNNt+biqGHhXZiFn80svC2z8HZg4XXIZhZu5+LfNvj32cy/zwP/7sgs3DgMOeww lMgOQ4nsMFSCHYYSmaNfxBz9LPGkeIpaGGd/ujTG1A0vrymmiWlUXXwIXl6RGXllZuRVxTfiG/Bv w8XLiwViAdIXgX+XZ9eiTLFMrAQjXy1WIzQORrXY1a2G2CA2ImWT2ITQeLuVYWejSmK72IG48Teq InaJ3Ygbl6Nq4og4irjxOiorjglNZdjxqIJt2QJx43tUxXZtF3HjflSB3Y8q2RE7gpR4sP/azPvr Me9vwLz/YjvDLo10w/5r2xXB/s+0q4D912b2X8euYddAvJZdC2Fduz7VhxJohHhjuzGdYZ8FPVCb 9UBduxn0QG27pd0S9Rs9UJuVwGWsBC5nJXAZK4HLWQO0B/sfTnHg/aMpiRl/KjP+DGb8jZ3pYPxN wfjnUXNnvvMttWHe3zaXJ5PLnkzx7MmUzJ5MnVkJdGAl0Jr9mTqyHmgCPbCQJGsAz10GDSBZA3is AeKY/XvM/lPdDe4GsPxf3U1IMbxfMuMvxYy/AzP+JGb8qcz409y97l6EhtO3Z07vMadPYk7fnjm9 kBKc3mM27zGbT2PW3p75usdMPYmZehqz8/bMyz3m5anMy9uDi0P3ytpg5JK5eBJz8fYxFt5ANkD+ LJmF/IaLt2cWHuXcHvNsj7n1ucytOzC3TmJufT5z65LMrUsxt05lbp3G7DlNDpaDwSmfkc+ATRr2 3IQZczM5XA5HumHMDZkxt5aj5WjwSMOVs+R4cOVmzJUzmCs3l6/JN8HjJ4MlZzBLvoT5cXP5vnwf pQxLzmKWfAlY8ocoOxNcOYO5cmPmys3lZ3Ieapgv5yO/4cpZzJIzmCU3ZpbcnFlyW7kALLkZs+TW zJKzmCU3Z5bcillyO2bJDeVKuRJHDT+OMuOGcpvciRTDjxszP27C/PgSeUweA0M1zLgZM+PmYMal EDecuBVz4tZeea8ytWFm3JaZcRdmxmczD27NPLgL8+C2zIMzvEZeI4SGAbdjBtzWa+m1RJ3GUSye vcRc9hKLZxexeHYRc9lFLMwuYheyi5jLLmKud7F3MVo3XmIue4nFs4tYR3YRS2YXsc7sIpbOLmLp 7CLmsouYyy5iLruIxbOLWHIuF7F4dhELs4tYPLuIpbOLmMsuYvHsIubmchFz2UUsnl3EXHYRS2YX sXR2EXPZRSyeXcTSc7mIuewiFs8uYp3ZRcxl/zA3l3+Yy/5hAfuHxbN/mMv+YZ1z+Ye57B8Wz/5h LvuHxbN/mMv+YS77h8Wzf5jL/mHnsX9YR/YPS2b/sAvYP+xC9g/rxP5hndk/LJ39w1z2D+vI/mEX sn9Y51z+YS77h6Wzf5gLDZNMTaBYKlNr1idt/Kp+VWiDan41cP2afk1q7Nfyz4DeqO3XRnodv05M t2T59fz61I7VS5af5TdGaDRMW7+p3xT1GA3Txm/vn4PwXL8jajvfvwB5LvQvpIZ+JyiZ5n5n/2Io hC5+Fxw1eqaVf41/DfpznX8dSkWdGI3CaQuFcyvaMgonzr/b74V67vHvQal7/XvpbP8+/z6k9PcH 4FMYndOEtU0GOzdmscJp5j/rP4vQ6Jx2rHOa+S/6QAnWOVmscJr7Y/wxSJngT0DrRu20ZbXTxZ/k v4lSRvM099/y30Keaf7bCN+D8on4q/z1CDdC80RY85zDmqeNv9ffi5qN5mniH/GP4NMZzRNhzXMJ a57WrHmasdrJYrXThNVOViiAwmkGhZNIrVjhtGWFczYrnHZQOCWhgkqFUpEzDQqnMWubDNYzbaBn qqKVGtAzEeiZBgizQk0QNoeGibCGiUDDdEJo1EuE1UuE1cs5UC+XxhSL0SpXQId0ZcVyVfgqpFwf vp5ahG8N34rw9vDtCO8M34mwZ7gnwt7h3giNF10ie9ElshddCfaiK8FedInsRZfIysdmbXNRJCNS gc6KdIhcRC0iN0T60qXsVOew2nGgcGpCRRgNU5M1THV1IzRMeXWLuhVM3eiW8qxYakKx3IV4T3U3 lEMf1QcpRqtUVA+qB5HSXw2ASjH6pDLrk5qsT6pDnzyFlKehUqqzSqmqhqghyG/0SU31ohqOoyOg T6pCn7yE2ow+qcz6JKpMKrIyqa3GqXEIJ6gJCI0yacDK5GI1CcqkLpTJFKS/paZSHVYmdVmZ1Gdl 0gDK5D2kvK8+oDPUdDUdOWeqmUg3+uRM9RH0SW01R83B0XlQJnVYkzRgTXKx+lp9g6Pfqu+RbpRJ fbVQLUROo0kaqGVqOdJ/gSapD02yErWtgjIpw8qkjlqj1qBdo0/qsT45U61X4HjsDliL/Uhr/D/2 vj+qjeTOs1rIQkMwwzAMwzEMwzAMISzLEkIIx7KEEIYQliEcSziWECSEJIS61Wq1Wi0hROsnMnE4 HsM6Dusjjo/lfH7E8WP9fD4v5zjE5/OyXh7hEdbH+XEcYXmE+HiEI4TlCMvct0oSgz1JZva9/e/u 1ft8ulxdXeqq/tb3R7m7iH0auwUleKfAjNjt2B3I4/0Cs8h+gRlkv8Bcsl9gBtkv8A2yH2la7D/G /iMw3jswN/b9WPAAyQ6CmeCYgwdI9hF8g+xNmkZ2E3yd7E2aRvYUzCJ7CuaSvUlzzsadfRHK8f6C WWdfPvsylOBdBrPJLoNvnE0+mwJn8V6DuWSvwSyy12A22Wsw82zG2Qw4i3cczCI7DmaQHQczzxrP GtGbJBJ7GyIxL4nEQB7Onjt7DiK0foi+3ibR12dI3NUAcde3IH/x7AjKJ9HXZ85eOnsJ8njnwiyy c+HrZOfCXLJzYTbZuTCL7FwoR9Rru6kecH5jo86j/4mQugWgBugBDIAHOE6OFDcBRwkQAJwHDAEu AkYBY4BrgBuAW4ApwDTgIWAWsABYAqwgmecRAVKvE8g884DHkH8K2AHsA44QapcBlIA4QCIgBZAe uof2rN9yzA211V4QBr6mGFBGzqH2SkBN6H7JNWOhPrbXA5oAraHy8FHmWSaguEnAbcivnZSFsAnY DucfA/bC+cMQvCgMBSAWkABIBqSF6nozSX3UrgEYQuPUzp6MeahuDqmH2gWAE+ABBMN9GAj9njc/ 3NdhwAjgcvj8ePh8URilUAbPsR335y7g/klfQn2+DbgLuA+YAcwBFgFPAKuAjfBx69QxUn8XcBA+ Pglfd3Dq/DFCGjkgBhAPSAKkfnDEz0+TAcj+2EeZt+KDZ4X7pskLP+t/KlKeBZHv86HfIXKVEqpH fvc0CgElHxxP2gi1K/NWQ3k5oCosf3BOU/vBUdMAaJa/1LZqqumdVwfMiLCCcCzweXMC8JA5Gfii OQ141JwJPGbO6Z3HV7lb1dfM+W5N24apvvdx25apqXdZfcNcRLj0JH/LXNG7jM+6DW27ptbeNfWU ubp3LZQP84FJ07upnjbXEW4EfkjyD0l+1twCvGBWAy+Z9cArZqZ3E1/lZoENkD82sb3b6nUzD/zU 7ADeMUu927jcLajkJqF3T71vDgAfmc+7naoYk7P3sF1mHiJ8kfAosLK9EjjOPAacaL4GnGK+AZxu vtV7iK9ye9qzzFPSqCre5JFgZM3TElIlmYKSArM7qEo1DUix7QXmh8DF5lkpFpe4B0LlYc4wDUsJ qmzTiJTcXmZeOOFK85KUjMvdw2HOM12W0tprzCuE14HrSb7J/BS41bwDrDHvAxvMRyfMcjL3SLvA Kd2XVYWmcSmz3cnFSZmktZxwiYdLjDAucY+rSkwTUn57kEshnB7J43L3hKrcNCkVtQ9wWVIRzrsn VeVcLuSrTLel0vZhroBw8Ul+hCsDvsxVAo9zNcATXD3wJNdE8q1SKb7WfVtVa7orVagaTPel6vbb nOaE73Ia9932+5xBqlY1m2akOlWbaY7cA0tYOMnPcE64E61pUWpsn+M8J7zIBaVGldH0RGrpmu72 EA4SHgB+2D0MPNs9ArzQfRl4qXsceKV7QmrBV/U5u9a7J/s8Ks60KqlVomlD0nc97b4NvNN9lzDO 73ffl/T4bF9Q5TJtSYquo+4ZSWGUmbb6BkKs8pl2Jcao7J4jvAgcR/JxJJ/Y/QQ4pXsVOL17Azir e0ti8FV9w8AHkO83HUu8Mbd7F7ig+wC4uBtKcHnfiGqQlUsOY5kTc6Uzpu+y6gIbI0nGGmc8ZmOQ 5JOA652pwE3ODOBWZzawxpkHbHAWShK+qm/cyDpL+iZUl1RrUsAoOMulgOoKGy+dx+zNVF1lk6Qh o9NZBexx1kpDuKRvMlQe5utsqnRRdZPNkEaNQWfDCQ84m2HuQHnf7TDfYbOlMeOws42w9iQ/4jQC X3ZywONOEXjC6QKedPqAbzv7++4a7zoH3RrVPTZPuma877zQd5+0diNcMuO8BDyHGZf0zagesIXS LeOi8wrhq5E8Lu+bUz1iS6Qp4xPndWkK5/sWjavOm31PVPNsuTRt3ICRB3beOclvOe8B7zofAB84 HwEfO+elaVrufAwc41yWpvG1fauqx2yV9FC1zNZKs3S8c+05TnJuSrOqNbZBWlBtss3SEp3q3Ca8 d5LPcB5KS6pttk1aobN70Ann9SikFdUeq5XW259wA4SHgVdJfoMbAd7iLgPvcuPAB9wE8DE3Ka3j q9z3NXLutntGdcgapadqxHLSjiaGuwscTziJcCp3X9rBZ91zagUrSvtqBTeDGec1GdycO04dy7qk I002t0j4yXP5PG4VuJDbAC7htoDLuV3pCF/lXlQnsD63TJ3M9ruVmiruALiWOwZusMiBmy0xbqU6 jR10x2naCGst8e4n6kz2gjtRY7QkEU4lnOFOVGdasiHPWfKARUshsMtSgsuh/qrGZymHkn5LlXtD ncNecqdoBi21wBcsDe4UdT57RVrA7N7SXLI0u3fVRexVqH/F0gYtFFm0mKFkNVQe5lL2ujtdXcHe hHu7ajECXyd808LByODyA80diwjWk+TV1ewdd5bmnsVF2HfCDyz9wI8sg8DzlgvAjy2XgJctV4DX LFfdx5pNy3WPHNq5585Vp1luAlewD4Dr2Edwn9uWO8B7mEnJqrqRnXcXaA4t955lXO6BsNXywJ3V obA88sSrW9jH7uKOWMu8uxjnPUnqFguUqNXsMulXiNci+Y4EyyZwsmUbOM2yB5xpOQTO4RFwPq+A vuNrD9R6ds1dpmbYTXdlRxEf+xyX8gnuSjXPbrtr1A52z13fUcENY+aTT7iaT3PXqyX20N3UUcdn AjcSbuFzgNV8vicV+ySejA49XwT+CfgGnuwOhi/t3ezg+QpgB18dsuCePGwHPYUdEl8npXUE+EYp DVsiT0nHeb4FWyVeDQy2xlPeMcTrpaKOizwD9gXmi6eqY5TnpXUst57ajjHeIR11XOMl4Bt8ICRj ngb8fD3NHbf48+4sdTU/BAzj4GnrmOIv4jHhR4FDPZ3mx4Af8tfc9cTibNCFPbFgfbDm36JLehIk hi7vSQau6kkL6+ddrOX6DujankxpTHWnJwcY65ljuqEnH+ucniJg0CRBOd3cUwrao62nQloikr/a Mcvf8Gg7FvhbHmPHEj/l4TpW+GmP2LHOP+xd7njKz/audezwCx4X1FmCOvv8isfXccSve/q1Mv6p Z1Cr5Hc8F7Rx/H7vtqqWP5IqtIlWmeeSNsWq9FxRNVvjpDptujXRc1WVbU3xXFflWdOlNG2WNcs9 o8215npuagusBZ47IX9DW2wt9tzTllnLeuexR+F5oK20VnoeaWusNfgpWOsjll1bb20i3ArcBPc2 r221ajyPtRqrwbOsNVhZz5qWtQqeTa1gdXq2tU6rx7MX8mnbZdYgeHEhP4p4KVqPdQB8V+I3aoPW YeAB6wh4cVg2Dts1VmDtsHXci7Qj1gmvQnvZOumN1Y7jmiq59XbvnnbCetebEPLc1KPW+73z2knr DMxx4qNqb1vnejfbU6yLvYfau9Yn8OsG6yqMw33rBvCMdUvK1M5Zd8EHm7AewP0sWo+Bnwhyz6B6 X4iB9leFeG+ydkNI8szjEfCmabeE1JBsezO1u0IGtHMgZEtF2mMhz5ujkwuF3vyQh6mLEUq8Rbp4 odxbiueFt0KXJFSBlw6+urc6xLpUoTbkgXvrTnEj4RbyK2rCel2G0NC7qcsWmnu3dXlCW+8e9qi9 jK5Q0IbzPGEHnl9eKTyS4A97A4TP47vyDulKBKN3KJQnfFFXLnBSgq5KEMEfBq/YO6qrFVwhH9g7 doqvgacqSJm6BsEH3IwZe63eGyHWtQn9IU/Ve0unFQalfJ1RuAAM5VDCCZdCXqun/AP2TuFZ750m /DDEOlG4Ar4oeKTeWZ1LuAqeJ/il3gWdT7gu1en6hZvAnHAHfM454R74lvi5LIVYNyg88K5oMoRH MLuxZo7TXRDmwXpmCI8hf0lY9q6r04Q1bBGETe9T3RVh272ruyrseXd014VD777upg15j3R3bAqf LKzbifZWt9hifUrdPVsCaGOHLdkXF9KEuge2NF+i7pEt05eim7dU+dJ1j205vqyQD6Ax2vLBFhAr o1vGejtko3VrtiJfrm7TVuor0G1ja6vbs1WA1QOt5SvWzNuqfcW6Q27RV6a5YKtzp+iRrdGXErbL V20t7ji9wqbGvoRNL63rY20Mtuk2XjrSJ9gc7kR9sk2C3122BbD9soEO1KfZhqA803bRndiRbxuN WAp9jm3MV6nPt12DewNfwpugL7Ld8Mzj3vlq9KW2WyFN617UV9imoJ1q2zRYAbC5vnp9HXvT14Tt lK9V32h76NPoW2yzPoNebVvwsXjcfAJpx6nX25Z8Hj1jW4EYB3S4LxjydjB72kIc8WpY0TeAOVTi GyY8gu/Bd5nwuJ63rbtleoftqVupl7A3gj0TT5s+YNsJ5cHeAcNVYAt8E1jr+ib05237Ib/CNxlm 6IWnQT9kOwJ7QfKkXxP6i6LMna4fFZXgUYBf4butHxPjQl4E3NUJ+0Y0V8VEd67+mpgCfENMD1l8 aAfYd1d/S8wKWXnfff2UmOsu0E+LBcBQDiUPxeKQlffNnOI5bKd8i4RHCD/Rz4plYLvBgvtW9Qti JVhqsOO+Df2SWOOu0a+I9cDrYhNYsTqx1d1ExnyL8G54ZJ6KGnexfkc0uCv1+yLrrtcfiYK03ikT nb4DWttTHYyhjT11gTqa62kEFntapCHa1aOW9LSvRy8p6P4eJhgPdXg4O9jjCCbRF3okOHupJxBM pa/0nA9m0Fd7hiAautJzUTpPX+8ZDWarLvSMSRJ9s+daMI++03MjWEjf67kVLAGLOSWN0Q96pv39 9KOeh8Fyer5nNlgVig5Uj3oWpCn6cc9SsJZedt4MNtBrPSvBZnqzZx3iuM2epyd++HbPTrCN3uvZ h/xhz5H/JoNcsqCWUbiUQSMT64oLckyCKzEoMsmulKCLSXOlB32hCNRY48qCmCsU6ZCYgsl05Qb7 Q1EekwMlPJPvKoCYC2x9cNA47ioODtLZrrLgBabIVRm8xJS6aoJGYy6uqRp01UsOpsLVFLwSirO6 pl2tkXg2FGMy1SSurDFu4IjPpTn59QmXAZjESkydi4WIKRTjHEOMOc009ux4S41lLgHab3E5g1cZ tcsDcRaMQPA6o3cFw77KMMO4BqQxhncNS0uMwzUSvMlIrsvBO6F4kAm4xoP3mPOuieAD7OcEHzFD rkmIqSGyDs4TfsxcdN0GqwERNNgL4OAyZjeJqYNr+FeCmyFmRl13oUdjEHPxzDXXfcmB49/gNnPD NRPO7xE+xP7SORQeSYhezynCDHd1Lpa55Zo7FxvKE05gplyL0kVm2vUEoleIYc8lMw9dq6GI9Vza Kc40zrg2YMRmXVvAC5hxjOlpDjGz5NoNxZXncpgV14F0i1l3HQNDOZQ87ZWHYsxz+ae4CHtx50oJ V4SY2emNgcgR4sdz1cx+bzzEiRBFnqtjjnqTpAWTrDcVWNmbIS2Z4nqzg234uZxrJNyiGuzNC26b EnsLpSlTSm+JNGtK7y2Hmlm9VVJLp1L0+I5J7EDsEdFdELN0xolBv7wzURzwx6gV4rA3oTNFHMG2 Q7zsj+9Mxwz5cX9SZ5Y44U8FnjzhXPG2P6OzQLzrz+4shquUoZius0y878/rrBRn/IWdNeKcv6Sz Xlz0l3emYP1J+KCzSXzi3cHa0l9FuFbjE1fdiZ2t4oa/oVMjbvmb1UXirnu10yAe+Ns6WfHYryVs xHrSz4VjK2C/2CnY5X5XKM7qdNpj/L5Ojz3e398ZtCf5BzsH7Kn+C53D9gzgEXu2/xLWmf4rhK92 Xrbn+a8DF7plneP2Ev/Nzgl7uf9myKZ0Ttqr/Hc6b9tr/fc679ob/A8679ub/Y86Z+xt3lKiRZWd c3atpO9ctBv9851P7Jz/ceeqXfQvqxm7y13ZuWH3ucs6t+z90q2QhcLsX1NLYA0hbx/0OUOemy7e fsG/2blrv+TfViP7Ff9e54H9qv+w89h+3XfcmWu/6c8wyO13/HmGGPu9ADLE2x8EFIYk+6NArCHV Pi8NGTLEkUDC6dYM2fbHgWRDnn05kGYotK8FMg0l9s1AjqHcvh3IN1TZ9wJFhlr7YaDU0OBAgQpD s0MRqDa0OWIDdQatIwHY6EgOJISZc6RJ6wbRkRloNLgcOX6fwefID7QY+h1FAbVh0FEa0BsuOCoC jOGSozrAG6446gIO/HwDkuGq2hEIGK47GgPnDakO0PmGmw51YCj07Ax3HPrARcM9B+MZNDxw8IFR wyOHA3jeIQXGDI/h0muGZcd5X6K62gERlmHNcRF40zEauGHYdowFbhn2HNeAD+0lgaku5LjhXelS OG5Jiq5Yx1RguivBMR142JXseCgxXWmO2cBsV6ZjIbDQleNYCix15bPz3tKuIseKv6Sr1LEeWIGa T6FmhWMnsB76la5qx37gaVed48gz39XYLQvsqBWGbGm/q6VbGdhXl3bHudO71N2JgaMufXdKn6yL 6U7vU3bxBlefUt3YDda5y9Gd2we+XHeBu6lL6i7uS+wKdJf1pXSd767sS+8a6q7py+os6K737mDu yw1F/V0Xu5v6CrpGu1v7irH30leGvZS+SryK0lcTmnFkBWMgvFLx7Oy4F14rICsDffVdY90afza2 731NOAbva8XS2KcJrQ4R/XDQdU0cgfaJJ9Z1o9vgXuzM6mbdi+HVG7Ku0nWL5foMnbvdQh8bivq7 prqdfQJ+1p4GJEOvUjvU/0aI+hW1j2TUIfVrJKfel1FIITsjU6AXZJ+QxaJPyOJlL6GzsldkSehF WYrsNfSSLEP2FnpZli37FHpF9h3Zd9CrUdVRX0bJZ6rOfAmlnOHPWFHqmR+d+RFKi4OE3ohLj3sX pcfVx7WiujhVXB/6Wtx7cT9EvriZuC30l3HbcfvoMdzNv0Jy8tcP4tCL6AX0EmpEn0BNSIO+grTo m6gV/Rs0iAJoCP0EBdHfoZ+iR+jvqRj036hY6ix6n3qReoWiKPyNkxK/N0m9SrVQnVQq1UUFqRyq n7pAVVMj1Heor1L/kfox9bWo70d9nxLlgtxG2eUeuY/qlvfLv0m55O/J36M88m/L/5zyyr8r/wsq IL8hn6S+Ib8t/ytqQP5D+Q+pIfl/lf819R75HvOCfEH+E+rb8hX5KvXn8g35z6lR+S/kv6CuyH8l /wfq3+G36KjxMy+feZn6D2d+cuaYuqY4o8ikFhWfVHyS2lN8SpFH/UrxOUUJ9Wv8hQf1vuKLikqZ XFGleFemUHxF0SqLU7QrtLJUhV7By9IVNoUk+33FNxSDss8phhSjsj9SfFdxVVaDv5yQNShuKP5W 9ieKOcWczKKYVyzJeMWyYlnWo1hVrMpcip8pnsp68ftYMq/il4o9WVCxrziW9Uej6LOy96ITol+R fTf61ei3ZH8RnRX9Wdlk9BeiGdl0tDV6WLYV/a3ob0XFRn87ejTqbPT3om9EvYz/rmrUq9H/KfpO VGr0VPSPotLw+0BRWdF/F70UVRj9JHojqjj659H/EPWOMkt5M6pR+csX3oz6adyv434tx9/LMagf OBal4a+NKybDUAJyURajqT5gDJXVX35cmc+wjMA4q1cZDxOsZOqHmNvMXeZ+5RQzw8wxi8wTZpXZ qI2pzWAGakVm+J2adwzMCHOZGWcmmMnajHcqQarkIOM7RMZ/hSjqfep9JAOJjkdRcO518iYqkn1P 9j1Eyb4v+z6cm5T9JYqS/UD2A3SGvImqkP1Y9mOkJF+CvSD7iWwRxZB3UGPJ26dnZT+V/RTFkfdO X5T9QvYLmB34zdKEKCqKOvmrwWeiFCiJfDmWHJUUlYT+RVRyVDJKIW+KvhaVHZWNXidfhaVFlUaV onTyDdibUeVRX0AZ5KuYTPLOxttw/7FUAhk5zIh+gFz0A/oRPU8/ppfpNXqT3qb36EMG0XuMgoll EphkgjQmk8mht5l8pogpZSqYaqaOaWRaGDWjZxiGZxyMxASY88wQc5EZZcYIrjE3mFvMFDPNPGRm mQVm6XQyNTErzDrzlNk5SfvMkUlmUp5KcaZEU4opHUqznkmtpiyom2sqMBUzR5FkKjNVmmqAcao3 aZgdkwHqsiaNSTA5TR5T0DQAbWaZhk0jpsumceg/9QIT1hr4m/WXyJgkQ4pCqZDkKAt9Ep1BuZCi 0R9AUqISSC+gUkgxqAzSJ1Aleoe8Xf7HoHXwd5cvoj9FLSgetUFKAL2jRS8jA6REZEUC+eLSSb61 dJM3yv0oBfTRe+g19G1Ir6N/CykN/Xt0Fb2BvgfpTXQDUgb6K0hvof8MKRP9ANLb6L+gB3B/jyBl k7+G/Sm0hP47ykH/A1Iu+ntIv49+BikP7aJfwr0foP+DPo2OIX2GklHRqJCKAd1XQt4f/0PQffGo lLw/XkalUW+iz1NvUW+hL5LvPStBG9aTLzpbUBX1dUqNvkRpKA36Y/IueS35uvNdiqEYVEeZKTP6 CmWjRFRP9VI+1AC6M4iaQXt+A/0p9U1qAH2NGqKG0NfJ151toEnvIBU1RU2hDmqa+hHSUg+pv0Z6 6m+ov0EG6m+pWdRF5JcGLZCNGGWOMgeZydt5nPLTygJkIW/kWZUlyhIkKMuUZchGviQSyft3dqVa 2Y66lR3KDtQDz3YD7RPZL8I7SxhvAaYA04CHgNkwFsJYAqygf22cMk4bHxpnjQvGJeOKcd341Lhj 3Ac+omW0ElIcnUin0Ol0Fp1LF9DFdBldSdfQ9XQT3UpraAPN0gLtpD10kB6gh+kR+jI9DmmCnqRv 03fp+/QMPUcv0k/oVXqD3qJ36QP6mOln5EwME88kMalMBpPN5DGFTAlTDqmKqWUamGZIbYyWMTIc IzIuxgdpkLnAXMJ/QfSM5kwXGMGvx7WR/RXe+WeT73chvUikPJ5I+UtEyl8mUp5IpPwVIuVJRMqT iZSnECl/jUh5KpHyNCLlbxApTydSnkGk/C0i5ZlEyt8mUp5FpPyTRMo/hWYh5RBZ/z0i67lE1vOI rP8BkfV8IuufJrL+GSLrnwVZl6EiIt+fI/L9L6nXqTSQeyzZpUSy/4hIdhn5PuLzRJrLiTR/gUhz BZHmL4I098IccFNumAP4K4kvEWmuJtJcQ/0Z9WcwH7BM15LvI94l0lxHpLmemgU5bqDmqDn0J8qv Kr+KGpUtyhb0VWWXsgt/rx3viT8PzykWxv4TiLK0gdwVAIoBZYDKcFkNoB7QBGjFZfKXjIWWInrh d4PUWeIXjSWWUmO5pYJeeRa4zFhlqabXAU/5JxjGWksdvfO7gesYGyyNxmZLC73/AfC/jW0WNX1k UTMyftWotegZ5e8GqRPHbxiNFoZJtDBGzsITiBYHkwJI51mSz+K3mFx+1+iySEafJcAUfADy72L+ wNhvOc+UfQQq+WOmxio3DlqGCC5YLhovWUaZ+hBwHveNafoApK9XLGNMq2UMHwmuWq4xmo8Grme8 brlhvGm5xRiehfGOZSrS7mkY71mmGfYDGB9YHn4ccG3iJeMjy6xx3rLwG/HYsoTBacUrGMZly8rH wppl3bhpefohbFt2MDijddC4Z9n/OOA48arx0HKEQSNeRqDglRicKF7HRzNrm6DVvIaO5ePoBD7x eXAu8SadzKd8FDifeIe0kcanE2TyWXQOn/sM8vmCD6GIL34GpXzZx0YFX0lX8zUfQh1fTzfyTR9C C9/6DHC/PwYYwRpD63kDzfDsbwScY5zWeMZjTSL1eF74WHDwTlriPR8Cbi8IGLCm0gE++HHADFsz 6PP8wAmG+OET4PMjgMvWbJIft+YxE9ZC+iI/Qu73OTCT1hKSH+UvfxSY29Zy5q616pk2xvjxZ3CN n/gQ8LX3rbX0DX6SmbE2kOOctfk33c9vxS3+Nj3F3/0Qpvn79EN+5kOY5edOg1m0tkV0+2ldHNGV JzruiVV7ooNWrcbTeuRETk4/18hziYzRhpU7Gdstq3j6nogu6QedAnOfGwzpAO5CaP6SeXWJTyF2 A+SduwK4Kt6LyDN3HY7wO/g8s2t1MQdWH3Ns7TfJrYPYvphirBdwOe6bKd56yZRkvYL1qynVehXr SVOG9bop23oT2wBTnvUO1u2kzyDvpkLrvYh+NpVYH5jKrY9wv01V1nk8FqZa62OsO3GbBA3WZVOz dc3UZt00aa3bJqN1z8RZD02igPD4EhuExxLG0OQCOxm2ZyYf2J/wOJv6oZ1BQYHbIOcuCLGmS0IC tjsntvbUMzppEyNsUyK2AN8Tto2mK0IyuberQlrkOZP6WPfDsyd2GWwe6dt1IROXmW6CDS8JAdtr PL7PoDZkl7G9IvYYfidii/GRAOSH9O05G0t+C2C6Y5EwsI2N2NUITPcsQxgnNhLbzLBtPG0rn7GR YTsZgekB2EF4xsT2gT00PbJMYRC5xXbuXggnOgtgmhdyyPGxkG9aFopIOegP05pQatoUKkzbQrVp T6gj5XgOY1uC5y3MIzyfTIdCI4uEFqyLWIWgJvMiMg/CepHIFrSD9RwbC7opPEfI8wK9ha+P6MAP za3n5tWJfoncP7SB9SabIOjxM2eTBebkelwf5hubJvBspuDA983mCBKbLwSIDsf9gT6wRcJ5tlQY Itd9lP4J3xdbEdbjkTkePFUnfM+kr8/p45P+YD0cwW/7rd+iT9nq8LGOn8R9OsHzevK0rsT6MaIj T+tEqEvawXXwORgDttFay90UH3B3xEcY2LfBz5v4NffEeVIGOotdsMVxD8THEf+FeyQuswFhmugx 8Du4eXGN+BSg09gbwlNWEqYiPgH3WNwkOg3bf+w3YF23LG5jG82tiXvcpnjITgtH3LYdcXt2BXdo j7Uge4JFYU+2xNrTiE8W1pfkWuybhf0m4vNEfBTcVrgNfM6SYM/E+hLf14lvF/HD9j7QwQQRHybs e+C2sD9mSbbnYH/HkmbPj1xP6kN/yL9hvMg8gb5ZMu1FpAz7jRGE/cRn8LwvGPb9nkF4XJ/3606A fbEInvfrIj7ab/DNLDkhfKRvhn2v0/4X9rkiftcpHwvfK7kW1wmPyYfmFsw/tkW4+KF5pRZGIz4W qxfGWEa4hnVRpB7LCzewXLMO4RaRp4gewHXwnAP5I8fzwkN2SJgl+YvCAjsqLGGcnm/smLCCdQR7 TVgn8nlL2PmQHwNgp4R9ApBHDDIPsd56aJOR46xNGZmDeE6wS7ZEdsWWcjL/sA5at6UTXfPUlsXu 2HLZfVsBtj0R4P7iGIvMP+gze2QrNstsZaRt0B9mpa2S9DNc3xxnqzEn2urNKbYmc7qtFesic5ZN Y861GcwFNtZcbBOw/SM2EOsn8AnMZTanudLmwfrYXGMLkpgFbKG53jZgbrINm1ttI3i8zBrbZbPB No7jBLNgm8TjZHbabuP6Zo/trjlou28esM1gHxDr/4huNg/b5swjtkUCaA/bGSzb5su2J3jczeO2 VfOEbQPLmXnStkV0GDxH823bLjl313ZA2rhvO8a63Dwjys1zYox5UYw3PxGTzKtiqnlDzDBvidnm XTEPj6/5QCwkegz3/1gswUdOLpZjeeBixCouXqzlksQGLlVsPpEf8MGx/8FliG1ctqjl8kQjKQ/r XK5Q5LgSUSTPD+YJVy66uCrRx9WK/SeyGokDIjYK8lyDOIjrcM3iBVyGZIiKC8YNIfT//wfl/6H/ QdlCux/8P4B2HzG6FF26LkuXqyvQFevKGuW6Sl2Nrh64Sdeq3Q8lXTqGTqMzaI9CScfqBJ1T59EF dQO6Yd2I7rJuXDehm2wc1N3W3W28p7uvm9HN6eLCaZhgUfdElxhOq7oN3ZZuV3egO9bL9TH6eH2S PlWfoc/W5+kL9SX6cn2VThZJUKNW36Bv1rfplKGk1+qNeg7qieQO8R3hmvgc/j34BbzOf3YCZPvL /yzroO/C3PgKpJfIOmgCWQd9mayDvkLWQZOQARnRq4iBlEJWQ18jq6Gvk9XQN8hqaDpZDX2TrIa+ RVZDM8lq6NtkNfSTZDU0m6yGfoqshuaQ1dDfI6uhuTDnZlEemoP0abIaWkBWQz9DVkM/S1ZDi9DP 0M/R59D/glRC1kT/kKyJ/hFZE/08WRMtJ2uiXyBrol+k0qg0VEnWRN8ha6JVZE30S2RNtJqsif5f 9s4Fuuri2v/n/B4nEeGINEWISGOqiDwUA6WIXLAUeeQ8QApKKZWY8z4ipUgRKY1A0UaKCF6lFBUp pRhToEiRAgIil1cpRaAIaCnlIkUKNFKhkXIh3L0/8wvESFftuuu/1n+te9es/T2bPXv2b2bPnj0z vxyP/XgnWsw70RDvRMP+7/kf90X9k/yTfPfyTnQg70S/xjvRwbwNvU9W+q989/tX+Vf5hvJO9Bu8 E/0m70SHO1OdH/pK+KXBUmels8oXl3W92Zd0jjl/9qVl/VaLL/2+cb6yy7EakxHH9sYOxA7HjsWq pJyJnRPHB+IN403izeItKcn4iPjo+Lh4mZQp8anxGfFZ8Rfj8+MV8SWUm+Jt4h3inePdKD3BvvGo 4KD40HiJFo0bq63ETXsvbprwfI0YS+boFokejRVH/F8k0aOxEiBWciRS7pEY0nfmV0l0DJUY0vi4 mvhoyHvyRjKuhySSNBoaSyzMlHjSOGgiUbBQ4kkjIM/3mpTPEwFNiYDrZP43Stzq+/DmMufvSoTp rF/PrLfgHfgNMvPHfS2Z4wJ/Y5njG5ndQub1i8zoTf7h/hLfzczoLTKjo3yt/WNlRtvwlrutf5rM YjtmsT2zeBvvtG/3/8q/0tfB58/tnNutzny0ca6Ntalf4uPjE2MdYp1rS7xVrJtXetYv8SdjfWNR U+LTYoNig+LPiqReic+Oz40NlVIiJaklvoDPEbHRtSVeGRv36RJfioVxsTKvTDElviI2NTY1vkZw xqdLfENsVuzFS2W+6nqlwitL6pfMkszy2PLY6tqSPBVb75XN9UtmdWx77bMy62O7pcwXSb2S6BSr ju2Xos87qCXdOh6UzyO0oCSqPm09tjndGwubaz0bO25KZnPsVOxUpkKw+tMls13Gd/5SicatSyXX lCt4amt8RzwYz7tU9sTzKe9d9kRtiR+KF8Rb1RZm/Gi8Xb1yUuijeBGli5Sznrwm4Qh2vzSiaKws 0SDe69Ml0ThenGgaHxC/T0uiRXyYKYnC+EiRlMZLE63jpXXsXCqJ22LH4+lLZWR8TG0x3o8dlBmR +E50JXb7Ju5O9NYYS4TVE4mBGh+JIcI9wGjbJeKJLD3KMlZjSSNlN7O0PbM/c5BoOIL3j+Ppk4lR snY6iP86x7olxsYqEhPEy8HEZOlfeWK6xHJJ4jmJ93GJOXErMU9ieUZpeWJhvIs8d7rEyRTRXZRY llgZO59Yl9iY2CY91vifkdjJKEtkxrbGpiT2ikY0cSBxWGzpqmVEaJq1orM7JTYocUz6XyVjPiPy qaLXWVbd1MQ54TokHkj6Yt2SgWTDZJNks2TL5E2s5UGmJNskO+h6TXZOdpPSM9lXVusIs2KT0eQg niZPSg6NTUmW6JpMimXRHJEcnRyXLEtOic1KTvXWn67AiuSM5AiJtSDxli+1s+LF8S7JF+P5yfnJ iuSS+LDkcplfma3E9OTq5PrkZvFcu3gv6dOs+I7k9uRu0d4v5WC8KLmaCNRRMleqJ0UiRr2UPCJ0 PN5L1vCMZLXIxyTPp6zkwVRuSp6dykvlpwpSrVLtxNfZVJHGe6pLqnuqV6o4NUBjXDzLnKfuS7SW aOuSGpYckSqVkk6NjHfXInVjUkWp8TKC4vh9UjMxPiz1pMapYGlqWurZ1OzU3ORNqQWx46nKeDq1 VOJxpI4ttSK1Rp5ZKhE6RseXORVbnqlOxyUzrM+cl/k5KOPpJfEyI2tlcyULVGSDkik2J2elTmbz Ys1iq0u3pQZk87MFuq4lZsRb2VbZdtmiZEW2S7a7RKhmjmrJZuqdiszqzGqjEZuR3pntJbY03xHB aJosIxEstnZni2OzsgNiS7L3xTbHLdFbLf05lR0m3PLUsGxpbH2ia6oo3TWbzo7MjiELepksOz5D Zk11yezO7M5OzD4pee6IyXXZadlneZo8KTs7djw7V7OZ4Kns3OyCbGV2abppVjJ6apjJXOSu3Mzx 7JrstPiw7AbtSWqDzJPGzrDU1tQOjR9TEtOl35tTezQnpd6TOT4UHyCzc1Tiqp3kg3apk+LrBamP 4t1TZ1M1sWjaSUveiR1JN043Ld1Wui3dQmZwgcTNqdi4dGG6dfq2dKd01/Td8dLkQfV7bHm8S7p3 Ohw7lR6YHpI8kn5AVs9USTDZ+Eh5/kHZH4+m75YVHJScVSo1o9Jj0xPi+enJ6fL09PRzsbJ4bnpO el56YWx3elF6WXplPJheJ1aD6Y3pbbH9Yvlgeqf0KSh92Zs+kD6cPpauSp+RPm4X27mxU6J5LuPL BGJTMw0l2zSRtRSVuGkmbdpJrHTJtJT4PZm5KbYk3Tp1MnUyMT11KHYwuTvTJtMhc5P4wcp0znTL 9Exuz/TNRDODMkMzJZlkpm+8WD5HJKszozPjRLssPT21IzMlMzU+JjMjMyvzYmZ+enqmIhHnNNX+ /26Y/4tumGnfKL7V0FT/bzIlFT7/g5Yvr2SBlEopS6WskLKmZM1QKSUbSjYM3z98f8lWKTtKdiDb I+U9KSo7JOWoFGk3pGpIVclJKR+V6B3WCkaD/eUZjbnR+LjRWNxlbM68DncZl1tMgDNvDreYXG4x V3FzuZqbS0POvEHOvNdw5m3MneVabiuf8/kbxxuPZEx877Ckk89fEpbPrvI50Lm278KS3p+Fiovl c5HQsn9AKw0VDzPUd91npI1C265AOw0Vj5HPvZ+NiifK5wGPDnt0zFC/g+azeLbQXOGrhM58moor 5fPcP6fiFUJrxK7Po4BQw08SY6tH/ZrUo2b/ArUUuukK1OYKdpU61KPOn42i4vd+3YR6/gPqayi6 11C/6GekQUJDr0AlhqIyb/2Sn42iMrf9Rng02qNxhqLHzGfkkHzuFioTmvJpikoM9Jv6zyl6xrMx w6NZQi/Wo/lXoIp6tORfoOVCq69A64U2X4G216Pdn42Kj8rn/hLWxxVJ6opPCn3k6R35jHRc6NQV aL9ns0Y+qz8bhRz5PH+Ziq3LdEmnsffZVKiF1OVeflZdChV6zw/+cwq1Frrtk+2L8+pR/hVI23aS zwL57Op93n3l/vwjKm4l1O4KVCTU5QrU/ZMU6l0nf9fNt7X50stjoXDJpfwSGljyyfxRGyd159Xz 9yUfDanj2wc+2adLOaVuDqhdw97a0j2jNub7N6sX09WmPhQXygqNMjlC95fQBCPXMYUmC5Wb/Fqi 8yV5MvSc0ByzB4Tmefn9nIn3kPikNj+HZE8LLTPjDa30/CA2NV+qTUjtynyGJC+GxHch6UNI7R7z /Ov5U9uyT9buYYfr+FnshH3GhtaFZb8IN/T6VX+e6s3RpT2ldp7Kzd4YbmL6Fm5Wp/05Mxb+vczb ++Tf4ZaebFEdWnkFqr8v77wC7a2zv9bZYy9RVR2qt79e2i//J/tky5JP7oVtSi7vgXX2u0s5Syjc 0/uUfSsc9daY5I+w7Elh2YPCsv+Ek55c1rDuH6zb3mY9hWWfCY82uSg8zlsX3jqozYsaW2pH8xz5 qXaNlJu8pe0v5cD6a6veuqrNL5fWVrnX/ynenE+93B59WW9h2ZvCs0y/w7InhXUPOujlJB2D7EHh JV67f5aD6ufxK+nU9vkK+fhSXe5l+oe57p/l04JP0qfyZN1cWVQnR9bJh+gWeDpdjA80R/eX+Onf xpCebXS+9UzTv4Mnk1iJ9BJe85h3fukvZ6NwtZfHZE77a2xNMfksor5Xf3lngv59vVym+/8sL89p /Mke3V/s9Rd7Eelvf4mb/mKvv8RZf7UpMda/zMuftflyiXc2qz03jb6cR7Hl2aCPU0y+pF/183C9 HHzpDFObh3WcakvrJKb6z6jTfqo3ns7GX5y5ZGz9Z3mybnWo7xWo/lmw5Ark+bX+ue4SldWh+ue6 2jPa/+Rstrzkk+ev9SWXz111z1glXtvVdXxSf23J+gtvL/nUugrvLrl0xgrruj5octGlfHXExHX4 uBdPtXLVqfbiTz8lr0S8dReRNRYJGqq73iJ5JkdE8k18Rlpd4RwjFGnnUZEh8qDa7+J9dr+8BnVN RGSviwyos/5EL3KfWW8R2aMjpUJps/fUEvmo0vhJxxwZKTTGsy3jiIz3xunpR+ROF3lSaJrQsyXk oshsIbnDRRYIVZr9T4k8KWeCyFKhFSYfR9aYONW9MLJBaKvQDs9fe4TeM/eEyFHjp8hJox+RvSNy VqjGnAE1/9fm5qjsAdEGhtQe+4zEdrSx8XtUzqDRFibOooXGjzqP0dZe3W2ejU4ml0fljBiV82FU c4+cx6JyDovKuSoq56lo3Pg3mvXymIw/Osr7HGviISpnoaicgaKyR0SnX44fzd16HojKWSgqZ6Ho PE/u5dyonAeii4x9XSdR8VFUzgDRdXVitfYeULtHCR/daHSi24xMv43RaEOjTf/3bYz/Te/KnDbO Rv2LqrXN9wufL6dAqJVQO6EioS5C3et89hIqFhogdJ/QMKFSobTQSKExQuOFJgo9KTRN6Fmh2UJz hRYIVXq0VGiF0BqhDUJbhXYI7RF6T+iQ0FHvmSf/wedHQmc9Uv0any/XMfLcBkKNvb6d9D5lDLlN hVoIFRr5pc/WQreZvuZ2ujzm3K5Cdwv1FgobO7kDzfNyhwg9IBT35FmhUUJjjd3cCUKThcqFpgs9 JzRHaJ7QQqFF3ueyOp+1+iuF1nmf87x26+rUbxTaJrRTaK/QAaHDlz/VP7nHhKr+hc9aX5wxfvxX iTmoSwMMqX3m65Cne6wenTP/2/naz9r2tXavCgg19OZb5Fc1ufx5VTOhlr5fhPqGoqFBoaGhklAS GhEaHRoXKgtNCU0NzQjNCr0Ymh+qCC0JLQ+tDq0PbQ5tD+2Wsj90MHQkdDx0KlQdOh+2wrnhYDgv nA8VhFvx73ZSisJdhLqHe4WLwwPC94VmhIeFKsKl4XR4JDQmPD48MfxkeFr42fDs8NzwgnBleKn8 e0V4TXhDeGt4R3hP+L3wofDR8MnwR+Gz4ZqIE2kQaRxpGmkRKYy0jtwW6RTpGrk70jsS1nqRD4wM iTwQiUeykVGRsZEJkclQeWR65Lkr0pzIvMjC0IjIIq8sk3IlfqWUdZGNkW3C7/TK3sgB6LCUY1Kq Imci56K+aABqGG0ie0LzK/7igs/7xYVcfnGhAb+40JBfXAjyiwuN+cWFJvziQh6/uNCUX1y4jt9a aB4sCN7huz7YMdjL1z4YC6Z9PYIjgt/23RMcE3zMFwqWBR/33RucEnzC97XgzOAbvsHBtcF1vonB rcETvsn8+sLC/4975vc38Y/i+yqr9f8mX1jkkWSWwu4e9fKouA6vJKum8D6PV71hHl/qUdojybqF knULJesWStYtfNLTnebpq+zZOv+e7X3O9WhBnWdWev9e6mtbvE3KzuK9xQeKD0s5Bh4urpJypvhc yBcKhBqaUrwt1CTULNQydJNI24i8ZahDqHPx4VC3UE9Zk6zK4jOyLqOhEpmra/ilDR+/sWHxGxt2 sChY5HOC9wR7+9xgv2DEl8PvbTQMDg+Wyjxkgg/5bgiODj7iKwiOD37PVxicHPy+r1VwTXCNr3Xw zeCbvluDJ4MnfW3+H1v313zD+argUIkOf83V8A3g74C/A76j01ewkzsGeSnyH8FPEyxyX4PvC2/a 3gE/gLa3C96GvJMzEjvatgj7w5yOiu439LtP7njh85yeiu53BJeh87I+9wL8hbX0YTLyh+A7wneE 72R66+F48NvoiM0L/+m0FTzkjagttd+gV4zUuZNxZeh5Wnl7P3wutT5avYrkYdqGkFwD34O2j2Lt GnrSA3TR6YxOUrADfAf4Iqcr8ix8ZywgBztSW0Ttl527FN2H6ElXNJXvaH+EjvHDNKytwZrOxe1O BXKDXcCB6MSxuQKb4g3rXn2i1d4tEXzCldVtjYXvAe53RwuWqY7fAp9Hn35aPkU7iebzbkxwITav VYl/n/L+09TORP8e9J+Bz8PaafAQ+uec34jccjYJDnT26FOU93+IJOnsE+ymOr5qRX8x+HdwraJt o9kPO4NV3/8+FirgF1PbB/2L6LeBPwpuAF9H/4TzLdEMu/8h/FmNWyvgvil8jcr9pe42wcOORIKV rzq+E+4kwb8p+o96EkG7CDv5YAvaJsCZ4HXORWofFP5tResA/BpwJ/i8M0znKHACXAFWguVglWJO M3lWJzODaD4R0N9QKYXvATbysBIsB7XtdWhupHYpkv1IypDMM/OuvOAKsBIsB6tA1e+H5gRa+Qy6 P9aogH+eni+EXw0u9CSVYDlYBfaSsax3y4mitCJP3weepu1MD1eAlWA5qBZm4o1nVMeeDT5Dn0+D h7BzSPvsP+FuFzwDnnBfAkeBw0EiwT0pFq5jvs6ieQg87uEkYmCDxgaSGizUYKEGCzVExWFqDyM5 7ElWC9qM5UZ3IzGzHRwFDgd3KRIJh0yMKS+RptZ2wZ+QM732QSRWVw9lLNYWjVKrBZIWSFqwuluo ZcFN4Goic5GMcbyJTyzPAGd6bXVdPELMX6f/J2551kvgKHA4uAk8CarNA7Q9gDd2Ym0n/PPwL3uo 3ttGP+/NUWuNDJpIg19o0H2DmR3FPGrtafgTgX9TDxvUXvmQyJ1WMR/5TmZ2J5JlrJFWYAFZ6A7y 2xOB1oKPI/+AXHQG/lndQfx/Iqc1MvlQNf0N3JTg58hmU8Dr8MYSdNqxFt6Bvxes8HKg7C9+7Fs5 ioFdOvuBH6o3XHKpU6I+CaxUPtBOefsYsV1BnBQRvdtptdJdpm2dJfRKa7Mmnwc0c7ZVlLW5hzW1 h3Wkq+Nm+JnU/skb4yP0J0nbn6P/c/xMhnGPqX8UJVcrmvlqH5D90RqLfiP4jeiXedmjkjxQrrsD azCJ/HnwWvBmnrIPvJjTV2czZxHP1dp7dJZl5Sqf56Ha/JKXk+cK34yY3IWkAHwvcL3OL/n2ZeL5 fvL2cs2i7m5icqdquq2JvVyVyNxpDOdpPvdvN6tY7sqyIzAvu9XDkgdWE2OrWZUGN7FeVoOb2EE0 V+drW/Hnm7SaxAqaRBzqU76jvbL7aa3dz2QVR84q/htY4z1ptTLwMflB9btobyWSVXJUV7pE+Du6 s9DzIi//TEJTn7IAnAluCNyifOBpVm5/3WVYuQeoXeOhWaHKDwq0pfYkkpP0Xz3cObBLcx29fUl3 Q/9v2RPz6e0F5K/h8xvgCxjLYT0pWQMctb/DCQoe09Oj1VxR5msSWUVnbQ5jnKtrzb6DffBWRbvA EYn1ayy/gOZpLP8R/o/wfbC/XT0vqJaL6fNIRd9S+OPg/W4Dn54r1P5dzFQbLOww+6+eo+Sc8CDZ TyN8KqeX406WUWi8fZHaOfR8F89ai7V8HanzO/WGi0+cj5nfsbq/203Vmv2O8s5d8L0ZbxWj+Jhc 8TErMZ9+ku2tNdpDuxNjv8rrrfakEL6dI2dX/xZG/StHToP+u+nbVtoS7VZXZ4SucVoN0jOwNcj+ i+Bzzj1iuTvzuNyJa3xaLwi/B2sfeKjWXsbOl7BZ5DiC7ytK1N3g01OZeMDOwQ+v0Go0OIMYOOao 95ZgoTX4I+xE4b/D2F/Czz0ZY5ZWH4AHwIx6TE5ZOorJemoV/iqNCvagh7FWSj8HYSfgztIM4EWj ju4N+nMucJOiexp8B1yLvBAs1pxgzpyqaXUAu7r72EeU721OodjZBW7BzhbsbMHO79FPop9UiTUK STckUXNqVd5XrT0RfAdci7wQXvUbmZMtT1lrkHNUP+z007bWYPjBhlc7gmuRF4I3IGlB/HDewOb7 WDsDVoCLwUWO7oB9sNkHm32w2QebfbDZBy/1Uct2G9W02+CBDVjYAP86/Os6CvHqXPqv+EszXuWl b3OxM5dWp7Ggki7082MPt7GytA8D3dtZrTo7kxw9ba73bgf6lE3OXtYstwPV9JmT/BHO9s25BfQF f4215tivBveCi2g7BOxN25XIPwC3OxKlgUIdV6BS0cmqjrPDXSUrnWcFRru6Tw3DV6PwwN/RD6pX A5Ws6zvo7S7i5H1whndP2cfsbCYm9zFr+/AM8amrTDzQSmfKvU7wRe5EFpot0dwFP4WndzPxxly8 qhLbZqZs5P3Qfx/8GKwAN3OSrwgc5SkquajzIvOr/FEPmWv4lSZyVCKRUMwMFjPjco/2TbF/J/fK qHu1YkDurRfe1pV44W1XZtl+gZPSNvWJc6fuO05Cefs18N+RV+h5zHmZrIi+nI31XPQF2oY4Fz2E 5lt633S2aJa2uT/ag/W+7DSm9pe0+plizvXIm2LhPLgI/RLipEznwn5dfWsfhO8DdlR0CnSOnEJi oxz9N4modxXdBeh0JCryVdN+ipn9C3yW2lupbUa09MKCuasuAvvyrB6cCl5mB+ytHrPfZwcpJzdu ZNfYrOcTex4n0unsQfM5H05A8gSnmirsrAP3gO+A72LnCLgDfJS96V322ZWK7lvwZeAqsms1e9AP 9PzmtOUU967HrwArwXKwSmv15uUex//90GwI3hn4uqC5kXFDtFd5WAmWg2rhNTTH0ep1lQiqZIBK 3AeIimGcdR8FQ+AoToajOX/25k7KCdZpRfy8wbPQtMs1lzpIBHUUx7B8s4crwEqwHBRr7q16Jw28 ScxscZtKq6uxNg+MgdxPnTzG/hj8Cg9XgJVgObU6rsfUV85a5XNuCPwYHKL2aeV4qP7hjmAvUj/Y PTj1TfDwJXAUOBwklvTkFmjAvH8Tzd6aG92b3S3Cf+i+Jfhj5Hs9HAUOBzeBt2u8UbsZyWYkT+lZ 1/6FrlD/9zhLtwT/DXyUs2UB96A7Obu241Q8nYh6lIidrudAqzeWfwn/GLfX5fTtD8j/oHacEP0/ qBLneg9fAkeBw0FdX7dor5wv6B028IqJeV0R1hGsXQ3O44QwkXWUx/nh28T/i9S+6+FL4ChwOLgJ HfGnc6M+xX1L3ysKqs4qWq2Cz8MD1XjpPbeStdBSaw1yYz2qN1bnmErctdoTZwX8h/AOceKgP8E9 wSwY1Nvr23p7FW9oVOxwJtI3jVgf/Cp6vopak0W7g1e7eYI+nS+3eeBe4eer3L2RSP4D+JiXSzXz rCGXzkRnKvqvsuL+wjq6mozahQw8B/4NzcASV9LKXc+8bMYmt1f7WSw/jLW28Cv0/is3XK0dheYa xdy1GuG5Pm5bP8Iy70xyTLb/DbebclbocVbQ66yOL4Hcju3FWHgFaz7nCWm1Bju/0r45vKdyuBHL XOgemuAu/IjyYqEK3MO6rgL3sFqrwD309pfCP80TV+Kl83oGsF8gO20BHfr2ht6RnZ+CYxRt3pzY 2wJP6n7HKp4J/zr6L9P2aVZ6uUoCac0GgYeQv4X+IXAwOC9QrZgzVHc6dH6mkZNzPXxTsCPWzqP/ HH1uoLuD00TfUzm3u/nEj/KW9s09qbPvNGHtTDD3TeJhkbtV40TlzvvenVrfWFZyx7mTdd1H94ic vszdO8zUXcoHGriNpPYse9YqvRFL9GpO6KW1OX3ZWebpapJ8tRrcRF5aDeoeWsx7pLbIDyI/iPxD 5EeQv4t8GNb+wFPMzWsCO+MecJU+1z2kIwrwPtZexo17PnvcbNW3/kPv15LlhuPhj+mz5qU79a4d aMSqr2J1r1MUT24nz9xOTxR3UHs156Kr9eQj+fACa+ElMobWloHlXvbQVvvIG2/qvVt05iCfQ//J V4HHhV9Bn+9xrhf8iaJTgP+XMtLfMztj0bnf01RJS+5Bv9YxOtfqHdnmrbJtbm37ubVtJSd/Fz+0 YN7bcy/7MdHSzJVcFMil1cecEH6h93E368jNwplOjh1J25G0nQZfoc+yvswTS5mXl7n1xxnRD7jh 7mFFOEie1lu505Z+fgP9UzyRXrlT4Cfo3dz+FrzReRgLncFv6nlJzo26Klc51+m+QA8/IM7Nbfor REIfxn67vUbGNVTtBMaA4xWdec5iMqeuiK8q745zx9Er9ecgdMzfO9aSzVyttR/RXcz1Y6cx/l9F D3+m9277PfgP9bZu3wHfR2/r9s8ZyzXaE5cV5NzvNBfJXPo/0f5Q8HFbIsE5rn/lCfyUM+GDeluX 0Wl/rtc7uz0Vm494qD5sBN6v93R3Ffh1vUfY/6VjDzTFA8XcwQ/TqkTv6fbn4ddRe4b+/JkeLkP+ V/6WUaCeCbTm6d3B4Yx3BNjZO1vqrtqcVtv15m79Tm/u9g/wT3PeHx6ihw+CxczOU8xjSGdNolfQ WoykBf2cwy1mJtjD8NxQZrLWZnLTmam3KqmVm4h7Cyfq9Wh+H3zdfYJ8qHwQDBnEQggLISz0QbOK u15blThtkexDMseRGffT1roJfJL78te4L3+NW9id3O9+rHcliQTRt9JovssTm3L+bI+19trW6QU/ ySCSSWpNcC3yQvAGdnbxjLuL0WUduRXaL2LzTuyb0XUHv6t3T+k/o8BmW2y2ZaRVjLRKfeXcr5YD vdzd4Pc1irCw1CD+KYXvix96BML4SrE/9/f39P4uowjruy9nF88Ns4J+j4XTWAvrbqW9ksyj+IJz s+ADzmSRjyOjcl+W+7XWPgW2QNLdmSL8KEf71h4J+da5gbn4C/hXRXubortD0WkPTtK27m085fPY 7Ad2BRdgrdz4Cgsfgq3x8GPgw5rxcraoB3Kj+PMs976HeEv/sPI5AXa9B7XWvQUPb0OzF3xC+Zwt ai03qicTt4b74J2My8RGF2a5F/PyInweFrqh83N9P2CXqP+dfGZhKbFxo+5i9lEdnb0YvjF8GToH wfa0KgTzmM2m2tadrzPuLkDeEc1XmOWnlLf+guTOQGfwOY03NJvrbEqcPEEOVNyJzUXwN9PnPHz4 XZWL5ll6e5YVyl/qL77q8/vsi7+GX6x/ywaLLr4CfytYrn8l92pfBeejPx7eYDNwJnLTdgn8Eqwt Av+A5A/w+9ERuXXvRX0j2h58AhwL9gD3g2WKfkvRdwZJEehTtJPwz4MLwWs9Xv9qsI+2p5HMBO+h 1TPwedQeAs8h4SnWQCQfwhv73Xh6NfgutX8H12LNRqcfOBj5+x6vfahAshhJH/iLtGoDfxTcAL4O nkAzDH8WPgBfAzYDD9e00ZMh/UHf9zeV2MYzLcB8lfgZtf9+8G3kB+DXgDvRMd67t+YrYqGTmQvl rR7gXHCemQX4ItAHPg8urNHT6Xrjf5X4fwGepva3WJ5tRgd/nfE8OjXo3GjGguQQvToKv8sby1cY V660HU/bCSrx4R//42gW1UQZxRx6PofezqFvijORnAZPILlR0Wf4FmA+eIQntgILwDvAD3iWicBn 4f8E5tf0FBwE/zlmdoqJSZVbS+Db1ejt+x34rsiJCitHMUCkBR5VdFZh4YJ6IPCw8u425nqh8czF F/Svjej/0MQG1p6lDx+j83d8da+uSllTzYh/xRlmli98pCuOkY710AILBK8De4Bl1JZhrUwl4k+V 90ZeBPo8LNB9Af55D1Uzirf3eZ4vYBbmgsrfo3L7GWrP0OpL9NBE+BlGhP/975kZYaQvm3iGj6Oz HC/tNtlDfeXswWNm/ebBt8AzG9DfUHO3vpWCH4ud78C/pGiziu1+ROBZ/DaTWmbTfwPyE+pD/3n6 HMB7+YwoFy/VKEpcGV7HiK/8PwRNHD7oYQFt52JH9d/G5m5qXwXxp+8Uoz4OvgT+9uLnBC8wxgZI XoO/Ab6AWRsAv4OeH6O2ufKSMSpEcje1j4BzqJ2LB4h2+w54s9Lz1WPWrcjNivg1+AKWE1hIYHmv 5yXlTWbbzrreyGr9gFkgq/gdPH8Xdkwm3AH++WJH9ST8NpMD0ZyK5hdNDuQpu5Cz+pyJrJ0t8B9f 7CP9NPvIfLLNO+or5y743sirsPMxPJnQugpsCxaaNYvOFvBXXnb6kiA7hX8rOsvNigbJANZzeKk7 OntAkzeIW4t9Qbwqdwqbte9/BRwNmlzRGvwR+B3kY+B7glki8DHkr3p7gcbzZI9XD5i9Yxj65BCr 1OwpzGYA/zcDZ4Jvg2tA8rn/NebrIvwb4Dna7jTzBY8n/R/CJ8EoXqqGb0TtWvh+4OCaau0h8vex OQNcDC7y1q95lkb+FiK/mhUxGOyDfAN8F/QnYY19x7+Jp9cQG+yMfjK53RzNtUQLvL+abLwXfhHy IfAmrzL7gUoiqjH4fTIM55NAS6yZjDSY3r5+8UX9GxMWLtb8kPEK+jeD58jDA8kki8EH0DxHHm7I WMw+lefl1QJiWzNDNyTd8F43sko18kb4Ya2HmnttNPt5qBYqqF3sYQH7zgh8WEA/NS8VULsdfJ22 A3jHeIZ3+C1409gi8EvRbOh9u0a/ndKF7+Rc4N3yrfotR//bilYlf//dxN2TN1T+Pzn6zZz13Mj4 a4vVK3C1rnT+grNDeest+I+c/dxV+ZuXns99Q61WOi/6RsJu42T06c5P9YyhvFXl/FWjUdH+yFno 0/dLouk7oOhP06qvolvJO40AeJszQdcmFiocOffaw7BwXmsDg2g1EOzE9xPOgrlOvs64/V31mL1R dZS3Jup/4WKNULRH2QexJpq+rYr+QtMKyW5F56SijEJxvv20jgI7vfStgrXZ2KF2iKI7GQtnwYPg VHCZre9z2ihaa2y93Rfovd46i6SJO5R+6rfIGqrEt1t53wFF0Vd+q+q73bBTQKsOtn5/r5U9W2ff nk/fFuk7bVotA7siaa367jpaHfF6orVDkMy1x2u2Qd7dQ/0ekeNZm69eom8rlPcfoj+25Vd0z+iv 3sBblqUS/zpq9RvIHf2H+casfqttgDVVsL2+dbHWWM9o1rV+oD23fqbrWnnrSetJwTJL/7ptqb5/ JjhQ0X4InectvutozRC83X5K8DX4dvYr2BHefxpN2lr30PYZ+M9h7bRGqf+PPP2c9Tldy5ZGxRCr Gf1srPFv8Vd+KyCSr1jX6Fq2btG1rPr+KHivou9viraNhb5YG2w115xpvY1N5aut93XXgF+EZhgL NbT9AvxR8C2/eng5fTju/6Jo3ubXN5ySF0Vy3q9/Zb7gP6N7gdVB86o1kb/a6y/LnvAf0v4o+r9i NVWJtVJ3Lv+fdM8FW4C3KYo1Qd/78DPAJv6DaB7UlQ5/wD9edxNsvu1fIPic//e6H2lPfB9g4W/a E+u8z6ffQndOKQby4P8TvhHfTr8a/svIf4FE7Dg/CYhNZyjYCzypaB8DFyu6DZGfV7Qc8GkkrdH5 pmJgH5ptwDC1hfCl8EPQPIoEuTNVMacl/C3UvgmeQcJT7N/AJ+AnggOQTAbHKfrprdWd2l/DH6I/ AXRmgpXUboJ/Df4vYH/w68gZkX2BtsbadvD7YAZ8B81O8IzL/i+e+G34jfRnL3gcyU+xFqdVFzS3 Ib8Rfgn8S/hkJfyj4MvgrbT6SY7sPoHrzewo75wEL5o5Ut5tiOQ8/N1mjpA8a2ZKefubYCk4CmsP mPmiVY6ZNXh8EvjQzBr6i8Gj1BYq5rRE8iZ9ux3NaWDW+Ienf5Uerjc+UYnsicobj+FnZz7YjSfi bf9fqcWT1hosEHXuc+Bm9OeBu8EIyKgdE2kv0c8y9G/GAj53g/SB+LFaEXtXoX8EnZ/D90DTxFhP MKiY+3Ntm/t5+mmj0wcLvwLzkF/PqFvjmW3oP08ta8TZQ6ubeBa+tZ8z6w4f7qMtvnWmgrdg55fo dMA+/rS+QtvlyFllronVNM8yK7GliT3s/BYeTespWp1A599BEyF4zx5tIpnn3oivlij6/4rkBZ5l 4vBL4F3gvbTdCd8RC0XgB+DfkT/Js2LwX8MO43J5utsZzenYmQ2P5y3yg7MAHAsORsc88XegiZA3 qH0IZF7s5jzxWyCez0HinOaJ45GbnMYadMzqZuW61yBpApIZbKLCxpplMhVZxTqFPm2dMeCrYAVy kxvh7beRbIE/yNOJK5u1Y31EK6LONavJjGgtOg3QfxGJmfd1yAeC+SB9tsmZgXJsml4RFc7vQdaU Q2z46XngcVp9F/1z8KxEZwK4HzlzauN/dxhycpRD1nKIB4us7iTB1eifIWYmEj8mX1WC5CKXdWR/ H4nJnFW0NXPKvNvMVIBYsr8BstbsGSDRm7NDMZeocNm/XKI9gLdzGHuAWgd9mxxl3wn216f7fHoH cX5So38tGgr2Ak8q2sfAxYpuQ+TnFS0HfBpJa3S+qRjY99/sfQeUFcXW7q6q7lNnuvsUAw4IQ5Cc hRkYkSQKApJEQBQkKTk4IMIwICIgggQRkSQZRJKImFCRJDlJEsk555zEgZl5Vd9pvczoe5f7e++/ 3nrvX2etr3bt2rW7ateu2tV1+vSBZFFgHZTmBd0KdGNIngYHfGuYQZkLdCGU/gi8CQ6uIn4C3RZ0 f2A9cAYAexlkaC2vhNKNoI+iPQHIfAich9K1oL8CfQn4HPAl8NEjkYy6YW2bge8AOwJ3QTIONPol 7uKKr4Neg/bsBp4H5xNoa4NaZSG5Cfw8oBeAngKbLALdEzgNWAR1s6NuKmSeAj0KpV1BtwBfAtGX wBVgSZQOB3YCPo1aK3DdHGhhuOXorzUDWBF10Wt2DaXoEV+Kuhh9ewxwHeSnA3cAnwWGWxge8XC/ +gILQAP6bivoxDjygvCBCMifhMxnoJ+EZHisqwBRK4jSYGa0U0DmGWj4HhiF0rGg4ZnWTsjkh2ZY RqD94huUxkAPLMMrg78QfHivHfaBDtAW9vCwr24BHzJ8KDgXUDoaiNHhsIPoBpwEbeFxfAxYAVgf pdtBl0atUsAzwN/Afxc6W4N+HnrQchtXsctAcgT0jAcNW3HMLGsmMBH4AmTCV/wFGB7TJSh9FQhL imy44mtAWE+CY93AFXuDH14N4L1WeF7A5+0M4GQCYk4JjKOANh6e45iP/CrkUddKAH4KnAt+eFUB LbaBsx70YVwdniDg4fw6asFP7LDPh3u0DDIO5CeDEx7Z5eA3AEYD0WaB1SYwBDrDrcK4WweAmAUW Rp+h5YF+qPUm5JNAY+5YfYB7wceYCtjfbgY+ZrcFT+BYCa12wMWQgVdb4ZXkMujwSGE0BewfgIeI pkD4vBgJhO/JrfB/jLWN9dyGrwZgQ4keBVBqQV5gfRDlDNIBvo/MqchWXZo/fI4hRmhODdx3tzOn DWIGThJqonSq+W2syG2eTxPjcZbCDYefA3+E4ZsHLMj82sJwmhm0dxi0SoB/E3W7ovSswUA30O2A NaDtclgS123sn2bkJ3NGYe4Np4IzyD/xKIHf1plTlFo4P0nCeUgUzkbmgz/T1OXbwWmH0nGgOTRc BiYC56LvnkHeHxZoaE5I+DqcWsSBjhPfm7pGhlJxXvGQf36ikY4ZGbsU9DRArao4ISlvOOwha7Lm Z/HPRubjDGQ+zkM0poxKNedU9VK3mrUXdGNzb8u3G5pVA90EpVVBLwO9F5J9QAdBl0fpatQ6D06m sDZwjqeYO/3ikMmEWjHAVijdHUaURoNOQukEaMgP/izwy4AuitIA6PagB4fbYGi2L9wGlPYydEqD 1NvaEwqC8zVl07gf9FRDiwy4l081KCoBr4OTBHo8JI8YtHcYtBj4HDgfpUGD7Cboy8AYyBNkRgCL AgeiNBFtGAO6Fei5uOIFyPQGvQGl8dDjQP8q4Ey/5aYlncBZBM5S4DAgeipqoFSB0z9lCf6F3Whe nmJOAnNDcxe/DYZ/0IyRqGSQDqLuAuBIaMOJBz8JTkMjYxVMMc+qPYnSyilzNKZQHc2PhEys4fCr 4TZD8wzThkBOcJYZmo0Ev0HKV8Y/jby1BqW7TanuuxkdD5obgJ8VOj9A+7OnJul2DkBrb6Ft+00t uyv6chr86fC6vqYWK4Nr9QadF3piUu7hG4R7xp7AYQb1bsrgUXByQOY06EwGxdNoVRxGbR2u1Qua 26GFRw0GLNi2cNhDUl8wXmdkeCbDMe/f0SskZpkVafoSyAr504a2q0PGA6dJ2A9h7Ry4igfLZDIW Y++i141TzNlsPFo4F7ST0sj4WIo57XwIWBdXXwdrVAPdykiym6gVA/o2JNdBw0jQw8HfDWtsBr8g ODdQ+iE4+6HtQ3CehOQVg3rFwXiF/RDtr4O+HEMbjsITwp48xvRa3wUchpUw7sD+GKmbkE+BhhK4 VnmUxsB/joJf1qBe38241PRlDJ6ED+yA5u1h+/vWMC2vir4cha2ygB8CNoZkvH/de5gX9+B71+EJ YUljt1yG1r59HZ5sZFoAR4LTCJLRuFY0JLei1jrITAQuQmldf/6W0n0JoM0L0cct4OcA/oj2dAhL or9dwr02ktqLcGoNjwr4Vp0Br4Y1jGVYB2geh3VgOay3yr+W0VMKI5UlvFKh1mXUWgXJFHh7DCQX wjOjDB3ISxngaUsw4qb9k8Mz2p8jRlszjFF+4Cto4UV/xcuGWGOustmfs+N16ZfhuWy06dVyHFpV CrXC66rRPBCnxJepDfyqjYnpqfU1/SK87jxksA6I8Dwajrp1+U/w/CUYTdPHFeG1EZL9wG8Iy48x qNelJVgrzKoSHpG5wCBKc6PXVdDfw8ARwHvQXBXj9RQwL7CWL2NWub7+OJqVbbRZM7U/LMFsmgOv uIdvcu/BV+/Bn+9hLAx9B3br70exbOCYXk9ETyuGoxjWnMsYnaUGJbxIIsqIs5BsA0SMo6vGD/Ue +BDWwOtYA80K0xDtLA8vjYEPb4dXYy3SkjMgaeS/AD8ekjVA1wZ/Jlq+G/R88Kun7AR2xey7bvbk 5iop41OPY7wamNmKMX0W/cobjmspq/F9fWbTWrR8APqSG5INUrDnQd0clEvrjPZHVtPJnxvNRHjP G1nmdzr+SaNBcsB3DJ/IcFKamqesU5qYJ+FT8HuQFAd0LOhY0KXNc9opceZZes3vCv480C+b58fM k/maXgv6MuiLhja/4tF1F5u33IAfZ54G1Ho+w7tZbuH9NksNmt8REJnfuadEmV9zpESZ34OkfB2I N2+5kW+bt9wYOnmZoVMGBD4wb7mRV43+wEmD8groA0a/PAv6LuiwTH1gaUi2BLYx770xbUs+Gm5z 4CPIzwAdrnUebb4Jfn7wIw3Kp9C7EsAr6O9AlC4ESvAfh2QVXOsi+JugsxQ45WGZMCcJpU0hPwxX 3AQrJQH74eqVIVkMdY1kDOgY0KUCG8C/A7oY9IT5BdGSF0EXAf0S9OwxGJSg8SafYBClTcEZCm0/ mHfgQMPj0BALOhZ0afN7eS3/M+gswMyoVQ1tLoU2t8IoT0FPb6EUbQvMBudl4FrgTZQ+rLGk/AL0 l9C5HPRwyHwDHA3+QtA7QN8wLTRv4dCtNX5YGt/Li+RU0LCb+SY9JTb5nGlPMsbCfPOuOddNafIy Y8kwJ6UfMDcQtaAhNnkNJFE3Gb1OngL6JHSuBr0b9GWUwqOS94FzBnrMEzhEDhsSPE+i9Rvd4imq fbe2r1Lf+JYJXehr0nd+zzeokpv0nUVqKmUmjwKUg/JRJipBj1E5eopqUSNqrnXUpzfpbWpNHek1 6kGDffkQScpJ+ekhKklltJbKVJsaUwt91QbUhwbolaMTdaVEGoL/GAzXURTUa0YBiqIYepwqUBW9 Or9ELxOn5+kteofa0qv0OvWkoZSFRM169WpQrQbPPZubWjVsUDs3jYeWh/HO0Ef02lxQa4ylivQ0 PUPPUhN6hQQVpYbUlwZSO4qnbtSLhqFOBOWmQmQi3RNUlepSMXoP/KwUqe2Qh6KpsNZbmspSJapG Neg5akotdbuL0wvUjwZRe+pM3ekNGu63ICO5lJeyUxGtIY6epOpUk+pRM2pFNj1KL1J/epc6UBdK oN7mXaatS3VvLV4EtgC2A3YBJgL7tm4ZnyDeBY4ETgTOBC4ALmrdsntbsQq4AbgVuBO4H3i0devO XcVp4E2DFgdGAnMBiwPLt4nv2N6qDqwDbNCmy2udrcbAFsA2wE7ArsBEYJ923Vq2tgYAhwPHAacD 5wEXApdrxS2tDcCtwJ3A/fFdenS2jgJPAy8CrwPvAFMM2lb8a63jbQcYCcwKzKULu9n5gUWBMcAy wIrAKsAarxk9dYENgU2ArwDbAeOB3V7r1qaL3QvYFziwq+EPA44EjgNOBs4AzgUu6K7HyF4IXAxc BdwA3Arc3b1jl3b2QeBx4FngZeBNYFL3zq27BgjoAKOAuYCFgaW6d4+JDVQEVgXWATYENgO20Vgq EA9MAPYBDgQOB47RWDowGTgTOB+4ELgUuEZjXGAzcAdwL/Aw8CTwfPcerboHrgJvA+8ZlBwYBKru Pbp2l1HAaGBuYEFgcWCpBG1JWRZYCVgVWAtYD/gi0OzGuV57ov6FVOh5np1y/JcohheH/p/R1iuG rVdRScF/W85CLkwzveqlx9ADotDrnIt3Lv8diunV+68x0wMjx4hwrdXkcNpj4oPZJT4wZnxgzPkn jHxgzI2WCqTsPjQ9uJ+n/ikKHamyUNZ/kXoYFNfxKe+/lOaj/P9SWoAK/gsp05H0n+M/twnTEfyf Y4YHwli920jQUX8MzaSFtIZ20km6ySwWxfKzOFaVNWRtWAIbyMawmWwhW8N2spPsJrd4Ll6H9+bD +EQ+jy/mm/h+fp4nCUdEi6KivKglmohOorcYJiaKeXoOmmsFwz4r6qbLt0qXH54uP+K+vJWuPKCn +V6S7L68E5c2781IW1/dTqs/qknafGZKqz9zVLp8wXTyNdLlm6XLp+tP5v1p81kKp8vXS5fvlbb9 OaanLc+5NG2+QPF0+RL35fX8KxCTrnwA8lyvD5nCPSxUL5wWDvfc0j6XRa9VBX3udj/d76cn/fTq X0kX/dpPl/rpOj/dkbYVxVTaXhZbnDZfckBa+ZIH0+ZjN6fNl/ouXX5R2nzphunyL6bLd02X75Yu P+4+L9NEmfHp8ovTypdJN0p/Kt+aLr89XX5H2lEst1Wj0pZpzcZSOzYZq20r/SE9U8cQsyPtjIgV mSjg1VTrvBpqjVqhVmlOgF1il7TcVXaVGLvOrhNnt9gtEqqyqkyWelo9reOm8Qcuqoka5no8E8+s OeYXRMq0R4R0zRI6n0XfjXSjybSOjlISi9JtCOpWRXn1iXs1vAYaa3rPa6ylWx+p1+Tc+m4hRt/z VFRnSfBI3aZzSNcpfafFM+v8BaTr1G7iOrdX4zq1X+MG3VfjodGUVx3VbV2hS48hXaeO63SVzp9A uu4+yZO+5Clf8rQvecaX/L29tdHeOmjvs2jv7yV1UfIcSurdX6I2oYWb0cKtaOHvJdtRsgMlO1HC SXL90dPM5ebJ7Ugeqa2aWVtVeNW9Z7TVV6gVFNBtWqUtJbSE+TYyHPX11NL1W2K8CCPFWBJL0qOW ylK1tWyu9z3Qa0NvAHolj+bRFOR5eV6K4IV5YXJEDT2art3KbkWe3cZuQyG7nd2OlN3B7kAZ7G52 N4q0E+wEymgn2omUSeVWuekhlVfl1X3Kr/JTZlVQFaQsqrDS93yqqCpKWVVxVZyyqRKqBEWrGBWD 93KXphzqMfUY5VSPq8cplyqnytEjqoKqQLnVE+oJyqOeVE/q0TH+lg/+ll89o56hAqq5ak4FVWvV mgqptqotFVbtVXsqouJVPBVVXVQXvVB0VV2puEpQCfSoSlSJVEL1Ur2opOqr+lKM6q/6U6waqAZS KTVYDabSaqgaSnFquBpOj6kRagSVUR+qD+lxNVqNprJqrBpL5dRH6iMqryaoCVRBTVKTtH9OUVPo CTVNTaNK6mP1MT2pPlGf0FNqlppFldUcNYeqqE/Vp/S0+kx9RlXV5+pzqqa+VF9SdfW1+pqeUQvV QqqhvlPfUU21SC2iWmqxWky11TK1jOpgvJ/FeNfVvrKGntO+so7qqQ3aW+qrTdq7GqjN2rueV1u1 dzVU27VXvaB2aK96Ue3UXtVI7dZzpLHaq+fIS2q/niNN1GF1mJrindjN1BV1hZqra+oatVA31A16 Wd1St8i853uAnh8DtCdlYBmoH4tmOak//hl1IGvCmtEgFs860xD8G+ow9jpLoPfYMDaMPmDj2QQa ya6xazSK3Wa3aTS7y+7SGLPI0Fge4AEaxz3u0Uc8I89I43kWnoUm8Ow8O03k+Xg+msSL8CI0mcfw ejSFJ/AetJz35D1phd5H9KaV/C3el1bxgXwgreGD+WBay8fwMbSOf8Q/ovV8Jt9DG0RIrz/3RJyI oxRRRVSlVFFT1GRcTBFTmLASrI+ZZbe2W7NSdlu7LSttt7fbszi7o92RPWZ3t7uzMnYPuwd73O5p 92Rl7V8CQ1g553mnJbviDHYZS/EivWr8Da+pN5V/EWoT6sRvhPqFhvMkxVVQBFUelUdkUPlUPhGp CqgCIqMqpAqJTKqIKiIeUsVUMRGlHlWPisyqpCopsqhYFSseVnEqTmRVZVQZkU2VVWVFtCqvyovs qqKqKHKoSqqSyKmeUk+JXKqKqiIeUVVVVZFb1VA1RB7VQrUQec2fU4t8qp1qJ/KrDqqDKKA6q86i oHpNvSYKqdfV66Kw6qF6iCKqp+opiqo31BuimOqn+oni6m31tnhUDVKDRAk1RA0RJdUwNUzEqPfV +yJWfaA+EKXUKDVKlFZj1BgRp8apceIxNV6NF2XURDVRPK4mq8mirJqqpopyarqaLsqrGWqGqKBm qpmiopqtZosn1Fw1V1RS89Q88aSar+aLp9QCtUBUVl+pr0QV9Y36RjytvlXfiqrqe/W9qKZ+UD+I 6mqJWiKeUcvVclFDrVQrRU21Wq0WtdRatVbUVuvVelFHbVQbxbPqJ/WTqKu2qC3iObVNbRP11M/q Z1Ff/aJ+EQ3ULrVLPK/2qD2iodqn9okX1AF1QLyojqgjopG6pC6JxuqquipeUtfVddFE3VQ3RVN1 W/0qmvn3UmbnE4e1toh2Z5s1Z801uy1rS8z63vqeeCA5kEwiWClYSc+ef89qrD33f1bj/89X4394 XzS8r6jZbbGOgQP/42P/42P/Jh9jdie9n49keXmcqG41phxUnqpQLWpATfT9Qie9f++t9wPDaBRN pBk0j76mxbSKNtEO2k/H6Txd1zt7YgHmRfQiEdE9IiHiDaQ9InojTYx4E2nPiLd0mqCpvkgTIvoh 7RHRH2lixNtIe0a8o9MeWm4g0oSIQUh7RLyLNDFiMNKeEUN1mqjlhiFNiHgPaY+I4UgTI95H2jPi A5321HIjkSZEfIi0R8QopIkRo5H2jOhDXJcO0NgjYojGxIgRGnv+DYuMRc+7R4zzLfORb5nxvmUm +JaZ6Ftmkm+Ryb5FpvgWmeZbZLpvkY99i8zwLfKJb5FZvkVm+xaZ41tkrm+RT32LfOZbZL5vkc99 iyzwLfKFb5Exuv/dI6bCIjNhkXl/0yJf+Rb52rfIN75FFvoW+da3yPe+RRb5vvKDb5nFvmWW+JZZ 6ltmmW+Z5b5FfvQtstK3yCrfIqt9i6zxLbLWt8h63yIbfIts9C2yybfIT75FvoRFvoOnrIBF1v1N i2zxLbLVt8g23yLbfYv87FvkF98iO32L7PItstu3yB7fIvt8i+z3LXLA95WDvmUO+ZY57FvmiG+Z o75ljvkWOeFb5KRvkVO+RU77FjnjW2QzLLIDFtkLTzn+Ny1yzrfIed8iF3yLXPQtcsm3yBXfIld9 i1zzLXLdt8gN3yK3fIvc9i3yq2+RO75FfvMtcte3yD3fIsm+RVJ8X0kNW8ahsGUcFraMw8OWcYRv mbOwyGVY5CYskmQ8xfxPo2k3TtMaUxG2g08TdcRzop1oLzqJV0V30UP0FG+It8QQMVQME++J4eJ9 fe9yXJwQJ8UpcVqcEWfFOXFeXBAXxSVxWVwRV8U1cV3cEDfFrVAZ8z9KbDvbri8w1fw6V9QWtYmL uqIuCdFGtCVLdBAdKSC6iW4UFAkigSJEokjUO4Feohe5oo/oQ57oK96hkJgkJtFDYrHYQlGhx0KP 4ZQhmhwrl/WIldvKY+W18ln5rQJWQauQ6Zlu0S2crjPKet/ZRDGcB8UbCV2zkC+R4z6J4veVaUuK eC1NVpRl3gVW2CpMrn/dKCuzlcV62MpqZbOizbvvtMQ/rsspP2WwMlkPWbYVsKQVtCIsx3ItzwpZ yspgRVrmvMvSfeunm2DqcOsJqxJ5VmWrMildVoayitlirpgvvhBrxFqxTqwXG8RGsUn8JDaLLX9l cXNaJmaJWVrjHPO7ZvGZ+Ezbe4HQ66i23Gp9vePiwh/aZ2mpz3TpYrFELBXLxHLxo1ghVopVYvVf jTG0zxaztfa5Yq55IlPM19q/EHp11i3corWbfhjtJSjqL7X+RT9gs+O+zUy9B/Qu1DPeoOvZXfhC eocG0iB6lwbTEBqq5/V7NBz/LvoBjaQP9SwfTWNoLI2jj2g8TdBzfhJNpik0labRdPpYrwCf0Eya RbNpDs2lT/V68BnNp89pAX1BX9JXenX4hhbSt/QdfU+L6Ae9ViyhpbSMltOPtIJW6pVjNa2htbSO 1tMG2qjXkZ9oM22hrbSNttPPelX5hXbSLtpNe2gv7dNrzAE6SIfoMB2ho3RMrzgn6CSdotN0hs7S Ob3+XKCLdIku0xW6Stf0anSDbtItuk2/0h36jZLoLt2jZEqhVO3QjNfnDfjzvCF/gb/IG/HG/CXe hDflzXhz3oK/zF/hLXkr3pq34W15O96ed+AdeSf+Ko/nnXkX/hrvyl/n0/levo/v5wf4QX6IH+ZH +FF+jB/nJ/hJfoqf5mf4WX6On+cX+EXh8Ev8snD5FX6VX+PX+Q1+k9/it/mv/A7/jSfxu/weT+Yp PFUvQeZpeyEsYYuAkCIoIkR90UA8LxqKZqK5eEW0FJ3F62KgGCTeFYPFaDFBTBZfiq/EN2KhWCR+ EFvFNrFd/Cx2iF/ETrFL7BZ7xF6xT+wXB8RBcUgcFkfEUXHMqmBVNP/bau20dlm7rT3WXmuftd86 YB20DlmHrSPWUeuYddw6YZ20TlmnrTPWWeucdd66YF20LlmXrSvWVeuadd26Yd20blm3rV+tO9Zv VpJ117pnJVspVqodsjPJyrKKfFpWldVkdfmMrCFrylqytqwjn5V15XOynqwvG8jnZUP5gnxRNpKN 5UuyiWwqm8nmsoV8Wb4iW8pWsrX+tNWf9vrTUXaSr8p42Vl2ka/JrvJ12U12lwmyh0yUPWUv+Ybs rT995Fuyr+wn+8u35QD5jhwoB8l35WA5RA6Vw+R7crh8X46QH8iR8kM5So6WY+RYOU5+JMfLCXKi nCQnyylyqpwmp8uP5Qz5iZwpP5Pz5edygfxCfim/kl/Lb+RC+a38zvz3q/xBLpZL5FK5TC6XP8oV cqVcJVfLNXKtXCfXyw1yo9wkf5Kb5Ra5VW6T2+XPcof8Re6Uu+RuuUfulfvkfnlAHpSH5GF5RB6V x+RxeUKelKfkaXlGnpXn5Hl5QV6Ul+RleUVeldfkdXlH/iaT5F15TybLFJkapCCTs+RsOUfOlZ/K efKGvClvydvyV6eX84bT23nT6eO85fR1+jn9nbedAc47zkBnkPOu+6bbx33L7ev2c/u7b7sD3Hfc ge677mB3iDvUHea+5w5333dHuB+4I92J7iR3sjvFnepOc6e7H7sz3E/cme4sd7Y7x53rfurOcz9z P3cXuF+4X7pfuV+737gL3W/dH90V7kp3lbvaXeOudde5m9yf3C3uVnebu9392d3h/uLudHe5u929 7jH3hHvKPeOecy+4V9xr7g33pnvLve3+6t5xf3OT3LvuPTfFTfXIYx73hGd5thfwTngnvVPeae+M d9Y75533LngXvUveZe+Kd9W75l33bng3vVvebe9X7473m5fk3fXuecleipcaohAL8ZAIWSE7FAjJ UDAUEXJCbsgLhUIqlCEUGcoYyhR6KBQVyhzKEno4lDWULRQdyh7KEcoZyhV6JJQ7lCeUN5QvlD9U IFQwNCk0OTQlNDU0LTQ99HFoRuiT0MzQrNDs0JzQXHz7jBNZnIz249O4XkFx3vmxqKXj+y7xrI7v e0QT0ZT2iRbiZTqAGHpIdBVd6bCOeG/TETFKjKITYrwYTycR2U8hbp1G3DqDuHUWceuc+E58T+cR IS5a5azyjHBuym3HdliMHWlHslicjJYKHAucZmdljIxjl3FKesMZ7Ezi3Jnl/MgfdjY6d3gpnJW2 winpbB3tr1OE3h3k1TG/rt4BTdQRYLlenfUl3EHE1UZQ80GZ72giKQvlcNfr/B53g8Z97kaNB9zN f8ju0dRKCuq9RFbKpXcARcPfHrn7DN89oPEn95DGLe4RjdvcS6amymw0qixGo3rYaISuZGj9/Tua CJ1bqxyN65WbpiQDSiJRkjFNSVaUZENJNEo4RehRi9FjV5abf0uqwCsQ59V5dRK8Jq9JFn+OP0e2 M9oZTQHne+d7ks5V56rWx+25/Of/UIxNG2H/346v/z0R1sTQB42b/8mYmUm2ke1kB/mmjkAmclbT MbMOoll9HZlGIE421jHSRMdwbGz7gFGxzz+Jh3+OhhN0HPxHBLw/uvzfFg3/iHY6Lo7X8fv+qFhZ 7z7M3iO88zD7jnp65/Gbv++4q3cdL+kdx1TsOabpHUeS9toXtae+bPzy99jJO6eNm16kl9HL5D3k RXmZvSzew15WL5sX7WX3cng5vVzeI15uL4+X18vn5fcKeAW9Ql5hr4hX9C+j7aC/jrcqQjnKfaCo O//PcVdlUJEq45+i73p3g7sRMXjzX0bhPToO73MPuIfcI7/HY5VFPYyYfOl/G5WT/xyXVVaVTUX/ l6JzmtjsJf83ROe6jLPM+lY2mhWmKFaPNaR8+Ka0MGvB2lIx1p61p9KsI+tIcexV1pkeY6+x3lSW 9WFjqSqbyKZQC/Yt20ateDeeQG/xRP4W9ef9+Ns0hL/DB9N7fCh/n0byD/goGovvPCfwcVyv9rjH nyo8kYmmiSgRRbNFFlGU5ojioiQtFbGiKq1AxN+JiL8Ld2+7rRnWNjpvZ7Qzsqz2bfs2y2bfse+w aDvJTmLZA9pcLEdgaOB9ljPwQWA0yxsYGxjPCgUmBqawYoFpgXmsZGB+YCGrEPgusI5VDWwIbGcv BHYHdrMWgX2BA+zlwKHAEdZK7w2SWdtAqt4bDJBlZAW2SD4hn2TLg0WCRdnKYPFgSbY6GBuMZeuD ZYJl2IZguWA5ttF8f8Y2BZ8KPsV+ClYJVmGbg9WD1dmWYM1gTbY1WCdYh20LNgw2ZNuDjYKN2M/B JsEmbEfw5WBr9kuwY7Aj2xuhb/vZPqeV05rtd9o6HdhBp5OTwI46iU4iu6Dj7CR2UcfZH9ktHWfv sBSXu025dJu7vXlLb5p3nPcLvR+ayFeHn2/Rd6ML8I1Lc9bO53x3H4dReQr4e4+Cek8Tp8tn6Y/B BXpXMAupyS3zc8t07pD+mKdsirFi2mtKsBI63JVlZbXOZ9gzOrjUZrXJYuPZeDxls4Fa2tF2djuH ndPOZT9i57bz2HntfHZ+u4Bd0C5kF7aL2EXtYnZx+1G7hF3SjrFj7VJ2afYL28l2sd1sD9vL9rH9 7AA7yA6xw+wIO8qOsePsBDvJTrHT7Aw7y86x8+wCu2gJyxK3xa/ijvhNJIm74p5IFiki9e/wLN0V i+OkwcKvFTLi26ys+iMoh/5Y2nKFdE+Lk3kuraT+BLVVy+t9YkX9caiS/rhUlaqRR7X1R1Ej/clA L1ETvT9soT+ZqI3+PEQd9CeKulMCZaY3qDc9TP30J5uenZyiWQYWSdn1HI2mnCwXy0W58EzDI3q+ 1qPcer42oTz4VjcvZmo+Fs/iKT+ecijAerBEKsjeYm/pOT2UDaUi7D02nIqykWwkFdczeCI9qmfw t1SCrWArqSRbx9ZTLNvMNlNpnDfFYeaVwZ66Fk6dWuDU6RWchUXfdxb2KJ6mqsCbaYvl5LE8Vu8c y/Ay5jdivKouqcVr6Z1jA95A7xwb8UZk6/1PWwronc+reuc4xBlGQWe4M5JcZ7YzhyKdT535lMnZ 7eyhLM4+5yBldY44J/Seuo/bl/LoKDKQ8psIQUV0hPiYipn1nErq9Xw3xepV/BA9plfyI1RGr+Un 6HG9np+isvoe6wyV02v6OSqv1/ULVEGv7Zf0WKXvSwn0pSbvpPuSK01fyvFyusT0SPB6+p7GQo9s 9Cig93lNSKJfQb2Le50i0C8H/QqhX5nQryhngfOl7tHXzneUHX3MjT7mdc4456igc8G5ovtleloC PY1FT8ugp2V1HJyl7xPm6LuNJ9Hrauj1Mzo+3abaOjol6zuU8Lev5leObdCjkqaP5k17VN7vY0lf prCevSPZuD94nM1jX+pc1B9yegb8hQ0qcm03WMLC2NqwRwD2kLBHEPaI0Pve5uTAKi5G24NtQs5L zkuk9J15X8qg775G6TEf40yiHPoe7DvK7yxyfqQy+k7sClVyrjl3qK3eQwymznq3MJJ6693BfBqg Y/+3NFbH+n00BWO+CGP+g47gx2gxRn4JRn4pRn4ZRn45Rv5HjPwKHdmv0Eod3a/RKh3hk2m1jucB 2qr3OFlpt97X5KHDei9TlE7rXYlLl/XuIiNd0zE+Wt8B6JVQ3yG9TmTuIKmKOWWg+uZpG3refdOr Rlt1nZxswgPL4W2X/yHpP/yBWmFUY+Dz9e7zh5h/+AM1pP/V3nlARZGse7yrZwaGCU2WKJIlSg85 I1FEBAQEAyg5iYCAYEAyGBEDorKoBLMCKigoImBAUBRx14SKmNaMCioiCq+6REXXfXvfffe+Pe+c ax3rq+5meqrqq/7X7+vu6bb8ug7HHNC1e7Gvf4djNFYhazv8zgZWMxzj/WzqyIFrUZT/uSYKqA7k cC2/1NUUqtk/oe7wk+JICzGkhQBpIQ1pIR1pIQNpIR/SQn6khUykhQJIC1lIC9lICzlICwmkhYJI C4WQFoogLRRFWiiGtFAcaaEE0kLqt80nYQs4uCPtGDb+L68F4YAFRGAtFYEG0AWmwAY4AXdYuwAQ AWJAAuSndLAMrAZ58FuLwE6wHxwCNeAEOA3OgUuwb27BfngMusEb8AFOQHw4BxfBJXE5XBnXgH1s CDRg69VgX2gjOwPOwJT1BSbIzgKmyM4GZsj6AXNk/YEFsgHAEtlAYIVsEBiPbDCwRjYE2CEbDhyQ jYSzOmWjgSuyBQwJytKPMCSRrWZIUZYYYLIpyxBlcijLt53JRbaOSSB7gimI7CemELKDTGFkh5gi lIUEJYqslSBA3xMB1KEaCULWwOGSFsxnQOKg+AVqEmwlHImwjTyY+wFdmPsDPZgHAMgysG0GMA8C hjAPBkYwDwE21P0nwBbmc4A9zCMhs+CwVY4wjwETYT4POME8FjjDvABMhnkhcIH5LwwxDIftFYd5 NYM6+zLAhI6BLYWjGraTDvM6JmQe2EY+6o4qJj/MB5lMmA8xBTActg0SGNMKU4fHlg+c8yPhXJ+E ZWKrsDysENuO7ceqsOPYaawV+w27hT3AnkN9Gb6mCEeSJBzrynAskcAQmMPR5AhcgCfsDT/Yqkiw F/ZWAeyhfcj6gv3IzgJlyM4G5cj6gQpkA6C6UzYQHETWHxxCNghUIhsMqpANYY6mLGyjHGVhK8cg W8eUR/YEUwHZT0xFZAeZSsgOMZUpC1usgqwV2Ir8tw15rgh5rhh5rgR5rhT5bDvy2Q7kxZ3Ic7uQ 53Yjz+2h/MEUQz0ujnp8FOpxCdTjkqjHpVCPS6Mel0E9Lot6HGB0QQzdWU5DWoGhIx0IUj8ToZ4m 7ILu61fDdBEHoLNhYBQaaxJojEhS303tBUh9LYVRI4nSXqgn+WisoJy6SgeEoEJhQBzGVQApEY70 hZpXJbHlYCrwBtPBNOAFwljT4Aw44/O5aXw+nowvwzfQCmh7aIeIj8QnYpAYgiq7hbWVtY1VxCpm lbBKWduh4jayTrJOsU6zzrCaWGdZzUQfgRM0gk4wCD6Cn2Cy+lkfWAOsj6xPrEHWEBvKHnstex17 PTuPvYGdz97I3sTezD7CrmbXsI+yj7Fr2cfZdewT7A72LXYnu4t9j/2A/Tv7Mfsp+zm7m/2K3cPh 5zA5AhwWh83hcLgcgiPI0eRocbQ54zg6HJLD4+hy9Dj6HAOOIceIY8wx4ZhyzDjmHAuOJceKM55j zbHh2HLsOPYEh+ASBCFCiBJixHuin/hAyBCyBHUdVBVFnhiKNhmQuibBOS0Cj4TkEA+jSg6+BEaV XHTfLIFiSEEUGQqh87/CtIO0g5gIXwXfAUyUr5qvGhPn6+Prg8wI4yVMgoqXIFt1sh5i6lTUBElq GeQHU3YZJAdbGPHfwJxh1H8Tm4z4wQXxgyviBzfED1MQP7gjfvBA/OCJ+GEq4gcvxA/eiB+msQch OUznCEFaCEC0sATRQiohDmkhA7bzGDbjH/HoP+fBf4ufvniIhXoTQ70pgPpRBPWjDOpHZdRybdRy Q9TyKajlnoiTvD9Hnwz0tkFYdsKoc8s2mNzI8f/jKP7z8fh57MA9CKORgqGRQkMe5kP+JJA/BZE/ hZA/hZE/RZA/RZE/xZA/xZE/RyF/SiB/SiJ/SiF/SkO/SWAyw7VnM4gRtScg8w4fsdQxj8YphsYp QOMUR+OUNvxZDkNwxGclIZV8VYEvRzpSDnQUoJHMQCOZH41k5udIGrwG78DAMA0I46NwGVwJV6dN ZAQyghmhjHBGHGM+I5FQIJQIFWIsoU5oEtqEDsEj9AlDwpgwJcwJS2I8YUPYEY7ELCKICCHCiLlE NDGPmE8kEguJFCKNyCKWESuIHCKXWEfkEfnEJqKAKCS2EkVECbGd2EnsJvYS+4ly4iBRSRwmqomj RC1xgmgkThFniLNEC3GeuEC0Ee3Er8QV4hpxg7hJ3CFeEK+IHuIN8e4/v/T4z32f/7JfeghB5g9h iBIDcM63+ofua4dHIojguzXiLmQmdZfO13t8/pv7dL7e4QP3gVvgs0ac6aDWTIIK9PV8AXiD9UFG N8CN4V/YwnWu+BTcC5+O++BBUKtioOotoa6r/SxR19JGJriX75PxHxN15W1koq7T/TTZ/pAcqKt4 3yXXPybqit7IBNvyJwnOB98l2Obv0/SfJTh/fJdgL32fZqH0bTnohxQKU8SfpJifJfbg9wnOWt8n qR+S4vdpuH2f64v28J/zI39yfgRgnXD+NIdzvSOkbE/0LJYvT2ChnsayAluD5cPopwTbjZXD+OcY 1oA1wQjoMnYd9h+Jrjf/T3Pjfyp3/Wfyn54F+XyOhANNPhX3YNZULADnulEoeqCuswCgDuNoHM72 G2A5H2yE5U2AeoP4Vhh54eAweEk9hRa8hvFKD3oPx1vwDpb7QD+aMwdg+SMYhOUhnHoLCo7T4Zhj 4HywzI9TT25l4zD+xrnonSJCOIyxcRFcDJbF8VGwLEG9IwTOqzKwLIsrwLIiDiM3XJl6+wicY9Vh WQPXgGVNXBOWtXAtjHqrijYsj8OptwH9gv8Cy4V4ISxvwbfA8lbaBPQk2YkYjebEEKWeVceA7WVI M+yppysyJmA0hiPDn3pWOCMcliOoNxPDuToRlhdQT61iZDGyYDmb0YBRb1luhOWTTKjMTBxGkThT VWAOBgQiBSDpCczl7sEAdy8XRr3cfdxGWD7JPQPLTZBUASEHOYMGaXIIRXhQlQVxQYXPv7NGnsGx gOFfB39jEIAYBCAGASN+xQoQgwDEIAAxCEAMAtBvTwBiEIAYBCAGAYhBAGIQgBgEIAb5XEMckQhA JAIQiQBEIgCRCEAkAhCJAEQiAJEIQCQCEIkARCIAkQhAJAIQiQBEIgCRCEAkAhCJAEQiAJEIQCQC EIkARCIAkQhAJAIQiQBEIgCRCEAkAhCJAEQiAJEIQCQCEIkARCIAkQhAJAIQiQBEIgCRCEAkAhCJ AEQiAJEIQCQCEIkARCIAkQhAJAIQiQBEIgCRCEAkAhCJAEQiAJEIQCQCEIkARCIAkQhAJAIQiQBE IgCRCEAkAhCJAEQiAJEIQCQCEIkARCIAkQhAJAIQiQBEIgCRCEAk8uUZJV+fWCITB60YWovJzCHT ZUL5BDSyHbP7uIAfL0qXmQZXeeIA8NikAB9Dk6Dh0gyM9OdjafIBOkg3wgG9yIOcQmqNWCNbIpcq iy4pmWOuWAAWh0VDEQ3G4uF/6hKTJakwYmd0sbH8pa7GvdrLn9gAyXnPVnQ8sa29VJQ+SoNMp4uQ 6fiHIhoOcCgOjdhKc/Nlwu2W7wKf3xlPcr/WFNBhnWJ4mqQ6H20qnS2qaBsdszA2PDQsXl4tUF2e Z2JiJD85PDA2Oi46JF7eNjo2ZhxPjpT9/Mfi32+JjvWPD4+O4imQY6jtNFHJb9vdo6Pj5a3nx4dF x4bHLyTlJLgmRiSPR5JGJPw3Q4KrS/J09XjDi39DjdKB4shuod5UlQ5lBa5n4ekAYHvwusaY3816 XGTUtm1cMIt8WrInR2X2+8ENzqXVg1tK5C2TppT8UpLrpzun3SZoYff+hBbPjp5nhdmyudsyQyrP zFkUoHR1tHmnIFj3OP90vXZIQUGY6uZLplr1nMPTVBsdHrEsjfO19qiZ7H4+McPmfqZgbUHkVP/9 6UnFftqJzk82VwWZFbjJ8pjKYtv2PFqrKfm7xaZAMb9pjOBto43cl/btepmHN8n8Wj/VvnJ5ar3p c888l/JPuxbNjXepkGzNF1BTwLzX+IUb1U4S4Tf3Gpo5sD2Exdx5Oc3L++URs1mj0hLpHe9OlKdu GDxwIeXqLulYH/Nzx18xSxXJSr6slkr5RNGsOzgNDvzStN1k2g4yrQT25mhATysg0zamCs28FPMy PHar0pRksUOTVw+dL479v/df+l+McRrlww2P2Q05vRslDV7UAOXricK9Pn6627ayz1sy1i7LbTH9 XaHnlfd6rcNFE5oDXn681mpmNmOPoWf4oPJcq5bWvZ2MpNu8HIttQjERtYMirpLhDR8v2d4XniHv +jRgccVeqWZNIxXtE8HFIitUBANL+zxl+xVaror3uu+PstXl/5Qu8f5haCR3yru61+5n6x6dJj/K 8wSWjd6gLj35ymh8x+vULlrVzDcHbzd7dwdPPOvueaSKpiYytObqK2Zucs3GM/uMtB4serA78X5C EXYpwqrxsuGKLmuR3QYRMhE3De7+Jkt/sNue3jxDzzhqsiw3oJpVsurXK55WDhdkp+6MuSliunT9 /G27LhdBVfAj02nOn1WBNW6f8C23IZ8t5xu+aMrov0sM4HFvrAv/QQXQhWLA04WLBl/EYCFSULgT PlF8qgdPlBSmFpiiLG//uLDwqNB4+DVCJEGt5Bfldw8OmhsdFfSlYqw/q5gSqfC5YtIjtwcFy3uE h0bBvcq72Vr/pSpUL1xy1bfS3mS3/n5eR7+KwcTEhoExW8/az3vZ7vD4t1Wn5ji7B7zZjJ+afH1i pI6yZXD9RaVqtmN1yvzb9nV7cwm3MyqaPUWPuEpj2q2VPwRsbpOy37HeaczmC5U6iqectJOib4jL ma0yETK5Xaf+JsRMG+gODY513Hk4EiwtHDh2KDAlvd+nKC0za/WBnpq80jbjnW5ZEmOXutwm32EW b5r6LdJOZL+INNk1Tv9d1bgK1pKAtQtCCjfFcbMrek73yh91FckJPK91Q9deqrvWKd/MzUPyYsiU hXvLljZ7WW5Ld1sWxTho0LhYuc49xGKzS6tmsl5U5gS+9q2XnLLxqGxse8PSOx7DqvCBTOsjRSlR UKFzSBYfE05oDAY/jfb/QyoEqTqKUq+dZJA0aMjR1AqCPoou1jr6YgIWM7Pidcdpl4IpduNK7QJf kWxqsyCdDg+j7BGHDtKYxfvKk51Uey4ed4kvmTY2XmN+Zfanfc55C7DJT849k7wVfoYoSerFbZvO LW1979F6cludV/SrQLs9dlh3fnPBFdka9jYpbt61Drky9SUvX+yM25/babLaYlPEceO5l5dVKH26 8+RquMDaZXWDd7Fa/d6+pH4hkXGMZ+r5623mqM2rNs7t4ue2+IZdqEu1nhOyu7a6drX+uR6aUNKi t5e7bO4sHrx7d//guztXuJUxV9fddz1iXJKk/ZvFTX12gBG+LS1Cafk7n8DcAzNqTa75rZqaKa33 1mxTUTqnZPbKSq3q4h3n93XIH6knpbLkxbgax93fWHfNIu+vUwtf2hhzr3fXvoupNrEJBNSYCKgx 7sMa4y+4YDIiJNrI44gBdeZvPKq/CI4eSULF0YOCQ5qQutSiHrVIxv9bqja8nfYn2/9Sa0pusnLa TjZO/OXCXlP9MqXpc25GnlBQrM5rflpe33RF9aSu8MrjHb5aA4ZecuKa5bnc22KlUWrOKaOsrPfn jD/osIx7Iy2vbCPfJW+7BJ+nrz8S91LiS/XOxz98ed+/OJlWbT90xVLkyoFzs7iXFvdUi3I/+kWo Zc1fVV12POuxRNWaE29HHQnwfSF8x7RbYebKitS4U/b3NyxP9PvlUVlio1GOnpiO6M2AlnLpPa6b Qst+kzch53XlhDrca5J9w3WLt9Z5zFCOUJgz8cC604dMztrsmOsj6bQv99rqDMsFrAnXtx/KVDp1 r2dxyEGn+DpV60mF/mJ+LmRzeu8ldkxS99TJiZeZUxPShrXmPZn2FvX9aEHqiIUHIV/DiAO2V2H8 6qQp7z0nbXoocS0iQ58xTvXxz6WJ0onRSnRJclTqzw9zO+oPxtAtSDPSpMioyCBbLyw+PsZURycw NnLc3C8+HBcYPVcnZk44tVYnJjY6aH5gfJyOrQccaOPgKtLxy1dCDjEnTUnjL8sknq01vMPExMSf 7TA4dsSe4n84gJDajPeO9gjdKp+hD4jfJSaZlz27npbSzV0Yn+i6cYJkLyYennwzYE3Jp9Diwgdq 6h+mXts86FY/S6Dy6M4X6b2b5KKnf3j7+i7n15VMy1ES8u0Nh+0nMFX9vAUm5b1ith6bHPXqnqOI msFKhdg7s49UhIso53U/0Re4mRwVvY7lfk7DeeJeXa3sx8WtvqrHj5t3zTyUwT5mIOuaaT9hqDav eDr/nvzbC+q8U3bscmntKSsssL533kfZ8laK/gSXd23Ni7c8O9JSGCjmUVFW8PJafVtR8b4N5xZp LtVqOHvjYySto9647HW7j5SEYEPfudSdQkzp22uUHh0odrZ8ekBYdQHRqHV0+5yzueZQbbZAtcn6 ojYTk14gtWH8fWrjGT43OC7ef27MSLUxJE14hiTPwEAX4Q0PLeqS1CKZtvPfUrexpMrniVIuyjY8 Jiw4Vt7Ow17e3sPFlEfaGWsbGOsbadvaOBh/+UOaqNyfNMIjODYhPDD4LwXq6TFGYPONheWZdpY7 Kk+/cN6qfMckQU7gqq7TtAWXNW/s4F/z8pHFQJ1qUunAwyXJum03LFaaGPW8v26mP+q3dekD+s/D smKlc7tqnLtqsnr1WHhjSUKcgbPv6+q7TktG1+QtuDkklyVu4zDvYspYb5H2DFeztg+d71a+sMLu X+n075fImbQ9zfxt+Pind5fX87sei1/8hPNwwtN9ka+vhKYx3486t0S0Nu6egPOHgIEXRSYFpoPP hJv95QKmXWd5ZlwxmzTp3tQ6HT/p1esYth2+z9JZShsFihi84JXrXeSsFUrWrflkb2cfbXDQ3qgs fE9wv77tQYmTZiZ3hVb1SC+97+k2xmwLr2ykQH0TpOTYV+OsvNS7VPrCasDHSXeT2+5bfqc90Y9d rDYe1d83KTv3eOHT/WbWtk2X/lfaEx8XE+j/L9GeL3uK/5mCMv+gwj8RqPBF6QKcUe2dbQ7Lx9W3 6y9KSxmrZq3R+6vCOmJj2WyPWer9Lxo9nXYv6RO9xBbrn9yTLY5F3c8YrWa/S8tE93Z0gdGMbiX3 XE9ajtWuwiDjd4bNYrZHTC03tXBPzUtT6w3Zxbvn45vb7+5+1+fZ+jVbwgWcl7e3JzjrcyPuJtnt 0pyZ4ZliryylcnqFwxmV+1Kp4epi7ySaXilqpTnM0nzTv7Mp0VIpun9nUNbqkgDuHm253Q/XWKYM HVj9cePz15/oFRcmXpwRv/9Dr+gYGZOLpVVXj7+p6m4u6/GSGzB/3XxVw+54faHVkhDJC4fkA1nn xlsE60olHaqxaFR1dFGU2hy1imx8vfZ7gRKKYG92bcBU9gnftB8zbVFoyY8y9fcEX8PqROrrG1Hq ZAIX/4bg6w/C+Vd6c8soaqCi2cZpnmTzRUdLj4YP+8SOaenWiri6N2e8sNS7MZG3Tu3I2qCuMW6Z x05Oak9hvH85/8TKs7uvlIfHhCwYG/L4SPXLrKMXuvd+EtnOnq6ortM2/oYXXSbh8NyguU6eN2+/ 7qzflnE29U6KM26U97ZhK9NLLmzChRsNCT46S46o0Ku8ZkbIBg6lJpl3X6GrTDZJjOf3PelzPdtI a34L8VTORCApYXBLZNSirueWuRu3ziNma7hKBvjpbr2c4aKp6BNmv7JTJ1PI7VD/YemcyG6VX0Tf nxe6lkW8SU+IM2zasKik1Y/vOeNAtl71+7yZmdaZ07Lyog6M0XJsjS607Yp4nKK6es5nvUkHarBH lH9+hP6/CL+E+ASGT4CKAyqmwkao50/FUerrB8RwOkeOhXlg87EAzBaz/j40+0Nc9xOBypsszDuZ 5FYrvLrYnx8Qq2Lsc17GedZZCTC0h2qmeGTJvjBZW13qxe5cdcRMpn1g/66W6oNTFGSimeHJc2gl ig4vIqvmJinWOPya2ZsjeIJ/hWHjs+QnMb7229Zdbr14e3XD3XqNC0nPW8p1ryw9ej7wtGG7pEJ9 QqdZQaVM3FaFZderqkQ8V70pPBnsVKCmWui3QtDsrGjwAsfatrIMU9cDAdM6ySdPTEbfX97TYZLW L6qwKig1kI+e31OA2+osdlh2bAi/Edzv1NlBi19fyYjitG65peaf5PhaolBYwRiXXbqf70y+bs3D 8U0eFnV7lnc+DjHKeaOYX9h6INFziunVWLtDSu946fQKKFL7cADItKV/Y1T2Xaz47Rx3UVoHKfbV 32qAx09joLuXqVEw7EwBGo8z8rQ6rM23JTaPIEduFSeVvn2QzoNjrC/XiT9t0trOw8wCtwPL6z+p ua49TAaN+AiH50V6FmmkqmGTsXAsEIvFotGZ+RAsHpPHPLGFWAxcCoXr/WEpDFtYrJqq/KfTa/zC mOjQWP+YsIXyP8gbPR1g8vW/10yXwkzFCqSXTb7Yu+FA4frxJU8JPW96t3Gcw8ePB8s3v+wi7yev ePvsDW3x2ys+/W/jt6Syoyo7ynVoUfSYp7Sr7ySWazdkbjDa0WaZ6etNLGy5LnW9/pPeyq23KuVL qh2eHU3e9qKiwbLpab3dnXbr4++fiEmtmPR6PbBvm63HWZlSvqrUNqf5o8tQYNm6Uxd4Y6fGVflV r6X3tXATyh0XlOMFqefK1+obqjb9HsQpWo23zB2zpDzZy+D0r6JJh2wUN2xuW+QSk1BarnlG8dGi uGu+RbnFL71debimUILdhzwH2YA80cW5SQ8ylbpKf3Exojc5h+x9vKNjxzSlJcvJ9jFixen4GDId l/nmIz5eOs6Bq5j/50P0xxnpuwCDf3iIFvmSkiNHIvvbVSAAv/PrFgZPEE61xjxSF060uiZ6BjP+ MBDxIWXizhH/HN9xs8ll9tJvK7qev/9Bs6ghcmfjKSem9p2aFpmdNxQYZznPQ7KVh2zwNttXdc3F 8gn5947fXb9aZPw9VY2SnWtX+q+S7G/VOOgmvfT94rVPPc6Mf1yr7Zt70W5dUJSXn4oN+2w2nmrd rbh58RndRW7dkcsefDCUeNu0cl3AaM+C3x6KihRf3VLeN+RtSpvw5Er3tN4QS+vQSbOqT9TdyNJ+ 4F3TvHZfwLwIq12izJNtmq3zOzevWLggJqPMoeBkZcZylwmmmhkeCrq7B5+etYpPwBvK98Z6+NaE nU1+xrMIKxib2lvFd+DRrzXCWumXI+sr7sw79DgjYPcRkEB2EOM9Ds1k9PZVGQYxPBTEV4Y6RAlF zJ0u6h5VxcX+C11w3RMNCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMzMgMCBvYmoNClsgMjc4IDAgMCAw IDAgMCAwIDAgMCAwIDAgNTg0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCA3MjIgNzIyIDY2NyAwIDc3OCAwIDI3OCAwIDAgMCA4MzMgMCA3NzggNjY3IDAgMCAw IDAgNzIyIDY2NyA5NDQgNjY3IDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDUwMCAwIDU1NiAwIDU1 NiAwIDIyMiAwIDAgMjIyIDgzMyA1NTYgNTU2IDAgMCAzMzMgNTAwIDI3OCAwIDUwMCA3MjIgNTAw XSANCmVuZG9iag0KMjM0IDAgb2JqDQo8PC9UeXBlL1hSZWYvU2l6ZSAyMzQvV1sgMSA0IDJdIC9S b290IDEgMCBSL0luZm8gMTY4IDAgUi9JRFs8MTg3REQ0ODhCNzQzQzI0Rjk3MzcyNUFGNTM4OEFF MEM+PDE4N0RENDg4Qjc0M0MyNEY5NzM3MjVBRjUzODhBRTBDPl0gL0ZpbHRlci9GbGF0ZURlY29k ZS9MZW5ndGggNjEwPj4NCnN0cmVhbQ0KeJw11FlQTnEYx/HT8pa9RSntIltlVxpjGOPCMMauaNEi SpaUIsZQkVYV2VIkLWjRJiqpMZZxwxjblXHFDIMxlitM3n5fzsX7mTPznv//eZ7/7xzDMF8DAxbm XwfDGKQYHgnTgNgQBkVwT4QmibBw+C02vhGbVsNXER4vIqwhQ0S6AmtGBUCV2LxQRK8XMUuhV8RG wDMRlyy25In412LrcvgotkXBH5GQIhLpNjFHbPeDcpEUAk1iB4vtjBG71sFjsTsBaDqZxvaUihQT 1IhUW6gTe/tEGoNMZ/f0+2LfW7H/l8ig+AyKP+gIn8UhK+CMDruIIz6QLTJ9RdYCkX1GHG0ROTaw GGrF8SXwQuQGA3PJpYi8aGDb/FjgroD0FHwThZxf4W1R5A5d4oQHdIviZcDIS+whFV6J0jRxskSc ei7KguClOP1DnI0U5w6I8xxVeSA8ERfigJRX+APFV3wXlWXiIsO65AQdoordLxPvajJR/VNcyYcv omYNdIpaN+gRdd7QL+oZVj3jueoJmfBOXDsGH8R1Mt/gBVnwXjQyz8Zm0bQS2kUz5Tazyo0V0Cpa nIEkt1Ju61ooBJpuI+XtDaLDDhjWzaei85O4tQp4rovUddNfD+fXQ8DuzBe9oeIub2oftfQxs/5F hmFp/jy1GUEQDPNgLvz7S8jgA5X/7yzAEqzAGkxgA7YwBIbCMBgOI2AkjAI7sAcHcITR4ATOMAZc wBXGghu4gwd4ghd4gw+MA18YDxPADybCJJgMU2Aq+EMABMI0mA4zYCbMgtkwxzzyB2Tiob7Xlk7m YP4F2HXqIQ0KZW5kc3RyZWFtDQplbmRvYmoNCnhyZWYNCjAgMjM1DQowMDAwMDAwMTcyIDY1NTM1 IGYNCjAwMDAwMDAwMTcgMDAwMDAgbg0KMDAwMDAwMDE0MyAwMDAwMCBuDQowMDAwMDAwMTk5IDAw MDAwIG4NCjAwMDAwMDE1MzUgMDAwMDAgbg0KMDAwMDAyMjEwNCAwMDAwMCBuDQowMDAwMDIyMTU3 IDAwMDAwIG4NCjAwMDAwMjIyMTAgMDAwMDAgbg0KMDAwMDAyMjM3OSAwMDAwMCBuDQowMDAwMDIy NjE5IDAwMDAwIG4NCjAwMDAwMjI3ODAgMDAwMDAgbg0KMDAwMDAyMzAwNSAwMDAwMCBuDQowMDAw MDIzMTIxIDAwMDAwIG4NCjAwMDAwMjMyODAgMDAwMDAgbg0KMDAwMDAyMzM5NyAwMDAwMCBuDQow MDAwMDIzNTU2IDAwMDAwIG4NCjAwMDAwMjM2NzMgMDAwMDAgbg0KMDAwMDAyMzgzMiAwMDAwMCBu DQowMDAwMDIzOTQ5IDAwMDAwIG4NCjAwMDAwMjQxMDggMDAwMDAgbg0KMDAwMDAyNDIyNCAwMDAw MCBuDQowMDAwMDI0MzgzIDAwMDAwIG4NCjAwMDAwMjQ2NjEgMDAwMDAgbg0KMDAwMDAyNDkwNCAw MDAwMCBuDQowMDAwMDI1MDIxIDAwMDAwIG4NCjAwMDAwMjUxODAgMDAwMDAgbg0KMDAwMDAyNTI5 NyAwMDAwMCBuDQowMDAwMDI1NDU2IDAwMDAwIG4NCjAwMDAwMjU3MzcgMDAwMDAgbg0KMDAwMDAy NjA3MSAwMDAwMCBuDQowMDAwMDI2MTg3IDAwMDAwIG4NCjAwMDAwMjYzNDYgMDAwMDAgbg0KMDAw MDAyNjQ2MiAwMDAwMCBuDQowMDAwMDI2NjIxIDAwMDAwIG4NCjAwMDAwMjY3MzggMDAwMDAgbg0K MDAwMDAyNjg5NyAwMDAwMCBuDQowMDAwMDI3MDE0IDAwMDAwIG4NCjAwMDAwMjcxNzMgMDAwMDAg bg0KMDAwMDAyNzI5MCAwMDAwMCBuDQowMDAwMDI3NDQ5IDAwMDAwIG4NCjAwMDAwMjc1NjUgMDAw MDAgbg0KMDAwMDAyNzcyMyAwMDAwMCBuDQowMDAwMDI4MDAxIDAwMDAwIG4NCjAwMDAwMjgyNDQg MDAwMDAgbg0KMDAwMDAyODM2MSAwMDAwMCBuDQowMDAwMDI4NTIwIDAwMDAwIG4NCjAwMDAwMjg2 MzcgMDAwMDAgbg0KMDAwMDAyODc5MyAwMDAwMCBuDQowMDAwMDI5MDczIDAwMDAwIG4NCjAwMDAw MjkxODkgMDAwMDAgbg0KMDAwMDAyOTM0OCAwMDAwMCBuDQowMDAwMDI5NDQ3IDAwMDAwIG4NCjAw MDAwMjk2MDYgMDAwMDAgbg0KMDAwMDAyOTg4NyAwMDAwMCBuDQowMDAwMDMwMTQ2IDAwMDAwIG4N CjAwMDAwMzAyNDUgMDAwMDAgbg0KMDAwMDAzMDQwNCAwMDAwMCBuDQowMDAwMDMwNjg3IDAwMDAw IG4NCjAwMDAwMzA5NzEgMDAwMDAgbg0KMDAwMDAzMTA3MCAwMDAwMCBuDQowMDAwMDMxMjI5IDAw MDAwIG4NCjAwMDAwMzE1MDYgMDAwMDAgbg0KMDAwMDAzMTcyNSAwMDAwMCBuDQowMDAwMDMyMDAz IDAwMDAwIG4NCjAwMDAwMzIyNTUgMDAwMDAgbg0KMDAwMDAzMjUzNSAwMDAwMCBuDQowMDAwMDMy ODAwIDAwMDAwIG4NCjAwMDAwMzI4OTkgMDAwMDAgbg0KMDAwMDAzMzA1OCAwMDAwMCBuDQowMDAw MDMzMzQxIDAwMDAwIG4NCjAwMDAwMzM2ODYgMDAwMDAgbg0KMDAwMDAzMzk2OCAwMDAwMCBuDQow MDAwMDM0MzEwIDAwMDAwIG4NCjAwMDAwMzQzNzAgMDAwMDAgbg0KMDAwMDAzNDQ2OSAwMDAwMCBu DQowMDAwMDM0NjI4IDAwMDAwIG4NCjAwMDAwMzQ3NzIgMDAwMDAgbg0KMDAwMDAzNDg3MSAwMDAw MCBuDQowMDAwMDM0OTcwIDAwMDAwIG4NCjAwMDAwMzUwNjkgMDAwMDAgbg0KMDAwMDAzNTE2OCAw MDAwMCBuDQowMDAwMDM1MzI3IDAwMDAwIG4NCjAwMDAwMzU0MjYgMDAwMDAgbg0KMDAwMDAzNTU4 MyAwMDAwMCBuDQowMDAwMDM1NzI3IDAwMDAwIG4NCjAwMDAwMzU4MjYgMDAwMDAgbg0KMDAwMDAz NTkyNSAwMDAwMCBuDQowMDAwMDM2MDI0IDAwMDAwIG4NCjAwMDAwMzYxMjMgMDAwMDAgbg0KMDAw MDAzNjI4MSAwMDAwMCBuDQowMDAwMDM2MzgwIDAwMDAwIG4NCjAwMDAwMzY1MzggMDAwMDAgbg0K MDAwMDAzNjY4MiAwMDAwMCBuDQowMDAwMDM2NzgxIDAwMDAwIG4NCjAwMDAwMzY4ODAgMDAwMDAg bg0KMDAwMDAzNjk3OSAwMDAwMCBuDQowMDAwMDM3MDc4IDAwMDAwIG4NCjAwMDAwMzcyMzcgMDAw MDAgbg0KMDAwMDAzNzUyMCAwMDAwMCBuDQowMDAwMDM3ODQzIDAwMDAwIG4NCjAwMDAwMzc5NDIg MDAwMDAgbg0KMDAwMDAzODEwMSAwMDAwMCBuDQowMDAwMDM4Mzg4IDAwMDAwIG4NCjAwMDAwMzg3 NDkgMDAwMDAgbg0KMDAwMDAzOTAzNCAwMDAwMCBuDQowMDAwMDM5MzY5IDAwMDAwIG4NCjAwMDAw Mzk0NjkgMDAwMDAgbg0KMDAwMDAzOTYzMCAwMDAwMCBuDQowMDAwMDM5Nzc5IDAwMDAwIG4NCjAw MDAwMzk4NzkgMDAwMDAgbg0KMDAwMDAzOTk3OSAwMDAwMCBuDQowMDAwMDQwMDc5IDAwMDAwIG4N CjAwMDAwNDAxNzkgMDAwMDAgbg0KMDAwMDA0MDM0MCAwMDAwMCBuDQowMDAwMDQwNjI0IDAwMDAw IG4NCjAwMDAwNDA3MjQgMDAwMDAgbg0KMDAwMDA0MDg4NCAwMDAwMCBuDQowMDAwMDQxMTcxIDAw MDAwIG4NCjAwMDAwNDE0NTYgMDAwMDAgbg0KMDAwMDA0MTU1NiAwMDAwMCBuDQowMDAwMDQxNzE3 IDAwMDAwIG4NCjAwMDAwNDE4NjYgMDAwMDAgbg0KMDAwMDA0MTk2NiAwMDAwMCBuDQowMDAwMDQy MDY2IDAwMDAwIG4NCjAwMDAwNDIxNjYgMDAwMDAgbg0KMDAwMDA0MjI2NiAwMDAwMCBuDQowMDAw MDQyNDI3IDAwMDAwIG4NCjAwMDAwNDI1MjcgMDAwMDAgbg0KMDAwMDA0MjY4OCAwMDAwMCBuDQow MDAwMDQyODM3IDAwMDAwIG4NCjAwMDAwNDI5MzcgMDAwMDAgbg0KMDAwMDA0MzAzNyAwMDAwMCBu DQowMDAwMDQzMTM3IDAwMDAwIG4NCjAwMDAwNDMyMzcgMDAwMDAgbg0KMDAwMDA0MzM5NyAwMDAw MCBuDQowMDAwMDQzNDk3IDAwMDAwIG4NCjAwMDAwNDM2NTcgMDAwMDAgbg0KMDAwMDA0MzgwNiAw MDAwMCBuDQowMDAwMDQzOTA2IDAwMDAwIG4NCjAwMDAwNDQwMDYgMDAwMDAgbg0KMDAwMDA0NDEw NiAwMDAwMCBuDQowMDAwMDQ0MjA2IDAwMDAwIG4NCjAwMDAwNDQzNjcgMDAwMDAgbg0KMDAwMDA0 NDQ2NyAwMDAwMCBuDQowMDAwMDQ0NjI4IDAwMDAwIG4NCjAwMDAwNDQ3NzcgMDAwMDAgbg0KMDAw MDA0NDg3NyAwMDAwMCBuDQowMDAwMDQ0OTc3IDAwMDAwIG4NCjAwMDAwNDUwNzcgMDAwMDAgbg0K MDAwMDA0NTE3NyAwMDAwMCBuDQowMDAwMDQ1MzM4IDAwMDAwIG4NCjAwMDAwNDUzOTUgMDAwMDAg bg0KMDAwMDA0NTQ1MiAwMDAwMCBuDQowMDAwMDQ1NTUyIDAwMDAwIG4NCjAwMDAwNDU3MTMgMDAw MDAgbg0KMDAwMDA0NTk5NSAwMDAwMCBuDQowMDAwMDQ2MDk1IDAwMDAwIG4NCjAwMDAwNDYyNTYg MDAwMDAgbg0KMDAwMDA0NjU0MyAwMDAwMCBuDQowMDAwMDQ2ODI4IDAwMDAwIG4NCjAwMDAwNDY5 MjggMDAwMDAgbg0KMDAwMDA0NzA4OCAwMDAwMCBuDQowMDAwMDQ3MzY2IDAwMDAwIG4NCjAwMDAw NDc2NDUgMDAwMDAgbg0KMDAwMDA0NzkyNiAwMDAwMCBuDQowMDAwMDQ4MDI2IDAwMDAwIG4NCjAw MDAwNDgxODcgMDAwMDAgbg0KMDAwMDA0ODQ3MSAwMDAwMCBuDQowMDAwMDQ4NzU0IDAwMDAwIG4N CjAwMDAwNDkwMTcgMDAwMDAgbg0KMDAwMDA0OTA4MyAwMDAwMCBuDQowMDAwMDQ5MjE2IDAwMDAw IG4NCjAwMDAwMDAxNzMgNjU1MzUgZg0KMDAwMDAwMDE3NCA2NTUzNSBmDQowMDAwMDAwMTc1IDY1 NTM1IGYNCjAwMDAwMDAxNzYgNjU1MzUgZg0KMDAwMDAwMDE3NyA2NTUzNSBmDQowMDAwMDAwMTc4 IDY1NTM1IGYNCjAwMDAwMDAxNzkgNjU1MzUgZg0KMDAwMDAwMDE4MCA2NTUzNSBmDQowMDAwMDAw MTgxIDY1NTM1IGYNCjAwMDAwMDAxODIgNjU1MzUgZg0KMDAwMDAwMDE4MyA2NTUzNSBmDQowMDAw MDAwMTg0IDY1NTM1IGYNCjAwMDAwMDAxODUgNjU1MzUgZg0KMDAwMDAwMDE4NiA2NTUzNSBmDQow MDAwMDAwMTg3IDY1NTM1IGYNCjAwMDAwMDAxODggNjU1MzUgZg0KMDAwMDAwMDE4OSA2NTUzNSBm DQowMDAwMDAwMTkwIDY1NTM1IGYNCjAwMDAwMDAxOTEgNjU1MzUgZg0KMDAwMDAwMDE5MiA2NTUz NSBmDQowMDAwMDAwMTkzIDY1NTM1IGYNCjAwMDAwMDAxOTQgNjU1MzUgZg0KMDAwMDAwMDE5NSA2 NTUzNSBmDQowMDAwMDAwMTk2IDY1NTM1IGYNCjAwMDAwMDAxOTcgNjU1MzUgZg0KMDAwMDAwMDE5 OCA2NTUzNSBmDQowMDAwMDAwMTk5IDY1NTM1IGYNCjAwMDAwMDAyMDAgNjU1MzUgZg0KMDAwMDAw MDIwMSA2NTUzNSBmDQowMDAwMDAwMjAyIDY1NTM1IGYNCjAwMDAwMDAyMDMgNjU1MzUgZg0KMDAw MDAwMDIwNCA2NTUzNSBmDQowMDAwMDAwMjA1IDY1NTM1IGYNCjAwMDAwMDAyMDYgNjU1MzUgZg0K MDAwMDAwMDIwNyA2NTUzNSBmDQowMDAwMDAwMjA4IDY1NTM1IGYNCjAwMDAwMDAyMDkgNjU1MzUg Zg0KMDAwMDAwMDIxMCA2NTUzNSBmDQowMDAwMDAwMjExIDY1NTM1IGYNCjAwMDAwMDAyMTIgNjU1 MzUgZg0KMDAwMDAwMDIxMyA2NTUzNSBmDQowMDAwMDAwMjE0IDY1NTM1IGYNCjAwMDAwMDAyMTUg NjU1MzUgZg0KMDAwMDAwMDIxNiA2NTUzNSBmDQowMDAwMDAwMjE3IDY1NTM1IGYNCjAwMDAwMDAy MTggNjU1MzUgZg0KMDAwMDAwMDIxOSA2NTUzNSBmDQowMDAwMDAwMjIwIDY1NTM1IGYNCjAwMDAw MDAyMjEgNjU1MzUgZg0KMDAwMDAwMDIyMiA2NTUzNSBmDQowMDAwMDAwMjIzIDY1NTM1IGYNCjAw MDAwMDAyMjQgNjU1MzUgZg0KMDAwMDAwMDIyNSA2NTUzNSBmDQowMDAwMDAwMjI2IDY1NTM1IGYN CjAwMDAwMDAyMjcgNjU1MzUgZg0KMDAwMDAwMDIyOCA2NTUzNSBmDQowMDAwMDAwMjI5IDY1NTM1 IGYNCjAwMDAwMDAyMzAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDUwNjAzIDAw MDAwIG4NCjAwMDAwNTA4NzcgMDAwMDAgbg0KMDAwMDEzNjMyMiAwMDAwMCBuDQowMDAwMTM2NTg0 IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgMjM1L1Jvb3QgMSAwIFIvSW5mbyAxNjggMCBSL0lE WzwxODdERDQ4OEI3NDNDMjRGOTczNzI1QUY1Mzg4QUUwQz48MTg3REQ0ODhCNzQzQzI0Rjk3Mzcy NUFGNTM4OEFFMEM+XSA+Pg0Kc3RhcnR4cmVmDQoxMzczOTgNCiUlRU9GDQp4cmVmDQowIDANCnRy YWlsZXINCjw8L1NpemUgMjM1L1Jvb3QgMSAwIFIvSW5mbyAxNjggMCBSL0lEWzwxODdERDQ4OEI3 NDNDMjRGOTczNzI1QUY1Mzg4QUUwQz48MTg3REQ0ODhCNzQzQzI0Rjk3MzcyNUFGNTM4OEFFMEM+ XSAvUHJldiAxMzczOTgvWFJlZlN0bSAxMzY1ODQ+Pg0Kc3RhcnR4cmVmDQoxNDIyNTkNCiUlRU9G ------=_NextPart_000_000C_01CD131F.3C4DFBB0-- From Ruediger.Geib@telekom.de Thu Apr 5 03:22:52 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9385021F86C1 for ; Thu, 5 Apr 2012 03:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+f1pm2wExVG for ; Thu, 5 Apr 2012 03:22:51 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 710CB21F86A8 for ; Thu, 5 Apr 2012 03:22:50 -0700 (PDT) Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 05 Apr 2012 12:22:49 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 5 Apr 2012 12:22:48 +0200 From: To: Date: Thu, 5 Apr 2012 12:22:47 +0200 Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYlnLYVxCAAAjaIA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> In-Reply-To: <000b01cd130e$78c48f70$6a4dae50$@unizar.es> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 10:22:52 -0000 Jose, regarding QoS, I'm happy to agree on 4 standard classes with properties as mentioned in my last email. If there's consensus on some codepoints for the= m, I'll support that. If IETF recommends how and which applications to use these classes/codepoin= ts, that's again agreeable. I don't think, that by now requiring a specific application to carry a specific DSCP makes sense, apart from few exceptions (like VoIP payload, network management traffic or Best Effort traffic). IETF needs consensus to do that. Note that the number of AF classes and codepoints are troublesome. Too many with too little explanation how to use them, nothing is aligned with user demand. EF/VoIP payload and network management are examples how to proceed: just specify what's required, no extras. Then regarding tunnels and header compression Yes, that's smart and there may be more use cases than gaming. I'm a backbo= ne engineer however and your proposal is rather application specific. What I can do is ask some colleagues on their view. But there's no guarantee, that they will respond. Some initial thoughts: To me a key point seems to be what can be reached at the bottleneck. There = the compression should save bandwidth with little cost and no negative service impact. Any kind of shared access from which traffic is transmitted to the same destination seems to be relevant. The application/tunnel awaren= ess of network elements may not be feasible, a network terminal at a UNI may be ab= le to handle that, or any service specific device in a network. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 11:29 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), an= d after talking to James, I thought that the idea of standardizing the traffi= c classification fits well with my proposal. I would like to know your opinio= n about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the waiting time in the multiplexer. So another use is to provide flexibility: if you are a game provider, you may over provision your network in order to be abl= e to manage traffic peaks. But perhaps using this, you may be able to have a smaller network, and use compression when necessary (rush hour, first days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct priority= . I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-Wa= r craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find the history of the problems of World of Warcraft for Virgin Media users. Th= e problem was caused by a modification in the traffic, and the provider did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe tha= t some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ QoS (sub)classes, I think. But one class optimised to transport "UDP" and one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be useful). My take would be to standardise four classes/properties (in brackets exampl= e usage): a) for traffic which doesn't support re-transmits, requiring lowest delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using TCP= , like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward for a= ) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, this may depend on the implemented application transport. Further details may be discussed. Everything else could be reserved, but shouldn't be recommended. Carriers have deployed differing schemes on codepoints and classes. They need coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and applications with codepoints as a requirement and I also object to standards leaving no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP precedence). Bob Briscoe mentioned the difference between classes and queues and above properties can be mapped to queues. If end to end QoS is desired, the same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of gettin= g end to end QoS. I don't support an approach requiring 8 three bit classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I find i= t interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online games are at least as real-time as VoIP is. In most cases, the gamers are a very difficult people to deal with. If the latency is high, they leave and never return (this statement is not mine, it can be corroborated in the reference= s I put below). This has been studied by many research groups, with empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the authors proposed the use of an adaptation of RTP in order to manage gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. World of Warcraft: They normally use TCP, even though some of them use UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP o= r UDP - Sports games: Since there is a big variety, they have not been deeply studied in the literature Some research papers supporting this classification, and also the real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf - In this paper from my research group, 8 FPS games were analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP (packet= s of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It is only based on delay and jitter, since packet loss has vevy little influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana From jsaldana@unizar.es Thu Apr 5 05:14:17 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE29721F861B for ; Thu, 5 Apr 2012 05:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+L+CUCAUr7L for ; Thu, 5 Apr 2012 05:14:15 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7621E21F879F for ; Thu, 5 Apr 2012 05:14:14 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q35CE2G3016944; Thu, 5 Apr 2012 14:14:03 +0200 From: "Jose Saldana" To: Subject: About the tunnels: packets per second savings Date: Thu, 5 Apr 2012 14:14:07 +0200 Message-ID: <000601cd1325$9a1afcb0$ce50f610$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CD1336.5DA49000" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0TI3xcOH/LIhs8T4KaC7euy7785Q== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 12:14:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0007_01CD1336.5DA49000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ruediger, Thank you for your fast response. I will separately answer the two = parts of your email. First, this message about the tunnels. This afternoon or tomorrow I will send to the list an idea about QoS classes, but I have = to think more before sending it. I'm glad to hear that you consider the "tunnels" proposal interesting. = There is another issue that I discussed with Gorry in Paris: the saving in = terms of packets per second. I attach a graph of the saving in terms of this parameter using Counter Strike. If you multiplex all the packets you = have received e.g. every 20ms, then you will send 50 pps (the inverse of the multiplexing period). So you can save a lot of pps. It is clear that bandwidth saving is interesting, but I have read some papers in which a "packets per second" upper bound in the routers was reported: Section V.A of W. Feng, F. Chang, W. Feng, J. Walpole: =93A Traffic Characterization of Popular On-Line Games=94. IEEE/ACM Trans. Netw., pp. 488-500, 2005. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf Section IV.3 of J. Yu, I. Al-Ajarmeh. =93Call Admission Control and Traffic Engineering = of VoIP=94, In Proc. Second Intenational Conference on Digital Telecommunications, IEEE ICDT 2007. http://140.192.40.4:8001/~imad/voip/YuJ-CallAdmin.pdf They not only talk about the bandwidth limitation of routers, but also = the packets per second limit. Gorry told me that high-end routers may not = have this problem. But low-end routers are not able to back-to-back send = small packets, due to the processing limitation. So, do you think this saving is interesting? Since you work in the = backbone, your opinion is important for me, taking into account that I am an = Academia researcher, and sometimes we are a little far from real things. Perhaps = you may ask some of your colleagues. Thanks, Jose=20 -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Enviado el: jueves, 05 de abril de 2012 12:23 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, (...) I have removed the first part of the message for clarity. Then regarding tunnels and header compression Yes, that's smart and = there may be more use cases than gaming. I'm a backbone engineer however and = your proposal is rather application specific. What I can do is ask some colleagues on their view. But there's no guarantee, that they will = respond. Some initial thoughts: To me a key point seems to be what can be reached at the bottleneck. = There the compression should save bandwidth with little cost and no negative service impact. Any kind of shared access from which traffic is = transmitted to the same destination seems to be relevant. The application/tunnel awareness of network elements may not be feasible, a network terminal at = a UNI may be able to handle that, or any service specific device in a = network. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 11:29 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you = may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), = and after talking to James, I thought that the idea of standardizing the = traffic classification fits well with my proposal. I would like to know your = opinion about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they = have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the = waiting time in the multiplexer. So another use is to provide flexibility: if = you are a game provider, you may over provision your network in order to be = able to manage traffic peaks. But perhaps using this, you may be able to have = a smaller network, and use compression when necessary (rush hour, first = days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct = priority. I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-= War craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can = find the history of the problems of World of Warcraft for Virgin Media users. = The problem was caused by a modification in the traffic, and the provider = did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado = el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe = that some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ = QoS (sub)classes, I think. But one class optimised to transport "UDP" and = one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a = point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be = useful). My take would be to standardise four classes/properties (in brackets = example usage): a) for traffic which doesn't support re-transmits, requiring lowest = delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using = TCP, like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best = Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward = for a) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, = this may depend on the implemented application transport. Further details may = be discussed. Everything else could be reserved, but shouldn't be recommended. = Carriers have deployed differing schemes on codepoints and classes. They need = coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) = as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and = applications with codepoints as a requirement and I also object to standards leaving = no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit = IP precedence). Bob Briscoe mentioned the difference between classes and queues and = above properties can be mapped to queues. If end to end QoS is desired, the = same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of = getting end to end QoS. I don't support an approach requiring 8 three bit = classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I = find it interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv = becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online = games are at least as real-time as VoIP is. In most cases, the gamers are a = very difficult people to deal with. If the latency is high, they leave and = never return (this statement is not mine, it can be corroborated in the = references I put below). This has been studied by many research groups, with = empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, = the authors proposed the use of an adaptation of RTP in order to manage = gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call = of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), = e.g. World of Warcraft: They normally use TCP, even though some of them use = UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use = TCP or UDP - Sports games: Since there is a big variety, they have not = been deeply studied in the literature Some research papers supporting this classification, and also the = real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can = be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf= - In this paper from my research group, 8 FPS games were = analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP = (packets of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It = is only based on delay and jitter, since packet loss has vevy little = influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even = with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms = (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added = delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana ------=_NextPart_000_0007_01CD1336.5DA49000 Content-Type: application/pdf; name="pps_saving_counter_strike.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="pps_saving_counter_strike.pdf" JVBERi0xLjUNCiW1tbW1DQoxIDAgb2JqDQo8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFIvTGFu Zyhlcy1FUykgL1N0cnVjdFRyZWVSb290IDEwIDAgUi9NYXJrSW5mbzw8L01hcmtlZCB0cnVlPj4+ Pg0KZW5kb2JqDQoyIDAgb2JqDQo8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkc1sgNCAwIFJdID4+ DQplbmRvYmoNCjMgMCBvYmoNCjw8L0F1dGhvcih1c3VhcmlvKSAvQ3JlYXRpb25EYXRlKEQ6MjAx MjA0MDUxNDExNDMrMDInMDAnKSAvTW9kRGF0ZShEOjIwMTIwNDA1MTQxMTQzKzAyJzAwJykgL1By b2R1Y2VyKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABFAHgAYwBlAGwArgAgADIAMAAxADApIC9D cmVhdG9yKP7/AE0AaQBjAHIAbwBzAG8AZgB0AK4AIABFAHgAYwBlAGwArgAgADIAMAAxADApID4+ DQplbmRvYmoNCjQgMCBvYmoNCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvUmVzb3VyY2VzPDwv Rm9udDw8L0YxIDYgMCBSL0YyIDggMCBSPj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VCL0ltYWdl Qy9JbWFnZUldID4+L01lZGlhQm94WyAwIDAgODQxLjkyIDU5NS4zMl0gL0NvbnRlbnRzIDUgMCBS L0dyb3VwPDwvVHlwZS9Hcm91cC9TL1RyYW5zcGFyZW5jeS9DUy9EZXZpY2VSR0I+Pi9UYWJzL1Mv U3RydWN0UGFyZW50cyAwPj4NCmVuZG9iag0KNSAwIG9iag0KPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAyMjcwPj4NCnN0cmVhbQ0KeJy9WtuOHDUQfR9p/8GPM5G247vdEuKBEBAIpIAX8RB4 iMISLplNyCIQf0+Vy3a7L+PeYXqJtLtpu1x9XHadOu1u9vQF++ijp18/++JTxj/+mH3y6TMm2Jur neGdZtYyp2SnLNNOd71lH26vdj8/udoJybFVKNdZMNOuE5YpGANX2YZ3TrK/8a+Rhn1+tQPHv7Ey tLcd9+x4tXPWgUVueFucS6OxfbBIDYOFEhJBDRapobJwAqZRGcTroV/LvvO1QWqoLLzvZI0zNYBF gLnhvFajEaogTIyP0xuR350QFp3MrFID4ksWJY7jwA4WQxzHgR0shjiOA1tZ5DiO4jr0D3EcB7ay KHFcnu80KnlXlPkuWpUG1Wm6m+snccsN2UIqj/EZLEpDsYAI+pFFbsgWypjO1halIVtoobsaRr4u /Q7+V/en69xvIO1k1Z+vS38v6t54lfus7ru+HlwasoXjHpOzinZuKBaj8NfrkS1gPSRGNma47Bnw Ra/ht1OKfUvZ/iVkO9za4XYw+AdjCXeCSEltO0nRBscaQtebtGGUtLgxhLNp5ZU3cYGsxVlg8ACB sKLjFAouO+g1Lm17Az0QatjkKlpbySNyI9N+s7AlFDZAgsa5wgYQcA1Qh8TulIDJGG5xSlqwD8CJ ZTIwnrayUZ2UcXaeUi5byE5ThuE8bWXxC5Bj5EaDkWN8FKTL/AaKroEMB3NP4YZM5jKGW8XJFgvI cLqG4NrKgABu5CnQ+kZagslRNjneeVkteLGQOP3YoPCmg0XGtI2rMOwxzztBCQyxd7redHkXqk54 apCdq7dlArWRqzDsc5iUjnytgCKNrjZ+yQRIQksNojN1amRQ27gKmGsqcp/VOB6ZCsqbqvMvW0AC Gk8NHKM/WCRQG7kKlPJItxbyKPIftxh8HCczJWA/pJEjx7BlhB8MEqIt/ISBcVzXEx3bmAlIQYmt kwHveqIoA4xT9Wc4G/gJRHg4CYObDOlfUg4MBEgG2mPy4DWU6L7qT3C28BOIbmUEKeNWtB6CSrNw MvMx0q9DRovXcMeqP8PZwE8Y2N4gbWFh07Tvgej0qBoYXIXYAKVbDgYJzhZ+RjXUacOwkmIRlRDQ WRFVuM6+LqLKJiFXFVEhJ0XUjPP9fy2iziiGpRTnpKB6UBWN0JQROMCi0LTl2WJeGk8bh1RzMBAK 5zHz1ewPqTpg2EQU7vPhjf5APJ543S6MbnQH4ltL/Lt060Z3IF4knjJLd250ByIxSaS2EP9Wd0iU Q+veL9261R8SRUjijIXRje6QEjpl+FLMWv0hJaCmjFyaeKt/lKmmj6pQYr5CtZ9nqnQ2PVDlTJUi lfqSqZLypkpUYSeJ6v+3PLXgjaQ7zEj3tdqVIGy0rVSphA1tKg1arhvS9iwnlY4FeUuiKqtP4ZOG ymqzNEx063kja50KC1FrS9+jo0pKloapKj1nYKVBYYGsHQlHUIcjmZiuJ4LznHFjdalGilChBqsF YG6Ya8mHD2wpx5m6Kw1rQrE5sqULZ/otN6wJwdbAlvKbKrR8vab0GuMaym6qwMr1ipJrjWsot6nC KtcrSq01rqXMZgoqN6xJsdbAEaNrPL9QDmndSrdA6MAqvawIHZXW+PwC5jh+2pPE34XPTTpSI0Ln SYY9EqGDW5xRj7+tMkToiXqB/wwdMyTuBYY0uibjwSINKRZzgt/AaSgsjUrLJYlLGdH7lHCloVjk IdkikvEGfsLA4RBrTnU8c7hF24rUB4tM+9kiwtnATxgY3uaDj+oEQdWUXxmUQwiVwVzuJVTsD4tH 1SCRfz89RygGaUA2oJpyqZcwqgqkLcppgU6nZFWZyBbpxCFbULm53E+Y1ozjUDNiUZnVkKrKZAOq RJd6CdNychzKiUv8Nyovdf3JBlSkLvUSpqXmOBwSxFo0LT31KUM2oAJ2qZcwLUPH4YAg1qlpWapP GLJBhHKxlzCtUMehQpl0mDquWFVNywax7l3sBaCw518/Y6x6DSiefvXq7g3b395dfxcO6Z3gH603 gt8/YXdXu09urnZPP4P9oPFZ5QYACigRHOqo4Bw1Ob47gO1xc8T3Zm/Sy7OXe374kd18ebV7DuO/ WcAjN8fjwdLrWALMBA675h3nFkr7zeuXewC+Ak49Fjg8eO+nwRqjk6vo9GOhU6CCdBOcWgVnHg0c Pjq3Q6dX0dnHQoevbFQTnFkF5x4NnIeq4pro7Co6vwlnKBGrGvA6VN4pZ9y9+vNg9r/+ddD72xU0 /RZoJNcYlxNozAoEwTfBYECMqWUMU9paAyS2AKQEaDLzIECrEZKbAHKuO7Flpsy5hkdtgUcrePJ5 UIDkaoD0JoDgqZWf2MbwoMgFaCUi7zU4Zgs4BjQsnvaux0etxsduAcjCo+CpNJ8WkDVAbhNATkQB 9wBAqxHahJad4vhC4gGAzGqEzmZmGQFZQhRvRv8AD7sWbNTifBIqfFnjOSUizPfv78c4HxUN1v6p bnq5Z2sK+Oz6IZfYsXd4cgVQhJ3XsPdYSj8crtX+V/z1Di5/gh8GPz/sj/c/HC6K0oSGnD4FYzUU Z1cuAIBvUkaRwK+aLDPCYUGdQnjx6vXvt38ervX+noHIeH+4lhAZdn/7+h023uH1T/89GlMwyMlO ngKzGg9Zf7RpLYciGD/26jU+cvUKTylnX2TGDxEbxg/7tstajRtK2/RtoPXx2J6u80HkwmdU1sUn YQ3De0NP0A6RxYGGHqHJAg8SUgMfW/wynhGdRW7heOzjxCOy3EQeWB8fy7Wx+Ge68pLH3ff21T/w 5/bD/dpGyALhIR8U5JWjo+Nq6aih9fYeAxaHxnel8dR6eIm6sCKnrRcDu4muyIFVqrPzlBLmvMDa WWBPv//NgQVMfpQT1NB63Zo3HohqNdq8QmBDtVdLQzMJzvAzHnJqz28jaNLSCJj4wtKcuef9bGlO vshJK6PwzMdWK5MaWu9NYgAtwyNo+tI67WqFalrniGJDZUFDisXSOl3udXGd/uMDr11cKOWnpwGg 7NjB0iL5E4v0LxG/F1oNCmVuZHN0cmVhbQ0KZW5kb2JqDQo2IDAgb2JqDQo8PC9UeXBlL0ZvbnQv U3VidHlwZS9UcnVlVHlwZS9OYW1lL0YxL0Jhc2VGb250L0FyaWFsL0VuY29kaW5nL1dpbkFuc2lF bmNvZGluZy9Gb250RGVzY3JpcHRvciA3IDAgUi9GaXJzdENoYXIgMzIvTGFzdENoYXIgMTIxL1dp ZHRocyA3MSAwIFI+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0FyaWFsL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDkwNS9EZXNjZW50IC0y MTAvQ2FwSGVpZ2h0IDcyOC9BdmdXaWR0aCA0NDEvTWF4V2lkdGggMjY2NS9Gb250V2VpZ2h0IDQw MC9YSGVpZ2h0IDI1MC9MZWFkaW5nIDMzL1N0ZW1WIDQ0L0ZvbnRCQm94WyAtNjY1IC0yMTAgMjAw MCA3MjhdID4+DQplbmRvYmoNCjggMCBvYmoNCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBl L05hbWUvRjIvQmFzZUZvbnQvQXJpYWwsQm9sZC9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvRm9u dERlc2NyaXB0b3IgOSAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDExNi9XaWR0aHMgNzIgMCBS Pj4NCmVuZG9iag0KOSAwIG9iag0KPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9Bcmlh bCxCb2xkL0ZsYWdzIDMyL0l0YWxpY0FuZ2xlIDAvQXNjZW50IDkwNS9EZXNjZW50IC0yMTAvQ2Fw SGVpZ2h0IDcyOC9BdmdXaWR0aCA0NzkvTWF4V2lkdGggMjYyOC9Gb250V2VpZ2h0IDcwMC9YSGVp Z2h0IDI1MC9MZWFkaW5nIDMzL1N0ZW1WIDQ3L0ZvbnRCQm94WyAtNjI4IC0yMTAgMjAwMCA3Mjhd ID4+DQplbmRvYmoNCjE4IDAgb2JqDQo8PC9UeXBlL09ialN0bS9OIDYwL0ZpcnN0IDQ1OS9GaWx0 ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDkzOT4+DQpzdHJlYW0NCnicpVdtaxQxEP4u+B/mH2zekwUR xCpKsRy9gh+KH7ZtbA+vt2Xdgv57n+zOvVQvsaRQmmQzM89k7slkRjoSpARZSbIlKRQpRdIZUhJ/ lhRm3pPSpFUg5Ui3kLdkDPYDWaGxT9Ya0oKcdKRacs5DmjymWpIPgrShYBRpTaGFJUettaQt8AQs BowukPYkJVwxAmOANPxR0ISiVK0jIEptAqBJGgk5jdEpMo6khZ8G9qyHHOw5GDWw5+CthT1vIQd7 QRjCVAbn5iNLnAH2WjhpcRQBv+GaEi3kXIoA1ji3Ap5FGBTwbItwAM8hAhp4DgExiAW2lAFeCp6F 0w72LOw42HMwhqgoLyAHux5KOLIKiLaHfvCQg91WpcNgDDgEYqqSk4iYFjgM4qgBKiXimQ6BELkk h2h7fHzzplkkZUHnzbJZPnSb5uL3Q2yW4/B4PX5Yx/tmcUtm2j8l8fbt61ezSssqi3/kTy9JfqOd 2l5li3IRf41X/a9jivglIXNMG9QqAKpqQJUF1CVAXQ1osoC2BGiqAV0W0JcAbTVgyAIWSeNqAXWW NLpIGl8NmCWNLpImVANmSaOLpGmrAbOk0UXSSFGNmGWNLqea6lxjsrQxRdrI6mRjsrwxRd7I6mxj ssQxReLI6nRjsswxZeZU5xuTZY4pM6c64dgsc2yZOdUZx2aZY8vMqU45Nsuc52jL6syjjmYQW+SO qs4BNsudZ9dESu10nCh6WX2LnXy5l2bvZZExqvoeuv8z5r9eur2Xruhl9U1y/uVehr2XxQyjqm+B z2YYaVj7/V03jMfzWpLgCp3rZq5mucbkyo/rMa6SuHbhioLfeX58+UXkZ4rfDk7onGU59XE+Sv3Q NMy+zNc3NUFpmK9Jan2mYVZws8L8s6c2ZxrabBj0YRh+3sV4PBZ2NrDX217Rr/3w46rvfxx//Z5o HUhcDDGe9/3YnPfr+KV7SH1VsrfohriZdlOHNdHkkn1M3u92z/CTn8bfJNn0R9ja9GNsztK/D5ub /WLLjmW8HptPsbuJwzxPOtv55816tYnLuy55mD6828BCN676Da+HcfW9w2Ra7Q590l8/3sOn6csc vUWi05fueugP1gfRndYnq27d3x58WK5XN/FAdsaB2O3Q3TcfV7ePQ+Sznj3e/7yk1Ffvo7tj69z4 cTvGTRK3LtxQcJnPxTeXxFyocvXIJR3XWVz8cEXCZQK/3fyg8iv3N1vDE7bKJ2w1T9jqD9m6vbSv X/0B4C9w7A0KZW5kc3RyZWFtDQplbmRvYmoNCjcxIDAgb2JqDQpbIDI3OCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgNTU2IDAgMCAwIDU1NiAwIDAgMCAyMjIgMCAwIDIyMiAwIDU1NiAwIDU1 NiAwIDMzMyA1MDAgMjc4IDAgNTAwIDAgMCA1MDBdIA0KZW5kb2JqDQo3MiAwIG9iag0KWyAyNzgg MCAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA2NjcgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCA1NTYgMCA1NTYgNjExIDU1NiAwIDAgMCAyNzggMCA1NTYgMCA4 ODkgNjExIDYxMSA2MTEgMCAzODkgNTU2IDMzM10gDQplbmRvYmoNCjczIDAgb2JqDQo8PC9UeXBl L1hSZWYvU2l6ZSA3My9XWyAxIDQgMl0gL1Jvb3QgMSAwIFIvSW5mbyAzIDAgUi9JRFs8QzFCRDZE NDMwQTc4QUE0RTk0MzM5NDMzMTM5NjZCOUE+PEMxQkQ2RDQzMEE3OEFBNEU5NDMzOTQzMzEzOTY2 QjlBPl0gL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTc0Pj4NCnN0cmVhbQ0KeJw10ccRwkAM heG1ydgGbJNzzjmY1Afd0AJ3CmE4MnTAmWbMsj/ooG80mneRhJDl+5rsthBfznBTaFeFflEYd4V5 UlgevOVeBhyxgz0cYAsebOAXOMp44vGfdNAgCAEIQwiiEIE4xMAEAxJgQQqS4IANaXAhCxnIQw6K UIAylKAKFahDDZrQgDa0oANd6EMPBjCCIYxhChOYwQLmsIQ1rOTJnZd6nPsU4gNTWBTjDQplbmRz dHJlYW0NCmVuZG9iag0KeHJlZg0KMCA3NA0KMDAwMDAwMDAxMCA2NTUzNSBmDQowMDAwMDAwMDE3 IDAwMDAwIG4NCjAwMDAwMDAxMjUgMDAwMDAgbg0KMDAwMDAwMDE4MSAwMDAwMCBuDQowMDAwMDAw NDA5IDAwMDAwIG4NCjAwMDAwMDA2NTQgMDAwMDAgbg0KMDAwMDAwMjk5OSAwMDAwMCBuDQowMDAw MDAzMTU4IDAwMDAwIG4NCjAwMDAwMDMzODIgMDAwMDAgbg0KMDAwMDAwMzU0NiAwMDAwMCBuDQow MDAwMDAwMDExIDY1NTM1IGYNCjAwMDAwMDAwMTIgNjU1MzUgZg0KMDAwMDAwMDAxMyA2NTUzNSBm DQowMDAwMDAwMDE0IDY1NTM1IGYNCjAwMDAwMDAwMTUgNjU1MzUgZg0KMDAwMDAwMDAxNiA2NTUz NSBmDQowMDAwMDAwMDE3IDY1NTM1IGYNCjAwMDAwMDAwMTggNjU1MzUgZg0KMDAwMDAwMDAxOSA2 NTUzNSBmDQowMDAwMDAwMDIwIDY1NTM1IGYNCjAwMDAwMDAwMjEgNjU1MzUgZg0KMDAwMDAwMDAy MiA2NTUzNSBmDQowMDAwMDAwMDIzIDY1NTM1IGYNCjAwMDAwMDAwMjQgNjU1MzUgZg0KMDAwMDAw MDAyNSA2NTUzNSBmDQowMDAwMDAwMDI2IDY1NTM1IGYNCjAwMDAwMDAwMjcgNjU1MzUgZg0KMDAw MDAwMDAyOCA2NTUzNSBmDQowMDAwMDAwMDI5IDY1NTM1IGYNCjAwMDAwMDAwMzAgNjU1MzUgZg0K MDAwMDAwMDAzMSA2NTUzNSBmDQowMDAwMDAwMDMyIDY1NTM1IGYNCjAwMDAwMDAwMzMgNjU1MzUg Zg0KMDAwMDAwMDAzNCA2NTUzNSBmDQowMDAwMDAwMDM1IDY1NTM1IGYNCjAwMDAwMDAwMzYgNjU1 MzUgZg0KMDAwMDAwMDAzNyA2NTUzNSBmDQowMDAwMDAwMDM4IDY1NTM1IGYNCjAwMDAwMDAwMzkg NjU1MzUgZg0KMDAwMDAwMDA0MCA2NTUzNSBmDQowMDAwMDAwMDQxIDY1NTM1IGYNCjAwMDAwMDAw NDIgNjU1MzUgZg0KMDAwMDAwMDA0MyA2NTUzNSBmDQowMDAwMDAwMDQ0IDY1NTM1IGYNCjAwMDAw MDAwNDUgNjU1MzUgZg0KMDAwMDAwMDA0NiA2NTUzNSBmDQowMDAwMDAwMDQ3IDY1NTM1IGYNCjAw MDAwMDAwNDggNjU1MzUgZg0KMDAwMDAwMDA0OSA2NTUzNSBmDQowMDAwMDAwMDUwIDY1NTM1IGYN CjAwMDAwMDAwNTEgNjU1MzUgZg0KMDAwMDAwMDA1MiA2NTUzNSBmDQowMDAwMDAwMDUzIDY1NTM1 IGYNCjAwMDAwMDAwNTQgNjU1MzUgZg0KMDAwMDAwMDA1NSA2NTUzNSBmDQowMDAwMDAwMDU2IDY1 NTM1IGYNCjAwMDAwMDAwNTcgNjU1MzUgZg0KMDAwMDAwMDA1OCA2NTUzNSBmDQowMDAwMDAwMDU5 IDY1NTM1IGYNCjAwMDAwMDAwNjAgNjU1MzUgZg0KMDAwMDAwMDA2MSA2NTUzNSBmDQowMDAwMDAw MDYyIDY1NTM1IGYNCjAwMDAwMDAwNjMgNjU1MzUgZg0KMDAwMDAwMDA2NCA2NTUzNSBmDQowMDAw MDAwMDY1IDY1NTM1IGYNCjAwMDAwMDAwNjYgNjU1MzUgZg0KMDAwMDAwMDA2NyA2NTUzNSBmDQow MDAwMDAwMDY4IDY1NTM1IGYNCjAwMDAwMDAwNjkgNjU1MzUgZg0KMDAwMDAwMDA3MCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDQ4MTYgMDAwMDAgbg0KMDAwMDAwNTA1NyAwMDAw MCBuDQowMDAwMDA1Mjg0IDAwMDAwIG4NCnRyYWlsZXINCjw8L1NpemUgNzQvUm9vdCAxIDAgUi9J bmZvIDMgMCBSL0lEWzxDMUJENkQ0MzBBNzhBQTRFOTQzMzk0MzMxMzk2NkI5QT48QzFCRDZENDMw QTc4QUE0RTk0MzM5NDMzMTM5NjZCOUE+XSA+Pg0Kc3RhcnR4cmVmDQo1NjU4DQolJUVPRg0KeHJl Zg0KMCAwDQp0cmFpbGVyDQo8PC9TaXplIDc0L1Jvb3QgMSAwIFIvSW5mbyAzIDAgUi9JRFs8QzFC RDZENDMwQTc4QUE0RTk0MzM5NDMzMTM5NjZCOUE+PEMxQkQ2RDQzMEE3OEFBNEU5NDMzOTQzMzEz OTY2QjlBPl0gL1ByZXYgNTY1OC9YUmVmU3RtIDUyODQ+Pg0Kc3RhcnR4cmVmDQo3MjkzDQolJUVP Rg== ------=_NextPart_000_0007_01CD1336.5DA49000-- From cbenson@adax.com Thu Apr 5 13:26:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1018E21F8659; Thu, 5 Apr 2012 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9CWF6mRqjOS; Thu, 5 Apr 2012 13:26:03 -0700 (PDT) Received: from mail1.adax.com (mail1.adax.com [70.36.226.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8435721F8653; Thu, 5 Apr 2012 13:26:03 -0700 (PDT) Received: from adax (adax [12.0.0.88]) by mail1.adax.com (Postfix) with ESMTP id 367FB1E124B; Thu, 5 Apr 2012 13:26:03 -0700 (PDT) Received: by adax (Postfix, from userid 243) id 19B048EE51; Thu, 5 Apr 2012 13:26:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by adax (Postfix) with ESMTP id 101178EE46; Thu, 5 Apr 2012 13:26:03 -0700 (PDT) Date: Thu, 5 Apr 2012 13:26:03 -0700 (PDT) From: Chris Benson X-X-Sender: cbenson@adax.adax To: Gorry Fairhurst Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 In-Reply-To: <4F731153.6040705@erg.abdn.ac.uk> Message-ID: References: <4F731153.6040705@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 20:26:04 -0000 James and Gorry, I support this. I have read and followed development of this draft for encapsulating SCTP over UDP. I recognize the need in this area, and approve of its content as useful, correct and complete. With thanks, from Chris Benson, Adax Inc. On Wed, 28 Mar 2012, Gorry Fairhurst wrote: >> Date: Wed, 28 Mar 2012 15:25:39 +0200 >> From: Gorry Fairhurst >> To: >> Cc: >> Subject: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, >> ending Friday 20th April 2012 >> >> This email announces the start of a working group last call for >> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >> >> Following the meeting this week, this document is now thought to be ready to >> proceed to be published as a BCP. Please send any comments to the TSVWG >> list. >> >> The draft is available at: >> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 >> >> The last call will run for THREE weeks, ending Friday 20th April 2012. >> >> Emails saying "I support" or "I don't support" publication are also most >> helpful in judging the WG consensus. Please let us know if this draft is >> useful and seems to provide the correct advice. >> >> James and Gorry >> (TSVWG Chairs) >> tsvwg-chairs@ietf.org >> From jsaldana@unizar.es Fri Apr 6 04:07:16 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B067C21F8655 for ; Fri, 6 Apr 2012 04:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL8VCgEbJbDS for ; Fri, 6 Apr 2012 04:07:15 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4945621F8653 for ; Fri, 6 Apr 2012 04:07:15 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q36B77QT000456; Fri, 6 Apr 2012 13:07:08 +0200 From: "Jose Saldana" To: "'James M. Polk'" References: <002101cd122a$d28a5560$779f0020$@unizar.es> <201204042135.q34LZZW0022804@mtv-core-4.cisco.com> In-Reply-To: <201204042135.q34LZZW0022804@mtv-core-4.cisco.com> Subject: RE: Some comments about draft-polk-tsvwg-rfc4594-update-00 Date: Fri, 6 Apr 2012 13:07:08 +0200 Message-ID: <000101cd13e5$693baed0$3bb30c70$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHq+MJJNELZQHvs+cniGpJTO1JaaQG3SavjlkQeo5A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:07:16 -0000 One errata: Page 16: "conversational signaling" service appears twice in the list of services. Regards, Jose -----Mensaje original----- De: James M. Polk [mailto:jmpolk@cisco.com]=20 Enviado el: mi=E9rcoles, 04 de abril de 2012 23:36 Para: Jose Saldana; tsvwg@ietf.org Asunto: Re: Some comments about draft-polk-tsvwg-rfc4594-update-00 Jose Thanks for catching these, I'll fix each of them in the upcoming = revision. James At 01:18 AM 4/4/2012, Jose Saldana wrote: >James, > >I have been reading the draft, and I have found some small errors,=20 >which may be corrected in the next version. > >Best regards, > >Jose Saldana > >-------- > >- Page 3, first paragraph of the introduction: There is something wrong = >in this sentence: > >Local administrators are who configuration each router for which > Differentiated Services Code > >Points (DSCP) are to be treated differently, ... > > >- Page 4: There is something missing in this sentence: > >[ID-DSCP] goes further to explain that may layer 2 technologies > fewer bits for marking and prioritization. > > >- Page 15: It is said that > >Conversational service group consists of five service classes: > >But only three classes appear > > > >- Page 16, Real-time paragraph. Games do not use RTP, but only bare UDP = >an TCP. > >Real-Time Interactive, which includes both 'admitted' and > 'unadmitted' Realtime-Interactive > >service class, is for bidirectional variable rate inelastic > applications that require low > >jitter and loss and very low delay, such as interactive gaming > applications that use > >RTP/UDP streams for game control commands, > > >- Page 20: You say that real-time interactive service has to work with=20 >very low loss rate. This may be true or not. In a reference I sent=20 >yesterday, it was shown that Microsoft's game "Halo" stops working with = >4% packet loss, whereas Quake III works well with 30%, and players do=20 >not notice > > >- Page 42, first paragraph: > >Interactive gaming applications that do not have the ability to > change encoding rates > >or to mark packets with different importance indications is one > good example of such an > >application. > >I think that talking about encoding rates for games is a bit confusing. = >The games I have studied do not modify encoding rates, since they do=20 >not transmit audio or video. They only transmit the game status or the=20 >actions of the player. The game is rendered in the local machine. One=20 >exception: games including a voice channel in order to coordinate the=20 >different players. > From jsaldana@unizar.es Fri Apr 6 04:27:45 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D11B21F84BD for ; Fri, 6 Apr 2012 04:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.914 X-Spam-Level: X-Spam-Status: No, score=-5.914 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuvxUXe6dy71 for ; Fri, 6 Apr 2012 04:27:44 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 33B2521F844D for ; Fri, 6 Apr 2012 04:27:43 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q36BRXoR018967; Fri, 6 Apr 2012 13:27:34 +0200 From: "Jose Saldana" To: "'James M. Polk'" References: <002101cd122a$d28a5560$779f0020$@unizar.es> <201204042135.q34LZZW0022804@mtv-core-4.cisco.com> In-Reply-To: <201204042135.q34LZZW0022804@mtv-core-4.cisco.com> Subject: RE: Some comments about draft-polk-tsvwg-rfc4594-update-00 Date: Fri, 6 Apr 2012 13:27:36 +0200 Message-ID: <000201cd13e8$455ebef0$d01c3cd0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHq+MJJNELZQHvs+cniGpJTO1JaaQG3SavjlkQg86A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Apr 2012 11:27:45 -0000 James, Another question: Clarifying the number of services and clases. I have summarized the service classification you present in the draft, at the end of this message. Some suggestions: 1) The fact of grouping "Audio", "Hi-Res Video" and "Video" into a group, makes it a bit confusing. In the figures, you consider them as different services, but in page 15 you put them at a different level. This results a bit confusing for the reader: are them a class or three classes? Since you use them separately in the next classifications, I think that the paragraph " Conversational service group consists of five service classes" could be a comment, and then you could put the three services using "o" instead of "-" 2) Perhaps "Broadcast video" in page 18 could be "Broadcast". There is also audio broadcast. 3) Perhaps the order of the different services could be the same in section 2.1, section 2.2 and the figures 2, 3 and 4. Perhaps it is not possible, but the draft would read better. 4) In figure 2, best effort service is called "standard", but in figure 3 it is called "best effort". Regards, Jose -------------------------------- Summary of the different classifications: Classification of draft-polk-tsvwg-rfc4594-update-00, section 2.1: * Network control o "Network Control" for routing and network control function. o "OAM" (Operations, Administration, and Management) for network configuration and management functions. * The user/subscriber traffic group is broken down into ten (eleven) service classes to o Audio \ o Hi-Res Video - Conversational service includes three service classes o Video / o Conversational Signaling (it appears twice in page 16) o Real-Time Interactive o Multimedia Conferencing o Multimedia Streaming o Broadcast o Low-Latency Data o High-Throughput Data o Standard service class, commonly called best effort (BE) o Low-Priority Data So we have 2 + 12 = 14 service classes Figure 2, 3, 4 include 14 service classes. Classification of draft-polk-tsvwg-rfc4594-update-00, section 2.2 (only user/subscriber traffic group): 12 application classes, divided into 4 categories * Application Control Category o Conversational Signaling * Media-Oriented Category o Audio o Video o Hi-Res Video o Realtime-Interactive o Multimedia Conferencing o Broadcast video o Multimedia Streaming * Data Category o Low-Latency Data o High-Throughput Data o Low-Priority Data * Best-Effort Category o Standard From jsaldana@unizar.es Sat Apr 7 05:03:40 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC6721F856F for ; Sat, 7 Apr 2012 05:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wltvW7vpPi0r for ; Sat, 7 Apr 2012 05:03:34 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id E0B8A21F8570 for ; Sat, 7 Apr 2012 05:03:33 -0700 (PDT) Received: from jsaldanapc (109.Red-88-4-219.dynamicIP.rima-tde.net [88.4.219.109]) (authenticated bits=0) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q37C3NqV019117; Sat, 7 Apr 2012 14:03:24 +0200 From: "Jose Saldana" To: , "James M. Polk" References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Date: Sat, 7 Apr 2012 14:03:24 +0200 Message-ID: <000c01cd14b6$70b33ad0$5219b070$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDJZaCuqA Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 12:03:40 -0000 I have been reading the two messages of Ruediger about Jame's draft. I = will try to make a "status of the question" and then a proposal. If something = is wrong, just tell me. - We have the old 8 TOS bits of the IP header. Nowadays, two of them are ECN, and six of them are the DSCP field. So the problem is how to use = these 6 bits (64 possible values) - Network control is 11xxxx, so this uses 16 values -11xx11 are defined in RFC 2474, and remain as only experimentally assignable/useable (this uses 4 of these 16 values) - This leaves 48 values - Best effort is 000000 - The draft of James proposes 14 values for the DSCP field, which = correspond to service classes, mapped to application categories. But Ruediger says that, in his opinion, more than 4 classes are not = useful, according to current implementations. We can ask ourselves: which are the key parameters that define how = packets have to be managed in a router? I think that they are: 1) "Real-time-ness": The tolerated delay of the service. The jitter can = be roughly included in this parameter. 2) loss tolerance: We can distinguish: TCP services are tolerant to = loss, since they retransmit packets. And some UDP services are also tolerant = to loss (VoIP, some games, etc) In my opinion, the "real-time-ness" is the key: it distinguishes very similar services: e.g. a video conference is different from a broadcast, since the latter permits delays of some seconds, whereas the first has = to be interactive. So one possible solution could be: - Using the first two bits in order to define 4 classes, taking into = account the existing implementations. They can be the 4 classes of Fig. 1 of = James' draft, or the ones proposed by Ruediger. 00xxxx best effort 01xxxx data 10xxxx media oriented 11xxxx control - With the other 4 bits, something should be done. My proposal: - If the third bit is "1", then the other three bits include a value defining the "real-time-ness" of the flow. So we have 8 levels of real-time-ness. Some examples: - 10-1-111 would be a media-oriented (10) and very real-time flow, as VoIP or a game - 10-0-xxx would be a media-oriented flow for which the real-time-ness is not defined - 10-1-010 could be a media-oriented flow with medium delay requirements, as multimedia conferencing - 10-1-000 would be a media-oriented flow with no very hard delay requirements, as multimedia streaming - 00-xxxx would be best-effort -01-1-111 would be very low-latency data -01-1-000 would be low-priority data One advantage of this is that some routers may only take into account = the first two bits, and others would use all of them. The new RFC could suggest or define different values of real-time-ness = for each application. So the applications should be ordered depending of the maximum tolerated delay. Ok. This is only an idea. Perhaps it does not make sense. Just tell me. Regards, Jose -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Enviado el: jueves, 05 de abril de 2012 12:23 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, regarding QoS, I'm happy to agree on 4 standard classes with properties = as mentioned in my last email. If there's consensus on some codepoints for them, I'll support that. If IETF recommends how and which applications to use these classes/codepoints, that's again agreeable. I don't think, that by now requiring a specific application to carry a specific DSCP makes sense, = apart from few exceptions (like VoIP payload, network management traffic or = Best Effort traffic). IETF needs consensus to do that. Note that the number of AF classes and codepoints are troublesome. Too = many with too little explanation how to use them, nothing is aligned with = user demand. EF/VoIP payload and network management are examples how to = proceed: just specify what's required, no extras. Then regarding tunnels and header compression Yes, that's smart and = there may be more use cases than gaming. I'm a backbone engineer however and = your proposal is rather application specific. What I can do is ask some colleagues on their view. But there's no guarantee, that they will = respond. Some initial thoughts: To me a key point seems to be what can be reached at the bottleneck. = There the compression should save bandwidth with little cost and no negative service impact. Any kind of shared access from which traffic is = transmitted to the same destination seems to be relevant. The application/tunnel awareness of network elements may not be feasible, a network terminal at = a UNI may be able to handle that, or any service specific device in a = network. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 11:29 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you = may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), = and after talking to James, I thought that the idea of standardizing the = traffic classification fits well with my proposal. I would like to know your = opinion about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they = have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the = waiting time in the multiplexer. So another use is to provide flexibility: if = you are a game provider, you may over provision your network in order to be = able to manage traffic peaks. But perhaps using this, you may be able to have = a smaller network, and use compression when necessary (rush hour, first = days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct = priority. I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-= War craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can = find the history of the problems of World of Warcraft for Virgin Media users. = The problem was caused by a modification in the traffic, and the provider = did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado = el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe = that some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ = QoS (sub)classes, I think. But one class optimised to transport "UDP" and = one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a = point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be = useful). My take would be to standardise four classes/properties (in brackets = example usage): a) for traffic which doesn't support re-transmits, requiring lowest = delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using = TCP, like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best = Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward = for a) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, = this may depend on the implemented application transport. Further details may = be discussed. Everything else could be reserved, but shouldn't be recommended. = Carriers have deployed differing schemes on codepoints and classes. They need = coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) = as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and = applications with codepoints as a requirement and I also object to standards leaving = no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit = IP precedence). Bob Briscoe mentioned the difference between classes and queues and = above properties can be mapped to queues. If end to end QoS is desired, the = same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of = getting end to end QoS. I don't support an approach requiring 8 three bit = classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I = find it interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv = becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online = games are at least as real-time as VoIP is. In most cases, the gamers are a = very difficult people to deal with. If the latency is high, they leave and = never return (this statement is not mine, it can be corroborated in the = references I put below). This has been studied by many research groups, with = empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, = the authors proposed the use of an adaptation of RTP in order to manage = gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call = of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), = e.g. World of Warcraft: They normally use TCP, even though some of them use = UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use = TCP or UDP - Sports games: Since there is a big variety, they have not = been deeply studied in the literature Some research papers supporting this classification, and also the = real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can = be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf= - In this paper from my research group, 8 FPS games were = analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP = (packets of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It = is only based on delay and jitter, since packet loss has vevy little = influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even = with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms = (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added = delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana From jmpolk@cisco.com Mon Apr 9 12:55:16 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1D21F87F4 for ; Mon, 9 Apr 2012 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.971 X-Spam-Level: X-Spam-Status: No, score=-108.971 tagged_above=-999 required=5 tests=[AWL=-1.627, BAYES_20=-0.74, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+YxcVlUrcA3 for ; Mon, 9 Apr 2012 12:55:15 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64621F846B for ; Mon, 9 Apr 2012 12:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=16070; q=dns/txt; s=iport; t=1334001315; x=1335210915; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=m+Bj/Y9hOEZfqCTKfdAbtduVE7OaYfnVc5TmHh0V66M=; b=Yw1HpchmlSh61VsV0l5AX2lZKegV6WnHJwx73mAsnBbVzMm51SSfUqG1 eGTee1233Q59bI2kllORH7wFsmEweYOq60VuIg/fchCbtFyKxp6vVUfHv xmdwVVHUuzfdtMD02gF53HUq5lsjT5/i/3iLe14F2Zst/jlqTklSsjUwq w=; X-IronPort-AV: E=Sophos;i="4.75,393,1330905600"; d="scan'208";a="39739861" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 09 Apr 2012 19:55:13 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q39JtCta019752; Mon, 9 Apr 2012 19:55:12 GMT Message-Id: <201204091955.q39JtCta019752@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 09 Apr 2012 14:55:12 -0500 To: "Jose Saldana" , From: "James M. Polk" Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt In-Reply-To: <000c01cd14b6$70b33ad0$5219b070$@unizar.es> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "James M. Polk" , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:55:17 -0000 Jose Thanks for giving this effort. SPs usually use=20 MPLS, which has 3 bits (8 values) of=20 differentiation. Thus, for SPs, this is the goal=20 -> to be 8 values or less. I don't expect too=20 many, if any, SPs to want to do 8 different=20 values per customer, so I understand where=20 Ruediger is coming from. At the same time, there=20 are many networks that want far more than 8=20 values for use, so SP desires to box everyone=20 into only their way of managing the world is not=20 satisfactory to these other networks. Thus, the=20 draft discusses aggregating several service=20 classes into a since value when traveling over SP=20 networks. The draft says in many places that not=20 all service classes are needed, and in fact that=20 few likely would be used across SP networks. What=20 the draft *didn't* make clear is saying this idea=20 in a concise part (i.e., its own section) of the=20 draft (instead, it was spread over the whole=20 draft). I said in the meeting that was an error=20 on my part. I also said at the meeting the next=20 version of the draft will have this concept in a=20 nice, concise standalone section that (hopefully)=20 will make this idea more apparent. I plan to get the next version written well before Vancouver, for WG review. James At 07:03 AM 4/7/2012, Jose Saldana wrote: >I have been reading the two messages of Ruediger about Jame's draft. I will >try to make a "status of the question" and then a proposal. If something is >wrong, just tell me. > >- We have the old 8 TOS bits of the IP header. Nowadays, two of them are >ECN, and six of them are the DSCP field. So the problem is how to use these >6 bits (64 possible values) >- Network control is 11xxxx, so this uses 16 values > -11xx11 are defined in RFC 2474, and remain as only experimentally >assignable/useable (this uses 4 of these 16 values) >- This leaves 48 values >- Best effort is 000000 >- The draft of James proposes 14 values for the DSCP field, which= correspond >to service classes, mapped to application categories. > >But Ruediger says that, in his opinion, more than 4 classes are not useful, >according to current implementations. > >We can ask ourselves: which are the key parameters that define how packets >have to be managed in a router? I think that they are: > >1) "Real-time-ness": The tolerated delay of the service. The jitter can be >roughly included in this parameter. >2) loss tolerance: We can distinguish: TCP services are tolerant to loss, >since they retransmit packets. And some UDP services are also tolerant to >loss (VoIP, some games, etc) > >In my opinion, the "real-time-ness" is the key: it distinguishes very >similar services: e.g. a video conference is different from a broadcast, >since the latter permits delays of some seconds, whereas the first has to= be >interactive. > >So one possible solution could be: > >- Using the first two bits in order to define 4 classes, taking into= account >the existing implementations. They can be the 4 classes of Fig. 1 of James' >draft, or the ones proposed by Ruediger. > 00xxxx best effort > 01xxxx data > 10xxxx media oriented > 11xxxx control > >- With the other 4 bits, something should be done. My proposal: > - If the third bit is "1", then the other three bits include a= value >defining the "real-time-ness" of the flow. So we have 8 levels of >real-time-ness. Some examples: > - 10-1-111 would be a media-oriented (10) and very >real-time flow, as VoIP or a game > - 10-0-xxx would be a media-oriented flow for which the >real-time-ness is not defined > - 10-1-010 could be a media-oriented flow with medium= delay >requirements, as multimedia conferencing > - 10-1-000 would be a media-oriented flow with no very= hard >delay requirements, as multimedia streaming > - 00-xxxx would be best-effort > -01-1-111 would be very low-latency data > -01-1-000 would be low-priority data > >One advantage of this is that some routers may only take into account the >first two bits, and others would use all of them. > >The new RFC could suggest or define different values of real-time-ness for >each application. So the applications should be ordered depending of the >maximum tolerated delay. > >Ok. This is only an idea. Perhaps it does not make sense. Just tell me. >Regards, > >Jose > >-----Mensaje original----- >De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] >Enviado el: jueves, 05 de abril de 2012 12:23 >Para: jsaldana@unizar.es >CC: tsvwg@ietf.org >Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > >Jose, > >regarding QoS, I'm happy to agree on 4 standard classes with properties as >mentioned in my last email. If there's consensus on some codepoints for >them, I'll support that. > >If IETF recommends how and which applications to use these >classes/codepoints, that's again agreeable. I don't think, that by now >requiring a specific application to carry a specific DSCP makes sense,= apart >from few exceptions (like VoIP payload, network management traffic or Best >Effort traffic). >IETF needs consensus to do that. >Note that the number of AF classes and codepoints are troublesome. Too many >with too little explanation how to use them, nothing is aligned with user >demand. EF/VoIP payload and network management are examples how to proceed: >just specify what's required, no extras. > > >Then regarding tunnels and header compression Yes, that's smart and there >may be more use cases than gaming. I'm a backbone engineer however and your >proposal is rather application specific. What I can do is ask some >colleagues on their view. But there's no guarantee, that they will respond. > >Some initial thoughts: >To me a key point seems to be what can be reached at the bottleneck. There >the compression should save bandwidth with little cost and no negative >service impact. Any kind of shared access from which traffic is transmitted >to the same destination seems to be relevant. The application/tunnel >awareness of network elements may not be feasible, a network terminal at a >UNI may be able to handle that, or any service specific device in a= network. > >Regards, > >Ruediger > > >-----Original Message----- >From: Jose Saldana [mailto:jsaldana@unizar.es] >Sent: Thursday, April 05, 2012 11:29 AM >To: Geib, R=FCdiger >Cc: tsvwg@ietf.org >Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > >Ruediger, > >I have read your message about draft-polk-tsvwg-rfc4594-update. As you may >know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02),= and >after talking to James, I thought that the idea of standardizing the= traffic >classification fits well with my proposal. I would like to know your= opinion >about it, if possible. > >The idea is to use tunnels in order to compress and multiplex real-time >traffic flows. Since these flows tend to use very small packets, they have >very bad efficiency. So perhaps tunnels could be used in order to group >these flows. The drawback is that they add small delays, i.e. the waiting >time in the multiplexer. So another use is to provide flexibility: if you >are a game provider, you may over provision your network in order to be= able >to manage traffic peaks. But perhaps using this, you may be able to have a >smaller network, and use compression when necessary (rush hour, first days >after releasing a new game, etc). When traffic is small, you do not >multiplex, in order to reduce latency. > >So if traffic classification is a standard, everyone in the way from the >origin to the destination will handle the traffic with the correct= priority. > >I attach a figure in order to clarify. > >Thank you, > >Jose > >PS: In >http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-Wa= r >craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find >the history of the problems of World of Warcraft for Virgin Media users.= The >problem was caused by a modification in the traffic, and the provider did >not notice about it, so it treated the packets as best-effort. > >-----Mensaje original----- >De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el: >jueves, 05 de abril de 2012 9:49 >Para: jsaldana@unizar.es >CC: tsvwg@ietf.org >Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > >Jose, > >you raise an interesting point: > >draft-polk-tsvwg-rfc4594-update suggests to standardise application to >codepoint mapping as well as codepoint to class properties. You observe= that >some games are using TCP while others use UDP, which I think is a useful >level of QoS requirement abstraction. There's no need to have like 25+ QoS >(sub)classes, I think. But one class optimised to transport "UDP" and one >for "TCP" are agreeable. > >The feedback that I had on carrier class QoS usage is that there's a point >in standardising class properties, and certainly not to standardise >application mappings to classes (recommending them may however be useful). >My take would be to standardise four classes/properties (in brackets= example >usage): > >a) for traffic which doesn't support re-transmits, requiring lowest delay >and jitter, having limited volume and packet > size, but being loss tolerant (example usage VoIP) >b) for any other traffic which doesn't support re-transmits (let's say >traffic with real time like properties, but any > packet size and possibly high volume, UDP transport, like IPTV) >c) for any other traffic which supports re-transmits (QoS traffic using= TCP, >like application signalling and network management traffic) >d) a default class, for any traffic supporting re-transmits (Best Effort) - >this class may not be regarded as QoS (or as lowest CoS) > >What I can tell ist that many carriers and standards on QoS support 3-4 >classes, having properties as described above. It is useful to recommend >codepoints matching to these classes. Standardising these codepoints >requires agreement between those having deplyed them. Straightforward for= a) >EF and d) 000000, probably easy for c) being used to transport Network >Management (CS 6). I'm not aware of common ground for anything else. My >favourites are: > >b) AF4 (GSMA supports this one, RFC4594 also) >c) AF3 (MEF and GSMA support this one) > >Gaming from my point of view would then match to an AF3 or AF4 class, this >may depend on the implemented application transport. Further details may be >discussed. > >Everything else could be reserved, but shouldn't be recommended. Carriers >have deployed differing schemes on codepoints and classes. They need coding >reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as >well as in DSCP space if they should converge to a standardised >codepoint/class scheme. > >I object to any approach standardising a match of classes and applications >with codepoints as a requirement and I also object to standards leaving no >spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP >precedence). > >Bob Briscoe mentioned the difference between classes and queues and above >properties can be mapped to queues. If end to end QoS is desired, the same >class properties must be negotiated end to end. The lower the number of >classes and codepoints being deployed, the higher the probability of= getting >end to end QoS. I don't support an approach requiring 8 three bit classes >and 25 or more 6 bit classes and codepoints. > >Regards, > >Ruediger > >________________________________ > >From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of >Jose Saldana >Sent: Monday, April 02, 2012 12:17 PM >To: James Polk >Cc: tsvwg@ietf.org >Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > >James, > > > >After returning home from IETF 83, I have been reading your draft. I find= it >interesting to standardize the service classes. Otherwise, if each one >classifies each traffic according to different criteria, Diffserv becomes >less useful. > > > >Regarding "Real-time interactive" service class, which refers to online >gaming (my main research field), I find it really interesting: online games >are at least as real-time as VoIP is. In most cases, the gamers are a very >difficult people to deal with. If the latency is high, they leave and never >return (this statement is not mine, it can be corroborated in the= references >I put below). This has been studied by many research groups, with empirical >tests using real gamers and adding delay, jitter, packet loss. > > > >Other question: in the draft it is said that online games use RTP/UDP >streams. This can be a little confusing. In fact, the vast majority of >online games do not use RTP, but bare UDP or even TCP. In >http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the >authors proposed the use of an adaptation of RTP in order to manage gaming >traffic. But as far as I know, this approach is not used by commercial >games. > > > > > >A typical classification of today's games is: > > > >- FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of >Duty: They use UDP > >- MMORPG (Massively Multiplayer Online Role-playing Games), e.g. >World of Warcraft: They normally use TCP, even though some of them use UDP > >- RTS (Real-time strategy) e.g. Age of Empires: They may use TCP= or >UDP > >- Sports games: Since there is a big variety, they have not been >deeply studied in the literature > > > >Some research papers supporting this classification, and also the real-time >requirements of the games: > > > >First Person Shooters > > > >- A survey of traffic models for 17 First Person Shooters can be >found here. All of them use UDP >http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf > > > >- In this paper from my research group, 8 FPS games were analyzed >in order to compress and multiplex their traffic. Figure 5 shows their >histograms (inter-packet time and packet size). It can be seen that they >generate real-time flows, with characteristics very similar to VoIP= (packets >of 60-80 bytes every 15-40 ms): >http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf > > > >- Another paper about FPS using UDP. Section V presents some >interesting conclusions about routing infrastructure. >http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > >- In this paper the network factors annoying the gamers are >analyzed. There are also some calculations of the MOS. Above 150 ms the >quality is bad (something similar to what happens with VoIP) >http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > >- In this one, a MOS model for a FPS (Quake IV) is deployed. It is >only based on delay and jitter, since packet loss has vevy little influence >(for this concrete game). Delay above 140 ms produces MOS below 3 >http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > >- In this paper, it is found that some FPS work properly even with >30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150 >OWD) makes MOS go above 3 >http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > >MMORPGs: > >- A traffic model for World of Warcraft: >http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > >- This one presents a MOS for World of Warcraft. When added delay >is above 160ms, the MOS is roughly 3.: >http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > >Best regards, > > > >Jose Saldana From david.black@emc.com Tue Apr 10 15:35:03 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B909B11E814A for ; Tue, 10 Apr 2012 15:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.309 X-Spam-Level: X-Spam-Status: No, score=-110.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wm8NVmQd5HUD for ; Tue, 10 Apr 2012 15:35:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A715611E8103 for ; Tue, 10 Apr 2012 15:35:01 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3AMYt1U019407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 18:34:55 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 10 Apr 2012 18:34:35 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3AMYZgj020078; Tue, 10 Apr 2012 18:34:35 -0400 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 10 Apr 2012 18:34:34 -0400 From: To: , , Date: Tue, 10 Apr 2012 18:34:33 -0400 Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDJZaCuqAgAcZHFA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> In-Reply-To: <000c01cd14b6$70b33ad0$5219b070$@unizar.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 22:35:03 -0000 > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are > ECN, and six of them are the DSCP field. So the problem is how to use the= se > 6 bits (64 possible values) > - Network control is 11xxxx, so this uses 16 values > -11xx11 are defined in RFC 2474, and remain as only experimentally > assignable/useable (this uses 4 of these 16 values) > - This leaves 48 values > - Best effort is 000000 > - The draft of James proposes 14 values for the DSCP field, which corresp= ond > to service classes, mapped to application categories. > > But Ruediger says that, in his opinion, more than 4 classes are not usefu= l, > according to current implementations. That's actually not appropriate for an RFC 4594 update - the proper place t= o address that requirement is an update to RFC 5127, which will need to be up= dated to be consistent with whatever is done to RFC 4594. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Jose > Saldana > Sent: Saturday, April 07, 2012 8:03 AM > To: Ruediger.Geib@telekom.de; James M. Polk > Cc: tsvwg@ietf.org > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > I have been reading the two messages of Ruediger about Jame's draft. I wi= ll > try to make a "status of the question" and then a proposal. If something = is > wrong, just tell me. > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are > ECN, and six of them are the DSCP field. So the problem is how to use the= se > 6 bits (64 possible values) > - Network control is 11xxxx, so this uses 16 values > -11xx11 are defined in RFC 2474, and remain as only experimentally > assignable/useable (this uses 4 of these 16 values) > - This leaves 48 values > - Best effort is 000000 > - The draft of James proposes 14 values for the DSCP field, which corresp= ond > to service classes, mapped to application categories. > > But Ruediger says that, in his opinion, more than 4 classes are not usefu= l, > according to current implementations. > > We can ask ourselves: which are the key parameters that define how packe= ts > have to be managed in a router? I think that they are: > > 1) "Real-time-ness": The tolerated delay of the service. The jitter can b= e > roughly included in this parameter. > 2) loss tolerance: We can distinguish: TCP services are tolerant to loss, > since they retransmit packets. And some UDP services are also tolerant to > loss (VoIP, some games, etc) > > In my opinion, the "real-time-ness" is the key: it distinguishes very > similar services: e.g. a video conference is different from a broadcast, > since the latter permits delays of some seconds, whereas the first has to= be > interactive. > > So one possible solution could be: > > - Using the first two bits in order to define 4 classes, taking into acco= unt > the existing implementations. They can be the 4 classes of Fig. 1 of Jame= s' > draft, or the ones proposed by Ruediger. > 00xxxx best effort > 01xxxx data > 10xxxx media oriented > 11xxxx control > > - With the other 4 bits, something should be done. My proposal: > - If the third bit is "1", then the other three bits include a valu= e > defining the "real-time-ness" of the flow. So we have 8 levels of > real-time-ness. Some examples: > - 10-1-111 would be a media-oriented (10) and very > real-time flow, as VoIP or a game > - 10-0-xxx would be a media-oriented flow for which the > real-time-ness is not defined > - 10-1-010 could be a media-oriented flow with medium delay > requirements, as multimedia conferencing > - 10-1-000 would be a media-oriented flow with no very hard > delay requirements, as multimedia streaming > - 00-xxxx would be best-effort > -01-1-111 would be very low-latency data > -01-1-000 would be low-priority data > > One advantage of this is that some routers may only take into account the > first two bits, and others would use all of them. > > The new RFC could suggest or define different values of real-time-ness fo= r > each application. So the applications should be ordered depending of the > maximum tolerated delay. > > Ok. This is only an idea. Perhaps it does not make sense. Just tell me. > Regards, > > Jose > > -----Mensaje original----- > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Enviado el: jueves, 05 de abril de 2012 12:23 > Para: jsaldana@unizar.es > CC: tsvwg@ietf.org > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Jose, > > regarding QoS, I'm happy to agree on 4 standard classes with properties a= s > mentioned in my last email. If there's consensus on some codepoints for > them, I'll support that. > > If IETF recommends how and which applications to use these > classes/codepoints, that's again agreeable. I don't think, that by now > requiring a specific application to carry a specific DSCP makes sense, ap= art > from few exceptions (like VoIP payload, network management traffic or Bes= t > Effort traffic). > IETF needs consensus to do that. > Note that the number of AF classes and codepoints are troublesome. Too ma= ny > with too little explanation how to use them, nothing is aligned with user > demand. EF/VoIP payload and network management are examples how to procee= d: > just specify what's required, no extras. > > > Then regarding tunnels and header compression Yes, that's smart and there > may be more use cases than gaming. I'm a backbone engineer however and yo= ur > proposal is rather application specific. What I can do is ask some > colleagues on their view. But there's no guarantee, that they will respon= d. > > Some initial thoughts: > To me a key point seems to be what can be reached at the bottleneck. Ther= e > the compression should save bandwidth with little cost and no negative > service impact. Any kind of shared access from which traffic is transmitt= ed > to the same destination seems to be relevant. The application/tunnel > awareness of network elements may not be feasible, a network terminal at = a > UNI may be able to handle that, or any service specific device in a netwo= rk. > > Regards, > > Ruediger > > > -----Original Message----- > From: Jose Saldana [mailto:jsaldana@unizar.es] > Sent: Thursday, April 05, 2012 11:29 AM > To: Geib, R=FCdiger > Cc: tsvwg@ietf.org > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Ruediger, > > I have read your message about draft-polk-tsvwg-rfc4594-update. As you ma= y > know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), = and > after talking to James, I thought that the idea of standardizing the traf= fic > classification fits well with my proposal. I would like to know your opin= ion > about it, if possible. > > The idea is to use tunnels in order to compress and multiplex real-time > traffic flows. Since these flows tend to use very small packets, they hav= e > very bad efficiency. So perhaps tunnels could be used in order to group > these flows. The drawback is that they add small delays, i.e. the waiting > time in the multiplexer. So another use is to provide flexibility: if you > are a game provider, you may over provision your network in order to be a= ble > to manage traffic peaks. But perhaps using this, you may be able to have = a > smaller network, and use compression when necessary (rush hour, first day= s > after releasing a new game, etc). When traffic is small, you do not > multiplex, in order to reduce latency. > > So if traffic classification is a standard, everyone in the way from the > origin to the destination will handle the traffic with the correct priori= ty. > > I attach a figure in order to clarify. > > Thank you, > > Jose > > PS: In > http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-= War > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find > the history of the problems of World of Warcraft for Virgin Media users. = The > problem was caused by a modification in the traffic, and the provider did > not notice about it, so it treated the packets as best-effort. > > -----Mensaje original----- > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el= : > jueves, 05 de abril de 2012 9:49 > Para: jsaldana@unizar.es > CC: tsvwg@ietf.org > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Jose, > > you raise an interesting point: > > draft-polk-tsvwg-rfc4594-update suggests to standardise application to > codepoint mapping as well as codepoint to class properties. You observe t= hat > some games are using TCP while others use UDP, which I think is a useful > level of QoS requirement abstraction. There's no need to have like 25+ Qo= S > (sub)classes, I think. But one class optimised to transport "UDP" and on= e > for "TCP" are agreeable. > > The feedback that I had on carrier class QoS usage is that there's a poin= t > in standardising class properties, and certainly not to standardise > application mappings to classes (recommending them may however be useful)= . > My take would be to standardise four classes/properties (in brackets exam= ple > usage): > > a) for traffic which doesn't support re-transmits, requiring lowest delay > and jitter, having limited volume and packet > size, but being loss tolerant (example usage VoIP) > b) for any other traffic which doesn't support re-transmits (let's say > traffic with real time like properties, but any > packet size and possibly high volume, UDP transport, like IPTV) > c) for any other traffic which supports re-transmits (QoS traffic using T= CP, > like application signalling and network management traffic) > d) a default class, for any traffic supporting re-transmits (Best Effort)= - > this class may not be regarded as QoS (or as lowest CoS) > > What I can tell ist that many carriers and standards on QoS support 3-4 > classes, having properties as described above. It is useful to recommend > codepoints matching to these classes. Standardising these codepoints > requires agreement between those having deplyed them. Straightforward for= a) > EF and d) 000000, probably easy for c) being used to transport Network > Management (CS 6). I'm not aware of common ground for anything else. My > favourites are: > > b) AF4 (GSMA supports this one, RFC4594 also) > c) AF3 (MEF and GSMA support this one) > > Gaming from my point of view would then match to an AF3 or AF4 class, thi= s > may depend on the implemented application transport. Further details may = be > discussed. > > Everything else could be reserved, but shouldn't be recommended. Carriers > have deployed differing schemes on codepoints and classes. They need codi= ng > reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) a= s > well as in DSCP space if they should converge to a standardised > codepoint/class scheme. > > I object to any approach standardising a match of classes and application= s > with codepoints as a requirement and I also object to standards leaving n= o > spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit I= P > precedence). > > Bob Briscoe mentioned the difference between classes and queues and above > properties can be mapped to queues. If end to end QoS is desired, the sam= e > class properties must be negotiated end to end. The lower the number of > classes and codepoints being deployed, the higher the probability of gett= ing > end to end QoS. I don't support an approach requiring 8 three bit classes > and 25 or more 6 bit classes and codepoints. > > Regards, > > Ruediger > > ________________________________ > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Jose Saldana > Sent: Monday, April 02, 2012 12:17 PM > To: James Polk > Cc: tsvwg@ietf.org > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > James, > > > > After returning home from IETF 83, I have been reading your draft. I find= it > interesting to standardize the service classes. Otherwise, if each one > classifies each traffic according to different criteria, Diffserv becomes > less useful. > > > > Regarding "Real-time interactive" service class, which refers to online > gaming (my main research field), I find it really interesting: online gam= es > are at least as real-time as VoIP is. In most cases, the gamers are a ver= y > difficult people to deal with. If the latency is high, they leave and nev= er > return (this statement is not mine, it can be corroborated in the referen= ces > I put below). This has been studied by many research groups, with empiric= al > tests using real gamers and adding delay, jitter, packet loss. > > > > Other question: in the draft it is said that online games use RTP/UDP > streams. This can be a little confusing. In fact, the vast majority of > online games do not use RTP, but bare UDP or even TCP. In > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the > authors proposed the use of an adaptation of RTP in order to manage gamin= g > traffic. But as far as I know, this approach is not used by commercial > games. > > > > > > A typical classification of today's games is: > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of > Duty: They use UDP > > - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. > World of Warcraft: They normally use TCP, even though some of them use UD= P > > - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP= or > UDP > > - Sports games: Since there is a big variety, they have not been > deeply studied in the literature > > > > Some research papers supporting this classification, and also the real-ti= me > requirements of the games: > > > > First Person Shooters > > > > - A survey of traffic models for 17 First Person Shooters can be > found here. All of them use UDP > http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf > > > > - In this paper from my research group, 8 FPS games were analyze= d > in order to compress and multiplex their traffic. Figure 5 shows their > histograms (inter-packet time and packet size). It can be seen that they > generate real-time flows, with characteristics very similar to VoIP (pack= ets > of 60-80 bytes every 15-40 ms): > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf > > > > - Another paper about FPS using UDP. Section V presents some > interesting conclusions about routing infrastructure. > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > - In this paper the network factors annoying the gamers are > analyzed. There are also some calculations of the MOS. Above 150 ms the > quality is bad (something similar to what happens with VoIP) > http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > - In this one, a MOS model for a FPS (Quake IV) is deployed. It = is > only based on delay and jitter, since packet loss has vevy little influen= ce > (for this concrete game). Delay above 140 ms produces MOS below 3 > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > - In this paper, it is found that some FPS work properly even wi= th > 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (1= 50 > OWD) makes MOS go above 3 > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > MMORPGs: > > - A traffic model for World of Warcraft: > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > - This one presents a MOS for World of Warcraft. When added dela= y > is above 160ms, the MOS is roughly 3.: > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > Best regards, > > > > Jose Saldana > > From jsaldana@unizar.es Fri Apr 13 01:48:02 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A7A21F86F1 for ; Fri, 13 Apr 2012 01:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYDa3uAaPOGQ for ; Fri, 13 Apr 2012 01:48:01 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9D99E21F8613 for ; Fri, 13 Apr 2012 01:47:59 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q3D8lsYN019633; Fri, 13 Apr 2012 10:47:54 +0200 From: "Jose Saldana" To: Subject: A suggestion for draft-polk-tsvwg-rfc4594-update Date: Fri, 13 Apr 2012 10:47:58 +0200 Organization: Universidad de Zaragoza Message-ID: <002101cd1952$208c7120$61a55360$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD1962.E416C7C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0ZSOBVvIv9Ogj2S4SbIGEsooJAXw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: =?iso-8859-1?Q?Jos=E9_Garc=EDa_Moros?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:48:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CD1962.E416C7C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Although I am mainly interested on online games, in my university there = are more serious people working on Telemedicine services. I was wondering if = it could be interesting to include in the draft a class for these kind of services. I have been talking with Jose Garcia, a Professor whose = research interests are in Telemedicine, and he has told me that there are two = kinds of telemedicine services: =20 - Non real-time: e.g. I send a radiography, and the doctor will have it this afternoon. - Real-time: examples: o A doctor is in a hospital in a big town. A nurse is in a small = village with a patient. There is a service including video, voice and an electrocardiogram signal established from the village to the hospital, = that allows a single doctor to attend a number of villages. o Another example: An ambulance carrying an injured man going to the hospital, and connected to the Internet using the mobile cellular = network to send the electrocardiogram, voice, etc. to a doctor who is waiting in = the hospital. =20 So we could think in the working group the possibility of including some service class for this. If we are trying to reduce latency for VoIP or online games, why not thinking about this? =20 This would be similar to what we do in real-life: letting the ambulance pass. Logically, we would have to be careful: some =93smarty-pants=94 = person would try to follow the ambulance and take advantage of it. In our case, = a =93smarty-pants=94 gamer could change his traffic in order to have a = bigger priority. =20 What do you think?, =20 Jose Saldana ------=_NextPart_000_0022_01CD1962.E416C7C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Although I am mainly interested on online games, in my = university there are more serious people working on Telemedicine = services. I was wondering if it could be interesting to include in the = draft a class for these kind of services. I have been talking with Jose = Garcia, a Professor whose research interests are in Telemedicine, and he = has told me that there are two kinds of telemedicine = services:

 

-          = Non real-time: e.g. I = send a radiography, and the doctor will have it this = afternoon.

-          = Real-time: = examples:

o   =A0A doctor is in a hospital in a big town. A nurse is in a = small village with a patient. There is a service including video, voice = and an electrocardiogram signal established from the village to the = hospital, that allows a single doctor to attend a number of = villages.

o   Another example: An ambulance carrying an injured man going = to the hospital, and connected to the Internet using the mobile cellular = network to send the electrocardiogram, voice, etc. to a doctor who is = waiting in the hospital.

 

So we could think in the working group the possibility of = including some service class for this. If we are trying to reduce = latency for VoIP or online games, why not thinking about = this?

 

This would be similar to what we do in real-life: letting = the ambulance pass. Logically, we would have to be careful: some = “smarty-pants” person would try to follow the ambulance and = take advantage of it. In our case, a “smarty-pants” gamer = could change his traffic in order to have a bigger = priority.

 

What do you think?,

 

Jose Saldana

------=_NextPart_000_0022_01CD1962.E416C7C0-- From acmorton@att.com Fri Apr 13 04:16:36 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67AD21F87D3 for ; Fri, 13 Apr 2012 04:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.631 X-Spam-Level: X-Spam-Status: No, score=-103.631 tagged_above=-999 required=5 tests=[AWL=-1.835, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT+rw70to26q for ; Fri, 13 Apr 2012 04:16:36 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1D93C21F87D2 for ; Fri, 13 Apr 2012 04:16:36 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 31b088f4.0.912875.00-488.1850767.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 13 Apr 2012 11:16:36 +0000 (UTC) X-MXL-Hash: 4f880b143b59aa44-21777072663f7a77042b0a8a327023fd7da22c59 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3DBGZqq020995 for ; Fri, 13 Apr 2012 07:16:35 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q3DBGTnv020966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Apr 2012 07:16:30 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Fri, 13 Apr 2012 07:16:08 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DBG8Hj025138 for ; Fri, 13 Apr 2012 07:16:08 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q3DBFvB6024587 for ; Fri, 13 Apr 2012 07:16:00 -0400 Message-Id: <201204131116.q3DBFvB6024587@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-90-108.vpn.swst.att.com[135.70.90.108](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120413111254gw1004orc0e>; Fri, 13 Apr 2012 11:12:55 +0000 X-Originating-IP: [135.70.90.108] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Apr 2012 07:17:06 -0400 To: jsaldana@unizar.es, From: Al Morton Subject: Re: A suggestion for draft-polk-tsvwg-rfc4594-update In-Reply-To: <002101cd1952$208c7120$61a55360$@unizar.es> References: <002101cd1952$208c7120$61a55360$@unizar.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=GzuGQrjJkWcA:10 a=tSoHJD8KhDUA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=vZDCaFUJiezEYHti2rAA:9 a=8NXTfSppfEuWOsijG] X-AnalysisOut: [6UA:7 a=CjuIK1q_8ugA:10] Cc: =?iso-8859-1?Q?Jos=E9?= =?iso-8859-1?Q?_Garc=EDa?= Moros X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 11:16:36 -0000 At 04:47 AM 4/13/2012, Jose Saldana wrote: > ... > >This would be similar to what we do in real-life: letting the >ambulance pass. Logically, we would have to be careful: some >"smarty-pants" person would try to follow the ambulance and take >advantage of it. In our case, a "smarty-pants" gamer could change >his traffic in order to have a bigger priority. > >What do you think? Hi Jose, You are discussing two mechanisms in series: - classifying telemedicine traffic by itself - arranging that (some) telemedicine traffic has priority treatment I don't think it is in scope to establish relative class priorities. There *should* be other classes whose characteristics can satisfy the needs of the telemedicine applications you describe (there are many classes!), and priority can be established in many ways. It is a common tendency to identify a new application and decide it needs special treatment in a class by itself, that's partly how we arrived were we are, IMO. regards, Al From jmpolk@cisco.com Fri Apr 13 12:05:07 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC3B21F8664 for ; Fri, 13 Apr 2012 12:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.273 X-Spam-Level: X-Spam-Status: No, score=-110.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHQrCxG2AWLA for ; Fri, 13 Apr 2012 12:05:07 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9B03321F865F for ; Fri, 13 Apr 2012 12:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1472; q=dns/txt; s=iport; t=1334343906; x=1335553506; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=8wGMYjnup2lbaO6zKKAAcGL8tX+h0HIYVFvz8agDrYM=; b=jT8DG3CA8izMhRU2xK9TvTMtboAkq23Xc3BadECB4qHuYJQo80Ry8pWS hEeQ3ttsKxfKWAyhUe9CqMN7NrHddg58dRVo3FUYcQn3EwoHPWMgeNGc2 dpz43IhoLViFHm5bZ02RFo4JK6mRdzK6yMIYbUTuaUFSipKNCpuB03C4F w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJp4iE+rRDoH/2dsb2JhbAA7CrUVgQeCCQEBAQQSASUCPxAHBA4KHhAZPgYBKwmHa5lNn3yLLoYpBIham1+BaYMF X-IronPort-AV: E=Sophos;i="4.75,418,1330905600"; d="scan'208";a="40474677" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 13 Apr 2012 19:05:06 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3DJ55aN022433; Fri, 13 Apr 2012 19:05:05 GMT Message-Id: <201204131905.q3DJ55aN022433@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 13 Apr 2012 14:05:05 -0500 To: Al Morton , jsaldana@unizar.es, From: "James M. Polk" Subject: Re: A suggestion for draft-polk-tsvwg-rfc4594-update In-Reply-To: <201204131116.q3DBFvB6024587@alpd052.aldc.att.com> References: <002101cd1952$208c7120$61a55360$@unizar.es> <201204131116.q3DBFvB6024587@alpd052.aldc.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: =?iso-8859-1?Q?Jos=E9?= =?iso-8859-1?Q?_Garc=EDa?= Moros X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 19:05:07 -0000 At 06:17 AM 4/13/2012, Al Morton wrote: >At 04:47 AM 4/13/2012, Jose Saldana wrote: >> ... >> >>This would be similar to what we do in real-life: letting the >>ambulance pass. Logically, we would have to be careful: some >>"smarty-pants" person would try to follow the ambulance and take >>advantage of it. In our case, a "smarty-pants" gamer could change >>his traffic in order to have a bigger priority. >> >>What do you think? > >Hi Jose, > >You are discussing two mechanisms in series: > > - classifying telemedicine traffic by itself > - arranging that (some) telemedicine traffic has priority treatment > >I don't think it is in scope to establish relative class priorities. > >There *should* be other classes whose characteristics can satisfy >the needs of the telemedicine applications you describe >(there are many classes!), and priority can be established in many ways. >It is a common tendency to identify a new application and decide >it needs special treatment in a class by itself, that's partly how >we arrived were we are, IMO. I agree with Al. We're trying to avoid application specific service classes, but rather determine the necessary traffic characteristics for applications, then slotting those applications into service classes - if, and only if - they are widely used. There are exceptions to this rule in both directions. But we want to keep them to a minimum. James >regards, >Al > > From jsaldana@unizar.es Mon Apr 16 05:32:43 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FB921F85F9 for ; Mon, 16 Apr 2012 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FT8ovDKYzX7j for ; Mon, 16 Apr 2012 05:32:42 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5E04221F85E4 for ; Mon, 16 Apr 2012 05:32:42 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q3GCWRHb004818; Mon, 16 Apr 2012 14:32:28 +0200 From: "Jose Saldana" To: "'James M. Polk'" , "'Al Morton'" , References: <002101cd1952$208c7120$61a55360$@unizar.es> <201204131116.q3DBFvB6024587@alpd052.aldc.att.com> <201204131905.q3DJ55aN022433@mtv-core-2.cisco.com> In-Reply-To: <201204131905.q3DJ55aN022433@mtv-core-2.cisco.com> Subject: RE: A suggestion for draft-polk-tsvwg-rfc4594-update Date: Mon, 16 Apr 2012 14:32:32 +0200 Organization: Universidad de Zaragoza Message-ID: <005701cd1bcc$ff9cb1f0$fed615d0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKiSjN/nCQYPeqvdazZDKK5uiPX1gE892VwAkyKBY6U1rT1gA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: =?iso-8859-1?Q?'Jos=E9_Garc=EDa_Moros'?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 12:32:43 -0000 I think I get the point: if we have two VoIP conversations, one from an ambulance carrying an injured man, and other one from a VoIP client, = then the two conversations have the same delay requirements, so they should = be in the same service class. The problem of prioritizing the first one does = not have to be solved by rfc4594-update. Perhaps the access provider may = have a special channel for ambulances, or something like that. The different types of telemedicine can be found here: http://en.wikipedia.org/wiki/Telemedicine#Types_of_telemedicine. Perhaps = it is correct that none of them can be seen as a new service. Perhaps telesurgery (http://en.wikipedia.org/wiki/Telemedicine#Telesurgery), but = I don't think it is a good idea to use the Internet to do telesurgery (at least if I am the patient). A dedicated link should be necessary in this case. Best regards, Jose -----Mensaje original----- De: James M. Polk [mailto:jmpolk@cisco.com]=20 Enviado el: viernes, 13 de abril de 2012 21:05 Para: Al Morton; jsaldana@unizar.es; tsvwg@ietf.org CC: Jos=E9 Garc=EDa Moros Asunto: Re: A suggestion for draft-polk-tsvwg-rfc4594-update At 06:17 AM 4/13/2012, Al Morton wrote: >At 04:47 AM 4/13/2012, Jose Saldana wrote: >> ... >> >>This would be similar to what we do in real-life: letting the=20 >>ambulance pass. Logically, we would have to be careful: some=20 >>"smarty-pants" person would try to follow the ambulance and take=20 >>advantage of it. In our case, a "smarty-pants" gamer could change his=20 >>traffic in order to have a bigger priority. >> >>What do you think? > >Hi Jose, > >You are discussing two mechanisms in series: > > - classifying telemedicine traffic by itself > - arranging that (some) telemedicine traffic has priority treatment > >I don't think it is in scope to establish relative class priorities. > >There *should* be other classes whose characteristics can satisfy the=20 >needs of the telemedicine applications you describe (there are many=20 >classes!), and priority can be established in many ways. >It is a common tendency to identify a new application and decide it=20 >needs special treatment in a class by itself, that's partly how we=20 >arrived were we are, IMO. I agree with Al. We're trying to avoid application specific service = classes, but rather determine the necessary traffic characteristics for = applications, then slotting those applications into service classes - if, and only if = - they are widely used. There are exceptions to this rule in both = directions. But we want to keep them to a minimum. James >regards, >Al > > From wwwrun@rfc-editor.org Tue Apr 17 00:25:41 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B7C21F8551 for ; Tue, 17 Apr 2012 00:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.231 X-Spam-Level: X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WctZZm3p+2KF for ; Tue, 17 Apr 2012 00:25:37 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1072E21F854F for ; Tue, 17 Apr 2012 00:25:37 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B3CDB62199; Tue, 17 Apr 2012 00:24:40 -0700 (PDT) To: fred@cisco.com, jmpolk@cisco.com, mdolly@att.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, gorry@erg.abdn.ac.uk, jmpolk@cisco.com Subject: [Editorial Errata Reported] RFC5865 (3194) From: RFC Errata System Message-Id: <20120417072440.B3CDB62199@rfc-editor.org> Date: Tue, 17 Apr 2012 00:24:40 -0700 (PDT) Cc: sergey.antipov@nsn.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:25:41 -0000 The following errata report has been submitted for RFC5865, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5865&eid=3194 -------------------------------------- Type: Editorial Reported by: Sergey Antipov Section: 2.2 Original Text ------------- There are at least six major ways that capacity admission is done or has been proposed to be done for real-time applications. Each will be described below, and Section 3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class. These include: Corrected Text -------------- There are at least six major ways that capacity admission is done or has been proposed to be done for real-time applications. Each will be described below, and Section 2.3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class. These include: Notes ----- Section 2.3 is the one, which recommends capacity admission procedures, while Section 3 summarizes proposed changes. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5865 (draft-ietf-tsvwg-admitted-realtime-dscp-07) -------------------------------------- Title : A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic Publication Date : May 2010 Author(s) : F. Baker, J. Polk, M. Dolly Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From fred@cisco.com Tue Apr 17 00:45:47 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DA521F8589 for ; Tue, 17 Apr 2012 00:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c3RvjFhcfQ8 for ; Tue, 17 Apr 2012 00:45:42 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7021F8587 for ; Tue, 17 Apr 2012 00:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2330; q=dns/txt; s=iport; t=1334648742; x=1335858342; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=dW3Hvwu6dpJ6qgyuDH+ZHda5LshFP0M2HMEDcsMrRYk=; b=BKRB/uDJ4d3//gUpigC10ZcBFE5uUDc73lyf4n/2QpBaT57tph5gK63T 4pjYQMnkcPPIpB6AoW5wNiaiabaozLfnXCpe2/Ty0Y7o/MZFt5CWbl5MP mDduP4cNGkd2ng2XRrcAFQPeftBtP5ESYFsIe16BkLYs+AVm15pARLJZj c=; X-IronPort-AV: E=Sophos;i="4.75,433,1330905600"; d="scan'208";a="10240440" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 17 Apr 2012 07:45:40 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q3H7jarX010152; Tue, 17 Apr 2012 07:45:37 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 17 Apr 2012 00:45:39 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 17 Apr 2012 00:45:39 -0700 Subject: Re: [Editorial Errata Reported] RFC5865 (3194) Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <20120417072440.B3CDB62199@rfc-editor.org> Date: Tue, 17 Apr 2012 00:44:48 -0700 Message-Id: <47D41F4E-BDFD-4210-A1D0-DC60DB91C77B@cisco.com> References: <20120417072440.B3CDB62199@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: gorry@erg.abdn.ac.uk, tsvwg@ietf.org, mdolly@att.com, jmpolk@cisco.com, sergey.antipov@nsn.com X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:45:47 -0000 I am not opposed to the erratum. On Apr 17, 2012, at 12:24 AM, RFC Errata System wrote: >=20 > The following errata report has been submitted for RFC5865, > "A Differentiated Services Code Point (DSCP) for Capacity-Admitted = Traffic". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5865&eid=3D3194 >=20 > -------------------------------------- > Type: Editorial > Reported by: Sergey Antipov >=20 > Section: 2.2 >=20 > Original Text > ------------- > There are at least six major ways that capacity admission is done or >=20 > has been proposed to be done for real-time applications. Each will >=20 > be described below, and Section 3 will judge which ones are likely = to >=20 > meet the requirements of the Admitted Telephony service class. = These >=20 > include: >=20 >=20 >=20 > Corrected Text > -------------- > There are at least six major ways that capacity admission is done or >=20 > has been proposed to be done for real-time applications. Each will >=20 > be described below, and Section 2.3 will judge which ones are likely = to >=20 > meet the requirements of the Admitted Telephony service class. = These >=20 > include: >=20 >=20 >=20 > Notes > ----- > Section 2.3 is the one, which recommends capacity admission = procedures, while Section 3 summarizes proposed changes. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC5865 (draft-ietf-tsvwg-admitted-realtime-dscp-07) > -------------------------------------- > Title : A Differentiated Services Code Point (DSCP) for = Capacity-Admitted Traffic > Publication Date : May 2010 > Author(s) : F. Baker, J. Polk, M. Dolly > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG From jmpolk@cisco.com Tue Apr 17 11:35:14 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04121F84EE for ; Tue, 17 Apr 2012 11:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.328 X-Spam-Level: X-Spam-Status: No, score=-110.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gG2Z9c--qWQf for ; Tue, 17 Apr 2012 11:35:09 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9702321F84F1 for ; Tue, 17 Apr 2012 11:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=2438; q=dns/txt; s=iport; t=1334687709; x=1335897309; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=lshf9CYjwzlvDCxuo5gTYssQDTc6RCPithhpeWPrSNg=; b=Hf44uHIFrb8FPxOQ/aPEL6knQ136wNPwYMqFZrtStpmhbKEETiR0en38 IN2ELv9AN5s7gNXj7n+eMGHCxZjbDv3vsIun9igF2yD31VB2sX4Zxlx3B zfoUnt9dVquMLPYBGj1MUJuhaJl9bP4qlBpEHA70jwidJ8BilRMhaRPWS 0=; X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="37845400" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 17 Apr 2012 18:35:09 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3HIZ8Rf011173; Tue, 17 Apr 2012 18:35:08 GMT Message-Id: <201204171835.q3HIZ8Rf011173@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Apr 2012 13:35:07 -0500 To: Fred Baker , RFC Errata System From: "James M. Polk" Subject: Re: [Editorial Errata Reported] RFC5865 (3194) In-Reply-To: <47D41F4E-BDFD-4210-A1D0-DC60DB91C77B@cisco.com> References: <20120417072440.B3CDB62199@rfc-editor.org> <47D41F4E-BDFD-4210-A1D0-DC60DB91C77B@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: gorry@erg.abdn.ac.uk, mdolly@att.com, jmpolk@cisco.com, sergey.antipov@nsn.com, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:35:14 -0000 Nor am I. At 02:44 AM 4/17/2012, Fred Baker wrote: >I am not opposed to the erratum. > >On Apr 17, 2012, at 12:24 AM, RFC Errata System wrote: > > > > > The following errata report has been submitted for RFC5865, > > "A Differentiated Services Code Point (DSCP) for > Capacity-Admitted Traffic". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5865&eid=3194 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Sergey Antipov > > > > Section: 2.2 > > > > Original Text > > ------------- > > There are at least six major ways that capacity admission is done or > > > > has been proposed to be done for real-time applications. Each will > > > > be described below, and Section 3 will judge which ones are likely to > > > > meet the requirements of the Admitted Telephony service class. These > > > > include: > > > > > > > > Corrected Text > > -------------- > > There are at least six major ways that capacity admission is done or > > > > has been proposed to be done for real-time applications. Each will > > > > be described below, and Section 2.3 will judge which ones are likely to > > > > meet the requirements of the Admitted Telephony service class. These > > > > include: > > > > > > > > Notes > > ----- > > Section 2.3 is the one, which recommends capacity admission > procedures, while Section 3 summarizes proposed changes. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5865 (draft-ietf-tsvwg-admitted-realtime-dscp-07) > > -------------------------------------- > > Title : A Differentiated Services Code Point (DSCP) > for Capacity-Admitted Traffic > > Publication Date : May 2010 > > Author(s) : F. Baker, J. Polk, M. Dolly > > Category : PROPOSED STANDARD > > Source : Transport Area Working Group > > Area : Transport > > Stream : IETF > > Verifying Party : IESG From Karen.Nielsen@tieto.com Wed Apr 18 00:25:47 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36F721F8624; Wed, 18 Apr 2012 00:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmfi8kBEIfa2; Wed, 18 Apr 2012 00:25:43 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3773A21F85E7; Wed, 18 Apr 2012 00:25:41 -0700 (PDT) X-AuditID: 83cfa824-b7d03ae000000a92-34-4f8e6c74808e Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 09.5C.02706.47C6E8F4; Wed, 18 Apr 2012 10:25:40 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.2.108]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Wed, 18 Apr 2012 10:25:28 +0300 From: To: Date: Wed, 18 Apr 2012 10:25:26 +0300 Subject: RE: [tcpm] CWND increase after under-utilization in congestion avoidance Thread-Topic: [tcpm] CWND increase after under-utilization in congestion avoidance Thread-Index: Ac0c2cpBnjqIMcfVSrOQ3+AFwCMyoQAVWJ3w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: tcpm@ietf.org, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:25:47 -0000 Hi, Thanks a lot!=20 My main concern is the slope of the increase of the CWND after a period of = CWND underutilization in congestion avoidance phase. My general understanding of the standards is that during slow start one may= raise the CWND per received (S)ACK whereas during congestion avoidance gen= erally CWND may be increase by one MTU only per RTT. Then some of the more = experimental CC algorithms allow for slow start slope increase after a pack= et loss, but that may be a sidetrack here. At least my question really goes= to the base standard of SCTP as specified in RFC4960. But I assume that th= e question is equally relevant for a TCP implementation that implements CWN= D validation in some form. The assumption here is that we are in congestion avoidance phase, but also = that the accumulated partical_bytes_ack can allow for several increases of = the CWND within the same RTT as SACKs will be returned. Provided that the a= pplication continues to fill the increasing CWND, the question is whether S= CTP (TCP) then is allowed to proactively increase the CWND several times pe= r RTT (slow start slope) or whether the increase should be limited to be do= ne one per RTT (congestion avoidance slope). Thanks! BR, Karen -----Original Message----- From: Matt Mathis [mailto:mattmathis@google.com]=20 Sent: 17. april 2012 22:37 To: Nielsen Karen Cc: tcpm@ietf.org Subject: Re: [tcpm] CWND increase after under-utilization in congestion avo= idance Well, my opinion would be that as long as flightsize >=3D cwnd at least once recently it should be ok to continue to raise cwnd. Note that raising cwnd probably causes the predicate to become not true. Also "recently" should be no shorter than one RTT, but may be a longer (the details are not so important). The point is that as long as FS reaches cwnd at least once per RTT, it is fine to continue to grow the window. I believe I have seen it implemented "as long as FS comes close to cwnd..." In the big picture is it important not to keep raising cwnd if cwnd in not controlling the connection, because then you have no way to know if it is a valid measure of anything useful. However, as long as cwnd has been "tested" it is fine to keep pushing it up. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Tue, Apr 17, 2012 at 5:50 AM, wrote: > Hi, > > > > SCTP as prescribed by RFC4960 operates with CWND validation in that CWND > increase always > > is subject to its fully usage. That is, CWND only may increase when > flightsize >=3D CWND. > > Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily > increased even when partial_bytes_ack > > increases beyond the present CWND. > > > > An implementation which boldly augments the partial_bytes_ack during the > time where a CWND is underutilized (but the connection is not idle) may > observe that the partial_bytes_ack increases to a very high value, possib= ly > it increases to > > a value many times higher than the CWND. > > > > The question now arises what should happen once the CWND resumes fully > utilization and thus may be increased. That is, is the intention of the > standard of SCTP CC to have : > > 1.=A0=A0=A0=A0=A0 the CWND now be increased as during "normal" congestion= control > avoidance, i.e., one MTU per acked CWND amount=A0 of data > > -=A0=A0=A0=A0=A0=A0=A0 Or to have - > > 2.=A0=A0=A0=A0=A0 the CWND now be allowed to recapture the growth that it= did not > realize due to under-utilization but which may be recaptured from the > partial_bytes_ack value. I.e., let it be increased one MTU per SACK until > partial_bytes_ack has been decreased below CWND, one CWND at a time. > > > > From an implementation perspective the question likely turns into a quest= ion > about the maintaining of the partial_bytes_ack value during the period of > time when the CWND is underutilized. E.g., should then partial_bytes_ack = be > decreased with CWND for each times it increases beyond the CWND or should= it > be allowed to increase unlimited. =A0But first we need to find out what t= he > intention of the standard is.. > > > > The above of course is subject to cumulative SACKs and other details like > that. I hope that we can leave such details out of the discussion. > > > > I hope that you may help. > > > > Thanks in advance! > > > > BR, Karen > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From Karen.Nielsen@tieto.com Wed Apr 18 00:53:07 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27521F8616 for ; Wed, 18 Apr 2012 00:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+1tt4ExNEUQ for ; Wed, 18 Apr 2012 00:53:02 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id DADB821F8497 for ; Wed, 18 Apr 2012 00:52:29 -0700 (PDT) X-AuditID: 83cfa824-b7d03ae000000a92-e6-4f8e72bc055d Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id CD.50.02706.CB27E8F4; Wed, 18 Apr 2012 10:52:28 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.2.108]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Wed, 18 Apr 2012 10:52:17 +0300 From: To: , Date: Wed, 18 Apr 2012 10:52:16 +0300 Subject: FW: [tcpm] CWND increase after under-utilization in congestion avoidance Thread-Topic: [tcpm] CWND increase after under-utilization in congestion avoidance Thread-Index: Ac0c2cpBnjqIMcfVSrOQ3+AFwCMyoQAVWJ3wAAFZTxA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:53:07 -0000 Hi, I am sorry to bother you again. My emails to tsvwg generally bounces back... I do not know if you are interested in the following topic. We have checked the BSD code and it seems that BSD SCTP allows for=20 slow start type increase of the CWND if the accumulated partial_bytes_ack a= llows=20 after a situation with CWND underutilization in congestion avoidance phase. Do you know if that is a conscious choice and/or if that is how you see the RFC4960 precription ? (which then is perfectly mute on what to do w= ith the partial_bytes-ack value in this situation). Actually I/we think that it should not be like this, namely that the partia= l_bytes_ack should not be allowed to increase much above CWND - so that it = will allow for only one +MTU increase of the CWND per RTT in congestion avo= idance phase. It is then an implementation decision as to how exactly to handle the parti= al_bytes_ack in the under-utilization phase and which value to start with o= nce the condition for CWND (flightsize >=3D CWND) resumes to be met. BR, Karen -----Original Message----- From: Nielsen Karen=20 Sent: 18. april 2012 09:25 To: 'Matt Mathis' Cc: tcpm@ietf.org; tsvwg@ietf.org Subject: RE: [tcpm] CWND increase after under-utilization in congestion avo= idance Hi, Thanks a lot!=20 My main concern is the slope of the increase of the CWND after a period of = CWND underutilization in congestion avoidance phase. My general understanding of the standards is that during slow start one may= raise the CWND per received (S)ACK whereas during congestion avoidance gen= erally CWND may be increase by one MTU only per RTT. Then some of the more = experimental CC algorithms allow for slow start slope increase after a pack= et loss, but that may be a sidetrack here. At least my question really goes= to the base standard of SCTP as specified in RFC4960. But I assume that th= e question is equally relevant for a TCP implementation that implements CWN= D validation in some form. The assumption here is that we are in congestion avoidance phase, but also = that the accumulated partical_bytes_ack can allow for several increases of = the CWND within the same RTT as SACKs will be returned. Provided that the a= pplication continues to fill the increasing CWND, the question is whether S= CTP (TCP) then is allowed to proactively increase the CWND several times pe= r RTT (slow start slope) or whether the increase should be limited to be do= ne one per RTT (congestion avoidance slope). Thanks! BR, Karen -----Original Message----- From: Matt Mathis [mailto:mattmathis@google.com]=20 Sent: 17. april 2012 22:37 To: Nielsen Karen Cc: tcpm@ietf.org Subject: Re: [tcpm] CWND increase after under-utilization in congestion avo= idance Well, my opinion would be that as long as flightsize >=3D cwnd at least once recently it should be ok to continue to raise cwnd. Note that raising cwnd probably causes the predicate to become not true. Also "recently" should be no shorter than one RTT, but may be a longer (the details are not so important). The point is that as long as FS reaches cwnd at least once per RTT, it is fine to continue to grow the window. I believe I have seen it implemented "as long as FS comes close to cwnd..." In the big picture is it important not to keep raising cwnd if cwnd in not controlling the connection, because then you have no way to know if it is a valid measure of anything useful. However, as long as cwnd has been "tested" it is fine to keep pushing it up. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Tue, Apr 17, 2012 at 5:50 AM, wrote: > Hi, > > > > SCTP as prescribed by RFC4960 operates with CWND validation in that CWND > increase always > > is subject to its fully usage. That is, CWND only may increase when > flightsize >=3D CWND. > > Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily > increased even when partial_bytes_ack > > increases beyond the present CWND. > > > > An implementation which boldly augments the partial_bytes_ack during the > time where a CWND is underutilized (but the connection is not idle) may > observe that the partial_bytes_ack increases to a very high value, possib= ly > it increases to > > a value many times higher than the CWND. > > > > The question now arises what should happen once the CWND resumes fully > utilization and thus may be increased. That is, is the intention of the > standard of SCTP CC to have : > > 1.=A0=A0=A0=A0=A0 the CWND now be increased as during "normal" congestion= control > avoidance, i.e., one MTU per acked CWND amount=A0 of data > > -=A0=A0=A0=A0=A0=A0=A0 Or to have - > > 2.=A0=A0=A0=A0=A0 the CWND now be allowed to recapture the growth that it= did not > realize due to under-utilization but which may be recaptured from the > partial_bytes_ack value. I.e., let it be increased one MTU per SACK until > partial_bytes_ack has been decreased below CWND, one CWND at a time. > > > > From an implementation perspective the question likely turns into a quest= ion > about the maintaining of the partial_bytes_ack value during the period of > time when the CWND is underutilized. E.g., should then partial_bytes_ack = be > decreased with CWND for each times it increases beyond the CWND or should= it > be allowed to increase unlimited. =A0But first we need to find out what t= he > intention of the standard is.. > > > > The above of course is subject to cumulative SACKs and other details like > that. I hope that we can leave such details out of the discussion. > > > > I hope that you may help. > > > > Thanks in advance! > > > > BR, Karen > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From bob.briscoe@bt.com Wed Apr 18 11:13:53 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449FA11E8097 for ; Wed, 18 Apr 2012 11:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEjcHWuqBs-5 for ; Wed, 18 Apr 2012 11:13:52 -0700 (PDT) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7C11E8094 for ; Wed, 18 Apr 2012 11:13:52 -0700 (PDT) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 18 Apr 2012 19:13:46 +0100 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Apr 2012 19:13:49 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.247.3; Wed, 18 Apr 2012 19:13:42 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1334772821187; Wed, 18 Apr 2012 19:13:41 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id q3IIDetq019006; Wed, 18 Apr 2012 19:13:40 +0100 Message-ID: <201204181813.q3IIDetq019006@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Apr 2012 19:13:44 +0100 To: John Leslie From: Bob Briscoe Subject: Re: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 In-Reply-To: <20120330155002.GB92614@verdi> References: <4F605902.40009@erg.abdn.ac.uk> <4F730BAC.4040602@erg.abdn.ac.uk> <20120330155002.GB92614@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: Gorry Fairhurst , tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 18:13:53 -0000 John, inline... At 16:50 30/03/2012, John Leslie wrote: >Gorry Fairhurst wrote: > > > > Please respond to the WGLC that ends on Friday 30th March 2012. > > > > Notes to the list would be helpful to complete the WGCC. > > I cannot support this draft as written. > > Perhaps some background would help... > > It will be no secret to anyone following the ConEx WG that Bob and I >fundamentally disagree about whether to model congestion as per-packet >or per-byte. I strongly believe that it's packets that are congested, and >that we'll do better to accurately count congested packets than estimate >congested bytes; Bob seems to strongly believe that we'll do better to >estimate congested bytes than accurately count congested packets. This doesn't need to be personal. There are two co-authors, and this is also the output of everyone else who has contributed (see acks). This is not just me, this is a WG document. If you believe differently, we need to hear a technical argument. There are 5 technical motivating arguments in this doc (S.3) that back up the recommendations. One specifically relates to the recommendations you don't like about the transport layer (S3.4). Then there is a more equivocal discussion in S.5 about whether bit-congestible is more prevalent than pkt-congestible, and whether this might change in future. I have been encouraging you to have this argument out, rather than just saying we shouldn't decide because 'some people' disagree. Let's hear it. I believe the disagreement is rooted in the idea that vendors hit the design limits of equipment performance when they cannot process packets any faster, whereas raw line transmission rates could be a lot faster. The point referred to by this draft [RFC6077] is that vendors then limit the bit-rate of the ports to the packet-processing rates they can achieve with a workload that includes reasonable runs of small packets (what point would there be in faster line rates?). Therefore, at *run-time*, congestion signals from the queues in such equipment generally represent bit-congestion, not packet-congestion, even though the kit was mostly constrained by packet processing during the *design* phase. > When I previously skimmed this document, I believed it contained only >common ground: that AQM should drop/mark packets without favoring small >packets, and that to whatever extent packet size _is_ considered, that >should be a transport-layer responsibility. Good - this is the main thing we wanted to ensure was said. > Alas, when I read it carefully this week, I find that Bob is actually >saying that transport-layer should _only_ consider "congested bytes", not >"congested packets". Assuming we are talking about the general recommendation in 2.3 here, it endorses protocols like TFRC-SP [RFC4828] that weights losses proportionate to packet size within a flow with variable size packets. The recommendation in 2.3 is largely unchanged since Sally Floyd (one of the authors of RFC4828) reviewed byte-pkt. In fact, TFRC-SP wrestled with the possibility that the network, not the transport, could weight its congestion signals relative to packet size. But it didn't even entertain the possibility that congestion might be packet-based not bit-based, so packet size wouldn't be an issue at all. byte-pkt-congest does at least entertain the possibility that prevalent bit-congestion may be a wrong assumption and describes a future where it might be wrong, but it also justifies fairly carefully why it is a safe working assumption and it will continue to be safe, based on advice from equipment designers. (Actually, in reading the latest draft, I notice some of this argument has disappeared in the editing and it now mainly justifies this position by reference to RFC6077. I would be happy to bring some of that removed text back in.) But, I gather that wouldn't satisfy you, because you believe packet-congestion is prevalent, so let's please have that technical discussion. > In fact, Bob openly endorses replacing TCP congestion-control with an >algorithm which calculates "fair-share bytes" and doesn't back off at all >(even in the presence of 20% packet loss) unless you're already sending >more than this "fair-share". I assume you're referring to bullet 1. under "What this advice means for the case of TCP:" in S2.3. If so, that's not how it should read at all. It says " 1. If two TCP flows with different packet sizes are required to run at equal bit rates under the same path conditions, this should be done by altering TCP (Section 4.2.2), not network equipment [...] " This doesn't say TCP should do this, it just says TCP is the place to fiddle, *if* you want to equalise bit-rates. If that's not clear, I would be happy (and I hope Jukka would too) to make it clearer that this recommendation is irrelevant if TCP flows are *not* required to run at equal bit-rates (Personally I would like to say that there should be no need for any equal-bit-rate requirement - however, that *would* be going beyond our charter). How about this text after S2.3. bullet 1? " For the avoidance of doubt, this is not a recommendation that TCP should be changed so that all TCP flows run at equal bit-rates. It is a recommendation that the transport protocol not the network is where any attempt should be made to equalise bit-rates of competing flows, *if* that is ever considered an important requirement. " > I do not believe that is the consensus of this WG; and I believe if >that were the consensus it would exceed our charter. > > The draft contains a number of things I _do_ support; and I'd be happy >to support a considerably shorter draft which concentrates on the AQM >recommendation, omitting any suggestions of modifying TCP congestion >control. We could omit "What this means for TCP" altogether. However, given people of the standing of Sally Floyd originally tried to equalise bit-rates in the network, then moved to doing it in the transport, I don't think it is wise to leave a vacuum. It is our duty to record the advice from this collective experience. But if the wording isn't nuanced correctly, let's change it. Bob >-- >John Leslie ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Thu Apr 19 06:38:04 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415E421F8646 for ; Thu, 19 Apr 2012 06:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.968 X-Spam-Level: X-Spam-Status: No, score=-105.968 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S65zme4kNqnJ for ; Thu, 19 Apr 2012 06:38:02 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 629B321F8532 for ; Thu, 19 Apr 2012 06:38:02 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2EC8E33C20; Thu, 19 Apr 2012 09:38:02 -0400 (EDT) Date: Thu, 19 Apr 2012 09:38:02 -0400 From: John Leslie To: Bob Briscoe Subject: Re: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 Message-ID: <20120419133802.GJ99904@verdi> References: <4F605902.40009@erg.abdn.ac.uk> <4F730BAC.4040602@erg.abdn.ac.uk> <20120330155002.GB92614@verdi> <201204181813.q3IIDetq019006@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201204181813.q3IIDetq019006@bagheera.jungle.bt.co.uk> User-Agent: Mutt/1.4.1i Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 13:38:04 -0000 Bob Briscoe wrote: > > I believe the disagreement is rooted in the idea that vendors hit the > design limits of equipment performance when they cannot process > packets any faster, whereas raw line transmission rates could be a > lot faster. Actually, that's not it at all. >> When I previously skimmed this document, I believed it contained only >> common ground: that AQM should drop/mark packets without favoring small >> packets, and that to whatever extent packet size _is_ considered, that >> should be a transport-layer responsibility. > > Good - this is the main thing we wanted to ensure was said. > >> Alas, when I read it carefully this week, I find that Bob is actually >> saying that transport-layer should _only_ consider "congested bytes", >> not "congested packets". > > In fact, TFRC-SP wrestled with the possibility that the network, not > the transport, could weight its congestion signals relative to packet > size. But it didn't even entertain the possibility that congestion > might be packet-based not bit-based, so packet size wouldn't be an > issue at all. Hopefully, we all can agree the network should not weigh congestion signals by packet size. But that doesn't mean some other layer needs to do so in any "ordinary" case. > byte-pkt-congest does at least entertain the possibility that > prevalent bit-congestion may be a wrong assumption and describes a > future where it might be wrong, but it also justifies fairly > carefully why it is a safe working assumption and it will continue to > be safe, based on advice from equipment designers. (Actually, in > reading the latest draft, I notice some of this argument has > disappeared in the editing and it now mainly justifies this position > by reference to RFC6077. I would be happy to bring some of that > removed text back in.) I very much doubt that what we need here is to add such text. > But, I gather that wouldn't satisfy you, because you believe > packet-congestion is prevalent, so let's please have that technical > discussion. Once again, that's not it at all. My technical argument is it's really-hard to accurately estimate per-packet overhead when counting bits for bit-congestible node pairs; and that counting packets (which we can do accurately) works well in all cases where packet size within a flow is fairly constant. This is basically what we do today; and I'm very resistant to any call to replace it with algorithms which tend to underestimate the overhead when counting payload bytes. >> In fact, Bob openly endorses replacing TCP congestion-control with an >> algorithm which calculates "fair-share bytes" and doesn't back off at all >> (even in the presence of 20% packet loss) unless you're already sending >> more than this "fair-share". BTW, I was very surprised to find "fair-share" as a recommendation in a Bob Briscoe document, given his previous "dismantling a religion" documents. > I assume you're referring to bullet 1. under "What this advice means > for the case of TCP:" in S2.3. Actually, that's not what I was referring to. > It says > " 1. If two TCP flows with different packet sizes are required to run > at equal bit rates under the same path conditions, this should be > done by altering TCP (Section 4.2.2), not network equipment [...] > " More likely, it was Section 4.2.2... I don't think this document needs a 4.2.2 at all. This statement would be stronger if we didn't try to describe possible modifications to TCP. > This doesn't say TCP should do this, it just says TCP is the place to > fiddle, *if* you want to equalise bit-rates. And I didn't find it objectionble until I read the rest of the document carefully. > If that's not clear, I would be happy (and I hope Jukka would too) to > make it clearer that this recommendation is irrelevant if TCP flows > are *not* required to run at equal bit-rates (Personally I would like > to say that there should be no need for any equal-bit-rate > requirement - however, that *would* be going beyond our charter). Maybe we should explore exactly what about our charter excludes such a statement? > How about this text after S2.3. bullet 1? > > " For the avoidance of doubt, this is not a recommendation that TCP > should be changed so that all TCP flows run at equal bit-rates. It is a > recommendation that the transport protocol not the network is where any > attempt should be made to equalise bit-rates of competing flows, *if* > that is ever considered an important requirement. > " I preferred your short-form: " " If you want to equalize bit-rates between TCP flows, this should be " done within TCP, not by network equipment. >> The draft contains a number of things I _do_ support; and I'd be happy >> to support a considerably shorter draft which concentrates on the AQM >> recommendation, omitting any suggestions of modifying TCP congestion >> control. > > We could omit "What this means for TCP" altogether. IMHO, the document would be stronger without it. > However, given people of the standing of Sally Floyd originally tried > to equalise bit-rates in the network, then moved to doing it in the > transport, I don't think it is wise to leave a vacuum. I don't perceive any such vacuum. At most, we might need an informative reference to a Sally Floyd document. -- John Leslie From Karen.Nielsen@tieto.com Fri Apr 20 00:52:41 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1C21F870F for ; Fri, 20 Apr 2012 00:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iziyOXJD3xN7 for ; Fri, 20 Apr 2012 00:52:40 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id B9E7D21F86D8 for ; Fri, 20 Apr 2012 00:52:38 -0700 (PDT) X-AuditID: 83cfa824-b7b25ae000006e91-a2-4f9115c480b5 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 63.93.28305.4C5119F4; Fri, 20 Apr 2012 10:52:36 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.51]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Fri, 20 Apr 2012 10:52:36 +0300 From: To: , , Date: Fri, 20 Apr 2012 10:52:35 +0300 Subject: SCTP CWND increase after under-utilization in congestion avoidance Thread-Topic: SCTP CWND increase after under-utilization in congestion avoidance Thread-Index: Ac0c2cpBnjqIMcfVSrOQ3+AFwCMyoQAVWJ3wAGYNupA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 07:52:41 -0000 Hi, RFC4960 specifies for the partial_bytes_ack (pba) to be uncritically increa= sed upon receipt of SACKs. Uncritically here means also if the CWND is unde= r-utilized, that is, also if flightsize < CWND. Further then once traffic increases (or resumes) and the CWND becomes fully= utilized and SACKs are received, then the prescription is for the CWND to be increases one MTU provided the = pba value >=3D CWND (and pba then set =3D pba - CWND) The pba parameter first was introduced in TCP ABC RFC3465 and the parameter= is used in the implementation to mimic congestion avoidance CWND increase = slope of "+MTU*MTU/CWND per SACK" as specified by RFC5681. Following the prescriptions of RFC4960 uncritically one may have the pba in= crease to multiple times the CWND during a period of CWND underutilization and further, once traffic and CWND utilizat= ion resumes, one may have a situation where the CWND in principle may be in= creases by one MTU per received SACK (more or less) a number of times corre= sponding to the value INT(pba/CWND) until the pba parameter iteratively has= been decreased below present CWND. This effectively results in slow start = slope increase of the CWND during congestion avoidance. Randy and Michael, as authors of the RFc4960, could I ask you to confirm th= at while the explicit handling of the pba in this particular case may be an= implementation decision THEN THE INTENTION of SCTP CC as specified in RFC = 4960 is for the CWND to be increased following congestion avoidance slope i= n this situation (traffic resume after CWND underutilization in congestion = avoidance phase). Many Thanks in advance !! BR, Karen -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of K= aren.Nielsen@tieto.com Sent: 18. april 2012 09:25 To: mattmathis@google.com Cc: tcpm@ietf.org; tsvwg@ietf.org Subject: RE: [tcpm] CWND increase after under-utilization in congestion avo= idance Hi, Thanks a lot!=20 My main concern is the slope of the increase of the CWND after a period of = CWND underutilization in congestion avoidance phase. My general understanding of the standards is that during slow start one may= raise the CWND per received (S)ACK whereas during congestion avoidance gen= erally CWND may be increase by one MTU only per RTT. Then some of the more = experimental CC algorithms allow for slow start slope increase after a pack= et loss, but that may be a sidetrack here. At least my question really goes= to the base standard of SCTP as specified in RFC4960. But I assume that th= e question is equally relevant for a TCP implementation that implements CWN= D validation in some form. The assumption here is that we are in congestion avoidance phase, but also = that the accumulated partical_bytes_ack can allow for several increases of = the CWND within the same RTT as SACKs will be returned. Provided that the a= pplication continues to fill the increasing CWND, the question is whether S= CTP (TCP) then is allowed to proactively increase the CWND several times pe= r RTT (slow start slope) or whether the increase should be limited to be do= ne one per RTT (congestion avoidance slope). Thanks! BR, Karen -----Original Message----- From: Matt Mathis [mailto:mattmathis@google.com]=20 Sent: 17. april 2012 22:37 To: Nielsen Karen Cc: tcpm@ietf.org Subject: Re: [tcpm] CWND increase after under-utilization in congestion avo= idance Well, my opinion would be that as long as flightsize >=3D cwnd at least once recently it should be ok to continue to raise cwnd. Note that raising cwnd probably causes the predicate to become not true. Also "recently" should be no shorter than one RTT, but may be a longer (the details are not so important). The point is that as long as FS reaches cwnd at least once per RTT, it is fine to continue to grow the window. I believe I have seen it implemented "as long as FS comes close to cwnd..." In the big picture is it important not to keep raising cwnd if cwnd in not controlling the connection, because then you have no way to know if it is a valid measure of anything useful. However, as long as cwnd has been "tested" it is fine to keep pushing it up. Thanks, --MM-- The best way to predict the future is to create it. =A0- Alan Kay On Tue, Apr 17, 2012 at 5:50 AM, wrote: > Hi, > > > > SCTP as prescribed by RFC4960 operates with CWND validation in that CWND > increase always > > is subject to its fully usage. That is, CWND only may increase when > flightsize >=3D CWND. > > Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily > increased even when partial_bytes_ack > > increases beyond the present CWND. > > > > An implementation which boldly augments the partial_bytes_ack during the > time where a CWND is underutilized (but the connection is not idle) may > observe that the partial_bytes_ack increases to a very high value, possib= ly > it increases to > > a value many times higher than the CWND. > > > > The question now arises what should happen once the CWND resumes fully > utilization and thus may be increased. That is, is the intention of the > standard of SCTP CC to have : > > 1.=A0=A0=A0=A0=A0 the CWND now be increased as during "normal" congestion= control > avoidance, i.e., one MTU per acked CWND amount=A0 of data > > -=A0=A0=A0=A0=A0=A0=A0 Or to have - > > 2.=A0=A0=A0=A0=A0 the CWND now be allowed to recapture the growth that it= did not > realize due to under-utilization but which may be recaptured from the > partial_bytes_ack value. I.e., let it be increased one MTU per SACK until > partial_bytes_ack has been decreased below CWND, one CWND at a time. > > > > From an implementation perspective the question likely turns into a quest= ion > about the maintaining of the partial_bytes_ack value during the period of > time when the CWND is underutilized. E.g., should then partial_bytes_ack = be > decreased with CWND for each times it increases beyond the CWND or should= it > be allowed to increase unlimited. =A0But first we need to find out what t= he > intention of the standard is.. > > > > The above of course is subject to cumulative SACKs and other details like > that. I hope that we can leave such details out of the discussion. > > > > I hope that you may help. > > > > Thanks in advance! > > > > BR, Karen > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From tuexen@fh-muenster.de Sat Apr 21 00:38:15 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B892521F85D1 for ; Sat, 21 Apr 2012 00:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sleYq9GbKY8p for ; Sat, 21 Apr 2012 00:38:11 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0521F8594 for ; Sat, 21 Apr 2012 00:38:06 -0700 (PDT) Received: from [192.168.1.103] (p508F9123.dip.t-dialin.net [80.143.145.35]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C60CD1C0C0BE9; Sat, 21 Apr 2012 09:38:03 +0200 (CEST) Subject: Re: SCTP CWND increase after under-utilization in congestion avoidance Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Sat, 21 Apr 2012 09:38:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1FF38C9B-CAC7-44C0-8639-B804E3B8D593@fh-muenster.de> References: To: X-Mailer: Apple Mail (2.1257) Cc: tsvwg@ietf.org, randall@lakerest.net X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 07:38:15 -0000 On Apr 20, 2012, at 9:52 AM, = wrote: > Hi, >=20 > RFC4960 specifies for the partial_bytes_ack (pba) to be uncritically = increased upon receipt of SACKs. Uncritically here means also if the = CWND is under-utilized, that is, also if flightsize < CWND. > Further then once traffic increases (or resumes) and the CWND becomes = fully utilized and SACKs are received, > then the prescription is for the CWND to be increases one MTU provided = the pba value >=3D CWND (and pba then set =3D pba - CWND) >=20 > The pba parameter first was introduced in TCP ABC RFC3465 and the = parameter is used in the implementation to mimic congestion avoidance = CWND increase slope of "+MTU*MTU/CWND per SACK" as specified by RFC5681. >=20 > Following the prescriptions of RFC4960 uncritically one may have the = pba increase to multiple times the CWND during a > period of CWND underutilization and further, once traffic and CWND = utilization resumes, one may have a situation where the CWND in = principle may be increases by one MTU per received SACK (more or less) a = number of times corresponding to the value INT(pba/CWND) until the pba = parameter iteratively has been decreased below present CWND. This = effectively results in slow start slope increase of the CWND during = congestion avoidance. >=20 > Randy and Michael, as authors of the RFc4960, could I ask you to = confirm that while the explicit handling of the pba in this particular = case may be an implementation decision THEN THE INTENTION of SCTP CC as = specified in RFC 4960 is for the CWND to be increased following = congestion avoidance slope in this situation (traffic resume after CWND = underutilization in congestion avoidance phase). Hi Karen, the text in RFC 4960 is already in RFC 2960 and it was not intended to = do anything different than TCP CC. The first sentence of section 7.2.2 states the goal: When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address. So I guess the algorithm described after that paragraph doesn't realize = this goal in the scenario you mention. I FreeBSD we try to follow the RFC. Best regards Michael >=20 > Many Thanks in advance !! >=20 > BR, Karen >=20 >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Karen.Nielsen@tieto.com > Sent: 18. april 2012 09:25 > To: mattmathis@google.com > Cc: tcpm@ietf.org; tsvwg@ietf.org > Subject: RE: [tcpm] CWND increase after under-utilization in = congestion avoidance >=20 > Hi, >=20 > Thanks a lot!=20 >=20 > My main concern is the slope of the increase of the CWND after a = period of CWND underutilization in congestion avoidance phase. >=20 > My general understanding of the standards is that during slow start = one may raise the CWND per received (S)ACK whereas during congestion = avoidance generally CWND may be increase by one MTU only per RTT. Then = some of the more experimental CC algorithms allow for slow start slope = increase after a packet loss, but that may be a sidetrack here. At least = my question really goes to the base standard of SCTP as specified in = RFC4960. But I assume that the question is equally relevant for a TCP = implementation that implements CWND validation in some form. >=20 > The assumption here is that we are in congestion avoidance phase, but = also that the accumulated partical_bytes_ack can allow for several = increases of the CWND within the same RTT as SACKs will be returned. = Provided that the application continues to fill the increasing CWND, the = question is whether SCTP (TCP) then is allowed to proactively increase = the CWND several times per RTT (slow start slope) or whether the = increase should be limited to be done one per RTT (congestion avoidance = slope). >=20 > Thanks! >=20 > BR, Karen >=20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: 17. april 2012 22:37 > To: Nielsen Karen > Cc: tcpm@ietf.org > Subject: Re: [tcpm] CWND increase after under-utilization in = congestion avoidance >=20 > Well, my opinion would be that as long as flightsize >=3D cwnd at = least > once recently it should be ok to continue to raise cwnd. Note that > raising cwnd probably causes the predicate to become not true. Also > "recently" should be no shorter than one RTT, but may be a longer (the > details are not so important). The point is that as long as FS > reaches cwnd at least once per RTT, it is fine to continue to grow the > window. I believe I have seen it implemented "as long as FS comes > close to cwnd..." >=20 > In the big picture is it important not to keep raising cwnd if cwnd in > not controlling the connection, because then you have no way to know > if it is a valid measure of anything useful. However, as long as cwnd > has been "tested" it is fine to keep pushing it up. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 >=20 > On Tue, Apr 17, 2012 at 5:50 AM, wrote: >> Hi, >>=20 >>=20 >>=20 >> SCTP as prescribed by RFC4960 operates with CWND validation in that = CWND >> increase always >>=20 >> is subject to its fully usage. That is, CWND only may increase when >> flightsize >=3D CWND. >>=20 >> Opposed to TCP, as standardized by RFC5681, CWND is thus not = necessarily >> increased even when partial_bytes_ack >>=20 >> increases beyond the present CWND. >>=20 >>=20 >>=20 >> An implementation which boldly augments the partial_bytes_ack during = the >> time where a CWND is underutilized (but the connection is not idle) = may >> observe that the partial_bytes_ack increases to a very high value, = possibly >> it increases to >>=20 >> a value many times higher than the CWND. >>=20 >>=20 >>=20 >> The question now arises what should happen once the CWND resumes = fully >> utilization and thus may be increased. That is, is the intention of = the >> standard of SCTP CC to have : >>=20 >> 1. the CWND now be increased as during "normal" congestion = control >> avoidance, i.e., one MTU per acked CWND amount of data >>=20 >> - Or to have - >>=20 >> 2. the CWND now be allowed to recapture the growth that it did = not >> realize due to under-utilization but which may be recaptured from the >> partial_bytes_ack value. I.e., let it be increased one MTU per SACK = until >> partial_bytes_ack has been decreased below CWND, one CWND at a time. >>=20 >>=20 >>=20 >> =46rom an implementation perspective the question likely turns into a = question >> about the maintaining of the partial_bytes_ack value during the = period of >> time when the CWND is underutilized. E.g., should then = partial_bytes_ack be >> decreased with CWND for each times it increases beyond the CWND or = should it >> be allowed to increase unlimited. But first we need to find out what = the >> intention of the standard is.. >>=20 >>=20 >>=20 >> The above of course is subject to cumulative SACKs and other details = like >> that. I hope that we can leave such details out of the discussion. >>=20 >>=20 >>=20 >> I hope that you may help. >>=20 >>=20 >>=20 >> Thanks in advance! >>=20 >>=20 >>=20 >> BR, Karen >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 From randall@lakerest.net Sat Apr 21 05:34:49 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6274721F8576 for ; Sat, 21 Apr 2012 05:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d590enejEwKy for ; Sat, 21 Apr 2012 05:34:45 -0700 (PDT) Received: from lakerest.net (lakerest.net [70.155.160.98]) by ietfa.amsl.com (Postfix) with ESMTP id EC8EF21F8550 for ; Sat, 21 Apr 2012 05:34:44 -0700 (PDT) Received: from [10.1.1.141] (bsd3.lakerest.net [70.155.160.101]) (authenticated bits=0) by lakerest.net (8.14.4/8.14.3) with ESMTP id q3LCXDxY072232 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 21 Apr 2012 08:33:14 -0400 (EDT) (envelope-from randall@lakerest.net) Subject: Re: SCTP CWND increase after under-utilization in congestion avoidance Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Randy Stewart In-Reply-To: Date: Sat, 21 Apr 2012 08:33:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <66FAC039-D7D8-44D6-B9AA-F5B22E319DAE@lakerest.net> References: To: "" X-Mailer: Apple Mail (2.1257) Cc: tuexen@fh-muenster.de, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2012 12:34:49 -0000 Karen: As Michael stated, this algorithm was written out in RFC2960 and was not touched in 4960 to my knowledge. I believe Lixia texted the original = wording (if my memory serves me correct). I guess the thing that is lacking is = reseting pba to 0 when you increase would have increased the cwnd (but were = blocked due to other issues.. i.e. you were not using the full cwnd). And as Michael stated, we try to follow 100% the RFC in the BSD = implementation ;-) R On Apr 20, 2012, at 3:52 AM, = wrote: > Hi, >=20 > RFC4960 specifies for the partial_bytes_ack (pba) to be uncritically = increased upon receipt of SACKs. Uncritically here means also if the = CWND is under-utilized, that is, also if flightsize < CWND. > Further then once traffic increases (or resumes) and the CWND becomes = fully utilized and SACKs are received, > then the prescription is for the CWND to be increases one MTU provided = the pba value >=3D CWND (and pba then set =3D pba - CWND) >=20 > The pba parameter first was introduced in TCP ABC RFC3465 and the = parameter is used in the implementation to mimic congestion avoidance = CWND increase slope of "+MTU*MTU/CWND per SACK" as specified by RFC5681. >=20 > Following the prescriptions of RFC4960 uncritically one may have the = pba increase to multiple times the CWND during a > period of CWND underutilization and further, once traffic and CWND = utilization resumes, one may have a situation where the CWND in = principle may be increases by one MTU per received SACK (more or less) a = number of times corresponding to the value INT(pba/CWND) until the pba = parameter iteratively has been decreased below present CWND. This = effectively results in slow start slope increase of the CWND during = congestion avoidance. >=20 > Randy and Michael, as authors of the RFc4960, could I ask you to = confirm that while the explicit handling of the pba in this particular = case may be an implementation decision THEN THE INTENTION of SCTP CC as = specified in RFC 4960 is for the CWND to be increased following = congestion avoidance slope in this situation (traffic resume after CWND = underutilization in congestion avoidance phase). >=20 > Many Thanks in advance !! >=20 > BR, Karen >=20 >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Karen.Nielsen@tieto.com > Sent: 18. april 2012 09:25 > To: mattmathis@google.com > Cc: tcpm@ietf.org; tsvwg@ietf.org > Subject: RE: [tcpm] CWND increase after under-utilization in = congestion avoidance >=20 > Hi, >=20 > Thanks a lot!=20 >=20 > My main concern is the slope of the increase of the CWND after a = period of CWND underutilization in congestion avoidance phase. >=20 > My general understanding of the standards is that during slow start = one may raise the CWND per received (S)ACK whereas during congestion = avoidance generally CWND may be increase by one MTU only per RTT. Then = some of the more experimental CC algorithms allow for slow start slope = increase after a packet loss, but that may be a sidetrack here. At least = my question really goes to the base standard of SCTP as specified in = RFC4960. But I assume that the question is equally relevant for a TCP = implementation that implements CWND validation in some form. >=20 > The assumption here is that we are in congestion avoidance phase, but = also that the accumulated partical_bytes_ack can allow for several = increases of the CWND within the same RTT as SACKs will be returned. = Provided that the application continues to fill the increasing CWND, the = question is whether SCTP (TCP) then is allowed to proactively increase = the CWND several times per RTT (slow start slope) or whether the = increase should be limited to be done one per RTT (congestion avoidance = slope). >=20 > Thanks! >=20 > BR, Karen >=20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: 17. april 2012 22:37 > To: Nielsen Karen > Cc: tcpm@ietf.org > Subject: Re: [tcpm] CWND increase after under-utilization in = congestion avoidance >=20 > Well, my opinion would be that as long as flightsize >=3D cwnd at = least > once recently it should be ok to continue to raise cwnd. Note that > raising cwnd probably causes the predicate to become not true. Also > "recently" should be no shorter than one RTT, but may be a longer (the > details are not so important). The point is that as long as FS > reaches cwnd at least once per RTT, it is fine to continue to grow the > window. I believe I have seen it implemented "as long as FS comes > close to cwnd..." >=20 > In the big picture is it important not to keep raising cwnd if cwnd in > not controlling the connection, because then you have no way to know > if it is a valid measure of anything useful. However, as long as cwnd > has been "tested" it is fine to keep pushing it up. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 >=20 > On Tue, Apr 17, 2012 at 5:50 AM, wrote: >> Hi, >>=20 >>=20 >>=20 >> SCTP as prescribed by RFC4960 operates with CWND validation in that = CWND >> increase always >>=20 >> is subject to its fully usage. That is, CWND only may increase when >> flightsize >=3D CWND. >>=20 >> Opposed to TCP, as standardized by RFC5681, CWND is thus not = necessarily >> increased even when partial_bytes_ack >>=20 >> increases beyond the present CWND. >>=20 >>=20 >>=20 >> An implementation which boldly augments the partial_bytes_ack during = the >> time where a CWND is underutilized (but the connection is not idle) = may >> observe that the partial_bytes_ack increases to a very high value, = possibly >> it increases to >>=20 >> a value many times higher than the CWND. >>=20 >>=20 >>=20 >> The question now arises what should happen once the CWND resumes = fully >> utilization and thus may be increased. That is, is the intention of = the >> standard of SCTP CC to have : >>=20 >> 1. the CWND now be increased as during "normal" congestion = control >> avoidance, i.e., one MTU per acked CWND amount of data >>=20 >> - Or to have - >>=20 >> 2. the CWND now be allowed to recapture the growth that it did = not >> realize due to under-utilization but which may be recaptured from the >> partial_bytes_ack value. I.e., let it be increased one MTU per SACK = until >> partial_bytes_ack has been decreased below CWND, one CWND at a time. >>=20 >>=20 >>=20 >> =46rom an implementation perspective the question likely turns into a = question >> about the maintaining of the partial_bytes_ack value during the = period of >> time when the CWND is underutilized. E.g., should then = partial_bytes_ack be >> decreased with CWND for each times it increases beyond the CWND or = should it >> be allowed to increase unlimited. But first we need to find out what = the >> intention of the standard is.. >>=20 >>=20 >>=20 >> The above of course is subject to cumulative SACKs and other details = like >> that. I hope that we can leave such details out of the discussion. >>=20 >>=20 >>=20 >> I hope that you may help. >>=20 >>=20 >>=20 >> Thanks in advance! >>=20 >>=20 >>=20 >> BR, Karen >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 ----- Randall Stewart randall@lakerest.net From Karen.Nielsen@tieto.com Sun Apr 22 23:30:28 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDDF21F85D9 for ; Sun, 22 Apr 2012 23:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK3vcffxI-BC for ; Sun, 22 Apr 2012 23:30:26 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2B921F85CC for ; Sun, 22 Apr 2012 23:30:23 -0700 (PDT) X-AuditID: 83cfa824-b7c6bae000005775-0f-4f94f6fdcbba Received: from FIHGA-EXHUB01.eu.tieto.com ( [131.207.136.34]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 61.D0.22389.DF6F49F4; Mon, 23 Apr 2012 09:30:21 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.51]) by FIHGA-EXHUB01.eu.tieto.com ([131.207.136.34]) with mapi; Mon, 23 Apr 2012 09:30:20 +0300 From: To: Date: Mon, 23 Apr 2012 09:30:19 +0300 Subject: RE: SCTP CWND increase after under-utilization in congestion avoidance Thread-Topic: SCTP CWND increase after under-utilization in congestion avoidance Thread-Index: Ac0fuyRDJpbW5wGqSiGX256AVXmoMgBXjBAw Message-ID: References: <66FAC039-D7D8-44D6-B9AA-F5B22E319DAE@lakerest.net> In-Reply-To: <66FAC039-D7D8-44D6-B9AA-F5B22E319DAE@lakerest.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: tuexen@fh-muenster.de, tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 06:30:28 -0000 Hi, Thanks a lot for the comments and for the confirmation. I think, as you say, that the conclusion is that the algorithm as described= in the RFC is not complete and that it need, by implementation choice, to be adjusted= =20 in order to ensure that the CWND does not increase more than 1MTU per RTT i= n congestion avoidance. The exact way this is achieved, either by adjusting how the pba is increase= d when the CWBD is underutilized or by adjusting the CWND increase or the pba value when CWWND usage resumes (o= r something completely different) would then, for now at least, remain an i= mplementation decision. Right ?! BR, Karen BSD implementation can then discuss with itself how to find peace with the = conflicting statements of the RFC in=20 this respect. Difficult to be 100% compliant with all statements, I should = think ;-)=20 -----Original Message----- From: Randy Stewart [mailto:randall@lakerest.net]=20 Sent: 21. april 2012 14:33 To: Nielsen Karen Cc: tsvwg@ietf.org; tuexen@fh-muenster.de Subject: Re: SCTP CWND increase after under-utilization in congestion avoid= ance Karen: As Michael stated, this algorithm was written out in RFC2960 and was not touched in 4960 to my knowledge. I believe Lixia texted the original wordin= g (if my memory serves me correct). I guess the thing that is lacking is rese= ting pba to 0 when you increase would have increased the cwnd (but were blo= cked due to other issues.. i.e. you were not using the full cwnd). And as Michael stated, we try to follow 100% the RFC in the BSD implementat= ion ;-) R On Apr 20, 2012, at 3:52 AM, wrote: > Hi, >=20 > RFC4960 specifies for the partial_bytes_ack (pba) to be uncritically incr= eased upon receipt of SACKs. Uncritically here means also if the CWND is un= der-utilized, that is, also if flightsize < CWND. > Further then once traffic increases (or resumes) and the CWND becomes ful= ly utilized and SACKs are received, > then the prescription is for the CWND to be increases one MTU provided th= e pba value >=3D CWND (and pba then set =3D pba - CWND) >=20 > The pba parameter first was introduced in TCP ABC RFC3465 and the paramet= er is used in the implementation to mimic congestion avoidance CWND increas= e slope of "+MTU*MTU/CWND per SACK" as specified by RFC5681. >=20 > Following the prescriptions of RFC4960 uncritically one may have the pba = increase to multiple times the CWND during a > period of CWND underutilization and further, once traffic and CWND utiliz= ation resumes, one may have a situation where the CWND in principle may be = increases by one MTU per received SACK (more or less) a number of times cor= responding to the value INT(pba/CWND) until the pba parameter iteratively h= as been decreased below present CWND. This effectively results in slow star= t slope increase of the CWND during congestion avoidance. >=20 > Randy and Michael, as authors of the RFc4960, could I ask you to confirm = that while the explicit handling of the pba in this particular case may be = an implementation decision THEN THE INTENTION of SCTP CC as specified in RF= C 4960 is for the CWND to be increased following congestion avoidance slope= in this situation (traffic resume after CWND underutilization in congestio= n avoidance phase). >=20 > Many Thanks in advance !! >=20 > BR, Karen >=20 >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Karen.Nielsen@tieto.com > Sent: 18. april 2012 09:25 > To: mattmathis@google.com > Cc: tcpm@ietf.org; tsvwg@ietf.org > Subject: RE: [tcpm] CWND increase after under-utilization in congestion a= voidance >=20 > Hi, >=20 > Thanks a lot!=20 >=20 > My main concern is the slope of the increase of the CWND after a period o= f CWND underutilization in congestion avoidance phase. >=20 > My general understanding of the standards is that during slow start one m= ay raise the CWND per received (S)ACK whereas during congestion avoidance g= enerally CWND may be increase by one MTU only per RTT. Then some of the mor= e experimental CC algorithms allow for slow start slope increase after a pa= cket loss, but that may be a sidetrack here. At least my question really go= es to the base standard of SCTP as specified in RFC4960. But I assume that = the question is equally relevant for a TCP implementation that implements C= WND validation in some form. >=20 > The assumption here is that we are in congestion avoidance phase, but als= o that the accumulated partical_bytes_ack can allow for several increases o= f the CWND within the same RTT as SACKs will be returned. Provided that the= application continues to fill the increasing CWND, the question is whether= SCTP (TCP) then is allowed to proactively increase the CWND several times = per RTT (slow start slope) or whether the increase should be limited to be = done one per RTT (congestion avoidance slope). >=20 > Thanks! >=20 > BR, Karen >=20 > -----Original Message----- > From: Matt Mathis [mailto:mattmathis@google.com]=20 > Sent: 17. april 2012 22:37 > To: Nielsen Karen > Cc: tcpm@ietf.org > Subject: Re: [tcpm] CWND increase after under-utilization in congestion a= voidance >=20 > Well, my opinion would be that as long as flightsize >=3D cwnd at least > once recently it should be ok to continue to raise cwnd. Note that > raising cwnd probably causes the predicate to become not true. Also > "recently" should be no shorter than one RTT, but may be a longer (the > details are not so important). The point is that as long as FS > reaches cwnd at least once per RTT, it is fine to continue to grow the > window. I believe I have seen it implemented "as long as FS comes > close to cwnd..." >=20 > In the big picture is it important not to keep raising cwnd if cwnd in > not controlling the connection, because then you have no way to know > if it is a valid measure of anything useful. However, as long as cwnd > has been "tested" it is fine to keep pushing it up. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 >=20 > On Tue, Apr 17, 2012 at 5:50 AM, wrote: >> Hi, >>=20 >>=20 >>=20 >> SCTP as prescribed by RFC4960 operates with CWND validation in that CWND >> increase always >>=20 >> is subject to its fully usage. That is, CWND only may increase when >> flightsize >=3D CWND. >>=20 >> Opposed to TCP, as standardized by RFC5681, CWND is thus not necessarily >> increased even when partial_bytes_ack >>=20 >> increases beyond the present CWND. >>=20 >>=20 >>=20 >> An implementation which boldly augments the partial_bytes_ack during the >> time where a CWND is underutilized (but the connection is not idle) may >> observe that the partial_bytes_ack increases to a very high value, possi= bly >> it increases to >>=20 >> a value many times higher than the CWND. >>=20 >>=20 >>=20 >> The question now arises what should happen once the CWND resumes fully >> utilization and thus may be increased. That is, is the intention of the >> standard of SCTP CC to have : >>=20 >> 1. the CWND now be increased as during "normal" congestion control >> avoidance, i.e., one MTU per acked CWND amount of data >>=20 >> - Or to have - >>=20 >> 2. the CWND now be allowed to recapture the growth that it did not >> realize due to under-utilization but which may be recaptured from the >> partial_bytes_ack value. I.e., let it be increased one MTU per SACK unti= l >> partial_bytes_ack has been decreased below CWND, one CWND at a time. >>=20 >>=20 >>=20 >> From an implementation perspective the question likely turns into a ques= tion >> about the maintaining of the partial_bytes_ack value during the period o= f >> time when the CWND is underutilized. E.g., should then partial_bytes_ack= be >> decreased with CWND for each times it increases beyond the CWND or shoul= d it >> be allowed to increase unlimited. But first we need to find out what th= e >> intention of the standard is.. >>=20 >>=20 >>=20 >> The above of course is subject to cumulative SACKs and other details lik= e >> that. I hope that we can leave such details out of the discussion. >>=20 >>=20 >>=20 >> I hope that you may help. >>=20 >>=20 >>=20 >> Thanks in advance! >>=20 >>=20 >>=20 >> BR, Karen >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 ----- Randall Stewart randall@lakerest.net From seggelmann@fh-muenster.de Mon Apr 23 06:35:31 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FBC21F8652; Mon, 23 Apr 2012 06:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsnUSoDmriws; Mon, 23 Apr 2012 06:35:31 -0700 (PDT) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id ED2F621F84EB; Mon, 23 Apr 2012 06:35:27 -0700 (PDT) Received: from [212.201.121.94] (helo=[10.0.1.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1SMJQL-00067V-S7; Mon, 23 Apr 2012 15:35:25 +0200 Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Robin Seggelmann In-Reply-To: <4F731153.6040705@erg.abdn.ac.uk> Date: Mon, 23 Apr 2012 15:35:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> References: <4F731153.6040705@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1257) X-Df-Sender: bWFpbEByb2Jpbi1zZWdnZWxtYW5uLmRl Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 13:35:31 -0000 I just had a look at the draft again, and I'm wondering how the Path MTU = Discovery (section 4.6) is handled when the Don't Fragment bit cannot be = set. If a userland implementation is used, this is the case on Mac OS X, = for example. Best regards Robin On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: > This email announces the start of a working group last call for > draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >=20 > Following the meeting this week, this document is now thought to be = ready to proceed to be published as a BCP. Please send any comments to = the TSVWG list. >=20 > The draft is available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 >=20 > The last call will run for THREE weeks, ending Friday 20th April 2012. >=20 > Emails saying "I support" or "I don't support" publication are also = most helpful in judging the WG consensus. Please let us know if this = draft is useful and seems to provide the correct advice. >=20 > James and Gorry > (TSVWG Chairs) > tsvwg-chairs@ietf.org From martin.becke@uni-due.de Mon Apr 23 07:36:51 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B460821F86C6; Mon, 23 Apr 2012 07:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfrXxigMxWwt; Mon, 23 Apr 2012 07:36:51 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id A5B4321F86B9; Mon, 23 Apr 2012 07:36:49 -0700 (PDT) Received: from HT01.win.uni-due.de (virt080.zim.uni-duisburg-essen.de [132.252.185.80]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id q3NEaedX012450; Mon, 23 Apr 2012 16:36:40 +0200 Received: from ccr02.win.uni-due.de ([169.254.2.188]) by HT01.win.uni-due.de ([132.252.190.233]) with mapi id 14.01.0289.001; Mon, 23 Apr 2012 16:36:39 +0200 From: "Becke, Martin" To: Robin Seggelmann Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Thread-Topic: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Thread-Index: AQHNIVX/4bAVqx5tIkuSiIBtBPyPTZaoWMmA Date: Mon, 23 Apr 2012 14:36:39 +0000 Message-ID: References: <4F731153.6040705@erg.abdn.ac.uk> <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> In-Reply-To: <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.151.201] Content-Type: multipart/alternative; boundary="_000_D15F3562C85C4307A1A22E5EC877A20Duniduede_" MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Cc: "" , "" , "" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:36:51 -0000 --_000_D15F3562C85C4307A1A22E5EC877A20Duniduede_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw so= cket, but I do not think that this will work for a SCTP userland implementa= tion. Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: I just had a look at the draft again, and I'm wondering how the Path MTU Di= scovery (section 4.6) is handled when the Don't Fragment bit cannot be set.= If a userland implementation is used, this is the case on Mac OS X, for ex= ample. Best regards Robin On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: This email announces the start of a working group last call for draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". Following the meeting this week, this document is now thought to be ready t= o proceed to be published as a BCP. Please send any comments to the TSVWG l= ist. The draft is available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 The last call will run for THREE weeks, ending Friday 20th April 2012. Emails saying "I support" or "I don't support" publication are also most he= lpful in judging the WG consensus. Please let us know if this draft is usef= ul and seems to provide the correct advice. James and Gorry (TSVWG Chairs) tsvwg-chairs@ietf.org --_000_D15F3562C85C4307A1A22E5EC877A20Duniduede_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <054B9AF511E99449A28DA4D31F0DCB65@win.uni-due.de> Content-Transfer-Encoding: quoted-printable
AFAIK, on MAC OS X you could do a work around by set the DF bit on a r= aw socket, but I do not think that this will work for a SCTP userland imple= mentation. 


Am 23.04.2012 um 15:35 schrieb Robin Seggelmann:

I just had a look at the draft again, and I'm wondering how the Path MTU Dis= covery (section 4.6) is handled when the Don't Fragment bit cannot be set. = If a userland implementation is used, this is the case on Mac OS X, for exa= mple.

Best regards
Robin





On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote:

This email announces the start of a working group= last call for
draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encap= sulation of SCTP Packets".

Following the meeting this week, this document is= now thought to be ready to proceed to be published as a BCP. Please send a= ny comments to the TSVWG list.

The draft is available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-= udp-encaps-03

The last call will run for THREE weeks, ending Fr= iday 20th April 2012.

Emails saying "I support" or "I do= n't support" publication are also most helpful in judging the WG conse= nsus. Please let us know if this draft is useful and seems to provide the c= orrect advice.

James and Gorry
(TSVWG Chairs)
tsvwg-ch= airs@ietf.org

--_000_D15F3562C85C4307A1A22E5EC877A20Duniduede_-- From Michael.Tuexen@lurchi.franken.de Mon Apr 23 07:49:50 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D18021F8639; Mon, 23 Apr 2012 07:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWcqIREu8DF0; Mon, 23 Apr 2012 07:49:49 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 7F27A21F8630; Mon, 23 Apr 2012 07:49:49 -0700 (PDT) Received: from [192.168.1.103] (p508F9FD0.dip.t-dialin.net [80.143.159.208]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id DE0A71C0B4603; Mon, 23 Apr 2012 16:49:46 +0200 (CEST) Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Michael Tuexen In-Reply-To: Date: Mon, 23 Apr 2012 16:49:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F731153.6040705@erg.abdn.ac.uk> <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> To: "Becke, Martin" X-Mailer: Apple Mail (2.1257) Cc: "" , "" , "" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:49:50 -0000 On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: > AFAIK, on MAC OS X you could do a work around by set the DF bit on a = raw socket, but I do not think that this will work for a SCTP userland = implementation.=20 I guess Robins points is the you SCTP/UDP because you don't have the = privileges to open a raw socket. Some OSes support the controlling of the DF bit for a normal user, some = don't. I'll update the text accordingly. I guess if you can't control the DF = bit, you can't do PMTU discovery. So you need to choose a small MTU value... Or use IPv6, which doesn't = have this problem. Best regards Michael >=20 >=20 > Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: >=20 >> I just had a look at the draft again, and I'm wondering how the Path = MTU Discovery (section 4.6) is handled when the Don't Fragment bit = cannot be set. If a userland implementation is used, this is the case on = Mac OS X, for example. >>=20 >> Best regards >> Robin >>=20 >>=20 >>=20 >>=20 >>=20 >> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >>=20 >>> This email announces the start of a working group last call for >>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP = Packets". >>>=20 >>> Following the meeting this week, this document is now thought to be = ready to proceed to be published as a BCP. Please send any comments to = the TSVWG list. >>>=20 >>> The draft is available at: >>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 >>>=20 >>> The last call will run for THREE weeks, ending Friday 20th April = 2012. >>>=20 >>> Emails saying "I support" or "I don't support" publication are also = most helpful in judging the WG consensus. Please let us know if this = draft is useful and seems to provide the correct advice. >>>=20 >>> James and Gorry >>> (TSVWG Chairs) >>> tsvwg-chairs@ietf.org >=20 From martin.becke@uni-due.de Mon Apr 23 09:06:56 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F64E21F864A; Mon, 23 Apr 2012 09:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbKzvqLwvFIU; Mon, 23 Apr 2012 09:06:55 -0700 (PDT) Received: from mailoutzim.uni-due.de (mailoutzim.uni-due.de [132.252.185.16]) by ietfa.amsl.com (Postfix) with ESMTP id E4DEA21F858B; Mon, 23 Apr 2012 09:06:48 -0700 (PDT) Received: from HT02.win.uni-due.de (virt098.zim.uni-duisburg-essen.de [132.252.185.98]) by mailoutzim.uni-due.de (8.13.1/8.13.1) with ESMTP id q3NG6eGu000760; Mon, 23 Apr 2012 18:06:40 +0200 Received: from ccr02.win.uni-due.de ([169.254.2.188]) by HT02.win.uni-due.de ([132.252.190.234]) with mapi id 14.01.0289.001; Mon, 23 Apr 2012 18:06:41 +0200 From: "Becke, Martin" To: Michael Tuexen Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Thread-Topic: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Thread-Index: AQHNIVX/4bAVqx5tIkuSiIBtBPyPTZaoWMmAgAADqYCAABV8gA== Date: Mon, 23 Apr 2012 16:06:39 +0000 Message-ID: <4F508910-2580-44E0-9F41-D7A87955FD09@uni-due.de> References: <4F731153.6040705@erg.abdn.ac.uk> <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [132.252.151.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: <9FEF210D7CB9D1489D727CA94858F1DB@win.uni-due.de> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org X-Scanned-By: MIMEDefang 2.57 on 132.252.185.16 Cc: "" , "" , "" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:06:56 -0000 Am 23.04.2012 um 16:49 schrieb Michael Tuexen: > On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: >=20 >> AFAIK, on MAC OS X you could do a work around by set the DF bit on a raw= socket, but I do not think that this will work for a SCTP userland impleme= ntation.=20 > I guess Robins points is the you SCTP/UDP because you don't have the priv= ileges to open a raw socket. > Some OSes support the controlling of the DF bit for a normal user, some d= on't. Yes, this results in a privilege issue.=20 >=20 > I'll update the text accordingly. I guess if you can't control the DF bit= , you can't do PMTU discovery. > So you need to choose a small MTU value=85 I agree.=20 Is "you" for you the protocol developer or the user of the protocol. =20 If I, as a user, have enough knowledge about the connection (even without c= ontrol and without PMTUD) I would like to change the value to increase my p= erformance.=20 Martin > Or use IPv6, which doesn't have this problem. >=20 > Best regards > Michael >>=20 >>=20 >> Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: >>=20 >>> I just had a look at the draft again, and I'm wondering how the Path MT= U Discovery (section 4.6) is handled when the Don't Fragment bit cannot be = set. If a userland implementation is used, this is the case on Mac OS X, fo= r example. >>>=20 >>> Best regards >>> Robin >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >>>=20 >>>> This email announces the start of a working group last call for >>>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP Packets". >>>>=20 >>>> Following the meeting this week, this document is now thought to be re= ady to proceed to be published as a BCP. Please send any comments to the TS= VWG list. >>>>=20 >>>> The draft is available at: >>>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 >>>>=20 >>>> The last call will run for THREE weeks, ending Friday 20th April 2012. >>>>=20 >>>> Emails saying "I support" or "I don't support" publication are also mo= st helpful in judging the WG consensus. Please let us know if this draft is= useful and seems to provide the correct advice. >>>>=20 >>>> James and Gorry >>>> (TSVWG Chairs) >>>> tsvwg-chairs@ietf.org >>=20 >=20 From Michael.Tuexen@lurchi.franken.de Mon Apr 23 10:29:49 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17AD821F8721; Mon, 23 Apr 2012 10:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es+twqFaN8qG; Mon, 23 Apr 2012 10:29:48 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 31A9C21F877C; Mon, 23 Apr 2012 10:29:48 -0700 (PDT) Received: from [192.168.1.103] (p508F9FD0.dip.t-dialin.net [80.143.159.208]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 6C8CC1C0B461B; Mon, 23 Apr 2012 19:29:46 +0200 (CEST) Subject: Re: WGLC for draft-ietf-tsvwg-sctp-udp-encaps-03, ending Friday 20th April 2012 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen In-Reply-To: <4F508910-2580-44E0-9F41-D7A87955FD09@uni-due.de> Date: Mon, 23 Apr 2012 19:29:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18C2CE87-ADA7-42C1-8259-4322E144B634@lurchi.franken.de> References: <4F731153.6040705@erg.abdn.ac.uk> <68B83028-8F66-4ACF-9F80-854D0A70BE94@fh-muenster.de> <4F508910-2580-44E0-9F41-D7A87955FD09@uni-due.de> To: "Becke, Martin" X-Mailer: Apple Mail (2.1257) Cc: "" , "" , "" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 17:29:49 -0000 On Apr 23, 2012, at 6:06 PM, Becke, Martin wrote: >=20 > Am 23.04.2012 um 16:49 schrieb Michael Tuexen: >=20 >> On Apr 23, 2012, at 4:36 PM, Becke, Martin wrote: >>=20 >>> AFAIK, on MAC OS X you could do a work around by set the DF bit on a = raw socket, but I do not think that this will work for a SCTP userland = implementation.=20 >> I guess Robins points is the you SCTP/UDP because you don't have the = privileges to open a raw socket. >> Some OSes support the controlling of the DF bit for a normal user, = some don't. >=20 > Yes, this results in a privilege issue.=20 >=20 >>=20 >> I'll update the text accordingly. I guess if you can't control the DF = bit, you can't do PMTU discovery. >> So you need to choose a small MTU value=85 >=20 > I agree.=20 >=20 > Is "you" for you the protocol developer or the user of the protocol. =20= I meant the developer of the SCTP stack... > If I, as a user, have enough knowledge about the connection (even = without control and without PMTUD) I would like to change the value to = increase my performance.=20 ... then you as a user of an SCTP stack providing a socket API will = allow you set the MTU and disable PMTU discovery by using the SCTP_PEER_ADDR_PARAMS = socket option as specified in http://tools.ietf.org/html/rfc6458#section-8.1.12 Best regards Michael >=20 > Martin >=20 >=20 >> Or use IPv6, which doesn't have this problem. >>=20 >> Best regards >> Michael >>>=20 >>>=20 >>> Am 23.04.2012 um 15:35 schrieb Robin Seggelmann: >>>=20 >>>> I just had a look at the draft again, and I'm wondering how the = Path MTU Discovery (section 4.6) is handled when the Don't Fragment bit = cannot be set. If a userland implementation is used, this is the case on = Mac OS X, for example. >>>>=20 >>>> Best regards >>>> Robin >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Mar 28, 2012, at 3:25 PM, Gorry Fairhurst wrote: >>>>=20 >>>>> This email announces the start of a working group last call for >>>>> draft-ietf-tsvwg-sctp-udp-encaps, "UDP Encapsulation of SCTP = Packets". >>>>>=20 >>>>> Following the meeting this week, this document is now thought to = be ready to proceed to be published as a BCP. Please send any comments = to the TSVWG list. >>>>>=20 >>>>> The draft is available at: >>>>> http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-03 >>>>>=20 >>>>> The last call will run for THREE weeks, ending Friday 20th April = 2012. >>>>>=20 >>>>> Emails saying "I support" or "I don't support" publication are = also most helpful in judging the WG consensus. Please let us know if = this draft is useful and seems to provide the correct advice. >>>>>=20 >>>>> James and Gorry >>>>> (TSVWG Chairs) >>>>> tsvwg-chairs@ietf.org >>>=20 >>=20 >=20 >=20 From Ruediger.Geib@telekom.de Tue Apr 24 01:28:12 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2985921F86B4 for ; Tue, 24 Apr 2012 01:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_DE=0.35, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a71T+3elorb9 for ; Tue, 24 Apr 2012 01:28:10 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id E83F321F8691 for ; Tue, 24 Apr 2012 01:28:09 -0700 (PDT) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 24 Apr 2012 10:28:07 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by he110890 ([10.134.92.131]) with mapi; Tue, 24 Apr 2012 10:28:06 +0200 From: To: Date: Tue, 24 Apr 2012 10:28:05 +0200 Subject: RE: About the tunnels: packets per second savings Thread-Topic: About the tunnels: packets per second savings Thread-Index: Ac0TI3xcOH/LIhs8T4KaC7euy7785QOz+nJg Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36B2D@HE111648.emea1.cds.t-internal.com> References: <000601cd1325$9a1afcb0$ce50f610$@unizar.es> In-Reply-To: <000601cd1325$9a1afcb0$ce50f610$@unizar.es> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 08:28:12 -0000 Jose, sorry for being late with my reply. Two of my colleagues replied. Simple ba= ndwidth savings at the access itself would be interesting, especially in the case o= f shared networks. Your proposal is related to the "core" part of the network and as you describe below, high end routers can deal with bigger numbers of packets pe= r second. That's the reason why my colleagues are not interested in working on the su= bject. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 2:14 PM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: About the tunnels: packets per second savings Ruediger, Thank you for your fast response. I will separately answer the two parts o= f your email. First, this message about the tunnels. This afternoon or tomorrow I will send to the list an idea about QoS classes, but I have to think more before sending it. I'm glad to hear that you consider the "tunnels" proposal interesting. Ther= e is another issue that I discussed with Gorry in Paris: the saving in terms of packets per second. I attach a graph of the saving in terms of this parameter using Counter Strike. If you multiplex all the packets you have received e.g. every 20ms, then you will send 50 pps (the inverse of the multiplexing period). So you can save a lot of pps. It is clear that bandwidth saving is interesting, but I have read some papers in which a "packets per second" upper bound in the routers was reported: Section V.A of W. Feng, F. Chang, W. Feng, J. Walpole: "A Traffic Characterization of Popular On-Line Games". IEEE/ACM Trans. Netw., pp. 488-500, 2005. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf Section IV.3 of J. Yu, I. Al-Ajarmeh. "Call Admission Control and Traffic Engineering of VoIP", In Proc. Second Intenational Conference on Digital Telecommunications, IEEE ICDT 2007. http://140.192.40.4:8001/~imad/voip/YuJ-CallAdmin.pdf They not only talk about the bandwidth limitation of routers, but also the packets per second limit. Gorry told me that high-end routers may not have this problem. But low-end routers are not able to back-to-back send small packets, due to the processing limitation. So, do you think this saving is interesting? Since you work in the backbone= , your opinion is important for me, taking into account that I am an Academia researcher, and sometimes we are a little far from real things. Perhaps you may ask some of your colleagues. Thanks, Jose -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el: jueves, 05 de abril de 2012 12:23 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, (...) I have removed the first part of the message for clarity. Then regarding tunnels and header compression Yes, that's smart and there may be more use cases than gaming. I'm a backbone engineer however and your proposal is rather application specific. What I can do is ask some colleagues on their view. But there's no guarantee, that they will respond. Some initial thoughts: To me a key point seems to be what can be reached at the bottleneck. There the compression should save bandwidth with little cost and no negative service impact. Any kind of shared access from which traffic is transmitted to the same destination seems to be relevant. The application/tunnel awareness of network elements may not be feasible, a network terminal at a UNI may be able to handle that, or any service specific device in a network= . Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 11:29 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), an= d after talking to James, I thought that the idea of standardizing the traffi= c classification fits well with my proposal. I would like to know your opinio= n about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the waiting time in the multiplexer. So another use is to provide flexibility: if you are a game provider, you may over provision your network in order to be abl= e to manage traffic peaks. But perhaps using this, you may be able to have a smaller network, and use compression when necessary (rush hour, first days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct priority= . I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-Wa= r craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find the history of the problems of World of Warcraft for Virgin Media users. Th= e problem was caused by a modification in the traffic, and the provider did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe tha= t some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ QoS (sub)classes, I think. But one class optimised to transport "UDP" and one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be useful). My take would be to standardise four classes/properties (in brackets exampl= e usage): a) for traffic which doesn't support re-transmits, requiring lowest delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using TCP= , like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward for a= ) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, this may depend on the implemented application transport. Further details may be discussed. Everything else could be reserved, but shouldn't be recommended. Carriers have deployed differing schemes on codepoints and classes. They need coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and applications with codepoints as a requirement and I also object to standards leaving no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP precedence). Bob Briscoe mentioned the difference between classes and queues and above properties can be mapped to queues. If end to end QoS is desired, the same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of gettin= g end to end QoS. I don't support an approach requiring 8 three bit classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I find i= t interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online games are at least as real-time as VoIP is. In most cases, the gamers are a very difficult people to deal with. If the latency is high, they leave and never return (this statement is not mine, it can be corroborated in the reference= s I put below). This has been studied by many research groups, with empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the authors proposed the use of an adaptation of RTP in order to manage gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. World of Warcraft: They normally use TCP, even though some of them use UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP o= r UDP - Sports games: Since there is a big variety, they have not been deeply studied in the literature Some research papers supporting this classification, and also the real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf - In this paper from my research group, 8 FPS games were analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP (packet= s of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It is only based on delay and jitter, since packet loss has vevy little influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana From jsaldana@unizar.es Tue Apr 24 02:14:59 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8297C21F8716 for ; Tue, 24 Apr 2012 02:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.298 X-Spam-Level: X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O5ftNlOrElX for ; Tue, 24 Apr 2012 02:14:58 -0700 (PDT) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 33B7221F86E1 for ; Tue, 24 Apr 2012 02:14:56 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q3O9EqMl031718; Tue, 24 Apr 2012 11:14:52 +0200 From: "Jose Saldana" To: References: <000601cd1325$9a1afcb0$ce50f610$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36B2D@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36B2D@HE111648.emea1.cds.t-internal.com> Subject: RE: About the tunnels: packets per second savings Date: Tue, 24 Apr 2012 11:14:54 +0200 Organization: Universidad de Zaragoza Message-ID: <002701cd21fa$b68c6fd0$23a54f70$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIhprOGX2vHUrQw0bSZ1wFqa2CEhgDoXfzplflknxA= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:14:59 -0000 Ruediger, Thanks for your response. This is good for understanding which are the = best scenarios for TCMTF. Best regards, Jose -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Enviado el: martes, 24 de abril de 2012 10:28 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About the tunnels: packets per second savings Jose, sorry for being late with my reply. Two of my colleagues replied. Simple bandwidth savings at the access itself would be interesting, especially = in the case of shared networks. Your proposal is related to the "core" part of the network and as you describe below, high end routers can deal with bigger numbers of packets = per second. That's the reason why my colleagues are not interested in working on the subject. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 2:14 PM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: About the tunnels: packets per second savings Ruediger, Thank you for your fast response. I will separately answer the two = parts of your email. First, this message about the tunnels. This afternoon or tomorrow I will send to the list an idea about QoS classes, but I have = to think more before sending it. I'm glad to hear that you consider the "tunnels" proposal interesting. = There is another issue that I discussed with Gorry in Paris: the saving in = terms of packets per second. I attach a graph of the saving in terms of this parameter using Counter Strike. If you multiplex all the packets you = have received e.g. every 20ms, then you will send 50 pps (the inverse of the multiplexing period). So you can save a lot of pps. It is clear that bandwidth saving is interesting, but I have read some papers in which a "packets per second" upper bound in the routers was reported: Section V.A of W. Feng, F. Chang, W. Feng, J. Walpole: "A Traffic Characterization of Popular On-Line Games". IEEE/ACM Trans. Netw., pp. 488-500, 2005. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf Section IV.3 of J. Yu, I. Al-Ajarmeh. "Call Admission Control and Traffic Engineering of VoIP", In Proc. Second Intenational Conference on Digital Telecommunications, IEEE ICDT 2007. http://140.192.40.4:8001/~imad/voip/YuJ-CallAdmin.pdf They not only talk about the bandwidth limitation of routers, but also = the packets per second limit. Gorry told me that high-end routers may not = have this problem. But low-end routers are not able to back-to-back send = small packets, due to the processing limitation. So, do you think this saving is interesting? Since you work in the = backbone, your opinion is important for me, taking into account that I am an = Academia researcher, and sometimes we are a little far from real things. Perhaps = you may ask some of your colleagues. Thanks, Jose -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado = el: jueves, 05 de abril de 2012 12:23 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, (...) I have removed the first part of the message for clarity. Then regarding tunnels and header compression Yes, that's smart and = there may be more use cases than gaming. I'm a backbone engineer however and = your proposal is rather application specific. What I can do is ask some colleagues on their view. But there's no guarantee, that they will = respond. Some initial thoughts: To me a key point seems to be what can be reached at the bottleneck. = There the compression should save bandwidth with little cost and no negative service impact. Any kind of shared access from which traffic is = transmitted to the same destination seems to be relevant. The application/tunnel awareness of network elements may not be feasible, a network terminal at = a UNI may be able to handle that, or any service specific device in a = network. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Thursday, April 05, 2012 11:29 AM To: Geib, R=FCdiger Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Ruediger, I have read your message about draft-polk-tsvwg-rfc4594-update. As you = may know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), = and after talking to James, I thought that the idea of standardizing the = traffic classification fits well with my proposal. I would like to know your = opinion about it, if possible. The idea is to use tunnels in order to compress and multiplex real-time traffic flows. Since these flows tend to use very small packets, they = have very bad efficiency. So perhaps tunnels could be used in order to group these flows. The drawback is that they add small delays, i.e. the = waiting time in the multiplexer. So another use is to provide flexibility: if = you are a game provider, you may over provision your network in order to be = able to manage traffic peaks. But perhaps using this, you may be able to have = a smaller network, and use compression when necessary (rush hour, first = days after releasing a new game, etc). When traffic is small, you do not multiplex, in order to reduce latency. So if traffic classification is a standard, everyone in the way from the origin to the destination will handle the traffic with the correct = priority. I attach a figure in order to clarify. Thank you, Jose PS: In http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-= War craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can = find the history of the problems of World of Warcraft for Virgin Media users. = The problem was caused by a modification in the traffic, and the provider = did not notice about it, so it treated the packets as best-effort. -----Mensaje original----- De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado = el: jueves, 05 de abril de 2012 9:49 Para: jsaldana@unizar.es CC: tsvwg@ietf.org Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Jose, you raise an interesting point: draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe = that some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ = QoS (sub)classes, I think. But one class optimised to transport "UDP" and = one for "TCP" are agreeable. The feedback that I had on carrier class QoS usage is that there's a = point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be = useful). My take would be to standardise four classes/properties (in brackets = example usage): a) for traffic which doesn't support re-transmits, requiring lowest = delay and jitter, having limited volume and packet size, but being loss tolerant (example usage VoIP) b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any packet size and possibly high volume, UDP transport, like IPTV) c) for any other traffic which supports re-transmits (QoS traffic using = TCP, like application signalling and network management traffic) d) a default class, for any traffic supporting re-transmits (Best = Effort) - this class may not be regarded as QoS (or as lowest CoS) What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward = for a) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are: b) AF4 (GSMA supports this one, RFC4594 also) c) AF3 (MEF and GSMA support this one) Gaming from my point of view would then match to an AF3 or AF4 class, = this may depend on the implemented application transport. Further details may = be discussed. Everything else could be reserved, but shouldn't be recommended. = Carriers have deployed differing schemes on codepoints and classes. They need = coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) = as well as in DSCP space if they should converge to a standardised codepoint/class scheme. I object to any approach standardising a match of classes and = applications with codepoints as a requirement and I also object to standards leaving = no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit = IP precedence). Bob Briscoe mentioned the difference between classes and queues and = above properties can be mapped to queues. If end to end QoS is desired, the = same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of = getting end to end QoS. I don't support an approach requiring 8 three bit = classes and 25 or more 6 bit classes and codepoints. Regards, Ruediger ________________________________ From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of Jose Saldana Sent: Monday, April 02, 2012 12:17 PM To: James Polk Cc: tsvwg@ietf.org Subject: About draft-polk-tsvwg-rfc4594-update-00.txt James, After returning home from IETF 83, I have been reading your draft. I = find it interesting to standardize the service classes. Otherwise, if each one classifies each traffic according to different criteria, Diffserv = becomes less useful. Regarding "Real-time interactive" service class, which refers to online gaming (my main research field), I find it really interesting: online = games are at least as real-time as VoIP is. In most cases, the gamers are a = very difficult people to deal with. If the latency is high, they leave and = never return (this statement is not mine, it can be corroborated in the = references I put below). This has been studied by many research groups, with = empirical tests using real gamers and adding delay, jitter, packet loss. Other question: in the draft it is said that online games use RTP/UDP streams. This can be a little confusing. In fact, the vast majority of online games do not use RTP, but bare UDP or even TCP. In http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, = the authors proposed the use of an adaptation of RTP in order to manage = gaming traffic. But as far as I know, this approach is not used by commercial games. A typical classification of today's games is: - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call = of Duty: They use UDP - MMORPG (Massively Multiplayer Online Role-playing Games), = e.g. World of Warcraft: They normally use TCP, even though some of them use = UDP - RTS (Real-time strategy) e.g. Age of Empires: They may use = TCP or UDP - Sports games: Since there is a big variety, they have not = been deeply studied in the literature Some research papers supporting this classification, and also the = real-time requirements of the games: First Person Shooters - A survey of traffic models for 17 First Person Shooters can = be found here. All of them use UDP http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf= - In this paper from my research group, 8 FPS games were = analyzed in order to compress and multiplex their traffic. Figure 5 shows their histograms (inter-packet time and packet size). It can be seen that they generate real-time flows, with characteristics very similar to VoIP = (packets of 60-80 bytes every 15-40 ms): http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf - Another paper about FPS using UDP. Section V presents some interesting conclusions about routing infrastructure. http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf - In this paper the network factors annoying the gamers are analyzed. There are also some calculations of the MOS. Above 150 ms the quality is bad (something similar to what happens with VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf - In this one, a MOS model for a FPS (Quake IV) is deployed. It = is only based on delay and jitter, since packet loss has vevy little = influence (for this concrete game). Delay above 140 ms produces MOS below 3 http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf - In this paper, it is found that some FPS work properly even = with 30% packet loss, whereas others stop working with 4%. RTT above 300 ms = (150 OWD) makes MOS go above 3 http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf MMORPGs: - A traffic model for World of Warcraft: http://publik.tuwien.ac.at/files/pub-et_12119.pdf - This one presents a MOS for World of Warcraft. When added = delay is above 160ms, the MOS is roughly 3.: http://publik.tuwien.ac.at/files/PubDat_170202.pdf Best regards, Jose Saldana From Ruediger.Geib@telekom.de Tue Apr 24 02:32:13 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C882D21F872A for ; Tue, 24 Apr 2012 02:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Spf6+mIApebM for ; Tue, 24 Apr 2012 02:32:13 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 65F6921F86DD for ; Tue, 24 Apr 2012 02:32:12 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 24 Apr 2012 11:32:10 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Tue, 24 Apr 2012 11:32:07 +0200 From: To: Date: Tue, 24 Apr 2012 11:32:07 +0200 Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDJZaCuqAgBwuANA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36CA5@HE111648.emea1.cds.t-internal.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> In-Reply-To: <000c01cd14b6$70b33ad0$5219b070$@unizar.es> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:32:13 -0000 Jose, thanks, part of your proposal isn't that far from the current deployment. IP offers 6 bits to encode QoS classes, while MPLS and Ethernet only offer = three. The commodity solution mapping IP QoS classes to MPLS or Ethernet is to cop= y the three most significant bits of the DSCP into the three bit QoS codepoint of Ethernet/MPLS (you proposed to use 2 bits). These three most significant bits are the so called IP-Precedence (RFC791). Making this copy mechanism a standard behaviour is a feature I'd support. I= t's simple, straightforward an widely deployed. Also DiffServ respects the prec= edence, EF has IP Prec 5, AF4 has IP Prec 4 and so on. All in all now, there are 8 possible codepoints. I suggest to standardise 4 classes. Some may use sub-classes with own codepoints. Further, a reserve of codepoints should be left for experiments and for provider internal use. So on standards track I support at most 4 classes and 4 IP precedence value= s. The number of IP DSCPs to be standardised should follow the usual IETF way = of dealing with things: If there's widespread deployment and more than one interoperable solution, put things on standards track. My take of interoperable solution here is not IETF like, as I look at this meaning two carriers or more having deployed a class in the same way. Starting from there you soon divide the problem into two issues: - carrier QoS classes having similar properties. - codepoints identifying these classes. Classes and codepoints I like: Class IP Prec, TC, P-Bits Example Use UDP short packets 5 Telephony UDP any 4 Streaming, IPTV, Gaming TCP any 3 Data, Signaling, 3. party n= etmgmt Default 0 Best Effort IP prec 6 should be reserved for network management traffic. I don't look at this as a public class (meaning it will be mapped to another class/DSCP at interconnection). Sub-classes on IP level are possible, the TCP any class is a candidate (AF3= ). The former should see standardisation by now. The latter is not in a good shape and requires goodwill and allow for migration plan, if something easy= to deploy should result. End to end QoS based with well known class properties and codepoints only results that way. A clear cause of the problem is the high number of DSCPs and the low degree of usage guidance of the AF classes. There's a need for two standard AF classes and up to 5 codepoints, that's my point of view. Compare EF: it uses a single DSCP and IP precedence and it has well defined properties. It saw widespread deployment. EF can be produced end to end. I oppose any concept to standardise over 25 DSCPs or any standard leaving no IP precedence codepoints for reserve. It doesn't matter whether that's in a VPN or public. QoS classes and codepoints to be put on standard= s track should have seen deployment and get support by more than one carrier. Entertaining documentation on classes and codepoints without a clear demand for usage impeded end to end QoS deployment so far. Regards, Ruediger -----Original Message----- From: Jose Saldana [mailto:jsaldana@unizar.es] Sent: Saturday, April 07, 2012 2:03 PM To: Geib, R=FCdiger; James M. Polk Cc: tsvwg@ietf.org Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt I have been reading the two messages of Ruediger about Jame's draft. I will try to make a "status of the question" and then a proposal. If something is wrong, just tell me. - We have the old 8 TOS bits of the IP header. Nowadays, two of them are ECN, and six of them are the DSCP field. So the problem is how to use these 6 bits (64 possible values) - Network control is 11xxxx, so this uses 16 values -11xx11 are defined in RFC 2474, and remain as only experimentally assignable/useable (this uses 4 of these 16 values) - This leaves 48 values - Best effort is 000000 - The draft of James proposes 14 values for the DSCP field, which correspon= d to service classes, mapped to application categories. But Ruediger says that, in his opinion, more than 4 classes are not useful, according to current implementations. We can ask ourselves: which are the key parameters that define how packets have to be managed in a router? I think that they are: 1) "Real-time-ness": The tolerated delay of the service. The jitter can be roughly included in this parameter. 2) loss tolerance: We can distinguish: TCP services are tolerant to loss, since they retransmit packets. And some UDP services are also tolerant to loss (VoIP, some games, etc) In my opinion, the "real-time-ness" is the key: it distinguishes very similar services: e.g. a video conference is different from a broadcast, since the latter permits delays of some seconds, whereas the first has to b= e interactive. So one possible solution could be: - Using the first two bits in order to define 4 classes, taking into accoun= t the existing implementations. They can be the 4 classes of Fig. 1 of James' draft, or the ones proposed by Ruediger. 00xxxx best effort 01xxxx data 10xxxx media oriented 11xxxx control - With the other 4 bits, something should be done. My proposal: - If the third bit is "1", then the other three bits include a valu= e defining the "real-time-ness" of the flow. So we have 8 levels of real-time-ness. Some examples: - 10-1-111 would be a media-oriented (10) and very real-time flow, as VoIP or a game - 10-0-xxx would be a media-oriented flow for which the real-time-ness is not defined - 10-1-010 could be a media-oriented flow with medium delay requirements, as multimedia conferencing - 10-1-000 would be a media-oriented flow with no very hard delay requirements, as multimedia streaming - 00-xxxx would be best-effort -01-1-111 would be very low-latency data -01-1-000 would be low-priority data One advantage of this is that some routers may only take into account the first two bits, and others would use all of them. The new RFC could suggest or define different values of real-time-ness for each application. So the applications should be ordered depending of the maximum tolerated delay. Ok. This is only an idea. Perhaps it does not make sense. Just tell me. Regards, Jose From Ruediger.Geib@telekom.de Tue Apr 24 02:56:12 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D63B21F857F for ; Tue, 24 Apr 2012 02:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBH5HcAjZpqX for ; Tue, 24 Apr 2012 02:56:10 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9409F21F856F for ; Tue, 24 Apr 2012 02:56:08 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 24 Apr 2012 11:56:06 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 24 Apr 2012 11:56:03 +0200 From: To: Date: Tue, 24 Apr 2012 11:56:02 +0200 Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDJZaCuqAgAcZHFCAFSbJoA== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:56:13 -0000 David, taking a formal point of view, you are probably right. These isues are intertwined however. End to end QoS will certainly not result from continuing to act like almost all standards bodies did so far: as there's a lot flexibility and little non-ambiguous guidance, anything is customised. I don't regard the update of RFC 4594 as being helpful if the expectation of the author is that even supporters of that standard will only deploy a subset of the defined classes and sub classes. Those standards close to deployment I know offer 3-4 classes and require no more than 6 codepoints (the latter is personal judgement). Any standards track QoS document should only determine things seeing widespread deployment. Some QoS classes have seen deployment. It's trickier with codepoints. Anything which might be useful in future or has seen an informational proposal in past should be critically reviewed and remain informational or experimental. Any QoS class should be well defined any easy to be differentiated against others. QoS codepoints should not identify applications. I also don't think that one needs to differentiate "admitted" from "non-admitted" classes. In a traffic engineered DiffServ network, customers get an SLA describing the worst case QoS class performance. To me it doesn't matter how a carrier ensures that the SLAs are kept. It only matters that they are kept. Regards, Ruediger > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are > ECN, and six of them are the DSCP field. So the problem is how to use the= se > 6 bits (64 possible values) > - Network control is 11xxxx, so this uses 16 values > -11xx11 are defined in RFC 2474, and remain as only experimentally > assignable/useable (this uses 4 of these 16 values) > - This leaves 48 values > - Best effort is 000000 > - The draft of James proposes 14 values for the DSCP field, which corresp= ond > to service classes, mapped to application categories. > > But Ruediger says that, in his opinion, more than 4 classes are not usefu= l, > according to current implementations. That's actually not appropriate for an RFC 4594 update - the proper place t= o address that requirement is an update to RFC 5127, which will need to be up= dated to be consistent with whatever is done to RFC 4594. Thanks, --David > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of= Jose > Saldana > Sent: Saturday, April 07, 2012 8:03 AM > To: Ruediger.Geib@telekom.de; James M. Polk > Cc: tsvwg@ietf.org > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > I have been reading the two messages of Ruediger about Jame's draft. I wi= ll > try to make a "status of the question" and then a proposal. If something = is > wrong, just tell me. > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are > ECN, and six of them are the DSCP field. So the problem is how to use the= se > 6 bits (64 possible values) > - Network control is 11xxxx, so this uses 16 values > -11xx11 are defined in RFC 2474, and remain as only experimentally > assignable/useable (this uses 4 of these 16 values) > - This leaves 48 values > - Best effort is 000000 > - The draft of James proposes 14 values for the DSCP field, which corresp= ond > to service classes, mapped to application categories. > > But Ruediger says that, in his opinion, more than 4 classes are not usefu= l, > according to current implementations. > > We can ask ourselves: which are the key parameters that define how packe= ts > have to be managed in a router? I think that they are: > > 1) "Real-time-ness": The tolerated delay of the service. The jitter can b= e > roughly included in this parameter. > 2) loss tolerance: We can distinguish: TCP services are tolerant to loss, > since they retransmit packets. And some UDP services are also tolerant to > loss (VoIP, some games, etc) > > In my opinion, the "real-time-ness" is the key: it distinguishes very > similar services: e.g. a video conference is different from a broadcast, > since the latter permits delays of some seconds, whereas the first has to= be > interactive. > > So one possible solution could be: > > - Using the first two bits in order to define 4 classes, taking into acco= unt > the existing implementations. They can be the 4 classes of Fig. 1 of Jame= s' > draft, or the ones proposed by Ruediger. > 00xxxx best effort > 01xxxx data > 10xxxx media oriented > 11xxxx control > > - With the other 4 bits, something should be done. My proposal: > - If the third bit is "1", then the other three bits include a valu= e > defining the "real-time-ness" of the flow. So we have 8 levels of > real-time-ness. Some examples: > - 10-1-111 would be a media-oriented (10) and very > real-time flow, as VoIP or a game > - 10-0-xxx would be a media-oriented flow for which the > real-time-ness is not defined > - 10-1-010 could be a media-oriented flow with medium delay > requirements, as multimedia conferencing > - 10-1-000 would be a media-oriented flow with no very hard > delay requirements, as multimedia streaming > - 00-xxxx would be best-effort > -01-1-111 would be very low-latency data > -01-1-000 would be low-priority data > > One advantage of this is that some routers may only take into account the > first two bits, and others would use all of them. > > The new RFC could suggest or define different values of real-time-ness fo= r > each application. So the applications should be ordered depending of the > maximum tolerated delay. > > Ok. This is only an idea. Perhaps it does not make sense. Just tell me. > Regards, > > Jose > > -----Mensaje original----- > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Enviado el: jueves, 05 de abril de 2012 12:23 > Para: jsaldana@unizar.es > CC: tsvwg@ietf.org > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Jose, > > regarding QoS, I'm happy to agree on 4 standard classes with properties a= s > mentioned in my last email. If there's consensus on some codepoints for > them, I'll support that. > > If IETF recommends how and which applications to use these > classes/codepoints, that's again agreeable. I don't think, that by now > requiring a specific application to carry a specific DSCP makes sense, ap= art > from few exceptions (like VoIP payload, network management traffic or Bes= t > Effort traffic). > IETF needs consensus to do that. > Note that the number of AF classes and codepoints are troublesome. Too ma= ny > with too little explanation how to use them, nothing is aligned with user > demand. EF/VoIP payload and network management are examples how to procee= d: > just specify what's required, no extras. > > > Then regarding tunnels and header compression Yes, that's smart and there > may be more use cases than gaming. I'm a backbone engineer however and yo= ur > proposal is rather application specific. What I can do is ask some > colleagues on their view. But there's no guarantee, that they will respon= d. > > Some initial thoughts: > To me a key point seems to be what can be reached at the bottleneck. Ther= e > the compression should save bandwidth with little cost and no negative > service impact. Any kind of shared access from which traffic is transmitt= ed > to the same destination seems to be relevant. The application/tunnel > awareness of network elements may not be feasible, a network terminal at = a > UNI may be able to handle that, or any service specific device in a netwo= rk. > > Regards, > > Ruediger > > > -----Original Message----- > From: Jose Saldana [mailto:jsaldana@unizar.es] > Sent: Thursday, April 05, 2012 11:29 AM > To: Geib, R=FCdiger > Cc: tsvwg@ietf.org > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Ruediger, > > I have read your message about draft-polk-tsvwg-rfc4594-update. As you ma= y > know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), = and > after talking to James, I thought that the idea of standardizing the traf= fic > classification fits well with my proposal. I would like to know your opin= ion > about it, if possible. > > The idea is to use tunnels in order to compress and multiplex real-time > traffic flows. Since these flows tend to use very small packets, they hav= e > very bad efficiency. So perhaps tunnels could be used in order to group > these flows. The drawback is that they add small delays, i.e. the waiting > time in the multiplexer. So another use is to provide flexibility: if you > are a game provider, you may over provision your network in order to be a= ble > to manage traffic peaks. But perhaps using this, you may be able to have = a > smaller network, and use compression when necessary (rush hour, first day= s > after releasing a new game, etc). When traffic is small, you do not > multiplex, in order to reduce latency. > > So if traffic classification is a standard, everyone in the way from the > origin to the destination will handle the traffic with the correct priori= ty. > > I attach a figure in order to clarify. > > Thank you, > > Jose > > PS: In > http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-= War > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find > the history of the problems of World of Warcraft for Virgin Media users. = The > problem was caused by a modification in the traffic, and the provider did > not notice about it, so it treated the packets as best-effort. > > -----Mensaje original----- > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado el= : > jueves, 05 de abril de 2012 9:49 > Para: jsaldana@unizar.es > CC: tsvwg@ietf.org > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > Jose, > > you raise an interesting point: > > draft-polk-tsvwg-rfc4594-update suggests to standardise application to > codepoint mapping as well as codepoint to class properties. You observe t= hat > some games are using TCP while others use UDP, which I think is a useful > level of QoS requirement abstraction. There's no need to have like 25+ Qo= S > (sub)classes, I think. But one class optimised to transport "UDP" and on= e > for "TCP" are agreeable. > > The feedback that I had on carrier class QoS usage is that there's a poin= t > in standardising class properties, and certainly not to standardise > application mappings to classes (recommending them may however be useful)= . > My take would be to standardise four classes/properties (in brackets exam= ple > usage): > > a) for traffic which doesn't support re-transmits, requiring lowest delay > and jitter, having limited volume and packet > size, but being loss tolerant (example usage VoIP) > b) for any other traffic which doesn't support re-transmits (let's say > traffic with real time like properties, but any > packet size and possibly high volume, UDP transport, like IPTV) > c) for any other traffic which supports re-transmits (QoS traffic using T= CP, > like application signalling and network management traffic) > d) a default class, for any traffic supporting re-transmits (Best Effort)= - > this class may not be regarded as QoS (or as lowest CoS) > > What I can tell ist that many carriers and standards on QoS support 3-4 > classes, having properties as described above. It is useful to recommend > codepoints matching to these classes. Standardising these codepoints > requires agreement between those having deplyed them. Straightforward for= a) > EF and d) 000000, probably easy for c) being used to transport Network > Management (CS 6). I'm not aware of common ground for anything else. My > favourites are: > > b) AF4 (GSMA supports this one, RFC4594 also) > c) AF3 (MEF and GSMA support this one) > > Gaming from my point of view would then match to an AF3 or AF4 class, thi= s > may depend on the implemented application transport. Further details may = be > discussed. > > Everything else could be reserved, but shouldn't be recommended. Carriers > have deployed differing schemes on codepoints and classes. They need codi= ng > reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) a= s > well as in DSCP space if they should converge to a standardised > codepoint/class scheme. > > I object to any approach standardising a match of classes and application= s > with codepoints as a requirement and I also object to standards leaving n= o > spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit I= P > precedence). > > Bob Briscoe mentioned the difference between classes and queues and above > properties can be mapped to queues. If end to end QoS is desired, the sam= e > class properties must be negotiated end to end. The lower the number of > classes and codepoints being deployed, the higher the probability of gett= ing > end to end QoS. I don't support an approach requiring 8 three bit classes > and 25 or more 6 bit classes and codepoints. > > Regards, > > Ruediger > > ________________________________ > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Jose Saldana > Sent: Monday, April 02, 2012 12:17 PM > To: James Polk > Cc: tsvwg@ietf.org > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > James, > > > > After returning home from IETF 83, I have been reading your draft. I find= it > interesting to standardize the service classes. Otherwise, if each one > classifies each traffic according to different criteria, Diffserv becomes > less useful. > > > > Regarding "Real-time interactive" service class, which refers to online > gaming (my main research field), I find it really interesting: online gam= es > are at least as real-time as VoIP is. In most cases, the gamers are a ver= y > difficult people to deal with. If the latency is high, they leave and nev= er > return (this statement is not mine, it can be corroborated in the referen= ces > I put below). This has been studied by many research groups, with empiric= al > tests using real gamers and adding delay, jitter, packet loss. > > > > Other question: in the draft it is said that online games use RTP/UDP > streams. This can be a little confusing. In fact, the vast majority of > online games do not use RTP, but bare UDP or even TCP. In > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, the > authors proposed the use of an adaptation of RTP in order to manage gamin= g > traffic. But as far as I know, this approach is not used by commercial > games. > > > > > > A typical classification of today's games is: > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of > Duty: They use UDP > > - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. > World of Warcraft: They normally use TCP, even though some of them use UD= P > > - RTS (Real-time strategy) e.g. Age of Empires: They may use TCP= or > UDP > > - Sports games: Since there is a big variety, they have not been > deeply studied in the literature > > > > Some research papers supporting this classification, and also the real-ti= me > requirements of the games: > > > > First Person Shooters > > > > - A survey of traffic models for 17 First Person Shooters can be > found here. All of them use UDP > http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf > > > > - In this paper from my research group, 8 FPS games were analyze= d > in order to compress and multiplex their traffic. Figure 5 shows their > histograms (inter-packet time and packet size). It can be seen that they > generate real-time flows, with characteristics very similar to VoIP (pack= ets > of 60-80 bytes every 15-40 ms): > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf > > > > - Another paper about FPS using UDP. Section V presents some > interesting conclusions about routing infrastructure. > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > - In this paper the network factors annoying the gamers are > analyzed. There are also some calculations of the MOS. Above 150 ms the > quality is bad (something similar to what happens with VoIP) > http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > - In this one, a MOS model for a FPS (Quake IV) is deployed. It = is > only based on delay and jitter, since packet loss has vevy little influen= ce > (for this concrete game). Delay above 140 ms produces MOS below 3 > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > - In this paper, it is found that some FPS work properly even wi= th > 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (1= 50 > OWD) makes MOS go above 3 > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > MMORPGs: > > - A traffic model for World of Warcraft: > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > - This one presents a MOS for World of Warcraft. When added dela= y > is above 160ms, the MOS is roughly 3.: > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > Best regards, > > > > Jose Saldana > > From trammell@tik.ee.ethz.ch Tue Apr 24 04:35:21 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCA821F86C9 for ; Tue, 24 Apr 2012 04:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VGx5Qt1PfwC for ; Tue, 24 Apr 2012 04:35:21 -0700 (PDT) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1121F86C8 for ; Tue, 24 Apr 2012 04:35:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 2BD3DD9308 for ; Tue, 24 Apr 2012 13:35:19 +0200 (MEST) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FeWTAOzBC1hJ for ; Tue, 24 Apr 2012 13:35:18 +0200 (MEST) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id EF5D7D9304 for ; Tue, 24 Apr 2012 13:35:18 +0200 (MEST) From: Brian Trammell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Comments on draft-ietf-tsvwg-sctp-udp-encaps-03 Date: Tue, 24 Apr 2012 13:35:18 +0200 Message-Id: To: tsvwg@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 11:35:21 -0000 Greetings, all, Apologies for missing the WGLC end on this draft; however as it appears = it may be rev'd anyway on the MTU DF question, I hope the following = comments prove useful. I've reviewed the document. It fills a need and the approach makes = sense, so I'm in favor of its publication. I do have a couple of = suggestions for clarification, though none of these change the normative = content of the document. I'll state that my perspective here is as an = SCTP application developer, and as someone interested both in this draft = and draft-tuexen-tsvwg-sctp-dtls-encaps within the context of IPFIX over = SCTP. (I'll also state that I didn't follow the WG discussion on this = draft to date, as I only sporadically pay attention to tsvwg, so = apologies if some of these comments are old news.) I'm still a little confused about how exactly UDP port mappings to SCTP = associations are meant to work in practice. Clearly, there is one UDP = port per "stack": one per application with application-bound = SCTP-over-UDP and one per host, defaulting to 9989, with SCTP-over-UDP = in the kernel or via a (probably privileged) userspace SCTP-over-UDP = daemon. This point might be made more clearly in section 4.1 -- that = there are really two envisioned deployment scenarios (or three, = depending on how you count), and explicitly spelling out the recommended = port numbering for each. (This opens an issue at the user interface level, though I am reasonably = certain this is out of scope for this document. Now you potentially have = one port that is exposed to the user or inherent to the application (the = SCTP port), plus one port that may have to be exposed to the client or = not based on the deployment scenario in use at the server. There are = ways for dealing with this with a single port in user- or = administrator-exposed names (URIs, DNS SRV...) but I don't know how well = this works for two ports.=20 Again, I'm not sure it fits in this document at all, but some discussion = of this issue (and suggested solutions) somewhere would keep each = application developer or specifier of application protocols from having = to solve it themselves. This issue would appear to apply to = draft-tuexen-tsvwg-sctp-dtls-encaps as well.) There are a couple of other bits that were terse to the point of being a = little unclear on a first reading. In section 4.2 it may be helpful to = point out that the point of UDP checksumming is to reduce the chance of = UDP header corruption. (I had to think about this for a couple of = seconds; SCTP has its own reliability mechanisms, after all...) = Likewise, section 4.8 might benefit from a note that you're talking = about ECN bits in the IP header, and that ECN over SCTP works otherwise = as specified in draft-stewart-tsvwg-sctpecn (with an informative = reference). Best regards, Brian= From Michael.Tuexen@lurchi.franken.de Tue Apr 24 12:33:10 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2C721E80B2 for ; Tue, 24 Apr 2012 12:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN9r1E+xC7eV for ; Tue, 24 Apr 2012 12:33:09 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 0829B21E8011 for ; Tue, 24 Apr 2012 12:33:08 -0700 (PDT) Received: from [192.168.1.103] (p508F971D.dip.t-dialin.net [80.143.151.29]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 917611C0B4619; Tue, 24 Apr 2012 21:33:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Tue, 24 Apr 2012 21:33:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1CF71169-29A6-4B5F-92D3-4443818B5CD3@lurchi.franken.de> References: To: Brian Trammell X-Mailer: Apple Mail (2.1257) Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-sctp-udp-encaps-03 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:33:10 -0000 Hi Brian, see my comments in-line. Best regards Michael On Apr 24, 2012, at 1:35 PM, Brian Trammell wrote: > Greetings, all, >=20 > Apologies for missing the WGLC end on this draft; however as it = appears it may be rev'd anyway on the MTU DF question, I hope the = following comments prove useful. >=20 > I've reviewed the document. It fills a need and the approach makes = sense, so I'm in favor of its publication. I do have a couple of = suggestions for clarification, though none of these change the normative = content of the document. I'll state that my perspective here is as an = SCTP application developer, and as someone interested both in this draft = and draft-tuexen-tsvwg-sctp-dtls-encaps within the context of IPFIX over = SCTP. (I'll also state that I didn't follow the WG discussion on this = draft to date, as I only sporadically pay attention to tsvwg, so = apologies if some of these comments are old news.) Why do you prefer IPFIX over SCTP over DTLS over UDP compared to IPFIX = over DTLS over SCTP over UDP? >=20 > I'm still a little confused about how exactly UDP port mappings to = SCTP associations are meant to work in practice. Clearly, there is one = UDP port per "stack": one per application with application-bound = SCTP-over-UDP and one per host, defaulting to 9989, with SCTP-over-UDP = in the kernel or via a (probably privileged) userspace SCTP-over-UDP = daemon. This point might be made more clearly in section 4.1 -- that = there are really two envisioned deployment scenarios (or three, = depending on how you count), and explicitly spelling out the recommended = port numbering for each. Each SCTP stack running in userland will use its own UDP port number for = receiving the packets. Each stack will then use the SCTP port number for = multiplexing/demultiplexing the packets belonging to different associations. >=20 > (This opens an issue at the user interface level, though I am = reasonably certain this is out of scope for this document. Now you = potentially have one port that is exposed to the user or inherent to the = application (the SCTP port), plus one port that may have to be exposed = to the client or not based on the deployment scenario in use at the = server. There are ways for dealing with this with a single port in user- = or administrator-exposed names (URIs, DNS SRV...) but I don't know how = well this works for two ports.=20 > Again, I'm not sure it fits in this document at all, but some = discussion of this issue (and suggested solutions) somewhere would keep = each application developer or specifier of application protocols from = having to solve it themselves. This issue would appear to apply to = draft-tuexen-tsvwg-sctp-dtls-encaps as well.) I guess this is not within the scope of the document. >=20 > There are a couple of other bits that were terse to the point of being = a little unclear on a first reading. In section 4.2 it may be helpful to = point out that the point of UDP checksumming is to reduce the chance of = UDP header corruption. (I had And UDP checksum is required for IPv6... However, the MUST will be = changed to a SHOULD. On FreeBSD we will just use the system wide setting for UDP/IPv4. > to think about this for a couple of seconds; SCTP has its own = reliability mechanisms, after all...) Likewise, section 4.8 might = benefit from a note that you're talking about ECN bits in the IP header, = and that ECN over SCTP works otherwise as specified in = draft-stewart-tsvwg-sctpecn (with an informative reference). I didn't wanted to add another reference. Just wanted to make sure that = encaps/decaps should try to transfer the ECN stuff. However, I have to double check if that is = possible with the socket API on plattforms like FreeBSD, Linux, Mac OS X using the socket API and = Windows using whatever they provide. Thanks a lot for the comments! Best regards Michael >=20 > Best regards, >=20 > Brian From david.black@emc.com Wed Apr 25 17:17:51 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8921F88C0 for ; Wed, 25 Apr 2012 17:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KHT1DgGJoHY for ; Wed, 25 Apr 2012 17:17:48 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7B63521F88BF for ; Wed, 25 Apr 2012 17:17:48 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3Q0HhPk021181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Apr 2012 20:17:44 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 25 Apr 2012 20:17:29 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q3Q0HRUL018390; Wed, 25 Apr 2012 20:17:27 -0400 Received: from mx15a.corp.emc.com ([169.254.1.107]) by mxhub35.corp.emc.com ([::1]) with mapi; Wed, 25 Apr 2012 20:17:27 -0400 From: To: Date: Wed, 25 Apr 2012 20:17:21 -0400 Thread-Topic: About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDJZaCuqAgAcZHFCAFSbJoIACh+3Q Message-ID: <8D3D17ACE214DC429325B2B98F3AE71203502D41@MX15A.corp.emc.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {AB2C97B1-F8DC-4CE4-A670-CE05520263F4} x-cr-hashedpuzzle: EqCy FFHK FYlO HHaP HoJi J/Kc LI59 LNKI LeFN O8Kv O8qr PvIL QMax QzKh UqSa UrFU; 2; cgB1AGUAZABpAGcAZQByAC4AZwBlAGkAYgBAAHQAZQBsAGUAawBvAG0ALgBkAGUAOwB0AHMAdgB3AGcAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {AB2C97B1-F8DC-4CE4-A670-CE05520263F4}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Thu, 26 Apr 2012 00:17:21 GMT; UgBFADoAIABBAGIAbwB1AHQAIABkAHIAYQBmAHQALQBwAG8AbABrAC0AdABzAHYAdwBnAC0AcgBmAGMANAA1ADkANAAtAHUAcABkAGEAdABlAC0AMAAwAC4AdAB4AHQA acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 00:17:51 -0000 Ruediger, We may be disagreeing more about means than ends. RFC 5127's intent was to aggregate all of the classes defined in RFC 4594 into a much smaller number of classes that would be suitable for a core network, e.g., "3-4 classes and require no more than 6 codepoints". The net would be that a choice of considerably more traffic classes from RFC 4594 would be deployable via aggregation as a suitably small number of classes on the wire. I believe (and I've said so to James), that RFC 5127 needs to be revised in concert with any work on RFC 4594 (in particular, I strongly oppose any revision to 4594 that ignores 5127). I also think that RFC 5127 is a better starting point to address the small number of classes use case that appears to be of interest and concern to you. Thanks, --David > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Tuesday, April 24, 2012 5:56 AM > To: Black, David > Cc: tsvwg@ietf.org > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > David, > > taking a formal point of view, you are probably right. These isues are > intertwined however. > > End to end QoS will certainly not result from continuing to act like > almost all standards bodies did so far: as there's a lot flexibility > and little non-ambiguous guidance, anything is customised. > > I don't regard the update of RFC 4594 as being helpful if the > expectation of the author is that even supporters of that standard > will only deploy a subset of the defined classes and sub classes. Those > standards close to deployment I know offer 3-4 classes and require no > more than 6 codepoints (the latter is personal judgement). > > Any standards track QoS document should only determine things seeing > widespread deployment. > > Some QoS classes have seen deployment. It's trickier with codepoints. > > Anything which might be useful in future or has seen an informational > proposal in past should be critically reviewed and remain > informational or experimental. > > Any QoS class should be well defined any easy to be differentiated > against others. > > QoS codepoints should not identify applications. > > I also don't think that one needs to differentiate "admitted" from > "non-admitted" classes. In a traffic engineered DiffServ network, > customers get an SLA describing the worst case QoS class performance. > To me it doesn't matter how a carrier ensures that the SLAs are kept. > It only matters that they are kept. > > Regards, > > Ruediger > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them ar= e > > ECN, and six of them are the DSCP field. So the problem is how to use t= hese > > 6 bits (64 possible values) > > - Network control is 11xxxx, so this uses 16 values > > -11xx11 are defined in RFC 2474, and remain as only experimentall= y > > assignable/useable (this uses 4 of these 16 values) > > - This leaves 48 values > > - Best effort is 000000 > > - The draft of James proposes 14 values for the DSCP field, which corre= spond > > to service classes, mapped to application categories. > > > > But Ruediger says that, in his opinion, more than 4 classes are not use= ful, > > according to current implementations. > > That's actually not appropriate for an RFC 4594 update - the proper place= to > address that requirement is an update to RFC 5127, which will need to be > updated > to be consistent with whatever is done to RFC 4594. > > Thanks, > --David > > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of > Jose > > Saldana > > Sent: Saturday, April 07, 2012 8:03 AM > > To: Ruediger.Geib@telekom.de; James M. Polk > > Cc: tsvwg@ietf.org > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > I have been reading the two messages of Ruediger about Jame's draft. I = will > > try to make a "status of the question" and then a proposal. If somethin= g is > > wrong, just tell me. > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them ar= e > > ECN, and six of them are the DSCP field. So the problem is how to use t= hese > > 6 bits (64 possible values) > > - Network control is 11xxxx, so this uses 16 values > > -11xx11 are defined in RFC 2474, and remain as only experimentall= y > > assignable/useable (this uses 4 of these 16 values) > > - This leaves 48 values > > - Best effort is 000000 > > - The draft of James proposes 14 values for the DSCP field, which corre= spond > > to service classes, mapped to application categories. > > > > But Ruediger says that, in his opinion, more than 4 classes are not use= ful, > > according to current implementations. > > > > We can ask ourselves: which are the key parameters that define how pac= kets > > have to be managed in a router? I think that they are: > > > > 1) "Real-time-ness": The tolerated delay of the service. The jitter can= be > > roughly included in this parameter. > > 2) loss tolerance: We can distinguish: TCP services are tolerant to los= s, > > since they retransmit packets. And some UDP services are also tolerant = to > > loss (VoIP, some games, etc) > > > > In my opinion, the "real-time-ness" is the key: it distinguishes very > > similar services: e.g. a video conference is different from a broadcast= , > > since the latter permits delays of some seconds, whereas the first has = to be > > interactive. > > > > So one possible solution could be: > > > > - Using the first two bits in order to define 4 classes, taking into ac= count > > the existing implementations. They can be the 4 classes of Fig. 1 of Ja= mes' > > draft, or the ones proposed by Ruediger. > > 00xxxx best effort > > 01xxxx data > > 10xxxx media oriented > > 11xxxx control > > > > - With the other 4 bits, something should be done. My proposal: > > - If the third bit is "1", then the other three bits include a va= lue > > defining the "real-time-ness" of the flow. So we have 8 levels of > > real-time-ness. Some examples: > > - 10-1-111 would be a media-oriented (10) and very > > real-time flow, as VoIP or a game > > - 10-0-xxx would be a media-oriented flow for which the > > real-time-ness is not defined > > - 10-1-010 could be a media-oriented flow with medium del= ay > > requirements, as multimedia conferencing > > - 10-1-000 would be a media-oriented flow with no very ha= rd > > delay requirements, as multimedia streaming > > - 00-xxxx would be best-effort > > -01-1-111 would be very low-latency data > > -01-1-000 would be low-priority data > > > > One advantage of this is that some routers may only take into account t= he > > first two bits, and others would use all of them. > > > > The new RFC could suggest or define different values of real-time-ness = for > > each application. So the applications should be ordered depending of th= e > > maximum tolerated delay. > > > > Ok. This is only an idea. Perhaps it does not make sense. Just tell me. > > Regards, > > > > Jose > > > > -----Mensaje original----- > > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Enviado el: jueves, 05 de abril de 2012 12:23 > > Para: jsaldana@unizar.es > > CC: tsvwg@ietf.org > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > Jose, > > > > regarding QoS, I'm happy to agree on 4 standard classes with properties= as > > mentioned in my last email. If there's consensus on some codepoints for > > them, I'll support that. > > > > If IETF recommends how and which applications to use these > > classes/codepoints, that's again agreeable. I don't think, that by now > > requiring a specific application to carry a specific DSCP makes sense, = apart > > from few exceptions (like VoIP payload, network management traffic or B= est > > Effort traffic). > > IETF needs consensus to do that. > > Note that the number of AF classes and codepoints are troublesome. Too = many > > with too little explanation how to use them, nothing is aligned with us= er > > demand. EF/VoIP payload and network management are examples how to proc= eed: > > just specify what's required, no extras. > > > > > > Then regarding tunnels and header compression Yes, that's smart and the= re > > may be more use cases than gaming. I'm a backbone engineer however and = your > > proposal is rather application specific. What I can do is ask some > > colleagues on their view. But there's no guarantee, that they will resp= ond. > > > > Some initial thoughts: > > To me a key point seems to be what can be reached at the bottleneck. Th= ere > > the compression should save bandwidth with little cost and no negative > > service impact. Any kind of shared access from which traffic is transmi= tted > > to the same destination seems to be relevant. The application/tunnel > > awareness of network elements may not be feasible, a network terminal a= t a > > UNI may be able to handle that, or any service specific device in a net= work. > > > > Regards, > > > > Ruediger > > > > > > -----Original Message----- > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > Sent: Thursday, April 05, 2012 11:29 AM > > To: Geib, R=FCdiger > > Cc: tsvwg@ietf.org > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > Ruediger, > > > > I have read your message about draft-polk-tsvwg-rfc4594-update. As you = may > > know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02)= , and > > after talking to James, I thought that the idea of standardizing the tr= affic > > classification fits well with my proposal. I would like to know your op= inion > > about it, if possible. > > > > The idea is to use tunnels in order to compress and multiplex real-time > > traffic flows. Since these flows tend to use very small packets, they h= ave > > very bad efficiency. So perhaps tunnels could be used in order to group > > these flows. The drawback is that they add small delays, i.e. the waiti= ng > > time in the multiplexer. So another use is to provide flexibility: if y= ou > > are a game provider, you may over provision your network in order to be= able > > to manage traffic peaks. But perhaps using this, you may be able to hav= e a > > smaller network, and use compression when necessary (rush hour, first d= ays > > after releasing a new game, etc). When traffic is small, you do not > > multiplex, in order to reduce latency. > > > > So if traffic classification is a standard, everyone in the way from th= e > > origin to the destination will handle the traffic with the correct prio= rity. > > > > I attach a figure in order to clarify. > > > > Thank you, > > > > Jose > > > > PS: In > > http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-o= f-War > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can fi= nd > > the history of the problems of World of Warcraft for Virgin Media users= . The > > problem was caused by a modification in the traffic, and the provider d= id > > not notice about it, so it treated the packets as best-effort. > > > > -----Mensaje original----- > > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] Enviado = el: > > jueves, 05 de abril de 2012 9:49 > > Para: jsaldana@unizar.es > > CC: tsvwg@ietf.org > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > Jose, > > > > you raise an interesting point: > > > > draft-polk-tsvwg-rfc4594-update suggests to standardise application to > > codepoint mapping as well as codepoint to class properties. You observe= that > > some games are using TCP while others use UDP, which I think is a usefu= l > > level of QoS requirement abstraction. There's no need to have like 25+ = QoS > > (sub)classes, I think. But one class optimised to transport "UDP" and = one > > for "TCP" are agreeable. > > > > The feedback that I had on carrier class QoS usage is that there's a po= int > > in standardising class properties, and certainly not to standardise > > application mappings to classes (recommending them may however be usefu= l). > > My take would be to standardise four classes/properties (in brackets ex= ample > > usage): > > > > a) for traffic which doesn't support re-transmits, requiring lowest del= ay > > and jitter, having limited volume and packet > > size, but being loss tolerant (example usage VoIP) > > b) for any other traffic which doesn't support re-transmits (let's say > > traffic with real time like properties, but any > > packet size and possibly high volume, UDP transport, like IPTV) > > c) for any other traffic which supports re-transmits (QoS traffic using= TCP, > > like application signalling and network management traffic) > > d) a default class, for any traffic supporting re-transmits (Best Effor= t) - > > this class may not be regarded as QoS (or as lowest CoS) > > > > What I can tell ist that many carriers and standards on QoS support 3-4 > > classes, having properties as described above. It is useful to recommen= d > > codepoints matching to these classes. Standardising these codepoints > > requires agreement between those having deplyed them. Straightforward f= or a) > > EF and d) 000000, probably easy for c) being used to transport Network > > Management (CS 6). I'm not aware of common ground for anything else. My > > favourites are: > > > > b) AF4 (GSMA supports this one, RFC4594 also) > > c) AF3 (MEF and GSMA support this one) > > > > Gaming from my point of view would then match to an AF3 or AF4 class, t= his > > may depend on the implemented application transport. Further details ma= y be > > discussed. > > > > Everything else could be reserved, but shouldn't be recommended. Carrie= rs > > have deployed differing schemes on codepoints and classes. They need co= ding > > reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits)= as > > well as in DSCP space if they should converge to a standardised > > codepoint/class scheme. > > > > I object to any approach standardising a match of classes and applicati= ons > > with codepoints as a requirement and I also object to standards leaving= no > > spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit= IP > > precedence). > > > > Bob Briscoe mentioned the difference between classes and queues and abo= ve > > properties can be mapped to queues. If end to end QoS is desired, the s= ame > > class properties must be negotiated end to end. The lower the number of > > classes and codepoints being deployed, the higher the probability of ge= tting > > end to end QoS. I don't support an approach requiring 8 three bit class= es > > and 25 or more 6 bit classes and codepoints. > > > > Regards, > > > > Ruediger > > > > ________________________________ > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf = Of > > Jose Saldana > > Sent: Monday, April 02, 2012 12:17 PM > > To: James Polk > > Cc: tsvwg@ietf.org > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > > > James, > > > > > > > > After returning home from IETF 83, I have been reading your draft. I fi= nd it > > interesting to standardize the service classes. Otherwise, if each one > > classifies each traffic according to different criteria, Diffserv becom= es > > less useful. > > > > > > > > Regarding "Real-time interactive" service class, which refers to online > > gaming (my main research field), I find it really interesting: online g= ames > > are at least as real-time as VoIP is. In most cases, the gamers are a v= ery > > difficult people to deal with. If the latency is high, they leave and n= ever > > return (this statement is not mine, it can be corroborated in the refer= ences > > I put below). This has been studied by many research groups, with empir= ical > > tests using real gamers and adding delay, jitter, packet loss. > > > > > > > > Other question: in the draft it is said that online games use RTP/UDP > > streams. This can be a little confusing. In fact, the vast majority of > > online games do not use RTP, but bare UDP or even TCP. In > > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf, t= he > > authors proposed the use of an adaptation of RTP in order to manage gam= ing > > traffic. But as far as I know, this approach is not used by commercial > > games. > > > > > > > > > > > > A typical classification of today's games is: > > > > > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call = of > > Duty: They use UDP > > > > - MMORPG (Massively Multiplayer Online Role-playing Games), e.= g. > > World of Warcraft: They normally use TCP, even though some of them use = UDP > > > > - RTS (Real-time strategy) e.g. Age of Empires: They may use T= CP or > > UDP > > > > - Sports games: Since there is a big variety, they have not be= en > > deeply studied in the literature > > > > > > > > Some research papers supporting this classification, and also the real-= time > > requirements of the games: > > > > > > > > First Person Shooters > > > > > > > > - A survey of traffic models for 17 First Person Shooters can = be > > found here. All of them use UDP > > http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.p= df > > > > > > > > - In this paper from my research group, 8 FPS games were analy= zed > > in order to compress and multiplex their traffic. Figure 5 shows their > > histograms (inter-packet time and packet size). It can be seen that the= y > > generate real-time flows, with characteristics very similar to VoIP (pa= ckets > > of 60-80 bytes every 15-40 ms): > > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf > > > > > > > > - Another paper about FPS using UDP. Section V presents some > > interesting conclusions about routing infrastructure. > > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > > > > > - In this paper the network factors annoying the gamers are > > analyzed. There are also some calculations of the MOS. Above 150 ms the > > quality is bad (something similar to what happens with VoIP) > > http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > > > > > - In this one, a MOS model for a FPS (Quake IV) is deployed. I= t is > > only based on delay and jitter, since packet loss has vevy little influ= ence > > (for this concrete game). Delay above 140 ms produces MOS below 3 > > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > > > > > - In this paper, it is found that some FPS work properly even = with > > 30% packet loss, whereas others stop working with 4%. RTT above 300 ms = (150 > > OWD) makes MOS go above 3 > > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > > > > > MMORPGs: > > > > - A traffic model for World of Warcraft: > > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > > > > > - This one presents a MOS for World of Warcraft. When added de= lay > > is above 160ms, the MOS is roughly 3.: > > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > > > > > Best regards, > > > > > > > > Jose Saldana > > > > > From gorry@erg.abdn.ac.uk Wed Apr 25 23:53:57 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E5E21F887A for ; Wed, 25 Apr 2012 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5DyzRaRS4er for ; Wed, 25 Apr 2012 23:53:57 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id C5B9821F87D8 for ; Wed, 25 Apr 2012 23:53:54 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q3Q6rnWX005669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Apr 2012 07:53:49 +0100 (BST) Message-ID: <4F98F0FD.7080009@erg.abdn.ac.uk> Date: Thu, 26 Apr 2012 07:53:49 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tsvwg] 6man WGLC of draft-ietf-6man-udpchecksums-02.txt to end May 3, 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:53:57 -0000 TSVWG... please note the following WGLC in the 6man WG to update the UDP spec when used with IPv6. If you have transport comments or think this update is OK, please note this on the 6man or tsvwg list. Gorry ---- This message starts a two week 6MAN Working Group on advancing: Title : UDP Checksums for Tunneled Packets Author(s) : Marshall Eubanks P.F. Chimento Filename : draft-ietf-6man-udpchecksums-02.txt Pages : 12 Date : 2012-03-12 http://tools.ietf.org/html/draft-ietf-6man-udpchecksums-02 as Proposed Standard. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on May 3, 2012. Regards, Ole Troan & Bob Hinden From gorry@erg.abdn.ac.uk Wed Apr 25 23:53:57 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C484721F87D8 for ; Wed, 25 Apr 2012 23:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, SARE_SUB_OBFU_Z=0.259, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43k9eNF9M+BQ for ; Wed, 25 Apr 2012 23:53:57 -0700 (PDT) Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by ietfa.amsl.com (Postfix) with ESMTP id A3CA421F8877 for ; Wed, 25 Apr 2012 23:53:56 -0700 (PDT) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id q3Q6rjUh005667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Thu, 26 Apr 2012 07:53:46 +0100 (BST) Message-ID: <4F98F0F9.1020100@erg.abdn.ac.uk> Date: Thu, 26 Apr 2012 07:53:45 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ERG-MailScanner: Found to be clean X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk Subject: [tsvwg] 6man WGLC of draft-ietf-6man-udpzero-05.txt to end May 3, 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 06:53:57 -0000 TSVWG... please note the following WGLC in the 6man WG this I-D presents transport-layer issues for the proposed update the UDP spec with IPv6. If you have transport comments or think this update is OK, please note this on the 6man or tsvwg list. Gorry ---- This message starts a two week 6MAN Working Group on advancing: Title : IPv6 UDP Checksum Considerations Author(s) : Godred Fairhurst Magnus Westerlund Filename : draft-ietf-6man-udpzero-05.txt Pages : 34 Date : 2011-12-23 http://tools.ietf.org/html/draft-ietf-6man-udpzero-05 as an Informational RFC. Substantive comments and statements of support for advancing this document should be directed to the mailing list. Editorial suggestions can be sent to the authors. This last call will end on May 3, 2012. Regards, Ole Troan & Bob Hinden From jukka.manner@aalto.fi Thu Apr 26 01:50:43 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF621F86B3 for ; Thu, 26 Apr 2012 01:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSRsbSpTkHdP for ; Thu, 26 Apr 2012 01:50:42 -0700 (PDT) Received: from mx05.aalto.fi (mx05.aalto.fi [130.233.222.104]) by ietfa.amsl.com (Postfix) with ESMTP id D55C821F8658 for ; Thu, 26 Apr 2012 01:50:41 -0700 (PDT) Received: from mx05.aalto.fi (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E237B80AC7; Thu, 26 Apr 2012 11:50:37 +0300 (EEST) Received: from EXHUB03.org.aalto.fi (ex-hub03.org.aalto.fi [130.233.222.116]) by mx05.aalto.fi (Postfix) with ESMTP id 9A5A780AC5; Thu, 26 Apr 2012 11:50:37 +0300 (EEST) Received: from EXMDB04.org.aalto.fi ([169.254.1.244]) by EXHUB03.org.aalto.fi ([130.233.222.116]) with mapi id 14.01.0339.001; Thu, 26 Apr 2012 11:50:37 +0300 From: Manner Jukka To: John Leslie Thread-Topic: Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 Thread-Index: AQHNHjGk9OLSBdAQuUiMPglAt0XT5paspJ6A Date: Thu, 26 Apr 2012 08:50:37 +0000 Message-ID: References: <4F605902.40009@erg.abdn.ac.uk> <4F730BAC.4040602@erg.abdn.ac.uk> <20120330155002.GB92614@verdi> <201204181813.q3IIDetq019006@bagheera.jungle.bt.co.uk> <375_1334842694_4F901545_375_154_1_20120419133802.GJ99904@verdi> In-Reply-To: <375_1334842694_4F901545_375_154_1_20120419133802.GJ99904@verdi> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.233.154.116] Content-Type: text/plain; charset="us-ascii" Content-ID: <64A490FB7813D84399FB7658D69793F1@aalto.fi> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [tsvwg] Note: WGLC Announcement for draft-ietf-tsvwg-byte-pkt-congest-07 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:50:43 -0000 Hi John, Could you give a concrete clear list of things, you would like to be change= d? Jukka On Apr 19, 2012, at 4:38 PM, John Leslie wrote: > Bob Briscoe wrote: >>=20 >> I believe the disagreement is rooted in the idea that vendors hit the=20 >> design limits of equipment performance when they cannot process=20 >> packets any faster, whereas raw line transmission rates could be a=20 >> lot faster. >=20 > Actually, that's not it at all. >=20 >>> When I previously skimmed this document, I believed it contained only >>> common ground: that AQM should drop/mark packets without favoring small >>> packets, and that to whatever extent packet size _is_ considered, that >>> should be a transport-layer responsibility. >>=20 >> Good - this is the main thing we wanted to ensure was said. >>=20 >>> Alas, when I read it carefully this week, I find that Bob is actually >>> saying that transport-layer should _only_ consider "congested bytes", >>> not "congested packets". >>=20 >> In fact, TFRC-SP wrestled with the possibility that the network, not=20 >> the transport, could weight its congestion signals relative to packet=20 >> size. But it didn't even entertain the possibility that congestion=20 >> might be packet-based not bit-based, so packet size wouldn't be an=20 >> issue at all. >=20 > Hopefully, we all can agree the network should not weigh congestion > signals by packet size. But that doesn't mean some other layer needs > to do so in any "ordinary" case. >=20 >> byte-pkt-congest does at least entertain the possibility that=20 >> prevalent bit-congestion may be a wrong assumption and describes a=20 >> future where it might be wrong, but it also justifies fairly=20 >> carefully why it is a safe working assumption and it will continue to=20 >> be safe, based on advice from equipment designers. (Actually, in=20 >> reading the latest draft, I notice some of this argument has=20 >> disappeared in the editing and it now mainly justifies this position=20 >> by reference to RFC6077. I would be happy to bring some of that=20 >> removed text back in.) >=20 > I very much doubt that what we need here is to add such text. >=20 >> But, I gather that wouldn't satisfy you, because you believe=20 >> packet-congestion is prevalent, so let's please have that technical=20 >> discussion. >=20 > Once again, that's not it at all. >=20 > My technical argument is it's really-hard to accurately estimate > per-packet overhead when counting bits for bit-congestible node pairs; > and that counting packets (which we can do accurately) works well in > all cases where packet size within a flow is fairly constant. >=20 > This is basically what we do today; and I'm very resistant to any > call to replace it with algorithms which tend to underestimate the > overhead when counting payload bytes. >=20 >>> In fact, Bob openly endorses replacing TCP congestion-control with an >>> algorithm which calculates "fair-share bytes" and doesn't back off at a= ll >>> (even in the presence of 20% packet loss) unless you're already sending >>> more than this "fair-share". >=20 > BTW, I was very surprised to find "fair-share" as a recommendation > in a Bob Briscoe document, given his previous "dismantling a religion" > documents. >=20 >> I assume you're referring to bullet 1. under "What this advice means=20 >> for the case of TCP:" in S2.3. >=20 > Actually, that's not what I was referring to. >=20 >> It says >> " 1. If two TCP flows with different packet sizes are required to run >> at equal bit rates under the same path conditions, this should be >> done by altering TCP (Section 4.2.2), not network equipment [...] >> " >=20 > More likely, it was Section 4.2.2... I don't think this document > needs a 4.2.2 at all. This statement would be stronger if we didn't try > to describe possible modifications to TCP. >=20 >> This doesn't say TCP should do this, it just says TCP is the place to=20 >> fiddle, *if* you want to equalise bit-rates. >=20 > And I didn't find it objectionble until I read the rest of the > document carefully. >=20 >> If that's not clear, I would be happy (and I hope Jukka would too) to=20 >> make it clearer that this recommendation is irrelevant if TCP flows=20 >> are *not* required to run at equal bit-rates (Personally I would like=20 >> to say that there should be no need for any equal-bit-rate=20 >> requirement - however, that *would* be going beyond our charter). >=20 > Maybe we should explore exactly what about our charter excludes such > a statement? >=20 >> How about this text after S2.3. bullet 1? >>=20 >> " For the avoidance of doubt, this is not a recommendation that TCP >> should be changed so that all TCP flows run at equal bit-rates. It is= a >> recommendation that the transport protocol not the network is where an= y >> attempt should be made to equalise bit-rates of competing flows, *if* >> that is ever considered an important requirement. >> " >=20 > I preferred your short-form: > "=20 > " If you want to equalize bit-rates between TCP flows, this should be > " done within TCP, not by network equipment. >=20 >>> The draft contains a number of things I _do_ support; and I'd be happy >>> to support a considerably shorter draft which concentrates on the AQM >>> recommendation, omitting any suggestions of modifying TCP congestion >>> control. >>=20 >> We could omit "What this means for TCP" altogether. >=20 > IMHO, the document would be stronger without it. >=20 >> However, given people of the standing of Sally Floyd originally tried >> to equalise bit-rates in the network, then moved to doing it in the >> transport, I don't think it is wise to leave a vacuum. >=20 > I don't perceive any such vacuum. At most, we might need an informative > reference to a Sally Floyd document. >=20 > -- > John Leslie From jmpolk@cisco.com Thu Apr 26 14:17:08 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFAA21F8718 for ; Thu, 26 Apr 2012 14:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.833 X-Spam-Level: X-Spam-Status: No, score=-109.833 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhxPSp1ZKIgi for ; Thu, 26 Apr 2012 14:17:06 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C112B21F8716 for ; Thu, 26 Apr 2012 14:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=21572; q=dns/txt; s=iport; t=1335475025; x=1336684625; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=FIjkqlAmvg90tfUQ20zAGRbmHwYQypzNklHzWQxePgc=; b=O+UlS9lq9VsGYesIiDXrTKx+W8dBM2UuBEn1Pgo04CS63MMO7CLA9oOP eNbBo43JZBNOFdBK0qdcn4oRVa8UvJw8mouioIin3tCVLUB9uiiEPxNq0 gLVyGR9SA5VKPG1sQbSMDQUvLmIhkP7UjNGdlXtmlL5hPBuA9gZXnLscL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEC6mU+rRDoJ/2dsb2JhbAA7ChaxW4EHggkBAQECAQESAQUgLwEICQUHBAcEEQQBAQEVEgcZLQkIBhMUBweHZgQMmmGgHIp5BII3gzEEiC80jiuNRoFpgwaBNgg X-IronPort-AV: E=Sophos;i="4.75,487,1330905600"; d="scan'208";a="42335828" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 26 Apr 2012 21:16:59 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q3QLGwZj011390; Thu, 26 Apr 2012 21:16:59 GMT Message-Id: <201204262116.q3QLGwZj011390@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 26 Apr 2012 16:16:58 -0500 To: From: "James M. Polk" In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71203502D41@MX15A.corp.emc.co m> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> <8D3D17ACE214DC429325B2B98F3AE71203502D41@MX15A.corp.emc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: tsvwg@ietf.org Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 21:17:08 -0000 David I absolutely agree with you that these two=20 efforts (the current rewrite of RFC4594, and the=20 coming rewrite of RFC5127) need to be=20 synchronized to have either make proper sense. I=20 also agree that the rewrite of RFC5127 is where a=20 smaller, aggregated set of classes for core=20 networks. Ruediger mentioned his worry about=20 "folks viewing tables and just configuring based=20 on the tables". Clearly his concerns on that need to be addressed. I'll work to get my initial version of the=20 rewrite of RFC5127 in before Vancouver. James At 07:17 PM 4/25/2012, david.black@emc.com wrote: >Ruediger, > >We may be disagreeing more about means than ends. > >RFC 5127's intent was to aggregate all of the classes defined in RFC 4594 >into a much smaller number of classes that would be suitable for a core >network, e.g., "3-4 classes and require no more than 6 codepoints". The >net would be that a choice of considerably more traffic classes from RFC >4594 would be deployable via aggregation as a suitably small number of >classes on the wire. > >I believe (and I've said so to James), that RFC 5127 needs to be revised >in concert with any work on RFC 4594 (in particular, I strongly oppose any >revision to 4594 that ignores 5127). I also think that RFC 5127 is a >better starting point to address the small number of classes use case >that appears to be of interest and concern to you. > >Thanks, >--David > > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Tuesday, April 24, 2012 5:56 AM > > To: Black, David > > Cc: tsvwg@ietf.org > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > David, > > > > taking a formal point of view, you are probably right. These isues are > > intertwined however. > > > > End to end QoS will certainly not result from continuing to act like > > almost all standards bodies did so far: as there's a lot flexibility > > and little non-ambiguous guidance, anything is customised. > > > > I don't regard the update of RFC 4594 as being helpful if the > > expectation of the author is that even supporters of that standard > > will only deploy a subset of the defined classes and sub classes. Those > > standards close to deployment I know offer 3-4 classes and require no > > more than 6 codepoints (the latter is personal judgement). > > > > Any standards track QoS document should only determine things seeing > > widespread deployment. > > > > Some QoS classes have seen deployment. It's trickier with codepoints. > > > > Anything which might be useful in future or has seen an informational > > proposal in past should be critically reviewed and remain > > informational or experimental. > > > > Any QoS class should be well defined any easy to be differentiated > > against others. > > > > QoS codepoints should not identify applications. > > > > I also don't think that one needs to differentiate "admitted" from > > "non-admitted" classes. In a traffic engineered DiffServ network, > > customers get an SLA describing the worst case QoS class performance. > > To me it doesn't matter how a carrier ensures that the SLAs are kept. > > It only matters that they are kept. > > > > Regards, > > > > Ruediger > > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them= are > > > ECN, and six of them are the DSCP field. So=20 > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only= experimentally > > > assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for=20 > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion,=20 > more than 4 classes are not useful, > > > according to current implementations. > > > > That's actually not appropriate for an RFC=20 > 4594 update - the proper place to > > address that requirement is an update to RFC 5127, which will need to be > > updated > > to be consistent with whatever is done to RFC 4594. > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf= Of > > Jose > > > Saldana > > > Sent: Saturday, April 07, 2012 8:03 AM > > > To: Ruediger.Geib@telekom.de; James M. Polk > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > I have been reading the two messages of=20 > Ruediger about Jame's draft. I will > > > try to make a "status of the question" and=20 > then a proposal. If something is > > > wrong, just tell me. > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them= are > > > ECN, and six of them are the DSCP field. So=20 > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only= experimentally > > > assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for=20 > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion,=20 > more than 4 classes are not useful, > > > according to current implementations. > > > > > > We can ask ourselves: which are the key=20 > parameters that define how packets > > > have to be managed in a router? I think that they are: > > > > > > 1) "Real-time-ness": The tolerated delay of=20 > the service. The jitter can be > > > roughly included in this parameter. > > > 2) loss tolerance: We can distinguish: TCP services are tolerant to= loss, > > > since they retransmit packets. And some UDP services are also tolerant= to > > > loss (VoIP, some games, etc) > > > > > > In my opinion, the "real-time-ness" is the key: it distinguishes very > > > similar services: e.g. a video conference is different from a= broadcast, > > > since the latter permits delays of some=20 > seconds, whereas the first has to be > > > interactive. > > > > > > So one possible solution could be: > > > > > > - Using the first two bits in order to=20 > define 4 classes, taking into account > > > the existing implementations. They can be=20 > the 4 classes of Fig. 1 of James' > > > draft, or the ones proposed by Ruediger. > > > 00xxxx best effort > > > 01xxxx data > > > 10xxxx media oriented > > > 11xxxx control > > > > > > - With the other 4 bits, something should be done. My proposal: > > > - If the third bit is "1", then the=20 > other three bits include a value > > > defining the "real-time-ness" of the flow. So we have 8 levels of > > > real-time-ness. Some examples: > > > - 10-1-111 would be a media-oriented (10) and very > > > real-time flow, as VoIP or a game > > > - 10-0-xxx would be a media-oriented flow for which the > > > real-time-ness is not defined > > > - 10-1-010 could be a media-oriented flow with medium= delay > > > requirements, as multimedia conferencing > > > - 10-1-000 would be a media-oriented flow with no very= hard > > > delay requirements, as multimedia streaming > > > - 00-xxxx would be best-effort > > > -01-1-111 would be very low-latency data > > > -01-1-000 would be low-priority data > > > > > > One advantage of this is that some routers may only take into account= the > > > first two bits, and others would use all of them. > > > > > > The new RFC could suggest or define=20 > different values of real-time-ness for > > > each application. So the applications should be ordered depending of= the > > > maximum tolerated delay. > > > > > > Ok. This is only an idea. Perhaps it does not make sense. Just tell= me. > > > Regards, > > > > > > Jose > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > > Enviado el: jueves, 05 de abril de 2012 12:23 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > regarding QoS, I'm happy to agree on 4=20 > standard classes with properties as > > > mentioned in my last email. If there's consensus on some codepoints= for > > > them, I'll support that. > > > > > > If IETF recommends how and which applications to use these > > > classes/codepoints, that's again agreeable. I don't think, that by now > > > requiring a specific application to carry a=20 > specific DSCP makes sense, apart > > > from few exceptions (like VoIP payload,=20 > network management traffic or Best > > > Effort traffic). > > > IETF needs consensus to do that. > > > Note that the number of AF classes and=20 > codepoints are troublesome. Too many > > > with too little explanation how to use them, nothing is aligned with= user > > > demand. EF/VoIP payload and network=20 > management are examples how to proceed: > > > just specify what's required, no extras. > > > > > > > > > Then regarding tunnels and header compression Yes, that's smart and= there > > > may be more use cases than gaming. I'm a=20 > backbone engineer however and your > > > proposal is rather application specific. What I can do is ask some > > > colleagues on their view. But there's no=20 > guarantee, that they will respond. > > > > > > Some initial thoughts: > > > To me a key point seems to be what can be=20 > reached at the bottleneck. There > > > the compression should save bandwidth with little cost and no negative > > > service impact. Any kind of shared access=20 > from which traffic is transmitted > > > to the same destination seems to be relevant. The application/tunnel > > > awareness of network elements may not be=20 > feasible, a network terminal at a > > > UNI may be able to handle that, or any=20 > service specific device in a network. > > > > > > Regards, > > > > > > Ruediger > > > > > > > > > -----Original Message----- > > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > > Sent: Thursday, April 05, 2012 11:29 AM > > > To: Geib, R=FCdiger > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Ruediger, > > > > > > I have read your message about=20 > draft-polk-tsvwg-rfc4594-update. As you may > > > know, I presented another draft in Paris=20 > (draft-saldana-tsvwg-tcmtf-02), and > > > after talking to James, I thought that the=20 > idea of standardizing the traffic > > > classification fits well with my proposal.=20 > I would like to know your opinion > > > about it, if possible. > > > > > > The idea is to use tunnels in order to compress and multiplex= real-time > > > traffic flows. Since these flows tend to=20 > use very small packets, they have > > > very bad efficiency. So perhaps tunnels could be used in order to= group > > > these flows. The drawback is that they add small delays, i.e. the= waiting > > > time in the multiplexer. So another use is to provide flexibility: if= you > > > are a game provider, you may over provision=20 > your network in order to be able > > > to manage traffic peaks. But perhaps using=20 > this, you may be able to have a > > > smaller network, and use compression when=20 > necessary (rush hour, first days > > > after releasing a new game, etc). When traffic is small, you do not > > > multiplex, in order to reduce latency. > > > > > > So if traffic classification is a standard, everyone in the way from= the > > > origin to the destination will handle the=20 > traffic with the correct priority. > > > > > > I attach a figure in order to clarify. > > > > > > Thank you, > > > > > > Jose > > > > > > PS: In > > >=20 >= http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World-of-Wa= r > > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can= find > > > the history of the problems of World of=20 > Warcraft for Virgin Media users. The > > > problem was caused by a modification in the traffic, and the provider= did > > > not notice about it, so it treated the packets as best-effort. > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de=20 > [mailto:Ruediger.Geib@telekom.de] Enviado el: > > > jueves, 05 de abril de 2012 9:49 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > you raise an interesting point: > > > > > > draft-polk-tsvwg-rfc4594-update suggests to standardise application to > > > codepoint mapping as well as codepoint to=20 > class properties. You observe that > > > some games are using TCP while others use UDP, which I think is a= useful > > > level of QoS requirement abstraction.=20 > There's no need to have like 25+ QoS > > > (sub)classes, I think. But one class=20 > optimised to transport "UDP" and one > > > for "TCP" are agreeable. > > > > > > The feedback that I had on carrier class=20 > QoS usage is that there's a point > > > in standardising class properties, and certainly not to standardise > > > application mappings to classes=20 > (recommending them may however be useful). > > > My take would be to standardise four=20 > classes/properties (in brackets example > > > usage): > > > > > > a) for traffic which doesn't support re-transmits, requiring lowest= delay > > > and jitter, having limited volume and packet > > > size, but being loss tolerant (example usage VoIP) > > > b) for any other traffic which doesn't support re-transmits (let's say > > > traffic with real time like properties, but any > > > packet size and possibly high volume, UDP transport, like IPTV) > > > c) for any other traffic which supports=20 > re-transmits (QoS traffic using TCP, > > > like application signalling and network management traffic) > > > d) a default class, for any traffic=20 > supporting re-transmits (Best Effort) - > > > this class may not be regarded as QoS (or as lowest CoS) > > > > > > What I can tell ist that many carriers and standards on QoS support= 3-4 > > > classes, having properties as described above. It is useful to= recommend > > > codepoints matching to these classes. Standardising these codepoints > > > requires agreement between those having=20 > deplyed them. Straightforward for a) > > > EF and d) 000000, probably easy for c) being used to transport Network > > > Management (CS 6). I'm not aware of common ground for anything else.= My > > > favourites are: > > > > > > b) AF4 (GSMA supports this one, RFC4594 also) > > > c) AF3 (MEF and GSMA support this one) > > > > > > Gaming from my point of view would then=20 > match to an AF3 or AF4 class, this > > > may depend on the implemented application=20 > transport. Further details may be > > > discussed. > > > > > > Everything else could be reserved, but shouldn't be recommended.= Carriers > > > have deployed differing schemes on=20 > codepoints and classes. They need coding > > > reserverves in 3 bit space (MPLS TC, IP=20 > Precedence and Ethernet P-Bits) as > > > well as in DSCP space if they should converge to a standardised > > > codepoint/class scheme. > > > > > > I object to any approach standardising a=20 > match of classes and applications > > > with codepoints as a requirement and I also=20 > object to standards leaving no > > > spare codepoints in 3 bit or 6 bit QoS=20 > codepoint space (including 3 bit IP > > > precedence). > > > > > > Bob Briscoe mentioned the difference between classes and queues and= above > > > properties can be mapped to queues. If end=20 > to end QoS is desired, the same > > > class properties must be negotiated end to end. The lower the number= of > > > classes and codepoints being deployed, the=20 > higher the probability of getting > > > end to end QoS. I don't support an approach requiring 8 three bit= classes > > > and 25 or more 6 bit classes and codepoints. > > > > > > Regards, > > > > > > Ruediger > > > > > > ________________________________ > > > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf= Of > > > Jose Saldana > > > Sent: Monday, April 02, 2012 12:17 PM > > > To: James Polk > > > Cc: tsvwg@ietf.org > > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > > > > > > > James, > > > > > > > > > > > > After returning home from IETF 83, I have=20 > been reading your draft. I find it > > > interesting to standardize the service classes. Otherwise, if each one > > > classifies each traffic according to different criteria, Diffserv= becomes > > > less useful. > > > > > > > > > > > > Regarding "Real-time interactive" service class, which refers to= online > > > gaming (my main research field), I find it=20 > really interesting: online games > > > are at least as real-time as VoIP is. In=20 > most cases, the gamers are a very > > > difficult people to deal with. If the=20 > latency is high, they leave and never > > > return (this statement is not mine, it can=20 > be corroborated in the references > > > I put below). This has been studied by many=20 > research groups, with empirical > > > tests using real gamers and adding delay, jitter, packet loss. > > > > > > > > > > > > Other question: in the draft it is said that online games use RTP/UDP > > > streams. This can be a little confusing. In fact, the vast majority of > > > online games do not use RTP, but bare UDP or even TCP. In > > > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.pdf,= the > > > authors proposed the use of an adaptation=20 > of RTP in order to manage gaming > > > traffic. But as far as I know, this approach is not used by commercial > > > games. > > > > > > > > > > > > > > > > > > A typical classification of today's games is: > > > > > > > > > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, Call= of > > > Duty: They use UDP > > > > > > - MMORPG (Massively Multiplayer Online Role-playing Games),= e.g. > > > World of Warcraft: They normally use TCP,=20 > even though some of them use UDP > > > > > > - RTS (Real-time strategy) e.g.=20 > Age of Empires: They may use TCP or > > > UDP > > > > > > - Sports games: Since there is a big variety, they have not= been > > > deeply studied in the literature > > > > > > > > > > > > Some research papers supporting this=20 > classification, and also the real-time > > > requirements of the games: > > > > > > > > > > > > First Person Shooters > > > > > > > > > > > > - A survey of traffic models for 17 First Person Shooters can= be > > > found here. All of them use UDP > > >= http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE-IC.pdf > > > > > > > > > > > > - In this paper from my research=20 > group, 8 FPS games were analyzed > > > in order to compress and multiplex their traffic. Figure 5 shows their > > > histograms (inter-packet time and packet size). It can be seen that= they > > > generate real-time flows, with=20 > characteristics very similar to VoIP (packets > > > of 60-80 bytes every 15-40 ms): > > > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana.pdf > > > > > > > > > > > > - Another paper about FPS using UDP. Section V presents some > > > interesting conclusions about routing infrastructure. > > > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > > > > > > > > > - In this paper the network factors annoying the gamers are > > > analyzed. There are also some calculations of the MOS. Above 150 ms= the > > > quality is bad (something similar to what happens with VoIP) > > > http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > > > > > > > > > - In this one, a MOS model for a=20 > FPS (Quake IV) is deployed. It is > > > only based on delay and jitter, since=20 > packet loss has vevy little influence > > > (for this concrete game). Delay above 140 ms produces MOS below 3 > > > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > > > > > > > > > - In this paper, it is found that=20 > some FPS work properly even with > > > 30% packet loss, whereas others stop=20 > working with 4%. RTT above 300 ms (150 > > > OWD) makes MOS go above 3 > > > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > > > > > > > > > MMORPGs: > > > > > > - A traffic model for World of Warcraft: > > > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > > > > > > > > > - This one presents a MOS for=20 > World of Warcraft. When added delay > > > is above 160ms, the MOS is roughly 3.: > > > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Jose Saldana > > > > > > > > From jsaldana@unizar.es Fri Apr 27 01:06:14 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE59D21F8608 for ; Fri, 27 Apr 2012 01:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJVWgbGml6QH for ; Fri, 27 Apr 2012 01:06:07 -0700 (PDT) Received: from isuela.unizar.es (isuela.unizar.es [155.210.1.53]) by ietfa.amsl.com (Postfix) with ESMTP id DF45321F845E for ; Fri, 27 Apr 2012 01:06:06 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by isuela.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q3R85ve2011194; Fri, 27 Apr 2012 10:05:58 +0200 From: "Jose Saldana" To: "'James M. Polk'" References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> <8D3D17ACE214DC429325B2B98F3AE71203502D41@MX15A.corp.emc.com> <201204262116.q3QLGwZj011390@mtv-core-4.cisco.com> In-Reply-To: <201204262116.q3QLGwZj011390@mtv-core-4.cisco.com> Date: Fri, 27 Apr 2012 10:06:02 +0200 Organization: Universidad de Zaragoza Message-ID: <000e01cd244c$9714ce50$c53e6af0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDAHno+m9AcWm5SsCxe9GxwIfk3tOAlQErS+WI7BmwA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tsvwg@ietf.org Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:06:14 -0000 James, I think it is clear that people agree with the need of rewriting RFC5127 = in conjunction with RFC4594. I also agree. If you want, I could help you with that task. Just tell me. Next two = months I think I will have a little more available time. Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de James M. Polk Enviado el: jueves, 26 de abril de 2012 23:17 Para: david.black@emc.com CC: tsvwg@ietf.org Asunto: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt David I absolutely agree with you that these two efforts (the current rewrite = of RFC4594, and the coming rewrite of RFC5127) need to be synchronized to = have either make proper sense. I also agree that the rewrite of RFC5127 is = where a smaller, aggregated set of classes for core networks. Ruediger = mentioned his worry about "folks viewing tables and just configuring based on the tables". Clearly his concerns on that need to be addressed. I'll work to get my initial version of the rewrite of RFC5127 in before Vancouver. James At 07:17 PM 4/25/2012, david.black@emc.com wrote: >Ruediger, > >We may be disagreeing more about means than ends. > >RFC 5127's intent was to aggregate all of the classes defined in RFC=20 >4594 into a much smaller number of classes that would be suitable for a = >core network, e.g., "3-4 classes and require no more than 6=20 >codepoints". The net would be that a choice of considerably more=20 >traffic classes from RFC >4594 would be deployable via aggregation as a suitably small number of=20 >classes on the wire. > >I believe (and I've said so to James), that RFC 5127 needs to be=20 >revised in concert with any work on RFC 4594 (in particular, I strongly = >oppose any revision to 4594 that ignores 5127). I also think that RFC=20 >5127 is a better starting point to address the small number of classes=20 >use case that appears to be of interest and concern to you. > >Thanks, >--David > > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Tuesday, April 24, 2012 5:56 AM > > To: Black, David > > Cc: tsvwg@ietf.org > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > David, > > > > taking a formal point of view, you are probably right. These isues=20 > > are intertwined however. > > > > End to end QoS will certainly not result from continuing to act like = > > almost all standards bodies did so far: as there's a lot flexibility = > > and little non-ambiguous guidance, anything is customised. > > > > I don't regard the update of RFC 4594 as being helpful if the=20 > > expectation of the author is that even supporters of that standard=20 > > will only deploy a subset of the defined classes and sub classes.=20 > > Those standards close to deployment I know offer 3-4 classes and=20 > > require no more than 6 codepoints (the latter is personal = judgement). > > > > Any standards track QoS document should only determine things seeing = > > widespread deployment. > > > > Some QoS classes have seen deployment. It's trickier with = codepoints. > > > > Anything which might be useful in future or has seen an=20 > > informational proposal in past should be critically reviewed and=20 > > remain informational or experimental. > > > > Any QoS class should be well defined any easy to be differentiated=20 > > against others. > > > > QoS codepoints should not identify applications. > > > > I also don't think that one needs to differentiate "admitted" from=20 > > "non-admitted" classes. In a traffic engineered DiffServ network,=20 > > customers get an SLA describing the worst case QoS class = performance. > > To me it doesn't matter how a carrier ensures that the SLAs are = kept. > > It only matters that they are kept. > > > > Regards, > > > > Ruediger > > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of=20 > > > them are ECN, and six of them are the DSCP field. So > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only=20 > > > experimentally assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion, > more than 4 classes are not useful, > > > according to current implementations. > > > > That's actually not appropriate for an RFC > 4594 update - the proper place to > > address that requirement is an update to RFC 5127, which will need=20 > > to be updated to be consistent with whatever is done to RFC 4594. > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On=20 > > > Behalf Of > > Jose > > > Saldana > > > Sent: Saturday, April 07, 2012 8:03 AM > > > To: Ruediger.Geib@telekom.de; James M. Polk > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > I have been reading the two messages of > Ruediger about Jame's draft. I will > > > try to make a "status of the question" and > then a proposal. If something is > > > wrong, just tell me. > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of=20 > > > them are ECN, and six of them are the DSCP field. So > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only=20 > > > experimentally assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion, > more than 4 classes are not useful, > > > according to current implementations. > > > > > > We can ask ourselves: which are the key > parameters that define how packets > > > have to be managed in a router? I think that they are: > > > > > > 1) "Real-time-ness": The tolerated delay of > the service. The jitter can be > > > roughly included in this parameter. > > > 2) loss tolerance: We can distinguish: TCP services are tolerant=20 > > > to loss, since they retransmit packets. And some UDP services are=20 > > > also tolerant to loss (VoIP, some games, etc) > > > > > > In my opinion, the "real-time-ness" is the key: it distinguishes=20 > > > very similar services: e.g. a video conference is different from a = > > > broadcast, since the latter permits delays of some > seconds, whereas the first has to be > > > interactive. > > > > > > So one possible solution could be: > > > > > > - Using the first two bits in order to > define 4 classes, taking into account > > > the existing implementations. They can be > the 4 classes of Fig. 1 of James' > > > draft, or the ones proposed by Ruediger. > > > 00xxxx best effort > > > 01xxxx data > > > 10xxxx media oriented > > > 11xxxx control > > > > > > - With the other 4 bits, something should be done. My proposal: > > > - If the third bit is "1", then the > other three bits include a value > > > defining the "real-time-ness" of the flow. So we have 8 levels of=20 > > > real-time-ness. Some examples: > > > - 10-1-111 would be a media-oriented (10) and very=20 > > > real-time flow, as VoIP or a game > > > - 10-0-xxx would be a media-oriented flow for which=20 > > > the real-time-ness is not defined > > > - 10-1-010 could be a media-oriented flow with=20 > > > medium delay requirements, as multimedia conferencing > > > - 10-1-000 would be a media-oriented flow with no=20 > > > very hard delay requirements, as multimedia streaming > > > - 00-xxxx would be best-effort > > > -01-1-111 would be very low-latency data > > > -01-1-000 would be low-priority data > > > > > > One advantage of this is that some routers may only take into=20 > > > account the first two bits, and others would use all of them. > > > > > > The new RFC could suggest or define > different values of real-time-ness for > > > each application. So the applications should be ordered depending=20 > > > of the maximum tolerated delay. > > > > > > Ok. This is only an idea. Perhaps it does not make sense. Just = tell me. > > > Regards, > > > > > > Jose > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 > > > Enviado el: jueves, 05 de abril de 2012 12:23 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > regarding QoS, I'm happy to agree on 4 > standard classes with properties as > > > mentioned in my last email. If there's consensus on some=20 > > > codepoints for them, I'll support that. > > > > > > If IETF recommends how and which applications to use these=20 > > > classes/codepoints, that's again agreeable. I don't think, that by = > > > now requiring a specific application to carry a > specific DSCP makes sense, apart > > > from few exceptions (like VoIP payload, > network management traffic or Best > > > Effort traffic). > > > IETF needs consensus to do that. > > > Note that the number of AF classes and > codepoints are troublesome. Too many > > > with too little explanation how to use them, nothing is aligned=20 > > > with user demand. EF/VoIP payload and network > management are examples how to proceed: > > > just specify what's required, no extras. > > > > > > > > > Then regarding tunnels and header compression Yes, that's smart=20 > > > and there may be more use cases than gaming. I'm a > backbone engineer however and your > > > proposal is rather application specific. What I can do is ask some = > > > colleagues on their view. But there's no > guarantee, that they will respond. > > > > > > Some initial thoughts: > > > To me a key point seems to be what can be > reached at the bottleneck. There > > > the compression should save bandwidth with little cost and no=20 > > > negative service impact. Any kind of shared access > from which traffic is transmitted > > > to the same destination seems to be relevant. The=20 > > > application/tunnel awareness of network elements may not be > feasible, a network terminal at a > > > UNI may be able to handle that, or any > service specific device in a network. > > > > > > Regards, > > > > > > Ruediger > > > > > > > > > -----Original Message----- > > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > > Sent: Thursday, April 05, 2012 11:29 AM > > > To: Geib, R=FCdiger > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Ruediger, > > > > > > I have read your message about > draft-polk-tsvwg-rfc4594-update. As you may > > > know, I presented another draft in Paris > (draft-saldana-tsvwg-tcmtf-02), and > > > after talking to James, I thought that the > idea of standardizing the traffic > > > classification fits well with my proposal.=20 > I would like to know your opinion > > > about it, if possible. > > > > > > The idea is to use tunnels in order to compress and multiplex=20 > > > real-time traffic flows. Since these flows tend to > use very small packets, they have > > > very bad efficiency. So perhaps tunnels could be used in order to=20 > > > group these flows. The drawback is that they add small delays,=20 > > > i.e. the waiting time in the multiplexer. So another use is to=20 > > > provide flexibility: if you are a game provider, you may over=20 > > > provision > your network in order to be able > > > to manage traffic peaks. But perhaps using > this, you may be able to have a > > > smaller network, and use compression when > necessary (rush hour, first days > > > after releasing a new game, etc). When traffic is small, you do=20 > > > not multiplex, in order to reduce latency. > > > > > > So if traffic classification is a standard, everyone in the way=20 > > > from the origin to the destination will handle the > traffic with the correct priority. > > > > > > I attach a figure in order to clarify. > > > > > > Thank you, > > > > > > Jose > > > > > > PS: In > > >=20 > http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World- > of-War > > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you=20 > > > can find the history of the problems of World of > Warcraft for Virgin Media users. The > > > problem was caused by a modification in the traffic, and the=20 > > > provider did not notice about it, so it treated the packets as best-effort. > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de > [mailto:Ruediger.Geib@telekom.de] Enviado el: > > > jueves, 05 de abril de 2012 9:49 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > you raise an interesting point: > > > > > > draft-polk-tsvwg-rfc4594-update suggests to standardise=20 > > > application to codepoint mapping as well as codepoint to > class properties. You observe that > > > some games are using TCP while others use UDP, which I think is a=20 > > > useful level of QoS requirement abstraction. > There's no need to have like 25+ QoS > > > (sub)classes, I think. But one class > optimised to transport "UDP" and one > > > for "TCP" are agreeable. > > > > > > The feedback that I had on carrier class > QoS usage is that there's a point > > > in standardising class properties, and certainly not to=20 > > > standardise application mappings to classes > (recommending them may however be useful). > > > My take would be to standardise four > classes/properties (in brackets example > > > usage): > > > > > > a) for traffic which doesn't support re-transmits, requiring=20 > > > lowest delay and jitter, having limited volume and packet > > > size, but being loss tolerant (example usage VoIP) > > > b) for any other traffic which doesn't support re-transmits (let's = > > > say traffic with real time like properties, but any > > > packet size and possibly high volume, UDP transport, like IPTV) > > > c) for any other traffic which supports > re-transmits (QoS traffic using TCP, > > > like application signalling and network management traffic) > > > d) a default class, for any traffic > supporting re-transmits (Best Effort) - > > > this class may not be regarded as QoS (or as lowest CoS) > > > > > > What I can tell ist that many carriers and standards on QoS=20 > > > support 3-4 classes, having properties as described above. It is=20 > > > useful to recommend codepoints matching to these classes.=20 > > > Standardising these codepoints requires agreement between those=20 > > > having > deplyed them. Straightforward for a) > > > EF and d) 000000, probably easy for c) being used to transport=20 > > > Network Management (CS 6). I'm not aware of common ground for=20 > > > anything else. My favourites are: > > > > > > b) AF4 (GSMA supports this one, RFC4594 also) > > > c) AF3 (MEF and GSMA support this one) > > > > > > Gaming from my point of view would then > match to an AF3 or AF4 class, this > > > may depend on the implemented application > transport. Further details may be > > > discussed. > > > > > > Everything else could be reserved, but shouldn't be recommended.=20 > > > Carriers have deployed differing schemes on > codepoints and classes. They need coding > > > reserverves in 3 bit space (MPLS TC, IP > Precedence and Ethernet P-Bits) as > > > well as in DSCP space if they should converge to a standardised=20 > > > codepoint/class scheme. > > > > > > I object to any approach standardising a > match of classes and applications > > > with codepoints as a requirement and I also > object to standards leaving no > > > spare codepoints in 3 bit or 6 bit QoS > codepoint space (including 3 bit IP > > > precedence). > > > > > > Bob Briscoe mentioned the difference between classes and queues=20 > > > and above properties can be mapped to queues. If end > to end QoS is desired, the same > > > class properties must be negotiated end to end. The lower the=20 > > > number of classes and codepoints being deployed, the > higher the probability of getting > > > end to end QoS. I don't support an approach requiring 8 three bit=20 > > > classes and 25 or more 6 bit classes and codepoints. > > > > > > Regards, > > > > > > Ruediger > > > > > > ________________________________ > > > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On=20 > > > Behalf Of Jose Saldana > > > Sent: Monday, April 02, 2012 12:17 PM > > > To: James Polk > > > Cc: tsvwg@ietf.org > > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > > > > > > > James, > > > > > > > > > > > > After returning home from IETF 83, I have > been reading your draft. I find it > > > interesting to standardize the service classes. Otherwise, if each = > > > one classifies each traffic according to different criteria,=20 > > > Diffserv becomes less useful. > > > > > > > > > > > > Regarding "Real-time interactive" service class, which refers to=20 > > > online gaming (my main research field), I find it > really interesting: online games > > > are at least as real-time as VoIP is. In > most cases, the gamers are a very > > > difficult people to deal with. If the > latency is high, they leave and never > > > return (this statement is not mine, it can > be corroborated in the references > > > I put below). This has been studied by many > research groups, with empirical > > > tests using real gamers and adding delay, jitter, packet loss. > > > > > > > > > > > > Other question: in the draft it is said that online games use=20 > > > RTP/UDP streams. This can be a little confusing. In fact, the vast = > > > majority of online games do not use RTP, but bare UDP or even TCP. = > > > In=20 > > > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.p > > > df, the authors proposed the use of an adaptation > of RTP in order to manage gaming > > > traffic. But as far as I know, this approach is not used by=20 > > > commercial games. > > > > > > > > > > > > > > > > > > A typical classification of today's games is: > > > > > > > > > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, = Call of > > > Duty: They use UDP > > > > > > - MMORPG (Massively Multiplayer Online Role-playing = Games), e.g. > > > World of Warcraft: They normally use TCP, > even though some of them use UDP > > > > > > - RTS (Real-time strategy) e.g.=20 > Age of Empires: They may use TCP or > > > UDP > > > > > > - Sports games: Since there is a big variety, they have = not been > > > deeply studied in the literature > > > > > > > > > > > > Some research papers supporting this > classification, and also the real-time > > > requirements of the games: > > > > > > > > > > > > First Person Shooters > > > > > > > > > > > > - A survey of traffic models for 17 First Person Shooters = can be > > > found here. All of them use UDP > > > http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE > > > -IC.pdf > > > > > > > > > > > > - In this paper from my research=20 > group, 8 FPS games were analyzed > > > in order to compress and multiplex their traffic. Figure 5 shows=20 > > > their histograms (inter-packet time and packet size). It can be=20 > > > seen that they generate real-time flows, with > characteristics very similar to VoIP (packets > > > of 60-80 bytes every 15-40 ms): > > > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana. > > > pdf > > > > > > > > > > > > - Another paper about FPS using UDP. Section V presents = some > > > interesting conclusions about routing infrastructure. > > > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > > > > > > > > > - In this paper the network factors annoying the gamers = are > > > analyzed. There are also some calculations of the MOS. Above 150=20 > > > ms the quality is bad (something similar to what happens with=20 > > > VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > > > > > > > > > - In this one, a MOS model for a=20 > FPS (Quake IV) is deployed. It is > > > only based on delay and jitter, since > packet loss has vevy little influence > > > (for this concrete game). Delay above 140 ms produces MOS below 3=20 > > > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > > > > > > > > > - In this paper, it is found that=20 > some FPS work properly even with > > > 30% packet loss, whereas others stop > working with 4%. RTT above 300 ms (150 > > > OWD) makes MOS go above 3 > > > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > > > > > > > > > MMORPGs: > > > > > > - A traffic model for World of Warcraft: > > > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > > > > > > > > > - This one presents a MOS for=20 > World of Warcraft. When added delay > > > is above 160ms, the MOS is roughly 3.: > > > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Jose Saldana > > > > > > > > From Ruediger.Geib@telekom.de Fri Apr 27 01:31:46 2012 Return-Path: X-Original-To: tsvwg@ietfa.amsl.com Delivered-To: tsvwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088C321F86C5 for ; Fri, 27 Apr 2012 01:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzGlenLOPttT for ; Fri, 27 Apr 2012 01:31:44 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3F721F869D for ; Fri, 27 Apr 2012 01:31:43 -0700 (PDT) Received: from he111630.emea1.cds.t-internal.com ([10.134.93.22]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 27 Apr 2012 10:31:18 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.136]) by HE111630.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 27 Apr 2012 10:31:17 +0200 From: To: Date: Fri, 27 Apr 2012 10:31:16 +0200 Thread-Topic: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt Thread-Index: AQHTz3/pe5777mJ5ARKWkD2W7JDgwAF0NXZYAT3+Pj4CD98kDAHno+m9AcWm5SsCxe9GxwIfk3tOAlQErS+WI7BmwIAACMOA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13DF00725E@HE111648.emea1.cds.t-internal.com> References: <007b01cd10b9$c1c80dc0$45582940$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980BDC@HE111648.emea1.cds.t-internal.com> <000b01cd130e$78c48f70$6a4dae50$@unizar.es> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DE980E7A@HE111648.emea1.cds.t-internal.com> <000c01cd14b6$70b33ad0$5219b070$@unizar.es> <8D3D17ACE214DC429325B2B98F3AE7120534EA@MX15A.corp.emc.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D13DEF36D2F@HE111648.emea1.cds.t-internal.com> <8D3D17ACE214DC429325B2B98F3AE71203502D41@MX15A.corp.emc.com> <201204262116.q3QLGwZj011390@mtv-core-4.cisco.com> <000e01cd244c$9714ce50$c53e6af0$@unizar.es> In-Reply-To: <000e01cd244c$9714ce50$c53e6af0$@unizar.es> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:31:46 -0000 Jose, I'd like to join in and also volunteer to co-author, but that for me depends on the contents we find consensus upon. My time is administered in Best Effort mode however... Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of J= ose Saldana Sent: Friday, April 27, 2012 10:06 AM To: 'James M. Polk' Cc: tsvwg@ietf.org Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt James, I think it is clear that people agree with the need of rewriting RFC5127 in conjunction with RFC4594. I also agree. If you want, I could help you with that task. Just tell me. Next two months I think I will have a little more available time. Jose -----Mensaje original----- De: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] En nombre de James M. Polk Enviado el: jueves, 26 de abril de 2012 23:17 Para: david.black@emc.com CC: tsvwg@ietf.org Asunto: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt David I absolutely agree with you that these two efforts (the current rewrite of RFC4594, and the coming rewrite of RFC5127) need to be synchronized to have either make proper sense. I also agree that the rewrite of RFC5127 is where a smaller, aggregated set of classes for core networks. Ruediger mentioned his worry about "folks viewing tables and just configuring based on the tables". Clearly his concerns on that need to be addressed. I'll work to get my initial version of the rewrite of RFC5127 in before Vancouver. James At 07:17 PM 4/25/2012, david.black@emc.com wrote: >Ruediger, > >We may be disagreeing more about means than ends. > >RFC 5127's intent was to aggregate all of the classes defined in RFC >4594 into a much smaller number of classes that would be suitable for a >core network, e.g., "3-4 classes and require no more than 6 >codepoints". The net would be that a choice of considerably more >traffic classes from RFC >4594 would be deployable via aggregation as a suitably small number of >classes on the wire. > >I believe (and I've said so to James), that RFC 5127 needs to be >revised in concert with any work on RFC 4594 (in particular, I strongly >oppose any revision to 4594 that ignores 5127). I also think that RFC >5127 is a better starting point to address the small number of classes >use case that appears to be of interest and concern to you. > >Thanks, >--David > > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Tuesday, April 24, 2012 5:56 AM > > To: Black, David > > Cc: tsvwg@ietf.org > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > David, > > > > taking a formal point of view, you are probably right. These isues > > are intertwined however. > > > > End to end QoS will certainly not result from continuing to act like > > almost all standards bodies did so far: as there's a lot flexibility > > and little non-ambiguous guidance, anything is customised. > > > > I don't regard the update of RFC 4594 as being helpful if the > > expectation of the author is that even supporters of that standard > > will only deploy a subset of the defined classes and sub classes. > > Those standards close to deployment I know offer 3-4 classes and > > require no more than 6 codepoints (the latter is personal judgement). > > > > Any standards track QoS document should only determine things seeing > > widespread deployment. > > > > Some QoS classes have seen deployment. It's trickier with codepoints. > > > > Anything which might be useful in future or has seen an > > informational proposal in past should be critically reviewed and > > remain informational or experimental. > > > > Any QoS class should be well defined any easy to be differentiated > > against others. > > > > QoS codepoints should not identify applications. > > > > I also don't think that one needs to differentiate "admitted" from > > "non-admitted" classes. In a traffic engineered DiffServ network, > > customers get an SLA describing the worst case QoS class performance. > > To me it doesn't matter how a carrier ensures that the SLAs are kept. > > It only matters that they are kept. > > > > Regards, > > > > Ruediger > > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of > > > them are ECN, and six of them are the DSCP field. So > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only > > > experimentally assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion, > more than 4 classes are not useful, > > > according to current implementations. > > > > That's actually not appropriate for an RFC > 4594 update - the proper place to > > address that requirement is an update to RFC 5127, which will need > > to be updated to be consistent with whatever is done to RFC 4594. > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > > > Behalf Of > > Jose > > > Saldana > > > Sent: Saturday, April 07, 2012 8:03 AM > > > To: Ruediger.Geib@telekom.de; James M. Polk > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > I have been reading the two messages of > Ruediger about Jame's draft. I will > > > try to make a "status of the question" and > then a proposal. If something is > > > wrong, just tell me. > > > > > > - We have the old 8 TOS bits of the IP header. Nowadays, two of > > > them are ECN, and six of them are the DSCP field. So > the problem is how to use these > > > 6 bits (64 possible values) > > > - Network control is 11xxxx, so this uses 16 values > > > -11xx11 are defined in RFC 2474, and remain as only > > > experimentally assignable/useable (this uses 4 of these 16 values) > > > - This leaves 48 values > > > - Best effort is 000000 > > > - The draft of James proposes 14 values for > the DSCP field, which correspond > > > to service classes, mapped to application categories. > > > > > > But Ruediger says that, in his opinion, > more than 4 classes are not useful, > > > according to current implementations. > > > > > > We can ask ourselves: which are the key > parameters that define how packets > > > have to be managed in a router? I think that they are: > > > > > > 1) "Real-time-ness": The tolerated delay of > the service. The jitter can be > > > roughly included in this parameter. > > > 2) loss tolerance: We can distinguish: TCP services are tolerant > > > to loss, since they retransmit packets. And some UDP services are > > > also tolerant to loss (VoIP, some games, etc) > > > > > > In my opinion, the "real-time-ness" is the key: it distinguishes > > > very similar services: e.g. a video conference is different from a > > > broadcast, since the latter permits delays of some > seconds, whereas the first has to be > > > interactive. > > > > > > So one possible solution could be: > > > > > > - Using the first two bits in order to > define 4 classes, taking into account > > > the existing implementations. They can be > the 4 classes of Fig. 1 of James' > > > draft, or the ones proposed by Ruediger. > > > 00xxxx best effort > > > 01xxxx data > > > 10xxxx media oriented > > > 11xxxx control > > > > > > - With the other 4 bits, something should be done. My proposal: > > > - If the third bit is "1", then the > other three bits include a value > > > defining the "real-time-ness" of the flow. So we have 8 levels of > > > real-time-ness. Some examples: > > > - 10-1-111 would be a media-oriented (10) and very > > > real-time flow, as VoIP or a game > > > - 10-0-xxx would be a media-oriented flow for which > > > the real-time-ness is not defined > > > - 10-1-010 could be a media-oriented flow with > > > medium delay requirements, as multimedia conferencing > > > - 10-1-000 would be a media-oriented flow with no > > > very hard delay requirements, as multimedia streaming > > > - 00-xxxx would be best-effort > > > -01-1-111 would be very low-latency data > > > -01-1-000 would be low-priority data > > > > > > One advantage of this is that some routers may only take into > > > account the first two bits, and others would use all of them. > > > > > > The new RFC could suggest or define > different values of real-time-ness for > > > each application. So the applications should be ordered depending > > > of the maximum tolerated delay. > > > > > > Ok. This is only an idea. Perhaps it does not make sense. Just tell me. > > > Regards, > > > > > > Jose > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > > Enviado el: jueves, 05 de abril de 2012 12:23 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > regarding QoS, I'm happy to agree on 4 > standard classes with properties as > > > mentioned in my last email. If there's consensus on some > > > codepoints for them, I'll support that. > > > > > > If IETF recommends how and which applications to use these > > > classes/codepoints, that's again agreeable. I don't think, that by > > > now requiring a specific application to carry a > specific DSCP makes sense, apart > > > from few exceptions (like VoIP payload, > network management traffic or Best > > > Effort traffic). > > > IETF needs consensus to do that. > > > Note that the number of AF classes and > codepoints are troublesome. Too many > > > with too little explanation how to use them, nothing is aligned > > > with user demand. EF/VoIP payload and network > management are examples how to proceed: > > > just specify what's required, no extras. > > > > > > > > > Then regarding tunnels and header compression Yes, that's smart > > > and there may be more use cases than gaming. I'm a > backbone engineer however and your > > > proposal is rather application specific. What I can do is ask some > > > colleagues on their view. But there's no > guarantee, that they will respond. > > > > > > Some initial thoughts: > > > To me a key point seems to be what can be > reached at the bottleneck. There > > > the compression should save bandwidth with little cost and no > > > negative service impact. Any kind of shared access > from which traffic is transmitted > > > to the same destination seems to be relevant. The > > > application/tunnel awareness of network elements may not be > feasible, a network terminal at a > > > UNI may be able to handle that, or any > service specific device in a network. > > > > > > Regards, > > > > > > Ruediger > > > > > > > > > -----Original Message----- > > > From: Jose Saldana [mailto:jsaldana@unizar.es] > > > Sent: Thursday, April 05, 2012 11:29 AM > > > To: Geib, R=FCdiger > > > Cc: tsvwg@ietf.org > > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Ruediger, > > > > > > I have read your message about > draft-polk-tsvwg-rfc4594-update. As you may > > > know, I presented another draft in Paris > (draft-saldana-tsvwg-tcmtf-02), and > > > after talking to James, I thought that the > idea of standardizing the traffic > > > classification fits well with my proposal. > I would like to know your opinion > > > about it, if possible. > > > > > > The idea is to use tunnels in order to compress and multiplex > > > real-time traffic flows. Since these flows tend to > use very small packets, they have > > > very bad efficiency. So perhaps tunnels could be used in order to > > > group these flows. The drawback is that they add small delays, > > > i.e. the waiting time in the multiplexer. So another use is to > > > provide flexibility: if you are a game provider, you may over > > > provision > your network in order to be able > > > to manage traffic peaks. But perhaps using > this, you may be able to have a > > > smaller network, and use compression when > necessary (rush hour, first days > > > after releasing a new game, etc). When traffic is small, you do > > > not multiplex, in order to reduce latency. > > > > > > So if traffic classification is a standard, everyone in the way > > > from the origin to the destination will handle the > traffic with the correct priority. > > > > > > I attach a figure in order to clarify. > > > > > > Thank you, > > > > > > Jose > > > > > > PS: In > > > > http://community.virginmedia.com/t5/Fibre-optic-broadband-cable/World- > of-War > > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you > > > can find the history of the problems of World of > Warcraft for Virgin Media users. The > > > problem was caused by a modification in the traffic, and the > > > provider did not notice about it, so it treated the packets as best-effort. > > > > > > -----Mensaje original----- > > > De: Ruediger.Geib@telekom.de > [mailto:Ruediger.Geib@telekom.de] Enviado el: > > > jueves, 05 de abril de 2012 9:49 > > > Para: jsaldana@unizar.es > > > CC: tsvwg@ietf.org > > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > Jose, > > > > > > you raise an interesting point: > > > > > > draft-polk-tsvwg-rfc4594-update suggests to standardise > > > application to codepoint mapping as well as codepoint to > class properties. You observe that > > > some games are using TCP while others use UDP, which I think is a > > > useful level of QoS requirement abstraction. > There's no need to have like 25+ QoS > > > (sub)classes, I think. But one class > optimised to transport "UDP" and one > > > for "TCP" are agreeable. > > > > > > The feedback that I had on carrier class > QoS usage is that there's a point > > > in standardising class properties, and certainly not to > > > standardise application mappings to classes > (recommending them may however be useful). > > > My take would be to standardise four > classes/properties (in brackets example > > > usage): > > > > > > a) for traffic which doesn't support re-transmits, requiring > > > lowest delay and jitter, having limited volume and packet > > > size, but being loss tolerant (example usage VoIP) > > > b) for any other traffic which doesn't support re-transmits (let's > > > say traffic with real time like properties, but any > > > packet size and possibly high volume, UDP transport, like IPTV) > > > c) for any other traffic which supports > re-transmits (QoS traffic using TCP, > > > like application signalling and network management traffic) > > > d) a default class, for any traffic > supporting re-transmits (Best Effort) - > > > this class may not be regarded as QoS (or as lowest CoS) > > > > > > What I can tell ist that many carriers and standards on QoS > > > support 3-4 classes, having properties as described above. It is > > > useful to recommend codepoints matching to these classes. > > > Standardising these codepoints requires agreement between those > > > having > deplyed them. Straightforward for a) > > > EF and d) 000000, probably easy for c) being used to transport > > > Network Management (CS 6). I'm not aware of common ground for > > > anything else. My favourites are: > > > > > > b) AF4 (GSMA supports this one, RFC4594 also) > > > c) AF3 (MEF and GSMA support this one) > > > > > > Gaming from my point of view would then > match to an AF3 or AF4 class, this > > > may depend on the implemented application > transport. Further details may be > > > discussed. > > > > > > Everything else could be reserved, but shouldn't be recommended. > > > Carriers have deployed differing schemes on > codepoints and classes. They need coding > > > reserverves in 3 bit space (MPLS TC, IP > Precedence and Ethernet P-Bits) as > > > well as in DSCP space if they should converge to a standardised > > > codepoint/class scheme. > > > > > > I object to any approach standardising a > match of classes and applications > > > with codepoints as a requirement and I also > object to standards leaving no > > > spare codepoints in 3 bit or 6 bit QoS > codepoint space (including 3 bit IP > > > precedence). > > > > > > Bob Briscoe mentioned the difference between classes and queues > > > and above properties can be mapped to queues. If end > to end QoS is desired, the same > > > class properties must be negotiated end to end. The lower the > > > number of classes and codepoints being deployed, the > higher the probability of getting > > > end to end QoS. I don't support an approach requiring 8 three bit > > > classes and 25 or more 6 bit classes and codepoints. > > > > > > Regards, > > > > > > Ruediger > > > > > > ________________________________ > > > > > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > > > Behalf Of Jose Saldana > > > Sent: Monday, April 02, 2012 12:17 PM > > > To: James Polk > > > Cc: tsvwg@ietf.org > > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt > > > > > > > > > > > > James, > > > > > > > > > > > > After returning home from IETF 83, I have > been reading your draft. I find it > > > interesting to standardize the service classes. Otherwise, if each > > > one classifies each traffic according to different criteria, > > > Diffserv becomes less useful. > > > > > > > > > > > > Regarding "Real-time interactive" service class, which refers to > > > online gaming (my main research field), I find it > really interesting: online games > > > are at least as real-time as VoIP is. In > most cases, the gamers are a very > > > difficult people to deal with. If the > latency is high, they leave and never > > > return (this statement is not mine, it can > be corroborated in the references > > > I put below). This has been studied by many > research groups, with empirical > > > tests using real gamers and adding delay, jitter, packet loss. > > > > > > > > > > > > Other question: in the draft it is said that online games use > > > RTP/UDP streams. This can be a little confusing. In fact, the vast > > > majority of online games do not use RTP, but bare UDP or even TCP. > > > In > > > http://www.cn.uni-duesseldorf.de/publications/library/Mauve2001a.p > > > df, the authors proposed the use of an adaptation > of RTP in order to manage gaming > > > traffic. But as far as I know, this approach is not used by > > > commercial games. > > > > > > > > > > > > > > > > > > A typical classification of today's games is: > > > > > > > > > > > > - FPS (First Person Shooters) e.g. Counter Strike, Halo, Cal= l of > > > Duty: They use UDP > > > > > > - MMORPG (Massively Multiplayer Online Role-playing Games), e.g. > > > World of Warcraft: They normally use TCP, > even though some of them use UDP > > > > > > - RTS (Real-time strategy) e.g. > Age of Empires: They may use TCP or > > > UDP > > > > > > - Sports games: Since there is a big variety, they have not been > > > deeply studied in the literature > > > > > > > > > > > > Some research papers supporting this > classification, and also the real-time > > > requirements of the games: > > > > > > > > > > > > First Person Shooters > > > > > > > > > > > > - A survey of traffic models for 17 First Person Shooters ca= n be > > > found here. All of them use UDP > > > http://www.discover.uottawa.ca/publications/files/MMOG-Survey_IEEE > > > -IC.pdf > > > > > > > > > > > > - In this paper from my research > group, 8 FPS games were analyzed > > > in order to compress and multiplex their traffic. Figure 5 shows > > > their histograms (inter-packet time and packet size). It can be > > > seen that they generate real-time flows, with > characteristics very similar to VoIP (packets > > > of 60-80 bytes every 15-40 ms): > > > http://diec.unizar.es/~jsaldana/personal/commag_nov_2011_jsaldana. > > > pdf > > > > > > > > > > > > - Another paper about FPS using UDP. Section V presents some > > > interesting conclusions about routing infrastructure. > > > http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf > > > > > > > > > > > > - In this paper the network factors annoying the gamers are > > > analyzed. There are also some calculations of the MOS. Above 150 > > > ms the quality is bad (something similar to what happens with > > > VoIP) http://www.research.ibm.com/netgames2005/papers/dick.pdf > > > > > > > > > > > > - In this one, a MOS model for a > FPS (Quake IV) is deployed. It is > > > only based on delay and jitter, since > packet loss has vevy little influence > > > (for this concrete game). Delay above 140 ms produces MOS below 3 > > > http://www.nas.ewi.tudelft.nl/publications/2006/netgames.pdf > > > > > > > > > > > > - In this paper, it is found that > some FPS work properly even with > > > 30% packet loss, whereas others stop > working with 4%. RTT above 300 ms (150 > > > OWD) makes MOS go above 3 > > > http://caia.swin.edu.au/pubs/ATNAC04/zander-armitage-ATNAC2004.pdf > > > > > > > > > > > > MMORPGs: > > > > > > - A traffic model for World of Warcraft: > > > http://publik.tuwien.ac.at/files/pub-et_12119.pdf > > > > > > > > > > > > - This one presents a MOS for > World of Warcraft. When added delay > > > is above 160ms, the MOS is roughly 3.: > > > http://publik.tuwien.ac.at/files/PubDat_170202.pdf > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Jose Saldana > > > > > > > >