From braden at isi.edu Mon Mar 4 09:45:25 2013 From: braden at isi.edu (Bob Braden) Date: Mon, 04 Mar 2013 09:45:25 -0800 Subject: [e2e] Congestion control as a hot topic in IETF Message-ID: <5134DDB5.70103@isi.edu> I hope that people of this E2E list are reading the current thread on the IETF list about choosing a new Transport Area director who is/is not an expert in congestion control. Some of you have been around long enough to recall the congestion collapse of the (NSF-sponsored) Internet, before Van J showed us how to not be stupid when he defined the basic TCP CC mechanism. They/we invented the concept of "TCP Friendly" to try to head off a race to the bottom while providing an easy-to-understand criterion for acceptable CC. It seems like an interesting question for research to determine whether widespread adoption of some future transport protocol with an ill-advised or inadequate CC mechanism could still cause congestion collapse of large areas of the Internet,or only local patches. Or has that been researched and I missed it? Congestion control seems a bit like riding a unicycle -- even after you learn how to do it, you have to pay attention every moment or you are in danger of falling off. Bob Braden From rogerj at gmail.com Mon Mar 4 10:20:46 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 4 Mar 2013 19:20:46 +0100 Subject: [e2e] congestion control? - (was Re: Appointment of a Transport Area Director) Message-ID: changed the subject ... and added a cc to some that might not follow ietf@ On Sun, Mar 3, 2013 at 1:50 PM, Eggert, Lars wrote: > On Mar 3, 2013, at 13:37, Eric Burger wrote: >> There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. >> >> Since I believe neither is the case, it sounds like the IESG requirements are too tight. > > I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. > > The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From scott.brim at gmail.com Mon Mar 4 10:41:32 2013 From: scott.brim at gmail.com (Scott Brim) Date: Mon, 4 Mar 2013 13:41:32 -0500 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5134DDB5.70103@isi.edu> References: <5134DDB5.70103@isi.edu> Message-ID: On Mon, Mar 4, 2013 at 12:45 PM, Bob Braden wrote: > I hope that people of this E2E list are reading the current thread on the > IETF list about choosing a > new Transport Area director who is/is not an expert in congestion control. > Some of you have > been around long enough to recall the congestion collapse of the > (NSF-sponsored) Internet, before > Van J showed us how to not be stupid when he defined the basic TCP CC > mechanism. They/we > invented the concept of "TCP Friendly" to try to head off a race to the > bottom while providing > an easy-to-understand criterion for acceptable CC. > > It seems like an interesting question for research to determine whether > widespread adoption > of some future transport protocol with an ill-advised or inadequate CC > mechanism could still > cause congestion collapse of large areas of the Internet,or only local > patches. Or has > that been researched and I missed it? > > Congestion control seems a bit like riding a unicycle -- even after you > learn how to do it, > you have to pay attention every moment or you are in danger of falling off. > > Bob Braden Yup :-). I was astounded at the "why is congestion control important" question. I'm holding back, not being an expert. I hope he gets 30+ answers ... but so far it seems to have shut everyone up. When I was for-profit I was told "nobody ever made money on the control plane". That could be the problem. Scott From braden at isi.edu Mon Mar 4 10:50:11 2013 From: braden at isi.edu (Bob Braden) Date: Mon, 04 Mar 2013 10:50:11 -0800 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> Message-ID: <5134ECE3.7060701@isi.edu> Scott wrote: When I was for-profit I was told "nobody ever made money on the control plane". That could be the problem. Scott Ah, but if CC gets screwed, everybody loses money. (Is there a Tragedy of the Commons lurking here?). Nobody makes money on a fire department, either. Bob From anoop at alumni.duke.edu Mon Mar 4 11:02:07 2013 From: anoop at alumni.duke.edu (Anoop Ghanwani) Date: Mon, 4 Mar 2013 11:02:07 -0800 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5134DDB5.70103@isi.edu> References: <5134DDB5.70103@isi.edu> Message-ID: On Mon, Mar 4, 2013 at 9:45 AM, Bob Braden wrote: > Congestion control seems a bit like riding a unicycle -- even after you > learn how to do it, > you have to pay attention every moment or you are in danger of falling off. I think that is true of almost anything in life. :) Anoop From rogerj at gmail.com Mon Mar 4 12:14:35 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Mon, 4 Mar 2013 21:14:35 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> Message-ID: hehe, I'm here to, lurking around trying to learn more of the deeper and tricky details on why and how Internet work;) With that question I was hoping for someone to teach the rest of us on the topic, give us some more than just "Ouch. Because without it (as we learned the hard way in the late 1980s) the Internet may collapse and provide essentially no service." That answer in itself might be news to lots of people on the subject, but as said, I was hoping for some more :-) among many other thing I follow bufferbloat, and CoDel is quite interesting. I'm still running a very early version (fq_codel kernel) in production because it gave me an interesting "rate-limiting" on throughput when I tweaked some of the values. --- Roger J --- On Mon, Mar 4, 2013 at 7:41 PM, Scott Brim wrote: > On Mon, Mar 4, 2013 at 12:45 PM, Bob Braden wrote: >> I hope that people of this E2E list are reading the current thread on the >> IETF list about choosing a >> new Transport Area director who is/is not an expert in congestion control. >> Some of you have >> been around long enough to recall the congestion collapse of the >> (NSF-sponsored) Internet, before >> Van J showed us how to not be stupid when he defined the basic TCP CC >> mechanism. They/we >> invented the concept of "TCP Friendly" to try to head off a race to the >> bottom while providing >> an easy-to-understand criterion for acceptable CC. >> >> It seems like an interesting question for research to determine whether >> widespread adoption >> of some future transport protocol with an ill-advised or inadequate CC >> mechanism could still >> cause congestion collapse of large areas of the Internet,or only local >> patches. Or has >> that been researched and I missed it? >> >> Congestion control seems a bit like riding a unicycle -- even after you >> learn how to do it, >> you have to pay attention every moment or you are in danger of falling off. >> >> Bob Braden > > Yup :-). I was astounded at the "why is congestion control important" > question. I'm holding back, not being an expert. I hope he gets 30+ > answers ... but so far it seems to have shut everyone up. > > When I was for-profit I was told "nobody ever made money on the > control plane". That could be the problem. > > Scott -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From michael.scharf at alcatel-lucent.com Mon Mar 4 14:07:44 2013 From: michael.scharf at alcatel-lucent.com (Scharf, Michael (Michael)) Date: Mon, 4 Mar 2013 23:07:44 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu>, Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> There has been some interesting research on whether a transport protocol could work without any congestion control. One reference is: B. Raghavan and A. Snoeren, "Decongestion Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. Some time ago, I wondered myself whether an Internet without congestion control could work, or not. My (somehow short) insight can be found on page 67 of: http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Section 4.1 and Section 4.2 of that document have been written to give a decent introduction into congestion control, complementing Michael Welzl's excellent book on the same topic Michael ________________________________________ Von: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] im Auftrag von Scott Brim [scott.brim at gmail.com] Gesendet: Montag, 4. M?rz 2013 19:41 An: braden at ISI.EDU Cc: Joel M. Halpern; end2end-interest at postel.org; john at jlc.net Betreff: Re: [e2e] Congestion control as a hot topic in IETF On Mon, Mar 4, 2013 at 12:45 PM, Bob Braden wrote: > It seems like an interesting question for research to determine whether > widespread adoption > of some future transport protocol with an ill-advised or inadequate CC > mechanism could still > cause congestion collapse of large areas of the Internet,or only local > patches. Or has > that been researched and I missed it? > > Congestion control seems a bit like riding a unicycle -- even after you > learn how to do it, > you have to pay attention every moment or you are in danger of falling off. > > Bob Braden Yup :-). I was astounded at the "why is congestion control important" question. I'm holding back, not being an expert. I hope he gets 30+ answers ... but so far it seems to have shut everyone up. When I was for-profit I was told "nobody ever made money on the control plane". That could be the problem. Scott From dhc2 at dcrocker.net Mon Mar 4 14:24:46 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Mon, 04 Mar 2013 14:24:46 -0800 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5134DDB5.70103@isi.edu> References: <5134DDB5.70103@isi.edu> Message-ID: <51351F2E.9050808@dcrocker.net> On 3/4/2013 9:45 AM, Bob Braden wrote: > It seems like an interesting question for research to determine > whether widespread adoption of some future transport protocol with an > ill-advised or inadequate CC mechanism could still cause congestion > collapse of large areas of the Internet,or only local patches. That seems a particularly counter-productive strawman to pursue. There is no community dismissal of the need for good CC mechanisms. There is no reduction in community review of proposals. There is no leverage to force the community to deploy bad CC mechanisms. Stray comments from stray individuals do not create a problem. Unless we let them distract us. So please don't start believing that we have any more danger of deploying bad mechanisms now than we've had for the last 40 years. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From detlef.bosau at web.de Mon Mar 4 22:01:41 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 05 Mar 2013 07:01:41 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5134DDB5.70103@isi.edu> References: <5134DDB5.70103@isi.edu> Message-ID: <51358A45.6010008@web.de> Am 04.03.2013 18:45, schrieb Bob Braden: > > Congestion control seems a bit like riding a unicycle -- even after > you learn how to do it, > you have to pay attention every moment or you are in danger of falling > off. > > Bob Braden It's perhaps a bit out of the scope of your thread. However: When congestion control is one of the fundamental mechanisms in the internet, we should employ mechanisms which are a bit more robust than riding a unicycle. And from what I've read here in the list and quite some private discussions, particularly on the buffer bloat issue, I'm not fully convinced that we really learned how to do it. At the moment, referring to a picture, we are mounting the unicycle, falling down, looking around where the unicycle is, mounting the unicycle again, falling down. In private discussions, I'm pointed to clean slate approaches, e.g. RINA, and actually, from what I see and what I'm told, in all of these discussions I see a mixture of science with personal interests, politics, bitterness and an astonishing lack of mutual respect. Sometimes I get the impression: The louder people speak, the less they have to say. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Mon Mar 4 22:39:23 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 05 Mar 2013 06:39:23 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51351F2E.9050808@dcrocker.net> References: <5134DDB5.70103@isi.edu> <51351F2E.9050808@dcrocker.net> Message-ID: I doubt anyone shipping any OS with a TCP (or any other significant transport) in is about to turn off congestion control - the folks that do tcp in linux/android, OSX/IOS, BSD, Windows etc are probably a bit beyond ietf unicycles or naive market and commons arguments these days - the details of engineering a protocol to work across 10Gbps multicore systems in data centers and on 2.5/3/4G cellular are important and complex enough that we've become irrelevant here:) [if you want to see where the hot topics are, the usual top conferences have a slew of papers n the last 2-3 years on even cleverer tcp hacks to solve incast and tight delay bounds requirements, as well as some ok work on bufferbloat (whether it happens much or not, and various ways to fix it ) that said, anyone wanting to witness congestion collapse should please only try the experiment in their own back yard and not release "working code" in the wild in a hurry, as they'll find the consensus will be very rough on them back in the day, (why even more than 10 years after the dreaded congestion collapse and its repair by congestion control but still in the last millenium) I remember ISPs disconnecting users who ran tcp-unfriendly flows... that was the micro-ecnomic version of the rationale for disconnecting users who run p2p and mess with the ISPs traffic engineering and peering arrangements... you wouldn't get in an airplane today that did not have feedback controllers stabilising its flight autonomically - why would you drive on the interweb without such technological safety measures? maybe no-one ever made money from this stuff, but an awful lot of people would lose their shirts if we stopped using it. In missive <51351F2E.9050808 at dcrocker.net>, Dave Crocker typed: >> >>On 3/4/2013 9:45 AM, Bob Braden wrote: >>> It seems like an interesting question for research to determine >>> whether widespread adoption of some future transport protocol with an >>> ill-advised or inadequate CC mechanism could still cause congestion >>> collapse of large areas of the Internet,or only local patches. >> >> >>That seems a particularly counter-productive strawman to pursue. >> >>There is no community dismissal of the need for good CC mechanisms. >>There is no reduction in community review of proposals. There is no >>leverage to force the community to deploy bad CC mechanisms. >> >>Stray comments from stray individuals do not create a problem. Unless >>we let them distract us. >> >>So please don't start believing that we have any more danger of >>deploying bad mechanisms now than we've had for the last 40 years. >> >>d/ >>-- >> Dave Crocker >> Brandenburg InternetWorking >> bbiw.net cheers jon From detlef.bosau at web.de Mon Mar 4 23:48:49 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 05 Mar 2013 08:48:49 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: <5135A361.1070702@web.de> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): > There has been some interesting research on whether a transport protocol could work without any congestion control. One reference is: B. Raghavan and A. Snoeren, "Decongestion Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. > I remember that you, some years ago, asked whether networking can be done without flow control. O.k. I just asked my provider to give me some additional space for my mailbox and claim the following: Congestion control is necessary, because when God created cabling and fibre, he forgot to give them a mouth to talk. So, we actually don't know how much data can reside, if transient, on the line. And NB: This is anything else but a trivial question. Particularly on mobile networks, we have only little knowledge about the transient channel capacity (you might remember some personal discussions between us two about 8, 9 years ago), if at all. The same holds true for shared networks e.g. Ethernet, particularly the good old yellow garden hose. So, actually, the only way to assess whether the amount of data send to a "media" stays within "acceptable limits" is, simply spoken, trial and error. Either it fits - or it is dropped. Depending on the link technology in use, this situation may vary. However, the fundamental problem is generic. While receivers can talk, perhaps God spent more time in creating them, flow control is easier. Congestion control is achieved indirectly and - to make things worse - it is strongly intertwined with scheduling. Particularly, VJCC attempts to extend TCP's "self clocking" into a "self scheduling" which is cumbersome because self scheduling requires sufficient space for the data to be interleaved to be put. I strongly suspect that the latter is a sufficient reason for what we often call "buffer bloat". Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From lars at netapp.com Mon Mar 4 23:52:56 2013 From: lars at netapp.com (Eggert, Lars) Date: Tue, 5 Mar 2013 07:52:56 +0000 Subject: [e2e] congestion control? - (was Re: Appointment of a Transport Area Director) In-Reply-To: <3061.1362422679@sandelman.ca> References: <3061.1362422679@sandelman.ca> Message-ID: On Mar 4, 2013, at 19:44, Michael Richardson wrote: > The Transport Area has all of the groups that deal with transport > protocols that need to do congestion control. Further, the (current) > split of work means that all of the groups that need congestion > oversight would be cared for by the position that is currently becoming > empty as Wes leaves. Also, other areas frequently build protocols that need review from a congestion control perspective (do they back of under loss, can they even detect loss, etc.) Inside the area, there is typically enough CC clue applied by the TSV community as a whole. It's outside the area where the TSV AD as a person gets involved a lot. Lars From Jon.Crowcroft at cl.cam.ac.uk Tue Mar 5 01:23:25 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 05 Mar 2013 09:23:25 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5135A361.1070702@web.de> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> Message-ID: actually lost of links have a clock but that's neither here nor there what you don't know is the other traffic demand on the net in a non work-conserving, stat muxed world, so you have to elicit feedback on what is nicely called sometimes the _shadow price_ of your traffic. the work of frank kelly is required reading round here in that regard: http://www.statslab.cam.ac.uk/~frank/PAPERS/ the optimisation frameworks have also been aired by a few other groups (caltech etc) and the math is pretty persusasive... the details of how you build protocols that do this a la KK ramakrishnan and raj jain et al's work at DEC, then Van's work on TCP are just that - protocol details - and surely newerer things like ECN (re-ecn, congestion exposure etc) and codel/bql etc can improve things closer to optimal if you want a circuit setup/open loop control, you need to invoke a lot of other mechanism as well (fancy switch schedulers, admission control, policers, pricing etc) to get to the same level of deployability, which are explicitly more complex system wide so have largely fallen by the wayside in many networks.... nature abhors a circuit, if you ask me.... ad the corrolary is that you better have a congestion avoidance and control scheme or live with long periods of massive packet loss and little progress (or: if god had wanted us to use connection oriented networks, it would have been listed in the commandments) In missive <5135A361.1070702 at web.de>, Detlef Bosau typed: >>Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>> There has been some interesting research on whether a transport protocol could work without any congestion control. One reference is: B. Raghavan and A. Snoeren, "Decongestion Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >>> >>I remember that you, some years ago, asked whether networking can be >>done without flow control. >> >>O.k. I just asked my provider to give me some additional space for my >>mailbox and claim the following: >> >>Congestion control is necessary, because when God created cabling and >>fibre, he forgot to give them a mouth to talk. >>So, we actually don't know how much data can reside, if transient, on >>the line. And NB: This is anything else but a trivial question. >>Particularly on mobile networks, we have only little knowledge about the >>transient channel capacity (you might remember some personal discussions >>between us two about 8, 9 years ago), if at all. The same holds true for >>shared networks e.g. Ethernet, particularly the good old yellow garden hose. >> >>So, actually, the only way to assess whether the amount of data send to >>a "media" stays within "acceptable limits" is, simply spoken, trial and >>error. >>Either it fits - or it is dropped. >> >>Depending on the link technology in use, this situation may vary. >>However, the fundamental problem is generic. >> >>While receivers can talk, perhaps God spent more time in creating them, >>flow control is easier. >> >>Congestion control is achieved indirectly and - to make things worse - >>it is strongly intertwined with scheduling. >> >>Particularly, VJCC attempts to extend TCP's "self clocking" into a "self >>scheduling" which is cumbersome because self scheduling requires >>sufficient space for the data to be interleaved to be put. I strongly >>suspect that the latter is a sufficient reason for what we often call >>"buffer bloat". >> >> >>Detlef >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From detlef.bosau at web.de Tue Mar 5 01:28:35 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 05 Mar 2013 10:28:35 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5134DDB5.70103@isi.edu> References: <5134DDB5.70103@isi.edu> Message-ID: <5135BAC3.1050001@web.de> Am 04.03.2013 18:45, schrieb Bob Braden: > I hope that people of this E2E list are reading the current thread on > the IETF list about choosing a > new Transport Area director who is/is not an expert in congestion > control. Some of you have > Perhaps, this question is annoying and may even sound inadequate. However: What has congestion control to do with transport? Or, in other words, should the IETF care for "TCP friendly DOS attacks" or for "TCP friendly ICMP storms"? We should agree what congestion control is all about: Proper management of network resources. So basically, I would locate congestion control mechanisms in the network layer or even lower. The more I think about it, the more I ask whether it was a good decision to locate congestion control first in the transport layer and second strictly on the communication endpoints. I'm expecting contradiction here, but I doubt these decisions. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From michael.scharf at alcatel-lucent.com Tue Mar 5 04:07:53 2013 From: michael.scharf at alcatel-lucent.com (Scharf, Michael (Michael)) Date: Tue, 5 Mar 2013 13:07:53 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5135A361.1070702@web.de> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> > Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): > > There has been some interesting research on whether a > transport protocol could work without any congestion control. > One reference is: B. Raghavan and A. Snoeren, "Decongestion > Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. > > > I remember that you, some years ago, asked whether networking > can be done without flow control. My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. Michael From l.wood at surrey.ac.uk Tue Mar 5 04:22:50 2013 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Tue, 5 Mar 2013 12:22:50 +0000 Subject: [e2e] congestion control? - (was Re: Appointment of a Transport Area Director) In-Reply-To: References: <5134EFEB.2090104@isi.edu> <20130305004135.34CCA1A5F4@ld9781.wdf.sap.corp>, Message-ID: <290E20B455C66743BE178C5C84F124081A49EEF285@EXMB01CMS.surrey.ac.uk> The problem with the congestion/interference and corruption problem is that error notification does not percolate up the stack. If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints, TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost... first hops benefit most. in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does. And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow. And to make the header checks pass with a chance of decoding the headers have to be coded better than the payloads - and this applies at each layer, recursively. um. But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums. And a paucity of available state to track and associate with flows. Lloyd Wood http://sat-net.com/L.Wood/ ________________________________________ From: ietf-bounces at ietf.org [ietf-bounces at ietf.org] On Behalf Of Dearlove, Christopher (UK) [Chris.Dearlove at baesystems.com] Sent: 05 March 2013 11:55 To: mrex at sap.com; braden at isi.edu Cc: ietf at ietf.org Subject: RE: congestion control? - (was Re: Appointment of a Transport Area Director) I've no idea about the example quoted, but I can see some of their motivation. TCP's assumptions (really simplified) that loss of packet = congestion => backoff aren't necessarily so in a wireless network, where packets can be lost without congestion. This means that TCP into, out of, or across, a MANET using TCP can be bad. It then tends to happen that the MANET people don't fully understand TCP, and the TCP people don't fully understand MANETs. I don't have a single good reference for what I say above, in particular have things got better (or worse) as TCP evolves, and therefore which references are still valid? But the obvious Google search (TCP MANET) throws up various discussions. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove at baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: braden at isi.edu Cc: ietf at ietf.org Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director) Bob Braden wrote: > On 3/4/2013 10:20 AM, Roger J?rgensen wrote: > > I'll ask a rather basic question and hope someone will answer in an > > educational way - Why is congestion control so important? And where > > does it apply? ... :-) > > Ouch. Because without it (as we learned the hard way in the late 1980s) \ > the Internet may collapse and provide essentially no service. It is PR like this one: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html That gets me worried about folks might try to "fix" the internet mostly due to the fact that they really haven't understood what is already there any why. -Martin ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From keshav at uwaterloo.ca Tue Mar 5 06:04:48 2013 From: keshav at uwaterloo.ca (Srinivasan Keshav) Date: Tue, 5 Mar 2013 14:04:48 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: To answer this question, I put together some slides for a presentation at the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size a shared resource (such as a link or a router) smaller than the sum of peak demands. This can result in transient or persistent overloads, reducing user-perceived performance. Transient overloads are easily relieved by a buffer, but persistent overload requires reductions of source loads, which is the role of congestion control. Lacking congestion control, or worse, with an inappropriate response to a performance problem (such as by increasing the load), shared network resources are always overloaded leading to delays, losses, and eventually collapse, where every packet that is sent is a retransmission and no source makes progress. A more detailed description can also be found in chapter 1 of my PhD thesis [2]. Incidentally, the distributed optimization approach that Jon mentioned is described beautifully in [3]. hope this helps, keshav [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published as UC Berkeley TR-654, September 1991 http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition methods for network utility maximization." Selected Areas in Communications, IEEE Journal on 24.8 (2006): 1439-1451. http://www.princeton.edu/~chiangm/decomptutorial.pdf From detlef.bosau at web.de Tue Mar 5 08:40:17 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 05 Mar 2013 17:40:17 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: <51361FF1.8050208@web.de> Am 05.03.2013 13:07, schrieb Scharf, Michael (Michael): >> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>> There has been some interesting research on whether a >> transport protocol could work without any congestion control. >> One reference is: B. Raghavan and A. Snoeren, "Decongestion >> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >> I remember that you, some years ago, asked whether networking >> can be done without flow control. > My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. > > Michael It's perhaps not the focus of this discussion, but you perhaps remember our private discussion years ago, where I started to make a difference between bandwidth and throughput, particularly as the "throughput delay product" is something completely different from the "bandwidth delay product". These are perhaps no central aspects of our discussion, however it somehow illustrates where some of the confusion may come from. And I made quite some turnarounds myself during the last years. Starting from mobile networks, as you may remember, ending up in the insight that VJCC does not really work with a single mobile wireless link (!!!!!!!!!!!!!!!) and that this does not change if we put 30 wired links in advance of the mobile one and 50 other behind - and then argue that VJCC will work end to end. No. Like in maths, one counterexample disproves a theorem. However, different from math, VJCC is not a theorem but a mechanism based upon quite some, if implicit, assumptions. So it may well be, and actually is the case, that these assumptions do not hold in some network so VJCC is not applicable and may lead to unwanted results. This is no way a disaster, it is some kind of collective learning. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From mattmathis at google.com Tue Mar 5 09:03:28 2013 From: mattmathis at google.com (Matt Mathis) Date: Tue, 5 Mar 2013 09:03:28 -0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: There is no disagreement as to the power and importance of statistical multiplexing and it's need for some e2e congestion control. It is just that the congestion control problem has be overly constrained. In particular I would place simpler requirements on the end systems (no wasted capacity at high load, so total goodput equals capacity) and then move some responsibility for the fairness/capacity allocation problem to the network. The "simple network, TCP friendly transport" paradigm does not work for "fair" capacity allocation at scale and for any useful definition of fair. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Tue, Mar 5, 2013 at 6:04 AM, Srinivasan Keshav wrote: > To answer this question, I put together some slides for a presentation at the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always size a shared resource (such as a link or a router) smaller than the sum of peak demands. This can result in transient or persistent overloads, reducing user-perceived performance. Transient overloads are easily relieved by a buffer, but persistent overload requires reductions of source loads, which is the role of congestion control. Lacking congestion control, or worse, with an inappropriate response to a performance problem (such as by increasing the load), shared network resources are always overloaded leading to delays, losses, and eventually collapse, where every packet that is sent is a retransmission and no source makes progress. A more detailed description can also be found in chapter 1 of my PhD thesis [2]. > > Incidentally, the distributed optimization approach that Jon mentioned is described beautifully in [3]. > > hope this helps, > keshav > > [1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf > > [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, published as UC Berkeley TR-654, September 1991 > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf > > [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition methods for network utility maximization." Selected Areas in Communications, IEEE Journal on 24.8 (2006): 1439-1451. > http://www.princeton.edu/~chiangm/decomptutorial.pdf > > From Jon.Crowcroft at cl.cam.ac.uk Tue Mar 5 23:20:43 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 06 Mar 2013 07:20:43 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51361FF1.8050208@web.de> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> Message-ID: congestion control does work on some single links if the link layer supports a congestion feedback mechanism - switched ethernet (for example) has a feedback mechanism and some people have used this in data center modifications and used it to push the later 2 feedback up (as well as back) to IP/TCP - ie trigger ECN from the layer 2 this could easily also be done with contention information in conventional and wireless ethernet on a single link and could be triggerd from a cellular base station too if you like but it isn't but it could be... given the impossibility (without precognition) of knowing who else is just about to send on a wireless link, and the bursty nature of human and software behaviour it seems that this would be a more useful direction to fix things in than other (more old fashioned and less efficient, c.f. keshav's message )approaches - In missive <51361FF1.8050208 at web.de>, Detlef Bosau typed: >>Am 05.03.2013 13:07, schrieb Scharf, Michael (Michael): >>>> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>>>> There has been some interesting research on whether a >>>> transport protocol could work without any congestion control. >>>> One reference is: B. Raghavan and A. Snoeren, "Decongestion >>>> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >>>> I remember that you, some years ago, asked whether networking >>>> can be done without flow control. >>> My comment is about network designs that typically assume erasure codes= >> and flow-based queueing/scheduling in all network nodes. Actually, it to= >>ok me a while to fully understand why this is no alternative to the way I= >>nternet congestion control works today. But, for what it is worth, I foun= >>d the overall idea intesting. >>> >>> Michael >> >>It's perhaps not the focus of this discussion, but you perhaps remember=20 >>our private discussion years ago, where I started to make a difference=20 >>between bandwidth and throughput, particularly as the "throughput delay=20 >>product" is something completely different from the "bandwidth delay=20 >>product". These are perhaps no central aspects of our discussion,=20 >>however it somehow illustrates where some of the confusion may come from. >> >> >>And I made quite some turnarounds myself during the last years. Starting=20 >>from mobile networks, as you may remember, ending up in the insight that=20 >>VJCC does not really work with a single mobile wireless link=20 >>(!!!!!!!!!!!!!!!) and that this does not change if we put 30 wired links=20 >>in advance of the mobile one and 50 other behind - and then argue that=20 >>VJCC will work end to end. >> >>No. Like in maths, one counterexample disproves a theorem. >> >>However, different from math, VJCC is not a theorem but a mechanism=20 >>based upon quite some, if implicit, assumptions. So it may well be, and=20 >>actually is the case, that these assumptions do not hold in some network=20 >>so VJCC is not applicable and may lead to unwanted results. >> >>This is no way a disaster, it is some kind of collective learning. >> >> >>--=20 >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra=DFe 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From vitacaishun at gmail.com Wed Mar 6 04:29:22 2013 From: vitacaishun at gmail.com (shun cai) Date: Wed, 6 Mar 2013 20:29:22 +0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: As discussed in chapter 1 of your PhD thesis, when network is congested, retransmission dominate the traffic and effective throughput diminshes rapidly, leading to a deteriorating situation. This can be illustrated in the well known figure with two turning points Knee and Cliff. I wonder, however, does the situation the same if rateless erasure code (say fountain codes) is used? As with erasure code, no ACK and retransmission is needed except when the whole file is completed. So even heavy loaded, the network is still busy with effective data packet, right? Although queueing delay will increase, I believe that the network throughput will not suffer the plunge as un-coded network. Kara 2013/3/5 Srinivasan Keshav > To answer this question, I put together some slides for a presentation at > the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we > always size a shared resource (such as a link or a router) smaller than the > sum of peak demands. This can result in transient or persistent overloads, > reducing user-perceived performance. Transient overloads are easily > relieved by a buffer, but persistent overload requires reductions of source > loads, which is the role of congestion control. Lacking congestion control, > or worse, with an inappropriate response to a performance problem (such as > by increasing the load), shared network resources are always overloaded > leading to delays, losses, and eventually collapse, where every packet that > is sent is a retransmission and no source makes progress. A more detailed > description can also be found in chapter 1 of my PhD thesis [2]. > > Incidentally, the distributed optimization approach that Jon mentioned is > described beautifully in [3]. > > hope this helps, > keshav > > [1] Congestion and Congestion Control, Presentation at IRTF ICCRG > Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf > > [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, > published as UC Berkeley TR-654, September 1991 > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf > > [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition > methods for network utility maximization." Selected Areas in > Communications, IEEE Journal on 24.8 (2006): 1439-1451. > http://www.princeton.edu/~chiangm/decomptutorial.pdf > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130306/3722f4e3/attachment-0001.html From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 6 05:43:56 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 06 Mar 2013 13:43:56 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: there's no free lunch - if the queue keeps being filled, you'll get increasing packet loss - to cover the loss, you'll need more redundency in your erasure coding - this will cost you more delay at source (in constructing more redundency) and more overhead in the net, which is a positive feedback loop, just like retransmitting a whole window into a congested queue/path - a "vicious cycle" as opposed to a virtuous one... so all that erasure codes buy you is delaying the point when you go over the clif In missive , shun cai typed: >>--f46d0444e84964e1a304d740bdcd >>Content-Type: text/plain; charset=ISO-8859-1 >> >>As discussed in chapter 1 of your PhD thesis, when network is congested, >>retransmission dominate the traffic and effective throughput diminshes >>rapidly, leading to a deteriorating situation. This can be illustrated in >>the well known figure with two turning points Knee and Cliff. >> >> >> I wonder, however, does the situation the same if rateless erasure >>code (say fountain codes) is used? As with erasure code, no ACK and >>retransmission is needed except when the whole file is completed. So even >>heavy loaded, the network is still busy with effective data packet, right? >>Although queueing delay will increase, I believe that the network >>throughput will not suffer the plunge as un-coded network. >> >> >> >>Kara >> >> >> >> >> >> >>2013/3/5 Srinivasan Keshav >> >>> To answer this question, I put together some slides for a presentation at >>> the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we >>> always size a shared resource (such as a link or a router) smaller than the >>> sum of peak demands. This can result in transient or persistent overloads, >>> reducing user-perceived performance. Transient overloads are easily >>> relieved by a buffer, but persistent overload requires reductions of source >>> loads, which is the role of congestion control. Lacking congestion control, >>> or worse, with an inappropriate response to a performance problem (such as >>> by increasing the load), shared network resources are always overloaded >>> leading to delays, losses, and eventually collapse, where every packet that >>> is sent is a retransmission and no source makes progress. A more detailed >>> description can also be found in chapter 1 of my PhD thesis [2]. >>> >>> Incidentally, the distributed optimization approach that Jon mentioned is >>> described beautifully in [3]. >>> >>> hope this helps, >>> keshav >>> >>> [1] Congestion and Congestion Control, Presentation at IRTF ICCRG >>> Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf >>> >>> [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, >>> published as UC Berkeley TR-654, September 1991 >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf >>> >>> [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition >>> methods for network utility maximization." Selected Areas in >>> Communications, IEEE Journal on 24.8 (2006): 1439-1451. >>> http://www.princeton.edu/~chiangm/decomptutorial.pdf >>> >>> >>> >> >>--f46d0444e84964e1a304d740bdcd >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>As discussed in chapter 1 of your PhD thesis,=A0 when network is congested,= >> retransmission dominate the traffic and effective throughput diminshes rap= >>idly, leading to a deteriorating situation. This can be illustrated in the = >>well known figure with two turning points Knee and Cliff.
>>>G6+AAAgAElEQVR4nOxdZ1xTydeOFfuqq7uL69rL7uqquy5WXFRELKiAWMDeUFEQUVERRVF6ryoq= >>IKxrowjSpKggSG9SBek9IQkhhYQkd94P82b+Q7CAFEXyfOAXbu69M3fy3DNnzjlzDqnP+0BI0H5= >>IRrKzIDaGJBJp5cqVNTU1AACSZJQ7C5KR7CxI+NodkIxkZ+G9fK2trZXwtQWEGAQCgUAgaP3tRy= >>7/NkYSPaZAIIAf0FMLRBAbB3gEP4iP4SfHrTUkfG0T0OByuVw+n99L+CoQCPh8PkEQfBHESCl2A= >>vpKIBDweDz4b3Nzc3NzM+I3n8+HfEWXtKtLEr5+GnB8ISn5fH5zczP8kQhM7n78Dj1xJOHDQkrx= >>eDxERz6fDwAgCAIxDw0OLjvhtTg18bFCQ9qZfO2SYeiZAAAAAOAQAxGINvO1JwJSkxDN9c3NzQK= >>BAA4CjUZjMBgEpg/gAwJPQ58J0SiBlkCtdKSTAICoqKi6ujoJX/8HGo2Wl5eXn59Po9EEAgGTyX= >>z79m1FRQWXyyXaoAz0UODCDypCAoGgtrY2Ojra2dnZy8vr3bt3DAaDx+NxudyKioq8vDwmk0kQB= >>IfDqa+vZ7FYUA3g8Xj5+fmxsbEFBQVMJpPBYBQVFZWWljY0NKBp6rMh4as4AAARERFbtmy5cOFC= >>QUEBl8t98uSJgYHBixcv2Gy22EriC/azK4DP8nw+Pz09/ezZs0eOHLly5YqRkZGBgYG5uXlcXBy= >>NRnvw4IGOjk5mZiYAoKSkxNXVNSwsjMViAQDKysqsrKz279+vrq7u5OTk4uJiaWlpaWn54sULXL= >>X9PEj4Kg4AgKen5+jRo/fs2VNcXJyWlnbq1CknJ6eysjIoHsD7gK79yBF08KsFUkYBAHV1dadOn= >>frzzz9dXFxqa2vz8vL09PR+++03KysrDodz9+7dJUuWvHjxAgBQVVXl5OT0+PHjpqYmNpvt5eWl= >>q6trY2OjoaGxatUqWVlZb2/ve/fuPX/+nMfj8Xg8CV87EwCAhISE5cuX79u3LyQkxMjIyMnJqbq= >>6GqlobDa7rq4OznRVVVVUKhWtJOh0ekVFRW1tbWNjI5RSLBarsrKSQqFwuVy0lIYrkq9TPCNDVW= >>ho6F9//bVp06aysjL4suXm5p4/f97R0ZHFYnl5eS1duvT58+cAAD6fX1VVVVdXRxBEUVHRvn37j= >>h8/XlRUlJ6efuDAgSVLlqSnp1OpVCqVCnXijnQP8pVMJkv4+v8AAJDJ5KNHj8rLy69fv37BggXB= >>wcFw9QAp+OLFiwMHDjg6Ot69e9fQ0NDa2jonJ0coFNbW1jo4OOjr6xsbG7u7u9fV1fH5fF9f3wM= >>HDty4cSMmJqaoqAgZfVpbLr8SwF41NTU5OjqOGTNmx44dVCoV2QdSU1OjoqIaGxu9vLzk5OSio6= >>MBANXV1f7+/ikpKQKBICEhQVZWdtGiRREREVlZWevWrfvtt98iIiLQ+rWDL6qEr+IAAFCp1OPHj= >>0+dOlVeXl5GRubKlSuVlZUEQUDd6/Hjx2PHjl28eLGXl9fjx481NTVv377NYrGioqJ2797t5ub2= >>33//7dmz5+XLl2VlZYcPH96xY8fTp0/t7e2dnZ1ra2uR9+Fr4yu+uudwOI6OjqNHj1ZXV6fRaIT= >>IIN3U1MRisbhcrru7u6ysbFRUFACgtLRUS0vL2tqayWS+ePFi0aJFsrKyMTExubm5W7ZsmT59+s= >>OHD6EagJtsPw8SvooDAPDu3btdu3Zt3LgxICDAwcFh8+bN7u7uVCqVIAihUBgQEPDnn38eOnSoq= >>KiosbHRwcHB1ta2qKjo2rVrGzduDA4OTkhIOH369L179169eqWmpmZmZpaXl+ft7W1kZJSVlfUZ= >>NsjuAb7YYrFYLi4uv/zyy/79+6ElC07ldDqdyWQKBAIvLy9FRcVXr14BAJqbm83Nzc3MzDgcTn5= >>+/vbt2/X19RsaGphMprW19fr161NTU6EfoeNakISv4gAAJCUlqaio6OnplZeX19fXGxkZrV279v= >>bt2zQaDQAQEhKydOnSCxcuUCiUxsZGZ2dnR0fH/Px8IyOjdevWPXz48M2bNyEhIenp6XFxcRoaG= >>hYWFtnZ2SkpKVFRUeXl5WhO/NrkKyFSXgEATU1N9+/fX7Bgwe7duysqKqA+QCaTb9++HR4ezuVy= >>fXx8Nm/eHB8fD9UkFxcXBwcHHo9XUVFx8OBBExOTpqYmDofj5OSkrq5eWFgI1dwOGgcIEV8pFIq= >>Er/8PAEBkZOTixYtVVVXT0tKamppcXV1/+umntWvXJiUlCYXCsLCw6dOna2hoFBcXl5eXX7hwwc= >>LCgkKh+Pv7q6qqenp6pqamPnjwoKqqKjc3d//+/RcvXszNzS0oKIiLiysvL29ubiYwj/zXA9wVw= >>ufzMzMztbS0ZGRkbG1tS0tLaTSav7+/mpra/fv3mUymq6vrokWLgoKChEJhUVHRoUOHzp8/39jY= >>mJOTs2HDBk1NTTKZXF1dffjwYRkZmeTkZEjr5ubmTrEPSPj6PwAAUlJSLl26ZGlpmZubS6fTfXx= >>8zp07Z2pqmpmZKRAIsrKyrl69evfuXQqFUlFR4eXlFRoayuFwKisr7e3tDQwMLC0tHR0dS0tLmU= >>xmaGiovr6+jY3Nf//9Fx0dTaPRkM3oa9MKcOcqFIfp6emHDx9WUlK6ePGiubm5tra2g4NDRUUFj= >>UYzNzeXk5Pz9PSsra319vZeuXLl8ePH3717Fx0draKioqGhER8fn56evm3btqVLlwYEBOCuWglf= >>OxlNTU319fX19fUcDofH49FoNAqFQiaTORwOQRBcLpdKpUI1rqmpiUqlNjY2QvJVVFS8fPkyMjI= >>yNzcXGs/ZbHZ8fHxoaGhKSgpUJ/BlzRd+zvcBiVjY1fz8/EePHp07d+7s2bOPHj2qqqoiCILJZL= >>5+/drX1zcjI4NCoSQmJvr4+ERGRlZVVRUXF4eEhDx9+jQ/P7+ysjIsLMzf3z8zMxOa8zo+q0j4+= >>h681yOADP4f+gz/JQgCuc7RCTD+A57zdWqu7wUyQlVUVFRWVsLAF7EICnz5iEx1YlFd+Equ412S= >>8LVzgMQSBBInOKFxNaCnsBaqB+ih4ISO/hVicS2Iu2IvMIEFf3VcvkZGRkr42gkQC7R771dI6ny= >>1Vi0x4EZTsadDXxEtdV+ipUDFz+8U+Srha0fR+pdAR3ASf+T8rxawq2J2/tYvHn5EjLUENggd7w= >>/ka319vYSvn4+P8LX1IqNTlh3dBriiR4RDxMUfWexxJHxtE74IAz4kKTt3EvyCENMHxPRvYcsVF= >>dJoCUwlaH3DjvTnG+Errtd3Pz/ErATEN8RX4qPMw0VsUVERtCGI6ayd25lvhK9oi5UQQ/c0LRAI= >>WCxWY2Njx4PneygAADwez8vLy8nJCe6s6rrx7/F8BQA0NDQkJSXBaL3ul2pNTU3Pnj3z8PCoqqr= >>q6aL08wAA4HK5BgYGGzduzM7OBqJ9b10xGt8CX7Oysk6fPv3o0SM2m02ItnF2WwdYLJaNjc3u3b= >>uzsrK+2kCWLgWUr66urjo6Om/fvgXYxsyuaKsH8xUOTUxMzOLFi3V1dSsrKwEAHQ8Cahe4XG5YW= >>Jirq2tJSUnPWvt3IoRCYVVV1bt371gsFtLHusLA3OP52tzcfP/+/QkTJqxYsSIpKan7XfNCoZDJ= >>ZFKp1KamJuKbWGB9HtCiE00yEr7+D8iAwmAw9PT0Bg0aNGfOnODgYB6PR3Q7X8UcsN3W9FcFJpN= >>Jo9HQqreLtLIexlc0ENAoCACoqalRVVUlkUiTJ0++c+cOVGG7kzQCgaCysvLt27eNjY3EVxnY2t= >>WAMjUwMNDJyamiooJo6art9LZ6GF/x3EwAgPj4eFlZWRKJNHbs2KtXr0LPcrf1BwDA4XD+/fdfm= >>Kygd4pYuN66dOnShg0bMjIyiK5c8vY8vuIaKpvNtrS0HDduHIlE6tOnz6ZNmzIzMyGPu6c/AAAW= >>i2Vqarpu3brU1NTuafRrA+SroaHh6tWr09LSJPbX/0FsILKystTV1SdPnjxy5Mhx48YtX74cWbW= >>6B5CvZmZmcFddt7X7VQHaXy9cuLBhwwa4tZBoGTnZuW31JL4SWIIxPp8fGRmppaWlqakpIyNz5M= >>iRS5cueXp6NjQ0dFtnIF9tbGy2bduWmpraO11ckK82NjaGhoZwA4LwfUlzO6utnsRXKF+RxaSoq= >>Cg+Pv7x48erV6++ceNGenr6mzdvmExmd2qQPB4vKSkpICCAQqH0Ns0VAsqOlJSU1NRU6GLsOqti= >>z+Mr0dJKIBQKX758qaCgcPv2bZiPreNJbz6jPwJRTkkCC75BaB0Qg04TiwvBbyIWudc6pge0zNK= >>FH8ebw0cDnibWf3Qy3kP8YGt86DjeSYl8FQccoOfPnysoKLi5ubHZbLHfo6uBzMBiwPVssd8S7R= >>iBp6EPAlHqanQynuFa7OZoUwp+PpqCAcZjoSjhdWuqvbfzxIeJ2PpMBoMB02g2NTVRKBSYfrT1C= >>HQiQE/nK0EQiK8sFovo9kDY5ubmysrK5OTkuLi4hISE2NjYhISEmpoa2I3q6ur4+Pjo6OiYmJjU= >>1FQqlcrn88lkcmpq6qtXr2JjY2NiYjIyMqDttr6+PikpKSYmJiYmJjY2FmbggscTExNfvnz54sW= >>LhIQEmCCIz+cXFxfHxcXFxMS8fPkyIyMDJmJpbGxMSUmBJ8fExMAYv+bmZjKZnJKS8urVq5iYmP= >>T0dCaTCYlVWVmZmJj46tWr+Pj4hISEgoKCwsLC5OTk+Pj4169fJ74P8PjLly9dXV3v3Lnz9OnTx= >>48fwx3w4eHhiYmJJSUl+ITTiZDwtaPgcDg+Pj7btm1TVFRcv379pk2b9uzZExERAXcwR0ZGHjhw= >>YNOmTRs3btTV1U1LSxMIBHFxcdra2ioqKioqKsrKypcvXy4qKmpqagoKCtqzZ4+KioqSktLevXt= >>fvnzJ4/EAAC9fvty7d6+ysvLGjRuPHj2alpYmFAo5HI63t7eGhsbGjRs3b95sYmJSUlICACgoKD= >>hx4oSqqqqKisqWLVtgCkEGg+Hu7q6mprZu3bpVq1apqqrevXuXTCYXFBRcunRpzZo1CgoKa9asW= >>bNmzdGjRzU1NVevXi0vL6+goLD6fVBQUFBUVJSTk5syZcrMmTMXLlz4559/jhkzZvz48UuXLlVS= >>UnJ1dYVzXaePtoSvnw9kA7a1tR01atTPP/+sqalpY2Nz8+bNnJwcmJ86IyPjxo0b9vb2tra2Xl5= >>eUPAUFBR4eHjY2dnZ2tra2Nj4+fnV1tZyOJz4+HgXFxd7e3tLS0sXF5c3b97ALdTZ2dk3btyws7= >>OztrZ2d3cvLS0VCAQ8Hg9mvrazs4M3gVmlqFTq/fv37ezsLCwsrK2tk5OTqVRqQkLClStX5s2bJ= >>yUl1bdvXykpqblz52pqampoaIwfP56EYejQocOHDx84cKCUlNSgQYMGfhgDBgwYOXLk5MmTJ0yY= >>MH78+AEDBkAr+MCBA3V0dGD6hU4fcwlfO9oBFotlaWk5atQoVVXV3NxcqCwiLxePx2tqaoI51Ju= >>ampB7HR3kcrnQYycUCtERLpfL4XBg5iKCIGBiDg6H09TUBG8C9Vd4c3hn2JnGxkYKhVJYWBgWFu= >>bl5eXp6enu7m5kZKSqqrps2TIxakL06dPnu++++/7770ePHj1y5Mgff/xxyZIlW7du3bJly9atW= >>7dt27alFTZv3qymprZ161Z9ff3r1687Ozvb29svWLAA3VBHRwfqG10x4BK+dqgD0Mc2d+5cd3d3= >>OH2jpQ9u1sFXS0SrNQ2Bxc20Pv7er3A0Njbm5ubGx8fb2dnp6+sfO3Zs9erVv/7667Rp0yZNmjR= >>y5EicoIMHD54xY8acOXPmzJkze/bs9evXGxoampubm5iYmJiY2Nvbh4aGZmdnZ2Vl5eTk5Ofn53= >>4YFRUVMG8zhUIxNTX99ddf+/fv37dv35MnT3aR10bC17YCNy3hHWAwGBYWFocPH87NzRW2THYCP= >>+PlkAjMGiVsmQpFzLQstuUfJ3pDQ0NWVhbMfxgYGHj//v2LFy+uXr160aJF48aNGzZs2KBBg4YN= >>GzZx4sTffvvtt99++/XXX2VkZNauXausrKyioqKrq3v//v1nz56Fh4eHh4enpKTU1NQwGAwmk9n= >>Y2AhzK3389XgvCgsL3dzcZGVlBw4cuGfPnrKyMok9SxzdzFeBQIAHg8MPNBrNz88vKioKtt4uCD= >>BAXkJyo+gzBKj1BgYGPnjwwMLCQllZGRJ0ypQpP/3008iRI6WkpIYOHbpkyZItW7aoqqoePXr0z= >>p07/v7+AQEBT548iYyMzM7OLisrKy0thboyNBog1eUzCApamZMpFIqBgcGwYcP+/vvv8PBwiT1L= >>HN3JV4Ig8BJq6CCPx6NQKHhcfRvvhstXeGc81Q8El8utrq7Ozs728PBQV1efNWuWtLT0999/P2D= >>AgL59+w4ePFhaWnrq1KkbN240NDS0tbWNiYkpLCwsKCioqKiApESatBj738u5z4ZQKGxoaKivrz= >>czMxs5cuSECRO8vb2FXRB4JOFrOwAnOChlCZHGKRQK3759Gx8fT6fT2xVMKKYDIAI1NTXR6fSSk= >>pKoqChPT089PT0lJaXp06f369cPCtGpU6euW7dOWVn52LFjd+7cCQgIyMzMbGxsbGpqEqM77rMQ= >>e5D2vl0fAQCAx+M9efLE29v73LlzI0eOHD9+vKenp0S+iqOb9QEc8Cfncrk1NTUuLi7Hjx/Pzs5= >>u7w3RB0gvCoWSnp7u4eFhZGR06NChv/766+effx48eDBcJ02dOvXo0aNXrlxxd3dPTU2Fyx1Ywo= >>5o6eUS6zCub3RFeC6cB4yNjVVVVffu3Qtj5Tw8PDq3FdSWhK/tBpxnWSxWRESEn5+fvr7+xo0bU= >>1JS2kgIXATy+fyGhobc3FwfHx9dXd1Vq1ZNmTJl2LBhQ4YMkZKSmjhx4ooVKxQVFTU0NDw8PAoL= >>C+HaCN0EDQJOU6KV+x5f5Il96DiAKF572bJlmzdvHjVq1IQJE9zd3aETuFOawNuS8LUdEIqCO4V= >>CYVxc3MmTJz09PS9evKikpATdTh/nK85UDocTGxvr5uYGL58wYcKgQYNIJNLo0aOXLVu2ZcsWPT= >>09b2/vnJyc0tLSmpoaNpuNZ2BFVBBieatbzwBES0HeRXyF8a+rVq06derUjBkzJk6cCPnaKfcXa= >>0vC1zYBkQCSpqGhwcTEZP/+/YmJifb29hoaGhkZGWKEIDBa4OppWVkZrPG5dOlSaWnpESNG9OvX= >>T1paevv27efOnXNycoqNjS0pKamvr29qamq9Hhd7wNZ0xPHeEzprNOBnyFdXV1c7O7tnz57BKcL= >>Dw0NizxJHd/IVeZXg3/j4eA0NDUdHx7q6utDQUB8fHyqVKhTZvPANTFAW8ng8Mpn8+vVrb2/vY8= >>eOzZw5c8CAAQMHDpw2bdry5ctVVFRcXV0LCwvZbHZTU1Onr987Hejthf/C/Fl1dXXv3r3bsGHD5= >>MmTJfrre9DN8hUZs4RC4Zs3b9zc3GBOl4aGBhaLhWZk6CbFxWpBQYGjo+OJEydWrlw5derUgQMH= >>Dho0aMaMGbt37/b09ExLS8vJycG1UoClXe9S9ebzICa5oSkXdru4uFhZWXnatGkeHh5d0XMJX9s= >>K3AYEtU8ajQaDWpBAhWzGg01LS0uDgoL2798vLS09aNCgvn37Tpw4cdWqVQYGBv7+/nAXOFowiS= >>3ku+IpOhG4fiwQCKqqquh0ekFBwYYNG6ZMmXL9+nXone7cRiV8bSuQUOHxeAwGA0pQoVDI5XJfv= >>37t7+9PJpMRm2Fwqr+//8GDBydNmtSvX7++ffvOnDlz+/btDx48KCsra2hogHowgb0JkPqtDVJd= >>8TgdhFC0jwM+L51Ot7CwcHJySkxMVFJS+vHHH83NzblcroSvLdD9+kBzc3Nubu7NmzdhsJ9AIGA= >>ymXZ2dhoaGpmZmVCmvnv3ztHRcceOHbNmzRowYMCQIUNkZGTOnTvn5+dXVFTE4XBwWyl08CIvF0= >>7Qr5avQmw7IeRrYmKivLz8xo0bg4KCVFRU+vXrd/LkSbhY7NymJXxtB4RCYVNT05MnT86ePfvmz= >>Rv4U8H93Bs3bkxLS6uvr4+NjT127BgMiRoyZMicOXMuXLgQExODdkGK2aGQq0z4AVvYV0hZXH+F= >>gxAQEDBjxgx5efmAgIDNmzf369fvxIkTEr6Ko5vlK0EQFArl33//DQkJaWhogFRjs9lWVlbr1q1= >>zdXU9d+6cnJzc0KFDBw0aNG7cuJ07dwYFBdXV1aGu4n1rYz+/Qr4SLe0DAICMjAwFBYVly5YFBg= >>Zu3ry5b9++Ojo6XbHFQMLXdkAoFMbGxl67dq2oqIgQebm4XK6dnd306dNnzpw5dOhQEok0bdq08= >>+fP+/n5ZWdnw7VXV3hBvyzEFoUsFsva2lpbWzssLExZWbl///7a2tpdscVAwtd2tMXn8589e+bg= >>4FBVVYWsTkVFRUePHoVe/vHjx+/cufPp06cwUx/aOPD1L/bbBTF7FnwbqVRqfX09rHc8cOBAbW1= >>tiXwVRzfzVSgUlpeX5+fnw5Uvl8uNjIzU1NScOHHid999t3DhQmtr69LSUmTnF2IRg13RpS8F3J= >>KF1G5kv1NWVu7bt++JEyfgyrJzm5bwta0QCoUweQn0qSYkJNja2q5YsaJ///5SUlK7du16/vw5l= >>UrFL0FM/Sb1AZQbAa4aKysrGxoaioqKoH1AV1dXIl/F0W18BQAUFhYGBgbC/FCRkZHr1q0bNmxY= >>//79f/vtt8WLF3t7e8PlMF5dTYhtaPn2+IrsWUKhMD8/X19f393dPS0tTVVVtX///hK+vgfdw1c= >>49d+7d8/JySk/Pz8wMHDlypX9+vUbMWKEkpKSh4eHtbV1aGgoXF4IW+Lbk6wEpr8i+0BMTIyCgs= >>KVK1cSEhKUlZUHDBigo6Mj0QfEAXWm58+fy8vL37x5E/K14xTB5SL8NzU19dy5c3fu3LGwsJg5c= >>yZcWllbW5eVldXU1Li5uQUFBcEcLUS3J+z4IoCDg5Jo02i0M2fOqKurh4aGqqurS0lJ6erqSvxb= >>4kB8Xbly5Y0bN9Ce944zBm2ogtqqq6vr7t27NTU1p06dKiUl9ffffzs6OtJoNABARUXF2bNnHz9= >>+zOFwvklp2hr41AG3slEoFC0tLXl5+bi4uFu3bv300087duyA5Xo6t+kez1eCIOLi4g4fPhwaGs= >>rlcsUqSX82kA5aWlp6+/ZtBQWFH3/8cfjw4X369FFUVHz+/DnKbVZUVKSjo/PgwQPI12/MFPBe4= >>Bo5HITCwsJdu3adPn2aQqEkJCRMmjRp8uTJT58+RaaSzkKP5yubzfb09Lx8+XJJSQkhypzfwfUN= >>ol1NTY2RkdHEiRP79+9PIpEGDRq0bdu26Oho5P0nCKKhoSEmJgYauXAt4psHrsKyWKy4uDhYLC4= >>+Ph5u6XFzcyPel120I+jxfKXRaPr6+np6etCGj6KqO3JboSgO68aNG5MmTerbty8MBjh48GBubi= >>4yAoiZHr9VU0Br4KvJ1vvFExISpk6dOnr0aE9PT0LCVxwAACaTeevWratXr0JDvRDbzPTZt4U3o= >>VAohw4dgpJ12LBh+/fvz8vLA1gEIAx7bW5uZjKZHA7nGzYItAZiKvzb1NSUl5dXXV2N+DpixAi4= >>xaBb+SoUZY7+CMQsOPi1QswLgr4SOy7WHP5tW3rPZDJdXFyMjIxKSkrQ5W3nK66HIcLB49HR0cu= >>XL+/Xrx+JRFq8eHFERASuBkCmEgRBo9ECAgLS0tJgPGiv0l/R9JKRkaGtrR0eHg4AiIuLmzRp0n= >>ffffcF5KtAIOBhaG5uRh+QpOHxePhGEfTa4YH3+FyJTkCsEn4Abek9lUo1MDA4ffp0aWkpgZmi2= >>vj86Hzo6+fz+TAqnkwmnzt37ocffiCRSBMnTnRwcIBjhF8If6qysrLTp0/7+PigUnW9Qb4KsexM= >>AABfX98lS5b4+fkBAHJzc+Xl5b///nt3d3dhZ6d4+bQ+UF9ff+PGDWNjYysrq3PnzhkbG5uZmV2= >>5cuX58+cVFRUhISEpKSko1Bz9xX9+IeZGF4iynkOWE60seUR7OAcAqKur271796FDhyoqKpA+0K= >>4hwF8klGolKioKlqEjkUg7d+6EyvF7O1BaWqqnpwftWaArS099VcBlEADAx8dnyZIl/v7+AAAOh= >>3Pt2rXvvvtOS0sLjlsnDsin5Wt4ePjatWtPnTp1/vx5aWlpVVXVa9euLV26dM+ePc+ePTt37ty/= >>//6L7zQXirRvvJeQ0PAnR/MmZDPuhhablNvS+7q6uj179hw5cgRV0mnvEKAXBoVTUSgUfX390aN= >>H9+vXb/bs2Q8fPvzQViQAQHFx8alTpx49eoT7t9rbh54FsdkSAPD06dPVq1cHBgZCfcnR0XHIkC= >>GLFy9OTk7uPr4CABgMxuXLl3fu3Jmdnf3s2bPff//94sWL7969O3PmzIYNGwICAgwMDDw8PCgUC= >>sweBQCAdETGHaQtEATBZDIbGhoQL3EGtFaF29h7Mpm8f//+w4cPQ/kKj7drgISilZNQtNvTx8dn= >>8uTJJBJp2bJlAQEBHymQBACoqqpydXWNjo7mcDhtb7RHAxcu8EhVVZWHh0dycjJBEDwez9bWdsi= >>QIbKysikpKd3K14aGBnt7++vXrzc2NoaGhv7+++8GBgZVVVW3b98+ceJEZGTkqVOnjh496u3t/f= >>Tp0/T0dLgHv7a2Njg4GBaTCAoKqqqqgvvvnj17FhYWVllZCYUrlUotLy9ns9nNzc3V1dW1tbVoM= >>1Pb9de6urq9e/cifaC9Kx5cz4bvW1lZ2aFDh/r16zdmzBhnZ2foVPxQfwAALBYrLy+vtxXfwidD= >>qPLBnOAEQfD5fBsbm0GDBi1dujQpKalb9YGmpqaSkhJYRDgkJGTBggXm5uZUKrnPbZ0AACAASUR= >>BVLW0tDQ1NTUrK0tTU3POnDmmpqYeHh66urqBgYEsFiswMFBeXn779u2nTp1SUVF58OBBTEzMtW= >>vX7t69e+fOHTMzs7y8PB6P9/DhQ0NDw8LCQgqF4uLicvPmzdraWtStNvYeyVfo/RN77z8JpLPCC= >>7lcrpeX18yZM7///vsjR47k5OQQoti5D92z9VzRGyDEjK8CUdQLyidiZWU1ePDgZcuWdas+gM6A= >>CAkJWb16tYeHB3Q8AgDKy8uPHj2qoKDw/Pnz2NhYeXl5BwcHBoNx+/btCRMmKCoq+vr6ent7BwY= >>GXrhwQU1NLSEhITIyUlFR8fbt2wwGw8TEZOXKlenp6dXV1ceOHTt58iSsJIH02o88J9L0yWTyvn= >>37Dh48WFZWhoamvfYBgShUoL6+/vjx41JSUrKyslFRUTD7n1iCbDE0NzdDP3DvKcaJ1qboSGNjY= >>1RUVEFBAUEQfD7fzs5u0KBBy5Ytg+WP8ZV0B7n7afsrOi8kJGTt2rX37t1DCXNKS0vPnTtnampK= >>o9FSUlLk5eUdHR0ZDIabm9tvv/125swZeN/IyMj169efPHmyvLy8qKho3759xsbGVCrV1NR0xYo= >>VaWlpVVVVx44d09PTKy0thQWrUlNToYP+40OG1luHDx9G/oJ2DQqUB0gZyM/PX7du3ejRow0NDW= >>ENLSG20f69d6DT6c+fPy8qKuptfEXjDAB49erV9u3b0XrL2dl5+PDhy5YtS09PB1g1h27l65MnT= >>xQUFP79919ogiUIoqCg4OzZsw8ePAAApKSkrF692snJicVi3bx5c8mSJb6+vlAEhoeHq6mpwYjm= >>jIyMHTt2WFpa0un0q1evrly58s2bN4WFhXv27NHV1S0qKioqKvL19Q0NDa2rq2v9bGJ0BADU1tb= >>u27fv9OnT5eXlrU9oC5BwpdForq6u48ePX7BgwcuXL8XG90P6a2VlpYWFRWRkJMqg0XsUWaj6Q3= >>vWokWL/Pz8CIIQCoVBQUHz5s1btmwZ1F/F7D8dafHTfIUv07t37wwMDBYvXgz5CrXssLAwVVVVd= >>3d3Ho/37NmzJUuWGBsbl5eXW1paLly40NfXF/HAwcHBwsLi+fPnBgYGcnJyvr6+bDbbxcVFUVHR= >>39//8ePHK1eu1NbWLisr43A4dXV1FAoFpaD6eO/r6upOnDhhampKJpOJ9s848HyogURFRcnJyQ0= >>ePPjIkSP43T5SkFYoFObk5Njb28fHx8PVRi/hK673AwD8/f2XLl0K7a8AgLdv327btk1GRiYiIg= >>LNTsKWVvbPw6f5Clchr1690tHROXTo0IsXL6BWx+PxAgMDjx8//uzZMyaTGRgYuHfvXjs7u+TkZ= >>BcXl/379//3338oOVRqaqqFhYWJiYmWlpaxsXFhYaFAIEhLS7t8+bKdnZ2Tk5Ourq6bmxtM6YNs= >>W+/tj1DkPoUjRSaTtbW1r1y5Ul9fT7Q/WBvpwTU1NefPn//uu++mT59+7949+Iwfj/aCxruEhIR= >>Hjx7V1NQgEdL21nsu8GGBPtht27YFBwfD366kpGTnzp0///yzra0tlUpFfhxhe1zl78Wn+Qpnfx= >>qN9vbt2+LiYjqdjgz+ZDL53bt3dDqdy+VWVVXl5uaWl5fX19eXl5fDkg9QbYCMLysry87Ofvv2b= >>V1dHfxRuVwu3G4K1YC6ujoouYUf9m+15iuFQjl//rybmxvMSPXZwxEfHy8rKztkyJAjR44UFxcL= >>Wu4T/NA9BQJBVVVVXl4erL7ZnaXBvyzEfiMGgxEeHp6fn08QBOSrhobGpEmTrl+/3tDQALBCYl3= >>OVwGW1wm+PUi8w3/R0hjJRdxuj0MgCp0hROlUQUugpfqHHgm/GzxSVVUFq05+nOgfAryKx+N5eX= >>mNHz9+3LhxDx8+RI4u/JyPXN4pQbc9CIgVgpY1baBvCADw7t07DQ2N2bNno20X6KoONv0JvuIGN= >>ry7hGjHCGi5/wRJI1xrQUwisGT7iFg4UwmCgEWh2shXgUAQHx9vYGCQlZVFtG2xJTZlw5MrKyuP= >>HTs2ePBgGRkZmNad+LBMbT2Cn/eq9Fygx0R85fF4LBYLTjKQrzt37hw7duzVq1fFPCkdHKJP219= >>bA1/uoYz6+Goa/cWZKtZjMSrjnz/5wyOiC4VCPz8/PT293Nxc9NWHlEj8/vjz19fXu7m5ycnJyc= >>nJ3bx5k8FgtN3439zcXFRUlJeXh4pdtfHCHg1cXhAEAQnq6+sL0zQRBFFZWamnpzdt2jRDQ0NYh= >>ZlomzT5JNrEV5xGYjMgi8WiUqlI5hOtRGBr2YN/hX5j3HT6yR8engYvcXFx2b17d3Z2tpgS8qGr= >>Wj9UaGjowoULpaWlL168WF1d3XYzKgCgsbHx1q1bjo6O0J7QSyAmmKBtXlVVNTQ0lCAIgUBAo9H= >>Onz//008/nTlzBvosO4WsRBvtWUQrcYi+zcrKunfv3tu3b99L0zZCIBCgctSffDD0LVSdTU1NN2= >>zYAO3SYn345OMQBFFfX3/58uURI0ZMmjTp/v37KEynjWPHYDBMTU2NjY1hEkLiw2/LNwZEAyg4H= >>j9+/Pfff8P4V6FQyOfzzc3NhwwZsmnTpoyMDFzSdbDdNumvRKvIf6FIxY6KitLS0goJCYEKK55x= >>F6ejsJVwRfOyUChsaGjIycmpq6sDIh/0h55N2FLx4PP5FhYWKioq6enpeEMf4auYMpCdnb1ly5Z= >>+/fqtWrUqPT1dIGiHDwby1dLS0traGmYiEvYaLRb/laG/YOHChdBfAGFnZzdw4MApU6Y8efLkve= >>WePw9t1V9RG2jPNIfD4fF4z58/37Fjx61bt+Def7R4QnYA9AEJxdYoLCz09vbOyMjA9/F9RAcVi= >>ra98/l8a2trFRWVtLQ0dMJHjKA4nwAAbDbb29v7119/HT58+MWLF+vr64XtWcMCAFgsVkBAQGho= >>KEyW0XvIii/EAQCxsbEnT5589eoVOgj5OmLEiLt370KzJrq2O/gKAOByuQUFBbACeU5Ojq+v78u= >>XLxMTEw8ePHjx4sXk5OS3b9/W1NTAUJX6+vri4uJ3797l5+cXFxdD4yiNRisrK6PRaDwer66urq= >>ysDNZACw4O1tbW9vX1pdFoH2cMEthovIKCgo4dO4bXvvoIXwmM8QCA2tpaPT29oUOHysrKRkdHo= >>0CCtg9fc3MzhUJhMBhiJrBvG0LRGgM9b0NDQ3FxcWNjI4oNCg4OnjVr1qhRo7y8vKDdAF3bkabb= >>ut4iCCItLe3s2bPXrl2zt7c/fPjwzp077969m5OTc+DAAVlZWbhh5uLFi/B29+/fP3LkiK6urrW= >>1tbGxsb+/f2NjY0pKyuXLl//777+6ujp/f//Lly8nJSXR6XQ3N7d169Zdu3atoKAAOSM+IiPRMw= >>MAKioqrKys0FT+kUcV00kAAG/fvt2yZYuUlJSOjg5cMH2c6x8aQYDFhfUGyoqpXoKWZnX4b1VVl= >>Zqa2vfff//w4UPI105Rlj693oI/IYVCMTY2Xrhwoaur6+3bt2fNmqWkpPT69evy8vL9+/cvXLjw= >>zp077u7uioqKZ8+eLS4u9vDw+OOPPzZt2vTw4UN9ff1jx47l5uampqauX7/+1KlT1dXV//3337p= >>16x48eMBkMv38/Pbu3evt7Q29mm1/MAAAlUp1cnLC9YGPKK+4iZsgiNDQUFhT2M3NDYYrtFe+8v= >>l8uFLE7Sdtv7yHApGPEL3hLBYrPj4ebvmEJk46nb5r167vvvvO0dER6ordx1cAQHl5+YkTJ/744= >>w9PT08fH5/Zs2erq6sXFxdXVVXt27dvz5490Fu7d+/egwcPlpSUZGRkbNiwwdDQsLKy8vbt2xs3= >>bnzx4kVhYaGampqurm5dXV1ISMiGDRsePXrU3NwcERGhp6cXFxcHpxJhm7120Hrq6OjYFr4Solh= >>VOMRUKtXIyOjHH3/csGFDamoqWsC1a73FZrMjIyNfv36NUs31EhMshEAUq56cnHz48OGwsDAgcn= >>CSyeQdO3b069dPTU0NbV1u1/LgvWiTPUsoFMLtADDGMSIiwtDQMDg4mMlk1tbWnjlz5tq1axQKh= >>Uwma2lpwa0phYWFW7ZsMTMzY7PZDx8+lJeXDw0NLSgoUFNTO3nyJIPBiIqKUlZWhovH8PDwM2fO= >>wFh0AvNHtKX37eKrQFTgisvlPnjwYO7cufPmzfPy8oI7tNC1bedrQ0ODtbU1jOogsJqdbbm8RwM= >>fLgCAv7+/rKysr68vsoJTKJTdu3eTSKR58+bl5OSATtpl0FZ9AAAQERFhYmKSkpLy5s2bnJwcuB= >>00JyfnyJEjNjY2dDq9rKxs7969u3btqqioKC4uVlNTu3DhQmFh4Y0bNxQUFKKiooqLi7dv366lp= >>QXdIcuWLTtz5kxNTc2LFy9OnToVGhpaXFycl5dHo9Ha3vt28RV9W1paum3btuHDhx88eBAGegtE= >>e9DbPqyQrxYWFqampvX19ehl6A18xZUfAICvr6+srOyTJ0+QFZxKpe7atYtEIv3xxx/Qm9MpKtO= >>n+YoCGmDYtbq6uoaGxqFDhwICAthsdlJS0oEDBywsLOrq6tLS0vbt23f48OG8vDxYl3HFihUaGh= >>pr1qy5ePFiRUUFi8Xy9PRUUVHZuXOnqqqqtLT0X3/9lZqaWlRUdOnSpY0bNx4+fDgyMpLJZLZx1= >>mgXX9F8JBAI7t69O2nSpGHDhp0/fx4lccdlRhtbZzAY5ubmV65cgZGQ7VInejqQug9E8a8+Pj5I= >>vjY0NOjp6Q0cOBDxVYjhsxttR/wALK20ffv2rVu3zp8/f+vWrbm5uQwGIzc3t7i4mM1mk8nk5OT= >>kzMxMGo2Wn5+vqqqqqqp69OjRK1euwDRpUA338PDQ1tY2NjbW09MzMDAoKSkRCARxcXGnTp06e/= >>ZsQUFB25+qXXwViILhORyOvr6+lJTU5MmTPT09PzvOGvpj7e3tLSwsoJe89ygDuMsK6q+HDh0KD= >>Q1F+ivcFj916tTZs2fDX7879AFC5MCorKzU19fX0dFJTEyMiIhQV1eXl5dPTU1FNn+ipS8ARpgb= >>GxtDKiO9ENpx6+vrmUwmjUarr69HFaoaGhqoVCpuq2tL7ykUioODQ2ZmJvEpASkUrR3T0tLWrVs= >>3YMCAzZs3wx2wnwf4LGlpaWlpaTDfW+/hq9hjslistLS08vJyJEcBANHR0X/88cecOXPy8/NB+7= >>fWvRdtWm8BAEpLS83MzPbu3WtjY3Ps2LFVq1adO3eurKwMnibAAACA22NUVVWtrKxgeDnAInRa+= >>7eIllxvV+9by9cPnQxbp9Pp9vb2EyZMGDx48JkzZ+BW9ba3KAakreJZaj77bj0IiHnIRABaBmEB= >>AKKiombNmgVdsk1NTURn2E/atN4iCILP5zOZzJiYGFdXV0dHx5CQkLq6OhirCi2aeF43JpMZHR3= >>t4eGRlJQEs6ARHXZsfKj3FArF0tIyMjIS7U340Mnwq8zMTFVV1QEDBvz666+PHj3qeE0I3KDbe0= >>IK0ZPCX5xOp+fn5+PuSQDAy5cv//rrr4EDBx47dgzmzu8OvsJshELRShA63JAsFLbcgIDEjFi8N= >>tF5EWViva+rqzM0NHz06BGTySQ+FT8gEAiePn06b948KSmpAwcOwPmrIx1obm7Ozs7OyMhAtXt6= >>iT6Au3UgNXV0dF68eIFOAABkZWWpqqoOHjx4165dkGEdH5xP8BXJTpQODUl+ARZVKBZUhb5CJgx= >>0Zqfztb6+3sbG5sWLFyjn3IdaAQCQyeTz58+PGTNm3rx5T58+hZsKO9I6k8m8ffv2jRs3YBR9Lz= >>FmEe+zv65cuRLu4EcH6XS6iYnJhAkTUO2NLpevAixaSiDasgP7hL7iYxXSCMzMgV/VRTucAAA0G= >>u3ff/8tLCwEn/L4CQSCly9fbtiwYdmyZTdu3KDT6UTHxCG0D1y/fh3erfc4C4iW+bMgh9TV1Z8/= >>f05gOj2Xy/X29paVld26dWtsbKyYM/zz8Gl9AP1FIpbAdpwJMRCYvoueB2f5Z/dSrEu4Uk+lUt3= >>c3PLy8sS+xf8lRLZ9ExMTaWnpLVu2wP1eRGfw1dnZ2d7eHu0m7w36q5jZHwAQHBy8YcOGkJAQfN= >>XF4XCcnZ0nT548Y8aMW7duIbthR5r+tD0LoTUPWreNE1eMyp0CIWb5g8woKSm5evVqXFwc8k7hL= >>eLr95SUlG3bto0aNUpLS6u0tLTjHQMAsNnsp0+fPnnyBO5aFnbYP94jILYygfbXK1euoOyZEDAl= >>irS09NixY52dnWG90u7j69cA/H0gCILP58fHxx85cuTBgwcwYlpM2BMi3Z9KpcJ8y/PmzXv48GF= >>nVULk8/kUCoVCoaBInd7AVwghpn2h+FchVhagubk5NjZ2yZIl48aNc3Bw6JRysj2MrxA4KfPy8g= >>wMDGAuQZx8cLzgZ+i/kJWVHThwoJ6eHtT9O0v2wwUoztdOnE++ciCpIRAIeDwejMnE9dq6ujo1N= >>bXRo0efOHGisrKy4y32VL4SIsFJJpMdHByys7OJljxGNjWCIPh8/oMHDyZOnDh16tTg4GBc+nYE= >>kKbV1dU1NTW9KnIAAtfKKBRKcHAw2lWP7Fx0On3Pnj39+/dfuXIlDNrsXfoABM5X6C+Iiop6r00= >>NDlxVVdXRo0eHDBkiLy8PLQm4oeOzuwEAYLFYjx8/fvToUUNDQ+9RBvB1AvRoxsbG7tq1C8a/El= >>heAjabbWZmNmLEiPnz579+/ZrozvXW1wO0DId8NTc3h3nwCGw4EHW4XC7MDD5ixAhdXV1kKBWzD= >>X8GAAAMBsPa2trU1BRu7u0lIha3XRKieMKlS5cGBASIeWUJgoiIiJg0aZKMjEx8fHzHm+6pfEUa= >>Un19vbOzs1i8CxKxAICqqqrTp0+PHDly3rx50JHdWaxCfDUxMYHxWb1HeUUrKkLkL0D1twjMmgk= >>ASEtLmzp16ty5cyMjIztFB+t5fEVAfE1PTyfel6SDIIhnz54tWLBg0KBB2trasNQH0UleU2jTdX= >>R0tLS0pFAonXXbngI0yACAuLi43bt34/oA+grydfz48d7e3qjM4Gejx/MVxhNmZGTAI4gxQtGO7= >>VOnTg0bNmz27NkwqUfnts7hcKKiogICAhgMhrAz8vH2FIipBDQaLTw8HNYvwL8FAOTl5S1atOj7= >>7793cXHpFB2sZ/MV2gfevHkjJlYJghAKhc+ePfvzzz8HDBiACh51bgeEQmFDQ0N1dTWMDus9fEV= >>PilaZKFgPX3dCk5auru748eOdnJw67uns8XylUCjOzs5v3ryBRxBfoTEF5saaMmWKh4cH2lUsdu= >>ZnAxIU2l9x/3Pv0QrQwpfH4zGZTBTSKcQMOFwu18XFZcyYMZqamu/eveuN9gEEyFcbG5vo6GjcH= >>wu/yszMVFJSGjhwoKKiYnx8PD5/EZ0ULMbn8+l0Oira2PF4jh4BNJLISpOfn+/h4YHKleF8hbmg= >>paWllyxZggIOPxs9nq9kMtnIyAi6WHGiAAACAwOnTp06fPhwWD2mc5lKiOyL/v7+Pj4+DAaD6DX= >>rLTiAaD6B8S5KSkoo3oXAEvYLBIKkpCQlJaX58+cHBQVJ5CvFwsIiPDwcr+UJAGhubnZ2dh41at= >>ScOXP8/f3x3QedyFe4n/vatWsoK29vAL5UgEt+X1/fRYsWQfsrPI6iKwEA1dXVR44cmTBhgr29P= >>dTKPrvpHs9XMpl87dq1gIAAVLxUKNogqaGhMXTo0CNHjsB9Zp2uWUK+WlpampmZiWWR7sRWvlrg= >>Xhs/P7/Fixej/K+4HQBaaWC6fVhGvVfzlUKhXLly5fHjxyjkiiAIDofj5eU1efLkuXPnBgQEwBx= >>Ena5ZQr6amZmZmJhA/xbRO/iKNAHE17CwsK1bt4aHh+NOPiSD2Ww2LMSnoqKSl5fX2/lqZ2eXkp= >>IiwGqVZGVlqampjR079vTp06isZlfIVxaL9ejRo//++49Op/ce/xYe/wopW1paGhQUBEv44qchL= >>TYmJuavv/6aMWNGQECAQFSm5TPwLfDVwcEB5teGXGlsbLSzs5swYcLMmTMfP34M9drO3eOA0Nzc= >>XF1dXVVVhSqN9Qa+Eti+TqSqouNESwMClCCJiYlLliwZNmzYzZs3O+Ll6vF8Fcs/QBBEYWHhpk2= >>bSCSSnJxcamoqHDJYo7lzW0erY9BrdsYiIOEqEO3Pa2xshElDiJZRR3CIcnJylJSUhgwZYm5uDi= >>PrPw89nq9kMtnR0RH6twiC4PP5fn5+v/32m5SU1KlTp2DRZBiZ0fbCL21vHdYzKiwshPkgehVlC= >>azoX2Vlpbu7e0ZGRmvBCflaXV29d+/efv36KSsrFxUV9V75ivMVqgcnT54cNmzYr7/+GhAQgKbp= >>rvCUAgCYTObdu3fv3LkD09j0Hn0Af1IAQFRUlKqq6tOnTwG2iU0o2m1KEERjY6ODg8PPP//8+++= >>/p6WlASwjebsGrcfztb6+3snJCcYTCgSCoKCgP/74Y/DgwVpaWrDCPNKxOp1JQFQfBsW/9h6+ov= >>UWQRAAAB8fH1Sfm8D0VzS5NTc3v3jxYuHChb/88gtaVCBC9yK+UigUR0dHmLGxqqrq+PHjQ4cOn= >>TJlipeXF26R7QomAVE+zatXr9bU1IBeE68NgVtYnzx5snTpUhT/iiAUBSILBIKsrCwVFZXhw4fv= >>3LkzLy9P2BJtbPQb4SuMd3n+/PmSJUsGDRq0c+fOrKwsfCC6gklQH7h586aLiwuK1+4l8VlES75= >>mZmaeOnUqIiJCbOkpEO1KIgiCxWJZWFiMHDly3Lhx3t7eKLlOu4IMezxfyWSyiYnJs2fPampqrK= >>2tf/755x9//NHNzQ2GEyBLYRe1zuPx0tPT09PTYVq79kqLHgrcIwCPsFiszMzMiooKdAIesMYXl= >>W8PCgqaNWvWwIEDT58+DSPc2xsR2+P5WldXp6WlZWxsHB0draamNnToUHV19ZycHCHmgCG6LPOK= >>QCBABfTEAsS+YaBnxNdVsJg8OgcZvJE+RhBEeXn55s2bSSSSvLx8SkrKZwiUHslXfGVKJpP3799= >>/4MABV1fX33//ffjw4Tdv3oRGFqJVvpmu6Ay0v+ISpe0NfbxvYgfxf9vbShcNArwhXPVmZWWhzP= >>oENtXANFaQtWw229DQEC4w7t27B/fSEe2xA/ZgvgpFGRk0NTW3bt26Z8+eUaNGzZ07NyIiAj+zq= >>6Udg8GoqKiA2li75CuSLmJpyHDlDz+Cz5sfmi7wS/ALkR6Jv1RiN/mMFwC5r169eqWrq/vq1St8= >>0dm6IT6fHxYWNnXq1AEDBujo6MCUe7ipEX+13vuAPYyv+C8BDdG1tbX79u1bvnz533//PXz4cE1= >>NzZKSku4J7QMANDU1BQQEeHt7w/gBYTsNEciRgTMJ/bpiv5ywFd57Q6ii4LVuxD4IW2aVxNtte7= >>eFmD4ARPu5UX0YnH/4BwBAYWHh6tWrSSTSqlWroJUAt2fhz/XeB+x5fIV6kkC0mZhMJqurq48YM= >>WLkyJHLly+HgbDd0xkg2s9tZmYGazC1V0VGv5ZYepgPfUZHAAaxr+AH/LX5yEE4niiZUtu7jfcN= >>AODv7//PP/8EBgai/iCCor/wTFgjaMaMGWPGjLGwsGAwGOgcsWvfi57HV3z2hPrA9u3bSSTSDz/= >>8YGpqCp+/28BkMm1tbc3NzeEIEi0LMfQeBAUFycnJQb5+EmQyWVNTc9CgQUuXLoUqRLvw8uXLHs= >>NXCNwIQiaTIV+nTJly9+7dju9wbzsAAI2NjVC+ovjX9oLL5RYWFiYlJcXHx8fHxycmJiaJkJiYm= >>JqaWlBQkJWVlZycnJWVlZ6enpSUlJCQkNgS6JLU1NTk5OTExMS4uLjExMTk5OSMjIzCwsLMzEx4= >>YVJSUnZ2dnl5eW5uLjwzJycnPz8/NTUVv88ngfc2JSXF0tJyzpw55ubm8D4JCQnJycnwEeLj49G= >>/SUlJycnJr1+/Pnv27E8//TR48GA9Pb3k5OT09PSUlBR4/se7kZWVdfPmTVglpWfwVYiZSAAAVV= >>VVKioqJBJpzJgxhw4dcnR0dHBwcHR0hB+6FE5OTlZWVmvWrFm7dq25uTk82PZ2nZycnJ2dr127t= >>mfPHkVFxVWrVikqKioqKq5Zs0ZBQUFBQUFRUVFFReXw4cM7duxYt26durq6srIy/HbNmjWKiooK= >>CgqrV6+GV61evVpeXn7p0qXLly+Hd1u1atXKlStVVFS0tbXXrVu3cuXKNWvWyMrKysrK7ty5U0l= >>JCV4FS1KuXbsW3q2NWLVqFfwA+zl//vxx48bJyMigzsAHaX0mbGXZsmVjxozp27fv1KlTly1btm= >>jRIjk5uTVr1sCng5e/tz9r165dsmRJbW1tj+Er0bJ8UkBAwOzZs6E+8Ndffy1atGjhwoULFy5c1= >>C2QkZGZNWvWrFmzZGRk2tv0woULZWRkVqxYoaura21tbWdnZ2tra21tbWNjY2lpCcvS2tvb37x5= >>09nZ2cbGxtnZ2VYEGxsba2treI6tra2VlZWVlZWxsfHq1asPHjxoY2Njb29/5cqV3bt3nz171t7= >>e/tChQ/r6+lZWVvv37//111+nT58uJyd3+fJl+ILt379fT0/Pus1AraPPDg4O169ft7e3t7GxQd= >>2DH+ARKysrS0tLGxEcHR01NTVHjBhBIpFIJNJPP/109OhRS0tLOzs7eE+8CRzOzs4nTpzoefIV6= >>gPNzc0BAQE7d+7cuHHjjRs3YmNjExIS4uPjX79+ndAtgHMimvXgLNn2a+Pi4tLS0mpqajgcDsyf= >>yuFwmpqampqauFwul8ttwoD+hR/QmfAzh8NhMplFRUW1tbXwYGNjY1VVFZlMZjAYtbW1dDqdzWb= >>X1NSkp6cnJCTk5OQwGIzm5mYWi1VeXk6hUFCjnwTeLjxCJpPj4+OLiorQU7z3QdAHWFfn6NGjI0= >>eOJJFIR48eLS4uRnf7SE8AAOHh4T1Gf0XmGPgBhglXVVUVFxfznEmINwAAIABJREFUeLz2au4Sd= >>Baio6PV1dXR/i2ibevOyspKY2PjrVu3+vr6Qi62Bc+fP+8xfIVA9kKUHw8CkbjtpplvD8h4gm9T= >>+cjJn9cK0seIlvZXolU1jvcCVXFjsVgNDQ1tL8IKepw9C5EVl7WgZVo8CWXFfAEfOfPzmkDFiQh= >>R/CuqJ0+08syJtQhfJGhHR7IGP+EbtL8KROnexegLgeou9TagVxfX8j/uxfgQsT4OfMAhXxcvXu= >>zv70+0DM56b3PNzc0wcgCRvu1blXoYXwUta9YJMRe8QBTH/nk/wJeC8MPOqs8AvAkUXWjLmvCjH= >>k78PW9jK2Ief4IgYmJidHV1X79+DbDUdx+6oVAUBMPlcj9Z9bf1A/YkviLnFj4ireXrl+5m+0Cl= >>UhMTE1+9egVTJYh9iz8R/q3YmVB9Ly0tDQsLe/78OdyDKibnPq4YtH3c8JGHrTCZzPr6erw+DNJ= >>uP3QHsZ+yjU33ML6KjVSPBppM8/LyDh48qKam9vr1a/hcKAgGSkr0sIgKeIFp9KsLBILw8HB5ef= >>mTJ0/C0KdP6q8d6Tn6AJtgsVgcDgcP1umK36iH8fVbglCkWTY0NJiamhoZGZWWlsL5FNEUupdx6= >>wcitFCU1g4xEgBQXV2tpqamra1NpVKFog3uXfRuo7cFWqbu3LmTlJSEvu2i1M0Svn5JQCaxWCwr= >>KytTU9OamhoCi8yHOmhjYyOVSqXT6TDEls/ns9lsFovFZDJhfgoo0rhcLpPJLCgo2Lp164kTJ7q= >>6ni3+8gAAwsLC1qxZA/cbtkUf+GxI+PolAX9aBoNhZWV19epVWAEQ/dIMBuPevXsXLlwwMzMzMD= >>AIDw9vbGyMj4+3sLDw8/O7c+eOl5cXTAiSmZl5+vRpTU3NgwcPzpw5U0dHp6v3P+KrBWgfWLhwI= >>dzPjexcXaESSPj6xSAUpZNvbGy0tbU1MzOD+/XQJJuUlLRmzZpz5869ePFix44de/fuTU5Ovnjx= >>4vbt29PT02/evKmkpOTj48NkMp2dnaWlpffv329lZTV//nwdHR24NaWL9Ff8EYSi+Ndly5ZBvgp= >>F9kQJX78p8Pl86IRksVi2trampqZQvkKJm56efvr06Xnz5nl7e7NYLG1t7fnz5wcHBxsZGamoqE= >>RHR1+/fn369OmXLl3Kz8/X0tJasGBBcHBwaWnpzp07T548CePHu8dgAgDw8/NbunSpj48P7i/oo= >>rYkfP0yQMKJzWbb2NiYmJhUV1cDAPh8flBQ0J49e/7444/Zs2c/ePCATqcfOXJkxowZT548MTMz= >>k5OTu379uqmp6fTp0y9evBgXF7dhw4Z169a9efOmvr5+586durq6MD9SF5FVTM0AAMTHx+vr60P= >>7a6c3h0PC1y8MAEBDQ4OJicnFixdhHvD8/Pzdu3fPnTt327Ztc+fOtbKyKikp2bdv39KlS93d3V= >>VUVBQUFBITEz09PadOnXrmzJn8/PwLFy789ddfd+7cyc7OhiGzVVVVXae84neG70NjY2NJSQksQ= >>obOkdizvjVA+VpQUHD06FF1dfWUlJT6+npLS8spU6aoqKj4+flt2bJFXV3d2Nh4xYoVOjo6L168= >>OHv27D///GNkZKSrqztjxoz169cnJibGxMQoKirKyMgcOHBg/vz5CgoK4eHh0BraRXYl3PIqxPI= >>PIA2kO+wDfd6HTm9SAghkXq2vr3/48KGnp2d5eXl9ff2dO3e0tbWfPXtGp9NDQkIMDQ1PnTp16d= >>KlxMRELpf77t07MzMzfX19R0dHGKP95s2b2traW7duHT9+3MrK6sqVKwYGBtHR0TDFJzTQdkXnh= >>VhcUUFBwePHj/Pz8wnRpt/OUkXE2AhzbUj4+gWA1tEAABikDM2odDqdQqHweDzoYa+tra2oqKBS= >>qTCaSSgU0mi0qqoqOp1Op9PJZDK8lkKh1NXVsVgseJDNZnedkEP9R/bXoKCgDRs2oHya7d1w+xF= >>I+Pq1QCjaSy0QRZESouy+yIopFgoDhaXYQch7olWINNGVzi0CMz5A++uCBQtQ/gF0QsdbkfD1Kw= >>JymcJ4Jdwz9N44Sfy01t+icz4ZIdVZnUdvmpj9tROFuoSvXxFwPuErlfeeib7CqYlIibOzS9UAv= >>Ank2ggICFi9ejXiK3pnOt6QhK8SdALwqQAAkJ6ebmtrCxO9o/VWp2gjEr5K0FEg2yqiI4fDoVKp= >>MP4VSfpOMcF+jK8dvLUEvQRiyjHSYtFKkRCF8HZ60xJ/gQSfCaRDQxNyenp6cXExi8VCIS+SeEI= >>Jvi4ge1ZcXNy+fft27dp1+/btyspKtC7s9BYlfO0okLGztwH3Fzx58mTatGl9+vRZsGBBWFgYtA= >>dL5OvXiC4NMP1qgUfWQvvrtGnTSCTSL7/88vDhQ8hXiXz9ugD9qG/fvoXBUF+6O90HZMlC+TJCQ= >>0Pnzp1LIpEmTpzo4+MD4yIkfP26AABgMBghISFpaWmofsGX7lR3ANkHUPzDu3fvduzY0adPn8mT= >>J/v5+cFcZl3RtISvnw8AAI/HKyoqqqur69JNzF8hcJcvAKCmpkZTU1NKSkpOTu7Vq1ddl19Hwtf= >>PB/q1AJZ4v5fwFZUogiMQGxsrKys7ZMgQLS2tqqoqQpJ/4OsEj8erq6trbGwUiz750v3qcuCbzq= >>F9YPr06YMHDz579iyNRgMti591IiR8/XwAAJhMZkBAQGJiIp58rpfwFZevT58+nTlz5uDBg8+fP= >>0+n04XtzDLUdkj4+vmAW6/s7e3v3LkDRWzX/U5fG/DwK8TXIUOGGBoaSvj6lQIAQKfTr127Zm5u= >>Dqv39gamEq1S0AEA/Pz8Jk2a9PPPP9+8eRO6ZCX5Xb46QH3Az88vODiYwWD0Hv21NV8fPHjwxx9= >>/KCoqxsXFEVjGyE5vWsLXDkEgENDpdCaTiZjaS/QBAqtgyOFwrKyspk+fvmfPnqysLCaTibK6St= >>ZbXx2gPQt6enoJWXEuAgBycnKUlZW/++67M2fO+Pr63r17l0wmE12ze0zC1w5BICouLLaV6kv3q= >>2uBnhEas8LCwqZNm/bjjz96enqamppu3LixoKCAkMS7tAXdSRcAAJvNTk5OfvfuHZKvvUTEEqLc= >>/ACAR48ejR07Vlpa2tfX9/Lly3Jycm/fvhV26q5DhB7JV1xZJDCO4kb7bugGtGe5u7u/fPkSesz= >>bVTqi5wKOMHxSFotlb28/cuRIaWnpR48eGRkZrVixAibOkKy3WjASbm4mWm4nQvNUN1AW2rOuX7= >>8eGRmJitj3Bn0A3xmbl5e3bdu2fv36/fDDD/fv3zczM1u9enVubq4k3oUgsJwo+HQDVzzdyVTUL= >>p1Ov3XrVlRUlFj2qO7pwJeCUJTpo7m52cfH5/fffyeRSGPHjvX393/69Km+vn5ZWZkknpAg3qcJ= >>CESFuPAcON2mD7BYrIiIiMzMzK7bAfIVQijaq81gMK5cuTJq1KixY8cqKyunpKRQqdT09HQ2m01= >>I9AGiZVo8+C+LxUpKSqqtrSVaBrl1T3/4fD6ZTIbOWKJ3KAMERsSsrCwlJaU+ffqsWrXqxYsXcB= >>xQupquaLoH8xXqT+np6RcvXoyPj4dk7f7Khkgb6SXKAIHtLwgODp44cWLfvn21tLTIZDKPx8vLy= >>4uLi0PRFJ3edA/jKwSuEnh4eCgoKHh4eMBkud3MG6FQSKPRYDJAdKQb2v0iwB9NKBRyuVxvb++x= >>Y8dOmzbt2rVrd+/ezcrKunnzpqamZklJCTIgdC56Hl+FWHlYFot14cKF8ePHHzx4ENqou5OvAIC= >>6uroHDx6kpaXh8cvfGGXRE+HPBQB4+/bt9u3bBw8erKGh4eLismnTJj8/v8uXL0N7loSvBCHSUJ= >>Fu9ObNG2Vl5QEDBvz555+hoaE8Ho/osgy9rQEAKCgoMDQ0DA4O5nK532r8K66DwTBtaGm+devWj= >>z/+OGbMGCcnp3v37q1YseLff/81MjJavnx5Xl6exJ5FEAQhEOUdJwhCKBSGh4fLyMiQSKTx48ff= >>vXuXxWIRXZz0FAcAoLi42MjIKCQkpKmpCYhKpXVD090GFBYoEIEgCABARkbGhg0bhg4dun79+jd= >>v3jx58mTFihX379+/dOmSnJycxF/w/0DLT4Ig2Gz2rVu34Lb3UaNGGRsbw+Jp3dYZAEBhYeGFCx= >>dCQkK+1XgXXBlAH6hUqpWV1Q8//CAtLe3s7MzlcgMDA+Xl5X19fe/fv3/mzBlYOETij23hWamtr= >>T1+/PjAgQNJJBKJRFq/fn1ubi7RLdlPIQAAZDI5ODg4Jyen6yr6fXEgPQdKCgBAQkLCypUrpaSk= >>1q5dm5qaShBEVlaWi4tLZmZmZWVldnY2i8WS2AcIQrTYgpSNj49XV1cfO3aslJTUqFGjFBQUYmJ= >>i0Ca47uwPDNEiuvFV6U6grVrIR2BnZzdmzJjvv//+xo0bHA6HIAgOh9PQ0MDlcqEoEUryvUGgKY= >>nH4wUGBpqamqqrq8+aNUtfX//u3buZmZkoBWm3dQnfC/pNrrfQVliCIHg8np+f38KFCwcPHqysr= >>AzXVTDPTV1dHYfDgf923Xvbw/gKAflaVFSUl5dna2u7efPmhIQEFovFZrO7OTyKx+Pl5uZWVFTg= >>xqxvjK+QfJCFMTExmzZtGjx48D///BMaGgrriTY3Nz99+vT8+fPp6enQdNB1cZU9jK9CrBwFHJH= >>Xr18bGBhkZmZ2f2cAADQazc3NLTo6GprSvj2yQkC+VldXHzhwYMiQIdLS0o6OjtBBIxAI4uPjV6= >>1a9csvv8B6RnAzTBeFVvY8vkJJhoKFKRSKg4NDWloaOqHbOgMAyM3NPX36dEBAACzO9u2RFeqjz= >>c3NaWlpFhYWv/zyC4lEWrVqFRSlTU1NCQkJ2trakydPnjx5Ml7PSLLe+n8gyQpf+vr6ekdHx4yM= >>DAKrsNM9zi2CIEJDQ9euXfvvv//CfG/fnj2LIAi4tN2zZ88vv/zSv3//OXPmuLm50el0AACVSrW= >>3t9fS0jp27JiMjIyfnx/o4tRMPYyveIwpFLSvX78+d+5cRkZGFzlUPgTEVzk5OS8vLyjsvzH7AB= >>SuLBbrzJkzgwYNIpFI8+fP9/Lygn4ZgiAaGxvDw8MTExMDAgKUlZVDQkLwQGSJfUA8bROfz7ezs= >>9u8eXNqaipap3ebkIP+WCsrq9jYWBRF/s2osJCsVCrV399/8eLFffr0mT9/PowrYrPZ5eXljY2N= >>cLslQRAlJSUBAQHFxcVidpJOH4oexldcf4V/79y5s2vXruTkZKQ2deekDO04DAYDr/DbQ/mKqAZ= >>lAY/HKykpcXFxmT9//pgxY5SUlAICAmBuAR8fn+vXrxcXFyP3LL4ORp8lfCUIUflntPzMycm5ev= >>Uq1F8Ruocx8IdpamqCpYp7omTFZSGKJYKTWFJS0pEjR6ZOndq3b18lJaWXL182Nzez2ewHDx4oK= >>yubmprW1taiBQOXy83Ozq6qqhJiVRcl+uv/dmZC+4BAICgpKbGwsHjz5g0Kmu62zsAFcmxsbG5u= >>bg/NTyhsuVkDrVaTkpLU1dWHDBlCIpHmzJnj5+cHU7y/fv1648aN6urqr1+/hio7VBtSU1NPnDg= >>RFhYGRPW3UB3nzkUP4yt6d9GghIaG6ujopKenE93uDoX66/nz54ODg1GFiZ7CV7yfuOYNAEhJSV= >>FVVR06dKiUlNTff//t7e2NqmqlpaXdu3fv7du3eEUNAIC/v/8///zj6+srsQ+IA+eEQCB49OjRw= >>YMHYeXS7tQgYXPBwcHLly+/d+8eFDY9KP8APoxC0foVAFBaWnr06NGBAwdKSUlt3rw5ICAAkhU+= >>XVNTE/RpEdhaAgDg5+e3ePHiwMBAFFQp7Joojh7GV6FQCONfkXy1tLRUUVHB7QNEN654EhISNDQ= >>0Hj16BOVND+IrBD5QAICamhpDQ8MffviBRCItWLAgJCQEkjI+Ph7uyoKnNTc3oxRM8EX19fVdvH= >>gx9BfgwVyd3uEexlektsKx4PP55ubmmzZtSk5O/iL6K5lMdnJyioyMhPvxe5D+iiYoociDlZ6er= >>q2tPXbs2EGDBh06dCgiIgJarAICArZu3ers7Az5ihZk6HmhCmFiYgKdXvD+EvsrQWDiE9lfLSws= >>lJWVxeRr9wDGJcF4l6/Z/ooGDU3TQpFDWyiqF5KUlKSmpgadAjCSGJq0YCD2sWPH8DUlui1Sedl= >>sdnV1NYwt7NIR6GF8hUDDJBAILCwsNm3aBPXXL9UZXLJ+bWT9v/a+PK6pY30fq63cVmurfuu9t/= >>15tXVptdd6XaoioCJL0SKiVVC0iqCgKCCguOCO4IKgbLKDgEAgIEvY17DKosi+72uAJBBCICTnn= >>N8fczN3CEgRCcbW5w8+h+TkzHKeeeedd973HRwxqqBBkdDOShBETk6OmpratGnT5s2bp6amFhoa= >>CjwDi4qK9uzZs3fvXhAuP6pKCt8FgKjH7Qe+vhXge+LxeKhiLVbAEJsoTwBgn+JwOCkpKaqqqjN= >>mzPi///u/S5cu1dbWwlML6+vrXVxcMjIyoPaFxsahjOzp6amvr4d5Q0QXQveBr2+FlpaWhISEur= >>o6IFfEkK/Y8N1RVLL29/f7+PjIyspOnz59/vz5V65cqaurgyMQ3An8JHEk3hCVoPBRmZmZxsbGq= >>ampuIhD6j/wdYIAbzQuLk5NTS0oKAhYecTQPoAJQlMgcBwnCILFYnl6eq5evVpCQmLu3LmXL19u= >>aWmBjXJzc2tqakK5CwLWgWBGVSBoH9i8efOzZ8+gSvDBPvA/iA9fw8PDN23a5OPjA0KXxFC+4gI= >>RC9lDEERTU9OtW7dAaPH333//6NEjGo0GqBYeHi4nJ3fu3Lm2tjYoZdG/I6U14OvGjRsBXz/Ys4= >>QhPnyNjIyUkZHx9fUVaRDIBACnY/QCjKX6+noTE5Mvv/xy5syZK1assLOzA6srLpdLoVDU1NQuX= >>bpUX1+P5nnAkWUl6iIHNd2IiAh5efnw8HDwFkTXDx/4+lYoLi6+cOFCbGws1F/fOV9RzRJew7ws= >>TU1N5ubm8+fPl5CQUFFRSU5OZrFYYNLv6ekJCQkJDAyk0+lAtxFKngfpixYBHltaWuru7l5eXo7= >>eIIrWfeDrW2FgYKC6urqzsxM9cmPqq4ECruIxxOUKWAP6+vqcnZ2XLVsmISGxYMECFxcXDDFF8X= >>g8FosFFHFMsI84anOw4V5dQEXmcDhcLhdufYlotvnA17cFeNl8UToljR/YcADSgFmbwWB4eXn9+= >>OOPEhISX3/9tbm5eUNDA0EQbDabQqGQSKSenh7Qh+OJ9UXVWbjvANVWlMqT28APfJ04QAWYTKaQ= >>iecdilgMMY7iSEcxGAwnJ6dly5ZNmzZt0aJFt2/f7ujoAPVPTEyUk5PT1taG9gHIudeNPf4IF8T= >>Ozs78/Hxw7JZI9fgPfH0r5OTkmJubp6WlwbXwO1dh4ciBcq66uvratWvffvvtZ599pq6uTiaTOz= >>s7gXoQEhJy6NAhMzOz7OxsDoeDrqWghjOyCP7wzTyCIOLj4w8dOpSSkgJeyof9gmEQB74CUQT86= >>Dw9PeEO0Lslq9AETRBEdXX12bNn586dO3PmTE1NTdBRADU1NWfOnDl9+nRNTQ36cyG6jyxFSOuA= >>9qyQkBD8na+3RqoykBmg2eidQj8Z4/O3aY/48DUyMhLExwL7q0hf1euAdilc/YDr0tJSQ0PDuXP= >>nfvLJJ+rq6s+fP4c8xnGcTqcnJiYWFRUJ1RxdS41RLrr7EBISIi0tDfMPvDN9ANYb1h6sImHGYL= >>jUgHei5mWUmkLdAY0sE6i0+PA1IiIC+Gu/E/8soXkZ9j+O4zweLzk5ec+ePbNmzZo5c6aGhkZ+f= >>j7Yi+JwOO3t7TCFINzBGilWxmgISkqCIGJiYpSUlID9VYgwk4s/4CtsPyi+paUlKSmJTCbX1tbW= >>1NRkZ2e/fPmyu7sbVp2PnHgh1GzgEYJ+CGwfE3i74sBXgMzMTCMjo/j4+PEIpEmHkJEVigAOh5O= >>WlqaioiIhITFr1qxDhw7l5uaCHuvr6wsNDbWwsCgtLQVGLgLJVzf+ooUIXVNTY2Njk5OTI2pTyb= >>jkK7xOT08/duzYrVu3qqqq0tPTTUxMNDQ0qFQqutpA5Ss+fLUI7HNo2ROTRuLDVwaDUVZWBtfFU= >>ylfoSgBgOVyOJykpCQ1NbWZM2dKSkoePny4oKAAfMVisaKjo3fv3n3s2LHy8nIhPk2ArzxB1tuh= >>oaHOzs6+vj58uDox6V0xLv0Vqin5+fmHDx/29/cfGhrq6uq6cePG0qVLPT094UhFxzr4CYfDAX7= >>pOI4DssIxPXImGifEh69w7YLGG05N0egOMCyUTqeHhoaCYzBmzZp18OBB4A1IEASXy01LS9PV1T= >>UyMsrIyAAJvwAm9gqgYAJG3K6uLuivzRNZtvE/lq8o+SorK8+cOePq6spgMNrb283MzFatWgV2z= >>9lsdlZWVl5eXlVVVV1dHQhMq6mpSUxMDA0NzcjIAOOvqKgoJSUlJSUlMTGxvLwchJG8v3zt7Ox8= >>8eJFe3s7jN+aSpUAQ7KHEAQxODjo6em5du1aSUlJIFlfvHgBo64HBwepVOr9+/fBh/hoC7Xxlyv= >>E1xcvXlhZWeXl5eEIZ96xPkAQRFdX14MHDy5evBgZGeni4qKsrKyjowNiqV++fKmlpWVhYeHr6+= >>vl5VVZWfnq1Stzc/MHDx5YW1vr6OhkZma2tLScP39+3bp1hw4dunjx4s2bN1+8eAFOqhAyNYwNc= >>eArIEFSUpK2tnZUVBRQzYWknUiB6h4EQfB4PCqVumXLFgkJidmzZx84cCA3Nxewub+/n81m83i8= >>vr6+rq4uYMrARyQfeFO+QtYSBBEeHr5t2zYYz42KucnFuOQrjlCEyWTW1NQUFxefO3dux44dERE= >>RfD6fxWLdvXt3165dUVFR0dHR+vr6ZDLZ19d3+/btNjY2KSkpVlZWmZmZfX19lpaWixYtun//fk= >>FBgYGBgbGxcW1t7cDAQE9PD4fDGWffiQ9fw8LCNm/ejNoHpmy/AENOF2Kz2TExMTt37pSUlJw3b= >>56enl5+fj74qquri0wmh4SEMBgMqICNpOnEhhmsQGhoKPR/xRHPmMlu9PjsA6h5AvhDEAQRGBj4= >>66+/+vn58fn8zs5OLS0teXl5Nzc3a2trVVVVLy+vuLg4TU3NQ4cOWVpaWlpaZmVl4TgeGRkJXnB= >>/f//Nmze3bduWnp6em5sbEhKSn58Pz3Ece2iKCV9xHI+IiJCWlvbz8xOpfEXHAOwfviADLo/Hi4= >>2N/eWXXyQlJVeuXGlkZPTy5UvQPwMDA+BkLDMzs+bmZkKw3fqWNYRthIoimUzetGkTylcRzTPj0= >>gfgfklnZ2dMTEx2djaO49nZ2bKyshoaGiAhz+HDh6WlpR8/fhwWFubu7p6dnV1TUxMYGGhubv7b= >>b7/JyMjcvHmzs7MzIiJCRkbm6dOnLBbL0tJyy5YtVCq1qKgoNja2uLgYGgXfC75iGAb4CvJlYIj= >>X/eSWJSQOUQHZ1dUVFRW1c+fOGTNmfPHFF1euXKmurgYyD8OwvLw8DQ2NPXv2xMTEgENDJ5ev4J= >>ogiNjYWHV1dZCPCJ+otB4PxqUPwLIzMzMvXLhw48aN1tbWjo4OXV3dhQsXampq+vn5nTp1asuWL= >>WQyuby8nEQiPX/+nEql3rt3j0QiRUREqKur6+npNTU1RURErFu3ztHRMT8//9SpU+rq6mVlZRiG= >>sdlsmKL6PeJramqqnp5eTEwM6v8qOn0AfTJBEAwGw8XFZePGjdOnT//00081NTVhXDuO4z09Pfb= >>29r///ntycjLISIdiUioD9de6urpnz57V1NSgfH038hW+A7DANDQ0vH37NgjuAcJSWVk5IiIiIS= >>Hh1KlT169fd3V1vXfvHpVKJZFIampqt27dcnJyunTpUnR0NIfDoVAoP/300/Hjx8+ePaujoxMaG= >>grd2PDR5McYPSUO9gE6nV5cXNzR0QE1NlG4EIx890Bn9fHxWbdunYSExLx5844dO5aZmYkmC2Kx= >>WJGRkbGxseDMHBgdMOlM4vP5g4ODg4ODqNnhXe4XwEHJYDBevnzZ1NQE1pidnZ0UCoVMJoNPCgs= >>Lvby8yGRyRUVFX19feXk5mUyOiYnx9vZOTU0FQRcUCmXz5s2mpqYgLUp/fz+6H4aa3N8LvuICRZ= >>aP7AKKgq/wAsizgYEBCoWyZcuWadOmff755ydOnIAnjvD5fBqNRqPRQPpLIccGdPvm7WsFXxyXy= >>21ra+vp6YFfvTO+8pGQHVxgIYfRZKjBH5gA4YIME2zDwjOxMAzz9/dfs2aNm5sbNGNBEyzK0feC= >>rxiGtbe3FxUVMZnMcdb8bcqCre7v76dQKMrKyh9//PGcOXOOHDmSn5+PC0ZOdXW1k5MTUFhxQfo= >>gDMk88PZ8RXewwPiprq6+d+9ebm6u0FT51u0Wxpvpr0IDHXQf/BdH9q4gg3EBp3Ec7+3tdXR0VF= >>RU9PPzg59PIDmKOPAVlJ6UlGRsbEylUtF8b2/5nkYV0pAZICpQUVFRUlLyb3/729GjRwsKCmDn1= >>9bW3rx58/Dhw8HBwWCBhZojJ0v8C02DBEHExMQoKiqC/IS4aHa2AP6Ar28JTLA1B0Y5m80G+1u1= >>tbVvo0uJCV8xDAN28oCAABjPPSlkRQ0CfMR1ure3F3hCffTRRzNnzty3b19OTg7sw+7ubgsLC2V= >>l5YCAgNbW1on5Er1RVeGLAP6E0J4FWzHphU4RX1F5DE3WsElv2q3iw9eIiAgpKSkfHx8hr7QJPx= >>b+HD4ESlY6ne7p6SkvLy8pKTl37tyDBw8mJyeD4y5A24F7wL1798DWwBtNWW8KVCUgCALsm4Dzj= >>ECJQEJNermi5Ss+fMmMylRo8X6v5SuFQpGTk/Pz85vc+AIMce8HLeVwOGQyec2aNTNnzly+fPnJ= >>kyfz8vJgigCwQs/NzU1OTu7s7BT6+dvXZyTgJABi8BpjAAAgAElEQVSql5KSoqam9uzZM3y4f/O= >>klytyvuLDnWghcWG48ATmUHHgK6hGQUHBnTt3srKyYBKeyeIHKr04HE5ISIiCgsL06dO//vpra2= >>tr4A0ImlxTU5OXl9ff3w+6lEAiqES0SEeVVxzHCYJoa2t7+vQp2FeDTBXFUJk4XwkBRn6CrrrQd= >>RiGWBtwQbMnoGaJCV9xHO/r62toaAB5fdG6vc0z0VENTC4JCQmKioozZsyYM2fO8ePHoVmeIIiq= >>qqq7d+96e3uDrO2ge2HyZBHFk8HHopRlsVjQn1Ds1lsoU0e9hgSFXc8XuJ1DgoKLCfBMfPiKNvN= >>NrRyvA/qQ3t7ekJAQQNbZs2fr6em9fPkSys7Kyspz587B01rAygwkZkOtkJNOHQxZFILXyuFw6H= >>Q66rE0uSVCTISvGIax2ey6urqampra2lqwuwMynZSWllZWVlZWVlZUVHR1dYHGMJnMysrK4uLik= >>pISOp3O5/N7e3urq6tLSkrKysp6e3tHzllj97L48LWnp6eiogKeRPVG70loVkUvwDCg0+lkMllO= >>Tk5SUvKLL75QU1ODBk5C4O2qpKR0584ddI8QFX74ZMj7MSoPRgiO48XFxc7OziUlJUINmfSi35i= >>vwASYlJRkZWWVkJCQkJAQGhpaX1/f29sbHBysra1tYWERHh5+584db29vJpPZ2toaExOTkpISFR= >>X16NGjwsJCYO4GNm13d3d/f/+Wlhahl/2+8DUnJ8fMzCw1NRVuoLwpZaFqhJ6QiOM4jUZzc3OTk= >>pL68ssvt23bduvWreTkZOAPBNg8MDCQmpoaEBBQWVkJddkpg9B6KyIi4pdffgHnyYtohABMhK8M= >>BsPKygqc2lpeXn716tWnT592d3c/ffp01apVJiYm2dnZ+vr6enp6LS0tGRkZBgYG/v7+GRkZHh4= >>excXFdXV1Fy9etLS0LCgocHJyAutKOJUAiD9foT0LuEdOYD0ORRSqSIDHlpaW2tra/uc//5k5c6= >>a8vHxoaCiTyYRecn19fWw2G8xpaAinSNsrBCG+ksnkjRs3gnhuXJQq7ET4WlxcvHv3biUlpdLS0= >>vb29lOnTpmZmdXX1/v4+CgqKpLJ5La2tjNnzuzfv7+oqKiwsNDY2FhHR+fcuXOmpqaxsbFkMllB= >>QeHKlSuJiYnW1tb79u0LDg4W4uvYECu+gnyaME3am7YCQ/IJ4zjO5/Pz8/P19fWXLl06a9YsBQU= >>FcGorQRBAH62oqHj8+HFiYiIa3Tr1eTogHfkCf210vwAXn/NhCIJ4+fKlvLy8vLx8eXl5c3Ozjo= >>6OsbFxXV2dj4/Pb7/9lpqa2t3draur+9NPP7m7u7e2tubn59vY2Bw5ckRKSkpXV/fhw4fy8vI2N= >>jYlJSV5eXnZ2dnNzc3QVjeefhcfvoaHhysoKJBIJNQZcvwPQQ1P4G9OTs7Ro0e//PJLCQkJeXl5= >>4BJECE6qLy4u1tfXV1RUJJFI0BVrAuW+PVA6EgRBoVB27tyJ6gMiqtJE+NrV1WVlZbV79+64uLj= >>U1FQtLS17e/vGxsYHDx4oKCgEBwe3trYeP3584cKFVlZW2dnZISEh2dnZFArl4MGDx48fj4yM1N= >>bWtre37+joaG5uBsko4fPflK937tzZtWvXu+JrZmbm1atXc3JyJmYcQI3qPB4vLy9PS0tr9uzZE= >>hISq1evDgoK4nK5hGDHqL6+3szMbMOGDdevX6+vr+cPdwwQRRvHACwXyNeysjJPT8/y8nIwD2Ai= >>sxJMxD7A5/NLSkru3r3r5OTk5OR0586doqKijo4OJycnAwODsLCwzs5ONze3U6dOhYeHU6nUu3f= >>vhoWFxcXF3blzJzQ0tK6uztnZ2cbGJj4+PiAgICMjAxUVaHe8rgIoX62trffs2fPq1aupX29hGE= >>aj0RobG/v6+ibMG9AQLpeblZWlq6u7YMGCzz//fOPGje7u7sDtC5rMMjIy9PX1LS0twakY8OeoH= >>jzZTXxtnSEj4cYem80Gig0PScM96UVPkK9cLrepqam4uLioqKiuro7L5XK53JaWFmDeGhwcpNFo= >>9fX1dDqdwWCAZDDV1dVVVVUMBmNwcLCtra28vLyysrKsrKy9vf2NNu5QWvB4PBcXF11dXZDZGRe= >>xsXpkTXp7e/v7+1GHvVGLhpSCFzgy6vr6+sCcs27dOllZ2Vu3bmVkZEBfUg6H09PTw+PxOjo6Cg= >>sLaTTaqGNjKqUsNgJsNrutrQ2G32Gi8VvHJ2x/FdoXQD+EcwSKkR/iSLTaG9UYfTFDQ0O2trYHD= >>x6EPnW4KI3VI2tSUFDg4eEBdkfHdjcT4iv8y2Kx/P39ZWVlP/vss8WLF1+7dq2+vh72EofDCQ0N= >>9fT0BDna0f6cmja+DqhQIAgiMzPTzMzs+fPnBHLesSiG0ET4ig/fiIMNeFONagIzODoTga6xtLR= >>UUVF58eIFvOFNnzkxEAJ/F3Ag4B/6RqITNy7Y22Oz2UFBQTIyMh999NHnn3+ur69fWloKB97Q0F= >>BsbKyysrKRkVF7ezt8zhS07g+Bbm4RI+JjxY6vEOhr+EP/lclqACY49gnaB4D+OpVzIiHIP7B16= >>1bgT4j/0VjFhmsCAwMDJBJJSkpq+vTpS5YsuXjxYklJCVQHORxObGysiorKzp07w8LCgL0PHa5T= >>08zXNQQTGLNwHCcIIiwsTEZGBs2XIaKiJy5f8RFerXCqEtHYwkcsS4XsA7DEKXidhCD/wKZNm0A= >>SBnSuH/UncEjjON7X1wdk0owZM1asWGFvbw88rOHNNBrNyMhIRUXl2bNnbDYbfj52EVMDbLhuA+= >>yvIF8xqg+IouhhfB1/GajaCpZf/f39cOWBv4kofaO2oTdD+bp79270JHMoxkQKMDyioqLk5OT8/= >>f3RfBljVB78kMlkenl5rV+/fvr06f/+9789PDy6u7vRkDiCILq7ux8/fhwfHw/sr/CxKOnfIVD1= >>jyCIrKwsU1PTkfrrpJc7jK+QhX8IcH4NXxCrmZ2dbW9vHxsby2QyYXuw0YCPQ8Ed+ysIAjlPHtp= >>fRTq4R1amrKzM2dkZ+Ezhw53T8dGGIiHwvAZx2MuWLXN3dwcnYAEGEATR39/f29s7MDAAEusK6T= >>kinb7GCShZIWVZLFZzczNIRIlu1U560cP42tHTNjg0gP9RMQRBdHR0xMXF0Wg0HMfBIY6mpqbx8= >>fFo8jZUBuNIJC2G6OmYwIAn1B1jV0CIr+j+1hS/SJBEDWSjgE1DfQlQbhEEQaPRbG1tN2zY8Mkn= >>nyxfvtzZ2ZnBYODI8qWqquratWuurq7A5UocTAEjgb5HDMNgmlRcsAOCrsYmF8P4Gp7r39hRx2D= >>RMXysPuJyuXFxcWZmZsXFxWAwsVgsGo0GznIWYifKWiFKgQsY6DP+FsInv8P9WADYOqH8LthogW= >>vAT+if//ynhITEkiVLnJ2de3p6wJ2gE7q7ux8+fLhu3To7O7ve3l748ynbCBgn0EEICAr8X0HKD= >>NDeqdgvSCuJCk5zyS6N5/P5BD766ycIoqamRkdHZ+3atdbW1jU1NW1tbREREUFBQU1NTTwer6Ki= >>wtvb297e3t3d3d3dPTIyMjc3l0wmOzs7p6SkgK2g9vb2+Pj45OTkrKwsNDkKf3xe+uLD15qaGjK= >>ZXFlZib6qkQ0hCILNZvv6+q5cuRKoAY6Ojt3d3Tgye7a3tzs6OhoYGLi5uTU3N+MI10URCPU2QE= >>cmjuMEQeTl5VlaWoJsSHCMiZyvpm5yD4IvJubHDHCFN0jRHzQ0NOjp6UlJSYFTx2k02uXLl1euX= >>Hnr1i0Gg5GcnCwlJfXNN99YWVk5ODjs27fP2NjY0dFRVVVVRUUlIyODw+H4+voaGBhER0fHxMR4= >>enrC3XC0R8Scr6C4qKgoRUVFsNHPEySVhioBX5BCkMvlksnktWvXTp8+/ccff3R3d6fT6eA5kJE= >>JCQmGhoYRERFgmhKfA2lHBbrsA/bX9evXBwYGQr7iU+Cvvdn0Wz2nUw/CbOs768fg6+DgoJ2dnY= >>aGRklJCUEQQ0ND9vb233zzjYaGRktLy4sXL2RkZL7++msqlVpaWqqsrKyvr19eXv7o0SNZWdmws= >>LDGxkZTU9OrV6+WlpbGxMTs3bs3ICAAJCMZJ8SErxiGhYeHS0lJPXnyBI37hVQDq6WhoaHU1NRN= >>mzZNmzZt2bJlTk5OYK8V3gDuaWhoKCsrAw4ufCRkTwz1AT4SGYYJ8g/A/QJszLO73hLD+Hrg3i/= >>X/K57JzzpZHSOwdehoSE7Ozt1dfXS0lLwb1BQ0Jo1aw4ePNjc3Pzy5cutW7f+61//Sk1NLSkpUV= >>NTMzc37+joCA8PV1FRiYqKqqioOH36tJGRkbe3t62tra6ubmRkJAhVg3gv5Cvgq7S0tLe3N8gDg= >>CGARExLS9u/f/+MGTNWrVrl4uICT78GtzEYDOBoAVVhKLewMX0S3iGwEfbXsLCw7du3o+dv4VPg= >>n6V6d+dV/xuBaST2AHsMvrJYrNu3b4NwIjqdzmQyX7x4oaKioqmpCeSrrKzswoULk5KSioqKdu3= >>aZWpq2traSiKRgONmaWmpjo7OkSNHwsPDc3Nzs7KyGhsbwSSI9siorRUiBLQPQPuriIb1qP2AYV= >>hsbOzOnTvJZDLcl4KvanBwsKqqikQi7d+/f86cOStXrnRycqLRaKDa4AkVFRX29vbOzs4gaauQ9= >>RpiCprzRgADCUbkEwTx8uVLkDNd1AaNYXx9VhjR0Ufr4/bxsddOQMBA6OXlJScnd+HChfDw8NLS= >>0ujoaDk5uT179pSWlubn5ysqKq5YsQLoA3v37gUnPoKU4WZmZkVFRSdPnpSVlSWRSDk5ORQKpaC= >>gYJzxMEKaPo/Hs7GxAZE5I7+dAjQ1NUVHR1dVVUEdABeEDAUGBu7btw+ECSxbtszNzQ0IUVDPgY= >>GBFy9enD59WllZ2d3dHVgGxVZbFQLsZ74gJoLD4TCZTNSuJ6KGDOMrHxsc55ZBTU3NuXPnlJSU7= >>t+/X15enpiYaGpqam5uXlhYWFdXd//+/YsXL5aVlTU3Nz969MjZ2bmpqamgoODChQsPHz5saWnx= >>9vbeuXPn6dOnL126dP/+/ZycHChfUQEzslxseH44Pp/v4+OjpaUFjpiCv5pKKQvtWbDyNBrN19d= >>3w4YNEhIS06dP3759+/3797u6ulDZU1paeubMmY0bNz548KC1tXWKq/2WwJCFIFQJANBFpyiKJo= >>T2t8b5GxzHKyoqAgMDs7Ky+vr6WCxWU1NTY2NjT0/PwMAAjUZrbW0FyUe7urq6urrAhm1rayuIJ= >>ujo6KBQKJ6engEBASUlJb29veN8YUJ85fF4T58+PXr0KPTPmmIRBfaigREAdsuNGzdWrVr10Ucf= >>zZ49e+/evcnJySC0HV1g5eTkGBgY2NjYtLS0iFThExHQzS0cxzs6OrKzs1tbW8G3UJpMOmuJifm= >>/glrClMrEmwD8dmhoiMVigawkBLL1/4d8hUzFMAyYJjQ1NUfqr1Pz7oE+UF9fj2FYT09Pfn7+5c= >>uXly1b9tVXX23bts3c3Dw1NRXs+QG7AUEQdDq9sbGxqanpxYsXHR0dxHCDpbiZAkYFfAtQ/8nOz= >>jYzM8vMzCQQ/wFRyI6J8BUXiDF0PYuaYDDEogGXIOgMgiHO3W+0/sUQgGcGBgaePXu2oqJi5G3j= >>b84EQAhiVE6dOkUmkxMSEkxNTXft2rV27VopKSk7O7vCwkI6nQ7TBYNfNTY2enh4+Pn50el02AR= >>0Q+i94CusMyawv8bFxe3fvz8xMRGYREQkXPG34Ss0iQsNJv4ICIWAoio5Sr7xkAwdDKCsiIgIAw= >>ODV69eoaNiCoQrGG+JiYkyMjLq6uoKCgqSkpLTpk1btWqVmZkZSHEFpw5w0dTUZGdnd/bsWQqFA= >>iYW2JNTvEx8S6BVBaLn2bNnwLhOTGV8wTj1V6F6jxT+KInRf1FxK8TUNyqXjxw95eDgsH//fiH/= >>rDd6GtqcMZqJ3gP419LSYmNjs3jx4jlz5nz88cdffvmlkpKSm5tbXV2dkDkWx/GWlhZ7e3sTE5P= >>IyEgQ54QP117eF7LiI94dQRCpqam7d+8OCwvDR0tHOYkYxlfOIOePfyEGAB1BTFI8Nx9JYC1EIH= >>QoQk0dx3EOh1NSUmJmZvbjjz+CQwS2b98ODlBlMpkEksMCrpqzsrJu3rwJyIq/bwQVwkhZ097eH= >>hAQIBTlIXL9tayxDJtQWNUUA+XrW+5vYcNTfPKHZ1SG14B2wOu3pqbG29v7wIEDf//73z/++ONv= >>v/1WW1ubSqWCKFb0sZjArs7lchsaGgoKCgCbRTRXThmEyAoGPJvNBjsIMP+kyPna2NmIrtbFFpP= >>LV7RzsREn/oBSuFwuk8lMTk5+/PjxiRMnfvjhh08//XTevHkKCgpWVlbgsFZcEM+EI6pFcXFxVF= >>RUY2PjSEXovVhavQ5oE/h8fn9/P5PJhEEWuMjsM8P4GvMyYoA7KIpiJheTyFd8+DY9fA1wtdTU1= >>BQVFeXq6nr58mV5efmFCxcuWLBg3bp1x44ds7a29vDwcHBwKC0txQVkhbxnsVhUKvXixYtXr16t= >>rq5GixO6eE+B6q9FRUX29vZFRUVvv4oYG8P4mloYx+zrEf9unHT5ihoc4NRfW1ubkJBgZGS0cuX= >>Kr7766tNPP5WQkFi8ePHx48dDQ0NBWpfIyEg1NTXgP4ByncVieXt7Kykp/f777wkJCSBgEDUDve= >>/yFR/O14iICHl5+YiICFzEu+LD+BqW4dc/yPlL6QPoRgaO44ODg/X19XFxcY6OjgcOHPj555+/+= >>OKLjz/++G9/+9uiRYv27Nnj5eVVWVkJzmoE7wmcz426qxIEUVVVdfjw4R07dqCh2KBEPrI5N5md= >>MoUQ0r8JgggJCUHPk8emxv5a1Vgh5vorlIV8QeSQlZWVqqpqfn4+IQjZQ3sTG7HLgiEGKYj29vZ= >>Xr15lZGQ4OTkdPnx4yZIls2bNkpCQmDlz5vr1642Nje/evUsikWpqauDpjaC4Z8+ebd682dfXFx= >>7VAh9IJpOpVCpIhYkjs//7sikwBoTWW4Qgnhvl61TEwzDYDHEmKz7cMwis3y0sLHbu3JmXlwcn2= >>VEZKQQOh9Pf39/Z2ZmWlubv729qaqqsrLx169YFCxZISEhMmzZt5syZS5cu1dDQCA4OBhnBoKoA= >>K8Pn8ykUyi+//OLv7w9T1nE4HMBd6FcgOmXuXQET5KyFE11YWNi2bduio6OJqYzn5vHFfYYauRP= >>h5uZ26NChsrIylI58Pr+3t7e7u5vBYNDpdDqdDvLPgZxzcXFxt27dMjY2Pnbs2MaNG5cvX75w4c= >>K5c+fOnz//m2++2bRpk7GxsbW1dXBwcHFxMQj/JxDnBBS1tbXBwcEVFRU8Hm9gYIBKpbq6uhYXF= >>wNXAVBnMXS4fnugx9LiOF5ZWRkQEFBbW4uL2OVoGF9fF2MoPkCFKBCxz58/P3v2bEREREVFRUVF= >>RVVVVXl5OYVCsbCwMDMzMzMzMzExOX/+/JkzZ3bu3Llhw4Y1a9YsXbp0zpw5n3zyyccffzxv3rx= >>NmzaZmJhYWFjY2NhERkYWFhb29PSgXlcoUMkBPgG3DQ0NhYWFKSsrGxgYVFVVYYgR4E8pX2H/g1= >>kOpggHjYVnWE960cRb5s+aeqC6/NDQ0NOnTzds2PDzzz9v27ZNVlZ269atsrKyP/zww5w5cyQlJ= >>T/77LNPP/109uzZn332mYSEhISExIwZMyQEWLp06bVr11JTU1tbW2k0WktLS3d3d29vL5olE1he= >>wYfgAiytuFxub29vX18fh8Pp6ury9/dXVFTcu3dvYmIimmtbdDPjOwS6fgCta2pqSk9Pb2lpAXK= >>XL1b5X98hMMSeDyYjS0tLkD1dQkLiiy++WLRo0eLFi7/77rvvvvtu0aJFS5YsARffffedtLT02b= >>Nnz549Kycnt2TJkmXLlmloaDx58qSurg7DsM7Ozvj4eF9fXz8/PwcHBxKJ1NHRwePxGhoaSCSSg= >>4PD48eP/fz8kpOTu7u7wRsKCQm5d+/etWvXrl69qqampqGhkZmZiYqZP59khUCbieN4eHj4jh07= >>KBQKjkT2fuDrKJtDAQEBmzdv3rp164EDB27fvk0ikUJDQ0NCQkIRhISEPHv2LDMzk8lkdnR0ZGZ= >>mhoWFkclkCoVCpVLB6Ql0Oj0rKysqKio6OtrFxcXf3x+kA2pvb4+Ojrazs/Pw8IiOjs7Nze3t7Q= >>UWgJiYGC0trUWLFuno6Pj7++fn58NVl5BY/ZOJWNQ+AJahz549k5KSAucd8xGPs0kv+j3jK46Yt= >>EB3NDc337x5Mzw8vLGxEXp/jx/oYzHBcUIgYgI6rPB4vJ6eHnD2FbrjOjg46OPjs2HDBi8vL5iI= >>CX3an5uv0FUA2AdkZWXDw8OJ4QkqJ73V7xlfhfqCIAgajfbo0aPi4uLxs/N1lH2jz8F1VFQU3C8= >>gCOJ9N6yOH+gCiyCI4ODg9evXg3yaGLK/NXV8JXDwbgixMhqAbsIF24A4jiclJZmYmICda6jUTo= >>EwIwT5NLdt2+bn5wfzXPyJdVYUKCkJgkhPTzcyMkpPT8eHWw9Ey1cCHyZFMPy/RsQxwrunGBji5= >>gdmanA+TEFBAY5E5kwZY0pLSx8/fpyXl4cmIPqL8BU2GcdxDofT0dEBTl0cucs4iSCE4gsGhrgt= >>PQ2tvUV1TGpFF6WDXVnRUc7hDoiJlEU5wefzBwcHb926JeSvPcXKIh9x94aWyCkr/V2BjwBDrNH= >>gpWBTYx/Ib3tln25+NU4luMjQ98Vp24wDac2RdfT6/sF+Qjz2aTFkswA4AcbExBgaGr58+RLcwB= >>el8+XIykArIxxCfwV9QGjG5/P5AwMDwDINADOEila+XorS0yatPP3sP0dI6y4n7jSKUb5G1X+Qf= >>ft5U+YgTyz8YjEkYhH8297ebmNj8+rVK3xEUPwUVKawsNDf37+2tvYvyFfIWhzHMzIyQD54XMQR= >>lMP4qh26SfeZlJrPdxtc/qbms+FkqLJFsnZwkUdqdWIjo1EcVIKRXdDd3W1nZwf1V1GXDi8IQb4= >>3JSWl4OBgoezEIq2GOEDIShMUFLR+/XoymSxkz5r0cofxVdVtnobdd1rOP+y79v909X/wjdFMa3= >>AIenXF8/m1srZX4sBXIRAE0d3dbW9vj+oDIqLLyBfQ09Nz9+7d//znPwEBAWj+rL8IoDWGIIiQk= >>JANGzbAfJqiG7fD+LpNb832E8t1bv58wWPDJZel1yOX7/ebp/B4kXWiRQuzVUxUWBSQrzC/C1z6= >>THpZkK9Qaaurqzt48OCOHTuAfQAXm8NbRA2UkcD+GhISsnHjxtDQUFzEKSCG8VXNeZu0o+wO963= >>qAd9pkb464vf1/icbdnvtvUS5WtJZJp587ezstLW1LSoqwsfsqUnsQfgcGo129+7d+/fvt7e3Q+= >>PrX8GeNVJ8FhUVOTo6wqwluMisNMP4uvz+8mWWS+TtlU75GBxzV1d9vH6Xh+yZUIPokpheTu+kl= >>/32IAiiq6vLzs6uuLgYzk2j9tSkdJ/QE3g8XnNzc3V1NdiqFZFHknhCaCYB+fyAozqKSS93GF+P= >>+WlJPVj/o9W3253Wm0YaWac7ehYEBBSTS7vEUbjiAn3A1tY2PT191A3YyQX+mrAFXLACQ3NkTA3= >>eVc8LRRTD+mACI/QfCoiJNYFA+Wocb+Kc7uqV6WWfbX0n60Jue8IQznu3/TI2CIKg0WgGBgYXLl= >>xISUnJz8/Pzc3NESA/P7+2thbs7H8ABP5HwULQ+oEjyVNeN2UB1jKZzMrKyp6eHqiSjS1fR1YJf= >>ebYb/x/fG1htzPYDCabyccIDMf42BBBEISYuRCgIAiCwWCYm5vv3r1bW1tbX1//1KlTenp6J0+e= >>1NPT09XVtbGxiY+Pz8zMTEpKSkhI8PPzI5FIWVlZ5eXlJSUlqampiYmJhYWF6enpMTExQUFBXl5= >>enq+Bh4cH/NbLy8vb2xt86OHh4evrGx0dnZ6eTqVS09LS0qcEVCo1Kyurrq4OZLXGX5OYB8Owvr= >>4+cIzUqKxF+QHXT5C140RKSsrRo0fHnuXQt9bR0ZGRkZGdnQ2cOeE96B7EqMQlhPZjX1eG2GJoa= >>KiioiIzMzMjIyMzMzM9PT0tLS0jIyM9PT0lJSU9PZ1EIpHJZG9vb0dHR0NDw8uXL5NIpLy8vKys= >>LF9fX1dXVyqV6u/vb2dnd/nyZcDyEydOnBwBPT09PT29EydO6Orqgn8PHz78/fffz58/X1VV1cD= >>AYMeOHdLS0ps3b5aSktosekhJScnIyOjq6j58+PDRo0d2dnaOjo4ODg72CBwcHB49emRhYWFpaf= >>nw4UMHB4eEhISGhobk5GQPDw8KhZKXl0ehUB4/fuzv75+UlOTm5hYZGVlVVZWUlAS6MSMjg8Fgc= >>DgcNpvNYrGApyWLxert7WWz2eDDwcFBf3//9evX+/n5cTicvr6+/v5+kNwX/Mtms4FyDza9CIKo= >>r683MzPbvHmzvr5+eHg4iOgcGBiAFpjXbWuPxlecwMVVoI6Kscc0m83u7+/v6+vr6enp7Ozs6Oj= >>o6+sDwxf0Johs6enp6erqam9vb2tr6xgN4KvW1tbW1lZwXVdXFxwc7OLikpubW1BQ4OnpaWtra2= >>tra2NjYyt6PHz48P79+3p6eoqKilu3bpWWlpaWlpYdDTIyMrKystLS0jIyMlpaWhYWFrt27fr22= >>28VFBQMDQ3V1NQWLly4YsUKFRWV7du3a2lpGRgYSEtLy8vL79mzR01N7fr163fu3Dl//vzp06cN= >>BDhz5oyRkdHp06f19fXPnj2rqqr6r3/969dffz1z5oyBgYGhoSG4MDAwMDIyOnfuXEBAQFxcXEB= >>AQEZGRklJSVRUlJqa2rRp0yQlJVetWnX48OGTJ09aWFikp6fT6XQulwuTcI1810h+wiE6l9dDEL= >>z3QrKOBIE4p6J7USOnQngbgayW3nF4G70AAAm1SURBVAZTvMyCaGlpycrKAhNLeno6mGdGAnwLL= >>hISEqysrHR1dW1tbZOTk58+fXry5Mljx45ZWlrGxcWlp6fb2dlpaWnp6elZWFhYWVk5OTnZ2dkZ= >>GRlpamqqq6sfOHDg4MGDBw4c2L9///79+zU1NTU0NDQ1NQ8fPnxQAHV1dQ0NDQ0NDXD/kSNHLl6= >>8aGpqqqSkdPr06cuXLyspKX3zzTcSw/H3v/997969GRkZmCAybNRX/D++ZjW4FNOCa+hpxW2F3X= >>3090rICrv048PXsEJObuid0BSFIT6d4ykRMhU+fIrJiv/Ryul16O3tbWtrA+EYQ0NDYN4Ax4QTB= >>MFms1taWlpbW5lMJpju+/v7Ozo66uvrGxoaGhsbGxsb6+rq6urqQGJ78Bdc1NfXg9vq6uoaGhqa= >>mprq6+sbGxurq6uzsrK8vb0pFEpCQsLt27eVlJQkJSU/+uijxYsXf//99/Ly8jdu3HBwcCgvLx/= >>jFRAoX+0y91ikqDtlX0urTevlsIj3SsqiSjo23O0QqE0A+PClLiZI/YAS+nXPF/pKaCGM0n1sjH= >>zIGHeO/RXanFHHJICQkxA+/HB0yGP4lYgAExgmJCQcOnRIWVlZR0cnMDAwMzOzuLgYqLxCbopCG= >>MbXK6n7joXu1A3VuJt8u6il+P21fmPDF5hCRBn5FfwJ/nrfrtdRbeRt46keeH+vux9l6hiVgfQa= >>oz5CXwnRHd2OGrXckRfoM2GPYYJ1Ei6Yr3DkaFyhvuVyuRkZGT4+PiUlJeAcViFa469PMjKMr6f= >>8fz0fuedK9GGH9Dvpdek9nN73S8SKLTBEDHO53Pr6+levXlVUVACDJT7cExK1wwvJRSGe8fn8tr= >>a20tLS1tZWMHuIoYhBaQfrDw0FKEfHA8BXcJiZxDXzNbGvzmU0OCZW2SdXu3f21X7g66QAynuCI= >>Lq6ujw9Pfft23fx4sWqqiohi6MQccF7xUeb63Ec53K5gYGB6urqDg4O4EwEMeTrqHhTmqI//B9f= >>9T0WawV+s9dn7u/+/ybnOzHZrz31+APeFJjAFN/X1+fs7LxixYrjx483NTUJSU0CWUVB7sIPcWS= >>iBPeEhoauXr3a0NCQTqf/FVzDCIJISkr6L1/3ev5zn8e3u91/2uWu6pLh0Tvwni25xBnoJE4mkz= >>du3Ghubg5Sb+ACn3wcx0F2o+7ubhBwi2HY4OAgi8ViMpnAVAwfNTg4yOFwCgoKfv31V2NjY3BG/= >>V+LrwdcNLY9XKHmLnMz4UZyTSqHxxm5xAO/EdsdWrEFZBKXyyWRSOvXr798+TKTycQEbmU4jnd1= >>dcXGxjo6OlpYWMTGxrJYLA6Hk5+f7+3t7eXlRSKRSkpKQGbP1tbW6Ohof3//u3fvrlmzxtDQEDz= >>qfdEHJoxhfN3lo3wywtgi1dog3Ngjw4Mz0E8QBB/j83g8Aifa+lohg8Unwvu9AKqYDg0NBQUFbd= >>iwAfAVfE4QBJPJdHV1NTY2trW11dHROXDgQGpqalFR0alTp/bs2WNnZ3fhwoVHjx61t7fTaDQ7O= >>7vjx4/b2NhoamouWLDAyMiIyWTifzX5KvVw7Q7Xnb/aqyhaKxk9PRucF+yX5xeSExL3Ku485bwB= >>5UxuU25Ja0lgbiCNRfugKrwRoPDj8XhBQUE///yzmZlZd3c3+KS2tjYsLExBQeHEiRNdXV3FxcU= >>HDhzw9vYuKirS1tbesWPHkydPzp8/b2ho2NzcTKVSt2zZYmhoWF9f7+bmtnz5cgMDA2Dt/4vwtb= >>OzkyAIieW6P/x87me563K/Wu6Su75d2kpG3VXd0Nto1ZVVP9/ZcDfynonPeRWbXbee3UorTetid= >>b3ryr9PgOv6oaGh4OBgIF8ZDAZBEHQ63cHB4dChQ4sWLdLW1gaB0SYmJiB34oULFzZv3nz58mUT= >>ExPA18DAwNWrV3t7exMEUVhYqKysbGJiAlXhPzeG8bX3UW/8xdgw05D0W6mvbr2IOR3tfsr9H6f= >>++dP51ZZ+Vrstdi+98I9dzr+c8TYwDzRv6Gr8K3TQxDBtNOCC8+eDgoLWrl1rbm7OYDAwDKNSqa= >>qqqvv37//hhx8OHTrU0dHBYDCMjIx8fHxCQkLWrFmjpKQUExMDNvErKytBcJ+dnV1vb29CQsKWL= >>VuMjY3huYp/Mgj1oYSEhJyc3H/5mmSWXGBcWGpcVnulufZiE9WQWmNZuezC94ccj/x45cdvb3+1= >>1nb5kivffn/pB5MnZ/OrcvmYuOePf1cYSdaPPvoI2F8HBgbc3Nx+/PFHXV3d58+f5+fnm5mZ/fT= >>TT46OjsePH1dUVAwKCgoICDhy5Eh4eLibm9v8+fMVFRXDw8PPnDmzbds2X1/ftLQ0FRUVVVVVNz= >>c3dXX1L7/8Ultbu7VVHANC3x5j8dXvelTy40qyZf6NQ8GUa3lUqwJ/3bDtt2XXXF0u6/rTmofLF= >>9/7f98/+oes2w/HQn5zfm7f9cFA+xq8jq84jvf29j59+lRHR+fSpUve3t6urq4GBgba2tpZWVkx= >>MTFHjx49ffr0+fPnr1+/XlZWlpqaqqqqKi0tbWxsfPr0aQUFBVNT05KSkidPngCvKGVl5dWrV1+= >>+fLmuru5dN1okGIuvVY6VbZG0ZI9c4+N3oq0LHl5Lengj8ICx4qnr23dd3SizZ/6JaysCXtmmNc= >>QlVcfGlyW0Mzs+8HVUjCTr9OnTcRwH8rWmpqawsLCoqKi0tLSoqOjVq1elpaU9PT0sFqugoCAiI= >>iI1NbW2tra/v5/BYKSlpXl4eISFhRUUFCQmJsbGxnZ3d3d1dcXHx5NIpOjo6KCgoIKCAqBavOt2= >>Tz5G5SuNRiMIQoLtymE95rHd+ZU2FfGGidQjRUUmHZsfrF5z96elt/653Giu6v01mqS9ak9+0/c= >>7Hfo8lMakfTDEjorXyVeIkYZtsKFFEATwBCAEJ3kQBDE4OAgj+IaGhnDkVFscx9Go1D8fZV/H1+= >>vXr0s0OPVUWHMa7g22W7bmnKO6aTxOOZquFrxLyn3z7JuzFjz4xx6yhpyH/GG/ww6JDuXN5aN2+= >>gcQBCExGsbzQ/z17nyvY/mfGyO7cdu2bf+Vr+XW9PbHPfUOtBdWNbV3mAnGKZrr95NKSWH1Ida5= >>9w6Faxgnnfg1UMkixSqrPquzv/Ndt0V8MWG+foAQRnbj5s2b/8vXZF963n1esX1/jkN/qOVQ1G3= >>89u9P5n7xxZGNR112hz+7kRF7vSTfpSnc4nkqOSOFkuLzxMdrBLw/4ANej5GEGSMmGUYmA7i7u7= >>u6uoaFhbW0tBCjxsd+wAeILT7w9QPeJ3zg6we8T/jA1w94n/D/AWQx0gRPTdK4AAAAAElFTkSuQ= >>mCC" alt=3D"">
>>
=A0=A0=A0=A0 I wonder, however, does the situation the same if rateless= >> erasure code (say fountain codes) is used?=A0 As with erasure code, no ACK= >> and retransmission is needed except when the whole file is completed. So e= >>ven heavy loaded, the network is still busy with effective data packet, rig= >>ht?=A0 Although queueing delay will increase, I believe that=A0 the network= >> throughput=A0 will not=A0 suffer the plunge as un-coded network.
>>
=A0

Kara






2= >>013/3/5 Srinivasan Keshav <>aterloo.ca" target=3D"_blank">keshav at uwaterloo.ca>
>uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = >>solid;padding-left:1ex"> >> >>To answer this question, I put together some slides for a presentation at t= >>he IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we always= >> size a shared resource (such as a link or a router) smaller than the sum o= >>f peak demands. This can result in transient or persistent overloads, reduc= >>ing user-perceived performance. Transient overloads are easily relieved by = >>a buffer, but persistent overload requires reductions of source loads, whic= >>h is the role of congestion control. Lacking congestion control, or worse, = >>with an inappropriate response to a performance problem (such as by increas= >>ing the load), shared network resources are always overloaded leading to de= >>lays, losses, and eventually collapse, where every packet that is sent is a= >> retransmission and no source makes progress. A more detailed description c= >>an also be found in chapter 1 of my PhD thesis [2].
>> >> >>
>>Incidentally, the distributed optimization approach that Jon mentioned is d= >>escribed beautifully in [3].
>>
>>hope this helps,
>>keshav
>>
>>[1] Congestion and Congestion Control, Presentation at IRTF ICCRG Workshop,= >> PFLDnet, 2007, Los Angeles (California), USA, February 2007.
>>>stion.pdf" target=3D"_blank">http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >>pers/data/07/congestion.pdf
>>
>>[2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, publishe= >>d as UC Berkeley TR-654, September 1991
>>>s/ch1.pdf" target=3D"_blank">http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >>pers/data/91/thesis/ch1.pdf
>>
>>[3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition = >>methods for network utility maximization." Selected Areas in Communica= >>tions, IEEE Journal on 24.8 (2006): 1439-1451.
>>>_blank">http://www.princeton.edu/~chiangm/decomptutorial.pdf
>>
>>
>>

>> >>--f46d0444e84964e1a304d740bdcd-- cheers jon From keshav at uwaterloo.ca Wed Mar 6 05:57:42 2013 From: keshav at uwaterloo.ca (Srinivasan Keshav) Date: Wed, 6 Mar 2013 13:57:42 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <6AE5486E-76DB-4BBE-A71B-48CC31447DED@uwaterloo.ca> Shun, To make sure that we're all on the same page, I assume that by a rateless code you mean a code where a source that wants to send S bytes actually sends a potentially infinite number of bytes, but the receiver can decode the source as long as it successfully receives aS bytes, where a > 1 [1]. Rateless erasure codes allow a receiver to recover from packet losses due to transient congestion because it can decode the transmitted information despite losses. Thus, these codes provide an alternative to buffers, allowing us to trade (buffer) space for (link) time. When source rates are not reduced in response to overload of a shared resource, then congestion is persistent and the packet loss rate is high (and equal to the difference between the sum of the source rates and the resource capacity). In this situation, I think that fountain codes are not a sufficient solution, because in order to receive aS bytes, a source may need to send a potentially unbounded number of bytes. Moreover, this excess load can cause overloads elsewhere in the network. Thus, the network is not carrying retransmissions, as you correctly observe, but it is still not a healthy situation. To fix ideas, consider a link whose carrying capacity is 1 unit, and whose average load over some period of time is 4 units. Then, 3 units of packets must be dropped at the link. Assuming that losses are shared perfectly evenly, a source that wants to send S bytes through this link would need to send (3+a)S bytes; the receiver would then still receive aS bytes and decode the source. This appears to be a reasonable solution, in that the receiver is able to decode the source despite overload, but note that every link prior to the congested link on the path from the source to the receiver is carrying 3S worth of traffic that is destined to be dropped. If such a link is on the path from some other source to some other destination, this can cause other paths to also be overloaded, raising the overall load on the network. Moreover, if the response of a source to overload is to send *more* data, to allow the receiver to decode traffic, this quickly leads to widespread collapse. Incidentally, Bob Braden's remarks on legislating TCP-friendliness become very clear in this context. If source A were to drop its source rate in response to congestion, but source B uses a fountain code and does not reduce its source rate, then source B's packets will dominate the shared resource, shutting out source A. Thus, it is individually rational for each source to use a fountain code, but the overall system suffers if each source acts in its own selfish self interest. This is well understood. Solutions range from careful sharing of the resource that allocates packet losses in proportion to source rates (for example by means of fair queueing) to legislating the use of TCP-friendly sources. From time to time researchers discover that 'selfish' transport protocols do better than TCP, the recent report from Fujtsu being one more in a long line of offenders. We can only hope that these efforts are not widely successful; otherwise costly in-network control mechanisms will need to be invoked. regards keshav [1] http://en.wikipedia.org/wiki/Fountain_code On 2013-03-06, at 7:29 AM, shun cai wrote: As discussed in chapter 1 of your PhD thesis, when network is congested, retransmission dominate the traffic and effective throughput diminshes rapidly, leading to a deteriorating situation. This can be illustrated in the well known figure with two turning points Knee and Cliff. [X] I wonder, however, does the situation the same if rateless erasure code (say fountain codes) is used? As with erasure code, no ACK and retransmission is needed except when the whole file is completed. So even heavy loaded, the network is still busy with effective data packet, right? Although queueing delay will increase, I believe that the network throughput will not suffer the plunge as un-coded network. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130306/000305a7/attachment.html From vitacaishun at gmail.com Wed Mar 6 06:49:09 2013 From: vitacaishun at gmail.com (shun cai) Date: Wed, 6 Mar 2013 22:49:09 +0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: 1. With fountain codes, for k original packets, infinite number of encoded packets can be generated and the receiver can recover the k packets with any k(1+ e) coded packets. 2. Suppose all flows are coded, and the short term packet arrival rate of some flows exceeds the service rate of the network. Overflow and packet loss could happen wheather the packet coded or not. My point is, I do not think the effective throughput will plunge with coded flows , although the buffers are full. The network is in full swing and the worst delay of a flow is the sum of the maximum queue time of the routers along the path. I think there will not be a cliff in the throughput-load figure, insdead, the curve will go beyond the Knee and reach a constant throughput. 2013/3/6 Jon Crowcroft > there's no free lunch - if the queue keeps being filled, you'll get > increasing > packet loss - to cover the loss, you'll need more redundency in your > erasure > coding - this will cost you more delay at source (in constructing more > redundency) and more overhead in the net, which is a positive feedback > loop, > just like retransmitting a whole window into a congested queue/path - a > "vicious cycle" as opposed to a virtuous one... > > so all that erasure codes buy you is delaying the point when you go over > the > clif > > In missive < > CANZhn5Gqyw6-XpaB2-XKmbahKidOap+ZDqGAJ2NqdMBxmYAP-w at mail.gmail.com>, shun > cai > typed: > > >>--f46d0444e84964e1a304d740bdcd > >>Content-Type: text/plain; charset=ISO-8859-1 > >> > >>As discussed in chapter 1 of your PhD thesis, when network is > congested, > >>retransmission dominate the traffic and effective throughput diminshes > >>rapidly, leading to a deteriorating situation. This can be illustrated > in > >>the well known figure with two turning points Knee and Cliff. > >> > >> > >> I wonder, however, does the situation the same if rateless erasure > >>code (say fountain codes) is used? As with erasure code, no ACK and > >>retransmission is needed except when the whole file is completed. So > even > >>heavy loaded, the network is still busy with effective data packet, > right? > >>Although queueing delay will increase, I believe that the network > >>throughput will not suffer the plunge as un-coded network. > >> > >> > >> > >>Kara > >> > >> > >> > >> > >> > >> > >>2013/3/5 Srinivasan Keshav > >> > >>> To answer this question, I put together some slides for a > presentation at > >>> the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we > >>> always size a shared resource (such as a link or a router) smaller > than the > >>> sum of peak demands. This can result in transient or persistent > overloads, > >>> reducing user-perceived performance. Transient overloads are easily > >>> relieved by a buffer, but persistent overload requires reductions of > source > >>> loads, which is the role of congestion control. Lacking congestion > control, > >>> or worse, with an inappropriate response to a performance problem > (such as > >>> by increasing the load), shared network resources are always > overloaded > >>> leading to delays, losses, and eventually collapse, where every > packet that > >>> is sent is a retransmission and no source makes progress. A more > detailed > >>> description can also be found in chapter 1 of my PhD thesis [2]. > >>> > >>> Incidentally, the distributed optimization approach that Jon > mentioned is > >>> described beautifully in [3]. > >>> > >>> hope this helps, > >>> keshav > >>> > >>> [1] Congestion and Congestion Control, Presentation at IRTF ICCRG > >>> Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. > >>> > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf > >>> > >>> [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, > >>> published as UC Berkeley TR-654, September 1991 > >>> > http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf > >>> > >>> [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition > >>> methods for network utility maximization." Selected Areas in > >>> Communications, IEEE Journal on 24.8 (2006): 1439-1451. > >>> http://www.princeton.edu/~chiangm/decomptutorial.pdf > >>> > >>> > >>> > >> > >>--f46d0444e84964e1a304d740bdcd > >>Content-Type: text/html; charset=ISO-8859-1 > >>Content-Transfer-Encoding: quoted-printable > >> > >>As discussed in chapter 1 of your PhD thesis,=A0 when network is > congested,= > >> retransmission dominate the traffic and effective throughput diminshes > rap= > >>idly, leading to a deteriorating situation. This can be illustrated in > the = > >>well known figure with two turning points Knee and Cliff.
> >> src=3D"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOUAAAFECAIAAABXn= > > >>G6+AAAgAElEQVR4nOxdZ1xTydeOFfuqq7uL69rL7uqquy5WXFRELKiAWMDeUFEQUVERRVF6ryoq= > > >>IKxrowjSpKggSG9SBek9IQkhhYQkd94P82b+Q7CAFEXyfOAXbu69M3fy3DNnzjlzDqnP+0BI0H5= > > >>IRrKzIDaGJBJp5cqVNTU1AACSZJQ7C5KR7CxI+NodkIxkZ+G9fK2trZXwtQWEGAQCgUAgaP3tRy= > > >>7/NkYSPaZAIIAf0FMLRBAbB3gEP4iP4SfHrTUkfG0T0OByuVw+n99L+CoQCPh8PkEQfBHESCl2A= > > >>vpKIBDweDz4b3Nzc3NzM+I3n8+HfEWXtKtLEr5+GnB8ISn5fH5zczP8kQhM7n78Dj1xJOHDQkrx= > > >>eDxERz6fDwAgCAIxDw0OLjvhtTg18bFCQ9qZfO2SYeiZAAAAAOAQAxGINvO1JwJSkxDN9c3NzQK= > > >>BAA4CjUZjMBgEpg/gAwJPQ58J0SiBlkCtdKSTAICoqKi6ujoJX/8HGo2Wl5eXn59Po9EEAgGTyX= > > >>z79m1FRQWXyyXaoAz0UODCDypCAoGgtrY2Ojra2dnZy8vr3bt3DAaDx+NxudyKioq8vDwmk0kQB= > > >>IfDqa+vZ7FYUA3g8Xj5+fmxsbEFBQVMJpPBYBQVFZWWljY0NKBp6rMh4as4AAARERFbtmy5cOFC= > > >>QUEBl8t98uSJgYHBixcv2Gy22EriC/azK4DP8nw+Pz09/ezZs0eOHLly5YqRkZGBgYG5uXlcXBy= > > >>NRnvw4IGOjk5mZiYAoKSkxNXVNSwsjMViAQDKysqsrKz279+vrq7u5OTk4uJiaWlpaWn54sULXL= > > >>X9PEj4Kg4AgKen5+jRo/fs2VNcXJyWlnbq1CknJ6eysjIoHsD7gK79yBF08KsFUkYBAHV1dadOn= > > >>frzzz9dXFxqa2vz8vL09PR+++03KysrDodz9+7dJUuWvHjxAgBQVVXl5OT0+PHjpqYmNpvt5eWl= > > >>q6trY2OjoaGxatUqWVlZb2/ve/fuPX/+nMfj8Xg8CV87EwCAhISE5cuX79u3LyQkxMjIyMnJqbq= > > >>6GqlobDa7rq4OznRVVVVUKhWtJOh0ekVFRW1tbWNjI5RSLBarsrKSQqFwuVy0lIYrkq9TPCNDVW= > > >>ho6F9//bVp06aysjL4suXm5p4/f97R0ZHFYnl5eS1duvT58+cAAD6fX1VVVVdXRxBEUVHRvn37j= > > >>h8/XlRUlJ6efuDAgSVLlqSnp1OpVCqVCnXijnQP8pVMJkv4+v8AAJDJ5KNHj8rLy69fv37BggXB= > > >>wcFw9QAp+OLFiwMHDjg6Ot69e9fQ0NDa2jonJ0coFNbW1jo4OOjr6xsbG7u7u9fV1fH5fF9f3wM= > > >>HDty4cSMmJqaoqAgZfVpbLr8SwF41NTU5OjqOGTNmx44dVCoV2QdSU1OjoqIaGxu9vLzk5OSio6= > > >>MBANXV1f7+/ikpKQKBICEhQVZWdtGiRREREVlZWevWrfvtt98iIiLQ+rWDL6qEr+IAAFCp1OPHj= > > >>0+dOlVeXl5GRubKlSuVlZUEQUDd6/Hjx2PHjl28eLGXl9fjx481NTVv377NYrGioqJ2797t5ub2= > > >>33//7dmz5+XLl2VlZYcPH96xY8fTp0/t7e2dnZ1ra2uR9+Fr4yu+uudwOI6OjqNHj1ZXV6fRaIT= > > >>IIN3U1MRisbhcrru7u6ysbFRUFACgtLRUS0vL2tqayWS+ePFi0aJFsrKyMTExubm5W7ZsmT59+s= > > >>OHD6EagJtsPw8SvooDAPDu3btdu3Zt3LgxICDAwcFh8+bN7u7uVCqVIAihUBgQEPDnn38eOnSoq= > > >>KiosbHRwcHB1ta2qKjo2rVrGzduDA4OTkhIOH369L179169eqWmpmZmZpaXl+ft7W1kZJSVlfUZ= > > >>NsjuAb7YYrFYLi4uv/zyy/79+6ElC07ldDqdyWQKBAIvLy9FRcVXr14BAJqbm83Nzc3MzDgcTn5= > > >>+/vbt2/X19RsaGphMprW19fr161NTU6EfoeNakISv4gAAJCUlqaio6OnplZeX19fXGxkZrV279v= > > >>bt2zQaDQAQEhKydOnSCxcuUCiUxsZGZ2dnR0fH/Px8IyOjdevWPXz48M2bNyEhIenp6XFxcRoaG= > > >>hYWFtnZ2SkpKVFRUeXl5WhO/NrkKyFSXgEATU1N9+/fX7Bgwe7duysqKqA+QCaTb9++HR4ezuVy= > > >>fXx8Nm/eHB8fD9UkFxcXBwcHHo9XUVFx8OBBExOTpqYmDofj5OSkrq5eWFgI1dwOGgcIEV8pFIq= > > >>Er/8PAEBkZOTixYtVVVXT0tKamppcXV1/+umntWvXJiUlCYXCsLCw6dOna2hoFBcXl5eXX7hwwc= > > >>LCgkKh+Pv7q6qqenp6pqamPnjwoKqqKjc3d//+/RcvXszNzS0oKIiLiysvL29ubiYwj/zXA9wVw= > > >>ufzMzMztbS0ZGRkbG1tS0tLaTSav7+/mpra/fv3mUymq6vrokWLgoKChEJhUVHRoUOHzp8/39jY= > > >>mJOTs2HDBk1NTTKZXF1dffjwYRkZmeTkZEjr5ubmTrEPSPj6PwAAUlJSLl26ZGlpmZubS6fTfXx= > > >>8zp07Z2pqmpmZKRAIsrKyrl69evfuXQqFUlFR4eXlFRoayuFwKisr7e3tDQwMLC0tHR0dS0tLmU= > > >>xmaGiovr6+jY3Nf//9Fx0dTaPRkM3oa9MKcOcqFIfp6emHDx9WUlK6ePGiubm5tra2g4NDRUUFj= > > >>UYzNzeXk5Pz9PSsra319vZeuXLl8ePH3717Fx0draKioqGhER8fn56evm3btqVLlwYEBOCuWglf= > > >>OxlNTU319fX19fUcDofH49FoNAqFQiaTORwOQRBcLpdKpUI1rqmpiUqlNjY2QvJVVFS8fPkyMjI= > > >>yNzcXGs/ZbHZ8fHxoaGhKSgpUJ/BlzRd+zvcBiVjY1fz8/EePHp07d+7s2bOPHj2qqqoiCILJZL= > > >>5+/drX1zcjI4NCoSQmJvr4+ERGRlZVVRUXF4eEhDx9+jQ/P7+ysjIsLMzf3z8zMxOa8zo+q0j4+= > > >>h681yOADP4f+gz/JQgCuc7RCTD+A57zdWqu7wUyQlVUVFRWVsLAF7EICnz5iEx1YlFd+Equ412S= > > >>8LVzgMQSBBInOKFxNaCnsBaqB+ih4ISO/hVicS2Iu2IvMIEFf3VcvkZGRkr42gkQC7R771dI6ny= > > >>1Vi0x4EZTsadDXxEtdV+ipUDFz+8U+Srha0fR+pdAR3ASf+T8rxawq2J2/tYvHn5EjLUENggd7w= > > >>/ka319vYSvn4+P8LX1IqNTlh3dBriiR4RDxMUfWexxJHxtE74IAz4kKTt3EvyCENMHxPRvYcsVF= > > >>dJoCUwlaH3DjvTnG+Errtd3Pz/ErATEN8RX4qPMw0VsUVERtCGI6ayd25lvhK9oi5UQQ/c0LRAI= > > >>WCxWY2Njx4PneygAADwez8vLy8nJCe6s6rrx7/F8BQA0NDQkJSXBaL3ul2pNTU3Pnj3z8PCoqqr= > > >>q6aL08wAA4HK5BgYGGzduzM7OBqJ9b10xGt8CX7Oysk6fPv3o0SM2m02ItnF2WwdYLJaNjc3u3b= > > >>uzsrK+2kCWLgWUr66urjo6Om/fvgXYxsyuaKsH8xUOTUxMzOLFi3V1dSsrKwEAHQ8Cahe4XG5YW= > > >>Jirq2tJSUnPWvt3IoRCYVVV1bt371gsFtLHusLA3OP52tzcfP/+/QkTJqxYsSIpKan7XfNCoZDJ= > > >>ZFKp1KamJuKbWGB9HtCiE00yEr7+D8iAwmAw9PT0Bg0aNGfOnODgYB6PR3Q7X8UcsN3W9FcFJpN= > > >>Jo9HQqreLtLIexlc0ENAoCACoqalRVVUlkUiTJ0++c+cOVGG7kzQCgaCysvLt27eNjY3EVxnY2t= > > >>WAMjUwMNDJyamiooJo6art9LZ6GF/x3EwAgPj4eFlZWRKJNHbs2KtXr0LPcrf1BwDA4XD+/fdfm= > > >>Kygd4pYuN66dOnShg0bMjIyiK5c8vY8vuIaKpvNtrS0HDduHIlE6tOnz6ZNmzIzMyGPu6c/AAAW= > > >>i2Vqarpu3brU1NTuafRrA+SroaHh6tWr09LSJPbX/0FsILKystTV1SdPnjxy5Mhx48YtX74cWbW= > > >>6B5CvZmZmcFddt7X7VQHaXy9cuLBhwwa4tZBoGTnZuW31JL4SWIIxPp8fGRmppaWlqakpIyNz5M= > > >>iRS5cueXp6NjQ0dFtnIF9tbGy2bduWmpraO11ckK82NjaGhoZwA4LwfUlzO6utnsRXKF+RxaSoq= > > >>Cg+Pv7x48erV6++ceNGenr6mzdvmExmd2qQPB4vKSkpICCAQqH0Ns0VAsqOlJSU1NRU6GLsOqti= > > >>z+Mr0dJKIBQKX758qaCgcPv2bZiPreNJbz6jPwJRTkkCC75BaB0Qg04TiwvBbyIWudc6pge0zNK= > > >>FH8ebw0cDnibWf3Qy3kP8YGt86DjeSYl8FQccoOfPnysoKLi5ubHZbLHfo6uBzMBiwPVssd8S7R= > > >>iBp6EPAlHqanQynuFa7OZoUwp+PpqCAcZjoSjhdWuqvbfzxIeJ2PpMBoMB02g2NTVRKBSYfrT1C= > > >>HQiQE/nK0EQiK8sFovo9kDY5ubmysrK5OTkuLi4hISE2NjYhISEmpoa2I3q6ur4+Pjo6OiYmJjU= > > >>1FQqlcrn88lkcmpq6qtXr2JjY2NiYjIyMqDttr6+PikpKSYmJiYmJjY2FmbggscTExNfvnz54sW= > > >>LhIQEmCCIz+cXFxfHxcXFxMS8fPkyIyMDJmJpbGxMSUmBJ8fExMAYv+bmZjKZnJKS8urVq5iYmP= > > >>T0dCaTCYlVWVmZmJj46tWr+Pj4hISEgoKCwsLC5OTk+Pj4169fJ74P8PjLly9dXV3v3Lnz9OnTx= > > >>48fwx3w4eHhiYmJJSUl+ITTiZDwtaPgcDg+Pj7btm1TVFRcv379pk2b9uzZExERAXcwR0ZGHjhw= > > >>YNOmTRs3btTV1U1LSxMIBHFxcdra2ioqKioqKsrKypcvXy4qKmpqagoKCtqzZ4+KioqSktLevXt= > > >>fvnzJ4/EAAC9fvty7d6+ysvLGjRuPHj2alpYmFAo5HI63t7eGhsbGjRs3b95sYmJSUlICACgoKD= > > >>hx4oSqqqqKisqWLVtgCkEGg+Hu7q6mprZu3bpVq1apqqrevXuXTCYXFBRcunRpzZo1CgoKa9asW= > > >>bNmzdGjRzU1NVevXi0vL6+goLD6fVBQUFBUVJSTk5syZcrMmTMXLlz4559/jhkzZvz48UuXLlVS= > > >>UnJ1dYVzXaePtoSvnw9kA7a1tR01atTPP/+sqalpY2Nz8+bNnJwcmJ86IyPjxo0b9vb2tra2Xl5= > > >>eUPAUFBR4eHjY2dnZ2tra2Nj4+fnV1tZyOJz4+HgXFxd7e3tLS0sXF5c3b97ALdTZ2dk3btyws7= > > >>OztrZ2d3cvLS0VCAQ8Hg9mvrazs4M3gVmlqFTq/fv37ezsLCwsrK2tk5OTqVRqQkLClStX5s2bJ= > > >>yUl1bdvXykpqblz52pqampoaIwfP56EYejQocOHDx84cKCUlNSgQYMGfhgDBgwYOXLk5MmTJ0yY= > > >>MH78+AEDBkAr+MCBA3V0dGD6hU4fcwlfO9oBFotlaWk5atQoVVXV3NxcqCwiLxePx2tqaoI51Ju= > > >>ampB7HR3kcrnQYycUCtERLpfL4XBg5iKCIGBiDg6H09TUBG8C9Vd4c3hn2JnGxkYKhVJYWBgWFu= > > >>bl5eXp6enu7m5kZKSqqrps2TIxakL06dPnu++++/7770ePHj1y5Mgff/xxyZIlW7du3bJly9atW= > > >>7dt27alFTZv3qymprZ161Z9ff3r1687Ozvb29svWLAA3VBHRwfqG10x4BK+dqgD0Mc2d+5cd3d3= > > >>OH2jpQ9u1sFXS0SrNQ2Bxc20Pv7er3A0Njbm5ubGx8fb2dnp6+sfO3Zs9erVv/7667Rp0yZNmjR= > > >>y5EicoIMHD54xY8acOXPmzJkze/bs9evXGxoampubm5iYmJiY2Nvbh4aGZmdnZ2Vl5eTk5Ofn53= > > >>4YFRUVMG8zhUIxNTX99ddf+/fv37dv35MnT3aR10bC17YCNy3hHWAwGBYWFocPH87NzRW2THYCP= > > >>+PlkAjMGiVsmQpFzLQstuUfJ3pDQ0NWVhbMfxgYGHj//v2LFy+uXr160aJF48aNGzZs2KBBg4YN= > > >>GzZx4sTffvvtt99++/XXX2VkZNauXausrKyioqKrq3v//v1nz56Fh4eHh4enpKTU1NQwGAwmk9n= > > >>Y2AhzK3389XgvCgsL3dzcZGVlBw4cuGfPnrKyMok9SxzdzFeBQIAHg8MPNBrNz88vKioKtt4uCD= > > >>BAXkJyo+gzBKj1BgYGPnjwwMLCQllZGRJ0ypQpP/3008iRI6WkpIYOHbpkyZItW7aoqqoePXr0z= > > >>p07/v7+AQEBT548iYyMzM7OLisrKy0thboyNBog1eUzCApamZMpFIqBgcGwYcP+/vvv8PBwiT1L= > > >>HN3JV4Ig8BJq6CCPx6NQKHhcfRvvhstXeGc81Q8El8utrq7Ozs728PBQV1efNWuWtLT0999/P2D= > > >>AgL59+w4ePFhaWnrq1KkbN240NDS0tbWNiYkpLCwsKCioqKiApESatBj738u5z4ZQKGxoaKivrz= > > >>czMxs5cuSECRO8vb2FXRB4JOFrOwAnOChlCZHGKRQK3759Gx8fT6fT2xVMKKYDIAI1NTXR6fSSk= > > >>pKoqChPT089PT0lJaXp06f369cPCtGpU6euW7dOWVn52LFjd+7cCQgIyMzMbGxsbGpqEqM77rMQ= > > >>e5D2vl0fAQCAx+M9efLE29v73LlzI0eOHD9+vKenp0S+iqOb9QEc8Cfncrk1NTUuLi7Hjx/Pzs5= > > >>u7w3RB0gvCoWSnp7u4eFhZGR06NChv/766+effx48eDBcJ02dOvXo0aNXrlxxd3dPTU2Fyx1Ywo= > > >>5o6eUS6zCub3RFeC6cB4yNjVVVVffu3Qtj5Tw8PDq3FdSWhK/tBpxnWSxWRESEn5+fvr7+xo0bU= > > >>1JS2kgIXATy+fyGhobc3FwfHx9dXd1Vq1ZNmTJl2LBhQ4YMkZKSmjhx4ooVKxQVFTU0NDw8PAoL= > > >>C+HaCN0EDQJOU6KV+x5f5Il96DiAKF572bJlmzdvHjVq1IQJE9zd3aETuFOawNuS8LUdEIqCO4V= > > >>CYVxc3MmTJz09PS9evKikpATdTh/nK85UDocTGxvr5uYGL58wYcKgQYNIJNLo0aOXLVu2ZcsWPT= > > >>09b2/vnJyc0tLSmpoaNpuNZ2BFVBBieatbzwBES0HeRXyF8a+rVq06derUjBkzJk6cCPnaKfcXa= > > >>0vC1zYBkQCSpqGhwcTEZP/+/YmJifb29hoaGhkZGWKEIDBa4OppWVkZrPG5dOlSaWnpESNG9OvX= > > >>T1paevv27efOnXNycoqNjS0pKamvr29qamq9Hhd7wNZ0xPHeEzprNOBnyFdXV1c7O7tnz57BKcL= > > >>Dw0NizxJHd/IVeZXg3/j4eA0NDUdHx7q6utDQUB8fHyqVKhTZvPANTFAW8ng8Mpn8+vVrb2/vY8= > > >>eOzZw5c8CAAQMHDpw2bdry5ctVVFRcXV0LCwvZbHZTU1Onr987Hejthf/C/Fl1dXXv3r3bsGHD5= > > >>MmTJfrre9DN8hUZs4RC4Zs3b9zc3GBOl4aGBhaLhWZk6CbFxWpBQYGjo+OJEydWrlw5derUgQMH= > > >>Dho0aMaMGbt37/b09ExLS8vJycG1UoClXe9S9ebzICa5oSkXdru4uFhZWXnatGkeHh5d0XMJX9s= > > >>K3AYEtU8ajQaDWpBAhWzGg01LS0uDgoL2798vLS09aNCgvn37Tpw4cdWqVQYGBv7+/nAXOFowiS= > > >>3ku+IpOhG4fiwQCKqqquh0ekFBwYYNG6ZMmXL9+nXone7cRiV8bSuQUOHxeAwGA0pQoVDI5XJfv= > > >>37t7+9PJpMRm2Fwqr+//8GDBydNmtSvX7++ffvOnDlz+/btDx48KCsra2hogHowgb0JkPqtDVJd= > > >>8TgdhFC0jwM+L51Ot7CwcHJySkxMVFJS+vHHH83NzblcroSvLdD9+kBzc3Nubu7NmzdhsJ9AIGA= > > >>ymXZ2dhoaGpmZmVCmvnv3ztHRcceOHbNmzRowYMCQIUNkZGTOnTvn5+dXVFTE4XBwWyl08CIvF0= > > >>7Qr5avQmw7IeRrYmKivLz8xo0bg4KCVFRU+vXrd/LkSbhY7NymJXxtB4RCYVNT05MnT86ePfvmz= > > >>Rv4U8H93Bs3bkxLS6uvr4+NjT127BgMiRoyZMicOXMuXLgQExODdkGK2aGQq0z4AVvYV0hZXH+F= > > >>gxAQEDBjxgx5efmAgIDNmzf369fvxIkTEr6Ko5vlK0EQFArl33//DQkJaWhogFRjs9lWVlbr1q1= > > >>zdXU9d+6cnJzc0KFDBw0aNG7cuJ07dwYFBdXV1aGu4n1rYz+/Qr4SLe0DAICMjAwFBYVly5YFBg= > > >>Zu3ry5b9++Ojo6XbHFQMLXdkAoFMbGxl67dq2oqIgQebm4XK6dnd306dNnzpw5dOhQEok0bdq08= > > >>+fP+/n5ZWdnw7VXV3hBvyzEFoUsFsva2lpbWzssLExZWbl///7a2tpdscVAwtd2tMXn8589e+bg= > > >>4FBVVYWsTkVFRUePHoVe/vHjx+/cufPp06cwUx/aOPD1L/bbBTF7FnwbqVRqfX09rHc8cOBAbW1= > > >>tiXwVRzfzVSgUlpeX5+fnw5Uvl8uNjIzU1NScOHHid999t3DhQmtr69LSUmTnF2IRg13RpS8F3J= > > >>KF1G5kv1NWVu7bt++JEyfgyrJzm5bwta0QCoUweQn0qSYkJNja2q5YsaJ///5SUlK7du16/vw5l= > > >>UrFL0FM/Sb1AZQbAa4aKysrGxoaioqKoH1AV1dXIl/F0W18BQAUFhYGBgbC/FCRkZHr1q0bNmxY= > > >>//79f/vtt8WLF3t7e8PlMF5dTYhtaPn2+IrsWUKhMD8/X19f393dPS0tTVVVtX///hK+vgfdw1c= > > >>49d+7d8/JySk/Pz8wMHDlypX9+vUbMWKEkpKSh4eHtbV1aGgoXF4IW+Lbk6wEpr8i+0BMTIyCgs= > > >>KVK1cSEhKUlZUHDBigo6Mj0QfEAXWm58+fy8vL37x5E/K14xTB5SL8NzU19dy5c3fu3LGwsJg5c= > > >>yZcWllbW5eVldXU1Li5uQUFBcEcLUS3J+z4IoCDg5Jo02i0M2fOqKurh4aGqqurS0lJ6erqSvxb= > > >>4kB8Xbly5Y0bN9Ce944zBm2ogtqqq6vr7t27NTU1p06dKiUl9ffffzs6OtJoNABARUXF2bNnHz9= > > >>+zOFwvklp2hr41AG3slEoFC0tLXl5+bi4uFu3bv300087duyA5Xo6t+kez1eCIOLi4g4fPhwaGs= > > >>rlcsUqSX82kA5aWlp6+/ZtBQWFH3/8cfjw4X369FFUVHz+/DnKbVZUVKSjo/PgwQPI12/MFPBe4= > > >>Bo5HITCwsJdu3adPn2aQqEkJCRMmjRp8uTJT58+RaaSzkKP5yubzfb09Lx8+XJJSQkhypzfwfUN= > > >>ol1NTY2RkdHEiRP79+9PIpEGDRq0bdu26Oho5P0nCKKhoSEmJgYauXAt4psHrsKyWKy4uDhYLC4= > > >>+Ph5u6XFzcyPel120I+jxfKXRaPr6+np6etCGj6KqO3JboSgO68aNG5MmTerbty8MBjh48GBubi= > > >>4yAoiZHr9VU0Br4KvJ1vvFExISpk6dOnr0aE9PT0LCVxwAACaTeevWratXr0JDvRDbzPTZt4U3o= > > >>VAohw4dgpJ12LBh+/fvz8vLA1gEIAx7bW5uZjKZHA7nGzYItAZiKvzb1NSUl5dXXV2N+DpixAi4= > > >>xaBb+SoUZY7+CMQsOPi1QswLgr4SOy7WHP5tW3rPZDJdXFyMjIxKSkrQ5W3nK66HIcLB49HR0cu= > > >>XL+/Xrx+JRFq8eHFERASuBkCmEgRBo9ECAgLS0tJgPGiv0l/R9JKRkaGtrR0eHg4AiIuLmzRp0n= > > >>ffffcF5KtAIOBhaG5uRh+QpOHxePhGEfTa4YH3+FyJTkCsEn4Abek9lUo1MDA4ffp0aWkpgZmi2= > > >>vj86Hzo6+fz+TAqnkwmnzt37ocffiCRSBMnTnRwcIBjhF8If6qysrLTp0/7+PigUnW9Qb4KsexM= > > >>AABfX98lS5b4+fkBAHJzc+Xl5b///nt3d3dhZ6d4+bQ+UF9ff+PGDWNjYysrq3PnzhkbG5uZmV2= > > >>5cuX58+cVFRUhISEpKSko1Bz9xX9+IeZGF4iynkOWE60seUR7OAcAqKur271796FDhyoqKpA+0K= > > >>4hwF8klGolKioKlqEjkUg7d+6EyvF7O1BaWqqnpwftWaArS099VcBlEADAx8dnyZIl/v7+AAAOh= > > >>3Pt2rXvvvtOS0sLjlsnDsin5Wt4ePjatWtPnTp1/vx5aWlpVVXVa9euLV26dM+ePc+ePTt37ty/= > > >>//6L7zQXirRvvJeQ0PAnR/MmZDPuhhablNvS+7q6uj179hw5cgRV0mnvEKAXBoVTUSgUfX390aN= > > >>H9+vXb/bs2Q8fPvzQViQAQHFx8alTpx49eoT7t9rbh54FsdkSAPD06dPVq1cHBgZCfcnR0XHIkC= > > >>GLFy9OTk7uPr4CABgMxuXLl3fu3Jmdnf3s2bPff//94sWL7969O3PmzIYNGwICAgwMDDw8PCgUC= > > >>sweBQCAdETGHaQtEATBZDIbGhoQL3EGtFaF29h7Mpm8f//+w4cPQ/kKj7drgISilZNQtNvTx8dn= > > >>8uTJJBJp2bJlAQEBHymQBACoqqpydXWNjo7mcDhtb7RHAxcu8EhVVZWHh0dycjJBEDwez9bWdsi= > > >>QIbKysikpKd3K14aGBnt7++vXrzc2NoaGhv7+++8GBgZVVVW3b98+ceJEZGTkqVOnjh496u3t/f= > > >>Tp0/T0dLgHv7a2Njg4GBaTCAoKqqqqgvvvnj17FhYWVllZCYUrlUotLy9ns9nNzc3V1dW1tbVoM= > > >>1Pb9de6urq9e/cifaC9Kx5cz4bvW1lZ2aFDh/r16zdmzBhnZ2foVPxQfwAALBYrLy+vtxXfwidD= > > >>qPLBnOAEQfD5fBsbm0GDBi1dujQpKalb9YGmpqaSkhJYRDgkJGTBggXm5uZUKrnPbZ0AACAASUR= > > >>BVLW0tDQ1NTUrK0tTU3POnDmmpqYeHh66urqBgYEsFiswMFBeXn779u2nTp1SUVF58OBBTEzMtW= > > >>vX7t69e+fOHTMzs7y8PB6P9/DhQ0NDw8LCQgqF4uLicvPmzdraWtStNvYeyVfo/RN77z8JpLPCC= > > >>7lcrpeX18yZM7///vsjR47k5OQQoti5D92z9VzRGyDEjK8CUdQLyidiZWU1ePDgZcuWdas+gM6A= > > >>CAkJWb16tYeHB3Q8AgDKy8uPHj2qoKDw/Pnz2NhYeXl5BwcHBoNx+/btCRMmKCoq+vr6ent7BwY= > > >>GXrhwQU1NLSEhITIyUlFR8fbt2wwGw8TEZOXKlenp6dXV1ceOHTt58iSsJIH02o88J9L0yWTyvn= > > >>37Dh48WFZWhoamvfYBgShUoL6+/vjx41JSUrKyslFRUTD7n1iCbDE0NzdDP3DvKcaJ1qboSGNjY= > > >>1RUVEFBAUEQfD7fzs5u0KBBy5Ytg+WP8ZV0B7n7afsrOi8kJGTt2rX37t1DCXNKS0vPnTtnampK= > > >>o9FSUlLk5eUdHR0ZDIabm9tvv/125swZeN/IyMj169efPHmyvLy8qKho3759xsbGVCrV1NR0xYo= > > >>VaWlpVVVVx44d09PTKy0thQWrUlNToYP+40OG1luHDx9G/oJ2DQqUB0gZyM/PX7du3ejRow0NDW= > > >>ENLSG20f69d6DT6c+fPy8qKuptfEXjDAB49erV9u3b0XrL2dl5+PDhy5YtS09PB1g1h27l65MnT= > > >>xQUFP79919ogiUIoqCg4OzZsw8ePAAApKSkrF692snJicVi3bx5c8mSJb6+vlAEhoeHq6mpwYjm= > > >>jIyMHTt2WFpa0un0q1evrly58s2bN4WFhXv27NHV1S0qKioqKvL19Q0NDa2rq2v9bGJ0BADU1tb= > > >>u27fv9OnT5eXlrU9oC5BwpdForq6u48ePX7BgwcuXL8XG90P6a2VlpYWFRWRkJMqg0XsUWaj6Q3= > > >>vWokWL/Pz8CIIQCoVBQUHz5s1btmwZ1F/F7D8dafHTfIUv07t37wwMDBYvXgz5CrXssLAwVVVVd= > > >>3d3Ho/37NmzJUuWGBsbl5eXW1paLly40NfXF/HAwcHBwsLi+fPnBgYGcnJyvr6+bDbbxcVFUVHR= > > >>39//8ePHK1eu1NbWLisr43A4dXV1FAoFpaD6eO/r6upOnDhhampKJpOJ9s848HyogURFRcnJyQ0= > > >>ePPjIkSP43T5SkFYoFObk5Njb28fHx8PVRi/hK673AwD8/f2XLl0K7a8AgLdv327btk1GRiYiIg= > > >>LNTsKWVvbPw6f5Clchr1690tHROXTo0IsXL6BWx+PxAgMDjx8//uzZMyaTGRgYuHfvXjs7u+TkZ= > > >>BcXl/379//3338oOVRqaqqFhYWJiYmWlpaxsXFhYaFAIEhLS7t8+bKdnZ2Tk5Ourq6bmxtM6YNs= > > >>W+/tj1DkPoUjRSaTtbW1r1y5Ul9fT7Q/WBvpwTU1NefPn//uu++mT59+7949+Iwfj/aCxruEhIR= > > >>Hjx7V1NQgEdL21nsu8GGBPtht27YFBwfD366kpGTnzp0///yzra0tlUpFfhxhe1zl78Wn+Qpnfx= > > >>qN9vbt2+LiYjqdjgz+ZDL53bt3dDqdy+VWVVXl5uaWl5fX19eXl5fDkg9QbYCMLysry87Ofvv2b= > > >>V1dHfxRuVwu3G4K1YC6ujoouYUf9m+15iuFQjl//rybmxvMSPXZwxEfHy8rKztkyJAjR44UFxcL= > > >>Wu4T/NA9BQJBVVVVXl4erL7ZnaXBvyzEfiMGgxEeHp6fn08QBOSrhobGpEmTrl+/3tDQALBCYl3= > > >>OVwGW1wm+PUi8w3/R0hjJRdxuj0MgCp0hROlUQUugpfqHHgm/GzxSVVUFq05+nOgfAryKx+N5eX= > > >>mNHz9+3LhxDx8+RI4u/JyPXN4pQbc9CIgVgpY1baBvCADw7t07DQ2N2bNno20X6KoONv0JvuIGN= > > >>ry7hGjHCGi5/wRJI1xrQUwisGT7iFg4UwmCgEWh2shXgUAQHx9vYGCQlZVFtG2xJTZlw5MrKyuP= > > >>HTs2ePBgGRkZmNad+LBMbT2Cn/eq9Fygx0R85fF4LBYLTjKQrzt37hw7duzVq1fFPCkdHKJP219= > > >>bA1/uoYz6+Goa/cWZKtZjMSrjnz/5wyOiC4VCPz8/PT293Nxc9NWHlEj8/vjz19fXu7m5ycnJyc= > > >>nJ3bx5k8FgtN3439zcXFRUlJeXh4pdtfHCHg1cXhAEAQnq6+sL0zQRBFFZWamnpzdt2jRDQ0NYh= > > >>ZlomzT5JNrEV5xGYjMgi8WiUqlI5hOtRGBr2YN/hX5j3HT6yR8engYvcXFx2b17d3Z2tpgS8qGr= > > >>Wj9UaGjowoULpaWlL168WF1d3XYzKgCgsbHx1q1bjo6O0J7QSyAmmKBtXlVVNTQ0lCAIgUBAo9H= > > >>Onz//008/nTlzBvosO4WsRBvtWUQrcYi+zcrKunfv3tu3b99L0zZCIBCgctSffDD0LVSdTU1NN2= > > >>zYAO3SYn345OMQBFFfX3/58uURI0ZMmjTp/v37KEynjWPHYDBMTU2NjY1hEkLiw2/LNwZEAyg4H= > > >>j9+/Pfff8P4V6FQyOfzzc3NhwwZsmnTpoyMDFzSdbDdNumvRKvIf6FIxY6KitLS0goJCYEKK55x= > > >>F6ejsJVwRfOyUChsaGjIycmpq6sDIh/0h55N2FLx4PP5FhYWKioq6enpeEMf4auYMpCdnb1ly5Z= > > >>+/fqtWrUqPT1dIGiHDwby1dLS0traGmYiEvYaLRb/laG/YOHChdBfAGFnZzdw4MApU6Y8efLkve= > > >>WePw9t1V9RG2jPNIfD4fF4z58/37Fjx61bt+Def7R4QnYA9AEJxdYoLCz09vbOyMjA9/F9RAcVi= > > >>ra98/l8a2trFRWVtLQ0dMJHjKA4nwAAbDbb29v7119/HT58+MWLF+vr64XtWcMCAFgsVkBAQGho= > > >>KEyW0XvIii/EAQCxsbEnT5589eoVOgj5OmLEiLt370KzJrq2O/gKAOByuQUFBbACeU5Ojq+v78u= > > >>XLxMTEw8ePHjx4sXk5OS3b9/W1NTAUJX6+vri4uJ3797l5+cXFxdD4yiNRisrK6PRaDwer66urq= > > >>ysDNZACw4O1tbW9vX1pdFoH2cMEthovIKCgo4dO4bXvvoIXwmM8QCA2tpaPT29oUOHysrKRkdHo= > > >>0CCtg9fc3MzhUJhMBhiJrBvG0LRGgM9b0NDQ3FxcWNjI4oNCg4OnjVr1qhRo7y8vKDdAF3bkabb= > > >>ut4iCCItLe3s2bPXrl2zt7c/fPjwzp077969m5OTc+DAAVlZWbhh5uLFi/B29+/fP3LkiK6urrW= > > >>1tbGxsb+/f2NjY0pKyuXLl//777+6ujp/f//Lly8nJSXR6XQ3N7d169Zdu3atoKAAOSM+IiPRMw= > > >>MAKioqrKys0FT+kUcV00kAAG/fvt2yZYuUlJSOjg5cMH2c6x8aQYDFhfUGyoqpXoKWZnX4b1VVl= > > >>Zqa2vfff//w4UPI105Rlj693oI/IYVCMTY2Xrhwoaur6+3bt2fNmqWkpPT69evy8vL9+/cvXLjw= > > >>zp077u7uioqKZ8+eLS4u9vDw+OOPPzZt2vTw4UN9ff1jx47l5uampqauX7/+1KlT1dXV//3337p= > > >>16x48eMBkMv38/Pbu3evt7Q29mm1/MAAAlUp1cnLC9YGPKK+4iZsgiNDQUFhT2M3NDYYrtFe+8v= > > >>l8uFLE7Sdtv7yHApGPEL3hLBYrPj4ebvmEJk46nb5r167vvvvO0dER6ordx1cAQHl5+YkTJ/744= > > >>w9PT08fH5/Zs2erq6sXFxdXVVXt27dvz5490Fu7d+/egwcPlpSUZGRkbNiwwdDQsLKy8vbt2xs3= > > >>bnzx4kVhYaGampqurm5dXV1ISMiGDRsePXrU3NwcERGhp6cXFxcHpxJhm7120Hrq6OjYFr4Solh= > > >>VOMRUKtXIyOjHH3/csGFDamoqWsC1a73FZrMjIyNfv36NUs31EhMshEAUq56cnHz48OGwsDAgcn= > > >>CSyeQdO3b069dPTU0NbV1u1/LgvWiTPUsoFMLtADDGMSIiwtDQMDg4mMlk1tbWnjlz5tq1axQKh= > > >>Uwma2lpwa0phYWFW7ZsMTMzY7PZDx8+lJeXDw0NLSgoUFNTO3nyJIPBiIqKUlZWhovH8PDwM2fO= > > >>wFh0AvNHtKX37eKrQFTgisvlPnjwYO7cufPmzfPy8oI7tNC1bedrQ0ODtbU1jOogsJqdbbm8RwM= > > >>fLgCAv7+/rKysr68vsoJTKJTdu3eTSKR58+bl5OSATtpl0FZ9AAAQERFhYmKSkpLy5s2bnJwcuB= > > >>00JyfnyJEjNjY2dDq9rKxs7969u3btqqioKC4uVlNTu3DhQmFh4Y0bNxQUFKKiooqLi7dv366lp= > > >>QXdIcuWLTtz5kxNTc2LFy9OnToVGhpaXFycl5dHo9Ha3vt28RV9W1paum3btuHDhx88eBAGegtE= > > >>e9DbPqyQrxYWFqampvX19ehl6A18xZUfAICvr6+srOyTJ0+QFZxKpe7atYtEIv3xxx/Qm9MpKtO= > > >>n+YoCGmDYtbq6uoaGxqFDhwICAthsdlJS0oEDBywsLOrq6tLS0vbt23f48OG8vDxYl3HFihUaGh= > > >>pr1qy5ePFiRUUFi8Xy9PRUUVHZuXOnqqqqtLT0X3/9lZqaWlRUdOnSpY0bNx4+fDgyMpLJZLZx1= > > >>mgXX9F8JBAI7t69O2nSpGHDhp0/fx4lccdlRhtbZzAY5ubmV65cgZGQ7VInejqQug9E8a8+Pj5I= > > >>vjY0NOjp6Q0cOBDxVYjhsxttR/wALK20ffv2rVu3zp8/f+vWrbm5uQwGIzc3t7i4mM1mk8nk5OT= > > >>kzMxMGo2Wn5+vqqqqqqp69OjRK1euwDRpUA338PDQ1tY2NjbW09MzMDAoKSkRCARxcXGnTp06e/= > > >>ZsQUFB25+qXXwViILhORyOvr6+lJTU5MmTPT09PzvOGvpj7e3tLSwsoJe89ygDuMsK6q+HDh0KD= > > >>Q1F+ivcFj916tTZs2fDX7879AFC5MCorKzU19fX0dFJTEyMiIhQV1eXl5dPTU1FNn+ipS8ARpgb= > > >>GxtDKiO9ENpx6+vrmUwmjUarr69HFaoaGhqoVCpuq2tL7ykUioODQ2ZmJvEpASkUrR3T0tLWrVs= > > >>3YMCAzZs3wx2wnwf4LGlpaWlpaTDfW+/hq9hjslistLS08vJyJEcBANHR0X/88cecOXPy8/NB+7= > > >>fWvRdtWm8BAEpLS83MzPbu3WtjY3Ps2LFVq1adO3eurKwMnibAAACA22NUVVWtrKxgeDnAInRa+= > > >>7eIllxvV+9by9cPnQxbp9Pp9vb2EyZMGDx48JkzZ+BW9ba3KAakreJZaj77bj0IiHnIRABaBmEB= > > >>AKKiombNmgVdsk1NTURn2E/atN4iCILP5zOZzJiYGFdXV0dHx5CQkLq6OhirCi2aeF43JpMZHR3= > > >>t4eGRlJQEs6ARHXZsfKj3FArF0tIyMjIS7U340Mnwq8zMTFVV1QEDBvz666+PHj3qeE0I3KDbe0= > > >>IK0ZPCX5xOp+fn5+PuSQDAy5cv//rrr4EDBx47dgzmzu8OvsJshELRShA63JAsFLbcgIDEjFi8N= > > >>tF5EWViva+rqzM0NHz06BGTySQ+FT8gEAiePn06b948KSmpAwcOwPmrIx1obm7Ozs7OyMhAtXt6= > > >>iT6Au3UgNXV0dF68eIFOAABkZWWpqqoOHjx4165dkGEdH5xP8BXJTpQODUl+ARZVKBZUhb5CJgx= > > >>0Zqfztb6+3sbG5sWLFyjn3IdaAQCQyeTz58+PGTNm3rx5T58+hZsKO9I6k8m8ffv2jRs3YBR9Lz= > > >>FmEe+zv65cuRLu4EcH6XS6iYnJhAkTUO2NLpevAixaSiDasgP7hL7iYxXSCMzMgV/VRTucAAA0G= > > >>u3ff/8tLCwEn/L4CQSCly9fbtiwYdmyZTdu3KDT6UTHxCG0D1y/fh3erfc4C4iW+bMgh9TV1Z8/= > > >>f05gOj2Xy/X29paVld26dWtsbKyYM/zz8Gl9AP1FIpbAdpwJMRCYvoueB2f5Z/dSrEu4Uk+lUt3= > > >>c3PLy8sS+xf8lRLZ9ExMTaWnpLVu2wP1eRGfw1dnZ2d7eHu0m7w36q5jZHwAQHBy8YcOGkJAQfN= > > >>XF4XCcnZ0nT548Y8aMW7duIbthR5r+tD0LoTUPWreNE1eMyp0CIWb5g8woKSm5evVqXFwc8k7hL= > > >>eLr95SUlG3bto0aNUpLS6u0tLTjHQMAsNnsp0+fPnnyBO5aFnbYP94jILYygfbXK1euoOyZEDAl= > > >>irS09NixY52dnWG90u7j69cA/H0gCILP58fHxx85cuTBgwcwYlpM2BMi3Z9KpcJ8y/PmzXv48GF= > > >>nVULk8/kUCoVCoaBInd7AVwghpn2h+FchVhagubk5NjZ2yZIl48aNc3Bw6JRysj2MrxA4KfPy8g= > > >>wMDGAuQZx8cLzgZ+i/kJWVHThwoJ6eHtT9O0v2wwUoztdOnE++ciCpIRAIeDwejMnE9dq6ujo1N= > > >>bXRo0efOHGisrKy4y32VL4SIsFJJpMdHByys7OJljxGNjWCIPh8/oMHDyZOnDh16tTg4GBc+nYE= > > >>kKbV1dU1NTW9KnIAAtfKKBRKcHAw2lWP7Fx0On3Pnj39+/dfuXIlDNrsXfoABM5X6C+Iiop6r00= > > >>NDlxVVdXRo0eHDBkiLy8PLQm4oeOzuwEAYLFYjx8/fvToUUNDQ+9RBvB1AvRoxsbG7tq1C8a/El= > > >>heAjabbWZmNmLEiPnz579+/ZrozvXW1wO0DId8NTc3h3nwCGw4EHW4XC7MDD5ixAhdXV1kKBWzD= > > >>X8GAAAMBsPa2trU1BRu7u0lIha3XRKieMKlS5cGBASIeWUJgoiIiJg0aZKMjEx8fHzHm+6pfEUa= > > >>Un19vbOzs1i8CxKxAICqqqrTp0+PHDly3rx50JHdWaxCfDUxMYHxWb1HeUUrKkLkL0D1twjMmgk= > > >>ASEtLmzp16ty5cyMjIztFB+t5fEVAfE1PTyfel6SDIIhnz54tWLBg0KBB2trasNQH0UleU2jTdX= > > >>R0tLS0pFAonXXbngI0yACAuLi43bt34/oA+grydfz48d7e3qjM4Gejx/MVxhNmZGTAI4gxQtGO7= > > >>VOnTg0bNmz27NkwqUfnts7hcKKiogICAhgMhrAz8vH2FIipBDQaLTw8HNYvwL8FAOTl5S1atOj7= > > >>7793cXHpFB2sZ/MV2gfevHkjJlYJghAKhc+ePfvzzz8HDBiACh51bgeEQmFDQ0N1dTWMDus9fEV= > > >>PilaZKFgPX3dCk5auru748eOdnJw67uns8XylUCjOzs5v3ryBRxBfoTEF5saaMmWKh4cH2lUsdu= > > >>ZnAxIU2l9x/3Pv0QrQwpfH4zGZTBTSKcQMOFwu18XFZcyYMZqamu/eveuN9gEEyFcbG5vo6GjcH= > > >>wu/yszMVFJSGjhwoKKiYnx8PD5/EZ0ULMbn8+l0Oira2PF4jh4BNJLISpOfn+/h4YHKleF8hbmg= > > >>paWllyxZggIOPxs9nq9kMtnIyAi6WHGiAAACAwOnTp06fPhwWD2mc5lKiOyL/v7+Pj4+DAaD6DX= > > >>rLTiAaD6B8S5KSkoo3oXAEvYLBIKkpCQlJaX58+cHBQVJ5CvFwsIiPDwcr+UJAGhubnZ2dh41at= > > >>ScOXP8/f3x3QedyFe4n/vatWsoK29vAL5UgEt+X1/fRYsWQfsrPI6iKwEA1dXVR44cmTBhgr29P= > > >>dTKPrvpHs9XMpl87dq1gIAAVLxUKNogqaGhMXTo0CNHjsB9Zp2uWUK+WlpampmZiWWR7sRWvlrg= > > >>Xhs/P7/Fixej/K+4HQBaaWC6fVhGvVfzlUKhXLly5fHjxyjkiiAIDofj5eU1efLkuXPnBgQEwBx= > > >>Ena5ZQr6amZmZmJhA/xbRO/iKNAHE17CwsK1bt4aHh+NOPiSD2Ww2LMSnoqKSl5fX2/lqZ2eXkp= > > >>IiwGqVZGVlqampjR079vTp06isZlfIVxaL9ejRo//++49Op/ce/xYe/wopW1paGhQUBEv44qchL= > > >>TYmJuavv/6aMWNGQECAQFSm5TPwLfDVwcEB5teGXGlsbLSzs5swYcLMmTMfP34M9drO3eOA0Nzc= > > >>XF1dXVVVhSqN9Qa+Eti+TqSqouNESwMClCCJiYlLliwZNmzYzZs3O+Ll6vF8Fcs/QBBEYWHhpk2= > > >>bSCSSnJxcamoqHDJYo7lzW0erY9BrdsYiIOEqEO3Pa2xshElDiJZRR3CIcnJylJSUhgwZYm5uDi= > > >>PrPw89nq9kMtnR0RH6twiC4PP5fn5+v/32m5SU1KlTp2DRZBiZ0fbCL21vHdYzKiwshPkgehVlC= > > >>azoX2Vlpbu7e0ZGRmvBCflaXV29d+/efv36KSsrFxUV9V75ivMVqgcnT54cNmzYr7/+GhAQgKbp= > > >>rvCUAgCYTObdu3fv3LkD09j0Hn0Af1IAQFRUlKqq6tOnTwG2iU0o2m1KEERjY6ODg8PPP//8+++= > > >>/p6WlASwjebsGrcfztb6+3snJCcYTCgSCoKCgP/74Y/DgwVpaWrDCPNKxOp1JQFQfBsW/9h6+ov= > > >>UWQRAAAB8fH1Sfm8D0VzS5NTc3v3jxYuHChb/88gtaVCBC9yK+UigUR0dHmLGxqqrq+PHjQ4cOn= > > >>TJlipeXF26R7QomAVE+zatXr9bU1IBeE68NgVtYnzx5snTpUhT/iiAUBSILBIKsrCwVFZXhw4fv= > > >>3LkzLy9P2BJtbPQb4SuMd3n+/PmSJUsGDRq0c+fOrKwsfCC6gklQH7h586aLiwuK1+4l8VlES75= > > >>mZmaeOnUqIiJCbOkpEO1KIgiCxWJZWFiMHDly3Lhx3t7eKLlOu4IMezxfyWSyiYnJs2fPampqrK= > > >>2tf/755x9//NHNzQ2GEyBLYRe1zuPx0tPT09PTYVq79kqLHgrcIwCPsFiszMzMiooKdAIesMYXl= > > >>W8PCgqaNWvWwIEDT58+DSPc2xsR2+P5WldXp6WlZWxsHB0draamNnToUHV19ZycHCHmgCG6LPOK= > > >>QCBABfTEAsS+YaBnxNdVsJg8OgcZvJE+RhBEeXn55s2bSSSSvLx8SkrKZwiUHslXfGVKJpP3799= > > >>/4MABV1fX33//ffjw4Tdv3oRGFqJVvpmu6Ay0v+ISpe0NfbxvYgfxf9vbShcNArwhXPVmZWWhzP= > > >>oENtXANFaQtWw229DQEC4w7t27B/fSEe2xA/ZgvgpFGRk0NTW3bt26Z8+eUaNGzZ07NyIiAj+zq= > > >>6Udg8GoqKiA2li75CuSLmJpyHDlDz+Cz5sfmi7wS/ALkR6Jv1RiN/mMFwC5r169eqWrq/vq1St8= > > >>0dm6IT6fHxYWNnXq1AEDBujo6MCUe7ipEX+13vuAPYyv+C8BDdG1tbX79u1bvnz533//PXz4cE1= > > >>NzZKSku4J7QMANDU1BQQEeHt7w/gBYTsNEciRgTMJ/bpiv5ywFd57Q6ii4LVuxD4IW2aVxNtte7= > > >>eFmD4ARPu5UX0YnH/4BwBAYWHh6tWrSSTSqlWroJUAt2fhz/XeB+x5fIV6kkC0mZhMJqurq48YM= > > >>WLkyJHLly+HgbDd0xkg2s9tZmYGazC1V0VGv5ZYepgPfUZHAAaxr+AH/LX5yEE4niiZUtu7jfcN= > > >>AODv7//PP/8EBgai/iCCor/wTFgjaMaMGWPGjLGwsGAwGOgcsWvfi57HV3z2hPrA9u3bSSTSDz/= > > >>8YGpqCp+/28BkMm1tbc3NzeEIEi0LMfQeBAUFycnJQb5+EmQyWVNTc9CgQUuXLoUqRLvw8uXLHs= > > >>NXCNwIQiaTIV+nTJly9+7dju9wbzsAAI2NjVC+ovjX9oLL5RYWFiYlJcXHx8fHxycmJiaJkJiYm= > > >>JqaWlBQkJWVlZycnJWVlZ6enpSUlJCQkNgS6JLU1NTk5OTExMS4uLjExMTk5OSMjIzCwsLMzEx4= > > >>YVJSUnZ2dnl5eW5uLjwzJycnPz8/NTUVv88ngfc2JSXF0tJyzpw55ubm8D4JCQnJycnwEeLj49G= > > >>/SUlJycnJr1+/Pnv27E8//TR48GA9Pb3k5OT09PSUlBR4/se7kZWVdfPmTVglpWfwVYiZSAAAVV= > > >>VVKioqJBJpzJgxhw4dcnR0dHBwcHR0hB+6FE5OTlZWVmvWrFm7dq25uTk82PZ2nZycnJ2dr127t= > > >>mfPHkVFxVWrVikqKioqKq5Zs0ZBQUFBQUFRUVFFReXw4cM7duxYt26durq6srIy/HbNmjWKiooK= > > >>CgqrV6+GV61evVpeXn7p0qXLly+Hd1u1atXKlStVVFS0tbXXrVu3cuXKNWvWyMrKysrK7ty5U0l= > > >>JCV4FS1KuXbsW3q2NWLVqFfwA+zl//vxx48bJyMigzsAHaX0mbGXZsmVjxozp27fv1KlTly1btm= > > >>jRIjk5uTVr1sCng5e/tz9r165dsmRJbW1tj+Er0bJ8UkBAwOzZs6E+8Ndffy1atGjhwoULFy5c1= > > >>C2QkZGZNWvWrFmzZGRk2tv0woULZWRkVqxYoaura21tbWdnZ2tra21tbWNjY2lpCcvS2tvb37x5= > > >>09nZ2cbGxtnZ2VYEGxsba2treI6tra2VlZWVlZWxsfHq1asPHjxoY2Njb29/5cqV3bt3nz171t7= > > >>e/tChQ/r6+lZWVvv37//111+nT58uJyd3+fJl+ILt379fT0/Pus1AraPPDg4O169ft7e3t7GxQd= > > >>2DH+ARKysrS0tLGxEcHR01NTVHjBhBIpFIJNJPP/109OhRS0tLOzs7eE+8CRzOzs4nTpzoefIV6= > > >>gPNzc0BAQE7d+7cuHHjjRs3YmNjExIS4uPjX79+ndAtgHMimvXgLNn2a+Pi4tLS0mpqajgcDsyf= > > >>yuFwmpqampqauFwul8ttwoD+hR/QmfAzh8NhMplFRUW1tbXwYGNjY1VVFZlMZjAYtbW1dDqdzWb= > > >>X1NSkp6cnJCTk5OQwGIzm5mYWi1VeXk6hUFCjnwTeLjxCJpPj4+OLiorQU7z3QdAHWFfn6NGjI0= > > >>eOJJFIR48eLS4uRnf7SE8AAOHh4T1Gf0XmGPgBhglXVVUVFxfznEmINwAAIABJREFUeLz2au4Sd= > > >>Baio6PV1dXR/i2ibevOyspKY2PjrVu3+vr6Qi62Bc+fP+8xfIVA9kKUHw8CkbjtpplvD8h4gm9T= > > >>+cjJn9cK0seIlvZXolU1jvcCVXFjsVgNDQ1tL8IKepw9C5EVl7WgZVo8CWXFfAEfOfPzmkDFiQh= > > >>R/CuqJ0+08syJtQhfJGhHR7IGP+EbtL8KROnexegLgeou9TagVxfX8j/uxfgQsT4OfMAhXxcvXu= > > >>zv70+0DM56b3PNzc0wcgCRvu1blXoYXwUta9YJMRe8QBTH/nk/wJeC8MPOqs8AvAkUXWjLmvCjH= > > >>k78PW9jK2Ief4IgYmJidHV1X79+DbDUdx+6oVAUBMPlcj9Z9bf1A/YkviLnFj4ireXrl+5m+0Cl= > > >>UhMTE1+9egVTJYh9iz8R/q3YmVB9Ly0tDQsLe/78OdyDKibnPq4YtH3c8JGHrTCZzPr6erw+DNJ= > > >>uP3QHsZ+yjU33ML6KjVSPBppM8/LyDh48qKam9vr1a/hcKAgGSkr0sIgKeIFp9KsLBILw8HB5ef= > > >>mTJ0/C0KdP6q8d6Tn6AJtgsVgcDgcP1umK36iH8fVbglCkWTY0NJiamhoZGZWWlsL5FNEUupdx6= > > >>wcitFCU1g4xEgBQXV2tpqamra1NpVKFog3uXfRuo7cFWqbu3LmTlJSEvu2i1M0Svn5JQCaxWCwr= > > >>KytTU9OamhoCi8yHOmhjYyOVSqXT6TDEls/ns9lsFovFZDJhfgoo0rhcLpPJLCgo2Lp164kTJ7q= > > >>6ni3+8gAAwsLC1qxZA/cbtkUf+GxI+PolAX9aBoNhZWV19epVWAEQ/dIMBuPevXsXLlwwMzMzMD= > > >>AIDw9vbGyMj4+3sLDw8/O7c+eOl5cXTAiSmZl5+vRpTU3NgwcPzpw5U0dHp6v3P+KrBWgfWLhwI= > > >>dzPjexcXaESSPj6xSAUpZNvbGy0tbU1MzOD+/XQJJuUlLRmzZpz5869ePFix44de/fuTU5Ovnjx= > > >>4vbt29PT02/evKmkpOTj48NkMp2dnaWlpffv329lZTV//nwdHR24NaWL9Ff8EYSi+Ndly5ZBvgp= > > >>F9kQJX78p8Pl86IRksVi2trampqZQvkKJm56efvr06Xnz5nl7e7NYLG1t7fnz5wcHBxsZGamoqE= > > >>RHR1+/fn369OmXLl3Kz8/X0tJasGBBcHBwaWnpzp07T548CePHu8dgAgDw8/NbunSpj48P7i/oo= > > >>rYkfP0yQMKJzWbb2NiYmJhUV1cDAPh8flBQ0J49e/7444/Zs2c/ePCATqcfOXJkxowZT548MTMz= > > >>k5OTu379uqmp6fTp0y9evBgXF7dhw4Z169a9efOmvr5+586durq6MD9SF5FVTM0AAMTHx+vr60P= > > >>7a6c3h0PC1y8MAEBDQ4OJicnFixdhHvD8/Pzdu3fPnTt327Ztc+fOtbKyKikp2bdv39KlS93d3V= > > >>VUVBQUFBITEz09PadOnXrmzJn8/PwLFy789ddfd+7cyc7OhiGzVVVVXae84neG70NjY2NJSQksQ= > > >>obOkdizvjVA+VpQUHD06FF1dfWUlJT6+npLS8spU6aoqKj4+flt2bJFXV3d2Nh4xYoVOjo6L168= > > >>OHv27D///GNkZKSrqztjxoz169cnJibGxMQoKirKyMgcOHBg/vz5CgoK4eHh0BraRXYl3PIqxPI= > > >>PIA2kO+wDfd6HTm9SAghkXq2vr3/48KGnp2d5eXl9ff2dO3e0tbWfPXtGp9NDQkIMDQ1PnTp16d= > > >>KlxMRELpf77t07MzMzfX19R0dHGKP95s2b2traW7duHT9+3MrK6sqVKwYGBtHR0TDFJzTQdkXnh= > > >>VhcUUFBwePHj/Pz8wnRpt/OUkXE2AhzbUj4+gWA1tEAABikDM2odDqdQqHweDzoYa+tra2oqKBS= > > >>qTCaSSgU0mi0qqoqOp1Op9PJZDK8lkKh1NXVsVgseJDNZnedkEP9R/bXoKCgDRs2oHya7d1w+xF= > > >>I+Pq1QCjaSy0QRZESouy+yIopFgoDhaXYQch7olWINNGVzi0CMz5A++uCBQtQ/gF0QsdbkfD1Kw= > > >>JymcJ4Jdwz9N44Sfy01t+icz4ZIdVZnUdvmpj9tROFuoSvXxFwPuErlfeeib7CqYlIibOzS9UAv= > > >>Ank2ggICFi9ejXiK3pnOt6QhK8SdALwqQAAkJ6ebmtrCxO9o/VWp2gjEr5K0FEg2yqiI4fDoVKp= > > >>MP4VSfpOMcF+jK8dvLUEvQRiyjHSYtFKkRCF8HZ60xJ/gQSfCaRDQxNyenp6cXExi8VCIS+SeEI= > > >>Jvi4ge1ZcXNy+fft27dp1+/btyspKtC7s9BYlfO0okLGztwH3Fzx58mTatGl9+vRZsGBBWFgYtA= > > >>dL5OvXiC4NMP1qgUfWQvvrtGnTSCTSL7/88vDhQ8hXiXz9ugD9qG/fvoXBUF+6O90HZMlC+TJCQ= > > >>0Pnzp1LIpEmTpzo4+MD4yIkfP26AABgMBghISFpaWmofsGX7lR3ANkHUPzDu3fvduzY0adPn8mT= > > >>J/v5+cFcZl3RtISvnw8AAI/HKyoqqqur69JNzF8hcJcvAKCmpkZTU1NKSkpOTu7Vq1ddl19Hwtf= > > >>PB/q1AJZ4v5fwFZUogiMQGxsrKys7ZMgQLS2tqqoqQpJ/4OsEj8erq6trbGwUiz750v3qcuCbzq= > > >>F9YPr06YMHDz579iyNRgMti591IiR8/XwAAJhMZkBAQGJiIp58rpfwFZevT58+nTlz5uDBg8+fP= > > >>0+n04XtzDLUdkj4+vmAW6/s7e3v3LkDRWzX/U5fG/DwK8TXIUOGGBoaSvj6lQIAQKfTr127Zm5u= > > >>Dqv39gamEq1S0AEA/Pz8Jk2a9PPPP9+8eRO6ZCX5Xb46QH3Az88vODiYwWD0Hv21NV8fPHjwxx9= > > >>/KCoqxsXFEVjGyE5vWsLXDkEgENDpdCaTiZjaS/QBAqtgyOFwrKyspk+fvmfPnqysLCaTibK6St= > > >>ZbXx2gPQt6enoJWXEuAgBycnKUlZW/++67M2fO+Pr63r17l0wmE12ze0zC1w5BICouLLaV6kv3q= > > >>2uBnhEas8LCwqZNm/bjjz96enqamppu3LixoKCAkMS7tAXdSRcAAJvNTk5OfvfuHZKvvUTEEqLc= > > >>/ACAR48ejR07Vlpa2tfX9/Lly3Jycm/fvhV26q5DhB7JV1xZJDCO4kb7bugGtGe5u7u/fPkSesz= > > >>bVTqi5wKOMHxSFotlb28/cuRIaWnpR48eGRkZrVixAibOkKy3WjASbm4mWm4nQvNUN1AW2rOuX7= > > >>8eGRmJitj3Bn0A3xmbl5e3bdu2fv36/fDDD/fv3zczM1u9enVubq4k3oUgsJwo+HQDVzzdyVTUL= > > >>p1Ov3XrVlRUlFj2qO7pwJeCUJTpo7m52cfH5/fffyeRSGPHjvX393/69Km+vn5ZWZkknpAg3qcJ= > > >>CESFuPAcON2mD7BYrIiIiMzMzK7bAfIVQijaq81gMK5cuTJq1KixY8cqKyunpKRQqdT09HQ2m01= > > >>I9AGiZVo8+C+LxUpKSqqtrSVaBrl1T3/4fD6ZTIbOWKJ3KAMERsSsrCwlJaU+ffqsWrXqxYsXcB= > > >>xQupquaLoH8xXqT+np6RcvXoyPj4dk7f7Khkgb6SXKAIHtLwgODp44cWLfvn21tLTIZDKPx8vLy= > > >>4uLi0PRFJ3edA/jKwSuEnh4eCgoKHh4eMBkud3MG6FQSKPRYDJAdKQb2v0iwB9NKBRyuVxvb++x= > > >>Y8dOmzbt2rVrd+/ezcrKunnzpqamZklJCTIgdC56Hl+FWHlYFot14cKF8ePHHzx4ENqou5OvAIC= > > >>6uroHDx6kpaXh8cvfGGXRE+HPBQB4+/bt9u3bBw8erKGh4eLismnTJj8/v8uXL0N7loSvBCHSUJ= > > >>Fu9ObNG2Vl5QEDBvz555+hoaE8Ho/osgy9rQEAKCgoMDQ0DA4O5nK532r8K66DwTBtaGm+devWj= > > >>z/+OGbMGCcnp3v37q1YseLff/81MjJavnx5Xl6exJ5FEAQhEOUdJwhCKBSGh4fLyMiQSKTx48ff= > > >>vXuXxWIRXZz0FAcAoLi42MjIKCQkpKmpCYhKpXVD090GFBYoEIEgCABARkbGhg0bhg4dun79+jd= > > >>v3jx58mTFihX379+/dOmSnJycxF/w/0DLT4Ig2Gz2rVu34Lb3UaNGGRsbw+Jp3dYZAEBhYeGFCx= > > >>dCQkK+1XgXXBlAH6hUqpWV1Q8//CAtLe3s7MzlcgMDA+Xl5X19fe/fv3/mzBlYOETij23hWamtr= > > >>T1+/PjAgQNJJBKJRFq/fn1ubi7RLdlPIQAAZDI5ODg4Jyen6yr6fXEgPQdKCgBAQkLCypUrpaSk= > > >>1q5dm5qaShBEVlaWi4tLZmZmZWVldnY2i8WS2AcIQrTYgpSNj49XV1cfO3aslJTUqFGjFBQUYmJ= > > >>i0Ca47uwPDNEiuvFV6U6grVrIR2BnZzdmzJjvv//+xo0bHA6HIAgOh9PQ0MDlcqEoEUryvUGgKY= > > >>nH4wUGBpqamqqrq8+aNUtfX//u3buZmZkoBWm3dQnfC/pNrrfQVliCIHg8np+f38KFCwcPHqysr= > > >>AzXVTDPTV1dHYfDgf923Xvbw/gKAflaVFSUl5dna2u7efPmhIQEFovFZrO7OTyKx+Pl5uZWVFTg= > > >>xqxvjK+QfJCFMTExmzZtGjx48D///BMaGgrriTY3Nz99+vT8+fPp6enQdNB1cZU9jK9CrBwFHJH= > > >>Xr18bGBhkZmZ2f2cAADQazc3NLTo6GprSvj2yQkC+VldXHzhwYMiQIdLS0o6OjtBBIxAI4uPjV6= > > >>1a9csvv8B6RnAzTBeFVvY8vkJJhoKFKRSKg4NDWloaOqHbOgMAyM3NPX36dEBAACzO9u2RFeqjz= > > >>c3NaWlpFhYWv/zyC4lEWrVqFRSlTU1NCQkJ2trakydPnjx5Ml7PSLLe+n8gyQpf+vr6ekdHx4yM= > > >>DAKrsNM9zi2CIEJDQ9euXfvvv//CfG/fnj2LIAi4tN2zZ88vv/zSv3//OXPmuLm50el0AACVSrW= > > >>3t9fS0jp27JiMjIyfnx/o4tRMPYyveIwpFLSvX78+d+5cRkZGFzlUPgTEVzk5OS8vLyjsvzH7AB= > > >>SuLBbrzJkzgwYNIpFI8+fP9/Lygn4ZgiAaGxvDw8MTExMDAgKUlZVDQkLwQGSJfUA8bROfz7ezs= > > >>9u8eXNqaipap3ebkIP+WCsrq9jYWBRF/s2osJCsVCrV399/8eLFffr0mT9/PowrYrPZ5eXljY2N= > > >>cLslQRAlJSUBAQHFxcVidpJOH4oexldcf4V/79y5s2vXruTkZKQ2deekDO04DAYDr/DbQ/mKqAZ= > > >>lAY/HKykpcXFxmT9//pgxY5SUlAICAmBuAR8fn+vXrxcXFyP3LL4ORp8lfCUIUflntPzMycm5ev= > > >>Uq1F8Ruocx8IdpamqCpYp7omTFZSGKJYKTWFJS0pEjR6ZOndq3b18lJaWXL182Nzez2ewHDx4oK= > > >>yubmprW1taiBQOXy83Ozq6qqhJiVRcl+uv/dmZC+4BAICgpKbGwsHjz5g0Kmu62zsAFcmxsbG5u= > > >>bg/NTyhsuVkDrVaTkpLU1dWHDBlCIpHmzJnj5+cHU7y/fv1648aN6urqr1+/hio7VBtSU1NPnDg= > > >>RFhYGRPW3UB3nzkUP4yt6d9GghIaG6ujopKenE93uDoX66/nz54ODg1GFiZ7CV7yfuOYNAEhJSV= > > >>FVVR06dKiUlNTff//t7e2NqmqlpaXdu3fv7du3eEUNAIC/v/8///zj6+srsQ+IA+eEQCB49OjRw= > > >>YMHYeXS7tQgYXPBwcHLly+/d+8eFDY9KP8APoxC0foVAFBaWnr06NGBAwdKSUlt3rw5ICAAkhU+= > > >>XVNTE/RpEdhaAgDg5+e3ePHiwMBAFFQp7Joojh7GV6FQCONfkXy1tLRUUVHB7QNEN654EhISNDQ= > > >>0Hj16BOVND+IrBD5QAICamhpDQ8MffviBRCItWLAgJCQEkjI+Ph7uyoKnNTc3oxRM8EX19fVdvH= > > >>gx9BfgwVyd3uEexlektsKx4PP55ubmmzZtSk5O/iL6K5lMdnJyioyMhPvxe5D+iiYoociDlZ6er= > > >>q2tPXbs2EGDBh06dCgiIgJarAICArZu3ers7Az5ihZk6HmhCmFiYgKdXvD+EvsrQWDiE9lfLSws= > > >>lJWVxeRr9wDGJcF4l6/Z/ooGDU3TQpFDWyiqF5KUlKSmpgadAjCSGJq0YCD2sWPH8DUlui1Sedl= > > >>sdnV1NYwt7NIR6GF8hUDDJBAILCwsNm3aBPXXL9UZXLJ+bWT9v/a+PK6pY30fq63cVmurfuu9t/= > > >>15tXVptdd6XaoioCJL0SKiVVC0iqCgKCCguOCO4IKgbLKDgEAgIEvY17DKosi+72uAJBBCICTnn= > > >>N8fczN3CEgRCcbW5w8+h+TkzHKeeeedd973HRwxqqBBkdDOShBETk6OmpratGnT5s2bp6amFhoa= > > >>CjwDi4qK9uzZs3fvXhAuP6pKCt8FgKjH7Qe+vhXge+LxeKhiLVbAEJsoTwBgn+JwOCkpKaqqqjN= > > >>mzPi///u/S5cu1dbWwlML6+vrXVxcMjIyoPaFxsahjOzp6amvr4d5Q0QXQveBr2+FlpaWhISEur= > > >>o6IFfEkK/Y8N1RVLL29/f7+PjIyspOnz59/vz5V65cqaurgyMQ3An8JHEk3hCVoPBRmZmZxsbGq= > > >>ampuIhD6j/wdYIAbzQuLk5NTS0oKAhYecTQPoAJQlMgcBwnCILFYnl6eq5evVpCQmLu3LmXL19u= > > >>aWmBjXJzc2tqakK5CwLWgWBGVSBoH9i8efOzZ8+gSvDBPvA/iA9fw8PDN23a5OPjA0KXxFC+4gI= > > >>RC9lDEERTU9OtW7dAaPH333//6NEjGo0GqBYeHi4nJ3fu3Lm2tjYoZdG/I6U14OvGjRsBXz/Ys4= > > >>QhPnyNjIyUkZHx9fUVaRDIBACnY/QCjKX6+noTE5Mvv/xy5syZK1assLOzA6srLpdLoVDU1NQuX= > > >>bpUX1+P5nnAkWUl6iIHNd2IiAh5efnw8HDwFkTXDx/4+lYoLi6+cOFCbGws1F/fOV9RzRJew7ws= > > >>TU1N5ubm8+fPl5CQUFFRSU5OZrFYYNLv6ekJCQkJDAyk0+lAtxFKngfpixYBHltaWuru7l5eXo7= > > >>eIIrWfeDrW2FgYKC6urqzsxM9cmPqq4ECruIxxOUKWAP6+vqcnZ2XLVsmISGxYMECFxcXDDFF8X= > > >>g8FosFFHFMsI84anOw4V5dQEXmcDhcLhdufYlotvnA17cFeNl8UToljR/YcADSgFmbwWB4eXn9+= > > >>OOPEhISX3/9tbm5eUNDA0EQbDabQqGQSKSenh7Qh+OJ9UXVWbjvANVWlMqT28APfJ04QAWYTKaQ= > > >>iecdilgMMY7iSEcxGAwnJ6dly5ZNmzZt0aJFt2/f7ujoAPVPTEyUk5PT1taG9gHIudeNPf4IF8T= > > >>Ozs78/Hxw7JZI9fgPfH0r5OTkmJubp6WlwbXwO1dh4ciBcq66uvratWvffvvtZ599pq6uTiaTOz= > > >>s7gXoQEhJy6NAhMzOz7OxsDoeDrqWghjOyCP7wzTyCIOLj4w8dOpSSkgJeyof9gmEQB74CUQT86= > > >>Dw9PeEO0Lslq9AETRBEdXX12bNn586dO3PmTE1NTdBRADU1NWfOnDl9+nRNTQ36cyG6jyxFSOuA= > > >>9qyQkBD8na+3RqoykBmg2eidQj8Z4/O3aY/48DUyMhLExwL7q0hf1euAdilc/YDr0tJSQ0PDuXP= > > >>nfvLJJ+rq6s+fP4c8xnGcTqcnJiYWFRUJ1RxdS41RLrr7EBISIi0tDfMPvDN9ANYb1h6sImHGYL= > > >>jUgHei5mWUmkLdAY0sE6i0+PA1IiIC+Gu/E/8soXkZ9j+O4zweLzk5ec+ePbNmzZo5c6aGhkZ+f= > > >>j7Yi+JwOO3t7TCFINzBGilWxmgISkqCIGJiYpSUlID9VYgwk4s/4CtsPyi+paUlKSmJTCbX1tbW= > > >>1NRkZ2e/fPmyu7sbVp2PnHgh1GzgEYJ+CGwfE3i74sBXgMzMTCMjo/j4+PEIpEmHkJEVigAOh5O= > > >>WlqaioiIhITFr1qxDhw7l5uaCHuvr6wsNDbWwsCgtLQVGLgLJVzf+ooUIXVNTY2Njk5OTI2pTyb= > > >>jkK7xOT08/duzYrVu3qqqq0tPTTUxMNDQ0qFQqutpA5Ss+fLUI7HNo2ROTRuLDVwaDUVZWBtfFU= > > >>ylfoSgBgOVyOJykpCQ1NbWZM2dKSkoePny4oKAAfMVisaKjo3fv3n3s2LHy8nIhPk2ArzxB1tuh= > > >>oaHOzs6+vj58uDox6V0xLv0Vqin5+fmHDx/29/cfGhrq6uq6cePG0qVLPT094UhFxzr4CYfDAX7= > > >>pOI4DssIxPXImGifEh69w7YLGG05N0egOMCyUTqeHhoaCYzBmzZp18OBB4A1IEASXy01LS9PV1T= > > >>UyMsrIyAAJvwAm9gqgYAJG3K6uLuivzRNZtvE/lq8o+SorK8+cOePq6spgMNrb283MzFatWgV2z= > > >>9lsdlZWVl5eXlVVVV1dHQhMq6mpSUxMDA0NzcjIAOOvqKgoJSUlJSUlMTGxvLwchJG8v3zt7Ox8= > > >>8eJFe3s7jN+aSpUAQ7KHEAQxODjo6em5du1aSUlJIFlfvHgBo64HBwepVOr9+/fBh/hoC7Xxlyv= > > >>E1xcvXlhZWeXl5eEIZ96xPkAQRFdX14MHDy5evBgZGeni4qKsrKyjowNiqV++fKmlpWVhYeHr6+= > > >>vl5VVZWfnq1Stzc/MHDx5YW1vr6OhkZma2tLScP39+3bp1hw4dunjx4s2bN1+8eAFOqhAyNYwNc= > > >>eArIEFSUpK2tnZUVBRQzYWknUiB6h4EQfB4PCqVumXLFgkJidmzZx84cCA3Nxewub+/n81m83i8= > > >>vr6+rq4uYMrARyQfeFO+QtYSBBEeHr5t2zYYz42KucnFuOQrjlCEyWTW1NQUFxefO3dux44dERE= > > >>RfD6fxWLdvXt3165dUVFR0dHR+vr6ZDLZ19d3+/btNjY2KSkpVlZWmZmZfX19lpaWixYtun//fk= > > >>FBgYGBgbGxcW1t7cDAQE9PD4fDGWffiQ9fw8LCNm/ejNoHpmy/AENOF2Kz2TExMTt37pSUlJw3b= > > >>56enl5+fj74qquri0wmh4SEMBgMqICNpOnEhhmsQGhoKPR/xRHPmMlu9PjsA6h5AvhDEAQRGBj4= > > >>66+/+vn58fn8zs5OLS0teXl5Nzc3a2trVVVVLy+vuLg4TU3NQ4cOWVpaWlpaZmVl4TgeGRkJXnB= > > >>/f//Nmze3bduWnp6em5sbEhKSn58Pz3Ece2iKCV9xHI+IiJCWlvbz8xOpfEXHAOwfviADLo/Hi4= > > >>2N/eWXXyQlJVeuXGlkZPTy5UvQPwMDA+BkLDMzs+bmZkKw3fqWNYRthIoimUzetGkTylcRzTPj0= > > >>gfgfklnZ2dMTEx2djaO49nZ2bKyshoaGiAhz+HDh6WlpR8/fhwWFubu7p6dnV1TUxMYGGhubv7b= > > >>b7/JyMjcvHmzs7MzIiJCRkbm6dOnLBbL0tJyy5YtVCq1qKgoNja2uLgYGgXfC75iGAb4CvJlYIj= > > >>X/eSWJSQOUQHZ1dUVFRW1c+fOGTNmfPHFF1euXKmurgYyD8OwvLw8DQ2NPXv2xMTEgENDJ5ev4J= > > >>ogiNjYWHV1dZCPCJ+otB4PxqUPwLIzMzMvXLhw48aN1tbWjo4OXV3dhQsXampq+vn5nTp1asuWL= > > >>WQyuby8nEQiPX/+nEql3rt3j0QiRUREqKur6+npNTU1RURErFu3ztHRMT8//9SpU+rq6mVlZRiG= > > >>sdlsmKL6PeJramqqnp5eTEwM6v8qOn0AfTJBEAwGw8XFZePGjdOnT//00081NTVhXDuO4z09Pfb= > > >>29r///ntycjLISIdiUioD9de6urpnz57V1NSgfH038hW+A7DANDQ0vH37NgjuAcJSWVk5IiIiIS= > > >>Hh1KlT169fd3V1vXfvHpVKJZFIampqt27dcnJyunTpUnR0NIfDoVAoP/300/Hjx8+ePaujoxMaG= > > >>grd2PDR5McYPSUO9gE6nV5cXNzR0QE1NlG4EIx890Bn9fHxWbdunYSExLx5844dO5aZmYkmC2Kx= > > >>WJGRkbGxseDMHBgdMOlM4vP5g4ODg4ODqNnhXe4XwEHJYDBevnzZ1NQE1pidnZ0UCoVMJoNPCgs= > > >>Lvby8yGRyRUVFX19feXk5mUyOiYnx9vZOTU0FQRcUCmXz5s2mpqYgLUp/fz+6H4aa3N8LvuICRZ= > > >>aP7AKKgq/wAsizgYEBCoWyZcuWadOmff755ydOnIAnjvD5fBqNRqPRQPpLIccGdPvm7WsFXxyXy= > > >>21ra+vp6YFfvTO+8pGQHVxgIYfRZKjBH5gA4YIME2zDwjOxMAzz9/dfs2aNm5sbNGNBEyzK0feC= > > >>rxiGtbe3FxUVMZnMcdb8bcqCre7v76dQKMrKyh9//PGcOXOOHDmSn5+PC0ZOdXW1k5MTUFhxQfo= > > >>gDMk88PZ8RXewwPiprq6+d+9ebm6u0FT51u0Wxpvpr0IDHXQf/BdH9q4gg3EBp3Ec7+3tdXR0VF= > > >>RU9PPzg59PIDmKOPAVlJ6UlGRsbEylUtF8b2/5nkYV0pAZICpQUVFRUlLyb3/729GjRwsKCmDn1= > > >>9bW3rx58/Dhw8HBwWCBhZojJ0v8C02DBEHExMQoKiqC/IS4aHa2AP6Ar28JTLA1B0Y5m80G+1u1= > > >>tbVvo0uJCV8xDAN28oCAABjPPSlkRQ0CfMR1ure3F3hCffTRRzNnzty3b19OTg7sw+7ubgsLC2V= > > >>l5YCAgNbW1on5Er1RVeGLAP6E0J4FWzHphU4RX1F5DE3WsElv2q3iw9eIiAgpKSkfHx8hr7QJPx= > > >>b+HD4ESlY6ne7p6SkvLy8pKTl37tyDBw8mJyeD4y5A24F7wL1798DWwBtNWW8KVCUgCALsm4Dzj= > > >>ECJQEJNermi5Ss+fMmMylRo8X6v5SuFQpGTk/Pz85vc+AIMce8HLeVwOGQyec2aNTNnzly+fPnJ= > > >>kyfz8vJgigCwQs/NzU1OTu7s7BT6+dvXZyTgJABi8BpjAAAgAElEQVSql5KSoqam9uzZM3y4f/O= > > >>klytyvuLDnWghcWG48ATmUHHgK6hGQUHBnTt3srKyYBKeyeIHKr04HE5ISIiCgsL06dO//vpra2= > > >>tr4A0ImlxTU5OXl9ff3w+6lEAiqES0SEeVVxzHCYJoa2t7+vQp2FeDTBXFUJk4XwkBRn6CrrrQd= > > >>RiGWBtwQbMnoGaJCV9xHO/r62toaAB5fdG6vc0z0VENTC4JCQmKioozZsyYM2fO8ePHoVmeIIiq= > > >>qqq7d+96e3uDrO2ge2HyZBHFk8HHopRlsVjQn1Ds1lsoU0e9hgSFXc8XuJ1DgoKLCfBMfPiKNvN= > > >>NrRyvA/qQ3t7ekJAQQNbZs2fr6em9fPkSys7Kyspz587B01rAygwkZkOtkJNOHQxZFILXyuFw6H= > > >>Q66rE0uSVCTISvGIax2ey6urqampra2lqwuwMynZSWllZWVlZWVlZUVHR1dYHGMJnMysrK4uLik= > > >>pISOp3O5/N7e3urq6tLSkrKysp6e3tHzllj97L48LWnp6eiogKeRPVG70loVkUvwDCg0+lkMllO= > > >>Tk5SUvKLL75QU1ODBk5C4O2qpKR0584ddI8QFX74ZMj7MSoPRgiO48XFxc7OziUlJUINmfSi35i= > > >>vwASYlJRkZWWVkJCQkJAQGhpaX1/f29sbHBysra1tYWERHh5+584db29vJpPZ2toaExOTkpISFR= > > >>X16NGjwsJCYO4GNm13d3d/f/+Wlhahl/2+8DUnJ8fMzCw1NRVuoLwpZaFqhJ6QiOM4jUZzc3OTk= > > >>pL68ssvt23bduvWreTkZOAPBNg8MDCQmpoaEBBQWVkJddkpg9B6KyIi4pdffgHnyYtohABMhK8M= > > >>BsPKygqc2lpeXn716tWnT592d3c/ffp01apVJiYm2dnZ+vr6enp6LS0tGRkZBgYG/v7+GRkZHh4= > > >>excXFdXV1Fy9etLS0LCgocHJyAutKOJUAiD9foT0LuEdOYD0ORRSqSIDHlpaW2tra/uc//5k5c6= > > >>a8vHxoaCiTyYRecn19fWw2G8xpaAinSNsrBCG+ksnkjRs3gnhuXJQq7ET4WlxcvHv3biUlpdLS0= > > >>vb29lOnTpmZmdXX1/v4+CgqKpLJ5La2tjNnzuzfv7+oqKiwsNDY2FhHR+fcuXOmpqaxsbFkMllB= > > >>QeHKlSuJiYnW1tb79u0LDg4W4uvYECu+gnyaME3am7YCQ/IJ4zjO5/Pz8/P19fWXLl06a9YsBQU= > > >>FcGorQRBAH62oqHj8+HFiYiIa3Tr1eTogHfkCf210vwAXn/NhCIJ4+fKlvLy8vLx8eXl5c3Ozjo= > > >>6OsbFxXV2dj4/Pb7/9lpqa2t3draur+9NPP7m7u7e2tubn59vY2Bw5ckRKSkpXV/fhw4fy8vI2N= > > >>jYlJSV5eXnZ2dnNzc3QVjeefhcfvoaHhysoKJBIJNQZcvwPQQ1P4G9OTs7Ro0e//PJLCQkJeXl5= > > >>4BJECE6qLy4u1tfXV1RUJJFI0BVrAuW+PVA6EgRBoVB27tyJ6gMiqtJE+NrV1WVlZbV79+64uLj= > > >>U1FQtLS17e/vGxsYHDx4oKCgEBwe3trYeP3584cKFVlZW2dnZISEh2dnZFArl4MGDx48fj4yM1N= > > >>bWtre37+joaG5uBsko4fPflK937tzZtWvXu+JrZmbm1atXc3JyJmYcQI3qPB4vLy9PS0tr9uzZE= > > >>hISq1evDgoK4nK5hGDHqL6+3szMbMOGDdevX6+vr+cPdwwQRRvHACwXyNeysjJPT8/y8nIwD2Ai= > > >>sxJMxD7A5/NLSkru3r3r5OTk5OR0586doqKijo4OJycnAwODsLCwzs5ONze3U6dOhYeHU6nUu3f= > > >>vhoWFxcXF3blzJzQ0tK6uztnZ2cbGJj4+PiAgICMjAxUVaHe8rgIoX62trffs2fPq1aupX29hGE= > > >>aj0RobG/v6+ibMG9AQLpeblZWlq6u7YMGCzz//fOPGje7u7sDtC5rMMjIy9PX1LS0twakY8OeoH= > > >>jzZTXxtnSEj4cYem80Gig0PScM96UVPkK9cLrepqam4uLioqKiuro7L5XK53JaWFmDeGhwcpNFo= > > >>9fX1dDqdwWCAZDDV1dVVVVUMBmNwcLCtra28vLyysrKsrKy9vf2NNu5QWvB4PBcXF11dXZDZGRe= > > >>xsXpkTXp7e/v7+1GHvVGLhpSCFzgy6vr6+sCcs27dOllZ2Vu3bmVkZEBfUg6H09PTw+PxOjo6Cg= > > >>sLaTTaqGNjKqUsNgJsNrutrQ2G32Gi8VvHJ2x/FdoXQD+EcwSKkR/iSLTaG9UYfTFDQ0O2trYHD= > > >>x6EPnW4KI3VI2tSUFDg4eEBdkfHdjcT4iv8y2Kx/P39ZWVlP/vss8WLF1+7dq2+vh72EofDCQ0N= > > >>9fT0BDna0f6cmja+DqhQIAgiMzPTzMzs+fPnBHLesSiG0ET4ig/fiIMNeFONagIzODoTga6xtLR= > > >>UUVF58eIFvOFNnzkxEAJ/F3Ag4B/6RqITNy7Y22Oz2UFBQTIyMh999NHnn3+ur69fWloKB97Q0F= > > >>BsbKyysrKRkVF7ezt8zhS07g+Bbm4RI+JjxY6vEOhr+EP/lclqACY49gnaB4D+OpVzIiHIP7B16= > > >>1bgT4j/0VjFhmsCAwMDJBJJSkpq+vTpS5YsuXjxYklJCVQHORxObGysiorKzp07w8LCgL0PHa5T= > > >>08zXNQQTGLNwHCcIIiwsTEZGBs2XIaKiJy5f8RFerXCqEtHYwkcsS4XsA7DEKXidhCD/wKZNm0A= > > >>SBnSuH/UncEjjON7X1wdk0owZM1asWGFvbw88rOHNNBrNyMhIRUXl2bNnbDYbfj52EVMDbLhuA+= > > >>yvIF8xqg+IouhhfB1/GajaCpZf/f39cOWBv4kofaO2oTdD+bp79270JHMoxkQKMDyioqLk5OT8/= > > >>f3RfBljVB78kMlkenl5rV+/fvr06f/+9789PDy6u7vRkDiCILq7ux8/fhwfHw/sr/CxKOnfIVD1= > > >>jyCIrKwsU1PTkfrrpJc7jK+QhX8IcH4NXxCrmZ2dbW9vHxsby2QyYXuw0YCPQ8Ed+ysIAjlPHtp= > > >>fRTq4R1amrKzM2dkZ+Ezhw53T8dGGIiHwvAZx2MuWLXN3dwcnYAEGEATR39/f29s7MDAAEusK6T= > > >>kinb7GCShZIWVZLFZzczNIRIlu1U560cP42tHTNjg0gP9RMQRBdHR0xMXF0Wg0HMfBIY6mpqbx8= > > >>fFo8jZUBuNIJC2G6OmYwIAn1B1jV0CIr+j+1hS/SJBEDWSjgE1DfQlQbhEEQaPRbG1tN2zY8Mkn= > > >>nyxfvtzZ2ZnBYODI8qWqquratWuurq7A5UocTAEjgb5HDMNgmlRcsAOCrsYmF8P4Gp7r39hRx2D= > > >>RMXysPuJyuXFxcWZmZsXFxWAwsVgsGo0GznIWYifKWiFKgQsY6DP+FsInv8P9WADYOqH8LthogW= > > >>vAT+if//ynhITEkiVLnJ2de3p6wJ2gE7q7ux8+fLhu3To7O7ve3l748ynbCBgn0EEICAr8X0HKD= > > >>NDeqdgvSCuJCk5zyS6N5/P5BD766ycIoqamRkdHZ+3atdbW1jU1NW1tbREREUFBQU1NTTwer6Ki= > > >>wtvb297e3t3d3d3dPTIyMjc3l0wmOzs7p6SkgK2g9vb2+Pj45OTkrKwsNDkKf3xe+uLD15qaGjK= > > >>ZXFlZib6qkQ0hCILNZvv6+q5cuRKoAY6Ojt3d3Tgye7a3tzs6OhoYGLi5uTU3N+MI10URCPU2QE= > > >>cmjuMEQeTl5VlaWoJsSHCMiZyvpm5yD4IvJubHDHCFN0jRHzQ0NOjp6UlJSYFTx2k02uXLl1euX= > > >>Hnr1i0Gg5GcnCwlJfXNN99YWVk5ODjs27fP2NjY0dFRVVVVRUUlIyODw+H4+voaGBhER0fHxMR4= > > >>enrC3XC0R8Scr6C4qKgoRUVFsNHPEySVhioBX5BCkMvlksnktWvXTp8+/ccff3R3d6fT6eA5kJE= > > >>JCQmGhoYRERFgmhKfA2lHBbrsA/bX9evXBwYGQr7iU+Cvvdn0Wz2nUw/CbOs768fg6+DgoJ2dnY= > > >>aGRklJCUEQQ0ND9vb233zzjYaGRktLy4sXL2RkZL7++msqlVpaWqqsrKyvr19eXv7o0SNZWdmws= > > >>LDGxkZTU9OrV6+WlpbGxMTs3bs3ICAAJCMZJ8SErxiGhYeHS0lJPXnyBI37hVQDq6WhoaHU1NRN= > > >>mzZNmzZt2bJlTk5OYK8V3gDuaWhoKCsrAw4ufCRkTwz1AT4SGYYJ8g/A/QJszLO73hLD+Hrg3i/= > > >>X/K57JzzpZHSOwdehoSE7Ozt1dfXS0lLwb1BQ0Jo1aw4ePNjc3Pzy5cutW7f+61//Sk1NLSkpUV= > > >>NTMzc37+joCA8PV1FRiYqKqqioOH36tJGRkbe3t62tra6ubmRkJAhVg3gv5Cvgq7S0tLe3N8gDg= > > >>CGARExLS9u/f/+MGTNWrVrl4uICT78GtzEYDOBoAVVhKLewMX0S3iGwEfbXsLCw7du3o+dv4VPg= > > >>n6V6d+dV/xuBaST2AHsMvrJYrNu3b4NwIjqdzmQyX7x4oaKioqmpCeSrrKzswoULk5KSioqKdu3= > > >>aZWpq2traSiKRgONmaWmpjo7OkSNHwsPDc3Nzs7KyGhsbwSSI9siorRUiBLQPQPuriIb1qP2AYV= > > >>hsbOzOnTvJZDLcl4KvanBwsKqqikQi7d+/f86cOStXrnRycqLRaKDa4AkVFRX29vbOzs4gaauQ9= > > >>RpiCprzRgADCUbkEwTx8uVLkDNd1AaNYXx9VhjR0Ufr4/bxsddOQMBA6OXlJScnd+HChfDw8NLS= > > >>0ujoaDk5uT179pSWlubn5ysqKq5YsQLoA3v37gUnPoKU4WZmZkVFRSdPnpSVlSWRSDk5ORQKpaC= > > >>gYJzxMEKaPo/Hs7GxAZE5I7+dAjQ1NUVHR1dVVUEdABeEDAUGBu7btw+ECSxbtszNzQ0IUVDPgY= > > >>GBFy9enD59WllZ2d3dHVgGxVZbFQLsZ74gJoLD4TCZTNSuJ6KGDOMrHxsc55ZBTU3NuXPnlJSU7= > > >>t+/X15enpiYaGpqam5uXlhYWFdXd//+/YsXL5aVlTU3Nz969MjZ2bmpqamgoODChQsPHz5saWnx= > > >>9vbeuXPn6dOnL126dP/+/ZycHChfUQEzslxseH44Pp/v4+OjpaUFjpiCv5pKKQvtWbDyNBrN19d= > > >>3w4YNEhIS06dP3759+/3797u6ulDZU1paeubMmY0bNz548KC1tXWKq/2WwJCFIFQJANBFpyiKJo= > > >>T2t8b5GxzHKyoqAgMDs7Ky+vr6WCxWU1NTY2NjT0/PwMAAjUZrbW0FyUe7urq6urrAhm1rayuIJ= > > >>ujo6KBQKJ6engEBASUlJb29veN8YUJ85fF4T58+PXr0KPTPmmIRBfaigREAdsuNGzdWrVr10Ucf= > > >>zZ49e+/evcnJySC0HV1g5eTkGBgY2NjYtLS0iFThExHQzS0cxzs6OrKzs1tbW8G3UJpMOmuJifm= > > >>/glrClMrEmwD8dmhoiMVigawkBLL1/4d8hUzFMAyYJjQ1NUfqr1Pz7oE+UF9fj2FYT09Pfn7+5c= > > >>uXly1b9tVXX23bts3c3Dw1NRXs+QG7AUEQdDq9sbGxqanpxYsXHR0dxHCDpbiZAkYFfAtQ/8nOz= > > >>jYzM8vMzCQQ/wFRyI6J8BUXiDF0PYuaYDDEogGXIOgMgiHO3W+0/sUQgGcGBgaePXu2oqJi5G3j= > > >>b84EQAhiVE6dOkUmkxMSEkxNTXft2rV27VopKSk7O7vCwkI6nQ7TBYNfNTY2enh4+Pn50el02AR= > > >>0Q+i94CusMyawv8bFxe3fvz8xMRGYREQkXPG34Ss0iQsNJv4ICIWAoio5Sr7xkAwdDKCsiIgIAw= > > >>ODV69eoaNiCoQrGG+JiYkyMjLq6uoKCgqSkpLTpk1btWqVmZkZSHEFpw5w0dTUZGdnd/bsWQqFA= > > >>iYW2JNTvEx8S6BVBaLn2bNnwLhOTGV8wTj1V6F6jxT+KInRf1FxK8TUNyqXjxw95eDgsH//fiH/= > > >>rDd6GtqcMZqJ3gP419LSYmNjs3jx4jlz5nz88cdffvmlkpKSm5tbXV2dkDkWx/GWlhZ7e3sTE5P= > > >>IyEgQ54QP117eF7LiI94dQRCpqam7d+8OCwvDR0tHOYkYxlfOIOePfyEGAB1BTFI8Nx9JYC1EIH= > > >>QoQk0dx3EOh1NSUmJmZvbjjz+CQwS2b98ODlBlMpkEksMCrpqzsrJu3rwJyIq/bwQVwkhZ097eH= > > >>hAQIBTlIXL9tayxDJtQWNUUA+XrW+5vYcNTfPKHZ1SG14B2wOu3pqbG29v7wIEDf//73z/++ONv= > > >>v/1WW1ubSqWCKFb0sZjArs7lchsaGgoKCgCbRTRXThmEyAoGPJvNBjsIMP+kyPna2NmIrtbFFpP= > > >>LV7RzsREn/oBSuFwuk8lMTk5+/PjxiRMnfvjhh08//XTevHkKCgpWVlbgsFZcEM+EI6pFcXFxVF= > > >>RUY2PjSEXovVhavQ5oE/h8fn9/P5PJhEEWuMjsM8P4GvMyYoA7KIpiJheTyFd8+DY9fA1wtdTU1= > > >>BQVFeXq6nr58mV5efmFCxcuWLBg3bp1x44ds7a29vDwcHBwKC0txQVkhbxnsVhUKvXixYtXr16t= > > >>rq5GixO6eE+B6q9FRUX29vZFRUVvv4oYG8P4mloYx+zrEf9unHT5ihoc4NRfW1ubkJBgZGS0cuX= > > >>Kr7766tNPP5WQkFi8ePHx48dDQ0NBWpfIyEg1NTXgP4ByncVieXt7Kykp/f777wkJCSBgEDUDve= > > >>/yFR/O14iICHl5+YiICFzEu+LD+BqW4dc/yPlL6QPoRgaO44ODg/X19XFxcY6OjgcOHPj555+/+= > > >>OKLjz/++G9/+9uiRYv27Nnj5eVVWVkJzmoE7wmcz426qxIEUVVVdfjw4R07dqCh2KBEPrI5N5md= > > >>MoUQ0r8JgggJCUHPk8emxv5a1Vgh5vorlIV8QeSQlZWVqqpqfn4+IQjZQ3sTG7HLgiEGKYj29vZ= > > >>Xr15lZGQ4OTkdPnx4yZIls2bNkpCQmDlz5vr1642Nje/evUsikWpqauDpjaC4Z8+ebd682dfXFx= > > >>7VAh9IJpOpVCpIhYkjs//7sikwBoTWW4Qgnhvl61TEwzDYDHEmKz7cMwis3y0sLHbu3JmXlwcn2= > > >>VEZKQQOh9Pf39/Z2ZmWlubv729qaqqsrLx169YFCxZISEhMmzZt5syZS5cu1dDQCA4OBhnBoKoA= > > >>K8Pn8ykUyi+//OLv7w9T1nE4HMBd6FcgOmXuXQET5KyFE11YWNi2bduio6OJqYzn5vHFfYYauRP= > > >>h5uZ26NChsrIylI58Pr+3t7e7u5vBYNDpdDqdDvLPgZxzcXFxt27dMjY2Pnbs2MaNG5cvX75w4c= > > >>K5c+fOnz//m2++2bRpk7GxsbW1dXBwcHFxMQj/JxDnBBS1tbXBwcEVFRU8Hm9gYIBKpbq6uhYXF= > > >>wNXAVBnMXS4fnugx9LiOF5ZWRkQEFBbW4uL2OVoGF9fF2MoPkCFKBCxz58/P3v2bEREREVFRUVF= > > >>RVVVVXl5OYVCsbCwMDMzMzMzMzExOX/+/JkzZ3bu3Llhw4Y1a9YsXbp0zpw5n3zyyccffzxv3rx= > > >>NmzaZmJhYWFjY2NhERkYWFhb29PSgXlcoUMkBPgG3DQ0NhYWFKSsrGxgYVFVVYYgR4E8pX2H/g1= > > >>kOpggHjYVnWE960cRb5s+aeqC6/NDQ0NOnTzds2PDzzz9v27ZNVlZ269atsrKyP/zww5w5cyQlJ= > > >>T/77LNPP/109uzZn332mYSEhISExIwZMyQEWLp06bVr11JTU1tbW2k0WktLS3d3d29vL5olE1he= > > >>wYfgAiytuFxub29vX18fh8Pp6ury9/dXVFTcu3dvYmIimmtbdDPjOwS6fgCta2pqSk9Pb2lpAXK= > > >>XL1b5X98hMMSeDyYjS0tLkD1dQkLiiy++WLRo0eLFi7/77rvvvvtu0aJFS5YsARffffedtLT02b= > > >>Nnz549Kycnt2TJkmXLlmloaDx58qSurg7DsM7Ozvj4eF9fXz8/PwcHBxKJ1NHRwePxGhoaSCSSg= > > >>4PD48eP/fz8kpOTu7u7wRsKCQm5d+/etWvXrl69qqampqGhkZmZiYqZP59khUCbieN4eHj4jh07= > > >>KBQKjkT2fuDrKJtDAQEBmzdv3rp164EDB27fvk0ikUJDQ0NCQkIRhISEPHv2LDMzk8lkdnR0ZGZ= > > >>mhoWFkclkCoVCpVLB6Ql0Oj0rKysqKio6OtrFxcXf3x+kA2pvb4+Ojrazs/Pw8IiOjs7Nze3t7Q= > > >>UWgJiYGC0trUWLFuno6Pj7++fn58NVl5BY/ZOJWNQ+AJahz549k5KSAucd8xGPs0kv+j3jK46Yt= > > >>EB3NDc337x5Mzw8vLGxEXp/jx/oYzHBcUIgYgI6rPB4vJ6eHnD2FbrjOjg46OPjs2HDBi8vL5iI= > > >>CX3an5uv0FUA2AdkZWXDw8OJ4QkqJ73V7xlfhfqCIAgajfbo0aPi4uLxs/N1lH2jz8F1VFQU3C8= > > >>gCOJ9N6yOH+gCiyCI4ODg9evXg3yaGLK/NXV8JXDwbgixMhqAbsIF24A4jiclJZmYmICda6jUTo= > > >>EwIwT5NLdt2+bn5wfzXPyJdVYUKCkJgkhPTzcyMkpPT8eHWw9Ey1cCHyZFMPy/RsQxwrunGBji5= > > >>gdmanA+TEFBAY5E5kwZY0pLSx8/fpyXl4cmIPqL8BU2GcdxDofT0dEBTl0cucs4iSCE4gsGhrgt= > > >>PQ2tvUV1TGpFF6WDXVnRUc7hDoiJlEU5wefzBwcHb926JeSvPcXKIh9x94aWyCkr/V2BjwBDrNH= > > >>gpWBTYx/Ib3tln25+NU4luMjQ98Vp24wDac2RdfT6/sF+Qjz2aTFkswA4AcbExBgaGr58+RLcwB= > > >>el8+XIykArIxxCfwV9QGjG5/P5AwMDwDINADOEila+XorS0yatPP3sP0dI6y4n7jSKUb5G1X+Qf= > > >>ft5U+YgTyz8YjEkYhH8297ebmNj8+rVK3xEUPwUVKawsNDf37+2tvYvyFfIWhzHMzIyQD54XMQR= > > >>lMP4qh26SfeZlJrPdxtc/qbms+FkqLJFsnZwkUdqdWIjo1EcVIKRXdDd3W1nZwf1V1GXDi8IQb4= > > >>3JSWl4OBgoezEIq2GOEDIShMUFLR+/XoymSxkz5r0cofxVdVtnobdd1rOP+y79v909X/wjdFMa3= > > >>AIenXF8/m1srZX4sBXIRAE0d3dbW9vj+oDIqLLyBfQ09Nz9+7d//znPwEBAWj+rL8IoDWGIIiQk= > > >>JANGzbAfJqiG7fD+LpNb832E8t1bv58wWPDJZel1yOX7/ebp/B4kXWiRQuzVUxUWBSQrzC/C1z6= > > >>THpZkK9Qaaurqzt48OCOHTuAfQAXm8NbRA2UkcD+GhISsnHjxtDQUFzEKSCG8VXNeZu0o+wO963= > > >>qAd9pkb464vf1/icbdnvtvUS5WtJZJp587ezstLW1LSoqwsfsqUnsQfgcGo129+7d+/fvt7e3Q+= > > >>PrX8GeNVJ8FhUVOTo6wqwluMisNMP4uvz+8mWWS+TtlU75GBxzV1d9vH6Xh+yZUIPokpheTu+kl= > > >>/32IAiiq6vLzs6uuLgYzk2j9tSkdJ/QE3g8XnNzc3V1NdiqFZFHknhCaCYB+fyAozqKSS93GF+P= > > >>+WlJPVj/o9W3253Wm0YaWac7ehYEBBSTS7vEUbjiAn3A1tY2PT191A3YyQX+mrAFXLACQ3NkTA3= > > >>eVc8LRRTD+mACI/QfCoiJNYFA+Wocb+Kc7uqV6WWfbX0n60Jue8IQznu3/TI2CIKg0WgGBgYXLl= > > >>xISUnJz8/Pzc3NESA/P7+2thbs7H8ABP5HwULQ+oEjyVNeN2UB1jKZzMrKyp6eHqiSjS1fR1YJf= > > >>ebYb/x/fG1htzPYDCabyccIDMf42BBBEISYuRCgIAiCwWCYm5vv3r1bW1tbX1//1KlTenp6J0+e= > > >>1NPT09XVtbGxiY+Pz8zMTEpKSkhI8PPzI5FIWVlZ5eXlJSUlqampiYmJhYWF6enpMTExQUFBXl5= > > >>enq+Bh4cH/NbLy8vb2xt86OHh4evrGx0dnZ6eTqVS09LS0qcEVCo1Kyurrq4OZLXGX5OYB8Owvr= > > >>4+cIzUqKxF+QHXT5C140RKSsrRo0fHnuXQt9bR0ZGRkZGdnQ2cOeE96B7EqMQlhPZjX1eG2GJoa= > > >>KiioiIzMzMjIyMzMzM9PT0tLS0jIyM9PT0lJSU9PZ1EIpHJZG9vb0dHR0NDw8uXL5NIpLy8vKys= > > >>LF9fX1dXVyqV6u/vb2dnd/nyZcDyEydOnBwBPT09PT29EydO6Orqgn8PHz78/fffz58/X1VV1cD= > > >>AYMeOHdLS0ps3b5aSktosekhJScnIyOjq6j58+PDRo0d2dnaOjo4ODg72CBwcHB49emRhYWFpaf= > > >>nw4UMHB4eEhISGhobk5GQPDw8KhZKXl0ehUB4/fuzv75+UlOTm5hYZGVlVVZWUlAS6MSMjg8Fgc= > > >>DgcNpvNYrGApyWLxert7WWz2eDDwcFBf3//9evX+/n5cTicvr6+/v5+kNwX/Mtms4FyDza9CIKo= > > >>r683MzPbvHmzvr5+eHg4iOgcGBiAFpjXbWuPxlecwMVVoI6Kscc0m83u7+/v6+vr6enp7Ozs6Oj= > > >>o6+sDwxf0Johs6enp6erqam9vb2tr6xgN4KvW1tbW1lZwXVdXFxwc7OLikpubW1BQ4OnpaWtra2= > > >>tra2NjYyt6PHz48P79+3p6eoqKilu3bpWWlpaWlpYdDTIyMrKystLS0jIyMlpaWhYWFrt27fr22= > > >>28VFBQMDQ3V1NQWLly4YsUKFRWV7du3a2lpGRgYSEtLy8vL79mzR01N7fr163fu3Dl//vzp06cN= > > >>BDhz5oyRkdHp06f19fXPnj2rqqr6r3/969dffz1z5oyBgYGhoSG4MDAwMDIyOnfuXEBAQFxcXEB= > > >>AQEZGRklJSVRUlJqa2rRp0yQlJVetWnX48OGTJ09aWFikp6fT6XQulwuTcI1810h+wiE6l9dDEL= > > >>z3QrKOBIE4p6J7USOnQngbgayW3nF4G70AAAm1SURBVAZTvMyCaGlpycrKAhNLeno6mGdGAnwLL= > > >>hISEqysrHR1dW1tbZOTk58+fXry5Mljx45ZWlrGxcWlp6fb2dlpaWnp6elZWFhYWVk5OTnZ2dkZ= > > >>GRlpamqqq6sfOHDg4MGDBw4c2L9///79+zU1NTU0NDQ1NQ8fPnxQAHV1dQ0NDQ0NDXD/kSNHLl6= > > >>8aGpqqqSkdPr06cuXLyspKX3zzTcSw/H3v/997969GRkZmCAybNRX/D++ZjW4FNOCa+hpxW2F3X= > > >>3090rICrv048PXsEJObuid0BSFIT6d4ykRMhU+fIrJiv/Ryul16O3tbWtrA+EYQ0NDYN4Ax4QTB= > > >>MFms1taWlpbW5lMJpju+/v7Ozo66uvrGxoaGhsbGxsb6+rq6urqQGJ78Bdc1NfXg9vq6uoaGhqa= > > >>mprq6+sbGxurq6uzsrK8vb0pFEpCQsLt27eVlJQkJSU/+uijxYsXf//99/Ly8jdu3HBwcCgvLx/= > > >>jFRAoX+0y91ikqDtlX0urTevlsIj3SsqiSjo23O0QqE0A+PClLiZI/YAS+nXPF/pKaCGM0n1sjH= > > >>zIGHeO/RXanFHHJICQkxA+/HB0yGP4lYgAExgmJCQcOnRIWVlZR0cnMDAwMzOzuLgYqLxCbopCG= > > >>MbXK6n7joXu1A3VuJt8u6il+P21fmPDF5hCRBn5FfwJ/nrfrtdRbeRt46keeH+vux9l6hiVgfQa= > > >>oz5CXwnRHd2OGrXckRfoM2GPYYJ1Ei6Yr3DkaFyhvuVyuRkZGT4+PiUlJeAcViFa469PMjKMr6f= > > >>8fz0fuedK9GGH9Dvpdek9nN73S8SKLTBEDHO53Pr6+levXlVUVACDJT7cExK1wwvJRSGe8fn8tr= > > >>a20tLS1tZWMHuIoYhBaQfrDw0FKEfHA8BXcJiZxDXzNbGvzmU0OCZW2SdXu3f21X7g66QAynuCI= > > >>Lq6ujw9Pfft23fx4sWqqiohi6MQccF7xUeb63Ec53K5gYGB6urqDg4O4EwEMeTrqHhTmqI//B9f= > > >>9T0WawV+s9dn7u/+/ybnOzHZrz31+APeFJjAFN/X1+fs7LxixYrjx483NTUJSU0CWUVB7sIPcWS= > > >>iBPeEhoauXr3a0NCQTqf/FVzDCIJISkr6L1/3ev5zn8e3u91/2uWu6pLh0Tvwni25xBnoJE4mkz= > > >>du3Ghubg5Sb+ACn3wcx0F2o+7ubhBwi2HY4OAgi8ViMpnAVAwfNTg4yOFwCgoKfv31V2NjY3BG/= > > >>V+LrwdcNLY9XKHmLnMz4UZyTSqHxxm5xAO/EdsdWrEFZBKXyyWRSOvXr798+TKTycQEbmU4jnd1= > > >>dcXGxjo6OlpYWMTGxrJYLA6Hk5+f7+3t7eXlRSKRSkpKQGbP1tbW6Ohof3//u3fvrlmzxtDQEDz= > > >>qfdEHJoxhfN3lo3wywtgi1dog3Ngjw4Mz0E8QBB/j83g8Aifa+lohg8Unwvu9AKqYDg0NBQUFbd= > > >>iwAfAVfE4QBJPJdHV1NTY2trW11dHROXDgQGpqalFR0alTp/bs2WNnZ3fhwoVHjx61t7fTaDQ7O= > > >>7vjx4/b2NhoamouWLDAyMiIyWTifzX5KvVw7Q7Xnb/aqyhaKxk9PRucF+yX5xeSExL3Ku485bwB= > > >>5UxuU25Ja0lgbiCNRfugKrwRoPDj8XhBQUE///yzmZlZd3c3+KS2tjYsLExBQeHEiRNdXV3FxcU= > > >>HDhzw9vYuKirS1tbesWPHkydPzp8/b2ho2NzcTKVSt2zZYmhoWF9f7+bmtnz5cgMDA2Dt/4vwtb= > > >>OzkyAIieW6P/x87me563K/Wu6Su75d2kpG3VXd0Nto1ZVVP9/ZcDfynonPeRWbXbee3UorTetid= > > >>b3ryr9PgOv6oaGh4OBgIF8ZDAZBEHQ63cHB4dChQ4sWLdLW1gaB0SYmJiB34oULFzZv3nz58mUT= > > >>ExPA18DAwNWrV3t7exMEUVhYqKysbGJiAlXhPzeG8bX3UW/8xdgw05D0W6mvbr2IOR3tfsr9H6f= > > >>++dP51ZZ+Vrstdi+98I9dzr+c8TYwDzRv6Gr8K3TQxDBtNOCC8+eDgoLWrl1rbm7OYDAwDKNSqa= > > >>qqqvv37//hhx8OHTrU0dHBYDCMjIx8fHxCQkLWrFmjpKQUExMDNvErKytBcJ+dnV1vb29CQsKWL= > > >>VuMjY3huYp/Mgj1oYSEhJyc3H/5mmSWXGBcWGpcVnulufZiE9WQWmNZuezC94ccj/x45cdvb3+1= > > >>1nb5kivffn/pB5MnZ/OrcvmYuOePf1cYSdaPPvoI2F8HBgbc3Nx+/PFHXV3d58+f5+fnm5mZ/fT= > > >>TT46OjsePH1dUVAwKCgoICDhy5Eh4eLibm9v8+fMVFRXDw8PPnDmzbds2X1/ftLQ0FRUVVVVVNz= > > >>c3dXX1L7/8Ultbu7VVHANC3x5j8dXvelTy40qyZf6NQ8GUa3lUqwJ/3bDtt2XXXF0u6/rTmofLF= > > >>9/7f98/+oes2w/HQn5zfm7f9cFA+xq8jq84jvf29j59+lRHR+fSpUve3t6urq4GBgba2tpZWVkx= > > >>MTFHjx49ffr0+fPnr1+/XlZWlpqaqqqqKi0tbWxsfPr0aQUFBVNT05KSkidPngCvKGVl5dWrV1+= > > >>+fLmuru5dN1okGIuvVY6VbZG0ZI9c4+N3oq0LHl5Lengj8ICx4qnr23dd3SizZ/6JaysCXtmmNc= > > >>QlVcfGlyW0Mzs+8HVUjCTr9OnTcRwH8rWmpqawsLCoqKi0tLSoqOjVq1elpaU9PT0sFqugoCAiI= > > >>iI1NbW2tra/v5/BYKSlpXl4eISFhRUUFCQmJsbGxnZ3d3d1dcXHx5NIpOjo6KCgoIKCAqBavOt2= > > >>Tz5G5SuNRiMIQoLtymE95rHd+ZU2FfGGidQjRUUmHZsfrF5z96elt/653Giu6v01mqS9ak9+0/c= > > >>7Hfo8lMakfTDEjorXyVeIkYZtsKFFEATwBCAEJ3kQBDE4OAgj+IaGhnDkVFscx9Go1D8fZV/H1+= > > >>vXr0s0OPVUWHMa7g22W7bmnKO6aTxOOZquFrxLyn3z7JuzFjz4xx6yhpyH/GG/ww6JDuXN5aN2+= > > >>gcQBCExGsbzQ/z17nyvY/mfGyO7cdu2bf+Vr+XW9PbHPfUOtBdWNbV3mAnGKZrr95NKSWH1Ida5= > > >>9w6Faxgnnfg1UMkixSqrPquzv/Ndt0V8MWG+foAQRnbj5s2b/8vXZF963n1esX1/jkN/qOVQ1G3= > > >>89u9P5n7xxZGNR112hz+7kRF7vSTfpSnc4nkqOSOFkuLzxMdrBLw/4ANej5GEGSMmGUYmA7i7u7= > > >>u6uoaFhbW0tBCjxsd+wAeILT7w9QPeJ3zg6we8T/jA1w94n/D/AWQx0gRPTdK4AAAAAElFTkSuQ= > >>mCC" alt=3D"">
> >>
=A0=A0=A0=A0 I wonder, however, does the situation the same if > rateless= > >> erasure code (say fountain codes) is used?=A0 As with erasure code, no > ACK= > >> and retransmission is needed except when the whole file is completed. > So e= > >>ven heavy loaded, the network is still busy with effective data packet, > rig= > >>ht?=A0 Although queueing delay will increase, I believe that=A0 the > network= > >> throughput=A0 will not=A0 suffer the plunge as un-coded network.
> >>
=A0

Kara






class=3D"gmail_quote">2= > >>013/3/5 Srinivasan Keshav < keshav at uw= > >>aterloo.ca" target=3D"_blank">keshav at uwaterloo.ca > >
>>uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px > #ccc = > >>solid;padding-left:1ex"> > >> > >>To answer this question, I put together some slides for a presentation > at t= > >>he IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we > always= > >> size a shared resource (such as a link or a router) smaller than the > sum o= > >>f peak demands. This can result in transient or persistent overloads, > reduc= > >>ing user-perceived performance. Transient overloads are easily relieved > by = > >>a buffer, but persistent overload requires reductions of source loads, > whic= > >>h is the role of congestion control. Lacking congestion control, or > worse, = > >>with an inappropriate response to a performance problem (such as by > increas= > >>ing the load), shared network resources are always overloaded leading > to de= > >>lays, losses, and eventually collapse, where every packet that is sent > is a= > >> retransmission and no source makes progress. A more detailed > description c= > >>an also be found in chapter 1 of my PhD thesis [2].
> >> > >> > >>
> >>Incidentally, the distributed optimization approach that Jon mentioned > is d= > >>escribed beautifully in [3].
> >>
> >>hope this helps,
> >>keshav
> >>
> >>[1] Congestion and Congestion Control, Presentation at IRTF ICCRG > Workshop,= > >> PFLDnet, 2007, Los Angeles (California), USA, February 2007.
> >> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/conge= > >>stion.pdf" target=3D"_blank"> > http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= > >>pers/data/07/congestion.pdf
> >>
> >>[2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, > publishe= > >>d as UC Berkeley TR-654, September 1991
> >> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesi= > >>s/ch1.pdf" target=3D"_blank"> > http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= > >>pers/data/91/thesis/ch1.pdf
> >>
> >>[3] Palomar, Daniel P., and Mung Chiang. "A tutorial on > decomposition = > >>methods for network utility maximization." Selected Areas in > Communica= > >>tions, IEEE Journal on 24.8 (2006): 1439-1451.
> >> target=3D"= > >>_blank">http://www.princeton.edu/~chiangm/decomptutorial.pdf
> >>
> >>
> >>

> >> > >>--f46d0444e84964e1a304d740bdcd-- > > cheers > > jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130306/38976483/attachment-0001.html From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 6 07:02:43 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 06 Mar 2013 15:02:43 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: ok - i see your point - this is true if your sources have a peak rate they can send at this could be the line rate of their uplink - that would be embarrasingly bad (see keshav's followup on escalating costs of coding) or the rate they can get data off disk (which could be as bad, but might be lower) or an application specific rate (e.g. streamed video) for which you're suggestion is quite reasonable.... but for data sources which are greedy (TCP with arbitrarily large files) you need a way to tell sources a non wasteful way of sending - and what is more there isn't just one set of sources in one location and a set of sinks in one other location so the system of senders sending at unconstrainted rates on a finite speed net with high speed edges, would create multiple bottlenecks, which would exponentiate the problem coding isn't magic - its info theory - if you lose info you must add redundency - coding does it pre-emptively rather than post-hoc the way ARQ/Retransmit does, which saves you time, but in the end, can't defer the inevitable if you look at digital fountin systems for video they pick a likely loss rate, pick a tolerable picture degradation rate and use those to derive/choose a code the assumption is that the losses are capped because most other systems are backing off just like TCP - if you break that assumption, you'll break the coding parameter choice anyhow, roll out ECN - much betterer technology:) congestion avoidance without keeping queues filled everywhere... In missive , shun cai typed: >>--e89a8ff1c4e2529bed04d742b110 >>Content-Type: text/plain; charset=ISO-8859-1 >> >>1. With fountain codes, for k original packets, infinite number of encoded >>packets can be generated and the receiver can recover the k packets with >>any k(1+ e) coded packets. >> >>2. Suppose all flows are coded, and the short term packet arrival rate of >>some flows exceeds the service rate of the network. Overflow and packet >>loss could happen wheather the packet coded or not. >> >> My point is, I do not think the effective throughput will plunge with >>coded flows , although the buffers are full. The network is in full swing >>and the worst delay of a flow is the sum of the maximum queue time of the >>routers along the path. >> >>I think there will not be a cliff in the throughput-load figure, insdead, >>the curve will go beyond the Knee and reach a constant throughput. >> >> >> >> >> >> >> >> >>2013/3/6 Jon Crowcroft >> >>> there's no free lunch - if the queue keeps being filled, you'll get >>> increasing >>> packet loss - to cover the loss, you'll need more redundency in your >>> erasure >>> coding - this will cost you more delay at source (in constructing more >>> redundency) and more overhead in the net, which is a positive feedback >>> loop, >>> just like retransmitting a whole window into a congested queue/path - a >>> "vicious cycle" as opposed to a virtuous one... >>> >>> so all that erasure codes buy you is delaying the point when you go over >>> the >>> clif >>> >>> In missive < >>> CANZhn5Gqyw6-XpaB2-XKmbahKidOap+ZDqGAJ2NqdMBxmYAP-w at mail.gmail.com>, shun >>> cai >>> typed: >>> >>> >>--f46d0444e84964e1a304d740bdcd >>> >>Content-Type: text/plain; charset=ISO-8859-1 >>> >> >>> >>As discussed in chapter 1 of your PhD thesis, when network is >>> congested, >>> >>retransmission dominate the traffic and effective throughput diminshes >>> >>rapidly, leading to a deteriorating situation. This can be illustrated >>> in >>> >>the well known figure with two turning points Knee and Cliff. >>> >> >>> >> >>> >> I wonder, however, does the situation the same if rateless erasure >>> >>code (say fountain codes) is used? As with erasure code, no ACK and >>> >>retransmission is needed except when the whole file is completed. So >>> even >>> >>heavy loaded, the network is still busy with effective data packet, >>> right? >>> >>Although queueing delay will increase, I believe that the network >>> >>throughput will not suffer the plunge as un-coded network. >>> >> >>> >> >>> >> >>> >>Kara >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>2013/3/5 Srinivasan Keshav >>> >> >>> >>> To answer this question, I put together some slides for a >>> presentation at >>> >>> the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we >>> >>> always size a shared resource (such as a link or a router) smaller >>> than the >>> >>> sum of peak demands. This can result in transient or persistent >>> overloads, >>> >>> reducing user-perceived performance. Transient overloads are easily >>> >>> relieved by a buffer, but persistent overload requires reductions of >>> source >>> >>> loads, which is the role of congestion control. Lacking congestion >>> control, >>> >>> or worse, with an inappropriate response to a performance problem >>> (such as >>> >>> by increasing the load), shared network resources are always >>> overloaded >>> >>> leading to delays, losses, and eventually collapse, where every >>> packet that >>> >>> is sent is a retransmission and no source makes progress. A more >>> detailed >>> >>> description can also be found in chapter 1 of my PhD thesis [2]. >>> >>> >>> >>> Incidentally, the distributed optimization approach that Jon >>> mentioned is >>> >>> described beautifully in [3]. >>> >>> >>> >>> hope this helps, >>> >>> keshav >>> >>> >>> >>> [1] Congestion and Congestion Control, Presentation at IRTF ICCRG >>> >>> Workshop, PFLDnet, 2007, Los Angeles (California), USA, February 2007. >>> >>> >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf >>> >>> >>> >>> [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, >>> >>> published as UC Berkeley TR-654, September 1991 >>> >>> >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf >>> >>> >>> >>> [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition >>> >>> methods for network utility maximization." Selected Areas in >>> >>> Communications, IEEE Journal on 24.8 (2006): 1439-1451. >>> >>> http://www.princeton.edu/~chiangm/decomptutorial.pdf >>> >>> >>> >>> >>> >>> >>> >> >>> >>--f46d0444e84964e1a304d740bdcd >>> >>Content-Type: text/html; charset=ISO-8859-1 >>> >>Content-Transfer-Encoding: quoted-printable >>> >> >>> >>As discussed in chapter 1 of your PhD thesis,=A0 when network is >>> congested,= >>> >> retransmission dominate the traffic and effective throughput diminshes >>> rap= >>> >>idly, leading to a deteriorating situation. This can be illustrated in >>> the = >>> >>well known figure with two turning points Knee and Cliff.
>>> >>>> src=3D"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOUAAAFECAIAAABXn= >>> >>> >>G6+AAAgAElEQVR4nOxdZ1xTydeOFfuqq7uL69rL7uqquy5WXFRELKiAWMDeUFEQUVERRVF6ryoq= >>> >>> >>IKxrowjSpKggSG9SBek9IQkhhYQkd94P82b+Q7CAFEXyfOAXbu69M3fy3DNnzjlzDqnP+0BI0H5= >>> >>> >>IRrKzIDaGJBJp5cqVNTU1AACSZJQ7C5KR7CxI+NodkIxkZ+G9fK2trZXwtQWEGAQCgUAgaP3tRy= >>> >>> >>7/NkYSPaZAIIAf0FMLRBAbB3gEP4iP4SfHrTUkfG0T0OByuVw+n99L+CoQCPh8PkEQfBHESCl2A= >>> >>> >>vpKIBDweDz4b3Nzc3NzM+I3n8+HfEWXtKtLEr5+GnB8ISn5fH5zczP8kQhM7n78Dj1xJOHDQkrx= >>> >>> >>eDxERz6fDwAgCAIxDw0OLjvhtTg18bFCQ9qZfO2SYeiZAAAAAOAQAxGINvO1JwJSkxDN9c3NzQK= >>> >>> >>BAA4CjUZjMBgEpg/gAwJPQ58J0SiBlkCtdKSTAICoqKi6ujoJX/8HGo2Wl5eXn59Po9EEAgGTyX= >>> >>> >>z79m1FRQWXyyXaoAz0UODCDypCAoGgtrY2Ojra2dnZy8vr3bt3DAaDx+NxudyKioq8vDwmk0kQB= >>> >>> >>IfDqa+vZ7FYUA3g8Xj5+fmxsbEFBQVMJpPBYBQVFZWWljY0NKBp6rMh4as4AAARERFbtmy5cOFC= >>> >>> >>QUEBl8t98uSJgYHBixcv2Gy22EriC/azK4DP8nw+Pz09/ezZs0eOHLly5YqRkZGBgYG5uXlcXBy= >>> >>> >>NRnvw4IGOjk5mZiYAoKSkxNXVNSwsjMViAQDKysqsrKz279+vrq7u5OTk4uJiaWlpaWn54sULXL= >>> >>> >>X9PEj4Kg4AgKen5+jRo/fs2VNcXJyWlnbq1CknJ6eysjIoHsD7gK79yBF08KsFUkYBAHV1dadOn= >>> >>> >>frzzz9dXFxqa2vz8vL09PR+++03KysrDodz9+7dJUuWvHjxAgBQVVXl5OT0+PHjpqYmNpvt5eWl= >>> >>> >>q6trY2OjoaGxatUqWVlZb2/ve/fuPX/+nMfj8Xg8CV87EwCAhISE5cuX79u3LyQkxMjIyMnJqbq= >>> >>> >>6GqlobDa7rq4OznRVVVVUKhWtJOh0ekVFRW1tbWNjI5RSLBarsrKSQqFwuVy0lIYrkq9TPCNDVW= >>> >>> >>ho6F9//bVp06aysjL4suXm5p4/f97R0ZHFYnl5eS1duvT58+cAAD6fX1VVVVdXRxBEUVHRvn37j= >>> >>> >>h8/XlRUlJ6efuDAgSVLlqSnp1OpVCqVCnXijnQP8pVMJkv4+v8AAJDJ5KNHj8rLy69fv37BggXB= >>> >>> >>wcFw9QAp+OLFiwMHDjg6Ot69e9fQ0NDa2jonJ0coFNbW1jo4OOjr6xsbG7u7u9fV1fH5fF9f3wM= >>> >>> >>HDty4cSMmJqaoqAgZfVpbLr8SwF41NTU5OjqOGTNmx44dVCoV2QdSU1OjoqIaGxu9vLzk5OSio6= >>> >>> >>MBANXV1f7+/ikpKQKBICEhQVZWdtGiRREREVlZWevWrfvtt98iIiLQ+rWDL6qEr+IAAFCp1OPHj= >>> >>> >>0+dOlVeXl5GRubKlSuVlZUEQUDd6/Hjx2PHjl28eLGXl9fjx481NTVv377NYrGioqJ2797t5ub2= >>> >>> >>33//7dmz5+XLl2VlZYcPH96xY8fTp0/t7e2dnZ1ra2uR9+Fr4yu+uudwOI6OjqNHj1ZXV6fRaIT= >>> >>> >>IIN3U1MRisbhcrru7u6ysbFRUFACgtLRUS0vL2tqayWS+ePFi0aJFsrKyMTExubm5W7ZsmT59+s= >>> >>> >>OHD6EagJtsPw8SvooDAPDu3btdu3Zt3LgxICDAwcFh8+bN7u7uVCqVIAihUBgQEPDnn38eOnSoq= >>> >>> >>KiosbHRwcHB1ta2qKjo2rVrGzduDA4OTkhIOH369L179169eqWmpmZmZpaXl+ft7W1kZJSVlfUZ= >>> >>> >>NsjuAb7YYrFYLi4uv/zyy/79+6ElC07ldDqdyWQKBAIvLy9FRcVXr14BAJqbm83Nzc3MzDgcTn5= >>> >>> >>+/vbt2/X19RsaGphMprW19fr161NTU6EfoeNakISv4gAAJCUlqaio6OnplZeX19fXGxkZrV279v= >>> >>> >>bt2zQaDQAQEhKydOnSCxcuUCiUxsZGZ2dnR0fH/Px8IyOjdevWPXz48M2bNyEhIenp6XFxcRoaG= >>> >>> >>hYWFtnZ2SkpKVFRUeXl5WhO/NrkKyFSXgEATU1N9+/fX7Bgwe7duysqKqA+QCaTb9++HR4ezuVy= >>> >>> >>fXx8Nm/eHB8fD9UkFxcXBwcHHo9XUVFx8OBBExOTpqYmDofj5OSkrq5eWFgI1dwOGgcIEV8pFIq= >>> >>> >>Er/8PAEBkZOTixYtVVVXT0tKamppcXV1/+umntWvXJiUlCYXCsLCw6dOna2hoFBcXl5eXX7hwwc= >>> >>> >>LCgkKh+Pv7q6qqenp6pqamPnjwoKqqKjc3d//+/RcvXszNzS0oKIiLiysvL29ubiYwj/zXA9wVw= >>> >>> >>ufzMzMztbS0ZGRkbG1tS0tLaTSav7+/mpra/fv3mUymq6vrokWLgoKChEJhUVHRoUOHzp8/39jY= >>> >>> >>mJOTs2HDBk1NTTKZXF1dffjwYRkZmeTkZEjr5ubmTrEPSPj6PwAAUlJSLl26ZGlpmZubS6fTfXx= >>> >>> >>8zp07Z2pqmpmZKRAIsrKyrl69evfuXQqFUlFR4eXlFRoayuFwKisr7e3tDQwMLC0tHR0dS0tLmU= >>> >>> >>xmaGiovr6+jY3Nf//9Fx0dTaPRkM3oa9MKcOcqFIfp6emHDx9WUlK6ePGiubm5tra2g4NDRUUFj= >>> >>> >>UYzNzeXk5Pz9PSsra319vZeuXLl8ePH3717Fx0draKioqGhER8fn56evm3btqVLlwYEBOCuWglf= >>> >>> >>OxlNTU319fX19fUcDofH49FoNAqFQiaTORwOQRBcLpdKpUI1rqmpiUqlNjY2QvJVVFS8fPkyMjI= >>> >>> >>yNzcXGs/ZbHZ8fHxoaGhKSgpUJ/BlzRd+zvcBiVjY1fz8/EePHp07d+7s2bOPHj2qqqoiCILJZL= >>> >>> >>5+/drX1zcjI4NCoSQmJvr4+ERGRlZVVRUXF4eEhDx9+jQ/P7+ysjIsLMzf3z8zMxOa8zo+q0j4+= >>> >>> >>h681yOADP4f+gz/JQgCuc7RCTD+A57zdWqu7wUyQlVUVFRWVsLAF7EICnz5iEx1YlFd+Equ412S= >>> >>> >>8LVzgMQSBBInOKFxNaCnsBaqB+ih4ISO/hVicS2Iu2IvMIEFf3VcvkZGRkr42gkQC7R771dI6ny= >>> >>> >>1Vi0x4EZTsadDXxEtdV+ipUDFz+8U+Srha0fR+pdAR3ASf+T8rxawq2J2/tYvHn5EjLUENggd7w= >>> >>> >>/ka319vYSvn4+P8LX1IqNTlh3dBriiR4RDxMUfWexxJHxtE74IAz4kKTt3EvyCENMHxPRvYcsVF= >>> >>> >>dJoCUwlaH3DjvTnG+Errtd3Pz/ErATEN8RX4qPMw0VsUVERtCGI6ayd25lvhK9oi5UQQ/c0LRAI= >>> >>> >>WCxWY2Njx4PneygAADwez8vLy8nJCe6s6rrx7/F8BQA0NDQkJSXBaL3ul2pNTU3Pnj3z8PCoqqr= >>> >>> >>q6aL08wAA4HK5BgYGGzduzM7OBqJ9b10xGt8CX7Oysk6fPv3o0SM2m02ItnF2WwdYLJaNjc3u3b= >>> >>> >>uzsrK+2kCWLgWUr66urjo6Om/fvgXYxsyuaKsH8xUOTUxMzOLFi3V1dSsrKwEAHQ8Cahe4XG5YW= >>> >>> >>Jirq2tJSUnPWvt3IoRCYVVV1bt371gsFtLHusLA3OP52tzcfP/+/QkTJqxYsSIpKan7XfNCoZDJ= >>> >>> >>ZFKp1KamJuKbWGB9HtCiE00yEr7+D8iAwmAw9PT0Bg0aNGfOnODgYB6PR3Q7X8UcsN3W9FcFJpN= >>> >>> >>Jo9HQqreLtLIexlc0ENAoCACoqalRVVUlkUiTJ0++c+cOVGG7kzQCgaCysvLt27eNjY3EVxnY2t= >>> >>> >>WAMjUwMNDJyamiooJo6art9LZ6GF/x3EwAgPj4eFlZWRKJNHbs2KtXr0LPcrf1BwDA4XD+/fdfm= >>> >>> >>Kygd4pYuN66dOnShg0bMjIyiK5c8vY8vuIaKpvNtrS0HDduHIlE6tOnz6ZNmzIzMyGPu6c/AAAW= >>> >>> >>i2Vqarpu3brU1NTuafRrA+SroaHh6tWr09LSJPbX/0FsILKystTV1SdPnjxy5Mhx48YtX74cWbW= >>> >>> >>6B5CvZmZmcFddt7X7VQHaXy9cuLBhwwa4tZBoGTnZuW31JL4SWIIxPp8fGRmppaWlqakpIyNz5M= >>> >>> >>iRS5cueXp6NjQ0dFtnIF9tbGy2bduWmpraO11ckK82NjaGhoZwA4LwfUlzO6utnsRXKF+RxaSoq= >>> >>> >>Cg+Pv7x48erV6++ceNGenr6mzdvmExmd2qQPB4vKSkpICCAQqH0Ns0VAsqOlJSU1NRU6GLsOqti= >>> >>> >>z+Mr0dJKIBQKX758qaCgcPv2bZiPreNJbz6jPwJRTkkCC75BaB0Qg04TiwvBbyIWudc6pge0zNK= >>> >>> >>FH8ebw0cDnibWf3Qy3kP8YGt86DjeSYl8FQccoOfPnysoKLi5ubHZbLHfo6uBzMBiwPVssd8S7R= >>> >>> >>iBp6EPAlHqanQynuFa7OZoUwp+PpqCAcZjoSjhdWuqvbfzxIeJ2PpMBoMB02g2NTVRKBSYfrT1C= >>> >>> >>HQiQE/nK0EQiK8sFovo9kDY5ubmysrK5OTkuLi4hISE2NjYhISEmpoa2I3q6ur4+Pjo6OiYmJjU= >>> >>> >>1FQqlcrn88lkcmpq6qtXr2JjY2NiYjIyMqDttr6+PikpKSYmJiYmJjY2FmbggscTExNfvnz54sW= >>> >>> >>LhIQEmCCIz+cXFxfHxcXFxMS8fPkyIyMDJmJpbGxMSUmBJ8fExMAYv+bmZjKZnJKS8urVq5iYmP= >>> >>> >>T0dCaTCYlVWVmZmJj46tWr+Pj4hISEgoKCwsLC5OTk+Pj4169fJ74P8PjLly9dXV3v3Lnz9OnTx= >>> >>> >>48fwx3w4eHhiYmJJSUl+ITTiZDwtaPgcDg+Pj7btm1TVFRcv379pk2b9uzZExERAXcwR0ZGHjhw= >>> >>> >>YNOmTRs3btTV1U1LSxMIBHFxcdra2ioqKioqKsrKypcvXy4qKmpqagoKCtqzZ4+KioqSktLevXt= >>> >>> >>fvnzJ4/EAAC9fvty7d6+ysvLGjRuPHj2alpYmFAo5HI63t7eGhsbGjRs3b95sYmJSUlICACgoKD= >>> >>> >>hx4oSqqqqKisqWLVtgCkEGg+Hu7q6mprZu3bpVq1apqqrevXuXTCYXFBRcunRpzZo1CgoKa9asW= >>> >>> >>bNmzdGjRzU1NVevXi0vL6+goLD6fVBQUFBUVJSTk5syZcrMmTMXLlz4559/jhkzZvz48UuXLlVS= >>> >>> >>UnJ1dYVzXaePtoSvnw9kA7a1tR01atTPP/+sqalpY2Nz8+bNnJwcmJ86IyPjxo0b9vb2tra2Xl5= >>> >>> >>eUPAUFBR4eHjY2dnZ2tra2Nj4+fnV1tZyOJz4+HgXFxd7e3tLS0sXF5c3b97ALdTZ2dk3btyws7= >>> >>> >>OztrZ2d3cvLS0VCAQ8Hg9mvrazs4M3gVmlqFTq/fv37ezsLCwsrK2tk5OTqVRqQkLClStX5s2bJ= >>> >>> >>yUl1bdvXykpqblz52pqampoaIwfP56EYejQocOHDx84cKCUlNSgQYMGfhgDBgwYOXLk5MmTJ0yY= >>> >>> >>MH78+AEDBkAr+MCBA3V0dGD6hU4fcwlfO9oBFotlaWk5atQoVVXV3NxcqCwiLxePx2tqaoI51Ju= >>> >>> >>ampB7HR3kcrnQYycUCtERLpfL4XBg5iKCIGBiDg6H09TUBG8C9Vd4c3hn2JnGxkYKhVJYWBgWFu= >>> >>> >>bl5eXp6enu7m5kZKSqqrps2TIxakL06dPnu++++/7770ePHj1y5Mgff/xxyZIlW7du3bJly9atW= >>> >>> >>7dt27alFTZv3qymprZ161Z9ff3r1687Ozvb29svWLAA3VBHRwfqG10x4BK+dqgD0Mc2d+5cd3d3= >>> >>> >>OH2jpQ9u1sFXS0SrNQ2Bxc20Pv7er3A0Njbm5ubGx8fb2dnp6+sfO3Zs9erVv/7667Rp0yZNmjR= >>> >>> >>y5EicoIMHD54xY8acOXPmzJkze/bs9evXGxoampubm5iYmJiY2Nvbh4aGZmdnZ2Vl5eTk5Ofn53= >>> >>> >>4YFRUVMG8zhUIxNTX99ddf+/fv37dv35MnT3aR10bC17YCNy3hHWAwGBYWFocPH87NzRW2THYCP= >>> >>> >>+PlkAjMGiVsmQpFzLQstuUfJ3pDQ0NWVhbMfxgYGHj//v2LFy+uXr160aJF48aNGzZs2KBBg4YN= >>> >>> >>GzZx4sTffvvtt99++/XXX2VkZNauXausrKyioqKrq3v//v1nz56Fh4eHh4enpKTU1NQwGAwmk9n= >>> >>> >>Y2AhzK3389XgvCgsL3dzcZGVlBw4cuGfPnrKyMok9SxzdzFeBQIAHg8MPNBrNz88vKioKtt4uCD= >>> >>> >>BAXkJyo+gzBKj1BgYGPnjwwMLCQllZGRJ0ypQpP/3008iRI6WkpIYOHbpkyZItW7aoqqoePXr0z= >>> >>> >>p07/v7+AQEBT548iYyMzM7OLisrKy0thboyNBog1eUzCApamZMpFIqBgcGwYcP+/vvv8PBwiT1L= >>> >>> >>HN3JV4Ig8BJq6CCPx6NQKHhcfRvvhstXeGc81Q8El8utrq7Ozs728PBQV1efNWuWtLT0999/P2D= >>> >>> >>AgL59+w4ePFhaWnrq1KkbN240NDS0tbWNiYkpLCwsKCioqKiApESatBj738u5z4ZQKGxoaKivrz= >>> >>> >>czMxs5cuSECRO8vb2FXRB4JOFrOwAnOChlCZHGKRQK3759Gx8fT6fT2xVMKKYDIAI1NTXR6fSSk= >>> >>> >>pKoqChPT089PT0lJaXp06f369cPCtGpU6euW7dOWVn52LFjd+7cCQgIyMzMbGxsbGpqEqM77rMQ= >>> >>> >>e5D2vl0fAQCAx+M9efLE29v73LlzI0eOHD9+vKenp0S+iqOb9QEc8Cfncrk1NTUuLi7Hjx/Pzs5= >>> >>> >>u7w3RB0gvCoWSnp7u4eFhZGR06NChv/766+effx48eDBcJ02dOvXo0aNXrlxxd3dPTU2Fyx1Ywo= >>> >>> >>5o6eUS6zCub3RFeC6cB4yNjVVVVffu3Qtj5Tw8PDq3FdSWhK/tBpxnWSxWRESEn5+fvr7+xo0bU= >>> >>> >>1JS2kgIXATy+fyGhobc3FwfHx9dXd1Vq1ZNmTJl2LBhQ4YMkZKSmjhx4ooVKxQVFTU0NDw8PAoL= >>> >>> >>C+HaCN0EDQJOU6KV+x5f5Il96DiAKF572bJlmzdvHjVq1IQJE9zd3aETuFOawNuS8LUdEIqCO4V= >>> >>> >>CYVxc3MmTJz09PS9evKikpATdTh/nK85UDocTGxvr5uYGL58wYcKgQYNIJNLo0aOXLVu2ZcsWPT= >>> >>> >>09b2/vnJyc0tLSmpoaNpuNZ2BFVBBieatbzwBES0HeRXyF8a+rVq06derUjBkzJk6cCPnaKfcXa= >>> >>> >>0vC1zYBkQCSpqGhwcTEZP/+/YmJifb29hoaGhkZGWKEIDBa4OppWVkZrPG5dOlSaWnpESNG9OvX= >>> >>> >>T1paevv27efOnXNycoqNjS0pKamvr29qamq9Hhd7wNZ0xPHeEzprNOBnyFdXV1c7O7tnz57BKcL= >>> >>> >>Dw0NizxJHd/IVeZXg3/j4eA0NDUdHx7q6utDQUB8fHyqVKhTZvPANTFAW8ng8Mpn8+vVrb2/vY8= >>> >>> >>eOzZw5c8CAAQMHDpw2bdry5ctVVFRcXV0LCwvZbHZTU1Onr987Hejthf/C/Fl1dXXv3r3bsGHD5= >>> >>> >>MmTJfrre9DN8hUZs4RC4Zs3b9zc3GBOl4aGBhaLhWZk6CbFxWpBQYGjo+OJEydWrlw5derUgQMH= >>> >>> >>Dho0aMaMGbt37/b09ExLS8vJycG1UoClXe9S9ebzICa5oSkXdru4uFhZWXnatGkeHh5d0XMJX9s= >>> >>> >>K3AYEtU8ajQaDWpBAhWzGg01LS0uDgoL2798vLS09aNCgvn37Tpw4cdWqVQYGBv7+/nAXOFowiS= >>> >>> >>3ku+IpOhG4fiwQCKqqquh0ekFBwYYNG6ZMmXL9+nXone7cRiV8bSuQUOHxeAwGA0pQoVDI5XJfv= >>> >>> >>37t7+9PJpMRm2Fwqr+//8GDBydNmtSvX7++ffvOnDlz+/btDx48KCsra2hogHowgb0JkPqtDVJd= >>> >>> >>8TgdhFC0jwM+L51Ot7CwcHJySkxMVFJS+vHHH83NzblcroSvLdD9+kBzc3Nubu7NmzdhsJ9AIGA= >>> >>> >>ymXZ2dhoaGpmZmVCmvnv3ztHRcceOHbNmzRowYMCQIUNkZGTOnTvn5+dXVFTE4XBwWyl08CIvF0= >>> >>> >>7Qr5avQmw7IeRrYmKivLz8xo0bg4KCVFRU+vXrd/LkSbhY7NymJXxtB4RCYVNT05MnT86ePfvmz= >>> >>> >>Rv4U8H93Bs3bkxLS6uvr4+NjT127BgMiRoyZMicOXMuXLgQExODdkGK2aGQq0z4AVvYV0hZXH+F= >>> >>> >>gxAQEDBjxgx5efmAgIDNmzf369fvxIkTEr6Ko5vlK0EQFArl33//DQkJaWhogFRjs9lWVlbr1q1= >>> >>> >>zdXU9d+6cnJzc0KFDBw0aNG7cuJ07dwYFBdXV1aGu4n1rYz+/Qr4SLe0DAICMjAwFBYVly5YFBg= >>> >>> >>Zu3ry5b9++Ojo6XbHFQMLXdkAoFMbGxl67dq2oqIgQebm4XK6dnd306dNnzpw5dOhQEok0bdq08= >>> >>> >>+fP+/n5ZWdnw7VXV3hBvyzEFoUsFsva2lpbWzssLExZWbl///7a2tpdscVAwtd2tMXn8589e+bg= >>> >>> >>4FBVVYWsTkVFRUePHoVe/vHjx+/cufPp06cwUx/aOPD1L/bbBTF7FnwbqVRqfX09rHc8cOBAbW1= >>> >>> >>tiXwVRzfzVSgUlpeX5+fnw5Uvl8uNjIzU1NScOHHid999t3DhQmtr69LSUmTnF2IRg13RpS8F3J= >>> >>> >>KF1G5kv1NWVu7bt++JEyfgyrJzm5bwta0QCoUweQn0qSYkJNja2q5YsaJ///5SUlK7du16/vw5l= >>> >>> >>UrFL0FM/Sb1AZQbAa4aKysrGxoaioqKoH1AV1dXIl/F0W18BQAUFhYGBgbC/FCRkZHr1q0bNmxY= >>> >>> >>//79f/vtt8WLF3t7e8PlMF5dTYhtaPn2+IrsWUKhMD8/X19f393dPS0tTVVVtX///hK+vgfdw1c= >>> >>> >>49d+7d8/JySk/Pz8wMHDlypX9+vUbMWKEkpKSh4eHtbV1aGgoXF4IW+Lbk6wEpr8i+0BMTIyCgs= >>> >>> >>KVK1cSEhKUlZUHDBigo6Mj0QfEAXWm58+fy8vL37x5E/K14xTB5SL8NzU19dy5c3fu3LGwsJg5c= >>> >>> >>yZcWllbW5eVldXU1Li5uQUFBcEcLUS3J+z4IoCDg5Jo02i0M2fOqKurh4aGqqurS0lJ6erqSvxb= >>> >>> >>4kB8Xbly5Y0bN9Ce944zBm2ogtqqq6vr7t27NTU1p06dKiUl9ffffzs6OtJoNABARUXF2bNnHz9= >>> >>> >>+zOFwvklp2hr41AG3slEoFC0tLXl5+bi4uFu3bv300087duyA5Xo6t+kez1eCIOLi4g4fPhwaGs= >>> >>> >>rlcsUqSX82kA5aWlp6+/ZtBQWFH3/8cfjw4X369FFUVHz+/DnKbVZUVKSjo/PgwQPI12/MFPBe4= >>> >>> >>Bo5HITCwsJdu3adPn2aQqEkJCRMmjRp8uTJT58+RaaSzkKP5yubzfb09Lx8+XJJSQkhypzfwfUN= >>> >>> >>ol1NTY2RkdHEiRP79+9PIpEGDRq0bdu26Oho5P0nCKKhoSEmJgYauXAt4psHrsKyWKy4uDhYLC4= >>> >>> >>+Ph5u6XFzcyPel120I+jxfKXRaPr6+np6etCGj6KqO3JboSgO68aNG5MmTerbty8MBjh48GBubi= >>> >>> >>4yAoiZHr9VU0Br4KvJ1vvFExISpk6dOnr0aE9PT0LCVxwAACaTeevWratXr0JDvRDbzPTZt4U3o= >>> >>> >>VAohw4dgpJ12LBh+/fvz8vLA1gEIAx7bW5uZjKZHA7nGzYItAZiKvzb1NSUl5dXXV2N+DpixAi4= >>> >>> >>xaBb+SoUZY7+CMQsOPi1QswLgr4SOy7WHP5tW3rPZDJdXFyMjIxKSkrQ5W3nK66HIcLB49HR0cu= >>> >>> >>XL+/Xrx+JRFq8eHFERASuBkCmEgRBo9ECAgLS0tJgPGiv0l/R9JKRkaGtrR0eHg4AiIuLmzRp0n= >>> >>> >>ffffcF5KtAIOBhaG5uRh+QpOHxePhGEfTa4YH3+FyJTkCsEn4Abek9lUo1MDA4ffp0aWkpgZmi2= >>> >>> >>vj86Hzo6+fz+TAqnkwmnzt37ocffiCRSBMnTnRwcIBjhF8If6qysrLTp0/7+PigUnW9Qb4KsexM= >>> >>> >>AABfX98lS5b4+fkBAHJzc+Xl5b///nt3d3dhZ6d4+bQ+UF9ff+PGDWNjYysrq3PnzhkbG5uZmV2= >>> >>> >>5cuX58+cVFRUhISEpKSko1Bz9xX9+IeZGF4iynkOWE60seUR7OAcAqKur271796FDhyoqKpA+0K= >>> >>> >>4hwF8klGolKioKlqEjkUg7d+6EyvF7O1BaWqqnpwftWaArS099VcBlEADAx8dnyZIl/v7+AAAOh= >>> >>> >>3Pt2rXvvvtOS0sLjlsnDsin5Wt4ePjatWtPnTp1/vx5aWlpVVXVa9euLV26dM+ePc+ePTt37ty/= >>> >>> >>//6L7zQXirRvvJeQ0PAnR/MmZDPuhhablNvS+7q6uj179hw5cgRV0mnvEKAXBoVTUSgUfX390aN= >>> >>> >>H9+vXb/bs2Q8fPvzQViQAQHFx8alTpx49eoT7t9rbh54FsdkSAPD06dPVq1cHBgZCfcnR0XHIkC= >>> >>> >>GLFy9OTk7uPr4CABgMxuXLl3fu3Jmdnf3s2bPff//94sWL7969O3PmzIYNGwICAgwMDDw8PCgUC= >>> >>> >>sweBQCAdETGHaQtEATBZDIbGhoQL3EGtFaF29h7Mpm8f//+w4cPQ/kKj7drgISilZNQtNvTx8dn= >>> >>> >>8uTJJBJp2bJlAQEBHymQBACoqqpydXWNjo7mcDhtb7RHAxcu8EhVVZWHh0dycjJBEDwez9bWdsi= >>> >>> >>QIbKysikpKd3K14aGBnt7++vXrzc2NoaGhv7+++8GBgZVVVW3b98+ceJEZGTkqVOnjh496u3t/f= >>> >>> >>Tp0/T0dLgHv7a2Njg4GBaTCAoKqqqqgvvvnj17FhYWVllZCYUrlUotLy9ns9nNzc3V1dW1tbVoM= >>> >>> >>1Pb9de6urq9e/cifaC9Kx5cz4bvW1lZ2aFDh/r16zdmzBhnZ2foVPxQfwAALBYrLy+vtxXfwidD= >>> >>> >>qPLBnOAEQfD5fBsbm0GDBi1dujQpKalb9YGmpqaSkhJYRDgkJGTBggXm5uZUKrnPbZ0AACAASUR= >>> >>> >>BVLW0tDQ1NTUrK0tTU3POnDmmpqYeHh66urqBgYEsFiswMFBeXn779u2nTp1SUVF58OBBTEzMtW= >>> >>> >>vX7t69e+fOHTMzs7y8PB6P9/DhQ0NDw8LCQgqF4uLicvPmzdraWtStNvYeyVfo/RN77z8JpLPCC= >>> >>> >>7lcrpeX18yZM7///vsjR47k5OQQoti5D92z9VzRGyDEjK8CUdQLyidiZWU1ePDgZcuWdas+gM6A= >>> >>> >>CAkJWb16tYeHB3Q8AgDKy8uPHj2qoKDw/Pnz2NhYeXl5BwcHBoNx+/btCRMmKCoq+vr6ent7BwY= >>> >>> >>GXrhwQU1NLSEhITIyUlFR8fbt2wwGw8TEZOXKlenp6dXV1ceOHTt58iSsJIH02o88J9L0yWTyvn= >>> >>> >>37Dh48WFZWhoamvfYBgShUoL6+/vjx41JSUrKyslFRUTD7n1iCbDE0NzdDP3DvKcaJ1qboSGNjY= >>> >>> >>1RUVEFBAUEQfD7fzs5u0KBBy5Ytg+WP8ZV0B7n7afsrOi8kJGTt2rX37t1DCXNKS0vPnTtnampK= >>> >>> >>o9FSUlLk5eUdHR0ZDIabm9tvv/125swZeN/IyMj169efPHmyvLy8qKho3759xsbGVCrV1NR0xYo= >>> >>> >>VaWlpVVVVx44d09PTKy0thQWrUlNToYP+40OG1luHDx9G/oJ2DQqUB0gZyM/PX7du3ejRow0NDW= >>> >>> >>ENLSG20f69d6DT6c+fPy8qKuptfEXjDAB49erV9u3b0XrL2dl5+PDhy5YtS09PB1g1h27l65MnT= >>> >>> >>xQUFP79919ogiUIoqCg4OzZsw8ePAAApKSkrF692snJicVi3bx5c8mSJb6+vlAEhoeHq6mpwYjm= >>> >>> >>jIyMHTt2WFpa0un0q1evrly58s2bN4WFhXv27NHV1S0qKioqKvL19Q0NDa2rq2v9bGJ0BADU1tb= >>> >>> >>u27fv9OnT5eXlrU9oC5BwpdForq6u48ePX7BgwcuXL8XG90P6a2VlpYWFRWRkJMqg0XsUWaj6Q3= >>> >>> >>vWokWL/Pz8CIIQCoVBQUHz5s1btmwZ1F/F7D8dafHTfIUv07t37wwMDBYvXgz5CrXssLAwVVVVd= >>> >>> >>3d3Ho/37NmzJUuWGBsbl5eXW1paLly40NfXF/HAwcHBwsLi+fPnBgYGcnJyvr6+bDbbxcVFUVHR= >>> >>> >>39//8ePHK1eu1NbWLisr43A4dXV1FAoFpaD6eO/r6upOnDhhampKJpOJ9s848HyogURFRcnJyQ0= >>> >>> >>ePPjIkSP43T5SkFYoFObk5Njb28fHx8PVRi/hK673AwD8/f2XLl0K7a8AgLdv327btk1GRiYiIg= >>> >>> >>LNTsKWVvbPw6f5Clchr1690tHROXTo0IsXL6BWx+PxAgMDjx8//uzZMyaTGRgYuHfvXjs7u+TkZ= >>> >>> >>BcXl/379//3338oOVRqaqqFhYWJiYmWlpaxsXFhYaFAIEhLS7t8+bKdnZ2Tk5Ourq6bmxtM6YNs= >>> >>> >>W+/tj1DkPoUjRSaTtbW1r1y5Ul9fT7Q/WBvpwTU1NefPn//uu++mT59+7949+Iwfj/aCxruEhIR= >>> >>> >>Hjx7V1NQgEdL21nsu8GGBPtht27YFBwfD366kpGTnzp0///yzra0tlUpFfhxhe1zl78Wn+Qpnfx= >>> >>> >>qN9vbt2+LiYjqdjgz+ZDL53bt3dDqdy+VWVVXl5uaWl5fX19eXl5fDkg9QbYCMLysry87Ofvv2b= >>> >>> >>V1dHfxRuVwu3G4K1YC6ujoouYUf9m+15iuFQjl//rybmxvMSPXZwxEfHy8rKztkyJAjR44UFxcL= >>> >>> >>Wu4T/NA9BQJBVVVVXl4erL7ZnaXBvyzEfiMGgxEeHp6fn08QBOSrhobGpEmTrl+/3tDQALBCYl3= >>> >>> >>OVwGW1wm+PUi8w3/R0hjJRdxuj0MgCp0hROlUQUugpfqHHgm/GzxSVVUFq05+nOgfAryKx+N5eX= >>> >>> >>mNHz9+3LhxDx8+RI4u/JyPXN4pQbc9CIgVgpY1baBvCADw7t07DQ2N2bNno20X6KoONv0JvuIGN= >>> >>> >>ry7hGjHCGi5/wRJI1xrQUwisGT7iFg4UwmCgEWh2shXgUAQHx9vYGCQlZVFtG2xJTZlw5MrKyuP= >>> >>> >>HTs2ePBgGRkZmNad+LBMbT2Cn/eq9Fygx0R85fF4LBYLTjKQrzt37hw7duzVq1fFPCkdHKJP219= >>> >>> >>bA1/uoYz6+Goa/cWZKtZjMSrjnz/5wyOiC4VCPz8/PT293Nxc9NWHlEj8/vjz19fXu7m5ycnJyc= >>> >>> >>nJ3bx5k8FgtN3439zcXFRUlJeXh4pdtfHCHg1cXhAEAQnq6+sL0zQRBFFZWamnpzdt2jRDQ0NYh= >>> >>> >>ZlomzT5JNrEV5xGYjMgi8WiUqlI5hOtRGBr2YN/hX5j3HT6yR8engYvcXFx2b17d3Z2tpgS8qGr= >>> >>> >>Wj9UaGjowoULpaWlL168WF1d3XYzKgCgsbHx1q1bjo6O0J7QSyAmmKBtXlVVNTQ0lCAIgUBAo9H= >>> >>> >>Onz//008/nTlzBvosO4WsRBvtWUQrcYi+zcrKunfv3tu3b99L0zZCIBCgctSffDD0LVSdTU1NN2= >>> >>> >>zYAO3SYn345OMQBFFfX3/58uURI0ZMmjTp/v37KEynjWPHYDBMTU2NjY1hEkLiw2/LNwZEAyg4H= >>> >>> >>j9+/Pfff8P4V6FQyOfzzc3NhwwZsmnTpoyMDFzSdbDdNumvRKvIf6FIxY6KitLS0goJCYEKK55x= >>> >>> >>F6ejsJVwRfOyUChsaGjIycmpq6sDIh/0h55N2FLx4PP5FhYWKioq6enpeEMf4auYMpCdnb1ly5Z= >>> >>> >>+/fqtWrUqPT1dIGiHDwby1dLS0traGmYiEvYaLRb/laG/YOHChdBfAGFnZzdw4MApU6Y8efLkve= >>> >>> >>WePw9t1V9RG2jPNIfD4fF4z58/37Fjx61bt+Def7R4QnYA9AEJxdYoLCz09vbOyMjA9/F9RAcVi= >>> >>> >>ra98/l8a2trFRWVtLQ0dMJHjKA4nwAAbDbb29v7119/HT58+MWLF+vr64XtWcMCAFgsVkBAQGho= >>> >>> >>KEyW0XvIii/EAQCxsbEnT5589eoVOgj5OmLEiLt370KzJrq2O/gKAOByuQUFBbACeU5Ojq+v78u= >>> >>> >>XLxMTEw8ePHjx4sXk5OS3b9/W1NTAUJX6+vri4uJ3797l5+cXFxdD4yiNRisrK6PRaDwer66urq= >>> >>> >>ysDNZACw4O1tbW9vX1pdFoH2cMEthovIKCgo4dO4bXvvoIXwmM8QCA2tpaPT29oUOHysrKRkdHo= >>> >>> >>0CCtg9fc3MzhUJhMBhiJrBvG0LRGgM9b0NDQ3FxcWNjI4oNCg4OnjVr1qhRo7y8vKDdAF3bkabb= >>> >>> >>ut4iCCItLe3s2bPXrl2zt7c/fPjwzp077969m5OTc+DAAVlZWbhh5uLFi/B29+/fP3LkiK6urrW= >>> >>> >>1tbGxsb+/f2NjY0pKyuXLl//777+6ujp/f//Lly8nJSXR6XQ3N7d169Zdu3atoKAAOSM+IiPRMw= >>> >>> >>MAKioqrKys0FT+kUcV00kAAG/fvt2yZYuUlJSOjg5cMH2c6x8aQYDFhfUGyoqpXoKWZnX4b1VVl= >>> >>> >>Zqa2vfff//w4UPI105Rlj693oI/IYVCMTY2Xrhwoaur6+3bt2fNmqWkpPT69evy8vL9+/cvXLjw= >>> >>> >>zp077u7uioqKZ8+eLS4u9vDw+OOPPzZt2vTw4UN9ff1jx47l5uampqauX7/+1KlT1dXV//3337p= >>> >>> >>16x48eMBkMv38/Pbu3evt7Q29mm1/MAAAlUp1cnLC9YGPKK+4iZsgiNDQUFhT2M3NDYYrtFe+8v= >>> >>> >>l8uFLE7Sdtv7yHApGPEL3hLBYrPj4ebvmEJk46nb5r167vvvvO0dER6ordx1cAQHl5+YkTJ/744= >>> >>> >>w9PT08fH5/Zs2erq6sXFxdXVVXt27dvz5490Fu7d+/egwcPlpSUZGRkbNiwwdDQsLKy8vbt2xs3= >>> >>> >>bnzx4kVhYaGampqurm5dXV1ISMiGDRsePXrU3NwcERGhp6cXFxcHpxJhm7120Hrq6OjYFr4Solh= >>> >>> >>VOMRUKtXIyOjHH3/csGFDamoqWsC1a73FZrMjIyNfv36NUs31EhMshEAUq56cnHz48OGwsDAgcn= >>> >>> >>CSyeQdO3b069dPTU0NbV1u1/LgvWiTPUsoFMLtADDGMSIiwtDQMDg4mMlk1tbWnjlz5tq1axQKh= >>> >>> >>Uwma2lpwa0phYWFW7ZsMTMzY7PZDx8+lJeXDw0NLSgoUFNTO3nyJIPBiIqKUlZWhovH8PDwM2fO= >>> >>> >>wFh0AvNHtKX37eKrQFTgisvlPnjwYO7cufPmzfPy8oI7tNC1bedrQ0ODtbU1jOogsJqdbbm8RwM= >>> >>> >>fLgCAv7+/rKysr68vsoJTKJTdu3eTSKR58+bl5OSATtpl0FZ9AAAQERFhYmKSkpLy5s2bnJwcuB= >>> >>> >>00JyfnyJEjNjY2dDq9rKxs7969u3btqqioKC4uVlNTu3DhQmFh4Y0bNxQUFKKiooqLi7dv366lp= >>> >>> >>QXdIcuWLTtz5kxNTc2LFy9OnToVGhpaXFycl5dHo9Ha3vt28RV9W1paum3btuHDhx88eBAGegtE= >>> >>> >>e9DbPqyQrxYWFqampvX19ehl6A18xZUfAICvr6+srOyTJ0+QFZxKpe7atYtEIv3xxx/Qm9MpKtO= >>> >>> >>n+YoCGmDYtbq6uoaGxqFDhwICAthsdlJS0oEDBywsLOrq6tLS0vbt23f48OG8vDxYl3HFihUaGh= >>> >>> >>pr1qy5ePFiRUUFi8Xy9PRUUVHZuXOnqqqqtLT0X3/9lZqaWlRUdOnSpY0bNx4+fDgyMpLJZLZx1= >>> >>> >>mgXX9F8JBAI7t69O2nSpGHDhp0/fx4lccdlRhtbZzAY5ubmV65cgZGQ7VInejqQug9E8a8+Pj5I= >>> >>> >>vjY0NOjp6Q0cOBDxVYjhsxttR/wALK20ffv2rVu3zp8/f+vWrbm5uQwGIzc3t7i4mM1mk8nk5OT= >>> >>> >>kzMxMGo2Wn5+vqqqqqqp69OjRK1euwDRpUA338PDQ1tY2NjbW09MzMDAoKSkRCARxcXGnTp06e/= >>> >>> >>ZsQUFB25+qXXwViILhORyOvr6+lJTU5MmTPT09PzvOGvpj7e3tLSwsoJe89ygDuMsK6q+HDh0KD= >>> >>> >>Q1F+ivcFj916tTZs2fDX7879AFC5MCorKzU19fX0dFJTEyMiIhQV1eXl5dPTU1FNn+ipS8ARpgb= >>> >>> >>GxtDKiO9ENpx6+vrmUwmjUarr69HFaoaGhqoVCpuq2tL7ykUioODQ2ZmJvEpASkUrR3T0tLWrVs= >>> >>> >>3YMCAzZs3wx2wnwf4LGlpaWlpaTDfW+/hq9hjslistLS08vJyJEcBANHR0X/88cecOXPy8/NB+7= >>> >>> >>fWvRdtWm8BAEpLS83MzPbu3WtjY3Ps2LFVq1adO3eurKwMnibAAACA22NUVVWtrKxgeDnAInRa+= >>> >>> >>7eIllxvV+9by9cPnQxbp9Pp9vb2EyZMGDx48JkzZ+BW9ba3KAakreJZaj77bj0IiHnIRABaBmEB= >>> >>> >>AKKiombNmgVdsk1NTURn2E/atN4iCILP5zOZzJiYGFdXV0dHx5CQkLq6OhirCi2aeF43JpMZHR3= >>> >>> >>t4eGRlJQEs6ARHXZsfKj3FArF0tIyMjIS7U340Mnwq8zMTFVV1QEDBvz666+PHj3qeE0I3KDbe0= >>> >>> >>IK0ZPCX5xOp+fn5+PuSQDAy5cv//rrr4EDBx47dgzmzu8OvsJshELRShA63JAsFLbcgIDEjFi8N= >>> >>> >>tF5EWViva+rqzM0NHz06BGTySQ+FT8gEAiePn06b948KSmpAwcOwPmrIx1obm7Ozs7OyMhAtXt6= >>> >>> >>iT6Au3UgNXV0dF68eIFOAABkZWWpqqoOHjx4165dkGEdH5xP8BXJTpQODUl+ARZVKBZUhb5CJgx= >>> >>> >>0Zqfztb6+3sbG5sWLFyjn3IdaAQCQyeTz58+PGTNm3rx5T58+hZsKO9I6k8m8ffv2jRs3YBR9Lz= >>> >>> >>FmEe+zv65cuRLu4EcH6XS6iYnJhAkTUO2NLpevAixaSiDasgP7hL7iYxXSCMzMgV/VRTucAAA0G= >>> >>> >>u3ff/8tLCwEn/L4CQSCly9fbtiwYdmyZTdu3KDT6UTHxCG0D1y/fh3erfc4C4iW+bMgh9TV1Z8/= >>> >>> >>f05gOj2Xy/X29paVld26dWtsbKyYM/zz8Gl9AP1FIpbAdpwJMRCYvoueB2f5Z/dSrEu4Uk+lUt3= >>> >>> >>c3PLy8sS+xf8lRLZ9ExMTaWnpLVu2wP1eRGfw1dnZ2d7eHu0m7w36q5jZHwAQHBy8YcOGkJAQfN= >>> >>> >>XF4XCcnZ0nT548Y8aMW7duIbthR5r+tD0LoTUPWreNE1eMyp0CIWb5g8woKSm5evVqXFwc8k7hL= >>> >>> >>eLr95SUlG3bto0aNUpLS6u0tLTjHQMAsNnsp0+fPnnyBO5aFnbYP94jILYygfbXK1euoOyZEDAl= >>> >>> >>irS09NixY52dnWG90u7j69cA/H0gCILP58fHxx85cuTBgwcwYlpM2BMi3Z9KpcJ8y/PmzXv48GF= >>> >>> >>nVULk8/kUCoVCoaBInd7AVwghpn2h+FchVhagubk5NjZ2yZIl48aNc3Bw6JRysj2MrxA4KfPy8g= >>> >>> >>wMDGAuQZx8cLzgZ+i/kJWVHThwoJ6eHtT9O0v2wwUoztdOnE++ciCpIRAIeDwejMnE9dq6ujo1N= >>> >>> >>bXRo0efOHGisrKy4y32VL4SIsFJJpMdHByys7OJljxGNjWCIPh8/oMHDyZOnDh16tTg4GBc+nYE= >>> >>> >>kKbV1dU1NTW9KnIAAtfKKBRKcHAw2lWP7Fx0On3Pnj39+/dfuXIlDNrsXfoABM5X6C+Iiop6r00= >>> >>> >>NDlxVVdXRo0eHDBkiLy8PLQm4oeOzuwEAYLFYjx8/fvToUUNDQ+9RBvB1AvRoxsbG7tq1C8a/El= >>> >>> >>heAjabbWZmNmLEiPnz579+/ZrozvXW1wO0DId8NTc3h3nwCGw4EHW4XC7MDD5ixAhdXV1kKBWzD= >>> >>> >>X8GAAAMBsPa2trU1BRu7u0lIha3XRKieMKlS5cGBASIeWUJgoiIiJg0aZKMjEx8fHzHm+6pfEUa= >>> >>> >>Un19vbOzs1i8CxKxAICqqqrTp0+PHDly3rx50JHdWaxCfDUxMYHxWb1HeUUrKkLkL0D1twjMmgk= >>> >>> >>ASEtLmzp16ty5cyMjIztFB+t5fEVAfE1PTyfel6SDIIhnz54tWLBg0KBB2trasNQH0UleU2jTdX= >>> >>> >>R0tLS0pFAonXXbngI0yACAuLi43bt34/oA+grydfz48d7e3qjM4Gejx/MVxhNmZGTAI4gxQtGO7= >>> >>> >>VOnTg0bNmz27NkwqUfnts7hcKKiogICAhgMhrAz8vH2FIipBDQaLTw8HNYvwL8FAOTl5S1atOj7= >>> >>> >>7793cXHpFB2sZ/MV2gfevHkjJlYJghAKhc+ePfvzzz8HDBiACh51bgeEQmFDQ0N1dTWMDus9fEV= >>> >>> >>PilaZKFgPX3dCk5auru748eOdnJw67uns8XylUCjOzs5v3ryBRxBfoTEF5saaMmWKh4cH2lUsdu= >>> >>> >>ZnAxIU2l9x/3Pv0QrQwpfH4zGZTBTSKcQMOFwu18XFZcyYMZqamu/eveuN9gEEyFcbG5vo6GjcH= >>> >>> >>wu/yszMVFJSGjhwoKKiYnx8PD5/EZ0ULMbn8+l0Oira2PF4jh4BNJLISpOfn+/h4YHKleF8hbmg= >>> >>> >>paWllyxZggIOPxs9nq9kMtnIyAi6WHGiAAACAwOnTp06fPhwWD2mc5lKiOyL/v7+Pj4+DAaD6DX= >>> >>> >>rLTiAaD6B8S5KSkoo3oXAEvYLBIKkpCQlJaX58+cHBQVJ5CvFwsIiPDwcr+UJAGhubnZ2dh41at= >>> >>> >>ScOXP8/f3x3QedyFe4n/vatWsoK29vAL5UgEt+X1/fRYsWQfsrPI6iKwEA1dXVR44cmTBhgr29P= >>> >>> >>dTKPrvpHs9XMpl87dq1gIAAVLxUKNogqaGhMXTo0CNHjsB9Zp2uWUK+WlpampmZiWWR7sRWvlrg= >>> >>> >>Xhs/P7/Fixej/K+4HQBaaWC6fVhGvVfzlUKhXLly5fHjxyjkiiAIDofj5eU1efLkuXPnBgQEwBx= >>> >>> >>Ena5ZQr6amZmZmJhA/xbRO/iKNAHE17CwsK1bt4aHh+NOPiSD2Ww2LMSnoqKSl5fX2/lqZ2eXkp= >>> >>> >>IiwGqVZGVlqampjR079vTp06isZlfIVxaL9ejRo//++49Op/ce/xYe/wopW1paGhQUBEv44qchL= >>> >>> >>TYmJuavv/6aMWNGQECAQFSm5TPwLfDVwcEB5teGXGlsbLSzs5swYcLMmTMfP34M9drO3eOA0Nzc= >>> >>> >>XF1dXVVVhSqN9Qa+Eti+TqSqouNESwMClCCJiYlLliwZNmzYzZs3O+Ll6vF8Fcs/QBBEYWHhpk2= >>> >>> >>bSCSSnJxcamoqHDJYo7lzW0erY9BrdsYiIOEqEO3Pa2xshElDiJZRR3CIcnJylJSUhgwZYm5uDi= >>> >>> >>PrPw89nq9kMtnR0RH6twiC4PP5fn5+v/32m5SU1KlTp2DRZBiZ0fbCL21vHdYzKiwshPkgehVlC= >>> >>> >>azoX2Vlpbu7e0ZGRmvBCflaXV29d+/efv36KSsrFxUV9V75ivMVqgcnT54cNmzYr7/+GhAQgKbp= >>> >>> >>rvCUAgCYTObdu3fv3LkD09j0Hn0Af1IAQFRUlKqq6tOnTwG2iU0o2m1KEERjY6ODg8PPP//8+++= >>> >>> >>/p6WlASwjebsGrcfztb6+3snJCcYTCgSCoKCgP/74Y/DgwVpaWrDCPNKxOp1JQFQfBsW/9h6+ov= >>> >>> >>UWQRAAAB8fH1Sfm8D0VzS5NTc3v3jxYuHChb/88gtaVCBC9yK+UigUR0dHmLGxqqrq+PHjQ4cOn= >>> >>> >>TJlipeXF26R7QomAVE+zatXr9bU1IBeE68NgVtYnzx5snTpUhT/iiAUBSILBIKsrCwVFZXhw4fv= >>> >>> >>3LkzLy9P2BJtbPQb4SuMd3n+/PmSJUsGDRq0c+fOrKwsfCC6gklQH7h586aLiwuK1+4l8VlES75= >>> >>> >>mZmaeOnUqIiJCbOkpEO1KIgiCxWJZWFiMHDly3Lhx3t7eKLlOu4IMezxfyWSyiYnJs2fPampqrK= >>> >>> >>2tf/755x9//NHNzQ2GEyBLYRe1zuPx0tPT09PTYVq79kqLHgrcIwCPsFiszMzMiooKdAIesMYXl= >>> >>> >>W8PCgqaNWvWwIEDT58+DSPc2xsR2+P5WldXp6WlZWxsHB0draamNnToUHV19ZycHCHmgCG6LPOK= >>> >>> >>QCBABfTEAsS+YaBnxNdVsJg8OgcZvJE+RhBEeXn55s2bSSSSvLx8SkrKZwiUHslXfGVKJpP3799= >>> >>> >>/4MABV1fX33//ffjw4Tdv3oRGFqJVvpmu6Ay0v+ISpe0NfbxvYgfxf9vbShcNArwhXPVmZWWhzP= >>> >>> >>oENtXANFaQtWw229DQEC4w7t27B/fSEe2xA/ZgvgpFGRk0NTW3bt26Z8+eUaNGzZ07NyIiAj+zq= >>> >>> >>6Udg8GoqKiA2li75CuSLmJpyHDlDz+Cz5sfmi7wS/ALkR6Jv1RiN/mMFwC5r169eqWrq/vq1St8= >>> >>> >>0dm6IT6fHxYWNnXq1AEDBujo6MCUe7ipEX+13vuAPYyv+C8BDdG1tbX79u1bvnz533//PXz4cE1= >>> >>> >>NzZKSku4J7QMANDU1BQQEeHt7w/gBYTsNEciRgTMJ/bpiv5ywFd57Q6ii4LVuxD4IW2aVxNtte7= >>> >>> >>eFmD4ARPu5UX0YnH/4BwBAYWHh6tWrSSTSqlWroJUAt2fhz/XeB+x5fIV6kkC0mZhMJqurq48YM= >>> >>> >>WLkyJHLly+HgbDd0xkg2s9tZmYGazC1V0VGv5ZYepgPfUZHAAaxr+AH/LX5yEE4niiZUtu7jfcN= >>> >>> >>AODv7//PP/8EBgai/iCCor/wTFgjaMaMGWPGjLGwsGAwGOgcsWvfi57HV3z2hPrA9u3bSSTSDz/= >>> >>> >>8YGpqCp+/28BkMm1tbc3NzeEIEi0LMfQeBAUFycnJQb5+EmQyWVNTc9CgQUuXLoUqRLvw8uXLHs= >>> >>> >>NXCNwIQiaTIV+nTJly9+7dju9wbzsAAI2NjVC+ovjX9oLL5RYWFiYlJcXHx8fHxycmJiaJkJiYm= >>> >>> >>JqaWlBQkJWVlZycnJWVlZ6enpSUlJCQkNgS6JLU1NTk5OTExMS4uLjExMTk5OSMjIzCwsLMzEx4= >>> >>> >>YVJSUnZ2dnl5eW5uLjwzJycnPz8/NTUVv88ngfc2JSXF0tJyzpw55ubm8D4JCQnJycnwEeLj49G= >>> >>> >>/SUlJycnJr1+/Pnv27E8//TR48GA9Pb3k5OT09PSUlBR4/se7kZWVdfPmTVglpWfwVYiZSAAAVV= >>> >>> >>VVKioqJBJpzJgxhw4dcnR0dHBwcHR0hB+6FE5OTlZWVmvWrFm7dq25uTk82PZ2nZycnJ2dr127t= >>> >>> >>mfPHkVFxVWrVikqKioqKq5Zs0ZBQUFBQUFRUVFFReXw4cM7duxYt26durq6srIy/HbNmjWKiooK= >>> >>> >>CgqrV6+GV61evVpeXn7p0qXLly+Hd1u1atXKlStVVFS0tbXXrVu3cuXKNWvWyMrKysrK7ty5U0l= >>> >>> >>JCV4FS1KuXbsW3q2NWLVqFfwA+zl//vxx48bJyMigzsAHaX0mbGXZsmVjxozp27fv1KlTly1btm= >>> >>> >>jRIjk5uTVr1sCng5e/tz9r165dsmRJbW1tj+Er0bJ8UkBAwOzZs6E+8Ndffy1atGjhwoULFy5c1= >>> >>> >>C2QkZGZNWvWrFmzZGRk2tv0woULZWRkVqxYoaura21tbWdnZ2tra21tbWNjY2lpCcvS2tvb37x5= >>> >>> >>09nZ2cbGxtnZ2VYEGxsba2treI6tra2VlZWVlZWxsfHq1asPHjxoY2Njb29/5cqV3bt3nz171t7= >>> >>> >>e/tChQ/r6+lZWVvv37//111+nT58uJyd3+fJl+ILt379fT0/Pus1AraPPDg4O169ft7e3t7GxQd= >>> >>> >>2DH+ARKysrS0tLGxEcHR01NTVHjBhBIpFIJNJPP/109OhRS0tLOzs7eE+8CRzOzs4nTpzoefIV6= >>> >>> >>gPNzc0BAQE7d+7cuHHjjRs3YmNjExIS4uPjX79+ndAtgHMimvXgLNn2a+Pi4tLS0mpqajgcDsyf= >>> >>> >>yuFwmpqampqauFwul8ttwoD+hR/QmfAzh8NhMplFRUW1tbXwYGNjY1VVFZlMZjAYtbW1dDqdzWb= >>> >>> >>X1NSkp6cnJCTk5OQwGIzm5mYWi1VeXk6hUFCjnwTeLjxCJpPj4+OLiorQU7z3QdAHWFfn6NGjI0= >>> >>> >>eOJJFIR48eLS4uRnf7SE8AAOHh4T1Gf0XmGPgBhglXVVUVFxfznEmINwAAIABJREFUeLz2au4Sd= >>> >>> >>Baio6PV1dXR/i2ibevOyspKY2PjrVu3+vr6Qi62Bc+fP+8xfIVA9kKUHw8CkbjtpplvD8h4gm9T= >>> >>> >>+cjJn9cK0seIlvZXolU1jvcCVXFjsVgNDQ1tL8IKepw9C5EVl7WgZVo8CWXFfAEfOfPzmkDFiQh= >>> >>> >>R/CuqJ0+08syJtQhfJGhHR7IGP+EbtL8KROnexegLgeou9TagVxfX8j/uxfgQsT4OfMAhXxcvXu= >>> >>> >>zv70+0DM56b3PNzc0wcgCRvu1blXoYXwUta9YJMRe8QBTH/nk/wJeC8MPOqs8AvAkUXWjLmvCjH= >>> >>> >>k78PW9jK2Ief4IgYmJidHV1X79+DbDUdx+6oVAUBMPlcj9Z9bf1A/YkviLnFj4ireXrl+5m+0Cl= >>> >>> >>UhMTE1+9egVTJYh9iz8R/q3YmVB9Ly0tDQsLe/78OdyDKibnPq4YtH3c8JGHrTCZzPr6erw+DNJ= >>> >>> >>uP3QHsZ+yjU33ML6KjVSPBppM8/LyDh48qKam9vr1a/hcKAgGSkr0sIgKeIFp9KsLBILw8HB5ef= >>> >>> >>mTJ0/C0KdP6q8d6Tn6AJtgsVgcDgcP1umK36iH8fVbglCkWTY0NJiamhoZGZWWlsL5FNEUupdx6= >>> >>> >>wcitFCU1g4xEgBQXV2tpqamra1NpVKFog3uXfRuo7cFWqbu3LmTlJSEvu2i1M0Svn5JQCaxWCwr= >>> >>> >>KytTU9OamhoCi8yHOmhjYyOVSqXT6TDEls/ns9lsFovFZDJhfgoo0rhcLpPJLCgo2Lp164kTJ7q= >>> >>> >>6ni3+8gAAwsLC1qxZA/cbtkUf+GxI+PolAX9aBoNhZWV19epVWAEQ/dIMBuPevXsXLlwwMzMzMD= >>> >>> >>AIDw9vbGyMj4+3sLDw8/O7c+eOl5cXTAiSmZl5+vRpTU3NgwcPzpw5U0dHp6v3P+KrBWgfWLhwI= >>> >>> >>dzPjexcXaESSPj6xSAUpZNvbGy0tbU1MzOD+/XQJJuUlLRmzZpz5869ePFix44de/fuTU5Ovnjx= >>> >>> >>4vbt29PT02/evKmkpOTj48NkMp2dnaWlpffv329lZTV//nwdHR24NaWL9Ff8EYSi+Ndly5ZBvgp= >>> >>> >>F9kQJX78p8Pl86IRksVi2trampqZQvkKJm56efvr06Xnz5nl7e7NYLG1t7fnz5wcHBxsZGamoqE= >>> >>> >>RHR1+/fn369OmXLl3Kz8/X0tJasGBBcHBwaWnpzp07T548CePHu8dgAgDw8/NbunSpj48P7i/oo= >>> >>> >>rYkfP0yQMKJzWbb2NiYmJhUV1cDAPh8flBQ0J49e/7444/Zs2c/ePCATqcfOXJkxowZT548MTMz= >>> >>> >>k5OTu379uqmp6fTp0y9evBgXF7dhw4Z169a9efOmvr5+586durq6MD9SF5FVTM0AAMTHx+vr60P= >>> >>> >>7a6c3h0PC1y8MAEBDQ4OJicnFixdhHvD8/Pzdu3fPnTt327Ztc+fOtbKyKikp2bdv39KlS93d3V= >>> >>> >>VUVBQUFBITEz09PadOnXrmzJn8/PwLFy789ddfd+7cyc7OhiGzVVVVXae84neG70NjY2NJSQksQ= >>> >>> >>obOkdizvjVA+VpQUHD06FF1dfWUlJT6+npLS8spU6aoqKj4+flt2bJFXV3d2Nh4xYoVOjo6L168= >>> >>> >>OHv27D///GNkZKSrqztjxoz169cnJibGxMQoKirKyMgcOHBg/vz5CgoK4eHh0BraRXYl3PIqxPI= >>> >>> >>PIA2kO+wDfd6HTm9SAghkXq2vr3/48KGnp2d5eXl9ff2dO3e0tbWfPXtGp9NDQkIMDQ1PnTp16d= >>> >>> >>KlxMRELpf77t07MzMzfX19R0dHGKP95s2b2traW7duHT9+3MrK6sqVKwYGBtHR0TDFJzTQdkXnh= >>> >>> >>VhcUUFBwePHj/Pz8wnRpt/OUkXE2AhzbUj4+gWA1tEAABikDM2odDqdQqHweDzoYa+tra2oqKBS= >>> >>> >>qTCaSSgU0mi0qqoqOp1Op9PJZDK8lkKh1NXVsVgseJDNZnedkEP9R/bXoKCgDRs2oHya7d1w+xF= >>> >>> >>I+Pq1QCjaSy0QRZESouy+yIopFgoDhaXYQch7olWINNGVzi0CMz5A++uCBQtQ/gF0QsdbkfD1Kw= >>> >>> >>JymcJ4Jdwz9N44Sfy01t+icz4ZIdVZnUdvmpj9tROFuoSvXxFwPuErlfeeib7CqYlIibOzS9UAv= >>> >>> >>Ank2ggICFi9ejXiK3pnOt6QhK8SdALwqQAAkJ6ebmtrCxO9o/VWp2gjEr5K0FEg2yqiI4fDoVKp= >>> >>> >>MP4VSfpOMcF+jK8dvLUEvQRiyjHSYtFKkRCF8HZ60xJ/gQSfCaRDQxNyenp6cXExi8VCIS+SeEI= >>> >>> >>Jvi4ge1ZcXNy+fft27dp1+/btyspKtC7s9BYlfO0okLGztwH3Fzx58mTatGl9+vRZsGBBWFgYtA= >>> >>> >>dL5OvXiC4NMP1qgUfWQvvrtGnTSCTSL7/88vDhQ8hXiXz9ugD9qG/fvoXBUF+6O90HZMlC+TJCQ= >>> >>> >>0Pnzp1LIpEmTpzo4+MD4yIkfP26AABgMBghISFpaWmofsGX7lR3ANkHUPzDu3fvduzY0adPn8mT= >>> >>> >>J/v5+cFcZl3RtISvnw8AAI/HKyoqqqur69JNzF8hcJcvAKCmpkZTU1NKSkpOTu7Vq1ddl19Hwtf= >>> >>> >>PB/q1AJZ4v5fwFZUogiMQGxsrKys7ZMgQLS2tqqoqQpJ/4OsEj8erq6trbGwUiz750v3qcuCbzq= >>> >>> >>F9YPr06YMHDz579iyNRgMti591IiR8/XwAAJhMZkBAQGJiIp58rpfwFZevT58+nTlz5uDBg8+fP= >>> >>> >>0+n04XtzDLUdkj4+vmAW6/s7e3v3LkDRWzX/U5fG/DwK8TXIUOGGBoaSvj6lQIAQKfTr127Zm5u= >>> >>> >>Dqv39gamEq1S0AEA/Pz8Jk2a9PPPP9+8eRO6ZCX5Xb46QH3Az88vODiYwWD0Hv21NV8fPHjwxx9= >>> >>> >>/KCoqxsXFEVjGyE5vWsLXDkEgENDpdCaTiZjaS/QBAqtgyOFwrKyspk+fvmfPnqysLCaTibK6St= >>> >>> >>ZbXx2gPQt6enoJWXEuAgBycnKUlZW/++67M2fO+Pr63r17l0wmE12ze0zC1w5BICouLLaV6kv3q= >>> >>> >>2uBnhEas8LCwqZNm/bjjz96enqamppu3LixoKCAkMS7tAXdSRcAAJvNTk5OfvfuHZKvvUTEEqLc= >>> >>> >>/ACAR48ejR07Vlpa2tfX9/Lly3Jycm/fvhV26q5DhB7JV1xZJDCO4kb7bugGtGe5u7u/fPkSesz= >>> >>> >>bVTqi5wKOMHxSFotlb28/cuRIaWnpR48eGRkZrVixAibOkKy3WjASbm4mWm4nQvNUN1AW2rOuX7= >>> >>> >>8eGRmJitj3Bn0A3xmbl5e3bdu2fv36/fDDD/fv3zczM1u9enVubq4k3oUgsJwo+HQDVzzdyVTUL= >>> >>> >>p1Ov3XrVlRUlFj2qO7pwJeCUJTpo7m52cfH5/fffyeRSGPHjvX393/69Km+vn5ZWZkknpAg3qcJ= >>> >>> >>CESFuPAcON2mD7BYrIiIiMzMzK7bAfIVQijaq81gMK5cuTJq1KixY8cqKyunpKRQqdT09HQ2m01= >>> >>> >>I9AGiZVo8+C+LxUpKSqqtrSVaBrl1T3/4fD6ZTIbOWKJ3KAMERsSsrCwlJaU+ffqsWrXqxYsXcB= >>> >>> >>xQupquaLoH8xXqT+np6RcvXoyPj4dk7f7Khkgb6SXKAIHtLwgODp44cWLfvn21tLTIZDKPx8vLy= >>> >>> >>4uLi0PRFJ3edA/jKwSuEnh4eCgoKHh4eMBkud3MG6FQSKPRYDJAdKQb2v0iwB9NKBRyuVxvb++x= >>> >>> >>Y8dOmzbt2rVrd+/ezcrKunnzpqamZklJCTIgdC56Hl+FWHlYFot14cKF8ePHHzx4ENqou5OvAIC= >>> >>> >>6uroHDx6kpaXh8cvfGGXRE+HPBQB4+/bt9u3bBw8erKGh4eLismnTJj8/v8uXL0N7loSvBCHSUJ= >>> >>> >>Fu9ObNG2Vl5QEDBvz555+hoaE8Ho/osgy9rQEAKCgoMDQ0DA4O5nK532r8K66DwTBtaGm+devWj= >>> >>> >>z/+OGbMGCcnp3v37q1YseLff/81MjJavnx5Xl6exJ5FEAQhEOUdJwhCKBSGh4fLyMiQSKTx48ff= >>> >>> >>vXuXxWIRXZz0FAcAoLi42MjIKCQkpKmpCYhKpXVD090GFBYoEIEgCABARkbGhg0bhg4dun79+jd= >>> >>> >>v3jx58mTFihX379+/dOmSnJycxF/w/0DLT4Ig2Gz2rVu34Lb3UaNGGRsbw+Jp3dYZAEBhYeGFCx= >>> >>> >>dCQkK+1XgXXBlAH6hUqpWV1Q8//CAtLe3s7MzlcgMDA+Xl5X19fe/fv3/mzBlYOETij23hWamtr= >>> >>> >>T1+/PjAgQNJJBKJRFq/fn1ubi7RLdlPIQAAZDI5ODg4Jyen6yr6fXEgPQdKCgBAQkLCypUrpaSk= >>> >>> >>1q5dm5qaShBEVlaWi4tLZmZmZWVldnY2i8WS2AcIQrTYgpSNj49XV1cfO3aslJTUqFGjFBQUYmJ= >>> >>> >>i0Ca47uwPDNEiuvFV6U6grVrIR2BnZzdmzJjvv//+xo0bHA6HIAgOh9PQ0MDlcqEoEUryvUGgKY= >>> >>> >>nH4wUGBpqamqqrq8+aNUtfX//u3buZmZkoBWm3dQnfC/pNrrfQVliCIHg8np+f38KFCwcPHqysr= >>> >>> >>AzXVTDPTV1dHYfDgf923Xvbw/gKAflaVFSUl5dna2u7efPmhIQEFovFZrO7OTyKx+Pl5uZWVFTg= >>> >>> >>xqxvjK+QfJCFMTExmzZtGjx48D///BMaGgrriTY3Nz99+vT8+fPp6enQdNB1cZU9jK9CrBwFHJH= >>> >>> >>Xr18bGBhkZmZ2f2cAADQazc3NLTo6GprSvj2yQkC+VldXHzhwYMiQIdLS0o6OjtBBIxAI4uPjV6= >>> >>> >>1a9csvv8B6RnAzTBeFVvY8vkJJhoKFKRSKg4NDWloaOqHbOgMAyM3NPX36dEBAACzO9u2RFeqjz= >>> >>> >>c3NaWlpFhYWv/zyC4lEWrVqFRSlTU1NCQkJ2trakydPnjx5Ml7PSLLe+n8gyQpf+vr6ekdHx4yM= >>> >>> >>DAKrsNM9zi2CIEJDQ9euXfvvv//CfG/fnj2LIAi4tN2zZ88vv/zSv3//OXPmuLm50el0AACVSrW= >>> >>> >>3t9fS0jp27JiMjIyfnx/o4tRMPYyveIwpFLSvX78+d+5cRkZGFzlUPgTEVzk5OS8vLyjsvzH7AB= >>> >>> >>SuLBbrzJkzgwYNIpFI8+fP9/Lygn4ZgiAaGxvDw8MTExMDAgKUlZVDQkLwQGSJfUA8bROfz7ezs= >>> >>> >>9u8eXNqaipap3ebkIP+WCsrq9jYWBRF/s2osJCsVCrV399/8eLFffr0mT9/PowrYrPZ5eXljY2N= >>> >>> >>cLslQRAlJSUBAQHFxcVidpJOH4oexldcf4V/79y5s2vXruTkZKQ2deekDO04DAYDr/DbQ/mKqAZ= >>> >>> >>lAY/HKykpcXFxmT9//pgxY5SUlAICAmBuAR8fn+vXrxcXFyP3LL4ORp8lfCUIUflntPzMycm5ev= >>> >>> >>Uq1F8Ruocx8IdpamqCpYp7omTFZSGKJYKTWFJS0pEjR6ZOndq3b18lJaWXL182Nzez2ewHDx4oK= >>> >>> >>yubmprW1taiBQOXy83Ozq6qqhJiVRcl+uv/dmZC+4BAICgpKbGwsHjz5g0Kmu62zsAFcmxsbG5u= >>> >>> >>bg/NTyhsuVkDrVaTkpLU1dWHDBlCIpHmzJnj5+cHU7y/fv1648aN6urqr1+/hio7VBtSU1NPnDg= >>> >>> >>RFhYGRPW3UB3nzkUP4yt6d9GghIaG6ujopKenE93uDoX66/nz54ODg1GFiZ7CV7yfuOYNAEhJSV= >>> >>> >>FVVR06dKiUlNTff//t7e2NqmqlpaXdu3fv7du3eEUNAIC/v/8///zj6+srsQ+IA+eEQCB49OjRw= >>> >>> >>YMHYeXS7tQgYXPBwcHLly+/d+8eFDY9KP8APoxC0foVAFBaWnr06NGBAwdKSUlt3rw5ICAAkhU+= >>> >>> >>XVNTE/RpEdhaAgDg5+e3ePHiwMBAFFQp7Joojh7GV6FQCONfkXy1tLRUUVHB7QNEN654EhISNDQ= >>> >>> >>0Hj16BOVND+IrBD5QAICamhpDQ8MffviBRCItWLAgJCQEkjI+Ph7uyoKnNTc3oxRM8EX19fVdvH= >>> >>> >>gx9BfgwVyd3uEexlektsKx4PP55ubmmzZtSk5O/iL6K5lMdnJyioyMhPvxe5D+iiYoociDlZ6er= >>> >>> >>q2tPXbs2EGDBh06dCgiIgJarAICArZu3ers7Az5ihZk6HmhCmFiYgKdXvD+EvsrQWDiE9lfLSws= >>> >>> >>lJWVxeRr9wDGJcF4l6/Z/ooGDU3TQpFDWyiqF5KUlKSmpgadAjCSGJq0YCD2sWPH8DUlui1Sedl= >>> >>> >>sdnV1NYwt7NIR6GF8hUDDJBAILCwsNm3aBPXXL9UZXLJ+bWT9v/a+PK6pY30fq63cVmurfuu9t/= >>> >>> >>15tXVptdd6XaoioCJL0SKiVVC0iqCgKCCguOCO4IKgbLKDgEAgIEvY17DKosi+72uAJBBCICTnn= >>> >>> >>N8fczN3CEgRCcbW5w8+h+TkzHKeeeedd973HRwxqqBBkdDOShBETk6OmpratGnT5s2bp6amFhoa= >>> >>> >>CjwDi4qK9uzZs3fvXhAuP6pKCt8FgKjH7Qe+vhXge+LxeKhiLVbAEJsoTwBgn+JwOCkpKaqqqjN= >>> >>> >>mzPi///u/S5cu1dbWwlML6+vrXVxcMjIyoPaFxsahjOzp6amvr4d5Q0QXQveBr2+FlpaWhISEur= >>> >>> >>o6IFfEkK/Y8N1RVLL29/f7+PjIyspOnz59/vz5V65cqaurgyMQ3An8JHEk3hCVoPBRmZmZxsbGq= >>> >>> >>ampuIhD6j/wdYIAbzQuLk5NTS0oKAhYecTQPoAJQlMgcBwnCILFYnl6eq5evVpCQmLu3LmXL19u= >>> >>> >>aWmBjXJzc2tqakK5CwLWgWBGVSBoH9i8efOzZ8+gSvDBPvA/iA9fw8PDN23a5OPjA0KXxFC+4gI= >>> >>> >>RC9lDEERTU9OtW7dAaPH333//6NEjGo0GqBYeHi4nJ3fu3Lm2tjYoZdG/I6U14OvGjRsBXz/Ys4= >>> >>> >>QhPnyNjIyUkZHx9fUVaRDIBACnY/QCjKX6+noTE5Mvv/xy5syZK1assLOzA6srLpdLoVDU1NQuX= >>> >>> >>bpUX1+P5nnAkWUl6iIHNd2IiAh5efnw8HDwFkTXDx/4+lYoLi6+cOFCbGws1F/fOV9RzRJew7ws= >>> >>> >>TU1N5ubm8+fPl5CQUFFRSU5OZrFYYNLv6ekJCQkJDAyk0+lAtxFKngfpixYBHltaWuru7l5eXo7= >>> >>> >>eIIrWfeDrW2FgYKC6urqzsxM9cmPqq4ECruIxxOUKWAP6+vqcnZ2XLVsmISGxYMECFxcXDDFF8X= >>> >>> >>g8FosFFHFMsI84anOw4V5dQEXmcDhcLhdufYlotvnA17cFeNl8UToljR/YcADSgFmbwWB4eXn9+= >>> >>> >>OOPEhISX3/9tbm5eUNDA0EQbDabQqGQSKSenh7Qh+OJ9UXVWbjvANVWlMqT28APfJ04QAWYTKaQ= >>> >>> >>iecdilgMMY7iSEcxGAwnJ6dly5ZNmzZt0aJFt2/f7ujoAPVPTEyUk5PT1taG9gHIudeNPf4IF8T= >>> >>> >>Ozs78/Hxw7JZI9fgPfH0r5OTkmJubp6WlwbXwO1dh4ciBcq66uvratWvffvvtZ599pq6uTiaTOz= >>> >>> >>s7gXoQEhJy6NAhMzOz7OxsDoeDrqWghjOyCP7wzTyCIOLj4w8dOpSSkgJeyof9gmEQB74CUQT86= >>> >>> >>Dw9PeEO0Lslq9AETRBEdXX12bNn586dO3PmTE1NTdBRADU1NWfOnDl9+nRNTQ36cyG6jyxFSOuA= >>> >>> >>9qyQkBD8na+3RqoykBmg2eidQj8Z4/O3aY/48DUyMhLExwL7q0hf1euAdilc/YDr0tJSQ0PDuXP= >>> >>> >>nfvLJJ+rq6s+fP4c8xnGcTqcnJiYWFRUJ1RxdS41RLrr7EBISIi0tDfMPvDN9ANYb1h6sImHGYL= >>> >>> >>jUgHei5mWUmkLdAY0sE6i0+PA1IiIC+Gu/E/8soXkZ9j+O4zweLzk5ec+ePbNmzZo5c6aGhkZ+f= >>> >>> >>j7Yi+JwOO3t7TCFINzBGilWxmgISkqCIGJiYpSUlID9VYgwk4s/4CtsPyi+paUlKSmJTCbX1tbW= >>> >>> >>1NRkZ2e/fPmyu7sbVp2PnHgh1GzgEYJ+CGwfE3i74sBXgMzMTCMjo/j4+PEIpEmHkJEVigAOh5O= >>> >>> >>WlqaioiIhITFr1qxDhw7l5uaCHuvr6wsNDbWwsCgtLQVGLgLJVzf+ooUIXVNTY2Njk5OTI2pTyb= >>> >>> >>jkK7xOT08/duzYrVu3qqqq0tPTTUxMNDQ0qFQqutpA5Ss+fLUI7HNo2ROTRuLDVwaDUVZWBtfFU= >>> >>> >>ylfoSgBgOVyOJykpCQ1NbWZM2dKSkoePny4oKAAfMVisaKjo3fv3n3s2LHy8nIhPk2ArzxB1tuh= >>> >>> >>oaHOzs6+vj58uDox6V0xLv0Vqin5+fmHDx/29/cfGhrq6uq6cePG0qVLPT094UhFxzr4CYfDAX7= >>> >>> >>pOI4DssIxPXImGifEh69w7YLGG05N0egOMCyUTqeHhoaCYzBmzZp18OBB4A1IEASXy01LS9PV1T= >>> >>> >>UyMsrIyAAJvwAm9gqgYAJG3K6uLuivzRNZtvE/lq8o+SorK8+cOePq6spgMNrb283MzFatWgV2z= >>> >>> >>9lsdlZWVl5eXlVVVV1dHQhMq6mpSUxMDA0NzcjIAOOvqKgoJSUlJSUlMTGxvLwchJG8v3zt7Ox8= >>> >>> >>8eJFe3s7jN+aSpUAQ7KHEAQxODjo6em5du1aSUlJIFlfvHgBo64HBwepVOr9+/fBh/hoC7Xxlyv= >>> >>> >>E1xcvXlhZWeXl5eEIZ96xPkAQRFdX14MHDy5evBgZGeni4qKsrKyjowNiqV++fKmlpWVhYeHr6+= >>> >>> >>vl5VVZWfnq1Stzc/MHDx5YW1vr6OhkZma2tLScP39+3bp1hw4dunjx4s2bN1+8eAFOqhAyNYwNc= >>> >>> >>eArIEFSUpK2tnZUVBRQzYWknUiB6h4EQfB4PCqVumXLFgkJidmzZx84cCA3Nxewub+/n81m83i8= >>> >>> >>vr6+rq4uYMrARyQfeFO+QtYSBBEeHr5t2zYYz42KucnFuOQrjlCEyWTW1NQUFxefO3dux44dERE= >>> >>> >>RfD6fxWLdvXt3165dUVFR0dHR+vr6ZDLZ19d3+/btNjY2KSkpVlZWmZmZfX19lpaWixYtun//fk= >>> >>> >>FBgYGBgbGxcW1t7cDAQE9PD4fDGWffiQ9fw8LCNm/ejNoHpmy/AENOF2Kz2TExMTt37pSUlJw3b= >>> >>> >>56enl5+fj74qquri0wmh4SEMBgMqICNpOnEhhmsQGhoKPR/xRHPmMlu9PjsA6h5AvhDEAQRGBj4= >>> >>> >>66+/+vn58fn8zs5OLS0teXl5Nzc3a2trVVVVLy+vuLg4TU3NQ4cOWVpaWlpaZmVl4TgeGRkJXnB= >>> >>> >>/f//Nmze3bduWnp6em5sbEhKSn58Pz3Ece2iKCV9xHI+IiJCWlvbz8xOpfEXHAOwfviADLo/Hi4= >>> >>> >>2N/eWXXyQlJVeuXGlkZPTy5UvQPwMDA+BkLDMzs+bmZkKw3fqWNYRthIoimUzetGkTylcRzTPj0= >>> >>> >>gfgfklnZ2dMTEx2djaO49nZ2bKyshoaGiAhz+HDh6WlpR8/fhwWFubu7p6dnV1TUxMYGGhubv7b= >>> >>> >>b7/JyMjcvHmzs7MzIiJCRkbm6dOnLBbL0tJyy5YtVCq1qKgoNja2uLgYGgXfC75iGAb4CvJlYIj= >>> >>> >>X/eSWJSQOUQHZ1dUVFRW1c+fOGTNmfPHFF1euXKmurgYyD8OwvLw8DQ2NPXv2xMTEgENDJ5ev4J= >>> >>> >>ogiNjYWHV1dZCPCJ+otB4PxqUPwLIzMzMvXLhw48aN1tbWjo4OXV3dhQsXampq+vn5nTp1asuWL= >>> >>> >>WQyuby8nEQiPX/+nEql3rt3j0QiRUREqKur6+npNTU1RURErFu3ztHRMT8//9SpU+rq6mVlZRiG= >>> >>> >>sdlsmKL6PeJramqqnp5eTEwM6v8qOn0AfTJBEAwGw8XFZePGjdOnT//00081NTVhXDuO4z09Pfb= >>> >>> >>29r///ntycjLISIdiUioD9de6urpnz57V1NSgfH038hW+A7DANDQ0vH37NgjuAcJSWVk5IiIiIS= >>> >>> >>Hh1KlT169fd3V1vXfvHpVKJZFIampqt27dcnJyunTpUnR0NIfDoVAoP/300/Hjx8+ePaujoxMaG= >>> >>> >>grd2PDR5McYPSUO9gE6nV5cXNzR0QE1NlG4EIx890Bn9fHxWbdunYSExLx5844dO5aZmYkmC2Kx= >>> >>> >>WJGRkbGxseDMHBgdMOlM4vP5g4ODg4ODqNnhXe4XwEHJYDBevnzZ1NQE1pidnZ0UCoVMJoNPCgs= >>> >>> >>Lvby8yGRyRUVFX19feXk5mUyOiYnx9vZOTU0FQRcUCmXz5s2mpqYgLUp/fz+6H4aa3N8LvuICRZ= >>> >>> >>aP7AKKgq/wAsizgYEBCoWyZcuWadOmff755ydOnIAnjvD5fBqNRqPRQPpLIccGdPvm7WsFXxyXy= >>> >>> >>21ra+vp6YFfvTO+8pGQHVxgIYfRZKjBH5gA4YIME2zDwjOxMAzz9/dfs2aNm5sbNGNBEyzK0feC= >>> >>> >>rxiGtbe3FxUVMZnMcdb8bcqCre7v76dQKMrKyh9//PGcOXOOHDmSn5+PC0ZOdXW1k5MTUFhxQfo= >>> >>> >>gDMk88PZ8RXewwPiprq6+d+9ebm6u0FT51u0Wxpvpr0IDHXQf/BdH9q4gg3EBp3Ec7+3tdXR0VF= >>> >>> >>RU9PPzg59PIDmKOPAVlJ6UlGRsbEylUtF8b2/5nkYV0pAZICpQUVFRUlLyb3/729GjRwsKCmDn1= >>> >>> >>9bW3rx58/Dhw8HBwWCBhZojJ0v8C02DBEHExMQoKiqC/IS4aHa2AP6Ar28JTLA1B0Y5m80G+1u1= >>> >>> >>tbVvo0uJCV8xDAN28oCAABjPPSlkRQ0CfMR1ure3F3hCffTRRzNnzty3b19OTg7sw+7ubgsLC2V= >>> >>> >>l5YCAgNbW1on5Er1RVeGLAP6E0J4FWzHphU4RX1F5DE3WsElv2q3iw9eIiAgpKSkfHx8hr7QJPx= >>> >>> >>b+HD4ESlY6ne7p6SkvLy8pKTl37tyDBw8mJyeD4y5A24F7wL1798DWwBtNWW8KVCUgCALsm4Dzj= >>> >>> >>ECJQEJNermi5Ss+fMmMylRo8X6v5SuFQpGTk/Pz85vc+AIMce8HLeVwOGQyec2aNTNnzly+fPnJ= >>> >>> >>kyfz8vJgigCwQs/NzU1OTu7s7BT6+dvXZyTgJABi8BpjAAAgAElEQVSql5KSoqam9uzZM3y4f/O= >>> >>> >>klytyvuLDnWghcWG48ATmUHHgK6hGQUHBnTt3srKyYBKeyeIHKr04HE5ISIiCgsL06dO//vpra2= >>> >>> >>tr4A0ImlxTU5OXl9ff3w+6lEAiqES0SEeVVxzHCYJoa2t7+vQp2FeDTBXFUJk4XwkBRn6CrrrQd= >>> >>> >>RiGWBtwQbMnoGaJCV9xHO/r62toaAB5fdG6vc0z0VENTC4JCQmKioozZsyYM2fO8ePHoVmeIIiq= >>> >>> >>qqq7d+96e3uDrO2ge2HyZBHFk8HHopRlsVjQn1Ds1lsoU0e9hgSFXc8XuJ1DgoKLCfBMfPiKNvN= >>> >>> >>NrRyvA/qQ3t7ekJAQQNbZs2fr6em9fPkSys7Kyspz587B01rAygwkZkOtkJNOHQxZFILXyuFw6H= >>> >>> >>Q66rE0uSVCTISvGIax2ey6urqampra2lqwuwMynZSWllZWVlZWVlZUVHR1dYHGMJnMysrK4uLik= >>> >>> >>pISOp3O5/N7e3urq6tLSkrKysp6e3tHzllj97L48LWnp6eiogKeRPVG70loVkUvwDCg0+lkMllO= >>> >>> >>Tk5SUvKLL75QU1ODBk5C4O2qpKR0584ddI8QFX74ZMj7MSoPRgiO48XFxc7OziUlJUINmfSi35i= >>> >>> >>vwASYlJRkZWWVkJCQkJAQGhpaX1/f29sbHBysra1tYWERHh5+584db29vJpPZ2toaExOTkpISFR= >>> >>> >>X16NGjwsJCYO4GNm13d3d/f/+Wlhahl/2+8DUnJ8fMzCw1NRVuoLwpZaFqhJ6QiOM4jUZzc3OTk= >>> >>> >>pL68ssvt23bduvWreTkZOAPBNg8MDCQmpoaEBBQWVkJddkpg9B6KyIi4pdffgHnyYtohABMhK8M= >>> >>> >>BsPKygqc2lpeXn716tWnT592d3c/ffp01apVJiYm2dnZ+vr6enp6LS0tGRkZBgYG/v7+GRkZHh4= >>> >>> >>excXFdXV1Fy9etLS0LCgocHJyAutKOJUAiD9foT0LuEdOYD0ORRSqSIDHlpaW2tra/uc//5k5c6= >>> >>> >>a8vHxoaCiTyYRecn19fWw2G8xpaAinSNsrBCG+ksnkjRs3gnhuXJQq7ET4WlxcvHv3biUlpdLS0= >>> >>> >>vb29lOnTpmZmdXX1/v4+CgqKpLJ5La2tjNnzuzfv7+oqKiwsNDY2FhHR+fcuXOmpqaxsbFkMllB= >>> >>> >>QeHKlSuJiYnW1tb79u0LDg4W4uvYECu+gnyaME3am7YCQ/IJ4zjO5/Pz8/P19fWXLl06a9YsBQU= >>> >>> >>FcGorQRBAH62oqHj8+HFiYiIa3Tr1eTogHfkCf210vwAXn/NhCIJ4+fKlvLy8vLx8eXl5c3Ozjo= >>> >>> >>6OsbFxXV2dj4/Pb7/9lpqa2t3draur+9NPP7m7u7e2tubn59vY2Bw5ckRKSkpXV/fhw4fy8vI2N= >>> >>> >>jYlJSV5eXnZ2dnNzc3QVjeefhcfvoaHhysoKJBIJNQZcvwPQQ1P4G9OTs7Ro0e//PJLCQkJeXl5= >>> >>> >>4BJECE6qLy4u1tfXV1RUJJFI0BVrAuW+PVA6EgRBoVB27tyJ6gMiqtJE+NrV1WVlZbV79+64uLj= >>> >>> >>U1FQtLS17e/vGxsYHDx4oKCgEBwe3trYeP3584cKFVlZW2dnZISEh2dnZFArl4MGDx48fj4yM1N= >>> >>> >>bWtre37+joaG5uBsko4fPflK937tzZtWvXu+JrZmbm1atXc3JyJmYcQI3qPB4vLy9PS0tr9uzZE= >>> >>> >>hISq1evDgoK4nK5hGDHqL6+3szMbMOGDdevX6+vr+cPdwwQRRvHACwXyNeysjJPT8/y8nIwD2Ai= >>> >>> >>sxJMxD7A5/NLSkru3r3r5OTk5OR0586doqKijo4OJycnAwODsLCwzs5ONze3U6dOhYeHU6nUu3f= >>> >>> >>vhoWFxcXF3blzJzQ0tK6uztnZ2cbGJj4+PiAgICMjAxUVaHe8rgIoX62trffs2fPq1aupX29hGE= >>> >>> >>aj0RobG/v6+ibMG9AQLpeblZWlq6u7YMGCzz//fOPGje7u7sDtC5rMMjIy9PX1LS0twakY8OeoH= >>> >>> >>jzZTXxtnSEj4cYem80Gig0PScM96UVPkK9cLrepqam4uLioqKiuro7L5XK53JaWFmDeGhwcpNFo= >>> >>> >>9fX1dDqdwWCAZDDV1dVVVVUMBmNwcLCtra28vLyysrKsrKy9vf2NNu5QWvB4PBcXF11dXZDZGRe= >>> >>> >>xsXpkTXp7e/v7+1GHvVGLhpSCFzgy6vr6+sCcs27dOllZ2Vu3bmVkZEBfUg6H09PTw+PxOjo6Cg= >>> >>> >>sLaTTaqGNjKqUsNgJsNrutrQ2G32Gi8VvHJ2x/FdoXQD+EcwSKkR/iSLTaG9UYfTFDQ0O2trYHD= >>> >>> >>x6EPnW4KI3VI2tSUFDg4eEBdkfHdjcT4iv8y2Kx/P39ZWVlP/vss8WLF1+7dq2+vh72EofDCQ0N= >>> >>> >>9fT0BDna0f6cmja+DqhQIAgiMzPTzMzs+fPnBHLesSiG0ET4ig/fiIMNeFONagIzODoTga6xtLR= >>> >>> >>UUVF58eIFvOFNnzkxEAJ/F3Ag4B/6RqITNy7Y22Oz2UFBQTIyMh999NHnn3+ur69fWloKB97Q0F= >>> >>> >>BsbKyysrKRkVF7ezt8zhS07g+Bbm4RI+JjxY6vEOhr+EP/lclqACY49gnaB4D+OpVzIiHIP7B16= >>> >>> >>1bgT4j/0VjFhmsCAwMDJBJJSkpq+vTpS5YsuXjxYklJCVQHORxObGysiorKzp07w8LCgL0PHa5T= >>> >>> >>08zXNQQTGLNwHCcIIiwsTEZGBs2XIaKiJy5f8RFerXCqEtHYwkcsS4XsA7DEKXidhCD/wKZNm0A= >>> >>> >>SBnSuH/UncEjjON7X1wdk0owZM1asWGFvbw88rOHNNBrNyMhIRUXl2bNnbDYbfj52EVMDbLhuA+= >>> >>> >>yvIF8xqg+IouhhfB1/GajaCpZf/f39cOWBv4kofaO2oTdD+bp79270JHMoxkQKMDyioqLk5OT8/= >>> >>> >>f3RfBljVB78kMlkenl5rV+/fvr06f/+9789PDy6u7vRkDiCILq7ux8/fhwfHw/sr/CxKOnfIVD1= >>> >>> >>jyCIrKwsU1PTkfrrpJc7jK+QhX8IcH4NXxCrmZ2dbW9vHxsby2QyYXuw0YCPQ8Ed+ysIAjlPHtp= >>> >>> >>fRTq4R1amrKzM2dkZ+Ezhw53T8dGGIiHwvAZx2MuWLXN3dwcnYAEGEATR39/f29s7MDAAEusK6T= >>> >>> >>kinb7GCShZIWVZLFZzczNIRIlu1U560cP42tHTNjg0gP9RMQRBdHR0xMXF0Wg0HMfBIY6mpqbx8= >>> >>> >>fFo8jZUBuNIJC2G6OmYwIAn1B1jV0CIr+j+1hS/SJBEDWSjgE1DfQlQbhEEQaPRbG1tN2zY8Mkn= >>> >>> >>nyxfvtzZ2ZnBYODI8qWqquratWuurq7A5UocTAEjgb5HDMNgmlRcsAOCrsYmF8P4Gp7r39hRx2D= >>> >>> >>RMXysPuJyuXFxcWZmZsXFxWAwsVgsGo0GznIWYifKWiFKgQsY6DP+FsInv8P9WADYOqH8LthogW= >>> >>> >>vAT+if//ynhITEkiVLnJ2de3p6wJ2gE7q7ux8+fLhu3To7O7ve3l748ynbCBgn0EEICAr8X0HKD= >>> >>> >>NDeqdgvSCuJCk5zyS6N5/P5BD766ycIoqamRkdHZ+3atdbW1jU1NW1tbREREUFBQU1NTTwer6Ki= >>> >>> >>wtvb297e3t3d3d3dPTIyMjc3l0wmOzs7p6SkgK2g9vb2+Pj45OTkrKwsNDkKf3xe+uLD15qaGjK= >>> >>> >>ZXFlZib6qkQ0hCILNZvv6+q5cuRKoAY6Ojt3d3Tgye7a3tzs6OhoYGLi5uTU3N+MI10URCPU2QE= >>> >>> >>cmjuMEQeTl5VlaWoJsSHCMiZyvpm5yD4IvJubHDHCFN0jRHzQ0NOjp6UlJSYFTx2k02uXLl1euX= >>> >>> >>Hnr1i0Gg5GcnCwlJfXNN99YWVk5ODjs27fP2NjY0dFRVVVVRUUlIyODw+H4+voaGBhER0fHxMR4= >>> >>> >>enrC3XC0R8Scr6C4qKgoRUVFsNHPEySVhioBX5BCkMvlksnktWvXTp8+/ccff3R3d6fT6eA5kJE= >>> >>> >>JCQmGhoYRERFgmhKfA2lHBbrsA/bX9evXBwYGQr7iU+Cvvdn0Wz2nUw/CbOs768fg6+DgoJ2dnY= >>> >>> >>aGRklJCUEQQ0ND9vb233zzjYaGRktLy4sXL2RkZL7++msqlVpaWqqsrKyvr19eXv7o0SNZWdmws= >>> >>> >>LDGxkZTU9OrV6+WlpbGxMTs3bs3ICAAJCMZJ8SErxiGhYeHS0lJPXnyBI37hVQDq6WhoaHU1NRN= >>> >>> >>mzZNmzZt2bJlTk5OYK8V3gDuaWhoKCsrAw4ufCRkTwz1AT4SGYYJ8g/A/QJszLO73hLD+Hrg3i/= >>> >>> >>X/K57JzzpZHSOwdehoSE7Ozt1dfXS0lLwb1BQ0Jo1aw4ePNjc3Pzy5cutW7f+61//Sk1NLSkpUV= >>> >>> >>NTMzc37+joCA8PV1FRiYqKqqioOH36tJGRkbe3t62tra6ubmRkJAhVg3gv5Cvgq7S0tLe3N8gDg= >>> >>> >>CGARExLS9u/f/+MGTNWrVrl4uICT78GtzEYDOBoAVVhKLewMX0S3iGwEfbXsLCw7du3o+dv4VPg= >>> >>> >>n6V6d+dV/xuBaST2AHsMvrJYrNu3b4NwIjqdzmQyX7x4oaKioqmpCeSrrKzswoULk5KSioqKdu3= >>> >>> >>aZWpq2traSiKRgONmaWmpjo7OkSNHwsPDc3Nzs7KyGhsbwSSI9siorRUiBLQPQPuriIb1qP2AYV= >>> >>> >>hsbOzOnTvJZDLcl4KvanBwsKqqikQi7d+/f86cOStXrnRycqLRaKDa4AkVFRX29vbOzs4gaauQ9= >>> >>> >>RpiCprzRgADCUbkEwTx8uVLkDNd1AaNYXx9VhjR0Ufr4/bxsddOQMBA6OXlJScnd+HChfDw8NLS= >>> >>> >>0ujoaDk5uT179pSWlubn5ysqKq5YsQLoA3v37gUnPoKU4WZmZkVFRSdPnpSVlSWRSDk5ORQKpaC= >>> >>> >>gYJzxMEKaPo/Hs7GxAZE5I7+dAjQ1NUVHR1dVVUEdABeEDAUGBu7btw+ECSxbtszNzQ0IUVDPgY= >>> >>> >>GBFy9enD59WllZ2d3dHVgGxVZbFQLsZ74gJoLD4TCZTNSuJ6KGDOMrHxsc55ZBTU3NuXPnlJSU7= >>> >>> >>t+/X15enpiYaGpqam5uXlhYWFdXd//+/YsXL5aVlTU3Nz969MjZ2bmpqamgoODChQsPHz5saWnx= >>> >>> >>9vbeuXPn6dOnL126dP/+/ZycHChfUQEzslxseH44Pp/v4+OjpaUFjpiCv5pKKQvtWbDyNBrN19d= >>> >>> >>3w4YNEhIS06dP3759+/3797u6ulDZU1paeubMmY0bNz548KC1tXWKq/2WwJCFIFQJANBFpyiKJo= >>> >>> >>T2t8b5GxzHKyoqAgMDs7Ky+vr6WCxWU1NTY2NjT0/PwMAAjUZrbW0FyUe7urq6urrAhm1rayuIJ= >>> >>> >>ujo6KBQKJ6engEBASUlJb29veN8YUJ85fF4T58+PXr0KPTPmmIRBfaigREAdsuNGzdWrVr10Ucf= >>> >>> >>zZ49e+/evcnJySC0HV1g5eTkGBgY2NjYtLS0iFThExHQzS0cxzs6OrKzs1tbW8G3UJpMOmuJifm= >>> >>> >>/glrClMrEmwD8dmhoiMVigawkBLL1/4d8hUzFMAyYJjQ1NUfqr1Pz7oE+UF9fj2FYT09Pfn7+5c= >>> >>> >>uXly1b9tVXX23bts3c3Dw1NRXs+QG7AUEQdDq9sbGxqanpxYsXHR0dxHCDpbiZAkYFfAtQ/8nOz= >>> >>> >>jYzM8vMzCQQ/wFRyI6J8BUXiDF0PYuaYDDEogGXIOgMgiHO3W+0/sUQgGcGBgaePXu2oqJi5G3j= >>> >>> >>b84EQAhiVE6dOkUmkxMSEkxNTXft2rV27VopKSk7O7vCwkI6nQ7TBYNfNTY2enh4+Pn50el02AR= >>> >>> >>0Q+i94CusMyawv8bFxe3fvz8xMRGYREQkXPG34Ss0iQsNJv4ICIWAoio5Sr7xkAwdDKCsiIgIAw= >>> >>> >>ODV69eoaNiCoQrGG+JiYkyMjLq6uoKCgqSkpLTpk1btWqVmZkZSHEFpw5w0dTUZGdnd/bsWQqFA= >>> >>> >>iYW2JNTvEx8S6BVBaLn2bNnwLhOTGV8wTj1V6F6jxT+KInRf1FxK8TUNyqXjxw95eDgsH//fiH/= >>> >>> >>rDd6GtqcMZqJ3gP419LSYmNjs3jx4jlz5nz88cdffvmlkpKSm5tbXV2dkDkWx/GWlhZ7e3sTE5P= >>> >>> >>IyEgQ54QP117eF7LiI94dQRCpqam7d+8OCwvDR0tHOYkYxlfOIOePfyEGAB1BTFI8Nx9JYC1EIH= >>> >>> >>QoQk0dx3EOh1NSUmJmZvbjjz+CQwS2b98ODlBlMpkEksMCrpqzsrJu3rwJyIq/bwQVwkhZ097eH= >>> >>> >>hAQIBTlIXL9tayxDJtQWNUUA+XrW+5vYcNTfPKHZ1SG14B2wOu3pqbG29v7wIEDf//73z/++ONv= >>> >>> >>v/1WW1ubSqWCKFb0sZjArs7lchsaGgoKCgCbRTRXThmEyAoGPJvNBjsIMP+kyPna2NmIrtbFFpP= >>> >>> >>LV7RzsREn/oBSuFwuk8lMTk5+/PjxiRMnfvjhh08//XTevHkKCgpWVlbgsFZcEM+EI6pFcXFxVF= >>> >>> >>RUY2PjSEXovVhavQ5oE/h8fn9/P5PJhEEWuMjsM8P4GvMyYoA7KIpiJheTyFd8+DY9fA1wtdTU1= >>> >>> >>BQVFeXq6nr58mV5efmFCxcuWLBg3bp1x44ds7a29vDwcHBwKC0txQVkhbxnsVhUKvXixYtXr16t= >>> >>> >>rq5GixO6eE+B6q9FRUX29vZFRUVvv4oYG8P4mloYx+zrEf9unHT5ihoc4NRfW1ubkJBgZGS0cuX= >>> >>> >>Kr7766tNPP5WQkFi8ePHx48dDQ0NBWpfIyEg1NTXgP4ByncVieXt7Kykp/f777wkJCSBgEDUDve= >>> >>> >>/yFR/O14iICHl5+YiICFzEu+LD+BqW4dc/yPlL6QPoRgaO44ODg/X19XFxcY6OjgcOHPj555+/+= >>> >>> >>OKLjz/++G9/+9uiRYv27Nnj5eVVWVkJzmoE7wmcz426qxIEUVVVdfjw4R07dqCh2KBEPrI5N5md= >>> >>> >>MoUQ0r8JgggJCUHPk8emxv5a1Vgh5vorlIV8QeSQlZWVqqpqfn4+IQjZQ3sTG7HLgiEGKYj29vZ= >>> >>> >>Xr15lZGQ4OTkdPnx4yZIls2bNkpCQmDlz5vr1642Nje/evUsikWpqauDpjaC4Z8+ebd682dfXFx= >>> >>> >>7VAh9IJpOpVCpIhYkjs//7sikwBoTWW4Qgnhvl61TEwzDYDHEmKz7cMwis3y0sLHbu3JmXlwcn2= >>> >>> >>VEZKQQOh9Pf39/Z2ZmWlubv729qaqqsrLx169YFCxZISEhMmzZt5syZS5cu1dDQCA4OBhnBoKoA= >>> >>> >>K8Pn8ykUyi+//OLv7w9T1nE4HMBd6FcgOmXuXQET5KyFE11YWNi2bduio6OJqYzn5vHFfYYauRP= >>> >>> >>h5uZ26NChsrIylI58Pr+3t7e7u5vBYNDpdDqdDvLPgZxzcXFxt27dMjY2Pnbs2MaNG5cvX75w4c= >>> >>> >>K5c+fOnz//m2++2bRpk7GxsbW1dXBwcHFxMQj/JxDnBBS1tbXBwcEVFRU8Hm9gYIBKpbq6uhYXF= >>> >>> >>wNXAVBnMXS4fnugx9LiOF5ZWRkQEFBbW4uL2OVoGF9fF2MoPkCFKBCxz58/P3v2bEREREVFRUVF= >>> >>> >>RVVVVXl5OYVCsbCwMDMzMzMzMzExOX/+/JkzZ3bu3Llhw4Y1a9YsXbp0zpw5n3zyyccffzxv3rx= >>> >>> >>NmzaZmJhYWFjY2NhERkYWFhb29PSgXlcoUMkBPgG3DQ0NhYWFKSsrGxgYVFVVYYgR4E8pX2H/g1= >>> >>> >>kOpggHjYVnWE960cRb5s+aeqC6/NDQ0NOnTzds2PDzzz9v27ZNVlZ269atsrKyP/zww5w5cyQlJ= >>> >>> >>T/77LNPP/109uzZn332mYSEhISExIwZMyQEWLp06bVr11JTU1tbW2k0WktLS3d3d29vL5olE1he= >>> >>> >>wYfgAiytuFxub29vX18fh8Pp6ury9/dXVFTcu3dvYmIimmtbdDPjOwS6fgCta2pqSk9Pb2lpAXK= >>> >>> >>XL1b5X98hMMSeDyYjS0tLkD1dQkLiiy++WLRo0eLFi7/77rvvvvtu0aJFS5YsARffffedtLT02b= >>> >>> >>Nnz549Kycnt2TJkmXLlmloaDx58qSurg7DsM7Ozvj4eF9fXz8/PwcHBxKJ1NHRwePxGhoaSCSSg= >>> >>> >>4PD48eP/fz8kpOTu7u7wRsKCQm5d+/etWvXrl69qqampqGhkZmZiYqZP59khUCbieN4eHj4jh07= >>> >>> >>KBQKjkT2fuDrKJtDAQEBmzdv3rp164EDB27fvk0ikUJDQ0NCQkIRhISEPHv2LDMzk8lkdnR0ZGZ= >>> >>> >>mhoWFkclkCoVCpVLB6Ql0Oj0rKysqKio6OtrFxcXf3x+kA2pvb4+Ojrazs/Pw8IiOjs7Nze3t7Q= >>> >>> >>UWgJiYGC0trUWLFuno6Pj7++fn58NVl5BY/ZOJWNQ+AJahz549k5KSAucd8xGPs0kv+j3jK46Yt= >>> >>> >>EB3NDc337x5Mzw8vLGxEXp/jx/oYzHBcUIgYgI6rPB4vJ6eHnD2FbrjOjg46OPjs2HDBi8vL5iI= >>> >>> >>CX3an5uv0FUA2AdkZWXDw8OJ4QkqJ73V7xlfhfqCIAgajfbo0aPi4uLxs/N1lH2jz8F1VFQU3C8= >>> >>> >>gCOJ9N6yOH+gCiyCI4ODg9evXg3yaGLK/NXV8JXDwbgixMhqAbsIF24A4jiclJZmYmICda6jUTo= >>> >>> >>EwIwT5NLdt2+bn5wfzXPyJdVYUKCkJgkhPTzcyMkpPT8eHWw9Ey1cCHyZFMPy/RsQxwrunGBji5= >>> >>> >>gdmanA+TEFBAY5E5kwZY0pLSx8/fpyXl4cmIPqL8BU2GcdxDofT0dEBTl0cucs4iSCE4gsGhrgt= >>> >>> >>PQ2tvUV1TGpFF6WDXVnRUc7hDoiJlEU5wefzBwcHb926JeSvPcXKIh9x94aWyCkr/V2BjwBDrNH= >>> >>> >>gpWBTYx/Ib3tln25+NU4luMjQ98Vp24wDac2RdfT6/sF+Qjz2aTFkswA4AcbExBgaGr58+RLcwB= >>> >>> >>el8+XIykArIxxCfwV9QGjG5/P5AwMDwDINADOEila+XorS0yatPP3sP0dI6y4n7jSKUb5G1X+Qf= >>> >>> >>ft5U+YgTyz8YjEkYhH8297ebmNj8+rVK3xEUPwUVKawsNDf37+2tvYvyFfIWhzHMzIyQD54XMQR= >>> >>> >>lMP4qh26SfeZlJrPdxtc/qbms+FkqLJFsnZwkUdqdWIjo1EcVIKRXdDd3W1nZwf1V1GXDi8IQb4= >>> >>> >>3JSWl4OBgoezEIq2GOEDIShMUFLR+/XoymSxkz5r0cofxVdVtnobdd1rOP+y79v909X/wjdFMa3= >>> >>> >>AIenXF8/m1srZX4sBXIRAE0d3dbW9vj+oDIqLLyBfQ09Nz9+7d//znPwEBAWj+rL8IoDWGIIiQk= >>> >>> >>JANGzbAfJqiG7fD+LpNb832E8t1bv58wWPDJZel1yOX7/ebp/B4kXWiRQuzVUxUWBSQrzC/C1z6= >>> >>> >>THpZkK9Qaaurqzt48OCOHTuAfQAXm8NbRA2UkcD+GhISsnHjxtDQUFzEKSCG8VXNeZu0o+wO963= >>> >>> >>qAd9pkb464vf1/icbdnvtvUS5WtJZJp587ezstLW1LSoqwsfsqUnsQfgcGo129+7d+/fvt7e3Q+= >>> >>> >>PrX8GeNVJ8FhUVOTo6wqwluMisNMP4uvz+8mWWS+TtlU75GBxzV1d9vH6Xh+yZUIPokpheTu+kl= >>> >>> >>/32IAiiq6vLzs6uuLgYzk2j9tSkdJ/QE3g8XnNzc3V1NdiqFZFHknhCaCYB+fyAozqKSS93GF+P= >>> >>> >>+WlJPVj/o9W3253Wm0YaWac7ehYEBBSTS7vEUbjiAn3A1tY2PT191A3YyQX+mrAFXLACQ3NkTA3= >>> >>> >>eVc8LRRTD+mACI/QfCoiJNYFA+Wocb+Kc7uqV6WWfbX0n60Jue8IQznu3/TI2CIKg0WgGBgYXLl= >>> >>> >>xISUnJz8/Pzc3NESA/P7+2thbs7H8ABP5HwULQ+oEjyVNeN2UB1jKZzMrKyp6eHqiSjS1fR1YJf= >>> >>> >>ebYb/x/fG1htzPYDCabyccIDMf42BBBEISYuRCgIAiCwWCYm5vv3r1bW1tbX1//1KlTenp6J0+e= >>> >>> >>1NPT09XVtbGxiY+Pz8zMTEpKSkhI8PPzI5FIWVlZ5eXlJSUlqampiYmJhYWF6enpMTExQUFBXl5= >>> >>> >>enq+Bh4cH/NbLy8vb2xt86OHh4evrGx0dnZ6eTqVS09LS0qcEVCo1Kyurrq4OZLXGX5OYB8Owvr= >>> >>> >>4+cIzUqKxF+QHXT5C140RKSsrRo0fHnuXQt9bR0ZGRkZGdnQ2cOeE96B7EqMQlhPZjX1eG2GJoa= >>> >>> >>KiioiIzMzMjIyMzMzM9PT0tLS0jIyM9PT0lJSU9PZ1EIpHJZG9vb0dHR0NDw8uXL5NIpLy8vKys= >>> >>> >>LF9fX1dXVyqV6u/vb2dnd/nyZcDyEydOnBwBPT09PT29EydO6Orqgn8PHz78/fffz58/X1VV1cD= >>> >>> >>AYMeOHdLS0ps3b5aSktosekhJScnIyOjq6j58+PDRo0d2dnaOjo4ODg72CBwcHB49emRhYWFpaf= >>> >>> >>nw4UMHB4eEhISGhobk5GQPDw8KhZKXl0ehUB4/fuzv75+UlOTm5hYZGVlVVZWUlAS6MSMjg8Fgc= >>> >>> >>DgcNpvNYrGApyWLxert7WWz2eDDwcFBf3//9evX+/n5cTicvr6+/v5+kNwX/Mtms4FyDza9CIKo= >>> >>> >>r683MzPbvHmzvr5+eHg4iOgcGBiAFpjXbWuPxlecwMVVoI6Kscc0m83u7+/v6+vr6enp7Ozs6Oj= >>> >>> >>o6+sDwxf0Johs6enp6erqam9vb2tr6xgN4KvW1tbW1lZwXVdXFxwc7OLikpubW1BQ4OnpaWtra2= >>> >>> >>tra2NjYyt6PHz48P79+3p6eoqKilu3bpWWlpaWlpYdDTIyMrKystLS0jIyMlpaWhYWFrt27fr22= >>> >>> >>28VFBQMDQ3V1NQWLly4YsUKFRWV7du3a2lpGRgYSEtLy8vL79mzR01N7fr163fu3Dl//vzp06cN= >>> >>> >>BDhz5oyRkdHp06f19fXPnj2rqqr6r3/969dffz1z5oyBgYGhoSG4MDAwMDIyOnfuXEBAQFxcXEB= >>> >>> >>AQEZGRklJSVRUlJqa2rRp0yQlJVetWnX48OGTJ09aWFikp6fT6XQulwuTcI1810h+wiE6l9dDEL= >>> >>> >>z3QrKOBIE4p6J7USOnQngbgayW3nF4G70AAAm1SURBVAZTvMyCaGlpycrKAhNLeno6mGdGAnwLL= >>> >>> >>hISEqysrHR1dW1tbZOTk58+fXry5Mljx45ZWlrGxcWlp6fb2dlpaWnp6elZWFhYWVk5OTnZ2dkZ= >>> >>> >>GRlpamqqq6sfOHDg4MGDBw4c2L9///79+zU1NTU0NDQ1NQ8fPnxQAHV1dQ0NDQ0NDXD/kSNHLl6= >>> >>> >>8aGpqqqSkdPr06cuXLyspKX3zzTcSw/H3v/997969GRkZmCAybNRX/D++ZjW4FNOCa+hpxW2F3X= >>> >>> >>3090rICrv048PXsEJObuid0BSFIT6d4ykRMhU+fIrJiv/Ryul16O3tbWtrA+EYQ0NDYN4Ax4QTB= >>> >>> >>MFms1taWlpbW5lMJpju+/v7Ozo66uvrGxoaGhsbGxsb6+rq6urqQGJ78Bdc1NfXg9vq6uoaGhqa= >>> >>> >>mprq6+sbGxurq6uzsrK8vb0pFEpCQsLt27eVlJQkJSU/+uijxYsXf//99/Ly8jdu3HBwcCgvLx/= >>> >>> >>jFRAoX+0y91ikqDtlX0urTevlsIj3SsqiSjo23O0QqE0A+PClLiZI/YAS+nXPF/pKaCGM0n1sjH= >>> >>> >>zIGHeO/RXanFHHJICQkxA+/HB0yGP4lYgAExgmJCQcOnRIWVlZR0cnMDAwMzOzuLgYqLxCbopCG= >>> >>> >>MbXK6n7joXu1A3VuJt8u6il+P21fmPDF5hCRBn5FfwJ/nrfrtdRbeRt46keeH+vux9l6hiVgfQa= >>> >>> >>oz5CXwnRHd2OGrXckRfoM2GPYYJ1Ei6Yr3DkaFyhvuVyuRkZGT4+PiUlJeAcViFa469PMjKMr6f= >>> >>> >>8fz0fuedK9GGH9Dvpdek9nN73S8SKLTBEDHO53Pr6+levXlVUVACDJT7cExK1wwvJRSGe8fn8tr= >>> >>> >>a20tLS1tZWMHuIoYhBaQfrDw0FKEfHA8BXcJiZxDXzNbGvzmU0OCZW2SdXu3f21X7g66QAynuCI= >>> >>> >>Lq6ujw9Pfft23fx4sWqqiohi6MQccF7xUeb63Ec53K5gYGB6urqDg4O4EwEMeTrqHhTmqI//B9f= >>> >>> >>9T0WawV+s9dn7u/+/ybnOzHZrz31+APeFJjAFN/X1+fs7LxixYrjx483NTUJSU0CWUVB7sIPcWS= >>> >>> >>iBPeEhoauXr3a0NCQTqf/FVzDCIJISkr6L1/3ev5zn8e3u91/2uWu6pLh0Tvwni25xBnoJE4mkz= >>> >>> >>du3Ghubg5Sb+ACn3wcx0F2o+7ubhBwi2HY4OAgi8ViMpnAVAwfNTg4yOFwCgoKfv31V2NjY3BG/= >>> >>> >>V+LrwdcNLY9XKHmLnMz4UZyTSqHxxm5xAO/EdsdWrEFZBKXyyWRSOvXr798+TKTycQEbmU4jnd1= >>> >>> >>dcXGxjo6OlpYWMTGxrJYLA6Hk5+f7+3t7eXlRSKRSkpKQGbP1tbW6Ohof3//u3fvrlmzxtDQEDz= >>> >>> >>qfdEHJoxhfN3lo3wywtgi1dog3Ngjw4Mz0E8QBB/j83g8Aifa+lohg8Unwvu9AKqYDg0NBQUFbd= >>> >>> >>iwAfAVfE4QBJPJdHV1NTY2trW11dHROXDgQGpqalFR0alTp/bs2WNnZ3fhwoVHjx61t7fTaDQ7O= >>> >>> >>7vjx4/b2NhoamouWLDAyMiIyWTifzX5KvVw7Q7Xnb/aqyhaKxk9PRucF+yX5xeSExL3Ku485bwB= >>> >>> >>5UxuU25Ja0lgbiCNRfugKrwRoPDj8XhBQUE///yzmZlZd3c3+KS2tjYsLExBQeHEiRNdXV3FxcU= >>> >>> >>HDhzw9vYuKirS1tbesWPHkydPzp8/b2ho2NzcTKVSt2zZYmhoWF9f7+bmtnz5cgMDA2Dt/4vwtb= >>> >>> >>OzkyAIieW6P/x87me563K/Wu6Su75d2kpG3VXd0Nto1ZVVP9/ZcDfynonPeRWbXbee3UorTetid= >>> >>> >>b3ryr9PgOv6oaGh4OBgIF8ZDAZBEHQ63cHB4dChQ4sWLdLW1gaB0SYmJiB34oULFzZv3nz58mUT= >>> >>> >>ExPA18DAwNWrV3t7exMEUVhYqKysbGJiAlXhPzeG8bX3UW/8xdgw05D0W6mvbr2IOR3tfsr9H6f= >>> >>> >>++dP51ZZ+Vrstdi+98I9dzr+c8TYwDzRv6Gr8K3TQxDBtNOCC8+eDgoLWrl1rbm7OYDAwDKNSqa= >>> >>> >>qqqvv37//hhx8OHTrU0dHBYDCMjIx8fHxCQkLWrFmjpKQUExMDNvErKytBcJ+dnV1vb29CQsKWL= >>> >>> >>VuMjY3huYp/Mgj1oYSEhJyc3H/5mmSWXGBcWGpcVnulufZiE9WQWmNZuezC94ccj/x45cdvb3+1= >>> >>> >>1nb5kivffn/pB5MnZ/OrcvmYuOePf1cYSdaPPvoI2F8HBgbc3Nx+/PFHXV3d58+f5+fnm5mZ/fT= >>> >>> >>TT46OjsePH1dUVAwKCgoICDhy5Eh4eLibm9v8+fMVFRXDw8PPnDmzbds2X1/ftLQ0FRUVVVVVNz= >>> >>> >>c3dXX1L7/8Ultbu7VVHANC3x5j8dXvelTy40qyZf6NQ8GUa3lUqwJ/3bDtt2XXXF0u6/rTmofLF= >>> >>> >>9/7f98/+oes2w/HQn5zfm7f9cFA+xq8jq84jvf29j59+lRHR+fSpUve3t6urq4GBgba2tpZWVkx= >>> >>> >>MTFHjx49ffr0+fPnr1+/XlZWlpqaqqqqKi0tbWxsfPr0aQUFBVNT05KSkidPngCvKGVl5dWrV1+= >>> >>> >>+fLmuru5dN1okGIuvVY6VbZG0ZI9c4+N3oq0LHl5Lengj8ICx4qnr23dd3SizZ/6JaysCXtmmNc= >>> >>> >>QlVcfGlyW0Mzs+8HVUjCTr9OnTcRwH8rWmpqawsLCoqKi0tLSoqOjVq1elpaU9PT0sFqugoCAiI= >>> >>> >>iI1NbW2tra/v5/BYKSlpXl4eISFhRUUFCQmJsbGxnZ3d3d1dcXHx5NIpOjo6KCgoIKCAqBavOt2= >>> >>> >>Tz5G5SuNRiMIQoLtymE95rHd+ZU2FfGGidQjRUUmHZsfrF5z96elt/653Giu6v01mqS9ak9+0/c= >>> >>> >>7Hfo8lMakfTDEjorXyVeIkYZtsKFFEATwBCAEJ3kQBDE4OAgj+IaGhnDkVFscx9Go1D8fZV/H1+= >>> >>> >>vXr0s0OPVUWHMa7g22W7bmnKO6aTxOOZquFrxLyn3z7JuzFjz4xx6yhpyH/GG/ww6JDuXN5aN2+= >>> >>> >>gcQBCExGsbzQ/z17nyvY/mfGyO7cdu2bf+Vr+XW9PbHPfUOtBdWNbV3mAnGKZrr95NKSWH1Ida5= >>> >>> >>9w6Faxgnnfg1UMkixSqrPquzv/Ndt0V8MWG+foAQRnbj5s2b/8vXZF963n1esX1/jkN/qOVQ1G3= >>> >>> >>89u9P5n7xxZGNR112hz+7kRF7vSTfpSnc4nkqOSOFkuLzxMdrBLw/4ANej5GEGSMmGUYmA7i7u7= >>> >>> >>u6uoaFhbW0tBCjxsd+wAeILT7w9QPeJ3zg6we8T/jA1w94n/D/AWQx0gRPTdK4AAAAAElFTkSuQ= >>> >>mCC" alt=3D"">
>>> >>
=A0=A0=A0=A0 I wonder, however, does the situation the same if >>> rateless= >>> >> erasure code (say fountain codes) is used?=A0 As with erasure code, no >>> ACK= >>> >> and retransmission is needed except when the whole file is completed. >>> So e= >>> >>ven heavy loaded, the network is still busy with effective data packet, >>> rig= >>> >>ht?=A0 Although queueing delay will increase, I believe that=A0 the >>> network= >>> >> throughput=A0 will not=A0 suffer the plunge as un-coded network.
>>> >>
=A0

Kara






>> class=3D"gmail_quote">2= >>> >>013/3/5 Srinivasan Keshav <>> keshav at uw= >>> >>aterloo.ca" target=3D"_blank">keshav at uwaterloo.ca >>> >
>> >>uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px >>> #ccc = >>> >>solid;padding-left:1ex"> >>> >> >>> >>To answer this question, I put together some slides for a presentation >>> at t= >>> >>he IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we >>> always= >>> >> size a shared resource (such as a link or a router) smaller than the >>> sum o= >>> >>f peak demands. This can result in transient or persistent overloads, >>> reduc= >>> >>ing user-perceived performance. Transient overloads are easily relieved >>> by = >>> >>a buffer, but persistent overload requires reductions of source loads, >>> whic= >>> >>h is the role of congestion control. Lacking congestion control, or >>> worse, = >>> >>with an inappropriate response to a performance problem (such as by >>> increas= >>> >>ing the load), shared network resources are always overloaded leading >>> to de= >>> >>lays, losses, and eventually collapse, where every packet that is sent >>> is a= >>> >> retransmission and no source makes progress. A more detailed >>> description c= >>> >>an also be found in chapter 1 of my PhD thesis [2].
>>> >> >>> >> >>> >>
>>> >>Incidentally, the distributed optimization approach that Jon mentioned >>> is d= >>> >>escribed beautifully in [3].
>>> >>
>>> >>hope this helps,
>>> >>keshav
>>> >>
>>> >>[1] Congestion and Congestion Control, Presentation at IRTF ICCRG >>> Workshop,= >>> >> PFLDnet, 2007, Los Angeles (California), USA, February 2007.
>>> >>>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/conge= >>> >>stion.pdf" target=3D"_blank"> >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >>> >>pers/data/07/congestion.pdf
>>> >>
>>> >>[2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, >>> publishe= >>> >>d as UC Berkeley TR-654, September 1991
>>> >>>> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesi= >>> >>s/ch1.pdf" target=3D"_blank"> >>> http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >>> >>pers/data/91/thesis/ch1.pdf
>>> >>
>>> >>[3] Palomar, Daniel P., and Mung Chiang. "A tutorial on >>> decomposition = >>> >>methods for network utility maximization." Selected Areas in >>> Communica= >>> >>tions, IEEE Journal on 24.8 (2006): 1439-1451.
>>> >>>> target=3D"= >>> >>_blank">http://www.princeton.edu/~chiangm/decomptutorial.pdf
>>> >>
>>> >>
>>> >>

>>> >> >>> >>--f46d0444e84964e1a304d740bdcd-- >>> >>> cheers >>> >>> jon >>> >>> >> >>--e89a8ff1c4e2529bed04d742b110 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>1. With fountain codes, for k original packets, infinite number of encoded = >>packets can be generated and the receiver can recover the k packets with an= >>y k(1+ e) coded packets.

2. Suppose all flows are coded, and=A0 the = >>short term packet arrival rate of some flows=A0 exceeds=A0 the service rate= >> of the network.=A0 Overflow and packet loss could happen wheather the pack= >>et coded or not.
>>
=A0My point is, I do not think the effective throughput will plunge=A0 = >>with coded flows , although the buffers are full. The network is in full sw= >>ing and the worst delay of a flow is=A0 the sum of the=A0 maximum queue tim= >>e of the routers along the path.=A0
>>
I think there will not be a cliff in the throughput-load figure, insdea= >>d, the curve will go beyond the Knee and reach a constant throughput.
<= >>br>=A0
=A0=A0

=A0=A0



= >>2013/3/6 Jon Crowcroft <>t at cl.cam.ac.uk" target=3D"_blank">Jon.Crowcroft at cl.cam.ac.uk>= >>
>>
there's no free lunch - if the queue kee= >>ps being filled, you'll get increasing
>>packet loss - to cover the loss, you'll need more redundency in your er= >>asure
>>coding - this will cost you more delay at source (in constructing more
>>redundency) and more overhead in the net, which is a positive feedback loop= >>,
>>just like retransmitting a whole window into a congested queue/path - a
>>"vicious cycle" as opposed to a virtuous one...
>>
>>so all that erasure codes buy you is delaying the point when you go over th= >>e
>>clif
>>
>>In missive <>qdMBxmYAP-w at mail.gmail.com">CANZhn5Gqyw6-XpaB2-XKmbahKidOap+ZDqGAJ2NqdMBxmY= >>AP-w at mail.gmail.com>, shun cai
>>=A0typed:
>>
>>=A0>>--f46d0444e84964e1a304d740bdcd
>>=A0>>Content-Type: text/plain; charset=3DISO-8859-1
>>
=A0>>
>>=A0>>As discussed in chapter 1 of your PhD thesis, =A0when network is= >> congested,
>>=A0>>retransmission dominate the traffic and effective throughput dim= >>inshes
>>=A0>>rapidly, leading to a deteriorating situation. This can be illus= >>trated in
>>=A0>>the well known figure with two turning points Knee and Cliff.>> >>=A0>>
>>=A0>>
>>
=A0>> =A0 =A0 I wonder, however, does th= >>e situation the same if rateless erasure
>>=A0>>code (say fountain codes) is used? =A0As with erasure code, no A= >>CK and
>>=A0>>retransmission is needed except when the whole file is completed= >>. So even
>>=A0>>heavy loaded, the network is still busy with effective data pack= >>et, right?
>>=A0>>Although queueing delay will increase, I believe that =A0the net= >>work
>>=A0>>throughput =A0will not =A0suffer the plunge as un-coded network.= >>
>>=A0>>
>>=A0>>
>>=A0>>
>>=A0>>Kara
>>=A0>>
>>=A0>>
>>=A0>>
>>=A0>>
>>=A0>>
>>=A0>>
>>=A0>>2013/3/5 Srinivasan Keshav <>o.ca">keshav at uwaterloo.ca>
>>=A0>>
>>=A0>>> To answer this question, I put together some slides for a p= >>resentation at
>>=A0>>> the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save= >> costs, we
>>=A0>>> always size a shared resource (such as a link or a router) = >>smaller than the
>>=A0>>> sum of peak demands. This can result in transient or persis= >>tent overloads,
>>=A0>>> reducing user-perceived performance. Transient overloads ar= >>e easily
>>=A0>>> relieved by a buffer, but persistent overload requires redu= >>ctions of source
>>=A0>>> loads, which is the role of congestion control. Lacking con= >>gestion control,
>>=A0>>> or worse, with an inappropriate response to a performance p= >>roblem (such as
>>=A0>>> by increasing the load), shared network resources are alway= >>s overloaded
>>=A0>>> leading to delays, losses, and eventually collapse, where e= >>very packet that
>>=A0>>> is sent is a retransmission and no source makes progress. A= >> more detailed
>>=A0>>> description can also be found in chapter 1 of my PhD thesis= >> [2].
>>=A0>>>
>>=A0>>> Incidentally, the distributed optimization approach that Jo= >>n mentioned is
>>=A0>>> described beautifully in [3].
>>=A0>>>
>>=A0>>> hope this helps,
>>=A0>>> keshav
>>=A0>>>
>>=A0>>> [1] Congestion and Congestion Control, Presentation at IRTF= >> ICCRG
>>=A0>>> Workshop, PFLDnet, 2007, Los Angeles (California), USA, Feb= >>ruary 2007.
>>=A0>>> >rs/data/07/congestion.pdf" target=3D"_blank">http://blizzard.cs.uwaterloo.c= >>a/keshav/home/Papers/data/07/congestion.pdf
>>=A0>>>
>>=A0>>> [2] S. Keshav, Congestion Control in Computer Networks PhD = >>Thesis,
>>=A0>>> published as UC Berkeley TR-654, September 1991
>>=A0>>> >rs/data/91/thesis/ch1.pdf" target=3D"_blank">http://blizzard.cs.uwaterloo.c= >>a/keshav/home/Papers/data/91/thesis/ch1.pdf
>>=A0>>>
>>=A0>>> [3] Palomar, Daniel P., and Mung Chiang. "A tutorial o= >>n decomposition
>>=A0>>> methods for network utility maximization." Selected Ar= >>eas in
>>=A0>>> Communications, IEEE Journal on 24.8 (2006): 1439-1451.
>>=A0>>> >.pdf" target=3D"_blank">http://www.princeton.edu/~chiangm/decomptutorial.pd= >>f
>>=A0>>>
>>=A0>>>
>>=A0>>>
>>=A0>>
>>
=A0>>--f46d0444e84964e1a304d740bdcd
>>=A0>>Content-Type: text/html; charset=3DISO-8859-1
>>=A0>>Content-Transfer-Encoding: quoted-printable
>>=A0>>
>>=A0>>As discussed in chapter 1 of your PhD thesis,=3DA0 when network = >>is congested,=3D
>>=A0>> retransmission dominate the traffic and effective throughput di= >>minshes rap=3D
>>=A0>>idly, leading to a deteriorating situation. This can be illustra= >>ted in the =3D
>>=A0>>well known figure with two turning points Knee and Cliff. <br= >>>
>>=A0>><img src=3D3D"data:image/png;base64,iVBORw0KGgoAAAANSUhE= >>UgAAAOUAAAFECAIAAABXn=3D
>>=A0>>G6+AAAgAElEQVR4nOxdZ1xTydeOFfuqq7uL69rL7uqquy5WXFRELKiAWMDeUFEQU= >>VERRVF6ryoq=3D
>>=A0>>IKxrowjSpKggSG9SBek9IQkhhYQkd94P82b+Q7CAFEXyfOAXbu69M3fy3DNnzjlz= >>DqnP+0BI0H5=3D
>>=A0>>IRrKzIDaGJBJp5cqVNTU1AACSZJQ7C5KR7CxI+NodkIxkZ+G9fK2trZXwtQWEGAQ= >>CgUAgaP3tRy=3D
>>=A0>>7/NkYSPaZAIIAf0FMLRBAbB3gEP4iP4SfHrTUkfG0T0OByuVw+n99L+CoQCPh8Pk= >>EQfBHESCl2A=3D
>>=A0>>vpKIBDweDz4b3Nzc3NzM+I3n8+HfEWXtKtLEr5+GnB8ISn5fH5zczP8kQhM7n78D= >>j1xJOHDQkrx=3D
>>=A0>>eDxERz6fDwAgCAIxDw0OLjvhtTg18bFCQ9qZfO2SYeiZAAAAAOAQAxGINvO1JwJS= >>kxDN9c3NzQK=3D
>>=A0>>BAA4CjUZjMBgEpg/gAwJPQ58J0SiBlkCtdKSTAICoqKi6ujoJX/8HGo2Wl5eXn59= >>Po9EEAgGTyX=3D
>>=A0>>z79m1FRQWXyyXaoAz0UODCDypCAoGgtrY2Ojra2dnZy8vr3bt3DAaDx+NxudyKio= >>q8vDwmk0kQB=3D
>>=A0>>IfDqa+vZ7FYUA3g8Xj5+fmxsbEFBQVMJpPBYBQVFZWWljY0NKBp6rMh4as4AAARE= >>RFbtmy5cOFC=3D
>>=A0>>QUEBl8t98uSJgYHBixcv2Gy22EriC/azK4DP8nw+Pz09/ezZs0eOHLly5YqRkZGB= >>gYG5uXlcXBy=3D
>>=A0>>NRnvw4IGOjk5mZiYAoKSkxNXVNSwsjMViAQDKysqsrKz279+vrq7u5OTk4uJiaWl= >>paWn54sULXL=3D
>>=A0>>X9PEj4Kg4AgKen5+jRo/fs2VNcXJyWlnbq1CknJ6eysjIoHsD7gK79yBF08KsFUk= >>YBAHV1dadOn=3D
>>=A0>>frzzz9dXFxqa2vz8vL09PR+++03KysrDodz9+7dJUuWvHjxAgBQVVXl5OT0+PHjp= >>qYmNpvt5eWl=3D
>>=A0>>q6trY2OjoaGxatUqWVlZb2/ve/fuPX/+nMfj8Xg8CV87EwCAhISE5cuX79u3LyQk= >>xMjIyMnJqbq=3D
>>=A0>>6GqlobDa7rq4OznRVVVVUKhWtJOh0ekVFRW1tbWNjI5RSLBarsrKSQqFwuVy0lIY= >>rkq9TPCNDVW=3D
>>=A0>>ho6F9//bVp06aysjL4suXm5p4/f97R0ZHFYnl5eS1duvT58+cAAD6fX1VVVVdXRx= >>BEUVHRvn37j=3D
>>=A0>>h8/XlRUlJ6efuDAgSVLlqSnp1OpVCqVCnXijnQP8pVMJkv4+v8AAJDJ5KNHj8rLy= >>69fv37BggXB=3D
>>=A0>>wcFw9QAp+OLFiwMHDjg6Ot69e9fQ0NDa2jonJ0coFNbW1jo4OOjr6xsbG7u7u9fV= >>1fH5fF9f3wM=3D
>>=A0>>HDty4cSMmJqaoqAgZfVpbLr8SwF41NTU5OjqOGTNmx44dVCoV2QdSU1OjoqIaGxu= >>9vLzk5OSio6=3D
>>=A0>>MBANXV1f7+/ikpKQKBICEhQVZWdtGiRREREVlZWevWrfvtt98iIiLQ+rWDL6qEr+= >>IAAFCp1OPHj=3D
>>=A0>>0+dOlVeXl5GRubKlSuVlZUEQUDd6/Hjx2PHjl28eLGXl9fjx481NTVv377NYrGio= >>qJ2797t5ub2=3D
>>=A0>>33//7dmz5+XLl2VlZYcPH96xY8fTp0/t7e2dnZ1ra2uR9+Fr4yu+uudwOI6OjqNH= >>j1ZXV6fRaIT=3D
>>=A0>>IIN3U1MRisbhcrru7u6ysbFRUFACgtLRUS0vL2tqayWS+ePFi0aJFsrKyMTExubm= >>5W7ZsmT59+s=3D
>>=A0>>OHD6EagJtsPw8SvooDAPDu3btdu3Zt3LgxICDAwcFh8+bN7u7uVCqVIAihUBgQEP= >>Dnn38eOnSoq=3D
>>=A0>>KiosbHRwcHB1ta2qKjo2rVrGzduDA4OTkhIOH369L179169eqWmpmZmZpaXl+ft7= >>W1kZJSVlfUZ=3D
>>=A0>>NsjuAb7YYrFYLi4uv/zyy/79+6ElC07ldDqdyWQKBAIvLy9FRcVXr14BAJqbm83N= >>zc3MzDgcTn5=3D
>>=A0>>+/vbt2/X19RsaGphMprW19fr161NTU6EfoeNakISv4gAAJCUlqaio6OnplZeX19f= >>XGxkZrV279v=3D
>>=A0>>bt2zQaDQAQEhKydOnSCxcuUCiUxsZGZ2dnR0fH/Px8IyOjdevWPXz48M2bNyEhIe= >>np6XFxcRoaG=3D
>>=A0>>hYWFtnZ2SkpKVFRUeXl5WhO/NrkKyFSXgEATU1N9+/fX7Bgwe7duysqKqA+QCaTb= >>9++HR4ezuVy=3D
>>=A0>>fXx8Nm/eHB8fD9UkFxcXBwcHHo9XUVFx8OBBExOTpqYmDofj5OSkrq5eWFgI1dwO= >>GgcIEV8pFIq=3D
>>=A0>>Er/8PAEBkZOTixYtVVVXT0tKamppcXV1/+umntWvXJiUlCYXCsLCw6dOna2hoFBc= >>Xl5eXX7hwwc=3D
>>=A0>>LCgkKh+Pv7q6qqenp6pqamPnjwoKqqKjc3d//+/RcvXszNzS0oKIiLiysvL29ubi= >>Ywj/zXA9wVw=3D
>>=A0>>ufzMzMztbS0ZGRkbG1tS0tLaTSav7+/mpra/fv3mUymq6vrokWLgoKChEJhUVHRo= >>UOHzp8/39jY=3D
>>=A0>>mJOTs2HDBk1NTTKZXF1dffjwYRkZmeTkZEjr5ubmTrEPSPj6PwAAUlJSLl26ZGlp= >>mZubS6fTfXx=3D
>>=A0>>8zp07Z2pqmpmZKRAIsrKyrl69evfuXQqFUlFR4eXlFRoayuFwKisr7e3tDQwMLC0= >>tHR0dS0tLmU=3D
>>=A0>>xmaGiovr6+jY3Nf//9Fx0dTaPRkM3oa9MKcOcqFIfp6emHDx9WUlK6ePGiubm5tr= >>a2g4NDRUUFj=3D
>>=A0>>UYzNzeXk5Pz9PSsra319vZeuXLl8ePH3717Fx0draKioqGhER8fn56evm3btqVLl= >>wYEBOCuWglf=3D
>>=A0>>OxlNTU319fX19fUcDofH49FoNAqFQiaTORwOQRBcLpdKpUI1rqmpiUqlNjY2QvJV= >>VFS8fPkyMjI=3D
>>=A0>>yNzcXGs/ZbHZ8fHxoaGhKSgpUJ/BlzRd+zvcBiVjY1fz8/EePHp07d+7s2bOPHj2= >>qqqoiCILJZL=3D
>>=A0>>5+/drX1zcjI4NCoSQmJvr4+ERGRlZVVRUXF4eEhDx9+jQ/P7+ysjIsLMzf3z8zMx= >>Oa8zo+q0j4+=3D
>>=A0>>h681yOADP4f+gz/JQgCuc7RCTD+A57zdWqu7wUyQlVUVFRWVsLAF7EICnz5iEx1Y= >>lFd+Equ412S=3D
>>=A0>>8LVzgMQSBBInOKFxNaCnsBaqB+ih4ISO/hVicS2Iu2IvMIEFf3VcvkZGRkr42gkQ= >>C7R771dI6ny=3D
>>=A0>>1Vi0x4EZTsadDXxEtdV+ipUDFz+8U+Srha0fR+pdAR3ASf+T8rxawq2J2/tYvHn5= >>EjLUENggd7w=3D
>>=A0>>/ka319vYSvn4+P8LX1IqNTlh3dBriiR4RDxMUfWexxJHxtE74IAz4kKTt3EvyCEN= >>MHxPRvYcsVF=3D
>>=A0>>dJoCUwlaH3DjvTnG+Errtd3Pz/ErATEN8RX4qPMw0VsUVERtCGI6ayd25lvhK9oi= >>5UQQ/c0LRAI=3D
>>=A0>>WCxWY2Njx4PneygAADwez8vLy8nJCe6s6rrx7/F8BQA0NDQkJSXBaL3ul2pNTU3P= >>nj3z8PCoqqr=3D
>>=A0>>q6aL08wAA4HK5BgYGGzduzM7OBqJ9b10xGt8CX7Oysk6fPv3o0SM2m02ItnF2Wwd= >>YLJaNjc3u3b=3D
>>=A0>>uzsrK+2kCWLgWUr66urjo6Om/fvgXYxsyuaKsH8xUOTUxMzOLFi3V1dSsrKwEAHQ= >>8Cahe4XG5YW=3D
>>=A0>>Jirq2tJSUnPWvt3IoRCYVVV1bt371gsFtLHusLA3OP52tzcfP/+/QkTJqxYsSIpK= >>an7XfNCoZDJ=3D
>>=A0>>ZFKp1KamJuKbWGB9HtCiE00yEr7+D8iAwmAw9PT0Bg0aNGfOnODgYB6PR3Q7X8Uc= >>sN3W9FcFJpN=3D
>>=A0>>Jo9HQqreLtLIexlc0ENAoCACoqalRVVUlkUiTJ0++c+cOVGG7kzQCgaCysvLt27e= >>NjY3EVxnY2t=3D
>>=A0>>WAMjUwMNDJyamiooJo6art9LZ6GF/x3EwAgPj4eFlZWRKJNHbs2KtXr0LPcrf1Bw= >>DA4XD+/fdfm=3D
>>=A0>>Kygd4pYuN66dOnShg0bMjIyiK5c8vY8vuIaKpvNtrS0HDduHIlE6tOnz6ZNmzIzM= >>yGPu6c/AAAW=3D
>>=A0>>i2Vqarpu3brU1NTuafRrA+SroaHh6tWr09LSJPbX/0FsILKystTV1SdPnjxy5Mhx= >>48YtX74cWbW=3D
>>=A0>>6B5CvZmZmcFddt7X7VQHaXy9cuLBhwwa4tZBoGTnZuW31JL4SWIIxPp8fGRmppaW= >>lqakpIyNz5M=3D
>>=A0>>iRS5cueXp6NjQ0dFtnIF9tbGy2bduWmpraO11ckK82NjaGhoZwA4LwfUlzO6utns= >>RXKF+RxaSoq=3D
>>=A0>>Cg+Pv7x48erV6++ceNGenr6mzdvmExmd2qQPB4vKSkpICCAQqH0Ns0VAsqOlJSU1= >>NRU6GLsOqti=3D
>>=A0>>z+Mr0dJKIBQKX758qaCgcPv2bZiPreNJbz6jPwJRTkkCC75BaB0Qg04TiwvBbyIW= >>udc6pge0zNK=3D
>>=A0>>FH8ebw0cDnibWf3Qy3kP8YGt86DjeSYl8FQccoOfPnysoKLi5ubHZbLHfo6uBzMB= >>iwPVssd8S7R=3D
>>=A0>>iBp6EPAlHqanQynuFa7OZoUwp+PpqCAcZjoSjhdWuqvbfzxIeJ2PpMBoMB02g2NT= >>VRKBSYfrT1C=3D
>>=A0>>HQiQE/nK0EQiK8sFovo9kDY5ubmysrK5OTkuLi4hISE2NjYhISEmpoa2I3q6ur4+= >>Pjo6OiYmJjU=3D
>>=A0>>1FQqlcrn88lkcmpq6qtXr2JjY2NiYjIyMqDttr6+PikpKSYmJiYmJjY2FmbggscT= >>ExNfvnz54sW=3D
>>=A0>>LhIQEmCCIz+cXFxfHxcXFxMS8fPkyIyMDJmJpbGxMSUmBJ8fExMAYv+bmZjKZnJK= >>S8urVq5iYmP=3D
>>=A0>>T0dCaTCYlVWVmZmJj46tWr+Pj4hISEgoKCwsLC5OTk+Pj4169fJ74P8PjLly9dXV= >>3v3Lnz9OnTx=3D
>>=A0>>48fwx3w4eHhiYmJJSUl+ITTiZDwtaPgcDg+Pj7btm1TVFRcv379pk2b9uzZExERA= >>XcwR0ZGHjhw=3D
>>=A0>>YNOmTRs3btTV1U1LSxMIBHFxcdra2ioqKioqKsrKypcvXy4qKmpqagoKCtqzZ4+K= >>ioqSktLevXt=3D
>>=A0>>fvnzJ4/EAAC9fvty7d6+ysvLGjRuPHj2alpYmFAo5HI63t7eGhsbGjRs3b95sYmJ= >>SUlICACgoKD=3D
>>=A0>>hx4oSqqqqKisqWLVtgCkEGg+Hu7q6mprZu3bpVq1apqqrevXuXTCYXFBRcunRpzZ= >>o1CgoKa9asW=3D
>>=A0>>bNmzdGjRzU1NVevXi0vL6+goLD6fVBQUFBUVJSTk5syZcrMmTMXLlz4559/jhkzZ= >>vz48UuXLlVS=3D
>>=A0>>UnJ1dYVzXaePtoSvnw9kA7a1tR01atTPP/+sqalpY2Nz8+bNnJwcmJ86IyPjxo0b= >>9vb2tra2Xl5=3D
>>=A0>>eUPAUFBR4eHjY2dnZ2tra2Nj4+fnV1tZyOJz4+HgXFxd7e3tLS0sXF5c3b97ALdT= >>Z2dk3btyws7=3D
>>=A0>>OztrZ2d3cvLS0VCAQ8Hg9mvrazs4M3gVmlqFTq/fv37ezsLCwsrK2tk5OTqVRqQk= >>LClStX5s2bJ=3D
>>=A0>>yUl1bdvXykpqblz52pqampoaIwfP56EYejQocOHDx84cKCUlNSgQYMGfhgDBgwYO= >>XLk5MmTJ0yY=3D
>>=A0>>MH78+AEDBkAr+MCBA3V0dGD6hU4fcwlfO9oBFotlaWk5atQoVVXV3NxcqCwiLxeP= >>x2tqaoI51Ju=3D
>>=A0>>ampB7HR3kcrnQYycUCtERLpfL4XBg5iKCIGBiDg6H09TUBG8C9Vd4c3hn2JnGxkY= >>KhVJYWBgWFu=3D
>>=A0>>bl5eXp6enu7m5kZKSqqrps2TIxakL06dPnu++++/7770ePHj1y5Mgff/xxyZIlW7= >>du3bJly9atW=3D
>>=A0>>7dt27alFTZv3qymprZ161Z9ff3r1687Ozvb29svWLAA3VBHRwfqG10x4BK+dqgD0= >>Mc2d+5cd3d3=3D
>>=A0>>OH2jpQ9u1sFXS0SrNQ2Bxc20Pv7er3A0Njbm5ubGx8fb2dnp6+sfO3Zs9erVv/76= >>67Rp0yZNmjR=3D
>>=A0>>y5EicoIMHD54xY8acOXPmzJkze/bs9evXGxoampubm5iYmJiY2Nvbh4aGZmdnZ2V= >>l5eTk5Ofn53=3D
>>=A0>>4YFRUVMG8zhUIxNTX99ddf+/fv37dv35MnT3aR10bC17YCNy3hHWAwGBYWFocPH8= >>7NzRW2THYCP=3D
>>=A0>>+PlkAjMGiVsmQpFzLQstuUfJ3pDQ0NWVhbMfxgYGHj//v2LFy+uXr160aJF48aNG= >>zZs2KBBg4YN=3D
>>=A0>>GzZx4sTffvvtt99++/XXX2VkZNauXausrKyioqKrq3v//v1nz56Fh4eHh4enpKTU= >>1NQwGAwmk9n=3D
>>=A0>>Y2AhzK3389XgvCgsL3dzcZGVlBw4cuGfPnrKyMok9SxzdzFeBQIAHg8MPNBrNz88= >>vKioKtt4uCD=3D
>>=A0>>BAXkJyo+gzBKj1BgYGPnjwwMLCQllZGRJ0ypQpP/3008iRI6WkpIYOHbpkyZItW7= >>aoqqoePXr0z=3D
>>=A0>>p07/v7+AQEBT548iYyMzM7OLisrKy0thboyNBog1eUzCApamZMpFIqBgcGwYcP+/= >>vvv8PBwiT1L=3D
>>=A0>>HN3JV4Ig8BJq6CCPx6NQKHhcfRvvhstXeGc81Q8El8utrq7Ozs728PBQV1efNWuW= >>tLT0999/P2D=3D
>>=A0>>AgL59+w4ePFhaWnrq1KkbN240NDS0tbWNiYkpLCwsKCioqKiApESatBj738u5z4Z= >>QKGxoaKivrz=3D
>>=A0>>czMxs5cuSECRO8vb2FXRB4JOFrOwAnOChlCZHGKRQK3759Gx8fT6fT2xVMKKYDIA= >>I1NTXR6fSSk=3D
>>=A0>>pKoqChPT089PT0lJaXp06f369cPCtGpU6euW7dOWVn52LFjd+7cCQgIyMzMbGxsb= >>GpqEqM77rMQ=3D
>>=A0>>e5D2vl0fAQCAx+M9efLE29v73LlzI0eOHD9+vKenp0S+iqOb9QEc8Cfncrk1NTUu= >>Li7Hjx/Pzs5=3D
>>=A0>>u7w3RB0gvCoWSnp7u4eFhZGR06NChv/766+effx48eDBcJ02dOvXo0aNXrlxxd3d= >>PTU2Fyx1Ywo=3D
>>=A0>>5o6eUS6zCub3RFeC6cB4yNjVVVVffu3Qtj5Tw8PDq3FdSWhK/tBpxnWSxWRESEn5= >>+fvr7+xo0bU=3D
>>=A0>>1JS2kgIXATy+fyGhobc3FwfHx9dXd1Vq1ZNmTJl2LBhQ4YMkZKSmjhx4ooVKxQVF= >>TU0NDw8PAoL=3D
>>=A0>>C+HaCN0EDQJOU6KV+x5f5Il96DiAKF572bJlmzdvHjVq1IQJE9zd3aETuFOawNuS= >>8LUdEIqCO4V=3D
>>=A0>>CYVxc3MmTJz09PS9evKikpATdTh/nK85UDocTGxvr5uYGL58wYcKgQYNIJNLo0aO= >>XLVu2ZcsWPT=3D
>>=A0>>09b2/vnJyc0tLSmpoaNpuNZ2BFVBBieatbzwBES0HeRXyF8a+rVq06derUjBkzJk= >>6cCPnaKfcXa=3D
>>=A0>>0vC1zYBkQCSpqGhwcTEZP/+/YmJifb29hoaGhkZGWKEIDBa4OppWVkZrPG5dOlSa= >>WnpESNG9OvX=3D
>>=A0>>T1paevv27efOnXNycoqNjS0pKamvr29qamq9Hhd7wNZ0xPHeEzprNOBnyFdXV1c7= >>O7tnz57BKcL=3D
>>=A0>>Dw0NizxJHd/IVeZXg3/j4eA0NDUdHx7q6utDQUB8fHyqVKhTZvPANTFAW8ng8Mpn= >>8+vVrb2/vY8=3D
>>=A0>>eOzZw5c8CAAQMHDpw2bdry5ctVVFRcXV0LCwvZbHZTU1Onr987Hejthf/C/Fl1dX= >>Xv3r3bsGHD5=3D
>>=A0>>MmTJfrre9DN8hUZs4RC4Zs3b9zc3GBOl4aGBhaLhWZk6CbFxWpBQYGjo+OJEydWr= >>lw5derUgQMH=3D
>>=A0>>Dho0aMaMGbt37/b09ExLS8vJycG1UoClXe9S9ebzICa5oSkXdru4uFhZWXnatGke= >>Hh5d0XMJX9s=3D
>>=A0>>K3AYEtU8ajQaDWpBAhWzGg01LS0uDgoL2798vLS09aNCgvn37Tpw4cdWqVQYGBv7= >>+/nAXOFowiS=3D
>>=A0>>3ku+IpOhG4fiwQCKqqquh0ekFBwYYNG6ZMmXL9+nXone7cRiV8bSuQUOHxeAwGA0= >>pQoVDI5XJfv=3D
>>=A0>>37t7+9PJpMRm2Fwqr+//8GDBydNmtSvX7++ffvOnDlz+/btDx48KCsra2hogHowg= >>b0JkPqtDVJd=3D
>>=A0>>8TgdhFC0jwM+L51Ot7CwcHJySkxMVFJS+vHHH83NzblcroSvLdD9+kBzc3Nubu7N= >>mzdhsJ9AIGA=3D
>>=A0>>ymXZ2dhoaGpmZmVCmvnv3ztHRcceOHbNmzRowYMCQIUNkZGTOnTvn5+dXVFTE4XB= >>wWyl08CIvF0=3D
>>=A0>>7Qr5avQmw7IeRrYmKivLz8xo0bg4KCVFRU+vXrd/LkSbhY7NymJXxtB4RCYVNT05= >>MnT86ePfvmz=3D
>>=A0>>Rv4U8H93Bs3bkxLS6uvr4+NjT127BgMiRoyZMicOXMuXLgQExODdkGK2aGQq0z4A= >>VvYV0hZXH+F=3D
>>=A0>>gxAQEDBjxgx5efmAgIDNmzf369fvxIkTEr6Ko5vlK0EQFArl33//DQkJaWhogFRj= >>s9lWVlbr1q1=3D
>>=A0>>zdXU9d+6cnJzc0KFDBw0aNG7cuJ07dwYFBdXV1aGu4n1rYz+/Qr4SLe0DAICMjAw= >>FBYVly5YFBg=3D
>>=A0>>Zu3ry5b9++Ojo6XbHFQMLXdkAoFMbGxl67dq2oqIgQebm4XK6dnd306dNnzpw5dO= >>hQEok0bdq08=3D
>>=A0>>+fP+/n5ZWdnw7VXV3hBvyzEFoUsFsva2lpbWzssLExZWbl///7a2tpdscVAwtd2t= >>MXn8589e+bg=3D
>>=A0>>4FBVVYWsTkVFRUePHoVe/vHjx+/cufPp06cwUx/aOPD1L/bbBTF7FnwbqVRqfX09= >>rHc8cOBAbW1=3D
>>=A0>>tiXwVRzfzVSgUlpeX5+fnw5Uvl8uNjIzU1NScOHHid999t3DhQmtr69LSUmTnF2I= >>Rg13RpS8F3J=3D
>>=A0>>KF1G5kv1NWVu7bt++JEyfgyrJzm5bwta0QCoUweQn0qSYkJNja2q5YsaJ///5SUl= >>K7du16/vw5l=3D
>>=A0>>UrFL0FM/Sb1AZQbAa4aKysrGxoaioqKoH1AV1dXIl/F0W18BQAUFhYGBgbC/FCRk= >>ZHr1q0bNmxY=3D
>>=A0>>//79f/vtt8WLF3t7e8PlMF5dTYhtaPn2+IrsWUKhMD8/X19f393dPS0tTVVVtX//= >>/hK+vgfdw1c=3D
>>=A0>>49d+7d8/JySk/Pz8wMHDlypX9+vUbMWKEkpKSh4eHtbV1aGgoXF4IW+Lbk6wEpr8= >>i+0BMTIyCgs=3D
>>=A0>>KVK1cSEhKUlZUHDBigo6Mj0QfEAXWm58+fy8vL37x5E/K14xTB5SL8NzU19dy5c3= >>fu3LGwsJg5c=3D
>>=A0>>yZcWllbW5eVldXU1Li5uQUFBcEcLUS3J+z4IoCDg5Jo02i0M2fOqKurh4aGqqurS= >>0lJ6erqSvxb=3D
>>=A0>>4kB8Xbly5Y0bN9Ce944zBm2ogtqqq6vr7t27NTU1p06dKiUl9ffffzs6OtJoNABA= >>RUXF2bNnHz9=3D
>>=A0>>+zOFwvklp2hr41AG3slEoFC0tLXl5+bi4uFu3bv300087duyA5Xo6t+kez1eCIOL= >>i4g4fPhwaGs=3D
>>=A0>>rlcsUqSX82kA5aWlp6+/ZtBQWFH3/8cfjw4X369FFUVHz+/DnKbVZUVKSjo/PgwQ= >>PI12/MFPBe4=3D
>>=A0>>Bo5HITCwsJdu3adPn2aQqEkJCRMmjRp8uTJT58+RaaSzkKP5yubzfb09Lx8+XJJS= >>QkhypzfwfUN=3D
>>=A0>>ol1NTY2RkdHEiRP79+9PIpEGDRq0bdu26Oho5P0nCKKhoSEmJgYauXAt4psHrsKy= >>WKy4uDhYLC4=3D
>>=A0>>+Ph5u6XFzcyPel120I+jxfKXRaPr6+np6etCGj6KqO3JboSgO68aNG5MmTerbty8= >>MBjh48GBubi=3D
>>=A0>>4yAoiZHr9VU0Br4KvJ1vvFExISpk6dOnr0aE9PT0LCVxwAACaTeevWratXr0JDvR= >>DbzPTZt4U3o=3D
>>=A0>>VAohw4dgpJ12LBh+/fvz8vLA1gEIAx7bW5uZjKZHA7nGzYItAZiKvzb1NSUl5dXX= >>V2N+DpixAi4=3D
>>=A0>>xaBb+SoUZY7+CMQsOPi1QswLgr4SOy7WHP5tW3rPZDJdXFyMjIxKSkrQ5W3nK66H= >>IcLB49HR0cu=3D
>>=A0>>XL+/Xrx+JRFq8eHFERASuBkCmEgRBo9ECAgLS0tJgPGiv0l/R9JKRkaGtrR0eHg4= >>AiIuLmzRp0n=3D
>>=A0>>ffffcF5KtAIOBhaG5uRh+QpOHxePhGEfTa4YH3+FyJTkCsEn4Abek9lUo1MDA4ff= >>p0aWkpgZmi2=3D
>>=A0>>vj86Hzo6+fz+TAqnkwmnzt37ocffiCRSBMnTnRwcIBjhF8If6qysrLTp0/7+PigU= >>nW9Qb4KsexM=3D
>>=A0>>AABfX98lS5b4+fkBAHJzc+Xl5b///nt3d3dhZ6d4+bQ+UF9ff+PGDWNjYysrq3Pn= >>zhkbG5uZmV2=3D
>>=A0>>5cuX58+cVFRUhISEpKSko1Bz9xX9+IeZGF4iynkOWE60seUR7OAcAqKur271796F= >>DhyoqKpA+0K=3D
>>=A0>>4hwF8klGolKioKlqEjkUg7d+6EyvF7O1BaWqqnpwftWaArS099VcBlEADAx8dnyZ= >>Il/v7+AAAOh=3D
>>=A0>>3Pt2rXvvvtOS0sLjlsnDsin5Wt4ePjatWtPnTp1/vx5aWlpVVXVa9euLV26dM+eP= >>c+ePTt37ty/=3D
>>=A0>>//6L7zQXirRvvJeQ0PAnR/MmZDPuhhablNvS+7q6uj179hw5cgRV0mnvEKAXBoVT= >>USgUfX390aN=3D
>>=A0>>H9+vXb/bs2Q8fPvzQViQAQHFx8alTpx49eoT7t9rbh54FsdkSAPD06dPVq1cHBgZ= >>CfcnR0XHIkC=3D
>>=A0>>GLFy9OTk7uPr4CABgMxuXLl3fu3Jmdnf3s2bPff//94sWL7969O3PmzIYNGwICAg= >>wMDDw8PCgUC=3D
>>=A0>>sweBQCAdETGHaQtEATBZDIbGhoQL3EGtFaF29h7Mpm8f//+w4cPQ/kKj7drgISil= >>ZNQtNvTx8dn=3D
>>=A0>>8uTJJBJp2bJlAQEBHymQBACoqqpydXWNjo7mcDhtb7RHAxcu8EhVVZWHh0dycjJB= >>EDwez9bWdsi=3D
>>=A0>>QIbKysikpKd3K14aGBnt7++vXrzc2NoaGhv7+++8GBgZVVVW3b98+ceJEZGTkqVO= >>njh496u3t/f=3D
>>=A0>>Tp0/T0dLgHv7a2Njg4GBaTCAoKqqqqgvvvnj17FhYWVllZCYUrlUotLy9ns9nNzc= >>3V1dW1tbVoM=3D
>>=A0>>1Pb9de6urq9e/cifaC9Kx5cz4bvW1lZ2aFDh/r16zdmzBhnZ2foVPxQfwAALBYrL= >>y+vtxXfwidD=3D
>>=A0>>qPLBnOAEQfD5fBsbm0GDBi1dujQpKalb9YGmpqaSkhJYRDgkJGTBggXm5uZUKrnP= >>bZ0AACAASUR=3D
>>=A0>>BVLW0tDQ1NTUrK0tTU3POnDmmpqYeHh66urqBgYEsFiswMFBeXn779u2nTp1SUVF= >>58OBBTEzMtW=3D
>>=A0>>vX7t69e+fOHTMzs7y8PB6P9/DhQ0NDw8LCQgqF4uLicvPmzdraWtStNvYeyVfo/R= >>N77z8JpLPCC=3D
>>=A0>>7lcrpeX18yZM7///vsjR47k5OQQoti5D92z9VzRGyDEjK8CUdQLyidiZWU1ePDgZ= >>cuWdas+gM6A=3D
>>=A0>>CAkJWb16tYeHB3Q8AgDKy8uPHj2qoKDw/Pnz2NhYeXl5BwcHBoNx+/btCRMmKCoq= >>+vr6ent7BwY=3D
>>=A0>>GXrhwQU1NLSEhITIyUlFR8fbt2wwGw8TEZOXKlenp6dXV1ceOHTt58iSsJIH02o8= >>8J9L0yWTyvn=3D
>>=A0>>37Dh48WFZWhoamvfYBgShUoL6+/vjx41JSUrKyslFRUTD7n1iCbDE0NzdDP3DvKc= >>aJ1qboSGNjY=3D
>>=A0>>1RUVEFBAUEQfD7fzs5u0KBBy5Ytg+WP8ZV0B7n7afsrOi8kJGTt2rX37t1DCXNKS= >>0vPnTtnampK=3D
>>=A0>>o9FSUlLk5eUdHR0ZDIabm9tvv/125swZeN/IyMj169efPHmyvLy8qKho3759xsbG= >>VCrV1NR0xYo=3D
>>=A0>>VaWlpVVVVx44d09PTKy0thQWrUlNToYP+40OG1luHDx9G/oJ2DQqUB0gZyM/PX7d= >>u3ejRow0NDW=3D
>>=A0>>ENLSG20f69d6DT6c+fPy8qKuptfEXjDAB49erV9u3b0XrL2dl5+PDhy5YtS09PB1= >>g1h27l65MnT=3D
>>=A0>>xQUFP79919ogiUIoqCg4OzZsw8ePAAApKSkrF692snJicVi3bx5c8mSJb6+vlAEh= >>oeHq6mpwYjm=3D
>>=A0>>jIyMHTt2WFpa0un0q1evrly58s2bN4WFhXv27NHV1S0qKioqKvL19Q0NDa2rq2v9= >>bGJ0BADU1tb=3D
>>=A0>>u27fv9OnT5eXlrU9oC5BwpdForq6u48ePX7BgwcuXL8XG90P6a2VlpYWFRWRkJMq= >>g0XsUWaj6Q3=3D
>>=A0>>vWokWL/Pz8CIIQCoVBQUHz5s1btmwZ1F/F7D8dafHTfIUv07t37wwMDBYvXgz5Cr= >>XssLAwVVVVd=3D
>>=A0>>3d3Ho/37NmzJUuWGBsbl5eXW1paLly40NfXF/HAwcHBwsLi+fPnBgYGcnJyvr6+b= >>DbbxcVFUVHR=3D
>>=A0>>39//8ePHK1eu1NbWLisr43A4dXV1FAoFpaD6eO/r6upOnDhhampKJpOJ9s848Hyo= >>gURFRcnJyQ0=3D
>>=A0>>ePPjIkSP43T5SkFYoFObk5Njb28fHx8PVRi/hK673AwD8/f2XLl0K7a8AgLdv327= >>btk1GRiYiIg=3D
>>=A0>>LNTsKWVvbPw6f5Clchr1690tHROXTo0IsXL6BWx+PxAgMDjx8//uzZMyaTGRgYuH= >>fvXjs7u+TkZ=3D
>>=A0>>BcXl/379//3338oOVRqaqqFhYWJiYmWlpaxsXFhYaFAIEhLS7t8+bKdnZ2Tk5Our= >>q6bmxtM6YNs=3D
>>=A0>>W+/tj1DkPoUjRSaTtbW1r1y5Ul9fT7Q/WBvpwTU1NefPn//uu++mT59+7949+Iwf= >>j/aCxruEhIR=3D
>>=A0>>Hjx7V1NQgEdL21nsu8GGBPtht27YFBwfD366kpGTnzp0///yzra0tlUpFfhxhe1z= >>l78Wn+Qpnfx=3D
>>=A0>>qN9vbt2+LiYjqdjgz+ZDL53bt3dDqdy+VWVVXl5uaWl5fX19eXl5fDkg9QbYCMLy= >>sry87Ofvv2b=3D
>>=A0>>V1dHfxRuVwu3G4K1YC6ujoouYUf9m+15iuFQjl//rybmxvMSPXZwxEfHy8rKztky= >>JAjR44UFxcL=3D
>>=A0>>Wu4T/NA9BQJBVVVVXl4erL7ZnaXBvyzEfiMGgxEeHp6fn08QBOSrhobGpEmTrl+/= >>3tDQALBCYl3=3D
>>=A0>>OVwGW1wm+PUi8w3/R0hjJRdxuj0MgCp0hROlUQUugpfqHHgm/GzxSVVUFq05+nOg= >>fAryKx+N5eX=3D
>>=A0>>mNHz9+3LhxDx8+RI4u/JyPXN4pQbc9CIgVgpY1baBvCADw7t07DQ2N2bNno20X6K= >>oONv0JvuIGN=3D
>>=A0>>ry7hGjHCGi5/wRJI1xrQUwisGT7iFg4UwmCgEWh2shXgUAQHx9vYGCQlZVFtG2xJ= >>TZlw5MrKyuP=3D
>>=A0>>HTs2ePBgGRkZmNad+LBMbT2Cn/eq9Fygx0R85fF4LBYLTjKQrzt37hw7duzVq1fF= >>PCkdHKJP219=3D
>>=A0>>bA1/uoYz6+Goa/cWZKtZjMSrjnz/5wyOiC4VCPz8/PT293Nxc9NWHlEj8/vjz19f= >>Xu7m5ycnJyc=3D
>>=A0>>nJ3bx5k8FgtN3439zcXFRUlJeXh4pdtfHCHg1cXhAEAQnq6+sL0zQRBFFZWamnpz= >>dt2jRDQ0NYh=3D
>>=A0>>ZlomzT5JNrEV5xGYjMgi8WiUqlI5hOtRGBr2YN/hX5j3HT6yR8engYvcXFx2b17d= >>3Z2tpgS8qGr=3D
>>=A0>>Wj9UaGjowoULpaWlL168WF1d3XYzKgCgsbHx1q1bjo6O0J7QSyAmmKBtXlVVNTQ0= >>lCAIgUBAo9H=3D
>>=A0>>Onz//008/nTlzBvosO4WsRBvtWUQrcYi+zcrKunfv3tu3b99L0zZCIBCgctSffDD= >>0LVSdTU1NN2=3D
>>=A0>>zYAO3SYn345OMQBFFfX3/58uURI0ZMmjTp/v37KEynjWPHYDBMTU2NjY1hEkLiw2= >>/LNwZEAyg4H=3D
>>=A0>>j9+/Pfff8P4V6FQyOfzzc3NhwwZsmnTpoyMDFzSdbDdNumvRKvIf6FIxY6KitLS0= >>goJCYEKK55x=3D
>>=A0>>F6ejsJVwRfOyUChsaGjIycmpq6sDIh/0h55N2FLx4PP5FhYWKioq6enpeEMf4auY= >>MpCdnb1ly5Z=3D
>>=A0>>+/fqtWrUqPT1dIGiHDwby1dLS0traGmYiEvYaLRb/laG/YOHChdBfAGFnZzdw4MA= >>pU6Y8efLkve=3D
>>=A0>>WePw9t1V9RG2jPNIfD4fF4z58/37Fjx61bt+Def7R4QnYA9AEJxdYoLCz09vbOyM= >>jA9/F9RAcVi=3D
>>=A0>>ra98/l8a2trFRWVtLQ0dMJHjKA4nwAAbDbb29v7119/HT58+MWLF+vr64XtWcMCA= >>FgsVkBAQGho=3D
>>=A0>>KEyW0XvIii/EAQCxsbEnT5589eoVOgj5OmLEiLt370KzJrq2O/gKAOByuQUFBbAC= >>eU5Ojq+v78u=3D
>>=A0>>XLxMTEw8ePHjx4sXk5OS3b9/W1NTAUJX6+vri4uJ3797l5+cXFxdD4yiNRisrK6P= >>RaDwer66urq=3D
>>=A0>>ysDNZACw4O1tbW9vX1pdFoH2cMEthovIKCgo4dO4bXvvoIXwmM8QCA2tpaPT29oU= >>OHysrKRkdHo=3D
>>=A0>>0CCtg9fc3MzhUJhMBhiJrBvG0LRGgM9b0NDQ3FxcWNjI4oNCg4OnjVr1qhRo7y8v= >>KDdAF3bkabb=3D
>>=A0>>ut4iCCItLe3s2bPXrl2zt7c/fPjwzp077969m5OTc+DAAVlZWbhh5uLFi/B29+/f= >>P3LkiK6urrW=3D
>>=A0>>1tbGxsb+/f2NjY0pKyuXLl//777+6ujp/f//Lly8nJSXR6XQ3N7d169Zdu3atoKA= >>AOSM+IiPRMw=3D
>>=A0>>MAKioqrKys0FT+kUcV00kAAG/fvt2yZYuUlJSOjg5cMH2c6x8aQYDFhfUGyoqpXo= >>KWZnX4b1VVl=3D
>>=A0>>Zqa2vfff//w4UPI105Rlj693oI/IYVCMTY2Xrhwoaur6+3bt2fNmqWkpPT69evy8= >>vL9+/cvXLjw=3D
>>=A0>>zp077u7uioqKZ8+eLS4u9vDw+OOPPzZt2vTw4UN9ff1jx47l5uampqauX7/+1KlT= >>1dXV//3337p=3D
>>=A0>>16x48eMBkMv38/Pbu3evt7Q29mm1/MAAAlUp1cnLC9YGPKK+4iZsgiNDQUFhT2M3= >>NDYYrtFe+8v=3D
>>=A0>>l8uFLE7Sdtv7yHApGPEL3hLBYrPj4ebvmEJk46nb5r167vvvvO0dER6ordx1cAQH= >>l5+YkTJ/744=3D
>>=A0>>w9PT08fH5/Zs2erq6sXFxdXVVXt27dvz5490Fu7d+/egwcPlpSUZGRkbNiwwdDQs= >>LKy8vbt2xs3=3D
>>=A0>>bnzx4kVhYaGampqurm5dXV1ISMiGDRsePXrU3NwcERGhp6cXFxcHpxJhm7120Hrq= >>6OjYFr4Solh=3D
>>=A0>>VOMRUKtXIyOjHH3/csGFDamoqWsC1a73FZrMjIyNfv36NUs31EhMshEAUq56cnHz= >>48OGwsDAgcn=3D
>>=A0>>CSyeQdO3b069dPTU0NbV1u1/LgvWiTPUsoFMLtADDGMSIiwtDQMDg4mMlk1tbWnj= >>lz5tq1axQKh=3D
>>=A0>>Uwma2lpwa0phYWFW7ZsMTMzY7PZDx8+lJeXDw0NLSgoUFNTO3nyJIPBiIqKUlZWh= >>ovH8PDwM2fO=3D
>>=A0>>wFh0AvNHtKX37eKrQFTgisvlPnjwYO7cufPmzfPy8oI7tNC1bedrQ0ODtbU1jOog= >>sJqdbbm8RwM=3D
>>=A0>>fLgCAv7+/rKysr68vsoJTKJTdu3eTSKR58+bl5OSATtpl0FZ9AAAQERFhYmKSkpL= >>y5s2bnJwcuB=3D
>>=A0>>00JyfnyJEjNjY2dDq9rKxs7969u3btqqioKC4uVlNTu3DhQmFh4Y0bNxQUFKKioo= >>qLi7dv366lp=3D
>>=A0>>QXdIcuWLTtz5kxNTc2LFy9OnToVGhpaXFycl5dHo9Ha3vt28RV9W1paum3btuHDh= >>x88eBAGegtE=3D
>>=A0>>e9DbPqyQrxYWFqampvX19ehl6A18xZUfAICvr6+srOyTJ0+QFZxKpe7atYtEIv3x= >>xx/Qm9MpKtO=3D
>>=A0>>n+YoCGmDYtbq6uoaGxqFDhwICAthsdlJS0oEDBywsLOrq6tLS0vbt23f48OG8vDx= >>Yl3HFihUaGh=3D
>>=A0>>pr1qy5ePFiRUUFi8Xy9PRUUVHZuXOnqqqqtLT0X3/9lZqaWlRUdOnSpY0bNx4+fD= >>gyMpLJZLZx1=3D
>>=A0>>mgXX9F8JBAI7t69O2nSpGHDhp0/fx4lccdlRhtbZzAY5ubmV65cgZGQ7VInejqQu= >>g9E8a8+Pj5I=3D
>>=A0>>vjY0NOjp6Q0cOBDxVYjhsxttR/wALK20ffv2rVu3zp8/f+vWrbm5uQwGIzc3t7i4= >>mM1mk8nk5OT=3D
>>=A0>>kzMxMGo2Wn5+vqqqqqqp69OjRK1euwDRpUA338PDQ1tY2NjbW09MzMDAoKSkRCAR= >>xcXGnTp06e/=3D
>>=A0>>ZsQUFB25+qXXwViILhORyOvr6+lJTU5MmTPT09PzvOGvpj7e3tLSwsoJe89ygDuM= >>sK6q+HDh0KD=3D
>>=A0>>Q1F+ivcFj916tTZs2fDX7879AFC5MCorKzU19fX0dFJTEyMiIhQV1eXl5dPTU1FN= >>n+ipS8ARpgb=3D
>>=A0>>GxtDKiO9ENpx6+vrmUwmjUarr69HFaoaGhqoVCpuq2tL7ykUioODQ2ZmJvEpASkU= >>rR3T0tLWrVs=3D
>>=A0>>3YMCAzZs3wx2wnwf4LGlpaWlpaTDfW+/hq9hjslistLS08vJyJEcBANHR0X/88ce= >>cOXPy8/NB+7=3D
>>=A0>>fWvRdtWm8BAEpLS83MzPbu3WtjY3Ps2LFVq1adO3eurKwMnibAAACA22NUVVWtrK= >>xgeDnAInRa+=3D
>>=A0>>7eIllxvV+9by9cPnQxbp9Pp9vb2EyZMGDx48JkzZ+BW9ba3KAakreJZaj77bj0Ii= >>HnIRABaBmEB=3D
>>=A0>>AKKiombNmgVdsk1NTURn2E/atN4iCILP5zOZzJiYGFdXV0dHx5CQkLq6OhirCi2a= >>eF43JpMZHR3=3D
>>=A0>>t4eGRlJQEs6ARHXZsfKj3FArF0tIyMjIS7U340Mnwq8zMTFVV1QEDBvz666+PHj3= >>qeE0I3KDbe0=3D
>>=A0>>IK0ZPCX5xOp+fn5+PuSQDAy5cv//rrr4EDBx47dgzmzu8OvsJshELRShA63JAsFL= >>bcgIDEjFi8N=3D
>>=A0>>tF5EWViva+rqzM0NHz06BGTySQ+FT8gEAiePn06b948KSmpAwcOwPmrIx1obm7Oz= >>s7OyMhAtXt6=3D
>>=A0>>iT6Au3UgNXV0dF68eIFOAABkZWWpqqoOHjx4165dkGEdH5xP8BXJTpQODUl+ARZV= >>KBZUhb5CJgx=3D
>>=A0>>0Zqfztb6+3sbG5sWLFyjn3IdaAQCQyeTz58+PGTNm3rx5T58+hZsKO9I6k8m8ffv= >>2jRs3YBR9Lz=3D
>>=A0>>FmEe+zv65cuRLu4EcH6XS6iYnJhAkTUO2NLpevAixaSiDasgP7hL7iYxXSCMzMgV= >>/VRTucAAA0G=3D
>>=A0>>u3ff/8tLCwEn/L4CQSCly9fbtiwYdmyZTdu3KDT6UTHxCG0D1y/fh3erfc4C4iW+= >>bMgh9TV1Z8/=3D
>>=A0>>f05gOj2Xy/X29paVld26dWtsbKyYM/zz8Gl9AP1FIpbAdpwJMRCYvoueB2f5Z/dS= >>rEu4Uk+lUt3=3D
>>=A0>>c3PLy8sS+xf8lRLZ9ExMTaWnpLVu2wP1eRGfw1dnZ2d7eHu0m7w36q5jZHwAQHBy= >>8YcOGkJAQfN=3D
>>=A0>>XF4XCcnZ0nT548Y8aMW7duIbthR5r+tD0LoTUPWreNE1eMyp0CIWb5g8woKSm5ev= >>VqXFwc8k7hL=3D
>>=A0>>eLr95SUlG3bto0aNUpLS6u0tLTjHQMAsNnsp0+fPnnyBO5aFnbYP94jILYygfbXK= >>1euoOyZEDAl=3D
>>=A0>>irS09NixY52dnWG90u7j69cA/H0gCILP58fHxx85cuTBgwcwYlpM2BMi3Z9KpcJ8= >>y/PmzXv48GF=3D
>>=A0>>nVULk8/kUCoVCoaBInd7AVwghpn2h+FchVhagubk5NjZ2yZIl48aNc3Bw6JRysj2= >>MrxA4KfPy8g=3D
>>=A0>>wMDGAuQZx8cLzgZ+i/kJWVHThwoJ6eHtT9O0v2wwUoztdOnE++ciCpIRAIeDwejM= >>nE9dq6ujo1N=3D
>>=A0>>bXRo0efOHGisrKy4y32VL4SIsFJJpMdHByys7OJljxGNjWCIPh8/oMHDyZOnDh16= >>tTg4GBc+nYE=3D
>>=A0>>kKbV1dU1NTW9KnIAAtfKKBRKcHAw2lWP7Fx0On3Pnj39+/dfuXIlDNrsXfoABM5X= >>6C+Iiop6r00=3D
>>=A0>>NDlxVVdXRo0eHDBkiLy8PLQm4oeOzuwEAYLFYjx8/fvToUUNDQ+9RBvB1AvRoxsb= >>G7tq1C8a/El=3D
>>=A0>>heAjabbWZmNmLEiPnz579+/ZrozvXW1wO0DId8NTc3h3nwCGw4EHW4XC7MDD5ixA= >>hdXV1kKBWzD=3D
>>=A0>>X8GAAAMBsPa2trU1BRu7u0lIha3XRKieMKlS5cGBASIeWUJgoiIiJg0aZKMjEx8f= >>HzHm+6pfEUa=3D
>>=A0>>Un19vbOzs1i8CxKxAICqqqrTp0+PHDly3rx50JHdWaxCfDUxMYHxWb1HeUUrKkLk= >>L0D1twjMmgk=3D
>>=A0>>ASEtLmzp16ty5cyMjIztFB+t5fEVAfE1PTyfel6SDIIhnz54tWLBg0KBB2trasNQ= >>H0UleU2jTdX=3D
>>=A0>>R0tLS0pFAonXXbngI0yACAuLi43bt34/oA+grydfz48d7e3qjM4Gejx/MVxhNmZG= >>TAI4gxQtGO7=3D
>>=A0>>VOnTg0bNmz27NkwqUfnts7hcKKiogICAhgMhrAz8vH2FIipBDQaLTw8HNYvwL8FA= >>OTl5S1atOj7=3D
>>=A0>>7793cXHpFB2sZ/MV2gfevHkjJlYJghAKhc+ePfvzzz8HDBiACh51bgeEQmFDQ0N1= >>dTWMDus9fEV=3D
>>=A0>>PilaZKFgPX3dCk5auru748eOdnJw67uns8XylUCjOzs5v3ryBRxBfoTEF5saaMmW= >>Kh4cH2lUsdu=3D
>>=A0>>ZnAxIU2l9x/3Pv0QrQwpfH4zGZTBTSKcQMOFwu18XFZcyYMZqamu/eveuN9gEEyF= >>cbG5vo6GjcH=3D
>>=A0>>wu/yszMVFJSGjhwoKKiYnx8PD5/EZ0ULMbn8+l0Oira2PF4jh4BNJLISpOfn+/h4= >>YHKleF8hbmg=3D
>>=A0>>paWllyxZggIOPxs9nq9kMtnIyAi6WHGiAAACAwOnTp06fPhwWD2mc5lKiOyL/v7+= >>Pj4+DAaD6DX=3D
>>=A0>>rLTiAaD6B8S5KSkoo3oXAEvYLBIKkpCQlJaX58+cHBQVJ5CvFwsIiPDwcr+UJAGh= >>ubnZ2dh41at=3D
>>=A0>>ScOXP8/f3x3QedyFe4n/vatWsoK29vAL5UgEt+X1/fRYsWQfsrPI6iKwEA1dXVR4= >>4cmTBhgr29P=3D
>>=A0>>dTKPrvpHs9XMpl87dq1gIAAVLxUKNogqaGhMXTo0CNHjsB9Zp2uWUK+WlpampmZi= >>WWR7sRWvlrg=3D
>>=A0>>Xhs/P7/Fixej/K+4HQBaaWC6fVhGvVfzlUKhXLly5fHjxyjkiiAIDofj5eU1efLk= >>uXPnBgQEwBx=3D
>>=A0>>Ena5ZQr6amZmZmJhA/xbRO/iKNAHE17CwsK1bt4aHh+NOPiSD2Ww2LMSnoqKSl5f= >>X2/lqZ2eXkp=3D
>>=A0>>IiwGqVZGVlqampjR079vTp06isZlfIVxaL9ejRo//++49Op/ce/xYe/wopW1paGh= >>QUBEv44qchL=3D
>>=A0>>TYmJuavv/6aMWNGQECAQFSm5TPwLfDVwcEB5teGXGlsbLSzs5swYcLMmTMfP34M9= >>drO3eOA0Nzc=3D
>>=A0>>XF1dXVVVhSqN9Qa+Eti+TqSqouNESwMClCCJiYlLliwZNmzYzZs3O+Ll6vF8Fcs/= >>QBBEYWHhpk2=3D
>>=A0>>bSCSSnJxcamoqHDJYo7lzW0erY9BrdsYiIOEqEO3Pa2xshElDiJZRR3CIcnJylJS= >>UhgwZYm5uDi=3D
>>=A0>>PrPw89nq9kMtnR0RH6twiC4PP5fn5+v/32m5SU1KlTp2DRZBiZ0fbCL21vHdYzKi= >>wshPkgehVlC=3D
>>=A0>>azoX2Vlpbu7e0ZGRmvBCflaXV29d+/efv36KSsrFxUV9V75ivMVqgcnT54cNmzYr= >>7/+GhAQgKbp=3D
>>=A0>>rvCUAgCYTObdu3fv3LkD09j0Hn0Af1IAQFRUlKqq6tOnTwG2iU0o2m1KEERjY6OD= >>g8PPP//8+++=3D
>>=A0>>/p6WlASwjebsGrcfztb6+3snJCcYTCgSCoKCgP/74Y/DgwVpaWrDCPNKxOp1JQFQ= >>fBsW/9h6+ov=3D
>>=A0>>UWQRAAAB8fH1Sfm8D0VzS5NTc3v3jxYuHChb/88gtaVCBC9yK+UigUR0dHmLGxqq= >>rq+PHjQ4cOn=3D
>>=A0>>TJlipeXF26R7QomAVE+zatXr9bU1IBeE68NgVtYnzx5snTpUhT/iiAUBSILBIKsr= >>CwVFZXhw4fv=3D
>>=A0>>3LkzLy9P2BJtbPQb4SuMd3n+/PmSJUsGDRq0c+fOrKwsfCC6gklQH7h586aLiwuK= >>1+4l8VlES75=3D
>>=A0>>mZmaeOnUqIiJCbOkpEO1KIgiCxWJZWFiMHDly3Lhx3t7eKLlOu4IMezxfyWSyiYn= >>Js2fPampqrK=3D
>>=A0>>2tf/755x9//NHNzQ2GEyBLYRe1zuPx0tPT09PTYVq79kqLHgrcIwCPsFiszMzMio= >>oKdAIesMYXl=3D
>>=A0>>W8PCgqaNWvWwIEDT58+DSPc2xsR2+P5WldXp6WlZWxsHB0draamNnToUHV19ZycH= >>CHmgCG6LPOK=3D
>>=A0>>QCBABfTEAsS+YaBnxNdVsJg8OgcZvJE+RhBEeXn55s2bSSSSvLx8SkrKZwiUHslX= >>fGVKJpP3799=3D
>>=A0>>/4MABV1fX33//ffjw4Tdv3oRGFqJVvpmu6Ay0v+ISpe0NfbxvYgfxf9vbShcNArw= >>hXPVmZWWhzP=3D
>>=A0>>oENtXANFaQtWw229DQEC4w7t27B/fSEe2xA/ZgvgpFGRk0NTW3bt26Z8+eUaNGzZ= >>07NyIiAj+zq=3D
>>=A0>>6Udg8GoqKiA2li75CuSLmJpyHDlDz+Cz5sfmi7wS/ALkR6Jv1RiN/mMFwC5r169e= >>qWrq/vq1St8=3D
>>=A0>>0dm6IT6fHxYWNnXq1AEDBujo6MCUe7ipEX+13vuAPYyv+C8BDdG1tbX79u1bvnz5= >>33//PXz4cE1=3D
>>=A0>>NzZKSku4J7QMANDU1BQQEeHt7w/gBYTsNEciRgTMJ/bpiv5ywFd57Q6ii4LVuxD4= >>IW2aVxNtte7=3D
>>=A0>>eFmD4ARPu5UX0YnH/4BwBAYWHh6tWrSSTSqlWroJUAt2fhz/XeB+x5fIV6kkC0mZ= >>hMJqurq48YM=3D
>>=A0>>WLkyJHLly+HgbDd0xkg2s9tZmYGazC1V0VGv5ZYepgPfUZHAAaxr+AH/LX5yEE4n= >>iiZUtu7jfcN=3D
>>=A0>>AODv7//PP/8EBgai/iCCor/wTFgjaMaMGWPGjLGwsGAwGOgcsWvfi57HV3z2hPrA= >>9u3bSSTSDz/=3D
>>=A0>>8YGpqCp+/28BkMm1tbc3NzeEIEi0LMfQeBAUFycnJQb5+EmQyWVNTc9CgQUuXLoU= >>qRLvw8uXLHs=3D
>>=A0>>NXCNwIQiaTIV+nTJly9+7dju9wbzsAAI2NjVC+ovjX9oLL5RYWFiYlJcXHx8fHxy= >>cmJiaJkJiYm=3D
>>=A0>>JqaWlBQkJWVlZycnJWVlZ6enpSUlJCQkNgS6JLU1NTk5OTExMS4uLjExMTk5OSMj= >>IzCwsLMzEx4=3D
>>=A0>>YVJSUnZ2dnl5eW5uLjwzJycnPz8/NTUVv88ngfc2JSXF0tJyzpw55ubm8D4JCQnJ= >>ycnwEeLj49G=3D
>>=A0>>/SUlJycnJr1+/Pnv27E8//TR48GA9Pb3k5OT09PSUlBR4/se7kZWVdfPmTVglpWf= >>wVYiZSAAAVV=3D
>>=A0>>VVKioqJBJpzJgxhw4dcnR0dHBwcHR0hB+6FE5OTlZWVmvWrFm7dq25uTk82PZ2nZ= >>ycnJ2dr127t=3D
>>=A0>>mfPHkVFxVWrVikqKioqKq5Zs0ZBQUFBQUFRUVFFReXw4cM7duxYt26durq6srIy/= >>HbNmjWKiooK=3D
>>=A0>>CgqrV6+GV61evVpeXn7p0qXLly+Hd1u1atXKlStVVFS0tbXXrVu3cuXKNWvWyMrK= >>ysrK7ty5U0l=3D
>>=A0>>JCV4FS1KuXbsW3q2NWLVqFfwA+zl//vxx48bJyMigzsAHaX0mbGXZsmVjxozp27f= >>v1KlTly1btm=3D
>>=A0>>jRIjk5uTVr1sCng5e/tz9r165dsmRJbW1tj+Er0bJ8UkBAwOzZs6E+8Ndffy1atG= >>jhwoULFy5c1=3D
>>=A0>>C2QkZGZNWvWrFmzZGRk2tv0woULZWRkVqxYoaura21tbWdnZ2tra21tbWNjY2lpC= >>cvS2tvb37x5=3D
>>=A0>>09nZ2cbGxtnZ2VYEGxsba2treI6tra2VlZWVlZWxsfHq1asPHjxoY2Njb29/5cqV= >>3bt3nz171t7=3D
>>=A0>>e/tChQ/r6+lZWVvv37//111+nT58uJyd3+fJl+ILt379fT0/Pus1AraPPDg4O169= >>ft7e3t7GxQd=3D
>>=A0>>2DH+ARKysrS0tLGxEcHR01NTVHjBhBIpFIJNJPP/109OhRS0tLOzs7eE+8CRzOzs= >>4nTpzoefIV6=3D
>>=A0>>gPNzc0BAQE7d+7cuHHjjRs3YmNjExIS4uPjX79+ndAtgHMimvXgLNn2a+Pi4tLS0= >>mpqajgcDsyf=3D
>>=A0>>yuFwmpqampqauFwul8ttwoD+hR/QmfAzh8NhMplFRUW1tbXwYGNjY1VVFZlMZjAY= >>tbW1dDqdzWb=3D
>>=A0>>X1NSkp6cnJCTk5OQwGIzm5mYWi1VeXk6hUFCjnwTeLjxCJpPj4+OLiorQU7z3QdA= >>HWFfn6NGjI0=3D
>>=A0>>eOJJFIR48eLS4uRnf7SE8AAOHh4T1Gf0XmGPgBhglXVVUVFxfznEmINwAAIABJRE= >>FUeLz2au4Sd=3D
>>=A0>>Baio6PV1dXR/i2ibevOyspKY2PjrVu3+vr6Qi62Bc+fP+8xfIVA9kKUHw8Ckbjtp= >>plvD8h4gm9T=3D
>>=A0>>+cjJn9cK0seIlvZXolU1jvcCVXFjsVgNDQ1tL8IKepw9C5EVl7WgZVo8CWXFfAEf= >>OfPzmkDFiQh=3D
>>=A0>>R/CuqJ0+08syJtQhfJGhHR7IGP+EbtL8KROnexegLgeou9TagVxfX8j/uxfgQsT4= >>OfMAhXxcvXu=3D
>>=A0>>zv70+0DM56b3PNzc0wcgCRvu1blXoYXwUta9YJMRe8QBTH/nk/wJeC8MPOqs8AvA= >>kUXWjLmvCjH=3D
>>=A0>>k78PW9jK2Ief4IgYmJidHV1X79+DbDUdx+6oVAUBMPlcj9Z9bf1A/YkviLnFj4ir= >>eXrl+5m+0Cl=3D
>>=A0>>UhMTE1+9egVTJYh9iz8R/q3YmVB9Ly0tDQsLe/78OdyDKibnPq4YtH3c8JGHrTCZ= >>zPr6erw+DNJ=3D
>>=A0>>uP3QHsZ+yjU33ML6KjVSPBppM8/LyDh48qKam9vr1a/hcKAgGSkr0sIgKeIFp9Ks= >>LBILw8HB5ef=3D
>>=A0>>mTJ0/C0KdP6q8d6Tn6AJtgsVgcDgcP1umK36iH8fVbglCkWTY0NJiamhoZGZWWls= >>L5FNEUupdx6=3D
>>=A0>>wcitFCU1g4xEgBQXV2tpqamra1NpVKFog3uXfRuo7cFWqbu3LmTlJSEvu2i1M0Sv= >>n5JQCaxWCwr=3D
>>=A0>>KytTU9OamhoCi8yHOmhjYyOVSqXT6TDEls/ns9lsFovFZDJhfgoo0rhcLpPJLCgo= >>2Lp164kTJ7q=3D
>>=A0>>6ni3+8gAAwsLC1qxZA/cbtkUf+GxI+PolAX9aBoNhZWV19epVWAEQ/dIMBuPevXs= >>XLlwwMzMzMD=3D
>>=A0>>AIDw9vbGyMj4+3sLDw8/O7c+eOl5cXTAiSmZl5+vRpTU3NgwcPzpw5U0dHp6v3P+= >>KrBWgfWLhwI=3D
>>=A0>>dzPjexcXaESSPj6xSAUpZNvbGy0tbU1MzOD+/XQJJuUlLRmzZpz5869ePFix44de= >>/fuTU5Ovnjx=3D
>>=A0>>4vbt29PT02/evKmkpOTj48NkMp2dnaWlpffv329lZTV//nwdHR24NaWL9Ff8EYSi= >>+Ndly5ZBvgp=3D
>>=A0>>F9kQJX78p8Pl86IRksVi2trampqZQvkKJm56efvr06Xnz5nl7e7NYLG1t7fnz5wc= >>HBxsZGamoqE=3D
>>=A0>>RHR1+/fn369OmXLl3Kz8/X0tJasGBBcHBwaWnpzp07T548CePHu8dgAgDw8/Nbun= >>Spj48P7i/oo=3D
>>=A0>>rYkfP0yQMKJzWbb2NiYmJhUV1cDAPh8flBQ0J49e/7444/Zs2c/ePCATqcfOXJkx= >>owZT548MTMz=3D
>>=A0>>k5OTu379uqmp6fTp0y9evBgXF7dhw4Z169a9efOmvr5+586durq6MD9SF5FVTM0A= >>AMTHx+vr60P=3D
>>=A0>>7a6c3h0PC1y8MAEBDQ4OJicnFixdhHvD8/Pzdu3fPnTt327Ztc+fOtbKyKikp2bd= >>v39KlS93d3V=3D
>>=A0>>VUVBQUFBITEz09PadOnXrmzJn8/PwLFy789ddfd+7cyc7OhiGzVVVVXae84neG70= >>NjY2NJSQksQ=3D
>>=A0>>obOkdizvjVA+VpQUHD06FF1dfWUlJT6+npLS8spU6aoqKj4+flt2bJFXV3d2Nh4x= >>YoVOjo6L168=3D
>>=A0>>OHv27D///GNkZKSrqztjxoz169cnJibGxMQoKirKyMgcOHBg/vz5CgoK4eHh0Bra= >>RXYl3PIqxPI=3D
>>=A0>>PIA2kO+wDfd6HTm9SAghkXq2vr3/48KGnp2d5eXl9ff2dO3e0tbWfPXtGp9NDQkI= >>MDQ1PnTp16d=3D
>>=A0>>KlxMRELpf77t07MzMzfX19R0dHGKP95s2b2traW7duHT9+3MrK6sqVKwYGBtHR0T= >>DFJzTQdkXnh=3D
>>=A0>>VhcUUFBwePHj/Pz8wnRpt/OUkXE2AhzbUj4+gWA1tEAABikDM2odDqdQqHweDzoY= >>a+tra2oqKBS=3D
>>=A0>>qTCaSSgU0mi0qqoqOp1Op9PJZDK8lkKh1NXVsVgseJDNZnedkEP9R/bXoKCgDRs2= >>oHya7d1w+xF=3D
>>=A0>>I+Pq1QCjaSy0QRZESouy+yIopFgoDhaXYQch7olWINNGVzi0CMz5A++uCBQtQ/gF= >>0QsdbkfD1Kw=3D
>>=A0>>JymcJ4Jdwz9N44Sfy01t+icz4ZIdVZnUdvmpj9tROFuoSvXxFwPuErlfeeib7CqY= >>lIibOzS9UAv=3D
>>=A0>>Ank2ggICFi9ejXiK3pnOt6QhK8SdALwqQAAkJ6ebmtrCxO9o/VWp2gjEr5K0FEg2= >>yqiI4fDoVKp=3D
>>=A0>>MP4VSfpOMcF+jK8dvLUEvQRiyjHSYtFKkRCF8HZ60xJ/gQSfCaRDQxNyenp6cXEx= >>i8VCIS+SeEI=3D
>>=A0>>Jvi4ge1ZcXNy+fft27dp1+/btyspKtC7s9BYlfO0okLGztwH3Fzx58mTatGl9+vR= >>ZsGBBWFgYtA=3D
>>=A0>>dL5OvXiC4NMP1qgUfWQvvrtGnTSCTSL7/88vDhQ8hXiXz9ugD9qG/fvoXBUF+6O9= >>0HZMlC+TJCQ=3D
>>=A0>>0Pnzp1LIpEmTpzo4+MD4yIkfP26AABgMBghISFpaWmofsGX7lR3ANkHUPzDu3fvd= >>uzY0adPn8mT=3D
>>=A0>>J/v5+cFcZl3RtISvnw8AAI/HKyoqqqur69JNzF8hcJcvAKCmpkZTU1NKSkpOTu7V= >>q1ddl19Hwtf=3D
>>=A0>>PB/q1AJZ4v5fwFZUogiMQGxsrKys7ZMgQLS2tqqoqQpJ/4OsEj8erq6trbGwUiz7= >>50v3qcuCbzq=3D
>>=A0>>F9YPr06YMHDz579iyNRgMti591IiR8/XwAAJhMZkBAQGJiIp58rpfwFZevT58+nT= >>lz5uDBg8+fP=3D
>>=A0>>0+n04XtzDLUdkj4+vmAW6/s7e3v3LkDRWzX/U5fG/DwK8TXIUOGGBoaSvj6lQIAQ= >>KfTr127Zm5u=3D
>>=A0>>Dqv39gamEq1S0AEA/Pz8Jk2a9PPPP9+8eRO6ZCX5Xb46QH3Az88vODiYwWD0Hv21= >>NV8fPHjwxx9=3D
>>=A0>>/KCoqxsXFEVjGyE5vWsLXDkEgENDpdCaTiZjaS/QBAqtgyOFwrKyspk+fvmfPnqy= >>sLCaTibK6St=3D
>>=A0>>ZbXx2gPQt6enoJWXEuAgBycnKUlZW/++67M2fO+Pr63r17l0wmE12ze0zC1w5BIC= >>ouLLaV6kv3q=3D
>>=A0>>2uBnhEas8LCwqZNm/bjjz96enqamppu3LixoKCAkMS7tAXdSRcAAJvNTk5OfvfuH= >>ZKvvUTEEqLc=3D
>>=A0>>/ACAR48ejR07Vlpa2tfX9/Lly3Jycm/fvhV26q5DhB7JV1xZJDCO4kb7bugGtGe5= >>u7u/fPkSesz=3D
>>=A0>>bVTqi5wKOMHxSFotlb28/cuRIaWnpR48eGRkZrVixAibOkKy3WjASbm4mWm4nQvN= >>UN1AW2rOuX7=3D
>>=A0>>8eGRmJitj3Bn0A3xmbl5e3bdu2fv36/fDDD/fv3zczM1u9enVubq4k3oUgsJwo+H= >>QDVzzdyVTUL=3D
>>=A0>>p1Ov3XrVlRUlFj2qO7pwJeCUJTpo7m52cfH5/fffyeRSGPHjvX393/69Km+vn5ZW= >>ZkknpAg3qcJ=3D
>>=A0>>CESFuPAcON2mD7BYrIiIiMzMzK7bAfIVQijaq81gMK5cuTJq1KixY8cqKyunpKRQ= >>qdT09HQ2m01=3D
>>=A0>>I9AGiZVo8+C+LxUpKSqqtrSVaBrl1T3/4fD6ZTIbOWKJ3KAMERsSsrCwlJaU+ffq= >>sWrXqxYsXcB=3D
>>=A0>>xQupquaLoH8xXqT+np6RcvXoyPj4dk7f7Khkgb6SXKAIHtLwgODp44cWLfvn21tL= >>TIZDKPx8vLy=3D
>>=A0>>4uLi0PRFJ3edA/jKwSuEnh4eCgoKHh4eMBkud3MG6FQSKPRYDJAdKQb2v0iwB9NK= >>BRyuVxvb++x=3D
>>=A0>>Y8dOmzbt2rVrd+/ezcrKunnzpqamZklJCTIgdC56Hl+FWHlYFot14cKF8ePHHzx4= >>ENqou5OvAIC=3D
>>=A0>>6uroHDx6kpaXh8cvfGGXRE+HPBQB4+/bt9u3bBw8erKGh4eLismnTJj8/v8uXL0N= >>7loSvBCHSUJ=3D
>>=A0>>Fu9ObNG2Vl5QEDBvz555+hoaE8Ho/osgy9rQEAKCgoMDQ0DA4O5nK532r8K66DwT= >>BtaGm+devWj=3D
>>=A0>>z/+OGbMGCcnp3v37q1YseLff/81MjJavnx5Xl6exJ5FEAQhEOUdJwhCKBSGh4fLy= >>MiQSKTx48ff=3D
>>=A0>>vXuXxWIRXZz0FAcAoLi42MjIKCQkpKmpCYhKpXVD090GFBYoEIEgCABARkbGhg0b= >>hg4dun79+jd=3D
>>=A0>>v3jx58mTFihX379+/dOmSnJycxF/w/0DLT4Ig2Gz2rVu34Lb3UaNGGRsbw+Jp3dY= >>ZAEBhYeGFCx=3D
>>=A0>>dCQkK+1XgXXBlAH6hUqpWV1Q8//CAtLe3s7MzlcgMDA+Xl5X19fe/fv3/mzBlYOE= >>Tij23hWamtr=3D
>>=A0>>T1+/PjAgQNJJBKJRFq/fn1ubi7RLdlPIQAAZDI5ODg4Jyen6yr6fXEgPQdKCgBAQ= >>kLCypUrpaSk=3D
>>=A0>>1q5dm5qaShBEVlaWi4tLZmZmZWVldnY2i8WS2AcIQrTYgpSNj49XV1cfO3aslJTU= >>qFGjFBQUYmJ=3D
>>=A0>>i0Ca47uwPDNEiuvFV6U6grVrIR2BnZzdmzJjvv//+xo0bHA6HIAgOh9PQ0MDlcqE= >>oEUryvUGgKY=3D
>>=A0>>nH4wUGBpqamqqrq8+aNUtfX//u3buZmZkoBWm3dQnfC/pNrrfQVliCIHg8np+f38= >>KFCwcPHqysr=3D
>>=A0>>AzXVTDPTV1dHYfDgf923Xvbw/gKAflaVFSUl5dna2u7efPmhIQEFovFZrO7OTyKx= >>+Pl5uZWVFTg=3D
>>=A0>>xqxvjK+QfJCFMTExmzZtGjx48D///BMaGgrriTY3Nz99+vT8+fPp6enQdNB1cZU9= >>jK9CrBwFHJH=3D
>>=A0>>Xr18bGBhkZmZ2f2cAADQazc3NLTo6GprSvj2yQkC+VldXHzhwYMiQIdLS0o6OjtB= >>BIxAI4uPjV6=3D
>>=A0>>1a9csvv8B6RnAzTBeFVvY8vkJJhoKFKRSKg4NDWloaOqHbOgMAyM3NPX36dEBAAC= >>zO9u2RFeqjz=3D
>>=A0>>c3NaWlpFhYWv/zyC4lEWrVqFRSlTU1NCQkJ2trakydPnjx5Ml7PSLLe+n8gyQpf+= >>vr6ekdHx4yM=3D
>>=A0>>DAKrsNM9zi2CIEJDQ9euXfvvv//CfG/fnj2LIAi4tN2zZ88vv/zSv3//OXPmuLm5= >>0el0AACVSrW=3D
>>=A0>>3t9fS0jp27JiMjIyfnx/o4tRMPYyveIwpFLSvX78+d+5cRkZGFzlUPgTEVzk5OS8= >>vLyjsvzH7AB=3D
>>=A0>>SuLBbrzJkzgwYNIpFI8+fP9/Lygn4ZgiAaGxvDw8MTExMDAgKUlZVDQkLwQGSJfU= >>A8bROfz7ezs=3D
>>=A0>>9u8eXNqaipap3ebkIP+WCsrq9jYWBRF/s2osJCsVCrV399/8eLFffr0mT9/PowrY= >>rPZ5eXljY2N=3D
>>=A0>>cLslQRAlJSUBAQHFxcVidpJOH4oexldcf4V/79y5s2vXruTkZKQ2deekDO04DAYD= >>r/DbQ/mKqAZ=3D
>>=A0>>lAY/HKykpcXFxmT9//pgxY5SUlAICAmBuAR8fn+vXrxcXFyP3LL4ORp8lfCUIUfl= >>ntPzMycm5ev=3D
>>=A0>>Uq1F8Ruocx8IdpamqCpYp7omTFZSGKJYKTWFJS0pEjR6ZOndq3b18lJaWXL182Nz= >>ez2ewHDx4oK=3D
>>=A0>>yubmprW1taiBQOXy83Ozq6qqhJiVRcl+uv/dmZC+4BAICgpKbGwsHjz5g0Kmu62z= >>sAFcmxsbG5u=3D
>>=A0>>bg/NTyhsuVkDrVaTkpLU1dWHDBlCIpHmzJnj5+cHU7y/fv1648aN6urqr1+/hio7= >>VBtSU1NPnDg=3D
>>=A0>>RFhYGRPW3UB3nzkUP4yt6d9GghIaG6ujopKenE93uDoX66/nz54ODg1GFiZ7CV7y= >>fuOYNAEhJSV=3D
>>=A0>>FVVR06dKiUlNTff//t7e2NqmqlpaXdu3fv7du3eEUNAIC/v/8///zj6+srsQ+IA+= >>eEQCB49OjRw=3D
>>=A0>>YMHYeXS7tQgYXPBwcHLly+/d+8eFDY9KP8APoxC0foVAFBaWnr06NGBAwdKSUlt3= >>rw5ICAAkhU+=3D
>>=A0>>XVNTE/RpEdhaAgDg5+e3ePHiwMBAFFQp7Joojh7GV6FQCONfkXy1tLRUUVHB7QNE= >>N654EhISNDQ=3D
>>=A0>>0Hj16BOVND+IrBD5QAICamhpDQ8MffviBRCItWLAgJCQEkjI+Ph7uyoKnNTc3oxR= >>M8EX19fVdvH=3D
>>=A0>>gx9BfgwVyd3uEexlektsKx4PP55ubmmzZtSk5O/iL6K5lMdnJyioyMhPvxe5D+ii= >>YoociDlZ6er=3D
>>=A0>>q2tPXbs2EGDBh06dCgiIgJarAICArZu3ers7Az5ihZk6HmhCmFiYgKdXvD+EvsrQ= >>WDiE9lfLSws=3D
>>=A0>>lJWVxeRr9wDGJcF4l6/Z/ooGDU3TQpFDWyiqF5KUlKSmpgadAjCSGJq0YCD2sWPH= >>8DUlui1Sedl=3D
>>=A0>>sdnV1NYwt7NIR6GF8hUDDJBAILCwsNm3aBPXXL9UZXLJ+bWT9v/a+PK6pY30fq63= >>cVmurfuu9t/=3D
>>=A0>>15tXVptdd6XaoioCJL0SKiVVC0iqCgKCCguOCO4IKgbLKDgEAgIEvY17DKosi+72= >>uAJBBCICTnn=3D
>>=A0>>N8fczN3CEgRCcbW5w8+h+TkzHKeeeedd973HRwxqqBBkdDOShBETk6OmpratGnT5= >>s2bp6amFhoa=3D
>>=A0>>CjwDi4qK9uzZs3fvXhAuP6pKCt8FgKjH7Qe+vhXge+LxeKhiLVbAEJsoTwBgn+Jw= >>OCkpKaqqqjN=3D
>>=A0>>mzPi///u/S5cu1dbWwlML6+vrXVxcMjIyoPaFxsahjOzp6amvr4d5Q0QXQveBr2+= >>FlpaWhISEur=3D
>>=A0>>o6IFfEkK/Y8N1RVLL29/f7+PjIyspOnz59/vz5V65cqaurgyMQ3An8JHEk3hCVoP= >>BRmZmZxsbGq=3D
>>=A0>>ampuIhD6j/wdYIAbzQuLk5NTS0oKAhYecTQPoAJQlMgcBwnCILFYnl6eq5evVpCQ= >>mLu3LmXL19u=3D
>>=A0>>aWmBjXJzc2tqakK5CwLWgWBGVSBoH9i8efOzZ8+gSvDBPvA/iA9fw8PDN23a5OPj= >>A0KXxFC+4gI=3D
>>=A0>>RC9lDEERTU9OtW7dAaPH333//6NEjGo0GqBYeHi4nJ3fu3Lm2tjYoZdG/I6U14Ov= >>GjRsBXz/Ys4=3D
>>=A0>>QhPnyNjIyUkZHx9fUVaRDIBACnY/QCjKX6+noTE5Mvv/xy5syZK1assLOzA6srLp= >>dLoVDU1NQuX=3D
>>=A0>>bpUX1+P5nnAkWUl6iIHNd2IiAh5efnw8HDwFkTXDx/4+lYoLi6+cOFCbGws1F/fO= >>V9RzRJew7ws=3D
>>=A0>>TU1N5ubm8+fPl5CQUFFRSU5OZrFYYNLv6ekJCQkJDAyk0+lAtxFKngfpixYBHlta= >>Wuru7l5eXo7=3D
>>=A0>>eIIrWfeDrW2FgYKC6urqzsxM9cmPqq4ECruIxxOUKWAP6+vqcnZ2XLVsmISGxYME= >>CFxcXDDFF8X=3D
>>=A0>>g8FosFFHFMsI84anOw4V5dQEXmcDhcLhdufYlotvnA17cFeNl8UToljR/YcADSgF= >>mbwWB4eXn9+=3D
>>=A0>>OOPEhISX3/9tbm5eUNDA0EQbDabQqGQSKSenh7Qh+OJ9UXVWbjvANVWlMqT28APf= >>J04QAWYTKaQ=3D
>>=A0>>iecdilgMMY7iSEcxGAwnJ6dly5ZNmzZt0aJFt2/f7ujoAPVPTEyUk5PT1taG9gHI= >>udeNPf4IF8T=3D
>>=A0>>Ozs78/Hxw7JZI9fgPfH0r5OTkmJubp6WlwbXwO1dh4ciBcq66uvratWvffvvtZ59= >>9pq6uTiaTOz=3D
>>=A0>>s7gXoQEhJy6NAhMzOz7OxsDoeDrqWghjOyCP7wzTyCIOLj4w8dOpSSkgJeyof9gm= >>EQB74CUQT86=3D
>>=A0>>Dw9PeEO0Lslq9AETRBEdXX12bNn586dO3PmTE1NTdBRADU1NWfOnDl9+nRNTQ36c= >>yG6jyxFSOuA=3D
>>=A0>>9qyQkBD8na+3RqoykBmg2eidQj8Z4/O3aY/48DUyMhLExwL7q0hf1euAdilc/YDr= >>0tJSQ0PDuXP=3D
>>=A0>>nfvLJJ+rq6s+fP4c8xnGcTqcnJiYWFRUJ1RxdS41RLrr7EBISIi0tDfMPvDN9ANY= >>b1h6sImHGYL=3D
>>=A0>>jUgHei5mWUmkLdAY0sE6i0+PA1IiIC+Gu/E/8soXkZ9j+O4zweLzk5ec+ePbNmzZ= >>o5c6aGhkZ+f=3D
>>=A0>>j7Yi+JwOO3t7TCFINzBGilWxmgISkqCIGJiYpSUlID9VYgwk4s/4CtsPyi+paUlK= >>SmJTCbX1tbW=3D
>>=A0>>1NRkZ2e/fPmyu7sbVp2PnHgh1GzgEYJ+CGwfE3i74sBXgMzMTCMjo/j4+PEIpEmH= >>kJEVigAOh5O=3D
>>=A0>>WlqaioiIhITFr1qxDhw7l5uaCHuvr6wsNDbWwsCgtLQVGLgLJVzf+ooUIXVNTY2N= >>jk5OTI2pTyb=3D
>>=A0>>jkK7xOT08/duzYrVu3qqqq0tPTTUxMNDQ0qFQqutpA5Ss+fLUI7HNo2ROTRuLDVw= >>aDUVZWBtfFU=3D
>>=A0>>ylfoSgBgOVyOJykpCQ1NbWZM2dKSkoePny4oKAAfMVisaKjo3fv3n3s2LHy8nIhP= >>k2ArzxB1tuh=3D
>>=A0>>oaHOzs6+vj58uDox6V0xLv0Vqin5+fmHDx/29/cfGhrq6uq6cePG0qVLPT094UhF= >>xzr4CYfDAX7=3D
>>=A0>>pOI4DssIxPXImGifEh69w7YLGG05N0egOMCyUTqeHhoaCYzBmzZp18OBB4A1IEAS= >>Xy01LS9PV1T=3D
>>=A0>>UyMsrIyAAJvwAm9gqgYAJG3K6uLuivzRNZtvE/lq8o+SorK8+cOePq6spgMNrb28= >>3MzFatWgV2z=3D
>>=A0>>9lsdlZWVl5eXlVVVV1dHQhMq6mpSUxMDA0NzcjIAOOvqKgoJSUlJSUlMTGxvLwch= >>JG8v3zt7Ox8=3D
>>=A0>>8eJFe3s7jN+aSpUAQ7KHEAQxODjo6em5du1aSUlJIFlfvHgBo64HBwepVOr9+/fB= >>h/hoC7Xxlyv=3D
>>=A0>>E1xcvXlhZWeXl5eEIZ96xPkAQRFdX14MHDy5evBgZGeni4qKsrKyjowNiqV++fKm= >>lpWVhYeHr6+=3D
>>=A0>>vl5VVZWfnq1Stzc/MHDx5YW1vr6OhkZma2tLScP39+3bp1hw4dunjx4s2bN1+8eA= >>FOqhAyNYwNc=3D
>>=A0>>eArIEFSUpK2tnZUVBRQzYWknUiB6h4EQfB4PCqVumXLFgkJidmzZx84cCA3Nxewu= >>b+/n81m83i8=3D
>>=A0>>vr6+rq4uYMrARyQfeFO+QtYSBBEeHr5t2zYYz42KucnFuOQrjlCEyWTW1NQUFxef= >>O3dux44dERE=3D
>>=A0>>RfD6fxWLdvXt3165dUVFR0dHR+vr6ZDLZ19d3+/btNjY2KSkpVlZWmZmZfX19lpa= >>WixYtun//fk=3D
>>=A0>>FBgYGBgbGxcW1t7cDAQE9PD4fDGWffiQ9fw8LCNm/ejNoHpmy/AENOF2Kz2TExMT= >>t37pSUlJw3b=3D
>>=A0>>56enl5+fj74qquri0wmh4SEMBgMqICNpOnEhhmsQGhoKPR/xRHPmMlu9PjsA6h5A= >>vhDEAQRGBj4=3D
>>=A0>>66+/+vn58fn8zs5OLS0teXl5Nzc3a2trVVVVLy+vuLg4TU3NQ4cOWVpaWlpaZmVl= >>4TgeGRkJXnB=3D
>>=A0>>/f//Nmze3bduWnp6em5sbEhKSn58Pz3Ece2iKCV9xHI+IiJCWlvbz8xOpfEXHAOw= >>fviADLo/Hi4=3D
>>=A0>>2N/eWXXyQlJVeuXGlkZPTy5UvQPwMDA+BkLDMzs+bmZkKw3fqWNYRthIoimUzetG= >>kTylcRzTPj0=3D
>>=A0>>gfgfklnZ2dMTEx2djaO49nZ2bKyshoaGiAhz+HDh6WlpR8/fhwWFubu7p6dnV1TU= >>xMYGGhubv7b=3D
>>=A0>>b7/JyMjcvHmzs7MzIiJCRkbm6dOnLBbL0tJyy5YtVCq1qKgoNja2uLgYGgXfC75i= >>GAb4CvJlYIj=3D
>>=A0>>X/eSWJSQOUQHZ1dUVFRW1c+fOGTNmfPHFF1euXKmurgYyD8OwvLw8DQ2NPXv2xMT= >>EgENDJ5ev4J=3D
>>=A0>>ogiNjYWHV1dZCPCJ+otB4PxqUPwLIzMzMvXLhw48aN1tbWjo4OXV3dhQsXampq+v= >>n5nTp1asuWL=3D
>>=A0>>WQyuby8nEQiPX/+nEql3rt3j0QiRUREqKur6+npNTU1RURErFu3ztHRMT8//9SpU= >>+rq6mVlZRiG=3D
>>=A0>>sdlsmKL6PeJramqqnp5eTEwM6v8qOn0AfTJBEAwGw8XFZePGjdOnT//00081NTVh= >>XDuO4z09Pfb=3D
>>=A0>>29r///ntycjLISIdiUioD9de6urpnz57V1NSgfH038hW+A7DANDQ0vH37NgjuAcJ= >>SWVk5IiIiIS=3D
>>=A0>>Hh1KlT169fd3V1vXfvHpVKJZFIampqt27dcnJyunTpUnR0NIfDoVAoP/300/Hjx8= >>+ePaujoxMaG=3D
>>=A0>>grd2PDR5McYPSUO9gE6nV5cXNzR0QE1NlG4EIx890Bn9fHxWbdunYSExLx5844dO= >>5aZmYkmC2Kx=3D
>>=A0>>WJGRkbGxseDMHBgdMOlM4vP5g4ODg4ODqNnhXe4XwEHJYDBevnzZ1NQE1pidnZ0U= >>CoVMJoNPCgs=3D
>>=A0>>Lvby8yGRyRUVFX19feXk5mUyOiYnx9vZOTU0FQRcUCmXz5s2mpqYgLUp/fz+6H4a= >>a3N8LvuICRZ=3D
>>=A0>>aP7AKKgq/wAsizgYEBCoWyZcuWadOmff755ydOnIAnjvD5fBqNRqPRQPpLIccGdP= >>vm7WsFXxyXy=3D
>>=A0>>21ra+vp6YFfvTO+8pGQHVxgIYfRZKjBH5gA4YIME2zDwjOxMAzz9/dfs2aNm5sbN= >>GNBEyzK0feC=3D
>>=A0>>rxiGtbe3FxUVMZnMcdb8bcqCre7v76dQKMrKyh9//PGcOXOOHDmSn5+PC0ZOdXW1= >>k5MTUFhxQfo=3D
>>=A0>>gDMk88PZ8RXewwPiprq6+d+9ebm6u0FT51u0Wxpvpr0IDHXQf/BdH9q4gg3EBp3E= >>c7+3tdXR0VF=3D
>>=A0>>RU9PPzg59PIDmKOPAVlJ6UlGRsbEylUtF8b2/5nkYV0pAZICpQUVFRUlLyb3/729= >>GjRwsKCmDn1=3D
>>=A0>>9bW3rx58/Dhw8HBwWCBhZojJ0v8C02DBEHExMQoKiqC/IS4aHa2AP6Ar28JTLA1B= >>0Y5m80G+1u1=3D
>>=A0>>tbVvo0uJCV8xDAN28oCAABjPPSlkRQ0CfMR1ure3F3hCffTRRzNnzty3b19OTg7s= >>w+7ubgsLC2V=3D
>>=A0>>l5YCAgNbW1on5Er1RVeGLAP6E0J4FWzHphU4RX1F5DE3WsElv2q3iw9eIiAgpKSk= >>fHx8hr7QJPx=3D
>>=A0>>b+HD4ESlY6ne7p6SkvLy8pKTl37tyDBw8mJyeD4y5A24F7wL1798DWwBtNWW8KVC= >>UgCALsm4Dzj=3D
>>=A0>>ECJQEJNermi5Ss+fMmMylRo8X6v5SuFQpGTk/Pz85vc+AIMce8HLeVwOGQyec2aN= >>TNnzly+fPnJ=3D
>>=A0>>kyfz8vJgigCwQs/NzU1OTu7s7BT6+dvXZyTgJABi8BpjAAAgAElEQVSql5KSoqam= >>9uzZM3y4f/O=3D
>>=A0>>klytyvuLDnWghcWG48ATmUHHgK6hGQUHBnTt3srKyYBKeyeIHKr04HE5ISIiCgsL= >>06dO//vpra2=3D
>>=A0>>tr4A0ImlxTU5OXl9ff3w+6lEAiqES0SEeVVxzHCYJoa2t7+vQp2FeDTBXFUJk4Xw= >>kBRn6CrrrQd=3D
>>=A0>>RiGWBtwQbMnoGaJCV9xHO/r62toaAB5fdG6vc0z0VENTC4JCQmKioozZsyYM2fO8= >>ePHoVmeIIiq=3D
>>=A0>>qqq7d+96e3uDrO2ge2HyZBHFk8HHopRlsVjQn1Ds1lsoU0e9hgSFXc8XuJ1DgoKL= >>CfBMfPiKNvN=3D
>>=A0>>NrRyvA/qQ3t7ekJAQQNbZs2fr6em9fPkSys7Kyspz587B01rAygwkZkOtkJNOHQx= >>ZFILXyuFw6H=3D
>>=A0>>Q66rE0uSVCTISvGIax2ey6urqampra2lqwuwMynZSWllZWVlZWVlZUVHR1dYHGMJ= >>nMysrK4uLik=3D
>>=A0>>pISOp3O5/N7e3urq6tLSkrKysp6e3tHzllj97L48LWnp6eiogKeRPVG70loVkUvw= >>DCg0+lkMllO=3D
>>=A0>>Tk5SUvKLL75QU1ODBk5C4O2qpKR0584ddI8QFX74ZMj7MSoPRgiO48XFxc7OziUl= >>JUINmfSi35i=3D
>>=A0>>vwASYlJRkZWWVkJCQkJAQGhpaX1/f29sbHBysra1tYWERHh5+584db29vJpPZ2to= >>aExOTkpISFR=3D
>>=A0>>X16NGjwsJCYO4GNm13d3d/f/+Wlhahl/2+8DUnJ8fMzCw1NRVuoLwpZaFqhJ6QiO= >>M4jUZzc3OTk=3D
>>=A0>>pL68ssvt23bduvWreTkZOAPBNg8MDCQmpoaEBBQWVkJddkpg9B6KyIi4pdffgHny= >>YtohABMhK8M=3D
>>=A0>>BsPKygqc2lpeXn716tWnT592d3c/ffp01apVJiYm2dnZ+vr6enp6LS0tGRkZBgYG= >>/v7+GRkZHh4=3D
>>=A0>>excXFdXV1Fy9etLS0LCgocHJyAutKOJUAiD9foT0LuEdOYD0ORRSqSIDHlpaW2tr= >>a/uc//5k5c6=3D
>>=A0>>a8vHxoaCiTyYRecn19fWw2G8xpaAinSNsrBCG+ksnkjRs3gnhuXJQq7ET4WlxcvH= >>v3biUlpdLS0=3D
>>=A0>>vb29lOnTpmZmdXX1/v4+CgqKpLJ5La2tjNnzuzfv7+oqKiwsNDY2FhHR+fcuXOmp= >>qaxsbFkMllB=3D
>>=A0>>QeHKlSuJiYnW1tb79u0LDg4W4uvYECu+gnyaME3am7YCQ/IJ4zjO5/Pz8/P19fWX= >>Ll06a9YsBQU=3D
>>=A0>>FcGorQRBAH62oqHj8+HFiYiIa3Tr1eTogHfkCf210vwAXn/NhCIJ4+fKlvLy8vLx= >>8eXl5c3Ozjo=3D
>>=A0>>6OsbFxXV2dj4/Pb7/9lpqa2t3draur+9NPP7m7u7e2tubn59vY2Bw5ckRKSkpXV/= >>fhw4fy8vI2N=3D
>>=A0>>jYlJSV5eXnZ2dnNzc3QVjeefhcfvoaHhysoKJBIJNQZcvwPQQ1P4G9OTs7Ro0e//= >>PJLCQkJeXl5=3D
>>=A0>>4BJECE6qLy4u1tfXV1RUJJFI0BVrAuW+PVA6EgRBoVB27tyJ6gMiqtJE+NrV1WVl= >>ZbV79+64uLj=3D
>>=A0>>U1FQtLS17e/vGxsYHDx4oKCgEBwe3trYeP3584cKFVlZW2dnZISEh2dnZFArl4MG= >>Dx48fj4yM1N=3D
>>=A0>>bWtre37+joaG5uBsko4fPflK937tzZtWvXu+JrZmbm1atXc3JyJmYcQI3qPB4vLy= >>9PS0tr9uzZE=3D
>>=A0>>hISq1evDgoK4nK5hGDHqL6+3szMbMOGDdevX6+vr+cPdwwQRRvHACwXyNeysjJPT= >>8/y8nIwD2Ai=3D
>>=A0>>sxJMxD7A5/NLSkru3r3r5OTk5OR0586doqKijo4OJycnAwODsLCwzs5ONze3U6dO= >>hYeHU6nUu3f=3D
>>=A0>>vhoWFxcXF3blzJzQ0tK6uztnZ2cbGJj4+PiAgICMjAxUVaHe8rgIoX62trffs2fP= >>q1aupX29hGE=3D
>>=A0>>aj0RobG/v6+ibMG9AQLpeblZWlq6u7YMGCzz//fOPGje7u7sDtC5rMMjIy9PX1LS= >>0twakY8OeoH=3D
>>=A0>>jzZTXxtnSEj4cYem80Gig0PScM96UVPkK9cLrepqam4uLioqKiuro7L5XK53JaWF= >>mDeGhwcpNFo=3D
>>=A0>>9fX1dDqdwWCAZDDV1dVVVVUMBmNwcLCtra28vLyysrKsrKy9vf2NNu5QWvB4PBcX= >>F11dXZDZGRe=3D
>>=A0>>xsXpkTXp7e/v7+1GHvVGLhpSCFzgy6vr6+sCcs27dOllZ2Vu3bmVkZEBfUg6H09P= >>Tw+PxOjo6Cg=3D
>>=A0>>sLaTTaqGNjKqUsNgJsNrutrQ2G32Gi8VvHJ2x/FdoXQD+EcwSKkR/iSLTaG9UYfT= >>FDQ0O2trYHD=3D
>>=A0>>x6EPnW4KI3VI2tSUFDg4eEBdkfHdjcT4iv8y2Kx/P39ZWVlP/vss8WLF1+7dq2+v= >>h72EofDCQ0N=3D
>>=A0>>9fT0BDna0f6cmja+DqhQIAgiMzPTzMzs+fPnBHLesSiG0ET4ig/fiIMNeFONagIz= >>ODoTga6xtLR=3D
>>=A0>>UUVF58eIFvOFNnzkxEAJ/F3Ag4B/6RqITNy7Y22Oz2UFBQTIyMh999NHnn3+ur69= >>fWloKB97Q0F=3D
>>=A0>>BsbKyysrKRkVF7ezt8zhS07g+Bbm4RI+JjxY6vEOhr+EP/lclqACY49gnaB4D+Op= >>VzIiHIP7B16=3D
>>=A0>>1bgT4j/0VjFhmsCAwMDJBJJSkpq+vTpS5YsuXjxYklJCVQHORxObGysiorKzp07w= >>8LCgL0PHa5T=3D
>>=A0>>08zXNQQTGLNwHCcIIiwsTEZGBs2XIaKiJy5f8RFerXCqEtHYwkcsS4XsA7DEKXid= >>hCD/wKZNm0A=3D
>>=A0>>SBnSuH/UncEjjON7X1wdk0owZM1asWGFvbw88rOHNNBrNyMhIRUXl2bNnbDYbfj5= >>2EVMDbLhuA+=3D
>>=A0>>yvIF8xqg+IouhhfB1/GajaCpZf/f39cOWBv4kofaO2oTdD+bp79270JHMoxkQKMD= >>yioqLk5OT8/=3D
>>=A0>>f3RfBljVB78kMlkenl5rV+/fvr06f/+9789PDy6u7vRkDiCILq7ux8/fhwfHw/sr= >>/CxKOnfIVD1=3D
>>=A0>>jyCIrKwsU1PTkfrrpJc7jK+QhX8IcH4NXxCrmZ2dbW9vHxsby2QyYXuw0YCPQ8Ed= >>+ysIAjlPHtp=3D
>>=A0>>fRTq4R1amrKzM2dkZ+Ezhw53T8dGGIiHwvAZx2MuWLXN3dwcnYAEGEATR39/f29s= >>7MDAAEusK6T=3D
>>=A0>>kinb7GCShZIWVZLFZzczNIRIlu1U560cP42tHTNjg0gP9RMQRBdHR0xMXF0Wg0HM= >>fBIY6mpqbx8=3D
>>=A0>>fFo8jZUBuNIJC2G6OmYwIAn1B1jV0CIr+j+1hS/SJBEDWSjgE1DfQlQbhEEQaPRb= >>G1tN2zY8Mkn=3D
>>=A0>>nyxfvtzZ2ZnBYODI8qWqquratWuurq7A5UocTAEjgb5HDMNgmlRcsAOCrsYmF8P4= >>Gp7r39hRx2D=3D
>>=A0>>RMXysPuJyuXFxcWZmZsXFxWAwsVgsGo0GznIWYifKWiFKgQsY6DP+FsInv8P9WAD= >>YOqH8LthogW=3D
>>=A0>>vAT+if//ynhITEkiVLnJ2de3p6wJ2gE7q7ux8+fLhu3To7O7ve3l748ynbCBgn0E= >>EICAr8X0HKD=3D
>>=A0>>NDeqdgvSCuJCk5zyS6N5/P5BD766ycIoqamRkdHZ+3atdbW1jU1NW1tbREREUFBQ= >>U1NTTwer6Ki=3D
>>=A0>>wtvb297e3t3d3d3dPTIyMjc3l0wmOzs7p6SkgK2g9vb2+Pj45OTkrKwsNDkKf3xe= >>+uLD15qaGjK=3D
>>=A0>>ZXFlZib6qkQ0hCILNZvv6+q5cuRKoAY6Ojt3d3Tgye7a3tzs6OhoYGLi5uTU3N+M= >>I10URCPU2QE=3D
>>=A0>>cmjuMEQeTl5VlaWoJsSHCMiZyvpm5yD4IvJubHDHCFN0jRHzQ0NOjp6UlJSYFTx2= >>k02uXLl1euX=3D
>>=A0>>Hnr1i0Gg5GcnCwlJfXNN99YWVk5ODjs27fP2NjY0dFRVVVVRUUlIyODw+H4+voaG= >>BhER0fHxMR4=3D
>>=A0>>enrC3XC0R8Scr6C4qKgoRUVFsNHPEySVhioBX5BCkMvlksnktWvXTp8+/ccff3R3= >>d6fT6eA5kJE=3D
>>=A0>>JCQmGhoYRERFgmhKfA2lHBbrsA/bX9evXBwYGQr7iU+Cvvdn0Wz2nUw/CbOs768f= >>g6+DgoJ2dnY=3D
>>=A0>>aGRklJCUEQQ0ND9vb233zzjYaGRktLy4sXL2RkZL7++msqlVpaWqqsrKyvr19eXv= >>7o0SNZWdmws=3D
>>=A0>>LDGxkZTU9OrV6+WlpbGxMTs3bs3ICAAJCMZJ8SErxiGhYeHS0lJPXnyBI37hVQDq= >>6WhoaHU1NRN=3D
>>=A0>>mzZNmzZt2bJlTk5OYK8V3gDuaWhoKCsrAw4ufCRkTwz1AT4SGYYJ8g/A/QJszLO7= >>3hLD+Hrg3i/=3D
>>=A0>>X/K57JzzpZHSOwdehoSE7Ozt1dfXS0lLwb1BQ0Jo1aw4ePNjc3Pzy5cutW7f+61/= >>/Sk1NLSkpUV=3D
>>=A0>>NTMzc37+joCA8PV1FRiYqKqqioOH36tJGRkbe3t62tra6ubmRkJAhVg3gv5Cvgq7= >>S0tLe3N8gDg=3D
>>=A0>>CGARExLS9u/f/+MGTNWrVrl4uICT78GtzEYDOBoAVVhKLewMX0S3iGwEfbXsLCw7= >>du3o+dv4VPg=3D
>>=A0>>n6V6d+dV/xuBaST2AHsMvrJYrNu3b4NwIjqdzmQyX7x4oaKioqmpCeSrrKzswoUL= >>k5KSioqKdu3=3D
>>=A0>>aZWpq2traSiKRgONmaWmpjo7OkSNHwsPDc3Nzs7KyGhsbwSSI9siorRUiBLQPQPu= >>riIb1qP2AYV=3D
>>=A0>>hsbOzOnTvJZDLcl4KvanBwsKqqikQi7d+/f86cOStXrnRycqLRaKDa4AkVFRX29v= >>bOzs4gaauQ9=3D
>>=A0>>RpiCprzRgADCUbkEwTx8uVLkDNd1AaNYXx9VhjR0Ufr4/bxsddOQMBA6OXlJScnd= >>+HChfDw8NLS=3D
>>=A0>>0ujoaDk5uT179pSWlubn5ysqKq5YsQLoA3v37gUnPoKU4WZmZkVFRSdPnpSVlSWR= >>SDk5ORQKpaC=3D
>>=A0>>gYJzxMEKaPo/Hs7GxAZE5I7+dAjQ1NUVHR1dVVUEdABeEDAUGBu7btw+ECSxbtsz= >>NzQ0IUVDPgY=3D
>>=A0>>GBFy9enD59WllZ2d3dHVgGxVZbFQLsZ74gJoLD4TCZTNSuJ6KGDOMrHxsc55ZBTU= >>3NuXPnlJSU7=3D
>>=A0>>t+/X15enpiYaGpqam5uXlhYWFdXd//+/YsXL5aVlTU3Nz969MjZ2bmpqamgoODCh= >>QsPHz5saWnx=3D
>>=A0>>9vbeuXPn6dOnL126dP/+/ZycHChfUQEzslxseH44Pp/v4+OjpaUFjpiCv5pKKQvt= >>WbDyNBrN19d=3D
>>=A0>>3w4YNEhIS06dP3759+/3797u6ulDZU1paeubMmY0bNz548KC1tXWKq/2WwJCFIFQ= >>JANBFpyiKJo=3D
>>=A0>>T2t8b5GxzHKyoqAgMDs7Ky+vr6WCxWU1NTY2NjT0/PwMAAjUZrbW0FyUe7urq6ur= >>rAhm1rayuIJ=3D
>>=A0>>ujo6KBQKJ6engEBASUlJb29veN8YUJ85fF4T58+PXr0KPTPmmIRBfaigREAdsuNG= >>zdWrVr10Ucf=3D
>>=A0>>zZ49e+/evcnJySC0HV1g5eTkGBgY2NjYtLS0iFThExHQzS0cxzs6OrKzs1tbW8G3= >>UJpMOmuJifm=3D
>>=A0>>/glrClMrEmwD8dmhoiMVigawkBLL1/4d8hUzFMAyYJjQ1NUfqr1Pz7oE+UF9fj2F= >>YT09Pfn7+5c=3D
>>=A0>>uXly1b9tVXX23bts3c3Dw1NRXs+QG7AUEQdDq9sbGxqanpxYsXHR0dxHCDpbiZAk= >>YFfAtQ/8nOz=3D
>>=A0>>jYzM8vMzCQQ/wFRyI6J8BUXiDF0PYuaYDDEogGXIOgMgiHO3W+0/sUQgGcGBgaeP= >>Xu2oqJi5G3j=3D
>>=A0>>b84EQAhiVE6dOkUmkxMSEkxNTXft2rV27VopKSk7O7vCwkI6nQ7TBYNfNTY2enh4= >>+Pn50el02AR=3D
>>=A0>>0Q+i94CusMyawv8bFxe3fvz8xMRGYREQkXPG34Ss0iQsNJv4ICIWAoio5Sr7xkAw= >>dDKCsiIgIAw=3D
>>=A0>>ODV69eoaNiCoQrGG+JiYkyMjLq6uoKCgqSkpLTpk1btWqVmZkZSHEFpw5w0dTUZG= >>dnd/bsWQqFA=3D
>>=A0>>iYW2JNTvEx8S6BVBaLn2bNnwLhOTGV8wTj1V6F6jxT+KInRf1FxK8TUNyqXjxw95= >>eDgsH//fiH/=3D
>>=A0>>rDd6GtqcMZqJ3gP419LSYmNjs3jx4jlz5nz88cdffvmlkpKSm5tbXV2dkDkWx/GW= >>lhZ7e3sTE5P=3D
>>=A0>>IyEgQ54QP117eF7LiI94dQRCpqam7d+8OCwvDR0tHOYkYxlfOIOePfyEGAB1BTFI= >>8Nx9JYC1EIH=3D
>>=A0>>QoQk0dx3EOh1NSUmJmZvbjjz+CQwS2b98ODlBlMpkEksMCrpqzsrJu3rwJyIq/bw= >>QVwkhZ097eH=3D
>>=A0>>hAQIBTlIXL9tayxDJtQWNUUA+XrW+5vYcNTfPKHZ1SG14B2wOu3pqbG29v7wIEDf= >>//73z/++ONv=3D
>>=A0>>v/1WW1ubSqWCKFb0sZjArs7lchsaGgoKCgCbRTRXThmEyAoGPJvNBjsIMP+kyPna= >>2NmIrtbFFpP=3D
>>=A0>>LV7RzsREn/oBSuFwuk8lMTk5+/PjxiRMnfvjhh08//XTevHkKCgpWVlbgsFZcEM+= >>EI6pFcXFxVF=3D
>>=A0>>RUY2PjSEXovVhavQ5oE/h8fn9/P5PJhEEWuMjsM8P4GvMyYoA7KIpiJheTyFd8+D= >>Y9fA1wtdTU1=3D
>>=A0>>BQVFeXq6nr58mV5efmFCxcuWLBg3bp1x44ds7a29vDwcHBwKC0txQVkhbxnsVhUK= >>vXixYtXr16t=3D
>>=A0>>rq5GixO6eE+B6q9FRUX29vZFRUVvv4oYG8P4mloYx+zrEf9unHT5ihoc4NRfW1ub= >>kJBgZGS0cuX=3D
>>=A0>>Kr7766tNPP5WQkFi8ePHx48dDQ0NBWpfIyEg1NTXgP4ByncVieXt7Kykp/f777wk= >>JCSBgEDUDve=3D
>>=A0>>/yFR/O14iICHl5+YiICFzEu+LD+BqW4dc/yPlL6QPoRgaO44ODg/X19XFxcY6Ojg= >>cOHPj555+/+=3D
>>=A0>>OKLjz/++G9/+9uiRYv27Nnj5eVVWVkJzmoE7wmcz426qxIEUVVVdfjw4R07dqCh2= >>KBEPrI5N5md=3D
>>=A0>>MoUQ0r8JgggJCUHPk8emxv5a1Vgh5vorlIV8QeSQlZWVqqpqfn4+IQjZQ3sTG7HL= >>giEGKYj29vZ=3D
>>=A0>>Xr15lZGQ4OTkdPnx4yZIls2bNkpCQmDlz5vr1642Nje/evUsikWpqauDpjaC4Z8+= >>ebd682dfXFx=3D
>>=A0>>7VAh9IJpOpVCpIhYkjs//7sikwBoTWW4Qgnhvl61TEwzDYDHEmKz7cMwis3y0sLH= >>bu3JmXlwcn2=3D
>>=A0>>VEZKQQOh9Pf39/Z2ZmWlubv729qaqqsrLx169YFCxZISEhMmzZt5syZS5cu1dDQC= >>A4OBhnBoKoA=3D
>>=A0>>K8Pn8ykUyi+//OLv7w9T1nE4HMBd6FcgOmXuXQET5KyFE11YWNi2bduio6OJqYzn= >>5vHFfYYauRP=3D
>>=A0>>h5uZ26NChsrIylI58Pr+3t7e7u5vBYNDpdDqdDvLPgZxzcXFxt27dMjY2Pnbs2Ma= >>NG5cvX75w4c=3D
>>=A0>>K5c+fOnz//m2++2bRpk7GxsbW1dXBwcHFxMQj/JxDnBBS1tbXBwcEVFRU8Hm9gYI= >>BKpbq6uhYXF=3D
>>=A0>>wNXAVBnMXS4fnugx9LiOF5ZWRkQEFBbW4uL2OVoGF9fF2MoPkCFKBCxz58/P3v2b= >>EREREVFRUVF=3D
>>=A0>>RVVVVXl5OYVCsbCwMDMzMzMzMzExOX/+/JkzZ3bu3Llhw4Y1a9YsXbp0zpw5n3zy= >>yccffzxv3rx=3D
>>=A0>>NmzaZmJhYWFjY2NhERkYWFhb29PSgXlcoUMkBPgG3DQ0NhYWFKSsrGxgYVFVVYYg= >>R4E8pX2H/g1=3D
>>=A0>>kOpggHjYVnWE960cRb5s+aeqC6/NDQ0NOnTzds2PDzzz9v27ZNVlZ269atsrKyP/= >>zww5w5cyQlJ=3D
>>=A0>>T/77LNPP/109uzZn332mYSEhISExIwZMyQEWLp06bVr11JTU1tbW2k0WktLS3d3d= >>29vL5olE1he=3D
>>=A0>>wYfgAiytuFxub29vX18fh8Pp6ury9/dXVFTcu3dvYmIimmtbdDPjOwS6fgCta2pq= >>Sk9Pb2lpAXK=3D
>>=A0>>XL1b5X98hMMSeDyYjS0tLkD1dQkLiiy++WLRo0eLFi7/77rvvvvtu0aJFS5YsARf= >>fffedtLT02b=3D
>>=A0>>Nnz549Kycnt2TJkmXLlmloaDx58qSurg7DsM7Ozvj4eF9fXz8/PwcHBxKJ1NHRwe= >>PxGhoaSCSSg=3D
>>=A0>>4PD48eP/fz8kpOTu7u7wRsKCQm5d+/etWvXrl69qqampqGhkZmZiYqZP59khUCbi= >>eN4eHj4jh07=3D
>>=A0>>KBQKjkT2fuDrKJtDAQEBmzdv3rp164EDB27fvk0ikUJDQ0NCQkIRhISEPHv2LDMz= >>k8lkdnR0ZGZ=3D
>>=A0>>mhoWFkclkCoVCpVLB6Ql0Oj0rKysqKio6OtrFxcXf3x+kA2pvb4+Ojrazs/Pw8Ii= >>Ojs7Nze3t7Q=3D
>>=A0>>UWgJiYGC0trUWLFuno6Pj7++fn58NVl5BY/ZOJWNQ+AJahz549k5KSAucd8xGPs0= >>kv+j3jK46Yt=3D
>>=A0>>EB3NDc337x5Mzw8vLGxEXp/jx/oYzHBcUIgYgI6rPB4vJ6eHnD2FbrjOjg46OPjs= >>2HDBi8vL5iI=3D
>>=A0>>CX3an5uv0FUA2AdkZWXDw8OJ4QkqJ73V7xlfhfqCIAgajfbo0aPi4uLxs/N1lH2j= >>z8F1VFQU3C8=3D
>>=A0>>gCOJ9N6yOH+gCiyCI4ODg9evXg3yaGLK/NXV8JXDwbgixMhqAbsIF24A4jiclJZm= >>YmICda6jUTo=3D
>>=A0>>EwIwT5NLdt2+bn5wfzXPyJdVYUKCkJgkhPTzcyMkpPT8eHWw9Ey1cCHyZFMPy/Rs= >>QxwrunGBji5=3D
>>=A0>>gdmanA+TEFBAY5E5kwZY0pLSx8/fpyXl4cmIPqL8BU2GcdxDofT0dEBTl0cucs4i= >>SCE4gsGhrgt=3D
>>=A0>>PQ2tvUV1TGpFF6WDXVnRUc7hDoiJlEU5wefzBwcHb926JeSvPcXKIh9x94aWyCkr= >>/V2BjwBDrNH=3D
>>=A0>>gpWBTYx/Ib3tln25+NU4luMjQ98Vp24wDac2RdfT6/sF+Qjz2aTFkswA4AcbExBg= >>aGr58+RLcwB=3D
>>=A0>>el8+XIykArIxxCfwV9QGjG5/P5AwMDwDINADOEila+XorS0yatPP3sP0dI6y4n7j= >>SKUb5G1X+Qf=3D
>>=A0>>ft5U+YgTyz8YjEkYhH8297ebmNj8+rVK3xEUPwUVKawsNDf37+2tvYvyFfIWhzHM= >>zIyQD54XMQR=3D
>>=A0>>lMP4qh26SfeZlJrPdxtc/qbms+FkqLJFsnZwkUdqdWIjo1EcVIKRXdDd3W1nZwf1= >>V1GXDi8IQb4=3D
>>=A0>>3JSWl4OBgoezEIq2GOEDIShMUFLR+/XoymSxkz5r0cofxVdVtnobdd1rOP+y79v9= >>09X/wjdFMa3=3D
>>=A0>>AIenXF8/m1srZX4sBXIRAE0d3dbW9vj+oDIqLLyBfQ09Nz9+7d//znPwEBAWj+rL= >>8IoDWGIIiQk=3D
>>=A0>>JANGzbAfJqiG7fD+LpNb832E8t1bv58wWPDJZel1yOX7/ebp/B4kXWiRQuzVUxUW= >>BSQrzC/C1z6=3D
>>=A0>>THpZkK9Qaaurqzt48OCOHTuAfQAXm8NbRA2UkcD+GhISsnHjxtDQUFzEKSCG8VXN= >>eZu0o+wO963=3D
>>=A0>>qAd9pkb464vf1/icbdnvtvUS5WtJZJp587ezstLW1LSoqwsfsqUnsQfgcGo129+7= >>d+/fvt7e3Q+=3D
>>=A0>>PrX8GeNVJ8FhUVOTo6wqwluMisNMP4uvz+8mWWS+TtlU75GBxzV1d9vH6Xh+yZUI= >>PokpheTu+kl=3D
>>=A0>>/32IAiiq6vLzs6uuLgYzk2j9tSkdJ/QE3g8XnNzc3V1NdiqFZFHknhCaCYB+fyAo= >>zqKSS93GF+P=3D
>>=A0>>+WlJPVj/o9W3253Wm0YaWac7ehYEBBSTS7vEUbjiAn3A1tY2PT191A3YyQX+mrAF= >>XLACQ3NkTA3=3D
>>=A0>>eVc8LRRTD+mACI/QfCoiJNYFA+Wocb+Kc7uqV6WWfbX0n60Jue8IQznu3/TI2CIK= >>g0WgGBgYXLl=3D
>>=A0>>xISUnJz8/Pzc3NESA/P7+2thbs7H8ABP5HwULQ+oEjyVNeN2UB1jKZzMrKyp6eHq= >>iSjS1fR1YJf=3D
>>=A0>>ebYb/x/fG1htzPYDCabyccIDMf42BBBEISYuRCgIAiCwWCYm5vv3r1bW1tbX1//1= >>KlTenp6J0+e=3D
>>=A0>>1NPT09XVtbGxiY+Pz8zMTEpKSkhI8PPzI5FIWVlZ5eXlJSUlqampiYmJhYWF6enp= >>MTExQUFBXl5=3D
>>=A0>>enq+Bh4cH/NbLy8vb2xt86OHh4evrGx0dnZ6eTqVS09LS0qcEVCo1Kyurrq4OZLX= >>GX5OYB8Owvr=3D
>>=A0>>4+cIzUqKxF+QHXT5C140RKSsrRo0fHnuXQt9bR0ZGRkZGdnQ2cOeE96B7EqMQlhP= >>ZjX1eG2GJoa=3D
>>=A0>>KiioiIzMzMjIyMzMzM9PT0tLS0jIyM9PT0lJSU9PZ1EIpHJZG9vb0dHR0NDw8uXL= >>5NIpLy8vKys=3D
>>=A0>>LF9fX1dXVyqV6u/vb2dnd/nyZcDyEydOnBwBPT09PT29EydO6Orqgn8PHz78/fff= >>z58/X1VV1cD=3D
>>=A0>>AYMeOHdLS0ps3b5aSktosekhJScnIyOjq6j58+PDRo0d2dnaOjo4ODg72CBwcHB4= >>9emRhYWFpaf=3D
>>=A0>>nw4UMHB4eEhISGhobk5GQPDw8KhZKXl0ehUB4/fuzv75+UlOTm5hYZGVlVVZWUlA= >>S6MSMjg8Fgc=3D
>>=A0>>DgcNpvNYrGApyWLxert7WWz2eDDwcFBf3//9evX+/n5cTicvr6+/v5+kNwX/Mtms= >>4FyDza9CIKo=3D
>>=A0>>r683MzPbvHmzvr5+eHg4iOgcGBiAFpjXbWuPxlecwMVVoI6Kscc0m83u7+/v6+vr= >>6enp7Ozs6Oj=3D
>>=A0>>o6+sDwxf0Johs6enp6erqam9vb2tr6xgN4KvW1tbW1lZwXVdXFxwc7OLikpubW1B= >>Q4OnpaWtra2=3D
>>=A0>>tra2NjYyt6PHz48P79+3p6eoqKilu3bpWWlpaWlpYdDTIyMrKystLS0jIyMlpaWh= >>YWFrt27fr22=3D
>>=A0>>28VFBQMDQ3V1NQWLly4YsUKFRWV7du3a2lpGRgYSEtLy8vL79mzR01N7fr163fu3= >>Dl//vzp06cN=3D
>>=A0>>BDhz5oyRkdHp06f19fXPnj2rqqr6r3/969dffz1z5oyBgYGhoSG4MDAwMDIyOnfu= >>XEBAQFxcXEB=3D
>>=A0>>AQEZGRklJSVRUlJqa2rRp0yQlJVetWnX48OGTJ09aWFikp6fT6XQulwuTcI1810h= >>+wiE6l9dDEL=3D
>>=A0>>z3QrKOBIE4p6J7USOnQngbgayW3nF4G70AAAm1SURBVAZTvMyCaGlpycrKAhNLen= >>o6mGdGAnwLL=3D
>>=A0>>hISEqysrHR1dW1tbZOTk58+fXry5Mljx45ZWlrGxcWlp6fb2dlpaWnp6elZWFhYW= >>Vk5OTnZ2dkZ=3D
>>=A0>>GRlpamqqq6sfOHDg4MGDBw4c2L9///79+zU1NTU0NDQ1NQ8fPnxQAHV1dQ0NDQ0N= >>DXD/kSNHLl6=3D
>>=A0>>8aGpqqqSkdPr06cuXLyspKX3zzTcSw/H3v/997969GRkZmCAybNRX/D++ZjW4FNO= >>Ca+hpxW2F3X=3D
>>=A0>>3090rICrv048PXsEJObuid0BSFIT6d4ykRMhU+fIrJiv/Ryul16O3tbWtrA+EYQ0= >>NDYN4Ax4QTB=3D
>>=A0>>MFms1taWlpbW5lMJpju+/v7Ozo66uvrGxoaGhsbGxsb6+rq6urqQGJ78Bdc1NfXg= >>9vq6uoaGhqa=3D
>>=A0>>mprq6+sbGxurq6uzsrK8vb0pFEpCQsLt27eVlJQkJSU/+uijxYsXf//99/Ly8jdu= >>3HBwcCgvLx/=3D
>>=A0>>jFRAoX+0y91ikqDtlX0urTevlsIj3SsqiSjo23O0QqE0A+PClLiZI/YAS+nXPF/p= >>KaCGM0n1sjH=3D
>>=A0>>zIGHeO/RXanFHHJICQkxA+/HB0yGP4lYgAExgmJCQcOnRIWVlZR0cnMDAwMzOzuL= >>gYqLxCbopCG=3D
>>=A0>>MbXK6n7joXu1A3VuJt8u6il+P21fmPDF5hCRBn5FfwJ/nrfrtdRbeRt46keeH+vu= >>x9l6hiVgfQa=3D
>>=A0>>oz5CXwnRHd2OGrXckRfoM2GPYYJ1Ei6Yr3DkaFyhvuVyuRkZGT4+PiUlJeAcViFa= >>469PMjKMr6f=3D
>>=A0>>8fz0fuedK9GGH9Dvpdek9nN73S8SKLTBEDHO53Pr6+levXlVUVACDJT7cExK1wwv= >>JRSGe8fn8tr=3D
>>=A0>>a20tLS1tZWMHuIoYhBaQfrDw0FKEfHA8BXcJiZxDXzNbGvzmU0OCZW2SdXu3f21X= >>7g66QAynuCI=3D
>>=A0>>Lq6ujw9Pfft23fx4sWqqiohi6MQccF7xUeb63Ec53K5gYGB6urqDg4O4EwEMeTrq= >>HhTmqI//B9f=3D
>>=A0>>9T0WawV+s9dn7u/+/ybnOzHZrz31+APeFJjAFN/X1+fs7LxixYrjx483NTUJSU0C= >>WUVB7sIPcWS=3D
>>=A0>>iBPeEhoauXr3a0NCQTqf/FVzDCIJISkr6L1/3ev5zn8e3u91/2uWu6pLh0Tvwni2= >>5xBnoJE4mkz=3D
>>=A0>>du3Ghubg5Sb+ACn3wcx0F2o+7ubhBwi2HY4OAgi8ViMpnAVAwfNTg4yOFwCgoKfv= >>31V2NjY3BG/=3D
>>=A0>>V+LrwdcNLY9XKHmLnMz4UZyTSqHxxm5xAO/EdsdWrEFZBKXyyWRSOvXr798+TKTy= >>cQEbmU4jnd1=3D
>>=A0>>dcXGxjo6OlpYWMTGxrJYLA6Hk5+f7+3t7eXlRSKRSkpKQGbP1tbW6Ohof3//u3fv= >>rlmzxtDQEDz=3D
>>=A0>>qfdEHJoxhfN3lo3wywtgi1dog3Ngjw4Mz0E8QBB/j83g8Aifa+lohg8Unwvu9AKq= >>YDg0NBQUFbd=3D
>>=A0>>iwAfAVfE4QBJPJdHV1NTY2trW11dHROXDgQGpqalFR0alTp/bs2WNnZ3fhwoVHjx= >>61t7fTaDQ7O=3D
>>=A0>>7vjx4/b2NhoamouWLDAyMiIyWTifzX5KvVw7Q7Xnb/aqyhaKxk9PRucF+yX5xeSE= >>xL3Ku485bwB=3D
>>=A0>>5UxuU25Ja0lgbiCNRfugKrwRoPDj8XhBQUE///yzmZlZd3c3+KS2tjYsLExBQeHE= >>iRNdXV3FxcU=3D
>>=A0>>HDhzw9vYuKirS1tbesWPHkydPzp8/b2ho2NzcTKVSt2zZYmhoWF9f7+bmtnz5cgM= >>DA2Dt/4vwtb=3D
>>=A0>>OzkyAIieW6P/x87me563K/Wu6Su75d2kpG3VXd0Nto1ZVVP9/ZcDfynonPeRWbXb= >>ee3UorTetid=3D
>>=A0>>b3ryr9PgOv6oaGh4OBgIF8ZDAZBEHQ63cHB4dChQ4sWLdLW1gaB0SYmJiB34oULF= >>zZv3nz58mUT=3D
>>=A0>>ExPA18DAwNWrV3t7exMEUVhYqKysbGJiAlXhPzeG8bX3UW/8xdgw05D0W6mvbr2I= >>OR3tfsr9H6f=3D
>>=A0>>++dP51ZZ+Vrstdi+98I9dzr+c8TYwDzRv6Gr8K3TQxDBtNOCC8+eDgoLWrl1rbm7= >>OYDAwDKNSqa=3D
>>=A0>>qqqvv37//hhx8OHTrU0dHBYDCMjIx8fHxCQkLWrFmjpKQUExMDNvErKytBcJ+dnV= >>1vb29CQsKWL=3D
>>=A0>>VuMjY3huYp/Mgj1oYSEhJyc3H/5mmSWXGBcWGpcVnulufZiE9WQWmNZuezC94ccj= >>/x45cdvb3+1=3D
>>=A0>>1nb5kivffn/pB5MnZ/OrcvmYuOePf1cYSdaPPvoI2F8HBgbc3Nx+/PFHXV3d58+f= >>5+fnm5mZ/fT=3D
>>=A0>>TT46OjsePH1dUVAwKCgoICDhy5Eh4eLibm9v8+fMVFRXDw8PPnDmzbds2X1/ftLQ= >>0FRUVVVVVNz=3D
>>=A0>>c3dXX1L7/8Ultbu7VVHANC3x5j8dXvelTy40qyZf6NQ8GUa3lUqwJ/3bDtt2XXXF= >>0u6/rTmofLF=3D
>>=A0>>9/7f98/+oes2w/HQn5zfm7f9cFA+xq8jq84jvf29j59+lRHR+fSpUve3t6urq4GB= >>gba2tpZWVkx=3D
>>=A0>>MTFHjx49ffr0+fPnr1+/XlZWlpqaqqqqKi0tbWxsfPr0aQUFBVNT05KSkidPngCv= >>KGVl5dWrV1+=3D
>>=A0>>+fLmuru5dN1okGIuvVY6VbZG0ZI9c4+N3oq0LHl5Lengj8ICx4qnr23dd3SizZ/6= >>JaysCXtmmNc=3D
>>=A0>>QlVcfGlyW0Mzs+8HVUjCTr9OnTcRwH8rWmpqawsLCoqKi0tLSoqOjVq1elpaU9PT= >>0sFqugoCAiI=3D
>>=A0>>iI1NbW2tra/v5/BYKSlpXl4eISFhRUUFCQmJsbGxnZ3d3d1dcXHx5NIpOjo6KCgo= >>IKCAqBavOt2=3D
>>=A0>>Tz5G5SuNRiMIQoLtymE95rHd+ZU2FfGGidQjRUUmHZsfrF5z96elt/653Giu6v01= >>mqS9ak9+0/c=3D
>>=A0>>7Hfo8lMakfTDEjorXyVeIkYZtsKFFEATwBCAEJ3kQBDE4OAgj+IaGhnDkVFscx9G= >>o1D8fZV/H1+=3D
>>=A0>>vXr0s0OPVUWHMa7g22W7bmnKO6aTxOOZquFrxLyn3z7JuzFjz4xx6yhpyH/GG/ww= >>6JDuXN5aN2+=3D
>>=A0>>gcQBCExGsbzQ/z17nyvY/mfGyO7cdu2bf+Vr+XW9PbHPfUOtBdWNbV3mAnGKZrr9= >>5NKSWH1Ida5=3D
>>=A0>>9w6Faxgnnfg1UMkixSqrPquzv/Ndt0V8MWG+foAQRnbj5s2b/8vXZF963n1esX1/= >>jkN/qOVQ1G3=3D
>>=A0>>89u9P5n7xxZGNR112hz+7kRF7vSTfpSnc4nkqOSOFkuLzxMdrBLw/4ANej5GEGSM= >>mGUYmA7i7u7=3D
>>=A0>>u6uoaFhbW0tBCjxsd+wAeILT7w9QPeJ3zg6we8T/jA1w94n/D/AWQx0gRPTdK4AA= >>AAAElFTkSuQ=3D
>>=A0>>mCC" alt=3D3D""><br>
>>=A0>><br>=3DA0=3DA0=3DA0=3DA0 I wonder, however, does the situa= >>tion the same if rateless=3D
>>=A0>> erasure code (say fountain codes) is used?=3DA0 As with erasure= >> code, no ACK=3D
>>=A0>> and retransmission is needed except when the whole file is comp= >>leted. So e=3D
>>=A0>>ven heavy loaded, the network is still busy with effective data = >>packet, rig=3D
>>=A0>>ht?=3DA0 Although queueing delay will increase, I believe that= >>=3DA0 the network=3D
>>=A0>> throughput=3DA0 will not=3DA0 suffer the plunge as un-coded net= >>work. <br>
>>=A0>><br>=3DA0<br><br>Kara<br><br><b= >>r><br><br><br><br><div class=3D3D"gmail_= >>quote">2=3D
>>=A0>>013/3/5 Srinivasan Keshav <span dir=3D3D"ltr">&a= >>mp;lt;<a href=3D3D"mailto:keshav at uw>>=3D
>>=A0>>aterloo.ca&q= >>uot; target=3D3D"_blank">>">keshav at uwaterloo.ca</a>&gt;</span><br><block= >>q=3D
>> >>=A0>>uote class=3D3D"gmail_quote" style=3D3D"margin:0 = >>0 0 .8ex;border-left:1px #ccc =3D
>>=A0>>solid;padding-left:1ex">
>>=A0>>
>>=A0>>To answer this question, I put together some slides for a presen= >>tation at t=3D
>>=A0>>he IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs= >>, we always=3D
>>=A0>> size a shared resource (such as a link or a router) smaller tha= >>n the sum o=3D
>>=A0>>f peak demands. This can result in transient or persistent overl= >>oads, reduc=3D
>>=A0>>ing user-perceived performance. Transient overloads are easily r= >>elieved by =3D
>>=A0>>a buffer, but persistent overload requires reductions of source = >>loads, whic=3D
>>=A0>>h is the role of congestion control. Lacking congestion control,= >> or worse, =3D
>>=A0>>with an inappropriate response to a performance problem (such as= >> by increas=3D
>>=A0>>ing the load), shared network resources are always overloaded le= >>ading to de=3D
>>=A0>>lays, losses, and eventually collapse, where every packet that i= >>s sent is a=3D
>>=A0>> retransmission and no source makes progress. A more detailed de= >>scription c=3D
>>=A0>>an also be found in chapter 1 of my PhD thesis [2].<br>>> >>=A0>>
>>=A0>>
>>=A0>><br>
>>=A0>>Incidentally, the distributed optimization approach that Jon men= >>tioned is d=3D
>>=A0>>escribed beautifully in [3].<br>
>>=A0>><br>
>>=A0>>hope this helps,<br>
>>=A0>>keshav<br>
>>=A0>><br>
>>=A0>>[1] Congestion and Congestion Control, Presentation at IRTF ICCR= >>G Workshop,=3D
>>=A0>> PFLDnet, 2007, Los Angeles (California), USA, February 2007.<= >>;br>
>>=A0>><a href=3D3D">keshav/home/Papers/data/07/conge=3D" target=3D"_blank">http://blizzard.cs.u= >>waterloo.ca/keshav/home/Papers/data/07/conge=3D
>>=A0>>stion.pdf" target=3D3D"_blank">>://blizzard.cs.uwaterloo.ca/keshav/home/Pa=3D" target=3D"_blank">http://bli= >>zzard.cs.uwaterloo.ca/keshav/home/Pa=3D
>>=A0>>pers/data/07/congestion.pdf</a><br>
>>=A0>><br>
>>=A0>>[2] S. Keshav, Congestion Control in Computer Networks PhD Thesi= >>s, publishe=3D
>>=A0>>d as UC Berkeley TR-654, September 1991<br>
>>=A0>><a href=3D3D">keshav/home/Papers/data/91/thesi=3D" target=3D"_blank">http://blizzard.cs.u= >>waterloo.ca/keshav/home/Papers/data/91/thesi=3D
>>=A0>>s/ch1.pdf" target=3D3D"_blank">>://blizzard.cs.uwaterloo.ca/keshav/home/Pa=3D" target=3D"_blank">http://bli= >>zzard.cs.uwaterloo.ca/keshav/home/Pa=3D
>>=A0>>pers/data/91/thesis/ch1.pdf</a><br>
>>=A0>><br>
>>=A0>>[3] Palomar, Daniel P., and Mung Chiang. &quot;A tutorial on= >> decomposition =3D
>>=A0>>methods for network utility maximization.&quot; Selected Are= >>as in Communica=3D
>>=A0>>tions, IEEE Journal on 24.8 (2006): 1439-1451.<br>
>>=A0>><a href=3D3D">m/decomptutorial.pdf" target=3D"_blank">http://www.princeton.edu/~chiangm/d= >>ecomptutorial.pdf" target=3D3D"=3D
>>=A0>>_blank">>omptutorial.pdf" target=3D"_blank">http://www.princeton.edu/~chiangm/decomp= >>tutorial.pdf</a><br>
>>=A0>><br>
>>=A0>><br>
>>=A0>></blockquote></div><br>
>>=A0>>
>>=A0>>--f46d0444e84964e1a304d740bdcd--
>>
>>=A0cheers
>>
>>=A0 =A0jon
>>
>>

>> >>--e89a8ff1c4e2529bed04d742b110-- cheers jon From dhc2 at dcrocker.net Wed Mar 6 07:16:02 2013 From: dhc2 at dcrocker.net (Dave Crocker) Date: Wed, 06 Mar 2013 07:16:02 -0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <51375DB2.2070701@dcrocker.net> On 3/6/2013 5:43 AM, Jon Crowcroft wrote: > there's no free lunch - if the queue keeps being filled, you'll get increasing > packet loss - to cover the loss, you'll need more redundency in your erasure > coding - ... > so all that erasure codes buy you is delaying the point when you go over the My introduction to networking was as support staff at the UCLA Arpanet project, with Leonard Kleinrock as principal investigator. This meant I got to hear him lecture about queuing theory and he is a good enough teacher to make even that topic interesting. Eventually he give a summary lecture, about lessons learned, and he put up a graph which started out shallow, had a sharp elbow, and then increased rapidly. He said that years of measurement of actual networking behavior produced this graph and that while the mathematics of it was complicated, its meaning was pretty simple: In a network, things are very good, until they are very bad. When things are very good, queuing isn't needed because there is plenty of capacity. When things are very bad, queuing isn't helpful because there isn't enough capacity. So why bother with the cost of queuing mechanisms? Queuing, he noted, is for that very small phase at the elbow. That is, short bursts of contention, not sustained problems. I believe this is the reason the short queue lengths are said to make sense but long ones to cause problems. If you need a long queue length, you have bigger problems than the length of the queue... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From braden at isi.edu Wed Mar 6 09:06:11 2013 From: braden at isi.edu (Bob Braden) Date: Wed, 06 Mar 2013 09:06:11 -0800 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> Message-ID: <51377783.50708@isi.edu> Jon, It appears that we missed this one in the Host Requirements RFC (RFC1122). When we update RF1122 ;-)) we can include this in the link/Internet layer interface (section 2.4). It is also related to the "advice" suggested for dead gateway detection ( see Discussion in Section 3.3.1.4) Bob On 3/5/2013 11:20 PM, Jon Crowcroft wrote: > congestion control does work on some single links if the link layer > supports a congestion feedback mechanism - switched ethernet (for > example) has a feedback mechanism and some people have used this in > data center modifications and used it to push the later 2 feedback > up (as well as back) to IP/TCP - ie trigger ECN from the layer 2 > > this could easily also be done with contention information in > conventional and wireless ethernet on a single link > and could be triggerd from a cellular base station too if > you like > > but it isn't > > but it could be... > > given the impossibility (without precognition) of knowing who else is > just about to send on a wireless link, and the bursty nature of human > and software behaviour > it seems that this would be a more useful direction to fix things in > than other (more old fashioned and less efficient, c.f. keshav's > message )approaches - > From emmanuel.lochin at isae.fr Wed Mar 6 09:40:47 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Wed, 06 Mar 2013 18:40:47 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: <51377F9F.1080206@isae.fr> Hi all, We've attempted with success to implement a Decongestion Control Transport Protocol following A. Snoeren and T. Bonald Infocom'09 paper : "Is the law of Jungle sustainable for the Internet". We defined an "Anarchical Networks" scenario and tested our proposal named DCTP with Achoo (proposed by A. Snoeren) over a simulated ISP-like topology. Preliminary results tend to confirm that both Snoeren and Bonald are right and that such architecture is sustainable. You'll find our first experiments in the slides available here: http://www.lochin.net/tetrysjungle.pdf Emmanuel On 05/03/2013 13:07, Scharf, Michael (Michael) wrote: >> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>> There has been some interesting research on whether a >> transport protocol could work without any congestion control. >> One reference is: B. Raghavan and A. Snoeren, "Decongestion >> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >> I remember that you, some years ago, asked whether networking >> can be done without flow control. > My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. > > Michael -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From mattmathis at google.com Wed Mar 6 09:45:55 2013 From: mattmathis at google.com (Matt Mathis) Date: Wed, 6 Mar 2013 09:45:55 -0800 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: Most of the old results also don't apply to modern TCP loss recovery: With SACK plus a Linux's bugfix (don't clear the scoreboard on a timeout) the TCP recovery machinery works very hard to avoid ever delivering duplicate data to the receiver, even under massive losses. Thus total goodput stays close to link capacity way beyond the point where the network has effectively become useless for human users. The weakest part of the protocol is that lost SYN-ACKs cause duplicate SYNs. For bulk data I believe that modern TCP implementations avoid significant wasted capacity well beyond 50% packet loss (and average fair share window sizes less than 1!) This region is actually not very tested (so there could be bugs) or studied, because it is way beyond what users will tolerate. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Wed, Mar 6, 2013 at 6:49 AM, shun cai wrote: > 1. With fountain codes, for k original packets, infinite number of encoded > packets can be generated and the receiver can recover the k packets with any > k(1+ e) coded packets. > > 2. Suppose all flows are coded, and the short term packet arrival rate of > some flows exceeds the service rate of the network. Overflow and packet > loss could happen wheather the packet coded or not. > > My point is, I do not think the effective throughput will plunge with > coded flows , although the buffers are full. The network is in full swing > and the worst delay of a flow is the sum of the maximum queue time of the > routers along the path. > > I think there will not be a cliff in the throughput-load figure, insdead, > the curve will go beyond the Knee and reach a constant throughput. > > > > > > > > > 2013/3/6 Jon Crowcroft >> >> there's no free lunch - if the queue keeps being filled, you'll get >> increasing >> packet loss - to cover the loss, you'll need more redundency in your >> erasure >> coding - this will cost you more delay at source (in constructing more >> redundency) and more overhead in the net, which is a positive feedback >> loop, >> just like retransmitting a whole window into a congested queue/path - a >> "vicious cycle" as opposed to a virtuous one... >> >> so all that erasure codes buy you is delaying the point when you go over >> the >> clif >> >> In missive >> , shun >> cai >> typed: >> >> >>--f46d0444e84964e1a304d740bdcd >> >>Content-Type: text/plain; charset=ISO-8859-1 >> >> >> >>As discussed in chapter 1 of your PhD thesis, when network is >> congested, >> >>retransmission dominate the traffic and effective throughput diminshes >> >>rapidly, leading to a deteriorating situation. This can be illustrated >> in >> >>the well known figure with two turning points Knee and Cliff. >> >> >> >> >> >> I wonder, however, does the situation the same if rateless erasure >> >>code (say fountain codes) is used? As with erasure code, no ACK and >> >>retransmission is needed except when the whole file is completed. So >> even >> >>heavy loaded, the network is still busy with effective data packet, >> right? >> >>Although queueing delay will increase, I believe that the network >> >>throughput will not suffer the plunge as un-coded network. >> >> >> >> >> >> >> >>Kara >> >> >> >> >> >> >> >> >> >> >> >> >> >>2013/3/5 Srinivasan Keshav >> >> >> >>> To answer this question, I put together some slides for a >> presentation at >> >>> the IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we >> >>> always size a shared resource (such as a link or a router) smaller >> than the >> >>> sum of peak demands. This can result in transient or persistent >> overloads, >> >>> reducing user-perceived performance. Transient overloads are easily >> >>> relieved by a buffer, but persistent overload requires reductions of >> source >> >>> loads, which is the role of congestion control. Lacking congestion >> control, >> >>> or worse, with an inappropriate response to a performance problem >> (such as >> >>> by increasing the load), shared network resources are always >> overloaded >> >>> leading to delays, losses, and eventually collapse, where every >> packet that >> >>> is sent is a retransmission and no source makes progress. A more >> detailed >> >>> description can also be found in chapter 1 of my PhD thesis [2]. >> >>> >> >>> Incidentally, the distributed optimization approach that Jon >> mentioned is >> >>> described beautifully in [3]. >> >>> >> >>> hope this helps, >> >>> keshav >> >>> >> >>> [1] Congestion and Congestion Control, Presentation at IRTF ICCRG >> >>> Workshop, PFLDnet, 2007, Los Angeles (California), USA, February >> 2007. >> >>> >> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/congestion.pdf >> >>> >> >>> [2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, >> >>> published as UC Berkeley TR-654, September 1991 >> >>> >> http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesis/ch1.pdf >> >>> >> >>> [3] Palomar, Daniel P., and Mung Chiang. "A tutorial on decomposition >> >>> methods for network utility maximization." Selected Areas in >> >>> Communications, IEEE Journal on 24.8 (2006): 1439-1451. >> >>> http://www.princeton.edu/~chiangm/decomptutorial.pdf >> >>> >> >>> >> >>> >> >> >> >>--f46d0444e84964e1a304d740bdcd >> >>Content-Type: text/html; charset=ISO-8859-1 >> >>Content-Transfer-Encoding: quoted-printable >> >> >> >>As discussed in chapter 1 of your PhD thesis,=A0 when network is >> congested,= >> >> retransmission dominate the traffic and effective throughput diminshes >> rap= >> >>idly, leading to a deteriorating situation. This can be illustrated in >> the = >> >>well known figure with two turning points Knee and Cliff.
>> >>> src=3D"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOUAAAFECAIAAABXn= >> >> >>G6+AAAgAElEQVR4nOxdZ1xTydeOFfuqq7uL69rL7uqquy5WXFRELKiAWMDeUFEQUVERRVF6ryoq= >> >> >>IKxrowjSpKggSG9SBek9IQkhhYQkd94P82b+Q7CAFEXyfOAXbu69M3fy3DNnzjlzDqnP+0BI0H5= >> >> >>IRrKzIDaGJBJp5cqVNTU1AACSZJQ7C5KR7CxI+NodkIxkZ+G9fK2trZXwtQWEGAQCgUAgaP3tRy= >> >> >>7/NkYSPaZAIIAf0FMLRBAbB3gEP4iP4SfHrTUkfG0T0OByuVw+n99L+CoQCPh8PkEQfBHESCl2A= >> >> >>vpKIBDweDz4b3Nzc3NzM+I3n8+HfEWXtKtLEr5+GnB8ISn5fH5zczP8kQhM7n78Dj1xJOHDQkrx= >> >> >>eDxERz6fDwAgCAIxDw0OLjvhtTg18bFCQ9qZfO2SYeiZAAAAAOAQAxGINvO1JwJSkxDN9c3NzQK= >> >> >>BAA4CjUZjMBgEpg/gAwJPQ58J0SiBlkCtdKSTAICoqKi6ujoJX/8HGo2Wl5eXn59Po9EEAgGTyX= >> >> >>z79m1FRQWXyyXaoAz0UODCDypCAoGgtrY2Ojra2dnZy8vr3bt3DAaDx+NxudyKioq8vDwmk0kQB= >> >> >>IfDqa+vZ7FYUA3g8Xj5+fmxsbEFBQVMJpPBYBQVFZWWljY0NKBp6rMh4as4AAARERFbtmy5cOFC= >> >> >>QUEBl8t98uSJgYHBixcv2Gy22EriC/azK4DP8nw+Pz09/ezZs0eOHLly5YqRkZGBgYG5uXlcXBy= >> >> >>NRnvw4IGOjk5mZiYAoKSkxNXVNSwsjMViAQDKysqsrKz279+vrq7u5OTk4uJiaWlpaWn54sULXL= >> >> >>X9PEj4Kg4AgKen5+jRo/fs2VNcXJyWlnbq1CknJ6eysjIoHsD7gK79yBF08KsFUkYBAHV1dadOn= >> >> >>frzzz9dXFxqa2vz8vL09PR+++03KysrDodz9+7dJUuWvHjxAgBQVVXl5OT0+PHjpqYmNpvt5eWl= >> >> >>q6trY2OjoaGxatUqWVlZb2/ve/fuPX/+nMfj8Xg8CV87EwCAhISE5cuX79u3LyQkxMjIyMnJqbq= >> >> >>6GqlobDa7rq4OznRVVVVUKhWtJOh0ekVFRW1tbWNjI5RSLBarsrKSQqFwuVy0lIYrkq9TPCNDVW= >> >> >>ho6F9//bVp06aysjL4suXm5p4/f97R0ZHFYnl5eS1duvT58+cAAD6fX1VVVVdXRxBEUVHRvn37j= >> >> >>h8/XlRUlJ6efuDAgSVLlqSnp1OpVCqVCnXijnQP8pVMJkv4+v8AAJDJ5KNHj8rLy69fv37BggXB= >> >> >>wcFw9QAp+OLFiwMHDjg6Ot69e9fQ0NDa2jonJ0coFNbW1jo4OOjr6xsbG7u7u9fV1fH5fF9f3wM= >> >> >>HDty4cSMmJqaoqAgZfVpbLr8SwF41NTU5OjqOGTNmx44dVCoV2QdSU1OjoqIaGxu9vLzk5OSio6= >> >> >>MBANXV1f7+/ikpKQKBICEhQVZWdtGiRREREVlZWevWrfvtt98iIiLQ+rWDL6qEr+IAAFCp1OPHj= >> >> >>0+dOlVeXl5GRubKlSuVlZUEQUDd6/Hjx2PHjl28eLGXl9fjx481NTVv377NYrGioqJ2797t5ub2= >> >> >>33//7dmz5+XLl2VlZYcPH96xY8fTp0/t7e2dnZ1ra2uR9+Fr4yu+uudwOI6OjqNHj1ZXV6fRaIT= >> >> >>IIN3U1MRisbhcrru7u6ysbFRUFACgtLRUS0vL2tqayWS+ePFi0aJFsrKyMTExubm5W7ZsmT59+s= >> >> >>OHD6EagJtsPw8SvooDAPDu3btdu3Zt3LgxICDAwcFh8+bN7u7uVCqVIAihUBgQEPDnn38eOnSoq= >> >> >>KiosbHRwcHB1ta2qKjo2rVrGzduDA4OTkhIOH369L179169eqWmpmZmZpaXl+ft7W1kZJSVlfUZ= >> >> >>NsjuAb7YYrFYLi4uv/zyy/79+6ElC07ldDqdyWQKBAIvLy9FRcVXr14BAJqbm83Nzc3MzDgcTn5= >> >> >>+/vbt2/X19RsaGphMprW19fr161NTU6EfoeNakISv4gAAJCUlqaio6OnplZeX19fXGxkZrV279v= >> >> >>bt2zQaDQAQEhKydOnSCxcuUCiUxsZGZ2dnR0fH/Px8IyOjdevWPXz48M2bNyEhIenp6XFxcRoaG= >> >> >>hYWFtnZ2SkpKVFRUeXl5WhO/NrkKyFSXgEATU1N9+/fX7Bgwe7duysqKqA+QCaTb9++HR4ezuVy= >> >> >>fXx8Nm/eHB8fD9UkFxcXBwcHHo9XUVFx8OBBExOTpqYmDofj5OSkrq5eWFgI1dwOGgcIEV8pFIq= >> >> >>Er/8PAEBkZOTixYtVVVXT0tKamppcXV1/+umntWvXJiUlCYXCsLCw6dOna2hoFBcXl5eXX7hwwc= >> >> >>LCgkKh+Pv7q6qqenp6pqamPnjwoKqqKjc3d//+/RcvXszNzS0oKIiLiysvL29ubiYwj/zXA9wVw= >> >> >>ufzMzMztbS0ZGRkbG1tS0tLaTSav7+/mpra/fv3mUymq6vrokWLgoKChEJhUVHRoUOHzp8/39jY= >> >> >>mJOTs2HDBk1NTTKZXF1dffjwYRkZmeTkZEjr5ubmTrEPSPj6PwAAUlJSLl26ZGlpmZubS6fTfXx= >> >> >>8zp07Z2pqmpmZKRAIsrKyrl69evfuXQqFUlFR4eXlFRoayuFwKisr7e3tDQwMLC0tHR0dS0tLmU= >> >> >>xmaGiovr6+jY3Nf//9Fx0dTaPRkM3oa9MKcOcqFIfp6emHDx9WUlK6ePGiubm5tra2g4NDRUUFj= >> >> >>UYzNzeXk5Pz9PSsra319vZeuXLl8ePH3717Fx0draKioqGhER8fn56evm3btqVLlwYEBOCuWglf= >> >> >>OxlNTU319fX19fUcDofH49FoNAqFQiaTORwOQRBcLpdKpUI1rqmpiUqlNjY2QvJVVFS8fPkyMjI= >> >> >>yNzcXGs/ZbHZ8fHxoaGhKSgpUJ/BlzRd+zvcBiVjY1fz8/EePHp07d+7s2bOPHj2qqqoiCILJZL= >> >> >>5+/drX1zcjI4NCoSQmJvr4+ERGRlZVVRUXF4eEhDx9+jQ/P7+ysjIsLMzf3z8zMxOa8zo+q0j4+= >> >> >>h681yOADP4f+gz/JQgCuc7RCTD+A57zdWqu7wUyQlVUVFRWVsLAF7EICnz5iEx1YlFd+Equ412S= >> >> >>8LVzgMQSBBInOKFxNaCnsBaqB+ih4ISO/hVicS2Iu2IvMIEFf3VcvkZGRkr42gkQC7R771dI6ny= >> >> >>1Vi0x4EZTsadDXxEtdV+ipUDFz+8U+Srha0fR+pdAR3ASf+T8rxawq2J2/tYvHn5EjLUENggd7w= >> >> >>/ka319vYSvn4+P8LX1IqNTlh3dBriiR4RDxMUfWexxJHxtE74IAz4kKTt3EvyCENMHxPRvYcsVF= >> >> >>dJoCUwlaH3DjvTnG+Errtd3Pz/ErATEN8RX4qPMw0VsUVERtCGI6ayd25lvhK9oi5UQQ/c0LRAI= >> >> >>WCxWY2Njx4PneygAADwez8vLy8nJCe6s6rrx7/F8BQA0NDQkJSXBaL3ul2pNTU3Pnj3z8PCoqqr= >> >> >>q6aL08wAA4HK5BgYGGzduzM7OBqJ9b10xGt8CX7Oysk6fPv3o0SM2m02ItnF2WwdYLJaNjc3u3b= >> >> >>uzsrK+2kCWLgWUr66urjo6Om/fvgXYxsyuaKsH8xUOTUxMzOLFi3V1dSsrKwEAHQ8Cahe4XG5YW= >> >> >>Jirq2tJSUnPWvt3IoRCYVVV1bt371gsFtLHusLA3OP52tzcfP/+/QkTJqxYsSIpKan7XfNCoZDJ= >> >> >>ZFKp1KamJuKbWGB9HtCiE00yEr7+D8iAwmAw9PT0Bg0aNGfOnODgYB6PR3Q7X8UcsN3W9FcFJpN= >> >> >>Jo9HQqreLtLIexlc0ENAoCACoqalRVVUlkUiTJ0++c+cOVGG7kzQCgaCysvLt27eNjY3EVxnY2t= >> >> >>WAMjUwMNDJyamiooJo6art9LZ6GF/x3EwAgPj4eFlZWRKJNHbs2KtXr0LPcrf1BwDA4XD+/fdfm= >> >> >>Kygd4pYuN66dOnShg0bMjIyiK5c8vY8vuIaKpvNtrS0HDduHIlE6tOnz6ZNmzIzMyGPu6c/AAAW= >> >> >>i2Vqarpu3brU1NTuafRrA+SroaHh6tWr09LSJPbX/0FsILKystTV1SdPnjxy5Mhx48YtX74cWbW= >> >> >>6B5CvZmZmcFddt7X7VQHaXy9cuLBhwwa4tZBoGTnZuW31JL4SWIIxPp8fGRmppaWlqakpIyNz5M= >> >> >>iRS5cueXp6NjQ0dFtnIF9tbGy2bduWmpraO11ckK82NjaGhoZwA4LwfUlzO6utnsRXKF+RxaSoq= >> >> >>Cg+Pv7x48erV6++ceNGenr6mzdvmExmd2qQPB4vKSkpICCAQqH0Ns0VAsqOlJSU1NRU6GLsOqti= >> >> >>z+Mr0dJKIBQKX758qaCgcPv2bZiPreNJbz6jPwJRTkkCC75BaB0Qg04TiwvBbyIWudc6pge0zNK= >> >> >>FH8ebw0cDnibWf3Qy3kP8YGt86DjeSYl8FQccoOfPnysoKLi5ubHZbLHfo6uBzMBiwPVssd8S7R= >> >> >>iBp6EPAlHqanQynuFa7OZoUwp+PpqCAcZjoSjhdWuqvbfzxIeJ2PpMBoMB02g2NTVRKBSYfrT1C= >> >> >>HQiQE/nK0EQiK8sFovo9kDY5ubmysrK5OTkuLi4hISE2NjYhISEmpoa2I3q6ur4+Pjo6OiYmJjU= >> >> >>1FQqlcrn88lkcmpq6qtXr2JjY2NiYjIyMqDttr6+PikpKSYmJiYmJjY2FmbggscTExNfvnz54sW= >> >> >>LhIQEmCCIz+cXFxfHxcXFxMS8fPkyIyMDJmJpbGxMSUmBJ8fExMAYv+bmZjKZnJKS8urVq5iYmP= >> >> >>T0dCaTCYlVWVmZmJj46tWr+Pj4hISEgoKCwsLC5OTk+Pj4169fJ74P8PjLly9dXV3v3Lnz9OnTx= >> >> >>48fwx3w4eHhiYmJJSUl+ITTiZDwtaPgcDg+Pj7btm1TVFRcv379pk2b9uzZExERAXcwR0ZGHjhw= >> >> >>YNOmTRs3btTV1U1LSxMIBHFxcdra2ioqKioqKsrKypcvXy4qKmpqagoKCtqzZ4+KioqSktLevXt= >> >> >>fvnzJ4/EAAC9fvty7d6+ysvLGjRuPHj2alpYmFAo5HI63t7eGhsbGjRs3b95sYmJSUlICACgoKD= >> >> >>hx4oSqqqqKisqWLVtgCkEGg+Hu7q6mprZu3bpVq1apqqrevXuXTCYXFBRcunRpzZo1CgoKa9asW= >> >> >>bNmzdGjRzU1NVevXi0vL6+goLD6fVBQUFBUVJSTk5syZcrMmTMXLlz4559/jhkzZvz48UuXLlVS= >> >> >>UnJ1dYVzXaePtoSvnw9kA7a1tR01atTPP/+sqalpY2Nz8+bNnJwcmJ86IyPjxo0b9vb2tra2Xl5= >> >> >>eUPAUFBR4eHjY2dnZ2tra2Nj4+fnV1tZyOJz4+HgXFxd7e3tLS0sXF5c3b97ALdTZ2dk3btyws7= >> >> >>OztrZ2d3cvLS0VCAQ8Hg9mvrazs4M3gVmlqFTq/fv37ezsLCwsrK2tk5OTqVRqQkLClStX5s2bJ= >> >> >>yUl1bdvXykpqblz52pqampoaIwfP56EYejQocOHDx84cKCUlNSgQYMGfhgDBgwYOXLk5MmTJ0yY= >> >> >>MH78+AEDBkAr+MCBA3V0dGD6hU4fcwlfO9oBFotlaWk5atQoVVXV3NxcqCwiLxePx2tqaoI51Ju= >> >> >>ampB7HR3kcrnQYycUCtERLpfL4XBg5iKCIGBiDg6H09TUBG8C9Vd4c3hn2JnGxkYKhVJYWBgWFu= >> >> >>bl5eXp6enu7m5kZKSqqrps2TIxakL06dPnu++++/7770ePHj1y5Mgff/xxyZIlW7du3bJly9atW= >> >> >>7dt27alFTZv3qymprZ161Z9ff3r1687Ozvb29svWLAA3VBHRwfqG10x4BK+dqgD0Mc2d+5cd3d3= >> >> >>OH2jpQ9u1sFXS0SrNQ2Bxc20Pv7er3A0Njbm5ubGx8fb2dnp6+sfO3Zs9erVv/7667Rp0yZNmjR= >> >> >>y5EicoIMHD54xY8acOXPmzJkze/bs9evXGxoampubm5iYmJiY2Nvbh4aGZmdnZ2Vl5eTk5Ofn53= >> >> >>4YFRUVMG8zhUIxNTX99ddf+/fv37dv35MnT3aR10bC17YCNy3hHWAwGBYWFocPH87NzRW2THYCP= >> >> >>+PlkAjMGiVsmQpFzLQstuUfJ3pDQ0NWVhbMfxgYGHj//v2LFy+uXr160aJF48aNGzZs2KBBg4YN= >> >> >>GzZx4sTffvvtt99++/XXX2VkZNauXausrKyioqKrq3v//v1nz56Fh4eHh4enpKTU1NQwGAwmk9n= >> >> >>Y2AhzK3389XgvCgsL3dzcZGVlBw4cuGfPnrKyMok9SxzdzFeBQIAHg8MPNBrNz88vKioKtt4uCD= >> >> >>BAXkJyo+gzBKj1BgYGPnjwwMLCQllZGRJ0ypQpP/3008iRI6WkpIYOHbpkyZItW7aoqqoePXr0z= >> >> >>p07/v7+AQEBT548iYyMzM7OLisrKy0thboyNBog1eUzCApamZMpFIqBgcGwYcP+/vvv8PBwiT1L= >> >> >>HN3JV4Ig8BJq6CCPx6NQKHhcfRvvhstXeGc81Q8El8utrq7Ozs728PBQV1efNWuWtLT0999/P2D= >> >> >>AgL59+w4ePFhaWnrq1KkbN240NDS0tbWNiYkpLCwsKCioqKiApESatBj738u5z4ZQKGxoaKivrz= >> >> >>czMxs5cuSECRO8vb2FXRB4JOFrOwAnOChlCZHGKRQK3759Gx8fT6fT2xVMKKYDIAI1NTXR6fSSk= >> >> >>pKoqChPT089PT0lJaXp06f369cPCtGpU6euW7dOWVn52LFjd+7cCQgIyMzMbGxsbGpqEqM77rMQ= >> >> >>e5D2vl0fAQCAx+M9efLE29v73LlzI0eOHD9+vKenp0S+iqOb9QEc8Cfncrk1NTUuLi7Hjx/Pzs5= >> >> >>u7w3RB0gvCoWSnp7u4eFhZGR06NChv/766+effx48eDBcJ02dOvXo0aNXrlxxd3dPTU2Fyx1Ywo= >> >> >>5o6eUS6zCub3RFeC6cB4yNjVVVVffu3Qtj5Tw8PDq3FdSWhK/tBpxnWSxWRESEn5+fvr7+xo0bU= >> >> >>1JS2kgIXATy+fyGhobc3FwfHx9dXd1Vq1ZNmTJl2LBhQ4YMkZKSmjhx4ooVKxQVFTU0NDw8PAoL= >> >> >>C+HaCN0EDQJOU6KV+x5f5Il96DiAKF572bJlmzdvHjVq1IQJE9zd3aETuFOawNuS8LUdEIqCO4V= >> >> >>CYVxc3MmTJz09PS9evKikpATdTh/nK85UDocTGxvr5uYGL58wYcKgQYNIJNLo0aOXLVu2ZcsWPT= >> >> >>09b2/vnJyc0tLSmpoaNpuNZ2BFVBBieatbzwBES0HeRXyF8a+rVq06derUjBkzJk6cCPnaKfcXa= >> >> >>0vC1zYBkQCSpqGhwcTEZP/+/YmJifb29hoaGhkZGWKEIDBa4OppWVkZrPG5dOlSaWnpESNG9OvX= >> >> >>T1paevv27efOnXNycoqNjS0pKamvr29qamq9Hhd7wNZ0xPHeEzprNOBnyFdXV1c7O7tnz57BKcL= >> >> >>Dw0NizxJHd/IVeZXg3/j4eA0NDUdHx7q6utDQUB8fHyqVKhTZvPANTFAW8ng8Mpn8+vVrb2/vY8= >> >> >>eOzZw5c8CAAQMHDpw2bdry5ctVVFRcXV0LCwvZbHZTU1Onr987Hejthf/C/Fl1dXXv3r3bsGHD5= >> >> >>MmTJfrre9DN8hUZs4RC4Zs3b9zc3GBOl4aGBhaLhWZk6CbFxWpBQYGjo+OJEydWrlw5derUgQMH= >> >> >>Dho0aMaMGbt37/b09ExLS8vJycG1UoClXe9S9ebzICa5oSkXdru4uFhZWXnatGkeHh5d0XMJX9s= >> >> >>K3AYEtU8ajQaDWpBAhWzGg01LS0uDgoL2798vLS09aNCgvn37Tpw4cdWqVQYGBv7+/nAXOFowiS= >> >> >>3ku+IpOhG4fiwQCKqqquh0ekFBwYYNG6ZMmXL9+nXone7cRiV8bSuQUOHxeAwGA0pQoVDI5XJfv= >> >> >>37t7+9PJpMRm2Fwqr+//8GDBydNmtSvX7++ffvOnDlz+/btDx48KCsra2hogHowgb0JkPqtDVJd= >> >> >>8TgdhFC0jwM+L51Ot7CwcHJySkxMVFJS+vHHH83NzblcroSvLdD9+kBzc3Nubu7NmzdhsJ9AIGA= >> >> >>ymXZ2dhoaGpmZmVCmvnv3ztHRcceOHbNmzRowYMCQIUNkZGTOnTvn5+dXVFTE4XBwWyl08CIvF0= >> >> >>7Qr5avQmw7IeRrYmKivLz8xo0bg4KCVFRU+vXrd/LkSbhY7NymJXxtB4RCYVNT05MnT86ePfvmz= >> >> >>Rv4U8H93Bs3bkxLS6uvr4+NjT127BgMiRoyZMicOXMuXLgQExODdkGK2aGQq0z4AVvYV0hZXH+F= >> >> >>gxAQEDBjxgx5efmAgIDNmzf369fvxIkTEr6Ko5vlK0EQFArl33//DQkJaWhogFRjs9lWVlbr1q1= >> >> >>zdXU9d+6cnJzc0KFDBw0aNG7cuJ07dwYFBdXV1aGu4n1rYz+/Qr4SLe0DAICMjAwFBYVly5YFBg= >> >> >>Zu3ry5b9++Ojo6XbHFQMLXdkAoFMbGxl67dq2oqIgQebm4XK6dnd306dNnzpw5dOhQEok0bdq08= >> >> >>+fP+/n5ZWdnw7VXV3hBvyzEFoUsFsva2lpbWzssLExZWbl///7a2tpdscVAwtd2tMXn8589e+bg= >> >> >>4FBVVYWsTkVFRUePHoVe/vHjx+/cufPp06cwUx/aOPD1L/bbBTF7FnwbqVRqfX09rHc8cOBAbW1= >> >> >>tiXwVRzfzVSgUlpeX5+fnw5Uvl8uNjIzU1NScOHHid999t3DhQmtr69LSUmTnF2IRg13RpS8F3J= >> >> >>KF1G5kv1NWVu7bt++JEyfgyrJzm5bwta0QCoUweQn0qSYkJNja2q5YsaJ///5SUlK7du16/vw5l= >> >> >>UrFL0FM/Sb1AZQbAa4aKysrGxoaioqKoH1AV1dXIl/F0W18BQAUFhYGBgbC/FCRkZHr1q0bNmxY= >> >> >>//79f/vtt8WLF3t7e8PlMF5dTYhtaPn2+IrsWUKhMD8/X19f393dPS0tTVVVtX///hK+vgfdw1c= >> >> >>49d+7d8/JySk/Pz8wMHDlypX9+vUbMWKEkpKSh4eHtbV1aGgoXF4IW+Lbk6wEpr8i+0BMTIyCgs= >> >> >>KVK1cSEhKUlZUHDBigo6Mj0QfEAXWm58+fy8vL37x5E/K14xTB5SL8NzU19dy5c3fu3LGwsJg5c= >> >> >>yZcWllbW5eVldXU1Li5uQUFBcEcLUS3J+z4IoCDg5Jo02i0M2fOqKurh4aGqqurS0lJ6erqSvxb= >> >> >>4kB8Xbly5Y0bN9Ce944zBm2ogtqqq6vr7t27NTU1p06dKiUl9ffffzs6OtJoNABARUXF2bNnHz9= >> >> >>+zOFwvklp2hr41AG3slEoFC0tLXl5+bi4uFu3bv300087duyA5Xo6t+kez1eCIOLi4g4fPhwaGs= >> >> >>rlcsUqSX82kA5aWlp6+/ZtBQWFH3/8cfjw4X369FFUVHz+/DnKbVZUVKSjo/PgwQPI12/MFPBe4= >> >> >>Bo5HITCwsJdu3adPn2aQqEkJCRMmjRp8uTJT58+RaaSzkKP5yubzfb09Lx8+XJJSQkhypzfwfUN= >> >> >>ol1NTY2RkdHEiRP79+9PIpEGDRq0bdu26Oho5P0nCKKhoSEmJgYauXAt4psHrsKyWKy4uDhYLC4= >> >> >>+Ph5u6XFzcyPel120I+jxfKXRaPr6+np6etCGj6KqO3JboSgO68aNG5MmTerbty8MBjh48GBubi= >> >> >>4yAoiZHr9VU0Br4KvJ1vvFExISpk6dOnr0aE9PT0LCVxwAACaTeevWratXr0JDvRDbzPTZt4U3o= >> >> >>VAohw4dgpJ12LBh+/fvz8vLA1gEIAx7bW5uZjKZHA7nGzYItAZiKvzb1NSUl5dXXV2N+DpixAi4= >> >> >>xaBb+SoUZY7+CMQsOPi1QswLgr4SOy7WHP5tW3rPZDJdXFyMjIxKSkrQ5W3nK66HIcLB49HR0cu= >> >> >>XL+/Xrx+JRFq8eHFERASuBkCmEgRBo9ECAgLS0tJgPGiv0l/R9JKRkaGtrR0eHg4AiIuLmzRp0n= >> >> >>ffffcF5KtAIOBhaG5uRh+QpOHxePhGEfTa4YH3+FyJTkCsEn4Abek9lUo1MDA4ffp0aWkpgZmi2= >> >> >>vj86Hzo6+fz+TAqnkwmnzt37ocffiCRSBMnTnRwcIBjhF8If6qysrLTp0/7+PigUnW9Qb4KsexM= >> >> >>AABfX98lS5b4+fkBAHJzc+Xl5b///nt3d3dhZ6d4+bQ+UF9ff+PGDWNjYysrq3PnzhkbG5uZmV2= >> >> >>5cuX58+cVFRUhISEpKSko1Bz9xX9+IeZGF4iynkOWE60seUR7OAcAqKur271796FDhyoqKpA+0K= >> >> >>4hwF8klGolKioKlqEjkUg7d+6EyvF7O1BaWqqnpwftWaArS099VcBlEADAx8dnyZIl/v7+AAAOh= >> >> >>3Pt2rXvvvtOS0sLjlsnDsin5Wt4ePjatWtPnTp1/vx5aWlpVVXVa9euLV26dM+ePc+ePTt37ty/= >> >> >>//6L7zQXirRvvJeQ0PAnR/MmZDPuhhablNvS+7q6uj179hw5cgRV0mnvEKAXBoVTUSgUfX390aN= >> >> >>H9+vXb/bs2Q8fPvzQViQAQHFx8alTpx49eoT7t9rbh54FsdkSAPD06dPVq1cHBgZCfcnR0XHIkC= >> >> >>GLFy9OTk7uPr4CABgMxuXLl3fu3Jmdnf3s2bPff//94sWL7969O3PmzIYNGwICAgwMDDw8PCgUC= >> >> >>sweBQCAdETGHaQtEATBZDIbGhoQL3EGtFaF29h7Mpm8f//+w4cPQ/kKj7drgISilZNQtNvTx8dn= >> >> >>8uTJJBJp2bJlAQEBHymQBACoqqpydXWNjo7mcDhtb7RHAxcu8EhVVZWHh0dycjJBEDwez9bWdsi= >> >> >>QIbKysikpKd3K14aGBnt7++vXrzc2NoaGhv7+++8GBgZVVVW3b98+ceJEZGTkqVOnjh496u3t/f= >> >> >>Tp0/T0dLgHv7a2Njg4GBaTCAoKqqqqgvvvnj17FhYWVllZCYUrlUotLy9ns9nNzc3V1dW1tbVoM= >> >> >>1Pb9de6urq9e/cifaC9Kx5cz4bvW1lZ2aFDh/r16zdmzBhnZ2foVPxQfwAALBYrLy+vtxXfwidD= >> >> >>qPLBnOAEQfD5fBsbm0GDBi1dujQpKalb9YGmpqaSkhJYRDgkJGTBggXm5uZUKrnPbZ0AACAASUR= >> >> >>BVLW0tDQ1NTUrK0tTU3POnDmmpqYeHh66urqBgYEsFiswMFBeXn779u2nTp1SUVF58OBBTEzMtW= >> >> >>vX7t69e+fOHTMzs7y8PB6P9/DhQ0NDw8LCQgqF4uLicvPmzdraWtStNvYeyVfo/RN77z8JpLPCC= >> >> >>7lcrpeX18yZM7///vsjR47k5OQQoti5D92z9VzRGyDEjK8CUdQLyidiZWU1ePDgZcuWdas+gM6A= >> >> >>CAkJWb16tYeHB3Q8AgDKy8uPHj2qoKDw/Pnz2NhYeXl5BwcHBoNx+/btCRMmKCoq+vr6ent7BwY= >> >> >>GXrhwQU1NLSEhITIyUlFR8fbt2wwGw8TEZOXKlenp6dXV1ceOHTt58iSsJIH02o88J9L0yWTyvn= >> >> >>37Dh48WFZWhoamvfYBgShUoL6+/vjx41JSUrKyslFRUTD7n1iCbDE0NzdDP3DvKcaJ1qboSGNjY= >> >> >>1RUVEFBAUEQfD7fzs5u0KBBy5Ytg+WP8ZV0B7n7afsrOi8kJGTt2rX37t1DCXNKS0vPnTtnampK= >> >> >>o9FSUlLk5eUdHR0ZDIabm9tvv/125swZeN/IyMj169efPHmyvLy8qKho3759xsbGVCrV1NR0xYo= >> >> >>VaWlpVVVVx44d09PTKy0thQWrUlNToYP+40OG1luHDx9G/oJ2DQqUB0gZyM/PX7du3ejRow0NDW= >> >> >>ENLSG20f69d6DT6c+fPy8qKuptfEXjDAB49erV9u3b0XrL2dl5+PDhy5YtS09PB1g1h27l65MnT= >> >> >>xQUFP79919ogiUIoqCg4OzZsw8ePAAApKSkrF692snJicVi3bx5c8mSJb6+vlAEhoeHq6mpwYjm= >> >> >>jIyMHTt2WFpa0un0q1evrly58s2bN4WFhXv27NHV1S0qKioqKvL19Q0NDa2rq2v9bGJ0BADU1tb= >> >> >>u27fv9OnT5eXlrU9oC5BwpdForq6u48ePX7BgwcuXL8XG90P6a2VlpYWFRWRkJMqg0XsUWaj6Q3= >> >> >>vWokWL/Pz8CIIQCoVBQUHz5s1btmwZ1F/F7D8dafHTfIUv07t37wwMDBYvXgz5CrXssLAwVVVVd= >> >> >>3d3Ho/37NmzJUuWGBsbl5eXW1paLly40NfXF/HAwcHBwsLi+fPnBgYGcnJyvr6+bDbbxcVFUVHR= >> >> >>39//8ePHK1eu1NbWLisr43A4dXV1FAoFpaD6eO/r6upOnDhhampKJpOJ9s848HyogURFRcnJyQ0= >> >> >>ePPjIkSP43T5SkFYoFObk5Njb28fHx8PVRi/hK673AwD8/f2XLl0K7a8AgLdv327btk1GRiYiIg= >> >> >>LNTsKWVvbPw6f5Clchr1690tHROXTo0IsXL6BWx+PxAgMDjx8//uzZMyaTGRgYuHfvXjs7u+TkZ= >> >> >>BcXl/379//3338oOVRqaqqFhYWJiYmWlpaxsXFhYaFAIEhLS7t8+bKdnZ2Tk5Ourq6bmxtM6YNs= >> >> >>W+/tj1DkPoUjRSaTtbW1r1y5Ul9fT7Q/WBvpwTU1NefPn//uu++mT59+7949+Iwfj/aCxruEhIR= >> >> >>Hjx7V1NQgEdL21nsu8GGBPtht27YFBwfD366kpGTnzp0///yzra0tlUpFfhxhe1zl78Wn+Qpnfx= >> >> >>qN9vbt2+LiYjqdjgz+ZDL53bt3dDqdy+VWVVXl5uaWl5fX19eXl5fDkg9QbYCMLysry87Ofvv2b= >> >> >>V1dHfxRuVwu3G4K1YC6ujoouYUf9m+15iuFQjl//rybmxvMSPXZwxEfHy8rKztkyJAjR44UFxcL= >> >> >>Wu4T/NA9BQJBVVVVXl4erL7ZnaXBvyzEfiMGgxEeHp6fn08QBOSrhobGpEmTrl+/3tDQALBCYl3= >> >> >>OVwGW1wm+PUi8w3/R0hjJRdxuj0MgCp0hROlUQUugpfqHHgm/GzxSVVUFq05+nOgfAryKx+N5eX= >> >> >>mNHz9+3LhxDx8+RI4u/JyPXN4pQbc9CIgVgpY1baBvCADw7t07DQ2N2bNno20X6KoONv0JvuIGN= >> >> >>ry7hGjHCGi5/wRJI1xrQUwisGT7iFg4UwmCgEWh2shXgUAQHx9vYGCQlZVFtG2xJTZlw5MrKyuP= >> >> >>HTs2ePBgGRkZmNad+LBMbT2Cn/eq9Fygx0R85fF4LBYLTjKQrzt37hw7duzVq1fFPCkdHKJP219= >> >> >>bA1/uoYz6+Goa/cWZKtZjMSrjnz/5wyOiC4VCPz8/PT293Nxc9NWHlEj8/vjz19fXu7m5ycnJyc= >> >> >>nJ3bx5k8FgtN3439zcXFRUlJeXh4pdtfHCHg1cXhAEAQnq6+sL0zQRBFFZWamnpzdt2jRDQ0NYh= >> >> >>ZlomzT5JNrEV5xGYjMgi8WiUqlI5hOtRGBr2YN/hX5j3HT6yR8engYvcXFx2b17d3Z2tpgS8qGr= >> >> >>Wj9UaGjowoULpaWlL168WF1d3XYzKgCgsbHx1q1bjo6O0J7QSyAmmKBtXlVVNTQ0lCAIgUBAo9H= >> >> >>Onz//008/nTlzBvosO4WsRBvtWUQrcYi+zcrKunfv3tu3b99L0zZCIBCgctSffDD0LVSdTU1NN2= >> >> >>zYAO3SYn345OMQBFFfX3/58uURI0ZMmjTp/v37KEynjWPHYDBMTU2NjY1hEkLiw2/LNwZEAyg4H= >> >> >>j9+/Pfff8P4V6FQyOfzzc3NhwwZsmnTpoyMDFzSdbDdNumvRKvIf6FIxY6KitLS0goJCYEKK55x= >> >> >>F6ejsJVwRfOyUChsaGjIycmpq6sDIh/0h55N2FLx4PP5FhYWKioq6enpeEMf4auYMpCdnb1ly5Z= >> >> >>+/fqtWrUqPT1dIGiHDwby1dLS0traGmYiEvYaLRb/laG/YOHChdBfAGFnZzdw4MApU6Y8efLkve= >> >> >>WePw9t1V9RG2jPNIfD4fF4z58/37Fjx61bt+Def7R4QnYA9AEJxdYoLCz09vbOyMjA9/F9RAcVi= >> >> >>ra98/l8a2trFRWVtLQ0dMJHjKA4nwAAbDbb29v7119/HT58+MWLF+vr64XtWcMCAFgsVkBAQGho= >> >> >>KEyW0XvIii/EAQCxsbEnT5589eoVOgj5OmLEiLt370KzJrq2O/gKAOByuQUFBbACeU5Ojq+v78u= >> >> >>XLxMTEw8ePHjx4sXk5OS3b9/W1NTAUJX6+vri4uJ3797l5+cXFxdD4yiNRisrK6PRaDwer66urq= >> >> >>ysDNZACw4O1tbW9vX1pdFoH2cMEthovIKCgo4dO4bXvvoIXwmM8QCA2tpaPT29oUOHysrKRkdHo= >> >> >>0CCtg9fc3MzhUJhMBhiJrBvG0LRGgM9b0NDQ3FxcWNjI4oNCg4OnjVr1qhRo7y8vKDdAF3bkabb= >> >> >>ut4iCCItLe3s2bPXrl2zt7c/fPjwzp077969m5OTc+DAAVlZWbhh5uLFi/B29+/fP3LkiK6urrW= >> >> >>1tbGxsb+/f2NjY0pKyuXLl//777+6ujp/f//Lly8nJSXR6XQ3N7d169Zdu3atoKAAOSM+IiPRMw= >> >> >>MAKioqrKys0FT+kUcV00kAAG/fvt2yZYuUlJSOjg5cMH2c6x8aQYDFhfUGyoqpXoKWZnX4b1VVl= >> >> >>Zqa2vfff//w4UPI105Rlj693oI/IYVCMTY2Xrhwoaur6+3bt2fNmqWkpPT69evy8vL9+/cvXLjw= >> >> >>zp077u7uioqKZ8+eLS4u9vDw+OOPPzZt2vTw4UN9ff1jx47l5uampqauX7/+1KlT1dXV//3337p= >> >> >>16x48eMBkMv38/Pbu3evt7Q29mm1/MAAAlUp1cnLC9YGPKK+4iZsgiNDQUFhT2M3NDYYrtFe+8v= >> >> >>l8uFLE7Sdtv7yHApGPEL3hLBYrPj4ebvmEJk46nb5r167vvvvO0dER6ordx1cAQHl5+YkTJ/744= >> >> >>w9PT08fH5/Zs2erq6sXFxdXVVXt27dvz5490Fu7d+/egwcPlpSUZGRkbNiwwdDQsLKy8vbt2xs3= >> >> >>bnzx4kVhYaGampqurm5dXV1ISMiGDRsePXrU3NwcERGhp6cXFxcHpxJhm7120Hrq6OjYFr4Solh= >> >> >>VOMRUKtXIyOjHH3/csGFDamoqWsC1a73FZrMjIyNfv36NUs31EhMshEAUq56cnHz48OGwsDAgcn= >> >> >>CSyeQdO3b069dPTU0NbV1u1/LgvWiTPUsoFMLtADDGMSIiwtDQMDg4mMlk1tbWnjlz5tq1axQKh= >> >> >>Uwma2lpwa0phYWFW7ZsMTMzY7PZDx8+lJeXDw0NLSgoUFNTO3nyJIPBiIqKUlZWhovH8PDwM2fO= >> >> >>wFh0AvNHtKX37eKrQFTgisvlPnjwYO7cufPmzfPy8oI7tNC1bedrQ0ODtbU1jOogsJqdbbm8RwM= >> >> >>fLgCAv7+/rKysr68vsoJTKJTdu3eTSKR58+bl5OSATtpl0FZ9AAAQERFhYmKSkpLy5s2bnJwcuB= >> >> >>00JyfnyJEjNjY2dDq9rKxs7969u3btqqioKC4uVlNTu3DhQmFh4Y0bNxQUFKKiooqLi7dv366lp= >> >> >>QXdIcuWLTtz5kxNTc2LFy9OnToVGhpaXFycl5dHo9Ha3vt28RV9W1paum3btuHDhx88eBAGegtE= >> >> >>e9DbPqyQrxYWFqampvX19ehl6A18xZUfAICvr6+srOyTJ0+QFZxKpe7atYtEIv3xxx/Qm9MpKtO= >> >> >>n+YoCGmDYtbq6uoaGxqFDhwICAthsdlJS0oEDBywsLOrq6tLS0vbt23f48OG8vDxYl3HFihUaGh= >> >> >>pr1qy5ePFiRUUFi8Xy9PRUUVHZuXOnqqqqtLT0X3/9lZqaWlRUdOnSpY0bNx4+fDgyMpLJZLZx1= >> >> >>mgXX9F8JBAI7t69O2nSpGHDhp0/fx4lccdlRhtbZzAY5ubmV65cgZGQ7VInejqQug9E8a8+Pj5I= >> >> >>vjY0NOjp6Q0cOBDxVYjhsxttR/wALK20ffv2rVu3zp8/f+vWrbm5uQwGIzc3t7i4mM1mk8nk5OT= >> >> >>kzMxMGo2Wn5+vqqqqqqp69OjRK1euwDRpUA338PDQ1tY2NjbW09MzMDAoKSkRCARxcXGnTp06e/= >> >> >>ZsQUFB25+qXXwViILhORyOvr6+lJTU5MmTPT09PzvOGvpj7e3tLSwsoJe89ygDuMsK6q+HDh0KD= >> >> >>Q1F+ivcFj916tTZs2fDX7879AFC5MCorKzU19fX0dFJTEyMiIhQV1eXl5dPTU1FNn+ipS8ARpgb= >> >> >>GxtDKiO9ENpx6+vrmUwmjUarr69HFaoaGhqoVCpuq2tL7ykUioODQ2ZmJvEpASkUrR3T0tLWrVs= >> >> >>3YMCAzZs3wx2wnwf4LGlpaWlpaTDfW+/hq9hjslistLS08vJyJEcBANHR0X/88cecOXPy8/NB+7= >> >> >>fWvRdtWm8BAEpLS83MzPbu3WtjY3Ps2LFVq1adO3eurKwMnibAAACA22NUVVWtrKxgeDnAInRa+= >> >> >>7eIllxvV+9by9cPnQxbp9Pp9vb2EyZMGDx48JkzZ+BW9ba3KAakreJZaj77bj0IiHnIRABaBmEB= >> >> >>AKKiombNmgVdsk1NTURn2E/atN4iCILP5zOZzJiYGFdXV0dHx5CQkLq6OhirCi2aeF43JpMZHR3= >> >> >>t4eGRlJQEs6ARHXZsfKj3FArF0tIyMjIS7U340Mnwq8zMTFVV1QEDBvz666+PHj3qeE0I3KDbe0= >> >> >>IK0ZPCX5xOp+fn5+PuSQDAy5cv//rrr4EDBx47dgzmzu8OvsJshELRShA63JAsFLbcgIDEjFi8N= >> >> >>tF5EWViva+rqzM0NHz06BGTySQ+FT8gEAiePn06b948KSmpAwcOwPmrIx1obm7Ozs7OyMhAtXt6= >> >> >>iT6Au3UgNXV0dF68eIFOAABkZWWpqqoOHjx4165dkGEdH5xP8BXJTpQODUl+ARZVKBZUhb5CJgx= >> >> >>0Zqfztb6+3sbG5sWLFyjn3IdaAQCQyeTz58+PGTNm3rx5T58+hZsKO9I6k8m8ffv2jRs3YBR9Lz= >> >> >>FmEe+zv65cuRLu4EcH6XS6iYnJhAkTUO2NLpevAixaSiDasgP7hL7iYxXSCMzMgV/VRTucAAA0G= >> >> >>u3ff/8tLCwEn/L4CQSCly9fbtiwYdmyZTdu3KDT6UTHxCG0D1y/fh3erfc4C4iW+bMgh9TV1Z8/= >> >> >>f05gOj2Xy/X29paVld26dWtsbKyYM/zz8Gl9AP1FIpbAdpwJMRCYvoueB2f5Z/dSrEu4Uk+lUt3= >> >> >>c3PLy8sS+xf8lRLZ9ExMTaWnpLVu2wP1eRGfw1dnZ2d7eHu0m7w36q5jZHwAQHBy8YcOGkJAQfN= >> >> >>XF4XCcnZ0nT548Y8aMW7duIbthR5r+tD0LoTUPWreNE1eMyp0CIWb5g8woKSm5evVqXFwc8k7hL= >> >> >>eLr95SUlG3bto0aNUpLS6u0tLTjHQMAsNnsp0+fPnnyBO5aFnbYP94jILYygfbXK1euoOyZEDAl= >> >> >>irS09NixY52dnWG90u7j69cA/H0gCILP58fHxx85cuTBgwcwYlpM2BMi3Z9KpcJ8y/PmzXv48GF= >> >> >>nVULk8/kUCoVCoaBInd7AVwghpn2h+FchVhagubk5NjZ2yZIl48aNc3Bw6JRysj2MrxA4KfPy8g= >> >> >>wMDGAuQZx8cLzgZ+i/kJWVHThwoJ6eHtT9O0v2wwUoztdOnE++ciCpIRAIeDwejMnE9dq6ujo1N= >> >> >>bXRo0efOHGisrKy4y32VL4SIsFJJpMdHByys7OJljxGNjWCIPh8/oMHDyZOnDh16tTg4GBc+nYE= >> >> >>kKbV1dU1NTW9KnIAAtfKKBRKcHAw2lWP7Fx0On3Pnj39+/dfuXIlDNrsXfoABM5X6C+Iiop6r00= >> >> >>NDlxVVdXRo0eHDBkiLy8PLQm4oeOzuwEAYLFYjx8/fvToUUNDQ+9RBvB1AvRoxsbG7tq1C8a/El= >> >> >>heAjabbWZmNmLEiPnz579+/ZrozvXW1wO0DId8NTc3h3nwCGw4EHW4XC7MDD5ixAhdXV1kKBWzD= >> >> >>X8GAAAMBsPa2trU1BRu7u0lIha3XRKieMKlS5cGBASIeWUJgoiIiJg0aZKMjEx8fHzHm+6pfEUa= >> >> >>Un19vbOzs1i8CxKxAICqqqrTp0+PHDly3rx50JHdWaxCfDUxMYHxWb1HeUUrKkLkL0D1twjMmgk= >> >> >>ASEtLmzp16ty5cyMjIztFB+t5fEVAfE1PTyfel6SDIIhnz54tWLBg0KBB2trasNQH0UleU2jTdX= >> >> >>R0tLS0pFAonXXbngI0yACAuLi43bt34/oA+grydfz48d7e3qjM4Gejx/MVxhNmZGTAI4gxQtGO7= >> >> >>VOnTg0bNmz27NkwqUfnts7hcKKiogICAhgMhrAz8vH2FIipBDQaLTw8HNYvwL8FAOTl5S1atOj7= >> >> >>7793cXHpFB2sZ/MV2gfevHkjJlYJghAKhc+ePfvzzz8HDBiACh51bgeEQmFDQ0N1dTWMDus9fEV= >> >> >>PilaZKFgPX3dCk5auru748eOdnJw67uns8XylUCjOzs5v3ryBRxBfoTEF5saaMmWKh4cH2lUsdu= >> >> >>ZnAxIU2l9x/3Pv0QrQwpfH4zGZTBTSKcQMOFwu18XFZcyYMZqamu/eveuN9gEEyFcbG5vo6GjcH= >> >> >>wu/yszMVFJSGjhwoKKiYnx8PD5/EZ0ULMbn8+l0Oira2PF4jh4BNJLISpOfn+/h4YHKleF8hbmg= >> >> >>paWllyxZggIOPxs9nq9kMtnIyAi6WHGiAAACAwOnTp06fPhwWD2mc5lKiOyL/v7+Pj4+DAaD6DX= >> >> >>rLTiAaD6B8S5KSkoo3oXAEvYLBIKkpCQlJaX58+cHBQVJ5CvFwsIiPDwcr+UJAGhubnZ2dh41at= >> >> >>ScOXP8/f3x3QedyFe4n/vatWsoK29vAL5UgEt+X1/fRYsWQfsrPI6iKwEA1dXVR44cmTBhgr29P= >> >> >>dTKPrvpHs9XMpl87dq1gIAAVLxUKNogqaGhMXTo0CNHjsB9Zp2uWUK+WlpampmZiWWR7sRWvlrg= >> >> >>Xhs/P7/Fixej/K+4HQBaaWC6fVhGvVfzlUKhXLly5fHjxyjkiiAIDofj5eU1efLkuXPnBgQEwBx= >> >> >>Ena5ZQr6amZmZmJhA/xbRO/iKNAHE17CwsK1bt4aHh+NOPiSD2Ww2LMSnoqKSl5fX2/lqZ2eXkp= >> >> >>IiwGqVZGVlqampjR079vTp06isZlfIVxaL9ejRo//++49Op/ce/xYe/wopW1paGhQUBEv44qchL= >> >> >>TYmJuavv/6aMWNGQECAQFSm5TPwLfDVwcEB5teGXGlsbLSzs5swYcLMmTMfP34M9drO3eOA0Nzc= >> >> >>XF1dXVVVhSqN9Qa+Eti+TqSqouNESwMClCCJiYlLliwZNmzYzZs3O+Ll6vF8Fcs/QBBEYWHhpk2= >> >> >>bSCSSnJxcamoqHDJYo7lzW0erY9BrdsYiIOEqEO3Pa2xshElDiJZRR3CIcnJylJSUhgwZYm5uDi= >> >> >>PrPw89nq9kMtnR0RH6twiC4PP5fn5+v/32m5SU1KlTp2DRZBiZ0fbCL21vHdYzKiwshPkgehVlC= >> >> >>azoX2Vlpbu7e0ZGRmvBCflaXV29d+/efv36KSsrFxUV9V75ivMVqgcnT54cNmzYr7/+GhAQgKbp= >> >> >>rvCUAgCYTObdu3fv3LkD09j0Hn0Af1IAQFRUlKqq6tOnTwG2iU0o2m1KEERjY6ODg8PPP//8+++= >> >> >>/p6WlASwjebsGrcfztb6+3snJCcYTCgSCoKCgP/74Y/DgwVpaWrDCPNKxOp1JQFQfBsW/9h6+ov= >> >> >>UWQRAAAB8fH1Sfm8D0VzS5NTc3v3jxYuHChb/88gtaVCBC9yK+UigUR0dHmLGxqqrq+PHjQ4cOn= >> >> >>TJlipeXF26R7QomAVE+zatXr9bU1IBeE68NgVtYnzx5snTpUhT/iiAUBSILBIKsrCwVFZXhw4fv= >> >> >>3LkzLy9P2BJtbPQb4SuMd3n+/PmSJUsGDRq0c+fOrKwsfCC6gklQH7h586aLiwuK1+4l8VlES75= >> >> >>mZmaeOnUqIiJCbOkpEO1KIgiCxWJZWFiMHDly3Lhx3t7eKLlOu4IMezxfyWSyiYnJs2fPampqrK= >> >> >>2tf/755x9//NHNzQ2GEyBLYRe1zuPx0tPT09PTYVq79kqLHgrcIwCPsFiszMzMiooKdAIesMYXl= >> >> >>W8PCgqaNWvWwIEDT58+DSPc2xsR2+P5WldXp6WlZWxsHB0draamNnToUHV19ZycHCHmgCG6LPOK= >> >> >>QCBABfTEAsS+YaBnxNdVsJg8OgcZvJE+RhBEeXn55s2bSSSSvLx8SkrKZwiUHslXfGVKJpP3799= >> >> >>/4MABV1fX33//ffjw4Tdv3oRGFqJVvpmu6Ay0v+ISpe0NfbxvYgfxf9vbShcNArwhXPVmZWWhzP= >> >> >>oENtXANFaQtWw229DQEC4w7t27B/fSEe2xA/ZgvgpFGRk0NTW3bt26Z8+eUaNGzZ07NyIiAj+zq= >> >> >>6Udg8GoqKiA2li75CuSLmJpyHDlDz+Cz5sfmi7wS/ALkR6Jv1RiN/mMFwC5r169eqWrq/vq1St8= >> >> >>0dm6IT6fHxYWNnXq1AEDBujo6MCUe7ipEX+13vuAPYyv+C8BDdG1tbX79u1bvnz533//PXz4cE1= >> >> >>NzZKSku4J7QMANDU1BQQEeHt7w/gBYTsNEciRgTMJ/bpiv5ywFd57Q6ii4LVuxD4IW2aVxNtte7= >> >> >>eFmD4ARPu5UX0YnH/4BwBAYWHh6tWrSSTSqlWroJUAt2fhz/XeB+x5fIV6kkC0mZhMJqurq48YM= >> >> >>WLkyJHLly+HgbDd0xkg2s9tZmYGazC1V0VGv5ZYepgPfUZHAAaxr+AH/LX5yEE4niiZUtu7jfcN= >> >> >>AODv7//PP/8EBgai/iCCor/wTFgjaMaMGWPGjLGwsGAwGOgcsWvfi57HV3z2hPrA9u3bSSTSDz/= >> >> >>8YGpqCp+/28BkMm1tbc3NzeEIEi0LMfQeBAUFycnJQb5+EmQyWVNTc9CgQUuXLoUqRLvw8uXLHs= >> >> >>NXCNwIQiaTIV+nTJly9+7dju9wbzsAAI2NjVC+ovjX9oLL5RYWFiYlJcXHx8fHxycmJiaJkJiYm= >> >> >>JqaWlBQkJWVlZycnJWVlZ6enpSUlJCQkNgS6JLU1NTk5OTExMS4uLjExMTk5OSMjIzCwsLMzEx4= >> >> >>YVJSUnZ2dnl5eW5uLjwzJycnPz8/NTUVv88ngfc2JSXF0tJyzpw55ubm8D4JCQnJycnwEeLj49G= >> >> >>/SUlJycnJr1+/Pnv27E8//TR48GA9Pb3k5OT09PSUlBR4/se7kZWVdfPmTVglpWfwVYiZSAAAVV= >> >> >>VVKioqJBJpzJgxhw4dcnR0dHBwcHR0hB+6FE5OTlZWVmvWrFm7dq25uTk82PZ2nZycnJ2dr127t= >> >> >>mfPHkVFxVWrVikqKioqKq5Zs0ZBQUFBQUFRUVFFReXw4cM7duxYt26durq6srIy/HbNmjWKiooK= >> >> >>CgqrV6+GV61evVpeXn7p0qXLly+Hd1u1atXKlStVVFS0tbXXrVu3cuXKNWvWyMrKysrK7ty5U0l= >> >> >>JCV4FS1KuXbsW3q2NWLVqFfwA+zl//vxx48bJyMigzsAHaX0mbGXZsmVjxozp27fv1KlTly1btm= >> >> >>jRIjk5uTVr1sCng5e/tz9r165dsmRJbW1tj+Er0bJ8UkBAwOzZs6E+8Ndffy1atGjhwoULFy5c1= >> >> >>C2QkZGZNWvWrFmzZGRk2tv0woULZWRkVqxYoaura21tbWdnZ2tra21tbWNjY2lpCcvS2tvb37x5= >> >> >>09nZ2cbGxtnZ2VYEGxsba2treI6tra2VlZWVlZWxsfHq1asPHjxoY2Njb29/5cqV3bt3nz171t7= >> >> >>e/tChQ/r6+lZWVvv37//111+nT58uJyd3+fJl+ILt379fT0/Pus1AraPPDg4O169ft7e3t7GxQd= >> >> >>2DH+ARKysrS0tLGxEcHR01NTVHjBhBIpFIJNJPP/109OhRS0tLOzs7eE+8CRzOzs4nTpzoefIV6= >> >> >>gPNzc0BAQE7d+7cuHHjjRs3YmNjExIS4uPjX79+ndAtgHMimvXgLNn2a+Pi4tLS0mpqajgcDsyf= >> >> >>yuFwmpqampqauFwul8ttwoD+hR/QmfAzh8NhMplFRUW1tbXwYGNjY1VVFZlMZjAYtbW1dDqdzWb= >> >> >>X1NSkp6cnJCTk5OQwGIzm5mYWi1VeXk6hUFCjnwTeLjxCJpPj4+OLiorQU7z3QdAHWFfn6NGjI0= >> >> >>eOJJFIR48eLS4uRnf7SE8AAOHh4T1Gf0XmGPgBhglXVVUVFxfznEmINwAAIABJREFUeLz2au4Sd= >> >> >>Baio6PV1dXR/i2ibevOyspKY2PjrVu3+vr6Qi62Bc+fP+8xfIVA9kKUHw8CkbjtpplvD8h4gm9T= >> >> >>+cjJn9cK0seIlvZXolU1jvcCVXFjsVgNDQ1tL8IKepw9C5EVl7WgZVo8CWXFfAEfOfPzmkDFiQh= >> >> >>R/CuqJ0+08syJtQhfJGhHR7IGP+EbtL8KROnexegLgeou9TagVxfX8j/uxfgQsT4OfMAhXxcvXu= >> >> >>zv70+0DM56b3PNzc0wcgCRvu1blXoYXwUta9YJMRe8QBTH/nk/wJeC8MPOqs8AvAkUXWjLmvCjH= >> >> >>k78PW9jK2Ief4IgYmJidHV1X79+DbDUdx+6oVAUBMPlcj9Z9bf1A/YkviLnFj4ireXrl+5m+0Cl= >> >> >>UhMTE1+9egVTJYh9iz8R/q3YmVB9Ly0tDQsLe/78OdyDKibnPq4YtH3c8JGHrTCZzPr6erw+DNJ= >> >> >>uP3QHsZ+yjU33ML6KjVSPBppM8/LyDh48qKam9vr1a/hcKAgGSkr0sIgKeIFp9KsLBILw8HB5ef= >> >> >>mTJ0/C0KdP6q8d6Tn6AJtgsVgcDgcP1umK36iH8fVbglCkWTY0NJiamhoZGZWWlsL5FNEUupdx6= >> >> >>wcitFCU1g4xEgBQXV2tpqamra1NpVKFog3uXfRuo7cFWqbu3LmTlJSEvu2i1M0Svn5JQCaxWCwr= >> >> >>KytTU9OamhoCi8yHOmhjYyOVSqXT6TDEls/ns9lsFovFZDJhfgoo0rhcLpPJLCgo2Lp164kTJ7q= >> >> >>6ni3+8gAAwsLC1qxZA/cbtkUf+GxI+PolAX9aBoNhZWV19epVWAEQ/dIMBuPevXsXLlwwMzMzMD= >> >> >>AIDw9vbGyMj4+3sLDw8/O7c+eOl5cXTAiSmZl5+vRpTU3NgwcPzpw5U0dHp6v3P+KrBWgfWLhwI= >> >> >>dzPjexcXaESSPj6xSAUpZNvbGy0tbU1MzOD+/XQJJuUlLRmzZpz5869ePFix44de/fuTU5Ovnjx= >> >> >>4vbt29PT02/evKmkpOTj48NkMp2dnaWlpffv329lZTV//nwdHR24NaWL9Ff8EYSi+Ndly5ZBvgp= >> >> >>F9kQJX78p8Pl86IRksVi2trampqZQvkKJm56efvr06Xnz5nl7e7NYLG1t7fnz5wcHBxsZGamoqE= >> >> >>RHR1+/fn369OmXLl3Kz8/X0tJasGBBcHBwaWnpzp07T548CePHu8dgAgDw8/NbunSpj48P7i/oo= >> >> >>rYkfP0yQMKJzWbb2NiYmJhUV1cDAPh8flBQ0J49e/7444/Zs2c/ePCATqcfOXJkxowZT548MTMz= >> >> >>k5OTu379uqmp6fTp0y9evBgXF7dhw4Z169a9efOmvr5+586durq6MD9SF5FVTM0AAMTHx+vr60P= >> >> >>7a6c3h0PC1y8MAEBDQ4OJicnFixdhHvD8/Pzdu3fPnTt327Ztc+fOtbKyKikp2bdv39KlS93d3V= >> >> >>VUVBQUFBITEz09PadOnXrmzJn8/PwLFy789ddfd+7cyc7OhiGzVVVVXae84neG70NjY2NJSQksQ= >> >> >>obOkdizvjVA+VpQUHD06FF1dfWUlJT6+npLS8spU6aoqKj4+flt2bJFXV3d2Nh4xYoVOjo6L168= >> >> >>OHv27D///GNkZKSrqztjxoz169cnJibGxMQoKirKyMgcOHBg/vz5CgoK4eHh0BraRXYl3PIqxPI= >> >> >>PIA2kO+wDfd6HTm9SAghkXq2vr3/48KGnp2d5eXl9ff2dO3e0tbWfPXtGp9NDQkIMDQ1PnTp16d= >> >> >>KlxMRELpf77t07MzMzfX19R0dHGKP95s2b2traW7duHT9+3MrK6sqVKwYGBtHR0TDFJzTQdkXnh= >> >> >>VhcUUFBwePHj/Pz8wnRpt/OUkXE2AhzbUj4+gWA1tEAABikDM2odDqdQqHweDzoYa+tra2oqKBS= >> >> >>qTCaSSgU0mi0qqoqOp1Op9PJZDK8lkKh1NXVsVgseJDNZnedkEP9R/bXoKCgDRs2oHya7d1w+xF= >> >> >>I+Pq1QCjaSy0QRZESouy+yIopFgoDhaXYQch7olWINNGVzi0CMz5A++uCBQtQ/gF0QsdbkfD1Kw= >> >> >>JymcJ4Jdwz9N44Sfy01t+icz4ZIdVZnUdvmpj9tROFuoSvXxFwPuErlfeeib7CqYlIibOzS9UAv= >> >> >>Ank2ggICFi9ejXiK3pnOt6QhK8SdALwqQAAkJ6ebmtrCxO9o/VWp2gjEr5K0FEg2yqiI4fDoVKp= >> >> >>MP4VSfpOMcF+jK8dvLUEvQRiyjHSYtFKkRCF8HZ60xJ/gQSfCaRDQxNyenp6cXExi8VCIS+SeEI= >> >> >>Jvi4ge1ZcXNy+fft27dp1+/btyspKtC7s9BYlfO0okLGztwH3Fzx58mTatGl9+vRZsGBBWFgYtA= >> >> >>dL5OvXiC4NMP1qgUfWQvvrtGnTSCTSL7/88vDhQ8hXiXz9ugD9qG/fvoXBUF+6O90HZMlC+TJCQ= >> >> >>0Pnzp1LIpEmTpzo4+MD4yIkfP26AABgMBghISFpaWmofsGX7lR3ANkHUPzDu3fvduzY0adPn8mT= >> >> >>J/v5+cFcZl3RtISvnw8AAI/HKyoqqqur69JNzF8hcJcvAKCmpkZTU1NKSkpOTu7Vq1ddl19Hwtf= >> >> >>PB/q1AJZ4v5fwFZUogiMQGxsrKys7ZMgQLS2tqqoqQpJ/4OsEj8erq6trbGwUiz750v3qcuCbzq= >> >> >>F9YPr06YMHDz579iyNRgMti591IiR8/XwAAJhMZkBAQGJiIp58rpfwFZevT58+nTlz5uDBg8+fP= >> >> >>0+n04XtzDLUdkj4+vmAW6/s7e3v3LkDRWzX/U5fG/DwK8TXIUOGGBoaSvj6lQIAQKfTr127Zm5u= >> >> >>Dqv39gamEq1S0AEA/Pz8Jk2a9PPPP9+8eRO6ZCX5Xb46QH3Az88vODiYwWD0Hv21NV8fPHjwxx9= >> >> >>/KCoqxsXFEVjGyE5vWsLXDkEgENDpdCaTiZjaS/QBAqtgyOFwrKyspk+fvmfPnqysLCaTibK6St= >> >> >>ZbXx2gPQt6enoJWXEuAgBycnKUlZW/++67M2fO+Pr63r17l0wmE12ze0zC1w5BICouLLaV6kv3q= >> >> >>2uBnhEas8LCwqZNm/bjjz96enqamppu3LixoKCAkMS7tAXdSRcAAJvNTk5OfvfuHZKvvUTEEqLc= >> >> >>/ACAR48ejR07Vlpa2tfX9/Lly3Jycm/fvhV26q5DhB7JV1xZJDCO4kb7bugGtGe5u7u/fPkSesz= >> >> >>bVTqi5wKOMHxSFotlb28/cuRIaWnpR48eGRkZrVixAibOkKy3WjASbm4mWm4nQvNUN1AW2rOuX7= >> >> >>8eGRmJitj3Bn0A3xmbl5e3bdu2fv36/fDDD/fv3zczM1u9enVubq4k3oUgsJwo+HQDVzzdyVTUL= >> >> >>p1Ov3XrVlRUlFj2qO7pwJeCUJTpo7m52cfH5/fffyeRSGPHjvX393/69Km+vn5ZWZkknpAg3qcJ= >> >> >>CESFuPAcON2mD7BYrIiIiMzMzK7bAfIVQijaq81gMK5cuTJq1KixY8cqKyunpKRQqdT09HQ2m01= >> >> >>I9AGiZVo8+C+LxUpKSqqtrSVaBrl1T3/4fD6ZTIbOWKJ3KAMERsSsrCwlJaU+ffqsWrXqxYsXcB= >> >> >>xQupquaLoH8xXqT+np6RcvXoyPj4dk7f7Khkgb6SXKAIHtLwgODp44cWLfvn21tLTIZDKPx8vLy= >> >> >>4uLi0PRFJ3edA/jKwSuEnh4eCgoKHh4eMBkud3MG6FQSKPRYDJAdKQb2v0iwB9NKBRyuVxvb++x= >> >> >>Y8dOmzbt2rVrd+/ezcrKunnzpqamZklJCTIgdC56Hl+FWHlYFot14cKF8ePHHzx4ENqou5OvAIC= >> >> >>6uroHDx6kpaXh8cvfGGXRE+HPBQB4+/bt9u3bBw8erKGh4eLismnTJj8/v8uXL0N7loSvBCHSUJ= >> >> >>Fu9ObNG2Vl5QEDBvz555+hoaE8Ho/osgy9rQEAKCgoMDQ0DA4O5nK532r8K66DwTBtaGm+devWj= >> >> >>z/+OGbMGCcnp3v37q1YseLff/81MjJavnx5Xl6exJ5FEAQhEOUdJwhCKBSGh4fLyMiQSKTx48ff= >> >> >>vXuXxWIRXZz0FAcAoLi42MjIKCQkpKmpCYhKpXVD090GFBYoEIEgCABARkbGhg0bhg4dun79+jd= >> >> >>v3jx58mTFihX379+/dOmSnJycxF/w/0DLT4Ig2Gz2rVu34Lb3UaNGGRsbw+Jp3dYZAEBhYeGFCx= >> >> >>dCQkK+1XgXXBlAH6hUqpWV1Q8//CAtLe3s7MzlcgMDA+Xl5X19fe/fv3/mzBlYOETij23hWamtr= >> >> >>T1+/PjAgQNJJBKJRFq/fn1ubi7RLdlPIQAAZDI5ODg4Jyen6yr6fXEgPQdKCgBAQkLCypUrpaSk= >> >> >>1q5dm5qaShBEVlaWi4tLZmZmZWVldnY2i8WS2AcIQrTYgpSNj49XV1cfO3aslJTUqFGjFBQUYmJ= >> >> >>i0Ca47uwPDNEiuvFV6U6grVrIR2BnZzdmzJjvv//+xo0bHA6HIAgOh9PQ0MDlcqEoEUryvUGgKY= >> >> >>nH4wUGBpqamqqrq8+aNUtfX//u3buZmZkoBWm3dQnfC/pNrrfQVliCIHg8np+f38KFCwcPHqysr= >> >> >>AzXVTDPTV1dHYfDgf923Xvbw/gKAflaVFSUl5dna2u7efPmhIQEFovFZrO7OTyKx+Pl5uZWVFTg= >> >> >>xqxvjK+QfJCFMTExmzZtGjx48D///BMaGgrriTY3Nz99+vT8+fPp6enQdNB1cZU9jK9CrBwFHJH= >> >> >>Xr18bGBhkZmZ2f2cAADQazc3NLTo6GprSvj2yQkC+VldXHzhwYMiQIdLS0o6OjtBBIxAI4uPjV6= >> >> >>1a9csvv8B6RnAzTBeFVvY8vkJJhoKFKRSKg4NDWloaOqHbOgMAyM3NPX36dEBAACzO9u2RFeqjz= >> >> >>c3NaWlpFhYWv/zyC4lEWrVqFRSlTU1NCQkJ2trakydPnjx5Ml7PSLLe+n8gyQpf+vr6ekdHx4yM= >> >> >>DAKrsNM9zi2CIEJDQ9euXfvvv//CfG/fnj2LIAi4tN2zZ88vv/zSv3//OXPmuLm50el0AACVSrW= >> >> >>3t9fS0jp27JiMjIyfnx/o4tRMPYyveIwpFLSvX78+d+5cRkZGFzlUPgTEVzk5OS8vLyjsvzH7AB= >> >> >>SuLBbrzJkzgwYNIpFI8+fP9/Lygn4ZgiAaGxvDw8MTExMDAgKUlZVDQkLwQGSJfUA8bROfz7ezs= >> >> >>9u8eXNqaipap3ebkIP+WCsrq9jYWBRF/s2osJCsVCrV399/8eLFffr0mT9/PowrYrPZ5eXljY2N= >> >> >>cLslQRAlJSUBAQHFxcVidpJOH4oexldcf4V/79y5s2vXruTkZKQ2deekDO04DAYDr/DbQ/mKqAZ= >> >> >>lAY/HKykpcXFxmT9//pgxY5SUlAICAmBuAR8fn+vXrxcXFyP3LL4ORp8lfCUIUflntPzMycm5ev= >> >> >>Uq1F8Ruocx8IdpamqCpYp7omTFZSGKJYKTWFJS0pEjR6ZOndq3b18lJaWXL182Nzez2ewHDx4oK= >> >> >>yubmprW1taiBQOXy83Ozq6qqhJiVRcl+uv/dmZC+4BAICgpKbGwsHjz5g0Kmu62zsAFcmxsbG5u= >> >> >>bg/NTyhsuVkDrVaTkpLU1dWHDBlCIpHmzJnj5+cHU7y/fv1648aN6urqr1+/hio7VBtSU1NPnDg= >> >> >>RFhYGRPW3UB3nzkUP4yt6d9GghIaG6ujopKenE93uDoX66/nz54ODg1GFiZ7CV7yfuOYNAEhJSV= >> >> >>FVVR06dKiUlNTff//t7e2NqmqlpaXdu3fv7du3eEUNAIC/v/8///zj6+srsQ+IA+eEQCB49OjRw= >> >> >>YMHYeXS7tQgYXPBwcHLly+/d+8eFDY9KP8APoxC0foVAFBaWnr06NGBAwdKSUlt3rw5ICAAkhU+= >> >> >>XVNTE/RpEdhaAgDg5+e3ePHiwMBAFFQp7Joojh7GV6FQCONfkXy1tLRUUVHB7QNEN654EhISNDQ= >> >> >>0Hj16BOVND+IrBD5QAICamhpDQ8MffviBRCItWLAgJCQEkjI+Ph7uyoKnNTc3oxRM8EX19fVdvH= >> >> >>gx9BfgwVyd3uEexlektsKx4PP55ubmmzZtSk5O/iL6K5lMdnJyioyMhPvxe5D+iiYoociDlZ6er= >> >> >>q2tPXbs2EGDBh06dCgiIgJarAICArZu3ers7Az5ihZk6HmhCmFiYgKdXvD+EvsrQWDiE9lfLSws= >> >> >>lJWVxeRr9wDGJcF4l6/Z/ooGDU3TQpFDWyiqF5KUlKSmpgadAjCSGJq0YCD2sWPH8DUlui1Sedl= >> >> >>sdnV1NYwt7NIR6GF8hUDDJBAILCwsNm3aBPXXL9UZXLJ+bWT9v/a+PK6pY30fq63cVmurfuu9t/= >> >> >>15tXVptdd6XaoioCJL0SKiVVC0iqCgKCCguOCO4IKgbLKDgEAgIEvY17DKosi+72uAJBBCICTnn= >> >> >>N8fczN3CEgRCcbW5w8+h+TkzHKeeeedd973HRwxqqBBkdDOShBETk6OmpratGnT5s2bp6amFhoa= >> >> >>CjwDi4qK9uzZs3fvXhAuP6pKCt8FgKjH7Qe+vhXge+LxeKhiLVbAEJsoTwBgn+JwOCkpKaqqqjN= >> >> >>mzPi///u/S5cu1dbWwlML6+vrXVxcMjIyoPaFxsahjOzp6amvr4d5Q0QXQveBr2+FlpaWhISEur= >> >> >>o6IFfEkK/Y8N1RVLL29/f7+PjIyspOnz59/vz5V65cqaurgyMQ3An8JHEk3hCVoPBRmZmZxsbGq= >> >> >>ampuIhD6j/wdYIAbzQuLk5NTS0oKAhYecTQPoAJQlMgcBwnCILFYnl6eq5evVpCQmLu3LmXL19u= >> >> >>aWmBjXJzc2tqakK5CwLWgWBGVSBoH9i8efOzZ8+gSvDBPvA/iA9fw8PDN23a5OPjA0KXxFC+4gI= >> >> >>RC9lDEERTU9OtW7dAaPH333//6NEjGo0GqBYeHi4nJ3fu3Lm2tjYoZdG/I6U14OvGjRsBXz/Ys4= >> >> >>QhPnyNjIyUkZHx9fUVaRDIBACnY/QCjKX6+noTE5Mvv/xy5syZK1assLOzA6srLpdLoVDU1NQuX= >> >> >>bpUX1+P5nnAkWUl6iIHNd2IiAh5efnw8HDwFkTXDx/4+lYoLi6+cOFCbGws1F/fOV9RzRJew7ws= >> >> >>TU1N5ubm8+fPl5CQUFFRSU5OZrFYYNLv6ekJCQkJDAyk0+lAtxFKngfpixYBHltaWuru7l5eXo7= >> >> >>eIIrWfeDrW2FgYKC6urqzsxM9cmPqq4ECruIxxOUKWAP6+vqcnZ2XLVsmISGxYMECFxcXDDFF8X= >> >> >>g8FosFFHFMsI84anOw4V5dQEXmcDhcLhdufYlotvnA17cFeNl8UToljR/YcADSgFmbwWB4eXn9+= >> >> >>OOPEhISX3/9tbm5eUNDA0EQbDabQqGQSKSenh7Qh+OJ9UXVWbjvANVWlMqT28APfJ04QAWYTKaQ= >> >> >>iecdilgMMY7iSEcxGAwnJ6dly5ZNmzZt0aJFt2/f7ujoAPVPTEyUk5PT1taG9gHIudeNPf4IF8T= >> >> >>Ozs78/Hxw7JZI9fgPfH0r5OTkmJubp6WlwbXwO1dh4ciBcq66uvratWvffvvtZ599pq6uTiaTOz= >> >> >>s7gXoQEhJy6NAhMzOz7OxsDoeDrqWghjOyCP7wzTyCIOLj4w8dOpSSkgJeyof9gmEQB74CUQT86= >> >> >>Dw9PeEO0Lslq9AETRBEdXX12bNn586dO3PmTE1NTdBRADU1NWfOnDl9+nRNTQ36cyG6jyxFSOuA= >> >> >>9qyQkBD8na+3RqoykBmg2eidQj8Z4/O3aY/48DUyMhLExwL7q0hf1euAdilc/YDr0tJSQ0PDuXP= >> >> >>nfvLJJ+rq6s+fP4c8xnGcTqcnJiYWFRUJ1RxdS41RLrr7EBISIi0tDfMPvDN9ANYb1h6sImHGYL= >> >> >>jUgHei5mWUmkLdAY0sE6i0+PA1IiIC+Gu/E/8soXkZ9j+O4zweLzk5ec+ePbNmzZo5c6aGhkZ+f= >> >> >>j7Yi+JwOO3t7TCFINzBGilWxmgISkqCIGJiYpSUlID9VYgwk4s/4CtsPyi+paUlKSmJTCbX1tbW= >> >> >>1NRkZ2e/fPmyu7sbVp2PnHgh1GzgEYJ+CGwfE3i74sBXgMzMTCMjo/j4+PEIpEmHkJEVigAOh5O= >> >> >>WlqaioiIhITFr1qxDhw7l5uaCHuvr6wsNDbWwsCgtLQVGLgLJVzf+ooUIXVNTY2Njk5OTI2pTyb= >> >> >>jkK7xOT08/duzYrVu3qqqq0tPTTUxMNDQ0qFQqutpA5Ss+fLUI7HNo2ROTRuLDVwaDUVZWBtfFU= >> >> >>ylfoSgBgOVyOJykpCQ1NbWZM2dKSkoePny4oKAAfMVisaKjo3fv3n3s2LHy8nIhPk2ArzxB1tuh= >> >> >>oaHOzs6+vj58uDox6V0xLv0Vqin5+fmHDx/29/cfGhrq6uq6cePG0qVLPT094UhFxzr4CYfDAX7= >> >> >>pOI4DssIxPXImGifEh69w7YLGG05N0egOMCyUTqeHhoaCYzBmzZp18OBB4A1IEASXy01LS9PV1T= >> >> >>UyMsrIyAAJvwAm9gqgYAJG3K6uLuivzRNZtvE/lq8o+SorK8+cOePq6spgMNrb283MzFatWgV2z= >> >> >>9lsdlZWVl5eXlVVVV1dHQhMq6mpSUxMDA0NzcjIAOOvqKgoJSUlJSUlMTGxvLwchJG8v3zt7Ox8= >> >> >>8eJFe3s7jN+aSpUAQ7KHEAQxODjo6em5du1aSUlJIFlfvHgBo64HBwepVOr9+/fBh/hoC7Xxlyv= >> >> >>E1xcvXlhZWeXl5eEIZ96xPkAQRFdX14MHDy5evBgZGeni4qKsrKyjowNiqV++fKmlpWVhYeHr6+= >> >> >>vl5VVZWfnq1Stzc/MHDx5YW1vr6OhkZma2tLScP39+3bp1hw4dunjx4s2bN1+8eAFOqhAyNYwNc= >> >> >>eArIEFSUpK2tnZUVBRQzYWknUiB6h4EQfB4PCqVumXLFgkJidmzZx84cCA3Nxewub+/n81m83i8= >> >> >>vr6+rq4uYMrARyQfeFO+QtYSBBEeHr5t2zYYz42KucnFuOQrjlCEyWTW1NQUFxefO3dux44dERE= >> >> >>RfD6fxWLdvXt3165dUVFR0dHR+vr6ZDLZ19d3+/btNjY2KSkpVlZWmZmZfX19lpaWixYtun//fk= >> >> >>FBgYGBgbGxcW1t7cDAQE9PD4fDGWffiQ9fw8LCNm/ejNoHpmy/AENOF2Kz2TExMTt37pSUlJw3b= >> >> >>56enl5+fj74qquri0wmh4SEMBgMqICNpOnEhhmsQGhoKPR/xRHPmMlu9PjsA6h5AvhDEAQRGBj4= >> >> >>66+/+vn58fn8zs5OLS0teXl5Nzc3a2trVVVVLy+vuLg4TU3NQ4cOWVpaWlpaZmVl4TgeGRkJXnB= >> >> >>/f//Nmze3bduWnp6em5sbEhKSn58Pz3Ece2iKCV9xHI+IiJCWlvbz8xOpfEXHAOwfviADLo/Hi4= >> >> >>2N/eWXXyQlJVeuXGlkZPTy5UvQPwMDA+BkLDMzs+bmZkKw3fqWNYRthIoimUzetGkTylcRzTPj0= >> >> >>gfgfklnZ2dMTEx2djaO49nZ2bKyshoaGiAhz+HDh6WlpR8/fhwWFubu7p6dnV1TUxMYGGhubv7b= >> >> >>b7/JyMjcvHmzs7MzIiJCRkbm6dOnLBbL0tJyy5YtVCq1qKgoNja2uLgYGgXfC75iGAb4CvJlYIj= >> >> >>X/eSWJSQOUQHZ1dUVFRW1c+fOGTNmfPHFF1euXKmurgYyD8OwvLw8DQ2NPXv2xMTEgENDJ5ev4J= >> >> >>ogiNjYWHV1dZCPCJ+otB4PxqUPwLIzMzMvXLhw48aN1tbWjo4OXV3dhQsXampq+vn5nTp1asuWL= >> >> >>WQyuby8nEQiPX/+nEql3rt3j0QiRUREqKur6+npNTU1RURErFu3ztHRMT8//9SpU+rq6mVlZRiG= >> >> >>sdlsmKL6PeJramqqnp5eTEwM6v8qOn0AfTJBEAwGw8XFZePGjdOnT//00081NTVhXDuO4z09Pfb= >> >> >>29r///ntycjLISIdiUioD9de6urpnz57V1NSgfH038hW+A7DANDQ0vH37NgjuAcJSWVk5IiIiIS= >> >> >>Hh1KlT169fd3V1vXfvHpVKJZFIampqt27dcnJyunTpUnR0NIfDoVAoP/300/Hjx8+ePaujoxMaG= >> >> >>grd2PDR5McYPSUO9gE6nV5cXNzR0QE1NlG4EIx890Bn9fHxWbdunYSExLx5844dO5aZmYkmC2Kx= >> >> >>WJGRkbGxseDMHBgdMOlM4vP5g4ODg4ODqNnhXe4XwEHJYDBevnzZ1NQE1pidnZ0UCoVMJoNPCgs= >> >> >>Lvby8yGRyRUVFX19feXk5mUyOiYnx9vZOTU0FQRcUCmXz5s2mpqYgLUp/fz+6H4aa3N8LvuICRZ= >> >> >>aP7AKKgq/wAsizgYEBCoWyZcuWadOmff755ydOnIAnjvD5fBqNRqPRQPpLIccGdPvm7WsFXxyXy= >> >> >>21ra+vp6YFfvTO+8pGQHVxgIYfRZKjBH5gA4YIME2zDwjOxMAzz9/dfs2aNm5sbNGNBEyzK0feC= >> >> >>rxiGtbe3FxUVMZnMcdb8bcqCre7v76dQKMrKyh9//PGcOXOOHDmSn5+PC0ZOdXW1k5MTUFhxQfo= >> >> >>gDMk88PZ8RXewwPiprq6+d+9ebm6u0FT51u0Wxpvpr0IDHXQf/BdH9q4gg3EBp3Ec7+3tdXR0VF= >> >> >>RU9PPzg59PIDmKOPAVlJ6UlGRsbEylUtF8b2/5nkYV0pAZICpQUVFRUlLyb3/729GjRwsKCmDn1= >> >> >>9bW3rx58/Dhw8HBwWCBhZojJ0v8C02DBEHExMQoKiqC/IS4aHa2AP6Ar28JTLA1B0Y5m80G+1u1= >> >> >>tbVvo0uJCV8xDAN28oCAABjPPSlkRQ0CfMR1ure3F3hCffTRRzNnzty3b19OTg7sw+7ubgsLC2V= >> >> >>l5YCAgNbW1on5Er1RVeGLAP6E0J4FWzHphU4RX1F5DE3WsElv2q3iw9eIiAgpKSkfHx8hr7QJPx= >> >> >>b+HD4ESlY6ne7p6SkvLy8pKTl37tyDBw8mJyeD4y5A24F7wL1798DWwBtNWW8KVCUgCALsm4Dzj= >> >> >>ECJQEJNermi5Ss+fMmMylRo8X6v5SuFQpGTk/Pz85vc+AIMce8HLeVwOGQyec2aNTNnzly+fPnJ= >> >> >>kyfz8vJgigCwQs/NzU1OTu7s7BT6+dvXZyTgJABi8BpjAAAgAElEQVSql5KSoqam9uzZM3y4f/O= >> >> >>klytyvuLDnWghcWG48ATmUHHgK6hGQUHBnTt3srKyYBKeyeIHKr04HE5ISIiCgsL06dO//vpra2= >> >> >>tr4A0ImlxTU5OXl9ff3w+6lEAiqES0SEeVVxzHCYJoa2t7+vQp2FeDTBXFUJk4XwkBRn6CrrrQd= >> >> >>RiGWBtwQbMnoGaJCV9xHO/r62toaAB5fdG6vc0z0VENTC4JCQmKioozZsyYM2fO8ePHoVmeIIiq= >> >> >>qqq7d+96e3uDrO2ge2HyZBHFk8HHopRlsVjQn1Ds1lsoU0e9hgSFXc8XuJ1DgoKLCfBMfPiKNvN= >> >> >>NrRyvA/qQ3t7ekJAQQNbZs2fr6em9fPkSys7Kyspz587B01rAygwkZkOtkJNOHQxZFILXyuFw6H= >> >> >>Q66rE0uSVCTISvGIax2ey6urqampra2lqwuwMynZSWllZWVlZWVlZUVHR1dYHGMJnMysrK4uLik= >> >> >>pISOp3O5/N7e3urq6tLSkrKysp6e3tHzllj97L48LWnp6eiogKeRPVG70loVkUvwDCg0+lkMllO= >> >> >>Tk5SUvKLL75QU1ODBk5C4O2qpKR0584ddI8QFX74ZMj7MSoPRgiO48XFxc7OziUlJUINmfSi35i= >> >> >>vwASYlJRkZWWVkJCQkJAQGhpaX1/f29sbHBysra1tYWERHh5+584db29vJpPZ2toaExOTkpISFR= >> >> >>X16NGjwsJCYO4GNm13d3d/f/+Wlhahl/2+8DUnJ8fMzCw1NRVuoLwpZaFqhJ6QiOM4jUZzc3OTk= >> >> >>pL68ssvt23bduvWreTkZOAPBNg8MDCQmpoaEBBQWVkJddkpg9B6KyIi4pdffgHnyYtohABMhK8M= >> >> >>BsPKygqc2lpeXn716tWnT592d3c/ffp01apVJiYm2dnZ+vr6enp6LS0tGRkZBgYG/v7+GRkZHh4= >> >> >>excXFdXV1Fy9etLS0LCgocHJyAutKOJUAiD9foT0LuEdOYD0ORRSqSIDHlpaW2tra/uc//5k5c6= >> >> >>a8vHxoaCiTyYRecn19fWw2G8xpaAinSNsrBCG+ksnkjRs3gnhuXJQq7ET4WlxcvHv3biUlpdLS0= >> >> >>vb29lOnTpmZmdXX1/v4+CgqKpLJ5La2tjNnzuzfv7+oqKiwsNDY2FhHR+fcuXOmpqaxsbFkMllB= >> >> >>QeHKlSuJiYnW1tb79u0LDg4W4uvYECu+gnyaME3am7YCQ/IJ4zjO5/Pz8/P19fWXLl06a9YsBQU= >> >> >>FcGorQRBAH62oqHj8+HFiYiIa3Tr1eTogHfkCf210vwAXn/NhCIJ4+fKlvLy8vLx8eXl5c3Ozjo= >> >> >>6OsbFxXV2dj4/Pb7/9lpqa2t3draur+9NPP7m7u7e2tubn59vY2Bw5ckRKSkpXV/fhw4fy8vI2N= >> >> >>jYlJSV5eXnZ2dnNzc3QVjeefhcfvoaHhysoKJBIJNQZcvwPQQ1P4G9OTs7Ro0e//PJLCQkJeXl5= >> >> >>4BJECE6qLy4u1tfXV1RUJJFI0BVrAuW+PVA6EgRBoVB27tyJ6gMiqtJE+NrV1WVlZbV79+64uLj= >> >> >>U1FQtLS17e/vGxsYHDx4oKCgEBwe3trYeP3584cKFVlZW2dnZISEh2dnZFArl4MGDx48fj4yM1N= >> >> >>bWtre37+joaG5uBsko4fPflK937tzZtWvXu+JrZmbm1atXc3JyJmYcQI3qPB4vLy9PS0tr9uzZE= >> >> >>hISq1evDgoK4nK5hGDHqL6+3szMbMOGDdevX6+vr+cPdwwQRRvHACwXyNeysjJPT8/y8nIwD2Ai= >> >> >>sxJMxD7A5/NLSkru3r3r5OTk5OR0586doqKijo4OJycnAwODsLCwzs5ONze3U6dOhYeHU6nUu3f= >> >> >>vhoWFxcXF3blzJzQ0tK6uztnZ2cbGJj4+PiAgICMjAxUVaHe8rgIoX62trffs2fPq1aupX29hGE= >> >> >>aj0RobG/v6+ibMG9AQLpeblZWlq6u7YMGCzz//fOPGje7u7sDtC5rMMjIy9PX1LS0twakY8OeoH= >> >> >>jzZTXxtnSEj4cYem80Gig0PScM96UVPkK9cLrepqam4uLioqKiuro7L5XK53JaWFmDeGhwcpNFo= >> >> >>9fX1dDqdwWCAZDDV1dVVVVUMBmNwcLCtra28vLyysrKsrKy9vf2NNu5QWvB4PBcXF11dXZDZGRe= >> >> >>xsXpkTXp7e/v7+1GHvVGLhpSCFzgy6vr6+sCcs27dOllZ2Vu3bmVkZEBfUg6H09PTw+PxOjo6Cg= >> >> >>sLaTTaqGNjKqUsNgJsNrutrQ2G32Gi8VvHJ2x/FdoXQD+EcwSKkR/iSLTaG9UYfTFDQ0O2trYHD= >> >> >>x6EPnW4KI3VI2tSUFDg4eEBdkfHdjcT4iv8y2Kx/P39ZWVlP/vss8WLF1+7dq2+vh72EofDCQ0N= >> >> >>9fT0BDna0f6cmja+DqhQIAgiMzPTzMzs+fPnBHLesSiG0ET4ig/fiIMNeFONagIzODoTga6xtLR= >> >> >>UUVF58eIFvOFNnzkxEAJ/F3Ag4B/6RqITNy7Y22Oz2UFBQTIyMh999NHnn3+ur69fWloKB97Q0F= >> >> >>BsbKyysrKRkVF7ezt8zhS07g+Bbm4RI+JjxY6vEOhr+EP/lclqACY49gnaB4D+OpVzIiHIP7B16= >> >> >>1bgT4j/0VjFhmsCAwMDJBJJSkpq+vTpS5YsuXjxYklJCVQHORxObGysiorKzp07w8LCgL0PHa5T= >> >> >>08zXNQQTGLNwHCcIIiwsTEZGBs2XIaKiJy5f8RFerXCqEtHYwkcsS4XsA7DEKXidhCD/wKZNm0A= >> >> >>SBnSuH/UncEjjON7X1wdk0owZM1asWGFvbw88rOHNNBrNyMhIRUXl2bNnbDYbfj52EVMDbLhuA+= >> >> >>yvIF8xqg+IouhhfB1/GajaCpZf/f39cOWBv4kofaO2oTdD+bp79270JHMoxkQKMDyioqLk5OT8/= >> >> >>f3RfBljVB78kMlkenl5rV+/fvr06f/+9789PDy6u7vRkDiCILq7ux8/fhwfHw/sr/CxKOnfIVD1= >> >> >>jyCIrKwsU1PTkfrrpJc7jK+QhX8IcH4NXxCrmZ2dbW9vHxsby2QyYXuw0YCPQ8Ed+ysIAjlPHtp= >> >> >>fRTq4R1amrKzM2dkZ+Ezhw53T8dGGIiHwvAZx2MuWLXN3dwcnYAEGEATR39/f29s7MDAAEusK6T= >> >> >>kinb7GCShZIWVZLFZzczNIRIlu1U560cP42tHTNjg0gP9RMQRBdHR0xMXF0Wg0HMfBIY6mpqbx8= >> >> >>fFo8jZUBuNIJC2G6OmYwIAn1B1jV0CIr+j+1hS/SJBEDWSjgE1DfQlQbhEEQaPRbG1tN2zY8Mkn= >> >> >>nyxfvtzZ2ZnBYODI8qWqquratWuurq7A5UocTAEjgb5HDMNgmlRcsAOCrsYmF8P4Gp7r39hRx2D= >> >> >>RMXysPuJyuXFxcWZmZsXFxWAwsVgsGo0GznIWYifKWiFKgQsY6DP+FsInv8P9WADYOqH8LthogW= >> >> >>vAT+if//ynhITEkiVLnJ2de3p6wJ2gE7q7ux8+fLhu3To7O7ve3l748ynbCBgn0EEICAr8X0HKD= >> >> >>NDeqdgvSCuJCk5zyS6N5/P5BD766ycIoqamRkdHZ+3atdbW1jU1NW1tbREREUFBQU1NTTwer6Ki= >> >> >>wtvb297e3t3d3d3dPTIyMjc3l0wmOzs7p6SkgK2g9vb2+Pj45OTkrKwsNDkKf3xe+uLD15qaGjK= >> >> >>ZXFlZib6qkQ0hCILNZvv6+q5cuRKoAY6Ojt3d3Tgye7a3tzs6OhoYGLi5uTU3N+MI10URCPU2QE= >> >> >>cmjuMEQeTl5VlaWoJsSHCMiZyvpm5yD4IvJubHDHCFN0jRHzQ0NOjp6UlJSYFTx2k02uXLl1euX= >> >> >>Hnr1i0Gg5GcnCwlJfXNN99YWVk5ODjs27fP2NjY0dFRVVVVRUUlIyODw+H4+voaGBhER0fHxMR4= >> >> >>enrC3XC0R8Scr6C4qKgoRUVFsNHPEySVhioBX5BCkMvlksnktWvXTp8+/ccff3R3d6fT6eA5kJE= >> >> >>JCQmGhoYRERFgmhKfA2lHBbrsA/bX9evXBwYGQr7iU+Cvvdn0Wz2nUw/CbOs768fg6+DgoJ2dnY= >> >> >>aGRklJCUEQQ0ND9vb233zzjYaGRktLy4sXL2RkZL7++msqlVpaWqqsrKyvr19eXv7o0SNZWdmws= >> >> >>LDGxkZTU9OrV6+WlpbGxMTs3bs3ICAAJCMZJ8SErxiGhYeHS0lJPXnyBI37hVQDq6WhoaHU1NRN= >> >> >>mzZNmzZt2bJlTk5OYK8V3gDuaWhoKCsrAw4ufCRkTwz1AT4SGYYJ8g/A/QJszLO73hLD+Hrg3i/= >> >> >>X/K57JzzpZHSOwdehoSE7Ozt1dfXS0lLwb1BQ0Jo1aw4ePNjc3Pzy5cutW7f+61//Sk1NLSkpUV= >> >> >>NTMzc37+joCA8PV1FRiYqKqqioOH36tJGRkbe3t62tra6ubmRkJAhVg3gv5Cvgq7S0tLe3N8gDg= >> >> >>CGARExLS9u/f/+MGTNWrVrl4uICT78GtzEYDOBoAVVhKLewMX0S3iGwEfbXsLCw7du3o+dv4VPg= >> >> >>n6V6d+dV/xuBaST2AHsMvrJYrNu3b4NwIjqdzmQyX7x4oaKioqmpCeSrrKzswoULk5KSioqKdu3= >> >> >>aZWpq2traSiKRgONmaWmpjo7OkSNHwsPDc3Nzs7KyGhsbwSSI9siorRUiBLQPQPuriIb1qP2AYV= >> >> >>hsbOzOnTvJZDLcl4KvanBwsKqqikQi7d+/f86cOStXrnRycqLRaKDa4AkVFRX29vbOzs4gaauQ9= >> >> >>RpiCprzRgADCUbkEwTx8uVLkDNd1AaNYXx9VhjR0Ufr4/bxsddOQMBA6OXlJScnd+HChfDw8NLS= >> >> >>0ujoaDk5uT179pSWlubn5ysqKq5YsQLoA3v37gUnPoKU4WZmZkVFRSdPnpSVlSWRSDk5ORQKpaC= >> >> >>gYJzxMEKaPo/Hs7GxAZE5I7+dAjQ1NUVHR1dVVUEdABeEDAUGBu7btw+ECSxbtszNzQ0IUVDPgY= >> >> >>GBFy9enD59WllZ2d3dHVgGxVZbFQLsZ74gJoLD4TCZTNSuJ6KGDOMrHxsc55ZBTU3NuXPnlJSU7= >> >> >>t+/X15enpiYaGpqam5uXlhYWFdXd//+/YsXL5aVlTU3Nz969MjZ2bmpqamgoODChQsPHz5saWnx= >> >> >>9vbeuXPn6dOnL126dP/+/ZycHChfUQEzslxseH44Pp/v4+OjpaUFjpiCv5pKKQvtWbDyNBrN19d= >> >> >>3w4YNEhIS06dP3759+/3797u6ulDZU1paeubMmY0bNz548KC1tXWKq/2WwJCFIFQJANBFpyiKJo= >> >> >>T2t8b5GxzHKyoqAgMDs7Ky+vr6WCxWU1NTY2NjT0/PwMAAjUZrbW0FyUe7urq6urrAhm1rayuIJ= >> >> >>ujo6KBQKJ6engEBASUlJb29veN8YUJ85fF4T58+PXr0KPTPmmIRBfaigREAdsuNGzdWrVr10Ucf= >> >> >>zZ49e+/evcnJySC0HV1g5eTkGBgY2NjYtLS0iFThExHQzS0cxzs6OrKzs1tbW8G3UJpMOmuJifm= >> >> >>/glrClMrEmwD8dmhoiMVigawkBLL1/4d8hUzFMAyYJjQ1NUfqr1Pz7oE+UF9fj2FYT09Pfn7+5c= >> >> >>uXly1b9tVXX23bts3c3Dw1NRXs+QG7AUEQdDq9sbGxqanpxYsXHR0dxHCDpbiZAkYFfAtQ/8nOz= >> >> >>jYzM8vMzCQQ/wFRyI6J8BUXiDF0PYuaYDDEogGXIOgMgiHO3W+0/sUQgGcGBgaePXu2oqJi5G3j= >> >> >>b84EQAhiVE6dOkUmkxMSEkxNTXft2rV27VopKSk7O7vCwkI6nQ7TBYNfNTY2enh4+Pn50el02AR= >> >> >>0Q+i94CusMyawv8bFxe3fvz8xMRGYREQkXPG34Ss0iQsNJv4ICIWAoio5Sr7xkAwdDKCsiIgIAw= >> >> >>ODV69eoaNiCoQrGG+JiYkyMjLq6uoKCgqSkpLTpk1btWqVmZkZSHEFpw5w0dTUZGdnd/bsWQqFA= >> >> >>iYW2JNTvEx8S6BVBaLn2bNnwLhOTGV8wTj1V6F6jxT+KInRf1FxK8TUNyqXjxw95eDgsH//fiH/= >> >> >>rDd6GtqcMZqJ3gP419LSYmNjs3jx4jlz5nz88cdffvmlkpKSm5tbXV2dkDkWx/GWlhZ7e3sTE5P= >> >> >>IyEgQ54QP117eF7LiI94dQRCpqam7d+8OCwvDR0tHOYkYxlfOIOePfyEGAB1BTFI8Nx9JYC1EIH= >> >> >>QoQk0dx3EOh1NSUmJmZvbjjz+CQwS2b98ODlBlMpkEksMCrpqzsrJu3rwJyIq/bwQVwkhZ097eH= >> >> >>hAQIBTlIXL9tayxDJtQWNUUA+XrW+5vYcNTfPKHZ1SG14B2wOu3pqbG29v7wIEDf//73z/++ONv= >> >> >>v/1WW1ubSqWCKFb0sZjArs7lchsaGgoKCgCbRTRXThmEyAoGPJvNBjsIMP+kyPna2NmIrtbFFpP= >> >> >>LV7RzsREn/oBSuFwuk8lMTk5+/PjxiRMnfvjhh08//XTevHkKCgpWVlbgsFZcEM+EI6pFcXFxVF= >> >> >>RUY2PjSEXovVhavQ5oE/h8fn9/P5PJhEEWuMjsM8P4GvMyYoA7KIpiJheTyFd8+DY9fA1wtdTU1= >> >> >>BQVFeXq6nr58mV5efmFCxcuWLBg3bp1x44ds7a29vDwcHBwKC0txQVkhbxnsVhUKvXixYtXr16t= >> >> >>rq5GixO6eE+B6q9FRUX29vZFRUVvv4oYG8P4mloYx+zrEf9unHT5ihoc4NRfW1ubkJBgZGS0cuX= >> >> >>Kr7766tNPP5WQkFi8ePHx48dDQ0NBWpfIyEg1NTXgP4ByncVieXt7Kykp/f777wkJCSBgEDUDve= >> >> >>/yFR/O14iICHl5+YiICFzEu+LD+BqW4dc/yPlL6QPoRgaO44ODg/X19XFxcY6OjgcOHPj555+/+= >> >> >>OKLjz/++G9/+9uiRYv27Nnj5eVVWVkJzmoE7wmcz426qxIEUVVVdfjw4R07dqCh2KBEPrI5N5md= >> >> >>MoUQ0r8JgggJCUHPk8emxv5a1Vgh5vorlIV8QeSQlZWVqqpqfn4+IQjZQ3sTG7HLgiEGKYj29vZ= >> >> >>Xr15lZGQ4OTkdPnx4yZIls2bNkpCQmDlz5vr1642Nje/evUsikWpqauDpjaC4Z8+ebd682dfXFx= >> >> >>7VAh9IJpOpVCpIhYkjs//7sikwBoTWW4Qgnhvl61TEwzDYDHEmKz7cMwis3y0sLHbu3JmXlwcn2= >> >> >>VEZKQQOh9Pf39/Z2ZmWlubv729qaqqsrLx169YFCxZISEhMmzZt5syZS5cu1dDQCA4OBhnBoKoA= >> >> >>K8Pn8ykUyi+//OLv7w9T1nE4HMBd6FcgOmXuXQET5KyFE11YWNi2bduio6OJqYzn5vHFfYYauRP= >> >> >>h5uZ26NChsrIylI58Pr+3t7e7u5vBYNDpdDqdDvLPgZxzcXFxt27dMjY2Pnbs2MaNG5cvX75w4c= >> >> >>K5c+fOnz//m2++2bRpk7GxsbW1dXBwcHFxMQj/JxDnBBS1tbXBwcEVFRU8Hm9gYIBKpbq6uhYXF= >> >> >>wNXAVBnMXS4fnugx9LiOF5ZWRkQEFBbW4uL2OVoGF9fF2MoPkCFKBCxz58/P3v2bEREREVFRUVF= >> >> >>RVVVVXl5OYVCsbCwMDMzMzMzMzExOX/+/JkzZ3bu3Llhw4Y1a9YsXbp0zpw5n3zyyccffzxv3rx= >> >> >>NmzaZmJhYWFjY2NhERkYWFhb29PSgXlcoUMkBPgG3DQ0NhYWFKSsrGxgYVFVVYYgR4E8pX2H/g1= >> >> >>kOpggHjYVnWE960cRb5s+aeqC6/NDQ0NOnTzds2PDzzz9v27ZNVlZ269atsrKyP/zww5w5cyQlJ= >> >> >>T/77LNPP/109uzZn332mYSEhISExIwZMyQEWLp06bVr11JTU1tbW2k0WktLS3d3d29vL5olE1he= >> >> >>wYfgAiytuFxub29vX18fh8Pp6ury9/dXVFTcu3dvYmIimmtbdDPjOwS6fgCta2pqSk9Pb2lpAXK= >> >> >>XL1b5X98hMMSeDyYjS0tLkD1dQkLiiy++WLRo0eLFi7/77rvvvvtu0aJFS5YsARffffedtLT02b= >> >> >>Nnz549Kycnt2TJkmXLlmloaDx58qSurg7DsM7Ozvj4eF9fXz8/PwcHBxKJ1NHRwePxGhoaSCSSg= >> >> >>4PD48eP/fz8kpOTu7u7wRsKCQm5d+/etWvXrl69qqampqGhkZmZiYqZP59khUCbieN4eHj4jh07= >> >> >>KBQKjkT2fuDrKJtDAQEBmzdv3rp164EDB27fvk0ikUJDQ0NCQkIRhISEPHv2LDMzk8lkdnR0ZGZ= >> >> >>mhoWFkclkCoVCpVLB6Ql0Oj0rKysqKio6OtrFxcXf3x+kA2pvb4+Ojrazs/Pw8IiOjs7Nze3t7Q= >> >> >>UWgJiYGC0trUWLFuno6Pj7++fn58NVl5BY/ZOJWNQ+AJahz549k5KSAucd8xGPs0kv+j3jK46Yt= >> >> >>EB3NDc337x5Mzw8vLGxEXp/jx/oYzHBcUIgYgI6rPB4vJ6eHnD2FbrjOjg46OPjs2HDBi8vL5iI= >> >> >>CX3an5uv0FUA2AdkZWXDw8OJ4QkqJ73V7xlfhfqCIAgajfbo0aPi4uLxs/N1lH2jz8F1VFQU3C8= >> >> >>gCOJ9N6yOH+gCiyCI4ODg9evXg3yaGLK/NXV8JXDwbgixMhqAbsIF24A4jiclJZmYmICda6jUTo= >> >> >>EwIwT5NLdt2+bn5wfzXPyJdVYUKCkJgkhPTzcyMkpPT8eHWw9Ey1cCHyZFMPy/RsQxwrunGBji5= >> >> >>gdmanA+TEFBAY5E5kwZY0pLSx8/fpyXl4cmIPqL8BU2GcdxDofT0dEBTl0cucs4iSCE4gsGhrgt= >> >> >>PQ2tvUV1TGpFF6WDXVnRUc7hDoiJlEU5wefzBwcHb926JeSvPcXKIh9x94aWyCkr/V2BjwBDrNH= >> >> >>gpWBTYx/Ib3tln25+NU4luMjQ98Vp24wDac2RdfT6/sF+Qjz2aTFkswA4AcbExBgaGr58+RLcwB= >> >> >>el8+XIykArIxxCfwV9QGjG5/P5AwMDwDINADOEila+XorS0yatPP3sP0dI6y4n7jSKUb5G1X+Qf= >> >> >>ft5U+YgTyz8YjEkYhH8297ebmNj8+rVK3xEUPwUVKawsNDf37+2tvYvyFfIWhzHMzIyQD54XMQR= >> >> >>lMP4qh26SfeZlJrPdxtc/qbms+FkqLJFsnZwkUdqdWIjo1EcVIKRXdDd3W1nZwf1V1GXDi8IQb4= >> >> >>3JSWl4OBgoezEIq2GOEDIShMUFLR+/XoymSxkz5r0cofxVdVtnobdd1rOP+y79v909X/wjdFMa3= >> >> >>AIenXF8/m1srZX4sBXIRAE0d3dbW9vj+oDIqLLyBfQ09Nz9+7d//znPwEBAWj+rL8IoDWGIIiQk= >> >> >>JANGzbAfJqiG7fD+LpNb832E8t1bv58wWPDJZel1yOX7/ebp/B4kXWiRQuzVUxUWBSQrzC/C1z6= >> >> >>THpZkK9Qaaurqzt48OCOHTuAfQAXm8NbRA2UkcD+GhISsnHjxtDQUFzEKSCG8VXNeZu0o+wO963= >> >> >>qAd9pkb464vf1/icbdnvtvUS5WtJZJp587ezstLW1LSoqwsfsqUnsQfgcGo129+7d+/fvt7e3Q+= >> >> >>PrX8GeNVJ8FhUVOTo6wqwluMisNMP4uvz+8mWWS+TtlU75GBxzV1d9vH6Xh+yZUIPokpheTu+kl= >> >> >>/32IAiiq6vLzs6uuLgYzk2j9tSkdJ/QE3g8XnNzc3V1NdiqFZFHknhCaCYB+fyAozqKSS93GF+P= >> >> >>+WlJPVj/o9W3253Wm0YaWac7ehYEBBSTS7vEUbjiAn3A1tY2PT191A3YyQX+mrAFXLACQ3NkTA3= >> >> >>eVc8LRRTD+mACI/QfCoiJNYFA+Wocb+Kc7uqV6WWfbX0n60Jue8IQznu3/TI2CIKg0WgGBgYXLl= >> >> >>xISUnJz8/Pzc3NESA/P7+2thbs7H8ABP5HwULQ+oEjyVNeN2UB1jKZzMrKyp6eHqiSjS1fR1YJf= >> >> >>ebYb/x/fG1htzPYDCabyccIDMf42BBBEISYuRCgIAiCwWCYm5vv3r1bW1tbX1//1KlTenp6J0+e= >> >> >>1NPT09XVtbGxiY+Pz8zMTEpKSkhI8PPzI5FIWVlZ5eXlJSUlqampiYmJhYWF6enpMTExQUFBXl5= >> >> >>enq+Bh4cH/NbLy8vb2xt86OHh4evrGx0dnZ6eTqVS09LS0qcEVCo1Kyurrq4OZLXGX5OYB8Owvr= >> >> >>4+cIzUqKxF+QHXT5C140RKSsrRo0fHnuXQt9bR0ZGRkZGdnQ2cOeE96B7EqMQlhPZjX1eG2GJoa= >> >> >>KiioiIzMzMjIyMzMzM9PT0tLS0jIyM9PT0lJSU9PZ1EIpHJZG9vb0dHR0NDw8uXL5NIpLy8vKys= >> >> >>LF9fX1dXVyqV6u/vb2dnd/nyZcDyEydOnBwBPT09PT29EydO6Orqgn8PHz78/fffz58/X1VV1cD= >> >> >>AYMeOHdLS0ps3b5aSktosekhJScnIyOjq6j58+PDRo0d2dnaOjo4ODg72CBwcHB49emRhYWFpaf= >> >> >>nw4UMHB4eEhISGhobk5GQPDw8KhZKXl0ehUB4/fuzv75+UlOTm5hYZGVlVVZWUlAS6MSMjg8Fgc= >> >> >>DgcNpvNYrGApyWLxert7WWz2eDDwcFBf3//9evX+/n5cTicvr6+/v5+kNwX/Mtms4FyDza9CIKo= >> >> >>r683MzPbvHmzvr5+eHg4iOgcGBiAFpjXbWuPxlecwMVVoI6Kscc0m83u7+/v6+vr6enp7Ozs6Oj= >> >> >>o6+sDwxf0Johs6enp6erqam9vb2tr6xgN4KvW1tbW1lZwXVdXFxwc7OLikpubW1BQ4OnpaWtra2= >> >> >>tra2NjYyt6PHz48P79+3p6eoqKilu3bpWWlpaWlpYdDTIyMrKystLS0jIyMlpaWhYWFrt27fr22= >> >> >>28VFBQMDQ3V1NQWLly4YsUKFRWV7du3a2lpGRgYSEtLy8vL79mzR01N7fr163fu3Dl//vzp06cN= >> >> >>BDhz5oyRkdHp06f19fXPnj2rqqr6r3/969dffz1z5oyBgYGhoSG4MDAwMDIyOnfuXEBAQFxcXEB= >> >> >>AQEZGRklJSVRUlJqa2rRp0yQlJVetWnX48OGTJ09aWFikp6fT6XQulwuTcI1810h+wiE6l9dDEL= >> >> >>z3QrKOBIE4p6J7USOnQngbgayW3nF4G70AAAm1SURBVAZTvMyCaGlpycrKAhNLeno6mGdGAnwLL= >> >> >>hISEqysrHR1dW1tbZOTk58+fXry5Mljx45ZWlrGxcWlp6fb2dlpaWnp6elZWFhYWVk5OTnZ2dkZ= >> >> >>GRlpamqqq6sfOHDg4MGDBw4c2L9///79+zU1NTU0NDQ1NQ8fPnxQAHV1dQ0NDQ0NDXD/kSNHLl6= >> >> >>8aGpqqqSkdPr06cuXLyspKX3zzTcSw/H3v/997969GRkZmCAybNRX/D++ZjW4FNOCa+hpxW2F3X= >> >> >>3090rICrv048PXsEJObuid0BSFIT6d4ykRMhU+fIrJiv/Ryul16O3tbWtrA+EYQ0NDYN4Ax4QTB= >> >> >>MFms1taWlpbW5lMJpju+/v7Ozo66uvrGxoaGhsbGxsb6+rq6urqQGJ78Bdc1NfXg9vq6uoaGhqa= >> >> >>mprq6+sbGxurq6uzsrK8vb0pFEpCQsLt27eVlJQkJSU/+uijxYsXf//99/Ly8jdu3HBwcCgvLx/= >> >> >>jFRAoX+0y91ikqDtlX0urTevlsIj3SsqiSjo23O0QqE0A+PClLiZI/YAS+nXPF/pKaCGM0n1sjH= >> >> >>zIGHeO/RXanFHHJICQkxA+/HB0yGP4lYgAExgmJCQcOnRIWVlZR0cnMDAwMzOzuLgYqLxCbopCG= >> >> >>MbXK6n7joXu1A3VuJt8u6il+P21fmPDF5hCRBn5FfwJ/nrfrtdRbeRt46keeH+vux9l6hiVgfQa= >> >> >>oz5CXwnRHd2OGrXckRfoM2GPYYJ1Ei6Yr3DkaFyhvuVyuRkZGT4+PiUlJeAcViFa469PMjKMr6f= >> >> >>8fz0fuedK9GGH9Dvpdek9nN73S8SKLTBEDHO53Pr6+levXlVUVACDJT7cExK1wwvJRSGe8fn8tr= >> >> >>a20tLS1tZWMHuIoYhBaQfrDw0FKEfHA8BXcJiZxDXzNbGvzmU0OCZW2SdXu3f21X7g66QAynuCI= >> >> >>Lq6ujw9Pfft23fx4sWqqiohi6MQccF7xUeb63Ec53K5gYGB6urqDg4O4EwEMeTrqHhTmqI//B9f= >> >> >>9T0WawV+s9dn7u/+/ybnOzHZrz31+APeFJjAFN/X1+fs7LxixYrjx483NTUJSU0CWUVB7sIPcWS= >> >> >>iBPeEhoauXr3a0NCQTqf/FVzDCIJISkr6L1/3ev5zn8e3u91/2uWu6pLh0Tvwni25xBnoJE4mkz= >> >> >>du3Ghubg5Sb+ACn3wcx0F2o+7ubhBwi2HY4OAgi8ViMpnAVAwfNTg4yOFwCgoKfv31V2NjY3BG/= >> >> >>V+LrwdcNLY9XKHmLnMz4UZyTSqHxxm5xAO/EdsdWrEFZBKXyyWRSOvXr798+TKTycQEbmU4jnd1= >> >> >>dcXGxjo6OlpYWMTGxrJYLA6Hk5+f7+3t7eXlRSKRSkpKQGbP1tbW6Ohof3//u3fvrlmzxtDQEDz= >> >> >>qfdEHJoxhfN3lo3wywtgi1dog3Ngjw4Mz0E8QBB/j83g8Aifa+lohg8Unwvu9AKqYDg0NBQUFbd= >> >> >>iwAfAVfE4QBJPJdHV1NTY2trW11dHROXDgQGpqalFR0alTp/bs2WNnZ3fhwoVHjx61t7fTaDQ7O= >> >> >>7vjx4/b2NhoamouWLDAyMiIyWTifzX5KvVw7Q7Xnb/aqyhaKxk9PRucF+yX5xeSExL3Ku485bwB= >> >> >>5UxuU25Ja0lgbiCNRfugKrwRoPDj8XhBQUE///yzmZlZd3c3+KS2tjYsLExBQeHEiRNdXV3FxcU= >> >> >>HDhzw9vYuKirS1tbesWPHkydPzp8/b2ho2NzcTKVSt2zZYmhoWF9f7+bmtnz5cgMDA2Dt/4vwtb= >> >> >>OzkyAIieW6P/x87me563K/Wu6Su75d2kpG3VXd0Nto1ZVVP9/ZcDfynonPeRWbXbee3UorTetid= >> >> >>b3ryr9PgOv6oaGh4OBgIF8ZDAZBEHQ63cHB4dChQ4sWLdLW1gaB0SYmJiB34oULFzZv3nz58mUT= >> >> >>ExPA18DAwNWrV3t7exMEUVhYqKysbGJiAlXhPzeG8bX3UW/8xdgw05D0W6mvbr2IOR3tfsr9H6f= >> >> >>++dP51ZZ+Vrstdi+98I9dzr+c8TYwDzRv6Gr8K3TQxDBtNOCC8+eDgoLWrl1rbm7OYDAwDKNSqa= >> >> >>qqqvv37//hhx8OHTrU0dHBYDCMjIx8fHxCQkLWrFmjpKQUExMDNvErKytBcJ+dnV1vb29CQsKWL= >> >> >>VuMjY3huYp/Mgj1oYSEhJyc3H/5mmSWXGBcWGpcVnulufZiE9WQWmNZuezC94ccj/x45cdvb3+1= >> >> >>1nb5kivffn/pB5MnZ/OrcvmYuOePf1cYSdaPPvoI2F8HBgbc3Nx+/PFHXV3d58+f5+fnm5mZ/fT= >> >> >>TT46OjsePH1dUVAwKCgoICDhy5Eh4eLibm9v8+fMVFRXDw8PPnDmzbds2X1/ftLQ0FRUVVVVVNz= >> >> >>c3dXX1L7/8Ultbu7VVHANC3x5j8dXvelTy40qyZf6NQ8GUa3lUqwJ/3bDtt2XXXF0u6/rTmofLF= >> >> >>9/7f98/+oes2w/HQn5zfm7f9cFA+xq8jq84jvf29j59+lRHR+fSpUve3t6urq4GBgba2tpZWVkx= >> >> >>MTFHjx49ffr0+fPnr1+/XlZWlpqaqqqqKi0tbWxsfPr0aQUFBVNT05KSkidPngCvKGVl5dWrV1+= >> >> >>+fLmuru5dN1okGIuvVY6VbZG0ZI9c4+N3oq0LHl5Lengj8ICx4qnr23dd3SizZ/6JaysCXtmmNc= >> >> >>QlVcfGlyW0Mzs+8HVUjCTr9OnTcRwH8rWmpqawsLCoqKi0tLSoqOjVq1elpaU9PT0sFqugoCAiI= >> >> >>iI1NbW2tra/v5/BYKSlpXl4eISFhRUUFCQmJsbGxnZ3d3d1dcXHx5NIpOjo6KCgoIKCAqBavOt2= >> >> >>Tz5G5SuNRiMIQoLtymE95rHd+ZU2FfGGidQjRUUmHZsfrF5z96elt/653Giu6v01mqS9ak9+0/c= >> >> >>7Hfo8lMakfTDEjorXyVeIkYZtsKFFEATwBCAEJ3kQBDE4OAgj+IaGhnDkVFscx9Go1D8fZV/H1+= >> >> >>vXr0s0OPVUWHMa7g22W7bmnKO6aTxOOZquFrxLyn3z7JuzFjz4xx6yhpyH/GG/ww6JDuXN5aN2+= >> >> >>gcQBCExGsbzQ/z17nyvY/mfGyO7cdu2bf+Vr+XW9PbHPfUOtBdWNbV3mAnGKZrr95NKSWH1Ida5= >> >> >>9w6Faxgnnfg1UMkixSqrPquzv/Ndt0V8MWG+foAQRnbj5s2b/8vXZF963n1esX1/jkN/qOVQ1G3= >> >> >>89u9P5n7xxZGNR112hz+7kRF7vSTfpSnc4nkqOSOFkuLzxMdrBLw/4ANej5GEGSMmGUYmA7i7u7= >> >> >>u6uoaFhbW0tBCjxsd+wAeILT7w9QPeJ3zg6we8T/jA1w94n/D/AWQx0gRPTdK4AAAAAElFTkSuQ= >> >>mCC" alt=3D"">
>> >>
=A0=A0=A0=A0 I wonder, however, does the situation the same if >> rateless= >> >> erasure code (say fountain codes) is used?=A0 As with erasure code, no >> ACK= >> >> and retransmission is needed except when the whole file is completed. >> So e= >> >>ven heavy loaded, the network is still busy with effective data packet, >> rig= >> >>ht?=A0 Although queueing delay will increase, I believe that=A0 the >> network= >> >> throughput=A0 will not=A0 suffer the plunge as un-coded network.
>> >>
=A0

Kara






> class=3D"gmail_quote">2= >> >>013/3/5 Srinivasan Keshav <> href=3D"mailto:keshav at uw= >> >>aterloo.ca" >> target=3D"_blank">keshav at uwaterloo.ca>
> >>uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px >> #ccc = >> >>solid;padding-left:1ex"> >> >> >> >>To answer this question, I put together some slides for a presentation >> at t= >> >>he IRTF ICCRG Workshop in 2007 [1]. In a nutshell, to save costs, we >> always= >> >> size a shared resource (such as a link or a router) smaller than the >> sum o= >> >>f peak demands. This can result in transient or persistent overloads, >> reduc= >> >>ing user-perceived performance. Transient overloads are easily relieved >> by = >> >>a buffer, but persistent overload requires reductions of source loads, >> whic= >> >>h is the role of congestion control. Lacking congestion control, or >> worse, = >> >>with an inappropriate response to a performance problem (such as by >> increas= >> >>ing the load), shared network resources are always overloaded leading >> to de= >> >>lays, losses, and eventually collapse, where every packet that is sent >> is a= >> >> retransmission and no source makes progress. A more detailed >> description c= >> >>an also be found in chapter 1 of my PhD thesis [2].
>> >> >> >> >> >>
>> >>Incidentally, the distributed optimization approach that Jon mentioned >> is d= >> >>escribed beautifully in [3].
>> >>
>> >>hope this helps,
>> >>keshav
>> >>
>> >>[1] Congestion and Congestion Control, Presentation at IRTF ICCRG >> Workshop,= >> >> PFLDnet, 2007, Los Angeles (California), USA, February 2007.
>> >>> href=3D"http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/conge= >> >>stion.pdf" >> target=3D"_blank">http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >> >>pers/data/07/congestion.pdf
>> >>
>> >>[2] S. Keshav, Congestion Control in Computer Networks PhD Thesis, >> publishe= >> >>d as UC Berkeley TR-654, September 1991
>> >>> href=3D"http://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/91/thesi= >> >>s/ch1.pdf" >> target=3D"_blank">http://blizzard.cs.uwaterloo.ca/keshav/home/Pa= >> >>pers/data/91/thesis/ch1.pdf
>> >>
>> >>[3] Palomar, Daniel P., and Mung Chiang. "A tutorial on >> decomposition = >> >>methods for network utility maximization." Selected Areas in >> Communica= >> >>tions, IEEE Journal on 24.8 (2006): 1439-1451.
>> >>> target=3D"= >> >>_blank">http://www.princeton.edu/~chiangm/decomptutorial.pdf
>> >>
>> >>
>> >>

>> >> >> >>--f46d0444e84964e1a304d740bdcd-- >> >> cheers >> >> jon >> > From jnc at mercury.lcs.mit.edu Wed Mar 6 09:48:23 2013 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Mar 2013 12:48:23 -0500 (EST) Subject: [e2e] Why do we need congestion control? Message-ID: <20130306174823.052AE18C15D@mercury.lcs.mit.edu> > From: Dave Crocker > with Leonard Kleinrock as principal investigator. This meant I got to > hear him lecture about queuing theory and he is a good enough teacher > to make even that topic interesting. Ah, The Master himself... :-) > When things are very good, queuing isn't needed because there is plenty > of capacity. When things are very bad, queuing isn't helpful because > there isn't enough capacity. A most succint summary of the situation! > If you need a long queue length, you have bigger problems than the > length of the queue... Where's that 'nail on head' icon... :-) Noel From kkrama at research.att.com Wed Mar 6 10:12:37 2013 From: kkrama at research.att.com (RAMAKRISHNAN, KADANGODE (K. K.)) Date: Wed, 6 Mar 2013 13:12:37 -0500 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <0037066628D6FC449C61186553CAE11D032D43A83ED9@njfpsrvexg2.research.att.com> I want to second what Jon and Keshav say with regard to the assistance provided by coding, but the limitations that arise in an environment without effective congestion control. We'd explored the benefit of coding (admittedly simple R-S codes) at the end-end transport layer to complement TCP, so as to help sustain losses on wireless links, in our work on LT-TCP. We did see the benefit of coding, to extend the dynamic range of transport protocols to tolerate higher loss rates, but only up to a point. Beyond that, you see the same results as you would see in an uncontrolled environment where losses (and the resulting wasted work) begin to dominate the utilization of the resources in the network. That is without paying attention to the delays that result from excessive losses that cause the receiver to wait to reconstruct a block. There is still the need for reasonable congestion control mechanisms to keep from causing excessive losses. And Keshav's point of the unfairness across flows in the short term and the eventual result of everyone losing out is certainly important to keep in mind. Finally, I heartily agree with Jon's last point regarding ECN... -- K. K. Ramakrishnan Email: kkrama at research.att.com AT&T Labs-Research, Rm. A161 Tel: (973)360-8764 180 Park Ave, Florham Park, NJ 07932 Fax: (973) 360-8871 URL: http://www.research.att.com/people/Ramakrishnan_Kadangode_K/index.html -----Original Message----- From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Jon Crowcroft Sent: Wednesday, March 06, 2013 10:03 AM To: shun cai Cc: Jon.Crowcroft at cl.cam.ac.uk; end2end-interest at postel.org Subject: Re: [e2e] Why do we need congestion control? ok - i see your point - this is true if your sources have a peak rate they can send at this could be the line rate of their uplink - that would be embarrasingly bad (see keshav's followup on escalating costs of coding) or the rate they can get data off disk (which could be as bad, but might be lower) or an application specific rate (e.g. streamed video) for which you're suggestion is quite reasonable.... but for data sources which are greedy (TCP with arbitrarily large files) you need a way to tell sources a non wasteful way of sending - and what is more there isn't just one set of sources in one location and a set of sinks in one other location so the system of senders sending at unconstrainted rates on a finite speed net with high speed edges, would create multiple bottlenecks, which would exponentiate the problem coding isn't magic - its info theory - if you lose info you must add redundency - coding does it pre-emptively rather than post-hoc the way ARQ/Retransmit does, which saves you time, but in the end, can't defer the inevitable if you look at digital fountin systems for video they pick a likely loss rate, pick a tolerable picture degradation rate and use those to derive/choose a code the assumption is that the losses are capped because most other systems are backing off just like TCP - if you break that assumption, you'll break the coding parameter choice anyhow, roll out ECN - much betterer technology:) congestion avoidance without keeping queues filled everywhere... From richard at richardclegg.org Wed Mar 6 10:19:15 2013 From: richard at richardclegg.org (Richard G. Clegg) Date: Wed, 06 Mar 2013 18:19:15 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <513788A3.6030005@richardclegg.org> On 06/03/13 15:02, Jon Crowcroft wrote: > ok - i see your point - this is true if your sources have a peak rate they can send at > > this could be the line rate of their uplink - > that would be embarrasingly bad > (see keshav's followup on escalating costs of coding) > or the rate they can get data off disk (which could be as bad, but might be lower) > or an application specific rate (e.g. streamed video) for which you're suggestion is > quite reasonable... Apologies if this has been mentioned already -- the "blast it out at full whack and code against loss" strategy is explored in Is the ''Law of the Jungle'' Sustainable for the Internet? from Infocom 2009. Nice maths in that paper actually -- I was lucky enough to see them present it. The conclusions are interesting. http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5061903 -- Richard G. Clegg, Dept of Elec. Eng., University College London http://www.richardclegg.org/ From jwbensley at gmail.com Wed Mar 6 10:39:14 2013 From: jwbensley at gmail.com (James Bensley) Date: Wed, 6 Mar 2013 18:39:14 +0000 Subject: [e2e] Research On Protocols Message-ID: Hi All, I believe I am posting to an appropriate list and target audience (if not, please point me to a more suitable mailing list or forum). I am conducting research for a Masters degree. I am studying the short comings, design oversites, or general unwanted behaviour of common networking protocols, that affects end users and applications that run over networks using these protocols (like Ethernet, MPLS, IP, UDP, TCP etc). An example of this would be that Ethernet has no TTL, so that is one good reason to have some form of spanning tree protocol on a network with redundant links (but spanning tree is also flawed). Another example; TCP has to ACK a lot, now we have Selective Acknowledgements which is useful for LFNs. Can anyone show or tell me where I might find some good research on common protocols? Or perhaps give me some pointers on what to look for my self? So far, the vast majority of research I pull up is about TCP congestion control, so I'd like to find something different if possible. Many thanks, James. From fu at cs.uni-goettingen.de Wed Mar 6 12:24:35 2013 From: fu at cs.uni-goettingen.de (Xiaoming Fu) Date: Wed, 6 Mar 2013 21:24:35 +0100 Subject: [e2e] Research On Protocols In-Reply-To: References: Message-ID: <5137A603.8070403@cs.uni-goettingen.de> Radia Perlman's "Folklore of Protocol Design" might be of your interest, although not TTL-specific: http://tools.ietf.org/id/draft-iab-perlman-folklore http://research.microsoft.com/apps/video/default.aspx?id=104809 Xiaoming On 3/6/2013 7:39 PM, James Bensley wrote: > Hi All, > > I believe I am posting to an appropriate list and target audience (if > not, please point me to a more suitable mailing list or forum). > > I am conducting research for a Masters degree. I am studying the short > comings, design oversites, or general unwanted behaviour of common > networking protocols, that affects end users and applications that run > over networks using these protocols (like Ethernet, MPLS, IP, UDP, TCP > etc). An example of this would be that Ethernet has no TTL, so that is > one good reason to have some form of spanning tree protocol on a > network with redundant links (but spanning tree is also flawed). > Another example; TCP has to ACK a lot, now we have Selective > Acknowledgements which is useful for LFNs. > > Can anyone show or tell me where I might find some good research on > common protocols? Or perhaps give me some pointers on what to look for > my self? > > So far, the vast majority of research I pull up is about TCP > congestion control, so I'd like to find something different if > possible. > > Many thanks, > James. From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 6 15:29:27 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 06 Mar 2013 23:29:27 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51377F9F.1080206@isae.fr> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51377F9F.1080206@isae.fr> Message-ID: well I beg to differ about this work being about a "congestion control free" internet the decongestion control idea involves (as well as xor coding) a) fairness support at the edges of the net (under specified) and b) active queue management in the core (a decent implemenation would need the same sort of virtual queue mechanisms a lot of decent ECN implemenations have looked at) so while the work is cool (for sure) and I am definitely in favour of exploring the design space, it doesn't amount really to just "everyone send as fast as they can" at all - that doesn't seem a fair way to describe it so i'd claim it is still congestion control, just with a different partitioning of the functionality than a purist end2end (which is just fine - i am no purist:) there is also the long term argument that the ratio of core to edge capacity flips over every now and then -- see the figure in our paper http://www.cl.cam.ac.uk/~jac22/out/ripqos-rant.pdf and this makes a lot of things break badly (go to places where the core nets are massively under provisioned and you'll see what damage "just a little bit of packet loss" can do... In missive <51377F9F.1080206 at isae.fr>, Emmanuel Lochin typed: >> >>Hi all, >> >>We've attempted with success to implement a Decongestion Control >>Transport Protocol following A. Snoeren and T. Bonald Infocom'09 paper : >>"Is the law of Jungle sustainable for the Internet". We defined an >>"Anarchical Networks" scenario and tested our proposal named DCTP with >>Achoo (proposed by A. Snoeren) over a simulated ISP-like topology. >>Preliminary results tend to confirm that both Snoeren and Bonald are >>right and that such architecture is sustainable. >>You'll find our first experiments in the slides available here: >>http://www.lochin.net/tetrysjungle.pdf >> >>Emmanuel >> >>On 05/03/2013 13:07, Scharf, Michael (Michael) wrote: >>>> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>>>> There has been some interesting research on whether a >>>> transport protocol could work without any congestion control. >>>> One reference is: B. Raghavan and A. Snoeren, "Decongestion >>>> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >>>> I remember that you, some years ago, asked whether networking >>>> can be done without flow control. >>> My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. >>> >>> Michael >> >> >>-- >>Emmanuel Lochin >>Professeur ISAE - OSSI >>Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) >>Issu du rapprochement SUPAERO et ENSICA >>10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 >>Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 >>Web : http://personnel.isae.fr/emmanuel-lochin/ >>--- >>"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" >> >> cheers jon From lars at netapp.com Wed Mar 6 23:57:01 2013 From: lars at netapp.com (Eggert, Lars) Date: Thu, 7 Mar 2013 07:57:01 +0000 Subject: [e2e] network coding RG proposal (Re: Why do we need congestion control?) In-Reply-To: References: Message-ID: Hi, just so you're all aware of it, there is a proposal for a new IRTF RG on network coding. The mailing list is https://www.irtf.org/mailman/listinfo/nwcrg and a wiki with more information is at http://trac.tools.ietf.org/group/irtf/trac/wiki/nwcrg Lars From detlef.bosau at web.de Thu Mar 7 01:10:29 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 10:10:29 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <51385985.2000405@web.de> Am 06.03.2013 13:29, schrieb shun cai: > As discussed in chapter 1 of your PhD thesis, when network is > congested, retransmission dominate the traffic and effective > throughput diminshes rapidly, leading to a deteriorating situation. > This can be illustrated in the well known figure with two turning > points Knee and Cliff. > > > I wonder, however, does the situation the same if rateless > erasure code (say fountain codes) is used? As with erasure code, no > ACK and retransmission is needed except when the whole file is > completed. So even heavy loaded, the network is still busy with > effective data packet, right? Although queueing delay will increase, > I believe that the network throughput will not suffer the plunge as > un-coded network. > > Very short answer, because I'm not quite familiar with erasure codes. However, we're moving around overhead here. In the end, it doesn't matter whether your network suffers from retransmission overload and the goodput as seen by the user runs to zero or of the network suffers from "unsatisfactory code rates" where 1 packet is encoded into 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 packets so that it can be recovered. To the point: Flow control and congestion control are supposed to /solve/ a problem, not to /worsen/ it. And from what I read in some off list discussions which developed from this thread here, there are quite some people who claim that VJCC is quite a kludge. At the moment, I have no clear position to that claim, though in some of the PMs I got, I missed the necessary respect towards Van's work. And quite some mails argued more historically than scientifically which I personally find annoying. Sliding window & Co. were invented to fully utilize network capacities. You cannot over utilize them. Or, wrt the 12 basic network truths: No matter how you push or pull, no matter what priority your project may have: You cannot increase the speed of light. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/363b02c4/attachment.html From detlef.bosau at web.de Thu Mar 7 01:15:36 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 10:15:36 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <51385985.2000405@web.de> References: <51385985.2000405@web.de> Message-ID: <51385AB8.3050500@web.de> In addition to erasure codes: TCP provides /reliable/ transport. In the general case, you neither know your corruption ratio nor your drop ratio. So you cannot really determine a necessary "code strength", as you cannot predict the necessary attempts of retransmissions. The game erasure codes vs. retransmissions seems like running in a vicious circle to me. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/f8aec661/attachment.html From emmanuel.lochin at isae.fr Thu Mar 7 03:00:33 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Thu, 07 Mar 2013 12:00:33 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <51385AB8.3050500@web.de> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> Message-ID: <51387351.2060502@isae.fr> On 07/03/2013 10:15, Detlef Bosau wrote: > > In addition to erasure codes: > > TCP provides /reliable/ transport. > > In the general case, you neither know your corruption ratio nor your > drop ratio. So you cannot really determine a necessary "code > strength", as you cannot predict the necessary attempts of > retransmissions. > > The game erasure codes vs. retransmissions seems like running in a > vicious circle to me. Hi Detlef Both are complementary for me : you are faster with ARQ over small RTT and faster with erasure coding over long-delay link. EL > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/8dabebb2/attachment-0001.html From detlef.bosau at web.de Thu Mar 7 04:22:02 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 13:22:02 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <51387351.2060502@isae.fr> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> <51387351.2060502@isae.fr> Message-ID: <5138866A.9040503@web.de> Am 07.03.2013 12:00, schrieb Emmanuel Lochin: > > > Both are complementary for me : you are faster with ARQ over small RTT > and faster with erasure coding over long-delay link. So, the decision whether to do ARQ or to use erasure codes depends on what you want to achieve. A typical trade off. This is, however, different from congestion control. Congestion control has basically two - contradictory - goals: 1. Fully utilize a channel 2. Not over utilize a channel. The problem is that we, in general, don't know a channel's capacity. And in my view, the problem with VJCC is, that it doen't scale with - networks becoming larger (in terms of e.g. RTT) and - link throughputs becoming larger (actually, we talk about terabit links) and that VJCC cannot really cope with RTT and path capacity becoming non stationary. Another problem is, spoken in the analogy of control theory, that VJCC attemps to control the filling levels in a multi tank system, while we only observe whether or not "liquid is dropped somewhere" and the only possible influence is to control a single tap. And as we notice that this will not work, we invent sophisticated algorithms for controlling the tap or - which is quite modern for quite some time now - additional taps where liquid my drop. So, liquid drops not because of an overloaded system but because of an "active dropping management" - this sounds more scientific. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/407c7d4c/attachment.html From barath at ICSI.Berkeley.EDU Thu Mar 7 06:28:50 2013 From: barath at ICSI.Berkeley.EDU (Barath Raghavan) Date: Thu, 7 Mar 2013 06:28:50 -0800 Subject: [e2e] Congestion control as a hot topic in IETF References: Message-ID: <1CC9A66C-0085-4C8D-B0FF-54EC4C8696D0@icsi.berkeley.edu> Just to weigh in on our work on Decongestion Control -- Jon is right that it wasn't about making a congestion-free Internet, but rather about making the case that it's possible for an Internet-like network to achieve high goodput despite extreme packet loss. We did significant followup work beyond our 2006 HotNets paper, but it was never published. A few of the things we found: 1. The notion of dead packets, per Patterns of Congestion Collapse (Kelly, Floyd, and Shenker), is key when you have a protocol that induces heavy loss. 2. That a refined notion of dead packets, which we called zombie packets, reflected the true loss of capacity when using Decongestion Control. The idea is that if an eventually-dropped packet is wasting network resources that could have been used by packets that would have contributed to overall goodput, then the packet is a zombie packet. 3. For networks structured like those of backbone ISPs (circa 2008), firehose Decongestion Control, in which senders send as fast as possible, would result in poor network-wide goodput due to high zombie packet rates. However, another approach, ratio Decongestion Control, in which senders send at a fixed fraction above their goodput, achieved near optimal goodput (we used 20% -- i.e., if a flow is getting 10Mbps goodput, send at 12Mbps). This latter approach is aligned with a sender's incentives (i.e., there's no reason for them to send faster than their goodput), and yet also yields good performance from the network's perspective. The bottom line for me was that it's possible to run a network like this, and that if done right (as we found in our implementation), you don't even have to use rateless codes to mask most losses if you have a decent SACK-like mechanism (making the coding cost minimal to zero depending on the type of flow). -Barath On Mar 6, 2013, at 3:29 PM, Jon Crowcroft wrote: > well I beg to differ about this work being about > a "congestion control free" internet > > the decongestion control idea involves (as well as xor coding) > a) fairness support at the edges of the net (under specified) > and > b) active queue management in the core (a decent implemenation > would need the same sort of virtual queue mechanisms a lot of > decent ECN implemenations have looked at) > > so while the work is cool (for sure) and I am definitely in favour > of exploring the design space, it doesn't amount really to > just "everyone send as fast as they can" at all - that doesn't seem > a fair way to describe it > > > so i'd claim it is still congestion control, just with a different > partitioning of the functionality than a purist end2end (which is > just fine - i am no purist:) > > there is also the long term argument that the ratio of core to edge capacity > flips over every now and then -- see the figure in our paper > http://www.cl.cam.ac.uk/~jac22/out/ripqos-rant.pdf > and this makes a lot of things break badly (go to places where the > core nets are massively under provisioned and you'll see what > damage "just a little bit of packet loss" can do... > > > In missive <51377F9F.1080206 at isae.fr>, Emmanuel Lochin typed: > >>> >>> Hi all, >>> >>> We've attempted with success to implement a Decongestion Control >>> Transport Protocol following A. Snoeren and T. Bonald Infocom'09 paper : >>> "Is the law of Jungle sustainable for the Internet". We defined an >>> "Anarchical Networks" scenario and tested our proposal named DCTP with >>> Achoo (proposed by A. Snoeren) over a simulated ISP-like topology. >>> Preliminary results tend to confirm that both Snoeren and Bonald are >>> right and that such architecture is sustainable. >>> You'll find our first experiments in the slides available here: >>> http://www.lochin.net/tetrysjungle.pdf >>> >>> Emmanuel >>> >>> On 05/03/2013 13:07, Scharf, Michael (Michael) wrote: >>>>> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>>>>> There has been some interesting research on whether a >>>>> transport protocol could work without any congestion control. >>>>> One reference is: B. Raghavan and A. Snoeren, "Decongestion >>>>> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >>>>> I remember that you, some years ago, asked whether networking >>>>> can be done without flow control. >>>> My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. >>>> >>>> Michael >>> >>> >>> -- >>> Emmanuel Lochin >>> Professeur ISAE - OSSI >>> Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) >>> Issu du rapprochement SUPAERO et ENSICA >>> 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 >>> Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 >>> Web : http://personnel.isae.fr/emmanuel-lochin/ >>> --- >>> "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" >>> >>> > > cheers > > jon > > From detlef.bosau at web.de Thu Mar 7 13:58:34 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 22:58:34 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> Message-ID: <51390D8A.6020508@web.de> Am 06.03.2013 08:20, schrieb Jon Crowcroft: > congestion control does work on some single links if the link layer > supports a congestion feedback mechanism - switched ethernet (for > example) has a feedback mechanism and some people have used this in > data center modifications and used it to push the later 2 feedback > up (as well as back) to IP/TCP - ie trigger ECN from the layer 2 Assumed that ECN is not lost. > > this could easily also be done with contention information in > conventional and wireless ethernet on a single link > and could be triggerd from a cellular base station too if > you like > > but it isn't > > but it could be... Frankly spoken, I don't see the need for congestion control in mobile links and WiFi. In these networks, we hardly have a full packet on the link, so sliding window per se is nonsense in these technologies. A simple use of stop'n wait would solve the problem. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From jon.crowcroft at cl.cam.ac.uk Thu Mar 7 14:02:11 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 7 Mar 2013 22:02:11 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51390D8A.6020508@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> Message-ID: What has the wireless link got to do with it? The same is true of a wire. The contention is for shared media, or shared buffer. On 7 Mar 2013 21:58, "Detlef Bosau" wrote: > Am 06.03.2013 08:20, schrieb Jon Crowcroft: > >> congestion control does work on some single links if the link layer >> supports a congestion feedback mechanism - switched ethernet (for >> example) has a feedback mechanism and some people have used this in >> data center modifications and used it to push the later 2 feedback >> up (as well as back) to IP/TCP - ie trigger ECN from the layer 2 >> > > Assumed that ECN is not lost. > >> >> this could easily also be done with contention information in >> conventional and wireless ethernet on a single link >> and could be triggerd from a cellular base station too if >> you like >> >> but it isn't >> >> but it could be... >> > > Frankly spoken, I don't see the need for congestion control in mobile > links and WiFi. In these networks, we hardly have a full packet on the > link, so sliding window per se is nonsense in these technologies. A simple > use of stop'n wait would solve the problem. > > > -- > ------------------------------**------------------------------**------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/c9c7367d/attachment.html From detlef.bosau at web.de Thu Mar 7 14:03:50 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 23:03:50 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51377783.50708@isi.edu> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51377783.50708@isi.edu> Message-ID: <51390EC6.7050708@web.de> Am 06.03.2013 18:06, schrieb Bob Braden: > Jon, > > It appears that we missed this one in the Host Requirements RFC > (RFC1122). When we update RF1122 > ;-)) we can include this in the link/Internet layer interface (section > 2.4). It is also related to the "advice" > suggested for dead gateway detection ( see Discussion in Section 3.3.1.4) > > Bob > This is a fundamental change to RFC 791. IIRC, such an interface was mentioned in Cerfs catenet-paper. In RFC 791, there is no flow control on links, neither congestion control, link overload is "signaled" implicitly by packet loss. (Reliable by nature: loss cannot get lost.) I'm not quite sure whether link layer flow control may lead to deadlock situations because circular waiting scenarios can be possible. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Thu Mar 7 14:05:55 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 07 Mar 2013 23:05:55 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> Message-ID: <51390F43.9090700@web.de> Am 07.03.2013 23:02, schrieb Jon Crowcroft: > > What has the wireless link got to do with it? The same is true of a > wire. The contention is for shared media, or shared buffer. > Hm. Does a wired link always keep only one packet or less? ;-) This is the difference here: The capacity. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130307/df57992c/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Thu Mar 7 15:22:21 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Thu, 07 Mar 2013 23:22:21 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51390F43.9090700@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> Message-ID: hunh? a wire is just a channel no different from free space except for interference and possibly slower than speed of light RF propagation, and, depending on technology, lower interference and lower path loss the channel is irrelevant to this discusson, except that a wireless channel may be shared so you can see contention for the receive antennae (some people talk about contention for the media too, but that's a figment of the technology of choice for MAC)... so i have no idea where you think packets are stored except in senders' and receivers' NICs' buffers.... you need to haev a REALLY long haul link to get a lot of packets in transit (propagation) - these are unusual cases (satellites) basically (comms #101) - you have the packet serialisation time (s=clock speed*packet length) and you have the packet propagation time (p=link geodistance / c) so the case of packets in transit is plural, is when p/s > 1 which is not too many cases... anyhow that's not what congestion or contention are about In missive <51390F43.9090700 at web.de>, Detlef Bosau typed: >>Am 07.03.2013 23:02, schrieb Jon Crowcroft: >>> >>> What has the wireless link got to do with it? The same is true of a >>> wire. The contention is for shared media, or shared buffer. >>Hm. Does a wired link always keep only one packet or less? ;-) >>This is the difference here: The capacity. not really. >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>--------------070804030003020405080909 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> > http-equiv="Content-Type"> >> >> >>
Am 07.03.2013 23:02, schrieb Jon >> Crowcroft:
>>
>>
>cite="mid:CAEeTejKADW=djTrj=H3hGEfYo62B2R3KvHgCM_m3W9JeaPSGhw at mail.gmail.com" >> type="cite"> >> >>

What has the wireless link got to do with it? The same is true >> of a wire. The contention is for shared media, or shared buffer.

>>
>>
>> Hm. Does a wired link always keep only one packet or less? > class="moz-smiley-s3"> ;-)
>>
>> This is the difference here: The capacity.
>> 
-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30   
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                           mobile: +49 172 6819937
 >>                                           skype:     detlef.bosau
 >>                                           ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>
 >>
>> >> >> >>--------------070804030003020405080909-- cheers jon From emmanuel.lochin at isae.fr Fri Mar 8 01:09:22 2013 From: emmanuel.lochin at isae.fr (Emmanuel Lochin) Date: Fri, 08 Mar 2013 10:09:22 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <1CC9A66C-0085-4C8D-B0FF-54EC4C8696D0@icsi.berkeley.edu> References: <1CC9A66C-0085-4C8D-B0FF-54EC4C8696D0@icsi.berkeley.edu> Message-ID: <5139AAC2.8090005@isae.fr> On 07/03/2013 15:28, Barath Raghavan wrote: > Just to weigh in on our work on Decongestion Control -- Jon is right that it wasn't about making a congestion-free Internet, but rather about making the case that it's possible for an Internet-like network to achieve high goodput despite extreme packet loss. > > We did significant followup work beyond our 2006 HotNets paper, but it was never published. A few of the things we found: > > 1. The notion of dead packets, per Patterns of Congestion Collapse (Kelly, Floyd, and Shenker), is key when you have a protocol that induces heavy loss. > > 2. That a refined notion of dead packets, which we called zombie packets, reflected the true loss of capacity when using Decongestion Control. The idea is that if an eventually-dropped packet is wasting network resources that could have been used by packets that would have contributed to overall goodput, then the packet is a zombie packet. > > 3. For networks structured like those of backbone ISPs (circa 2008), firehose Decongestion Control, in which senders send as fast as possible, would result in poor network-wide goodput due to high zombie packet rates. However, another approach, ratio Decongestion Control, in which senders send at a fixed fraction above their goodput, achieved near optimal goodput (we used 20% -- i.e., if a flow is getting 10Mbps goodput, send at 12Mbps). This latter approach is aligned with a sender's incentives (i.e., there's no reason for them to send faster than their goodput), and yet also yields good performance from the network's perspective. Hi Barath, Did you use Achoo for your experiments or did you slide to another mechanism? We've developed our own ns-2 Achoo prototype to compare with our Tetrys proposal and noticed some limitation of Achoo when the RTT increases (might be due to the fact that Achoo remains a block erasure coding scheme). If you have a pseudo code or any prototype of Achoo, we will be interested in to allow a fair comparison. Emmanuel > > The bottom line for me was that it's possible to run a network like this, and that if done right (as we found in our implementation), you don't even have to use rateless codes to mask most losses if you have a decent SACK-like mechanism (making the coding cost minimal to zero depending on the type of flow). > > -Barath > > On Mar 6, 2013, at 3:29 PM, Jon Crowcroft wrote: > >> well I beg to differ about this work being about >> a "congestion control free" internet >> >> the decongestion control idea involves (as well as xor coding) >> a) fairness support at the edges of the net (under specified) >> and >> b) active queue management in the core (a decent implemenation >> would need the same sort of virtual queue mechanisms a lot of >> decent ECN implemenations have looked at) >> >> so while the work is cool (for sure) and I am definitely in favour >> of exploring the design space, it doesn't amount really to >> just "everyone send as fast as they can" at all - that doesn't seem >> a fair way to describe it >> >> >> so i'd claim it is still congestion control, just with a different >> partitioning of the functionality than a purist end2end (which is >> just fine - i am no purist:) >> >> there is also the long term argument that the ratio of core to edge capacity >> flips over every now and then -- see the figure in our paper >> http://www.cl.cam.ac.uk/~jac22/out/ripqos-rant.pdf >> and this makes a lot of things break badly (go to places where the >> core nets are massively under provisioned and you'll see what >> damage "just a little bit of packet loss" can do... >> >> >> In missive <51377F9F.1080206 at isae.fr>, Emmanuel Lochin typed: >> >>>> Hi all, >>>> >>>> We've attempted with success to implement a Decongestion Control >>>> Transport Protocol following A. Snoeren and T. Bonald Infocom'09 paper : >>>> "Is the law of Jungle sustainable for the Internet". We defined an >>>> "Anarchical Networks" scenario and tested our proposal named DCTP with >>>> Achoo (proposed by A. Snoeren) over a simulated ISP-like topology. >>>> Preliminary results tend to confirm that both Snoeren and Bonald are >>>> right and that such architecture is sustainable. >>>> You'll find our first experiments in the slides available here: >>>> http://www.lochin.net/tetrysjungle.pdf >>>> >>>> Emmanuel >>>> >>>> On 05/03/2013 13:07, Scharf, Michael (Michael) wrote: >>>>>> Am 04.03.2013 23:07, schrieb Scharf, Michael (Michael): >>>>>>> There has been some interesting research on whether a >>>>>> transport protocol could work without any congestion control. >>>>>> One reference is: B. Raghavan and A. Snoeren, "Decongestion >>>>>> Control", ACM SIGCOMM Workshop on Hot Topics in Networks, 2006. >>>>>> I remember that you, some years ago, asked whether networking >>>>>> can be done without flow control. >>>>> My comment is about network designs that typically assume erasure codes and flow-based queueing/scheduling in all network nodes. Actually, it took me a while to fully understand why this is no alternative to the way Internet congestion control works today. But, for what it is worth, I found the overall idea intesting. >>>>> >>>>> Michael >>>> >>>> -- >>>> Emmanuel Lochin >>>> Professeur ISAE - OSSI >>>> Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) >>>> Issu du rapprochement SUPAERO et ENSICA >>>> 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 >>>> Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 >>>> Web : http://personnel.isae.fr/emmanuel-lochin/ >>>> --- >>>> "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" >>>> >>>> >> cheers >> >> jon >> >> > > -- Emmanuel Lochin Professeur ISAE - OSSI Institut Sup?rieur de l'A?ronautique et de l'Espace (ISAE) Issu du rapprochement SUPAERO et ENSICA 10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 Web : http://personnel.isae.fr/emmanuel-lochin/ --- "This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" From Martin.Heusse at imag.fr Fri Mar 8 02:59:39 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Fri, 8 Mar 2013 11:59:39 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> Message-ID: ?Or the link uses interleaving: in ADSL, it's generally done over 17ms, so on a 20Mb/s link, that's ~28 packets (1500B long) in flight (one way!)? Same thing with UMTS (it's less striking with HSDPA's 2ms TTI)(although sometimes the Node B backhaul is DSL?) Martin Le 8 mars 2013 ? 00:22, Jon Crowcroft a ?crit : > you need to haev a REALLY long haul link to get a lot of packets > in transit (propagation) - these are unusual cases (satellites) From detlef.bosau at web.de Fri Mar 8 05:51:40 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 08 Mar 2013 14:51:40 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> Message-ID: <5139ECEC.5020702@web.de> Am 08.03.2013 00:22, schrieb Jon Crowcroft: > hunh? Likewise :-) > > a wire is just a channel no different from free space > except for interference and possibly slower than speed of light RF > propagation, and, depending on technology, lower interference and > lower path loss from a very abstract level you're right. However: From that abstract level we don't talk about interference and path loss. Because from that abstract level, we apply Shannon-Hartley and are simply fine. Particularly, no channel suffers from "path loss". It's not the channel, where packets/blocks are lost. It's the receiver who discards nonsense with defective CRC, if he is told to do so. NB: This is definitely not the case for wireless speech connections. Because there is no CRC check at all. the channel is irrelevant to this discusson, except that a wireless I strongly disagree. The whole VJCC is based upon Little's law. So, for VJCC, a channel is characterized by exactly four proberties. P1: A path capacity. P2: A path RTT. P3: Capacity and RTT are not necessarily constant but: at least (quasi-)stationary. P4: A loss rate, which is necessarily negligible. That's all - and these are the four inevitably required necessary conditions for VJCC to work. (If these conditions do not hold, VJCC does something. And TCP behaves somehow. However, this behaviour has hardly anything to do with the congavoid paper and what we expect as "Congestion Control".) > channel may be shared so you can see contention for the receive > antennae (some people talk about contention for the media too, but > that's a figment of the technology of choice for MAC)... > > so i have no idea where you think packets are stored except in > senders' and receivers' NICs' buffers.... This is an academic question. However: If no data were stored along the channels, there would be no need for flow control and congestion control, we could employ a wired handshake as in V.24 with RTS/CTS, DSR/DTR. VJCC does not make a difference whether data is stored in buffers or along the channel. > > > you need to haev a REALLY long haul link to get a lot of packets > in transit (propagation) - these are unusual cases (satellites) and intercontinental fibres - and it's that "irrelevant" that BIC and CuBIC have been proposed. > basically (comms #101) - you have the > packet serialisation time (s=clock speed*packet length) That's another point where I strongly disagree. The term "serialization delay" is, frankly spoken, complete nonsense in the context of wireless networks. We can talk about service times for a block/packet to be successfully delivered along a wireless channel. Hence, we can talk about capacity/service time/loss rate for a wireless channel. It does, however, make ABSOLUTELY NO SENSE to talk about serialization delays in thes context. (I did not yet have a look at the NS3, so I don't know whether this was changed. What's used in the NS2 in this context is simply complete nonsense. The model used there is simply completely wrong. Although I will ask for additional memory for my mailbox for the next two hours to have capacity for the rants, I'm "looking forward to".) (From what I'm told, CS guys are polite and well behaved. They do not rant, but on some occasions they throw chairs ;-)) > and you have the packet propagation time (p=link geodistance / c) Which is of no interest for VJCC because it's encapsulated in the service time. > so the case of packets in transit is plural, is when p/s > 1 > which is not too many cases... > > anyhow that's not what congestion or contention are about If the path's capacity is sufficiently low (which is almost certainly the case in terrestrial wireless networks) I agree. So, I said we can use stop'n wait. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130308/5ea73def/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Fri Mar 8 06:00:25 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 08 Mar 2013 14:00:25 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5139ECEC.5020702@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> Message-ID: congestion/contention involve multiple senders competing for a resource, and partitioning the use of that resource when you have multiple packets in flight (sure, intercontinental fiber a bit, and ong haul radio links more) then sure but the origins of the scheme are shared resource in the sense of the output link at the the bottleneck as measured by a queue building in the buffer just behind that the media type of the link up to that point is irrelevant. the capacity is btw, path loss is very real (and not at the antennae) - in freespace, with omnidorectional antennae its a feature of inverse square law of spreading the signal over a speherical surface ...plus there's atenuuation from signal energy being absorped (e.g. by water vapour or concrete) - etc etc your mixing it up with interference with concurrent senders o nthe receive antennae (which is fixable using mimo and smart processing - viz http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p235.pdf >>Am 08.03.2013 00:22, schrieb Jon Crowcroft: >>> hunh? >> >>Likewise :-) >> >>> >>> a wire is just a channel no different from free space >>> except for interference and possibly slower than speed of light RF >>> propagation, and, depending on technology, lower interference and >>> lower path loss >> >>from a very abstract level you're right. However: From that abstract >>level we don't talk about interference and path loss. >>Because from that abstract level, we apply Shannon-Hartley and are >>simply fine. >> >>Particularly, no channel suffers from "path loss". It's not the channel, >>where packets/blocks are lost. It's the receiver who discards nonsense >>with defective CRC, if he is told to do so. NB: This is definitely not >>the case for wireless speech connections. Because there is no CRC check >>at all. >> >> >>the channel is irrelevant to this discusson, except that a wireless >> >> >>I strongly disagree. The whole VJCC is based upon Little's law. So, for >>VJCC, a channel is characterized by exactly four proberties. >> >>P1: A path capacity. >>P2: A path RTT. >>P3: Capacity and RTT are not necessarily constant but: at least >>(quasi-)stationary. >>P4: A loss rate, which is necessarily negligible. >> >>That's all - and these are the four inevitably required necessary >>conditions for VJCC to work. >> >>(If these conditions do not hold, VJCC does something. And TCP behaves >>somehow. However, this behaviour has hardly anything to do with the >>congavoid paper and what we expect as "Congestion Control".) >> >>> channel may be shared so you can see contention for the receive >>> antennae (some people talk about contention for the media too, but >>> that's a figment of the technology of choice for MAC)... >>> >>> so i have no idea where you think packets are stored except in >>> senders' and receivers' NICs' buffers.... >> >>This is an academic question. However: If no data were stored along the >>channels, there would be no need for flow control and congestion >>control, we could employ a wired handshake as in V.24 with RTS/CTS, DSR/DTR. >> >> >>VJCC does not make a difference whether data is stored in buffers or >>along the channel. >> >>> >>> >>> you need to haev a REALLY long haul link to get a lot of packets >>> in transit (propagation) - these are unusual cases (satellites) >>and intercontinental fibres - and it's that "irrelevant" that BIC and >>CuBIC have been proposed. >> >> >>> basically (comms #101) - you have the >>> packet serialisation time (s=clock speed*packet length) >> >>That's another point where I strongly disagree. The term "serialization >>delay" is, frankly spoken, complete nonsense in the context of wireless >>networks. >> >>We can talk about service times for a block/packet to be successfully >>delivered along a wireless channel. >> >>Hence, we can talk about capacity/service time/loss rate for a wireless >>channel. It does, however, make ABSOLUTELY NO SENSE to talk about >>serialization delays in thes context. >> >>(I did not yet have a look at the NS3, so I don't know whether this was >>changed. What's used in the NS2 in this context is simply complete >>nonsense. The model used there is simply completely wrong. Although I >>will ask for additional memory for my mailbox for the next two hours to >>have capacity for the rants, I'm "looking forward to".) >> >>(From what I'm told, CS guys are polite and well behaved. They do not >>rant, but on some occasions they throw chairs ;-)) >> >>> and you have the packet propagation time (p=link geodistance / c) >> >>Which is of no interest for VJCC because it's encapsulated in the >>service time. >> >>> so the case of packets in transit is plural, is when p/s > 1 >>> which is not too many cases... >>> >>> anyhow that's not what congestion or contention are about >> >>If the path's capacity is sufficiently low (which is almost certainly >>the case in terrestrial wireless networks) I agree. >> >>So, I said we can use stop'n wait. >> >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>--------------080605040504040009030400 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> > http-equiv="Content-Type"> >> >> >>
Am 08.03.2013 00:22, schrieb Jon >> Crowcroft:
>>
>>
> type="cite"> >> 
hunh?
>>
>>
>> Likewise :-)
>>
>>
> type="cite"> >> 
 >>
 >>a wire is just a channel no different from free space
 >>except for interference and possibly slower than speed of light RF
 >>propagation, and, depending on technology, lower interference and
 >>lower path loss
>>
>>
>> from a very abstract level you're right. However: From that abstract >> level we don't talk about interference and path loss.
>> Because from that abstract level, we apply Shannon-Hartley and are >> simply fine.
>>
>> Particularly, no channel suffers from "path loss". It's not the >> channel, where packets/blocks are lost. It's the receiver who >> discards nonsense with defective CRC, if he is told to do so. NB: >> This is definitely not the case for wireless speech connections. >> Because there is no CRC check at all.
>> 
 >>
 >>the channel is irrelevant to this discusson, except that a wireless
>>
>> I strongly disagree. The whole VJCC is based upon Little's law. So, >> for VJCC, a channel is characterized by exactly four proberties.
>>
>> P1: A path capacity.
>> P2: A path RTT.
>> P3: Capacity and RTT are not necessarily constant but: at least (quasi-)stationary.
>> P4: A loss rate, which is necessarily negligible.
>>
>> That's all - and these are the four inevitably required necessary >> conditions for VJCC to work.
>>
>> (If these conditions do not hold, VJCC does something. And TCP >> behaves somehow. However, this behaviour has hardly anything to do >> with the congavoid paper and what we expect as "Congestion >> Control".)
>>
>>
> type="cite"> >> 
 >>channel may be shared so you can see contention for the receive
 >>antennae (some people talk about contention for the media too, but
 >>that's a figment of the technology of choice for MAC)...
 >>
 >>so i have no idea where you think packets are stored except in
 >>senders' and receivers' NICs' buffers....
>>
>>
>> This is an academic question. However: If no data were stored along >> the channels, there would be no need for flow control and congestion >> control, we could employ a wired handshake as in V.24 with RTS/CTS, >> DSR/DTR.
>>
>>
>> VJCC does not make a difference whether data is stored in buffers or >> along the channel.
>>
>>
> type="cite"> >> 
 >>
 >>
 >>you need to haev a REALLY long haul link to get a lot of packets
 >>in transit (propagation) - these are unusual cases (satellites)
 >>
>>
>> and intercontinental fibres - and it's that "irrelevant" that BIC >> and CuBIC have been proposed.
>>
>>
>>
> type="cite"> >> 
 >>basically (comms #101) - you have the 
 >>packet serialisation time (s=clock speed*packet length)
>>
>>
>> That's another point where I strongly disagree. The term >> "serialization delay" is, frankly spoken, complete nonsense in the >> context of wireless networks.
>>
>> We can talk about service times for a block/packet to be >> successfully delivered along a wireless channel.
>>
>> Hence, we can talk about capacity/service time/loss rate for a >> wireless channel. It does, however, make ABSOLUTELY NO SENSE to talk >> about serialization delays in thes context.
>>
>> (I did not yet have a look at the NS3, so I don't know whether this >> was changed. What's used in the NS2 in this context is simply >> complete nonsense. The model used there is simply completely wrong. >> Although I will ask for additional memory for my mailbox for the >> next two hours to have capacity for the rants, I'm "looking forward >> to".)
>>
>> (From what I'm told, CS guys are polite and well behaved. They do >> not rant, but on some occasions they throw chairs ;-))
>>
>>
> type="cite"> >> 
 >>and you have the packet propagation time (p=link geodistance / c)
 >>
>>
>>
>> Which is of no interest for VJCC because it's encapsulated in the >> service time.
>>
>>
> type="cite"> >> 
 >>so the case of packets in transit is plural, is when p/s  > 1
 >>which is not too many cases...
 >>
 >>anyhow that's not what congestion or contention are about
 >>
>>
>>
>> If the path's capacity is sufficiently low (which is almost >> certainly the case in terrestrial wireless networks) I agree.
>>
>> So, I said we can use stop'n wait.
>>  
>>
>> 
-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30   
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                           mobile: +49 172 6819937
 >>                                           skype:     detlef.bosau
 >>                                           ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>
 >>
>> >> >> >>--------------080605040504040009030400-- cheers jon From jon.crowcroft at cl.cam.ac.uk Fri Mar 8 06:28:47 2013 From: jon.crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 8 Mar 2013 14:28:47 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5139ECEC.5020702@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> Message-ID: actually packets stored in the channel may not have contended for the channel, whereas packets arriving at a queue are contending for the output to that queue.... this leads to an interesting model of shadow pricing - its a bit like changing he solid angle subtended by the source On Fri, Mar 8, 2013 at 1:51 PM, Detlef Bosau wrote: > Am 08.03.2013 00:22, schrieb Jon Crowcroft: > > hunh? > > > Likewise :-) > > > a wire is just a channel no different from free space > except for interference and possibly slower than speed of light RF > propagation, and, depending on technology, lower interference and > lower path loss > > > from a very abstract level you're right. However: From that abstract level > we don't talk about interference and path loss. > Because from that abstract level, we apply Shannon-Hartley and are simply > fine. > > Particularly, no channel suffers from "path loss". It's not the channel, > where packets/blocks are lost. It's the receiver who discards nonsense with > defective CRC, if he is told to do so. NB: This is definitely not the case > for wireless speech connections. Because there is no CRC check at all. > > the channel is irrelevant to this discusson, except that a wireless > > > I strongly disagree. The whole VJCC is based upon Little's law. So, for > VJCC, a channel is characterized by exactly four proberties. > > P1: A path capacity. > P2: A path RTT. > P3: Capacity and RTT are not necessarily constant but: at least (quasi-) > stationary. > P4: A loss rate, which is necessarily negligible. > > That's all - and these are the four inevitably required necessary > conditions for VJCC to work. > > (If these conditions do not hold, VJCC does something. And TCP behaves > somehow. However, this behaviour has hardly anything to do with the > congavoid paper and what we expect as "Congestion Control".) > > > channel may be shared so you can see contention for the receive > antennae (some people talk about contention for the media too, but > that's a figment of the technology of choice for MAC)... > > so i have no idea where you think packets are stored except in > senders' and receivers' NICs' buffers.... > > > This is an academic question. However: If no data were stored along the > channels, there would be no need for flow control and congestion control, > we could employ a wired handshake as in V.24 with RTS/CTS, DSR/DTR. > > > VJCC does not make a difference whether data is stored in buffers or along > the channel. > > > you need to haev a REALLY long haul link to get a lot of packets > in transit (propagation) - these are unusual cases (satellites) > > and intercontinental fibres - and it's that "irrelevant" that BIC and > CuBIC have been proposed. > > > > basically (comms #101) - you have the > packet serialisation time (s=clock speed*packet length) > > > That's another point where I strongly disagree. The term "serialization > delay" is, frankly spoken, complete nonsense in the context of wireless > networks. > > We can talk about service times for a block/packet to be successfully > delivered along a wireless channel. > > Hence, we can talk about capacity/service time/loss rate for a wireless > channel. It does, however, make ABSOLUTELY NO SENSE to talk about > serialization delays in thes context. > > (I did not yet have a look at the NS3, so I don't know whether this was > changed. What's used in the NS2 in this context is simply complete > nonsense. The model used there is simply completely wrong. Although I will > ask for additional memory for my mailbox for the next two hours to have > capacity for the rants, I'm "looking forward to".) > > (From what I'm told, CS guys are polite and well behaved. They do not > rant, but on some occasions they throw chairs ;-)) > > > and you have the packet propagation time (p=link geodistance / c) > > > Which is of no interest for VJCC because it's encapsulated in the service > time. > > > so the case of packets in transit is plural, is when p/s > 1 > which is not too many cases... > > anyhow that's not what congestion or contention are about > > > If the path's capacity is sufficiently low (which is almost certainly the > case in terrestrial wireless networks) I agree. > > So, I said we can use stop'n wait. > > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673detlef.bosau at web.de http://www.detlef-bosau.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130308/e424f58e/attachment.html From detlef.bosau at web.de Fri Mar 8 07:33:18 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 08 Mar 2013 16:33:18 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> Message-ID: <513A04BE.4060505@web.de> Am 08.03.2013 15:00, schrieb Jon Crowcroft: > congestion/contention > involve multiple senders competing for a resource, > and partitioning the use of that resource > > when you have multiple packets in flight (sure, intercontinental fiber a bit, and ong haul radio links more) then > sure but the origins of the scheme are shared resource in the sense of the output link at the > the bottleneck as measured by a queue building in the buffer just behind that > > the media type of the link up to that point is irrelevant. the capacity is As I said above: For VJCC, it simply doesn't matter, /where/ any packet in flight resides, the packet is in flight and that's it. > > btw, path loss is very real (and not at the antennae) no. Or can you tell me where the waves have gone? Where the energy has gone? Data corruption is a phenomenon which occurs at the receiver. The problem is that the receiver cannot successfully rebuild a packet from what he received. The air interface has no idea of which waves are travelling along and whether they make any sense at all. > - in freespace, with omnidorectional antennae its > a feature of inverse square law of spreading the signal over a speherical surface ...plus > there's atenuuation from signal energy being absorped (e.g. by water vapour or concrete) - etc etc that are wonderful formulae for the received power. They don't tell you whether a packet will be successfully read. And that's why I said formulae, which describe a "bandwidth" depending on the distance base-station/mobile, I referred to "Modelling Computer Networks for Emulation" by Rothermel, Herrscher, Leonhardi from 2002, are pleasant to read, however the model is completely nonsense. And I wonder, why no communication engineer and no signalling theorist has made objections here so far, sometimes I think these guys simply ignore us CS guys because we would continue telling nonsense here and no one wants to spend his time in useless arguments. I thin, CE and EE guys simply don't take us seriously. > > your mixing it up with interference with concurrent senders o nthe receive antennae (which is fixable using mimo and > smart processing - viz > http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p235.pdf I don't think so. In that paper, one discusses and uses an "effictive SNR algorithm", is this correct? And where can you derive a throughput from the SNR? Do you mix up signal power and data rate? If so, you simply misunderstood the Shannon-Hartley Law. You may wonder why I get a bit upset here. However, a whole research project of mine yielded no results and it took years to understand, that people simply pulled my leg here. I wasted 4 years of my life for this research completely and years afterwards for indirect consequences. So, please let's spare discussions on elementary signalling theory. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130308/622542f3/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Fri Mar 8 07:54:53 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Fri, 08 Mar 2013 15:54:53 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <513A04BE.4060505@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> Message-ID: In missive <513A04BE.4060505 at web.de>, Detlef Bosau typed: >>> btw, path loss is very real (and not at the antennae) >>no. >>Or can you tell me where the waves have gone? Where the energy has gone? this is physics #101 - if you transmit with some power level, and spread that over a distance, guess what, at a distance with a signal that is spreading out over a surface, the power level is lower eventually the signal (to background noise) is too low level to carry any info in any way distinguishable >>Data corruption is a phenomenon which occurs at the receiver. The >>problem is that the receiver cannot successfully rebuild a packet from >>what he received. The air interface has no idea of which waves are >>travelling along and whether they make any sense at all. you're confusing interference with other sources and misreading the honorably Dave Reed secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter) and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading) >>> - in freespace, with omnidorectional antennae its >>> a feature of inverse square law of spreading the signal over a speherical surface ...plus >>> there's atenuuation from signal energy being absorped (e.g. by water vapour or concrete) - etc etc >>that are wonderful formulae for the received power. They don't tell you >>whether a packet will be successfully read. And that's why I said >>formulae, which describe a "bandwidth" depending on the distance >>base-station/mobile, I referred to "Modelling Computer Networks for >>Emulation" by Rothermel, Herrscher, Leonhardi from 2002, are pleasant to >>read, however the model is completely nonsense. there are simple formulae for path loss - however you need to run them in immensely complex physical environments, which is why most people rely on measurement... >>And I wonder, why no communication engineer and no signalling theorist >>has made objections here so far, sometimes I think these guys simply >>ignore us CS guys because we would continue telling nonsense here and no >>one wants to spend his time in useless arguments. I thin, CE and EE guys >>simply don't take us seriously. well, i kind of have a physics degree as well as a CS masters and PhD so I beg to differ... >>> your mixing it up with interference with concurrent senders o nthe receive antennae (which is fixable using mimo and >>> smart processing - viz >>> http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p235.pdf >>I don't think so. In that paper, one discusses and uses an "effictive >>SNR algorithm", is this correct? >>And where can you derive a throughput from the SNR? Do you mix up signal >>power and data rate? If so, you simply misunderstood the Shannon-Hartley >>Law. >>You may wonder why I get a bit upset here. However, a whole research >>project of mine yielded no results and it took years to understand, that >>people simply pulled my leg here. I wasted 4 years of my life for this >>research completely and years afterwards for indirect consequences. >> >>So, please let's spare discussions on elementary signalling theory. this isn't elemntary signalling theory, its elementary physics... once you know the power level at a receiver, then you can do shannon... (and with multiple antennae, the mondodb clever stuff to extract max signal...) but you still have to worry about propagation if this wasn't the case, we'd all be toast because of all the incipient power on all of us from all the sources around us adding to infinity (oh, ok there's quantum effects to limit that too;) j. From barath at ICSI.Berkeley.EDU Fri Mar 8 08:49:25 2013 From: barath at ICSI.Berkeley.EDU (Barath Raghavan) Date: Fri, 8 Mar 2013 08:49:25 -0800 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5139AAC2.8090005@isae.fr> References: <1CC9A66C-0085-4C8D-B0FF-54EC4C8696D0@icsi.berkeley.edu> <5139AAC2.8090005@isae.fr> Message-ID: <98EF9743-5F92-42D2-BF94-29882A6800E5@ICSI.Berkeley.EDU> On Mar 8, 2013, at 1:09 AM, Emmanuel Lochin wrote: > On 07/03/2013 15:28, Barath Raghavan wrote: >> Just to weigh in on our work on Decongestion Control -- Jon is right that it wasn't about making a congestion-free Internet, but rather about making the case that it's possible for an Internet-like network to achieve high goodput despite extreme packet loss. >> >> We did significant followup work beyond our 2006 HotNets paper, but it was never published. A few of the things we found: >> >> 1. The notion of dead packets, per Patterns of Congestion Collapse (Kelly, Floyd, and Shenker), is key when you have a protocol that induces heavy loss. >> >> 2. That a refined notion of dead packets, which we called zombie packets, reflected the true loss of capacity when using Decongestion Control. The idea is that if an eventually-dropped packet is wasting network resources that could have been used by packets that would have contributed to overall goodput, then the packet is a zombie packet. >> >> 3. For networks structured like those of backbone ISPs (circa 2008), firehose Decongestion Control, in which senders send as fast as possible, would result in poor network-wide goodput due to high zombie packet rates. However, another approach, ratio Decongestion Control, in which senders send at a fixed fraction above their goodput, achieved near optimal goodput (we used 20% -- i.e., if a flow is getting 10Mbps goodput, send at 12Mbps). This latter approach is aligned with a sender's incentives (i.e., there's no reason for them to send faster than their goodput), and yet also yields good performance from the network's perspective. > > Hi Barath, > > Did you use Achoo for your experiments or did you slide to another mechanism? We've developed our own ns-2 Achoo prototype to compare with our Tetrys proposal and noticed some limitation of Achoo when the RTT increases (might be due to the fact that Achoo remains a block erasure coding scheme). If you have a pseudo code or any prototype of Achoo, we will be interested in to allow a fair comparison. > > Emmanuel We used a few different implementations over the lifetime of the project, but this was years ago so unfortunately I'm not sure I have anything to share. There were two distinct focuses to our work: a) the impact on the network of large scale use of Decongestion Control and b) the design and implementation of the protocol itself. For the former, John McCullough built a flow-based simulator (to try out larger topologies than ns2 could handle). For the latter I built a Linux user-level implementation (that used library interposition to make TCP-based apps use Decongestion), and later we built a simplified ns2 implementation. You're right that there is a potential issue with the naive scheme as RTT increases -- this can be largely though not completely mitigated by a) using the ratio send approach rather than firehose, b) SACKs (ours were a bit vector of blocks received), and c) overlapping the sending of coding windows, scaling one down in rate while scaling the next up (we only partially explored this). -Barath From detlef.bosau at web.de Fri Mar 8 11:30:18 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Fri, 08 Mar 2013 20:30:18 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> Message-ID: <513A3C4A.5060805@web.de> Am 08.03.2013 16:54, schrieb Jon Crowcroft: > In missive <513A04BE.4060505 at web.de>, Detlef Bosau typed: > > >>> btw, path loss is very real (and not at the antennae) > > >>no. > > >>Or can you tell me where the waves have gone? Where the energy has gone? > > this is physics #101 - if you transmit with some power level, and spread that over a distance, guess what, at a > distance with a signal that is spreading out over a surface, the power level is lower Good answer :-) I see, you understood why the power level depends on the distance via a sqrt-Function :-) And that means what? Merely nothing. When I move around my laptop in my apartment, I use WLAN to access my DSL router, the power level will change. However: Hardly that much that the packet corruption level is affected. Unfortunately, in my appartment I see up to 8 (eight) WLANs. So, what do you think affects my data rate notebook - router? Me moving around in the apartment or my neighbours surfing the Internet? In addition, the SNR sinks continuously when moving around. The packet corruption ratio doesn't. It is a theoretical game with numbers. > > eventually the signal (to background noise) is too low level to carry any info in any way distinguishable > > > >>Data corruption is a phenomenon which occurs at the receiver. The > >>problem is that the receiver cannot successfully rebuild a packet from > >>what he received. The air interface has no idea of which waves are > >>travelling along and whether they make any sense at all. > > you're confusing interference with other sources and misreading the honorably Dave Reed I'm quite sure that I'm not misreading Dave Reed. > > secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter) > and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading) > So, a model which correctly describes wireless channels is that flexible that it fits anything - and has no use at all. I don't think I misread Dave Reed - to the contrary, in some particular respects I share his anger. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Fri Mar 8 15:41:38 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 09 Mar 2013 00:41:38 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> Message-ID: <513A7732.5010406@web.de> Am 08.03.2013 15:28, schrieb Jon Crowcroft: > actually packets stored in the channel may not have contended for the > channel, whereas packets arriving at a queue are contending for the > output to that queue.... > Even that is simply wrong. In Wifi, packets are sent in the whole: One IP packet is encapsulated in one 802.11 packet. This simply holds not true in mobile networks. E.g. in HSDPA you have 2 ms timeslots and you may change the line coding scheme, the puncturing and the wrapping about channels each and every 2 ms. You have transport blocks the payload of which may vary from about 150 bit to 12000 bit, very roughly I need to look it up. Than you have opportunistic scheduling where channels may be suspended for some time. What I read so far in CS books is simply orthogonal to reality in many cases. And the model to assign a packet a "serialization delay" is hopelessly naive and, physically, simply as wrong as could be. That's completely different from wired networks. And I really cannot imagine that I'm the only one here to see this. One immediate consequence is that the annoying discussion about "spurious time outs" is nonsense. The RTO in TCP is a confidence interval derived, by Cantelli's inequality, from expectation and variance of the/, so assuemed, //stationary /RTT. (See Edge's paper, the congavoid paper etc.) (Cantelli's inequality is a special case of Chebysheff's inequality.) Of course, you can put RTT "measurements" into an EWMA filter (garbage in garbage out principle), put this into Cantelli's inequality and get (again garbage in garbage out) an RTO statistics. You can easier take 15. (No matter if seconds or hours.) This is as wrong as the other RTO formulae but easier to implement. However, if we use an RTO determined by pure hand waving, how can we really claim this to be a confidence interval and say that ACKs are "late"? And what's particular annoying: I'm neither the first one to claim so neither the only one. E.g. Raj Jain and Lixia Zhang published on the deficiencies of timers nearly 25 years ago! This is really old and accepted basic knowledge! Why is this ignored? You referred to Dave Reed some posts ago, from quite some PM exchange I very well know Dave's anger about formulae, which are mistaken for reality, and the ignorance of the community against physical reality which is around everywhere! And for decades we modelled "bandwidths" in our simulators as "serialization delay" in wired networks and mobile networks as well. except some very few extensions, e.g. the EURANE extensions to the NS2, and wonder why simulators yield exactly the wrong results we previously encoded in them! As you may notice, I'm extremely upset about this! It may sound cynical, however I'm not employed with any university at the moment, so there is no professor to fire me tomorrow morning because I wrote this post. And believe me, this attitude is anything than unfamiliar to me. If someone points to physical reality and violates some dogmatic "laws", he is most likely to be at least severely berated he must not damage the reputation of his employer. However, wrong statements are not corrected by berating students, PhD students or research assistants! Wrong statements are only corrected by correct ones! -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130309/d72ede51/attachment.html From Martin.Heusse at imag.fr Sat Mar 9 01:37:18 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Sat, 9 Mar 2013 10:37:18 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <1362759740.38291122@apps.rackspace.com> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lu cent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lu cent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <1362759740.38291122@apps.rackspace.com> Message-ID: <805E7EAB-8680-434E-BB8D-821273876120@imag.fr> The key word was "interleaving". Martin Le 8 mars 2013 ? 17:22, dpreed at reed.com a ?crit : > Huh? At the speed of light, 17 ms. is 0.017*299,792,458 meters. What ADSL link is that long? > From Jon.Crowcroft at cl.cam.ac.uk Sat Mar 9 02:21:54 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 09 Mar 2013 10:21:54 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <513A7732.5010406@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A7732.5010406@web.de> Message-ID: not sure why you are annoyed.... serialisation delays are the time taken to clock a packet on to a channel - this isn't some figment - there's a coding method and a modulation technique - there's a signal which is modulated and a nyquist limit for the symbol rate you can get out of the signal so the physics impose a delay to get all the bits of a packet on to the channel. then the speed of light (or lower - your milegage may vary in different media) imposes a propagation delay you may dice and slice the channel in some time vaying manner (indeed you often do) but it is a resource which is going to have a limit for you - and if it is shared with other people (whether on a per packet basis, or slot/cell (e.g. atm multiplexed dsl line, or packet interleaving on some wireless links) there's a limit imposed by other people on what you can send (or by you on others) - that's contention for the channel - it isn't magic then there's contention for the buffer in a bottleneck switch just before any contended link - persistent contention leads to queues building, and eventual buffer overrun or, as some call it, congestion.... I'm not modeling bandwidth as serialisation delay, by the way - i am not sure where you think i said that - what I am saying is that there are a number of contributions to the delay across a hop and yes, it is quite complex to get a good model - but a relatively simple feedback based controller (esp. if you use some decent control theory and decent filters to manage the noise in the feedback, and especially if you have explicit feedback from the switch with a building queue, and perhaps from the switch if it has detailed knowledge of the channel contention (e.g. from looking at number of sources, which you can't see as a lone sender (for lots of reasons like hidden terminal, transmit signal drowning receive signal in today's antennae etc etc) then you can manage congestion.... by the way, a lot of techniques on wireless nets are making their way into wired (and photonic) nets these days to get better resilience to noise and pack more bits in.... anyhow, i'll stop annoying you at this point, as I have other fish to fry In missive <513A7732.5010406 at web.de>, Detlef Bosau typed: >>Content-Transfer-Encoding: 8bit >> >>Am 08.03.2013 15:28, schrieb Jon Crowcroft: >>> actually packets stored in the channel may not have contended for the >>> channel, whereas packets arriving at a queue are contending for the >>> output to that queue.... >>> >> >>Even that is simply wrong. >> >>In Wifi, packets are sent in the whole: One IP packet is encapsulated in >>one 802.11 packet. This simply holds not true in mobile networks. >> >>E.g. in HSDPA you have 2 ms timeslots and you may change the line coding >>scheme, the puncturing and the wrapping about channels each and every 2 ms. >>You have transport blocks the payload of which may vary from about 150 >>bit to 12000 bit, very roughly I need to look it up. >> >>Than you have opportunistic scheduling where channels may be suspended >>for some time. >> >>What I read so far in CS books is simply orthogonal to reality in many >>cases. And the model to assign a packet a "serialization delay" is >>hopelessly naive and, physically, simply as wrong as could be. >> >>That's completely different from wired networks. >> >>And I really cannot imagine that I'm the only one here to see this. >> >>One immediate consequence is that the annoying discussion about >>"spurious time outs" is nonsense. >> >>The RTO in TCP is a confidence interval derived, by Cantelli's >>inequality, from expectation and variance of the/, so assuemed, >>//stationary /RTT. (See Edge's paper, the congavoid paper etc.) >> >>(Cantelli's inequality is a special case of Chebysheff's inequality.) >> >>Of course, you can put RTT "measurements" into an EWMA filter (garbage >>in garbage out principle), put this into Cantelli's inequality and get >>(again garbage in garbage out) an RTO statistics. >> >>You can easier take 15. (No matter if seconds or hours.) >> >>This is as wrong as the other RTO formulae but easier to implement. >> >>However, if we use an RTO determined by pure hand waving, how can we >>really claim this to be a confidence interval and say that ACKs are "late"? >> >> >>And what's particular annoying: I'm neither the first one to claim so >>neither the only one. E.g. Raj Jain and Lixia Zhang published on the >>deficiencies of timers nearly 25 years ago! This is really old and >>accepted basic knowledge! Why is this ignored? >> >>You referred to Dave Reed some posts ago, from quite some PM exchange I >>very well know Dave's anger about formulae, which are mistaken for >>reality, and the ignorance of the community against physical reality >>which is around everywhere! >> >>And for decades we modelled "bandwidths" in our simulators as >>"serialization delay" in wired networks and mobile networks as well. >>except some very few extensions, e.g. the EURANE extensions to the NS2, >>and wonder why simulators yield exactly the wrong results we previously >>encoded in them! >> >>As you may notice, I'm extremely upset about this! >> >>It may sound cynical, however I'm not employed with any university at >>the moment, so there is no professor to fire me tomorrow morning because >>I wrote this post. And believe me, this attitude is anything than >>unfamiliar to me. If someone points to physical reality and violates >>some dogmatic "laws", he is most likely to be at least severely berated >>he must not damage the reputation of his employer. >> >>However, wrong statements are not corrected by berating students, PhD >>students or research assistants! >> >>Wrong statements are only corrected by correct ones! >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>--------------020404080109060908000106 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> > http-equiv="Content-Type"> >> >> >>
Am 08.03.2013 15:28, schrieb Jon >> Crowcroft:
>>
>>
>cite="mid:CAEeTejL03mjAxPTk87b24RNf4ECQhjphSYmocd77ct4T+oAoYw at mail.gmail.com" >> type="cite"> >> >> actually packets stored in the channel may not have contended for >> the channel, whereas packets arriving at a queue are contending >> for the output to that queue.... >>

>>
>>
>>
>> Even that is simply wrong.
>>
>> In Wifi, packets are sent in the whole: One IP packet is >> encapsulated in one 802.11 packet. This simply holds not true in >> mobile networks.
>>
>> E.g. in HSDPA you have 2 ms timeslots and you may change the line >> coding scheme, the puncturing and the wrapping about channels each >> and every 2 ms.
>> You have transport blocks the payload of which may vary from about >> 150 bit to 12000 bit, very roughly I need to look it up.
>>
>> Than you have opportunistic scheduling where channels may be >> suspended for some time.
>>
>> What I read so far in CS books is simply orthogonal to reality in >> many cases. And the model to assign a packet a "serialization delay" >> is hopelessly naive and, physically, simply as wrong as could be.
>>
>> That's completely different from wired networks.
>>
>> And I really cannot imagine that I'm the only one here to see this.
>>
>> One immediate consequence is that the annoying discussion about >> "spurious time outs" is nonsense.
>>
>> The RTO in TCP is a confidence interval derived, by Cantelli's >> inequality, from expectation and variance of the, so assuemed, stationary >> RTT. (See Edge's paper, the congavoid paper etc.)
>>
>> (Cantelli's inequality is a special case of Chebysheff's >> inequality.)
>>
>> Of course, you can put RTT "measurements" into an EWMA filter >> (garbage in garbage out principle), put this into Cantelli's >> inequality and get (again garbage in garbage out) an RTO statistics.
>>
>> You can easier take 15. (No matter if seconds or hours.)
>>
>> This is as wrong as the other RTO formulae but easier to implement.
>>
>> However, if we use an RTO determined by pure hand waving, how can we >> really claim this to be a confidence interval and say that ACKs are >> "late"?
>>
>>
>> And what's particular annoying: I'm neither the first one to claim >> so neither the only one. E.g. Raj Jain and Lixia Zhang published on >> the deficiencies of timers nearly 25 years ago! This is really old >> and accepted basic knowledge! Why is this ignored?
>>
>> You referred to Dave Reed some posts ago, from quite some PM >> exchange I very well know Dave's anger about formulae, which are >> mistaken for reality, and the ignorance of the community against >> physical reality which is around everywhere!
>>
>> And for decades we modelled "bandwidths" in our simulators as >> "serialization delay" in wired networks and mobile networks as well. >> except some very few extensions, e.g. the EURANE extensions to the >> NS2, and wonder why simulators yield exactly the wrong results we >> previously encoded in them!
>>
>> As you may notice, I'm extremely upset about this!
>>
>> It may sound cynical, however I'm not employed with any university >> at the moment, so there is no professor to fire me tomorrow morning >> because I wrote this post. And believe me, this attitude is anything >> than unfamiliar to me. If someone points to physical reality and >> violates some dogmatic "laws", he is most likely to be at least >> severely berated he must not damage the reputation of his employer. >>
>>
>> However, wrong statements are not corrected by berating students, PhD students or research assistants!
>>
>> Wrong statements are only corrected by correct ones!
>> 
-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30   
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                           mobile: +49 172 6819937
 >>                                           skype:     detlef.bosau
 >>                                           ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>
 >>
>> >> >> >>--------------020404080109060908000106-- cheers jon From Jon.Crowcroft at cl.cam.ac.uk Sat Mar 9 02:28:05 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sat, 09 Mar 2013 10:28:05 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <513A3C4A.5060805@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> <513A3C4A.5060805@web.de> Message-ID: In missive <513A3C4A.5060805 at web.de>, Detlef Bosau typed: >>Am 08.03.2013 16:54, schrieb Jon Crowcroft: >>> In missive <513A04BE.4060505 at web.de>, Detlef Bosau typed: >>Merely nothing. When I move around my laptop in my apartment, I use WLAN >>to access my DSL router, the power level will change. >>However: Hardly that much that the packet corruption level is affected. when you switch from 55Mpbs to 11Mbps and to 2Mbps, without any other users around, why do you think that happens.... >>Unfortunately, in my appartment I see up to 8 (eight) WLANs. if you buy a WiFI router with MIMO you might solve your interference problems - dense mode stuff is getting tackeld but you ill still find the data rate switches down to lower rates as you get further from your AP >>So, what do you think affects my data rate notebook - router? Me moving >>around in the apartment or my neighbours surfing the Internet? >>In addition, the SNR sinks continuously when moving around. The packet >>corruption ratio doesn't. >> >>It is a theoretical game with numbers. no, its a basis for sound system design. >>> eventually the signal (to background noise) is too low level to carry any info in any way distinguishable >>> >>> >>Data corruption is a phenomenon which occurs at the receiver. The >>> >>problem is that the receiver cannot successfully rebuild a packet from >>> >>what he received. The air interface has no idea of which waves are >>> >>travelling along and whether they make any sense at all. >>> >>> you're confusing interference with other sources and misreading the honorably Dave Reed >> >>I'm quite sure that I'm not misreading Dave Reed. >> you are conflating two (or three) completely different facets of wireless nets... >>> secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter) >>> and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading) >>> >> >>So, a model which correctly describes wireless channels is that flexible >>that it fits anything - and has no use at all. incorrect - it is a sound basis for design. >>I don't think I misread Dave Reed - to the contrary, in some particular >>respects I share his anger. not sure why you are angry - this is a technical forum, not a personal chat forum. >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> cheers jon From fred at cisco.com Sat Mar 9 05:31:23 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 9 Mar 2013 13:31:23 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Message-ID: <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> On Mar 4, 2013, at 5:07 PM, "Scharf, Michael (Michael)" wrote: > Some time ago, I wondered myself whether an Internet without congestion control could work, or not. My (somehow short) insight can be found on page 67 of: http://www.ikr.uni-stuttgart.de/Content/Publications/Archive/Sf_Diss_40112.pdf Well, we have experience with networks using Internet technology with inadequate congestion control. That's a good description to the Internet before TCP congestion control was deployed, and I can think of some other cases in which people learned about it the hard way in private networks. The question, I suppose, is 'how "controlled" is "controlled well enough"?'. There is work right now on deterministic (read: TDM-like) networking, including a project funded through FIRE a few years back, and commercial product related to avionics and industrial automation. I personally think it's a little oversold, but you should know that the idea is out there. In a network that is deterministic end to end, one could argue that the only congestion control required is for a host to not congest its own queues, as no other queue would (by design) become congested or for that matter introduce more than the design quantum of delay. I'm personally of the opinion that loss-based congestion controls are inefficient, for the simple reason that a mechanism that tunes to the knee will generally achieve the same bit rate end to end as one that tunes to the cliff (they will both, given that they have enough data to do so, fill the bottleneck); However, one that tunes to the cliff has to assume and account for some amount of self-inflicted loss, which implies recovery delays and a reduction in end to end bit rate comparable to the retransmission rate. CAIA CDG has, I think, characteristics that would enable it to eliminate a number of data center issues and issues on the wide wooly Internet. Yes, we need some form of congestion control. We have proven that to ourselves time and again. The question is "with what characteristics, seeking to achieve what goal?" From detlef.bosau at web.de Sat Mar 9 12:17:52 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 09 Mar 2013 21:17:52 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> <513A3C4A.5060805@web.de> Message-ID: <513B98F0.5020801@web.de> Am 09.03.2013 11:28, schrieb Jon Crowcroft: > > no, its a basis for sound system design. Up to now, and I'm looking for this for a decade now and asked many, many researchers, I don't know a formula which derives the possible throughput over a wireless channel depending on the SNR. And no, Shannon-Hartley doesn't. > >>> eventually the signal (to background noise) is too low level to carry any info in any way distinguishable > > >>> > >>> >>Data corruption is a phenomenon which occurs at the receiver. The > >>> >>problem is that the receiver cannot successfully rebuild a packet from > >>> >>what he received. The air interface has no idea of which waves are > >>> >>travelling along and whether they make any sense at all. > >>> > >>> you're confusing interference with other sources and misreading the honorably Dave Reed > >> > >>I'm quite sure that I'm not misreading Dave Reed. > >> > > you are conflating two (or three) completely different facets of > wireless nets... Just the opposite is true. The problem is that we often observe _one_ phenomenon, e.g. packets are not ACKed in time, which can be the consequence of - collision, i.e. a MAC problem, - corruption, caused by noise, shading, interference etc., - congestion, and believe that there is _the one single reason_ for the observed phenomenon and afterwards identify this by an educated guess or divine inspiration. This is sometimes called "ratio ex post" and is one of the two most often made mistakes in science. (The other one is to mistake coincidence for correlation and even more causal relation. Take this and "ratio ex post" - and I'm convinced you can falsify the vast majority of medical studies currently being published.) When I understand Dave correctly, this is what Dave sometimes calls "confirmation bias". > > >>> secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter) > >>> and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading) > >>> > >> > >>So, a model which correctly describes wireless channels is that flexible > >>that it fits anything - and has no use at all. > > incorrect - it is a sound basis for design. No. A model with dozens of variables, hardly any of which can be estimated in a sound way doesn't prove anything. A typical example is the loss differentiation debate. There are literally hundreds of papers around which try to determine whether a packet loss is due to corruption or congestion. Take any of them - and look for "ratio ex post" - I don't know at least one single paper which holds. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130309/49f3a581/attachment.html From detlef.bosau at web.de Sat Mar 9 16:22:58 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 10 Mar 2013 01:22:58 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A7732.5010406@web.de> Message-ID: <513BD262.1000705@web.de> Am 09.03.2013 11:21, schrieb Jon Crowcroft: > not sure why you are annoyed.... > > serialisation delays are the time taken to clock a packet on to a > channel - this isn't some figment - there's a coding method and a The term "serialization delay" is inherited from wired networks like Ethernet and may, within certain limits, have some minimal justification in 802.11 networks. It is nothing else than the reciprocal value of the holy "bandwidth" which is an idealized model for some kind of data rate, data may be conveyed with with negligible error rate. In mobile networks this model simply does not apply. Think of opportunistic scheduling in HSDPA, which means, figuratively, that your network interface is simply plugged off now and then. Or your 10 GE interface is replaced by a 10 MBit/s Ethernet interface, than by a 19k2 modem line, then the interface is plugged of for, say, 20 seconds. The term "serialization delay" does not make any sense in this context. Contrary to Ethernet, you cannot even tell in advance how long the "serialized packet" will be, because, again e.g. HSDPA, the net data rate may change several times from the beginning of the packet to the end of the packet and the channel may even be suspended and getting no service in between. And when you refer to 802.11 and the base station switches from DCF to PCF from time to time, you may well tell me that the base station will issue flow control messages to stop a sender from sending if necessary, does this waiting time affect the time it takes to send the packet to the channel? Of course it does! So, what's the justification of a "serialization delay" or a known throughput (as perceived by the application) in mobile networks? Or, in other words, what should be the meaning of such a term? Which is typically coined in wire line networks. I would agree with you when we talk about point to point technologies. But I completely disagree in case of 802.11 and particularly in mobile networks. And this is neither rocket science nor a brand new insight, this is standard knowledge from any lecture in communication engineering. When I started my research in the COMCAR project 13 years ago and I discussed QoS parameters with CE and EE guys, they simply ridiculed about me and asked me: "You're a wire line guy, aren't you?" And Jon, although this is beyond the scope of this mailing list, this experience hurts me up to this moment. I was berated for not having provided QoS in mobile networks from my CS colleagues and I was not taken seriously by my CE and EE colleagues and I spent literally hundreds of hours to understand what's happening here during the last 13 years. Ahd the result of this investigation is quite simple: We CS guys do not listen to what the CE and EE colleages say - and vice versa. We don't listen to each other - and quite often, we intentionally misinterpret the other discipline. E.g. the term "bandwidth" which is even discussed in some RFCs. Fine. The term was coined in by the CE colleagues with a well defined meaning decades ago. And when we CS guys redefine a well defined term of engineering which was successfully used over 80 years or so and redefine the meaning, the only consequence is some kind of babylonian confusion. (Perhaps, I suffer from my experience with some civil engineers here, because for civil engineers the first thing is the standard. Second comes the standard, which is the only thing. The word of good or the law are helpful - but they are not part of the standard. I worked with an institute of steel construction and the relevant standard was the DIN 18.800. That was the word of god. And if god would have spoken differently, he would be berated because he would have violated DIN 18.800. This may sound extremely narrow minded. But as a consequence, e.g. civil engineers from the US, from GB, from Germany, from Japan and much other places in the world could cooperate in building things like the Akashi-Kaikyo-Bridge http://en.wikipedia.org/wiki/Akashi_Kaiky%C5%8D_Bridge because they understood each other. And I've seen many engineers, particularly civil engineers, shaking their heads about us CS guys and complaining: When are the CS guys to develop a professional engineering attitude towards their own work? In other words: Most of us know the well known Unix cookie: "When builders built buildings like programmers write programs, any woodpecker that came along would destroy human civilization." So we can apply the term "serialization delay" to a wire line interface. For mobile networs and 802.11 this term simply does not apply. And I was held responsible for not providing something which is, to the best of our knowledge, physically impossible. E.g. providing QoS in HSDPA would require some kind of throughput forecast. Not only for my own channel but for competing ones as well because of opportunistic scheduling. Now, it's credited not only to Niels Bohr but to many scientists: "Prediction is hard. Especially of the future." As I said. This experience hurts until this day - and not only as a personal experience, in that case I should not talk about this here, but as a central misconception in how we deal with mobile networks! And as long as algorithms like VJCC do not make a difference between wired and wireless networks but are applied thoughtlessly on "internetworks" consisting of wired and wireless lines as well, we cannot really expect them to provide the results we want to see! So this is not only a personal experience but I'm convinced I've learned something during the last 13 years. Detlef Detlef Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Jon.Crowcroft at cl.cam.ac.uk Sun Mar 10 03:52:21 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Sun, 10 Mar 2013 10:52:21 +0000 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <513B98F0.5020801@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> <513A3C4A.5060805@web.de> <513B98F0.5020801@web.de> Message-ID: you misunderstand - there are very good _MODELS_ of wireless behaviour - there isn't just one single magic FORMULA because the systems are so complex in reality e.g. simply considering a simple path loss exponent doesn't work in a building because you need to ray trace from transmit to all potential receiver to compute the multipath interference effects - so we don't do this unless we're planning a very robust deployment however, you can use the MODEL to choose robust designs of modulation, coding etc (given spectrum, power budgets and antennae constraints) and bound the capacity (and delay) seen in a wide range of circumstances the designs are usually adaptive.... (as per the WiFi discussion we just had).... so building a +predictive+ online, realtime wireless channel equation based system is almost impossible for any real world deployment, but we can explain the behaviour of the system just fine... (oh, and look at any movemone on the order of physical scale of the wavelength of the signal, or any atmospheric effects (ionosphere/scintillation) to make life more fun... but that does not mean we don't understand it = it just maskes the design space more fun.... coz you have to evaluate a range of techniques over a wide range of circumstances... however, it also does mean you can base a congestion feedback at layer 4 on info passed by layer 1/2/3 up, at a receiver to infer channel contention - and, using aforesaid models, use this to trigger feedback to layer four senders (e.g. via ECN) to factor in layer 2 troubl, just the way you can factor in queue/buffer build problem (e.g. via a virtual queue occupancy estimation)... its not black magic or a dark art - its just not as simple as shannon, coz there's a lot of devils in the details....but that is what engineering so often is... In missive <513B98F0.5020801 at web.de>, Detlef Bosau typed: >>Content-Transfer-Encoding: 8bit >> >>Am 09.03.2013 11:28, schrieb Jon Crowcroft: >>> >>> no, its a basis for sound system design. >> >>Up to now, and I'm looking for this for a decade now and asked many, >>many researchers, I don't know a formula which derives the possible >>throughput over a wireless channel depending on the SNR. >> >>And no, Shannon-Hartley doesn't. >>> >>> eventually the signal (to background noise) is too low level to carry any info in any way distinguishable >>> >>> >>> >>> >>> >>Data corruption is a phenomenon which occurs at the receiver. The >>> >>> >>problem is that the receiver cannot successfully rebuild a packet from >>> >>> >>what he received. The air interface has no idea of which waves are >>> >>> >>travelling along and whether they make any sense at all. >>> >>> >>> >>> you're confusing interference with other sources and misreading the honorably Dave Reed >>> >> >>> >>I'm quite sure that I'm not misreading Dave Reed. >>> >> >>> >>> you are conflating two (or three) completely different facets of >>> wireless nets... >> >>Just the opposite is true. >> >>The problem is that we often observe _one_ phenomenon, e.g. packets are >>not ACKed in time, which can be the consequence of >>- collision, i.e. a MAC problem, >>- corruption, caused by noise, shading, interference etc., >>- congestion, >>and believe that there is _the one single reason_ for the observed >>phenomenon and afterwards identify this by an educated guess or divine >>inspiration. >> >>This is sometimes called "ratio ex post" and is one of the two most >>often made mistakes in science. >>(The other one is to mistake coincidence for correlation and even more >>causal relation. Take this and "ratio ex post" - and I'm convinced you >>can falsify the vast majority of medical studies currently being >>published.) >> >>When I understand Dave correctly, this is what Dave sometimes calls >>"confirmation bias". >> >>> >>> >>> secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter) >>> >>> and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading) >>> >>> >>> >> >>> >>So, a model which correctly describes wireless channels is that flexible >>> >>that it fits anything - and has no use at all. >>> >>> incorrect - it is a sound basis for design. >> >>No. A model with dozens of variables, hardly any of which can be >>estimated in a sound way doesn't prove anything. >> >>A typical example is the loss differentiation debate. >> >>There are literally hundreds of papers around which try to determine >>whether a packet loss is due to corruption or congestion. >> >>Take any of them - and look for "ratio ex post" - I don't know at least >>one single paper which holds. >> >> >>-- >>------------------------------------------------------------------ >>Detlef Bosau >>Galileistra?e 30 >>70565 Stuttgart Tel.: +49 711 5208031 >> mobile: +49 172 6819937 >> skype: detlef.bosau >> ICQ: 566129673 >>detlef.bosau at web.de http://www.detlef-bosau.de >> >> >>--------------090201050506010700000902 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: 7bit >> >> >> >> > http-equiv="Content-Type"> >> >> >>
Am 09.03.2013 11:28, schrieb Jon >> Crowcroft:
>>
>>
> type="cite"> >> 
 >> 
 >>no, its a basis for sound system design.
 >>
>>
>>
>> Up to now, and I'm looking for this for a decade now and asked many, >> many researchers, I don't know a formula which derives the possible >> throughput over a wireless channel depending on the SNR.
>>
>> And no, Shannon-Hartley doesn't.
>>
> type="cite"> >> 
 >> >>> eventually the signal (to background noise) is too low level to carry any info in any way distinguishable
 >> 
 >> >>>
 >> >>>   >>Data corruption is a phenomenon which occurs at the receiver. The
 >> >>>   >>problem is that the receiver cannot successfully rebuild a packet from
 >> >>>   >>what he received. The air interface has no idea of which waves are
 >> >>>   >>travelling along and whether they make any sense at all.
 >> >>>
 >> >>> you're confusing interference with other sources and misreading the honorably Dave Reed
 >> >>
 >> >>I'm quite sure that I'm not misreading Dave Reed.
 >> >>
 >>
 >>you are conflating two (or three) completely different facets of
 >>wireless nets...
>>
>>
>> Just the opposite is true.
>>
>> The problem is that we often observe one phenomenon, e.g. >> packets are not ACKed in time, which can be the consequence of
>> - collision, i.e. a MAC problem,
>> - corruption, caused by noise, shading, interference etc.,
>> - congestion,
>> and believe that there is the one single reason for the >> observed phenomenon and afterwards identify this by an educated >> guess or divine inspiration.
>>
>> This is sometimes called "ratio ex post" and is one of the two most >> often made mistakes in science.
>> (The other one is to mistake coincidence for correlation and even >> more causal relation. Take this and "ratio ex post" - and I'm >> convinced you can falsify the vast majority of medical studies >> currently being published.)
>>
>> When I understand Dave correctly, this is what Dave sometimes calls >> "confirmation bias".
>>
>>
> type="cite"> >> 
 >> 
 >> >>> secondly, you are ignoring absorption (e.g. by water vapour which gets a little bit hotter)
 >> >>> and also _self_ interferance (aka Ricean fading) and scattering (rayleigh fading)
 >> >>>   
 >> >>
 >> >>So, a model which correctly describes wireless channels is that flexible 
 >> >>that it fits anything - and has no use at all.
 >>
 >>incorrect - it is a sound basis for design.
>>
>>
>> No. A model with dozens of variables, hardly any of which can be >> estimated in a sound way doesn't prove anything.
>>
>> A typical example is the loss differentiation debate.
>>
>> There are literally hundreds of papers around which try to determine >> whether a packet loss is due to corruption or congestion.
>>
>> Take any of them - and look for "ratio ex post" - I don't know at >> least one single paper which holds.
>>
>>
>> 
-- 
 >>------------------------------------------------------------------
 >>Detlef Bosau
 >>Galileistraße 30   
 >>70565 Stuttgart                            Tel.:   +49 711 5208031
 >>                                           mobile: +49 172 6819937
 >>                                           skype:     detlef.bosau
 >>                                           ICQ:          566129673
 >>detlef.bosau at web.de                     http://www.detlef-bosau.de
 >>
 >>
>> >> >> >>--------------090201050506010700000902-- cheers jon From lastewart at swin.edu.au Sun Mar 10 09:58:17 2013 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Mon, 11 Mar 2013 03:58:17 +1100 Subject: [e2e] Multipath TCP for FreeBSD v0.1 Message-ID: <513CBBA9.6010605@swin.edu.au> Hi all, The CAIA MPTCP team is pleased to announce the initial release of our multipath TCP implementation for FreeBSD 10-CURRENT which is available from [1]. This release contains wire-related protocol code and a lot of core stack infrastructure. It is capable of running regular TCP flows and single or multi-subflow MPTCP flows (with some caveats as documented in the readme [2]). We consider this code to be of alpha quality and plan to release frequent updates going forward as we continue to flesh out additional features and fix the rough edges. That being said, we welcome everyone to start playing with the code and provide feedback, bug reports, fixes, praise and/or abuse ;) The "Multipath TCP for FreeBSD" project team consists of: Nigel Williams: lead R&D engineer Lawrence Stewart: supporting R&D engineer Grenville Armitage: principal investigator & overall project lead Many thanks go to the Cisco University Research Program Fund at Community Foundation Silicon Valley for their support of this work. Have fun with it! Cheers, Lawrence, Nigel & Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt From detlef.bosau at web.de Sun Mar 10 15:05:46 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 10 Mar 2013 23:05:46 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <5135A361.1070702@web.de> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6428@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <51361FF1.8050208@web.de> <51390D8A.6020508@web.de> <51390F43.9090700@web.de> <5139ECEC.5020702@web.de> <513A04BE.4060505@web.de> <513A3C4A.5060805@web.de> <513B98F0.5020801@web.de> Message-ID: <513D03BA.9050500@web.de> Am 10.03.2013 11:52, schrieb Jon Crowcroft: > you misunderstand - > > there are very good _MODELS_ > of wireless behaviour - Perhaps. To my understanding - and in my personal experience - I was talked into those which are modelled in simulators like the NS2, which is not sufficient for the aforementioned reasons. > > there isn't just one single magic FORMULA I didn't claim so. > because the systems are so complex in reality I gave reasons, why such a formula cannot be expected. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Mon Mar 11 05:19:39 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 11 Mar 2013 13:19:39 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. Message-ID: <513DCBDB.30703@web.de> Because of the recent discussion on congestion control, let me please refer to the following table, which is taken from "European Telecommunications Standards Institute. Digital cellular telecommunications system (phase 2+); General Packet Radio Service (GPRS); Service description; Stage 1. ETSI Standard EN 301 113 V6.1.1, 1998." and to my understanding describes the SDU delivery times via GPRS from the SGSN to the mobile. GPRS Delay Classes Hopefully, this table appears on the list, otherwise I would to have to write it down in ASCII characters. First, we can model this transport latency using the terms "serialization delay" and "propagation delay". In GPRS the maximum cell radius is about 32 kilometers, IIRC, so the propagation latency is certainly less than 0,1 milliseconds. Hence we can simply neglect the the propagation latency in this case. So let's talk about the "serialization delay". For 1024 octets, this may be up to 375 seconds, for 128 octets, it may be up to 250 seconds. In the first example, the resulting throughput is about 22.8 bit/second. The first question is, whether or not the RTT (the table above shows STT from the SGSN to the terminal) is stationary, so that we can derive some kind of RTO. BTW: Deriving an RTO from an observed RTT via Chebycheff/Cantelli/Edge is simply ridiculous here: The RTO is nothing but a, say, 0.95 quantile and would be 375 seconds here, which is far to long for any practical use. On the other hand, GPRS uses transport blocks / radio blocks for transmission and has a quite precise knowledge of the distance Antenna/Terminal (necessary for the GSM timing advance) and hence a much more realistic RTO for its own recovery layer. I strongly expect objections here because I didn't mention the appropriate reliability classes for the aforementioned delay classes. IIRC, the "QoS Profile" for delay class 3 ensures an SDU corruption probability less than 10^-9. So the recovery layer in that case is extremely strong. Particularly, any loss differentiation (corruption/congestion) is simply not necessary here. From TCP's point of view, corruption is negligible here. The second question is how we can explain the "serialization delay" and which consequences must be drawn from a "serialization delay" 375 seconds. I occasionally refered to "PERFORMANCE EVALUATION OF A TCP PROXY IN WCDMA NETWORKS" by Meyer, Holtzke, Sachs. IEEE Wireless Communications October 2003. Throughout this paper, the authors talk about a "latency bandwidth product" where "bandwidth" is the GPRS gross data rate 384 kBit/s. Even a WCDMA "bandwidth", i.e. 2 MBit/s is mentioned. So the reader is made to expect a "path capacity" 384 kbit/s * 375 seconds = 144.000 kbit. (750 Mbit respectively.) And of course, this huge path capacity should be utilized by an appropriate initial TCP window. Now, neither the air interface in GPRS or UMTS has a path capacity comparable to a 5 1/4" floppy disk nor the "serialization" of a 1024 octed SDU using a data rate 2 MBit/s lasts 375 seconds. So, the interpretation of the delay als "serialization time" is at least, say, strange, the so called "latency bandwidth" product in this case is simply an abuse of Little's formula. First of all, the "mean" value and the 0.95 quantiles in the table above indicate that the transport latency exhibits an extreme skew. So, the immediate question is, whether the expectations for service time, rate of arrival and jobs in the system exist at all and hence whether or not Little's law is applicable. Second, what are the jobs in the "system"? Packets sent via GPRS or UMTS are typically split up into a sequence of RLP blocks, so there are blocks for new transmissions, there are blocks for repeated transmissions, there are blocks for RLP control, hence the data to be transmitted (represented by the first transmission only) are only a part of the traffic in flight. And because GPRS offers only little adaptivity in its channel- and line-coding, but QoS profiles with an extremely low SDU corruption ratio, I strongly believe, that the payload interesting for higher layers is only a minor part of the traffic in flight. I did not yet get any sound explanation for the high transport times in GPRS. However, I think the major part is more or less queueing delay. And because the real air interface has hardly any "transient storage capacity" at all, I think, a sliding window approach for GPRS networks is completely inappropriate. We should use stop 'n wait here and that's it. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/19691f30/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 32960 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/19691f30/attachment-0001.png From Martin.Heusse at imag.fr Mon Mar 11 09:12:11 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Mon, 11 Mar 2013 17:12:11 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <513DCBDB.30703@web.de> References: <513DCBDB.30703@web.de> Message-ID: (Although I would tend to think you might need to read a bit about GPRS and cellular networks, I'll stick to a more general remark, replacing your reflections in an end to end perspective. And forgive me if I misunderstood you.) A sliding window (congestion window, anticipation window) allows a sender to use the links on a multi hop paths in parallel when the network device are store and forward. So to use a GPRS network properly you need a least 4 packets. UE -> BSC -> SGSN -> GGSN -> gateway to dest network Etc. And that's one way, the return path also count for what's ?inflight". (ok, high speed links don't hurt as much a low speed links beyond the bottleneck, but I hope you get the idea?) Also: RLC-ack (Is that what you call RLP?) does use ARQ? (Are you happy now? ...) And that actually allows TCP to kind of work on those links. Martin Le 11 mars 2013 ? 13:19, Detlef Bosau a ?crit : > And because the real air interface has hardly any "transient storage capacity" at all, I think, a sliding window approach for GPRS networks is completely inappropriate. We should use stop 'n wait here and that's it. From detlef.bosau at web.de Mon Mar 11 12:39:58 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 11 Mar 2013 20:39:58 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: References: <513DCBDB.30703@web.de> Message-ID: <513E330E.6080102@web.de> Am 11.03.2013 17:12, schrieb Martin Heusse: > (Although I would tend to think you might need to read a bit about GPRS and cellular networks, Be assured: I read quite some literature. However: Could you please be a bit more concrete? > I'll stick to a more general remark, replacing your reflections in an end to end perspective. And forgive me if I misunderstood you.) > > A sliding window (congestion window, anticipation window) allows a sender to use the links on a multi hop paths in parallel when the network device are store and forward. Hang on. Sliding window is used to utilize a channel which is able to keep more than one packet in transit. Particularly on the media. > So to use a GPRS network properly you need a least 4 packets. > UE -> BSC > -> SGSN > -> GGSN > -> gateway to dest network > Etc. At a first glance, I tend to agree, however from what I read so far about mobile networks, these do not necessarily deal with IP packets internally. Nevertheless, when the technology allows to keep more than one packet in transit and is underutilized otherweise, sliding window makes sense. On the air interface (in GPRS actually perhaps "behind" the GGSN) this (at least to my understanding) not always make sense. Generally spoken: I've chosen GPRS because of it's huge latencies. And any example I would take, may turn out to be "bad" because the huge complexity of different technologies and implementation used in wireless networks. > And that's one way, the return path also count for what's ?inflight". > (ok, high speed links don't hurt as much a low speed links beyond the bottleneck, but I hope you get the idea?) > > Also: RLC-ack (Is that what you call RLP?) does use ARQ? (Are you happy now? ...) This is no matter of happiness. It is a matter of fact and it is part of the time necessary to convey a packet. I mentioned the COMCAR project and I should provide a "QoS architecture" there - which included to describe the "rate" available for a stream. Later on, in a conference, the first question was: "Mr. Bosau, how do you no the available rate?" Period. Latest in that moment, it became clear to me that TelCo guys and CS guys (packet switching guys) simply don't understand each other. They talk at cross purposes. Later on, it became clear to me that packet switching and line switching (used for voice) use different APIs. We talk about the years from 2000 to 2005 here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Mon Mar 11 12:51:36 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 11 Mar 2013 20:51:36 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <1363010329.878918385@apps.rackspace.com> References: <513DCBDB.30703@web.de> <1363010329.878918385@apps.rackspace.com> Message-ID: <513E35C8.90202@web.de> Am 11.03.2013 14:58, schrieb dpreed at reed.com: > > These are "specifications", and not actual measurements of actual systems. > > In particular, the 95 percentile statement on Delay Class 3 is a > statement that "only 5 percent of the time will any packets be delayed > longer than 375 seconds." This does not characterize or even > specifiy a channel model - perhaps the 5 percent are infinite delays > (permanent losses) and all other packets are delivered *in 1 msec. or > less.* > Yes. So, we don't know anything about the channel - and I was berated for not having provided a QoS architechture ("this is no witchcraft!") for a channel we do nothing about. And David,/that /hurts. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130311/82b848e0/attachment.html From Martin.Heusse at imag.fr Mon Mar 11 13:58:39 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Mon, 11 Mar 2013 21:58:39 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <513E330E.6080102@web.de> References: <513DCBDB.30703@web.de> <513E330E.6080102@web.de> Message-ID: <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> Le 11 mars 2013 ? 20:39, Detlef Bosau a ?crit : > Am 11.03.2013 17:12, schrieb Martin Heusse: >> (Although I would tend to think you might need to read a bit about GPRS and cellular networks, > > Be assured: I read quite some literature. However: Could you please be a bit more concrete? Sorry for this unnecessary remark. > >> I'll stick to a more general remark, replacing your reflections in an end to end perspective. And forgive me if I misunderstood you.) >> >> A sliding window (congestion window, anticipation window) allows a sender to use the links on a multi hop paths in parallel when the network device are store and forward. > > Hang on. Sliding window is used to utilize a channel which is able to keep more than one packet in transit. Particularly on the media. Not particularly, but rather anywhere. An Ethernet "link" composed of several segments connected by switches "holds" just as many packets. A protocol that would not use a sliding window would use that network badly. Do you agree with this? >> So to use a GPRS network properly you need a least 4 packets. >> UE -> BSC >> -> SGSN >> -> GGSN >> -> gateway to dest network >> Etc. > > At a first glance, I tend to agree, however from what I read so far about mobile networks, these do not necessarily deal with IP packets internally. Well, ok, PDP, GTP tunnels etc. They are still store&forward, don't you think? > > Nevertheless, when the technology allows to keep more than one packet in transit and is underutilized otherweise, sliding window makes sense. On the air interface (in GPRS actually perhaps "behind" the GGSN) this (at least to my understanding) not always make sense. Can't you leave aside the air interface? It goes at the speed of light, and not very far. So it does not store much. But the GPRS network does. Don't you think? > > Generally spoken: I've chosen GPRS because of it's huge latencies. And any example I would take, may turn out to be "bad" because the huge complexity of different technologies and implementation used in wireless networks. > >> And that's one way, the return path also count for what's ?inflight". >> (ok, high speed links don't hurt as much a low speed links beyond the bottleneck, but I hope you get the idea?) >> >> Also: RLC-ack (Is that what you call RLP?) does use ARQ? (Are you happy now? ...) > > This is no matter of happiness. It is a matter of fact and it is part of the time necessary to convey a packet. No, a packet can perfectly be sent up by the BSC before it's acked to the UE. My point was that there are places where ARQ makes sense (on a link with non negligible losses), and other places where an anticipation window makes sense? Guess where? Dadaaaaa: end to end. > > I mentioned the COMCAR project and I should provide a "QoS architecture" there - which included to describe the "rate" available for a stream. > > Later on, in a conference, the first question was: "Mr. Bosau, how do you no the available rate?" > > Period. ? > Latest in that moment, it became clear to me that TelCo guys and CS guys (packet switching guys) simply don't understand each other. They talk at cross purposes. Later on, it became clear to me that packet switching and line switching (used for voice) use different APIs. We talk about the years from 2000 to 2005 here. CS guy?? For me "CS" means "circuit switched", typically TelCo. You probably meant "PS"? Anyway, there is no CS network in LTE, for instance, so it looks like the TelCo guys are going to have to understand what a router is. But I think most of them did? M. From detlef.bosau at web.de Mon Mar 11 15:27:31 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 11 Mar 2013 23:27:31 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> References: <513DCBDB.30703@web.de> <513E330E.6080102@web.de> <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> Message-ID: <513E5A53.9040605@web.de> Am 11.03.2013 21:58, schrieb Martin Heusse: > Not particularly, but rather anywhere. An Ethernet "link" composed of several segments connected by switches "holds" just as many packets. A protocol that would not use a sliding window would use that network badly. Do you agree with this? I think, it was a bit extreme, when I talked about "stop and wait". In general, sliding window addresses the work conservation. When this can be achieved with one segment, it's o.k. When it is reasonable, as in your sketch, to use 4 segments, it is o.k. as well. In the particular case of TCP, we do not know the best window size in advance and employ an estimation scheme. What I have in mind is to split up TCP congestion control along the path and so be able to use different estimation schemes along the individual segments. And you're correct, as others are (I got some PM on this one): window size 1 (segment) may not be adequate in any case. >>> So to use a GPRS network properly you need a least 4 packets. >>> UE -> BSC >>> -> SGSN >>> -> GGSN >>> -> gateway to dest network >>> Etc. >> At a first glance, I tend to agree, however from what I read so far about mobile networks, these do not necessarily deal with IP packets internally. > Well, ok, PDP, GTP tunnels etc. They are still store&forward, don't you think? Se above. A sliding window may be adequate here. Even more: What you illustrate is a case where we KNOW an appropriate window size for a certain path segment, so why should we make this subject to VJCC and it's AIMD scheme? When we have sound knowledge, why should we rely upon estimation? >> Nevertheless, when the technology allows to keep more than one packet in transit and is underutilized otherweise, sliding window makes sense. On the air interface (in GPRS actually perhaps "behind" the GGSN) this (at least to my understanding) not always make sense. > Can't you leave aside the air interface? It goes at the speed of light, and not very far. So it does not store much. But the GPRS network does. Don't you think? I agree. For terrestrial networks. If we employ geostationary satellites, the situation may be different. However, it is the same rationale as discussed above. So, perhaps my argument was too extreme - and therefore wrong. I was pointed to similar situations in UUCP, however, the discussion remains the same: When sliding window is adequate, which window size yields the best throughput. And I think we can agree that we have situation where the ideal window size is known, while in others we have to asses the ideal window size. However, we should avoid to blast buffers by using unreasonable huge window sizes. >> >> This is no matter of happiness. It is a matter of fact and it is part of the time necessary to convey a packet. > No, a packet can perfectly be sent up by the BSC before it's acked to the UE. My point was that there are places where ARQ makes sense (on a link with non negligible losses), and other places where an anticipation window makes sense? Guess where? Dadaaaaa: end to end. Really? And that's the point I don't agree. It's just this strict end to end principle what I put in question. VJCC estimates the optimal window e2e. Why shouldn't we exploit SOUND knowledge of path segments? > >> I mentioned the COMCAR project and I should provide a "QoS architecture" there - which included to describe the "rate" available for a stream. >> >> Later on, in a conference, the first question was: "Mr. Bosau, how do you no the available rate?" >> >> Period. > ? > O.k., perhaps this lead to confusion without further explanation. >> Latest in that moment, it became clear to me that TelCo guys and CS guys (packet switching guys) simply don't understand each other. They talk at cross purposes. Later on, it became clear to me that packet switching and line switching (used for voice) use different APIs. We talk about the years from 2000 to 2005 here. > CS guy?? For me "CS" means "circuit switched", No, CS is Computer Science. In contrast to Electrical/Electronical Engineers or Communication Engineers. Hopefully this clears the confusion. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From Martin.Heusse at imag.fr Tue Mar 12 05:14:54 2013 From: Martin.Heusse at imag.fr (Martin Heusse) Date: Tue, 12 Mar 2013 13:14:54 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <513E5A53.9040605@web.de> References: <513DCBDB.30703@web.de> <513E330E.6080102@web.de> <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> <513E5A53.9040605@web.de> Message-ID: Le 11 mars 2013 ? 23:27, Detlef Bosau a ?crit : > In general, sliding window addresses the work conservation. When this can be achieved with one segment, it's o.k. When it is reasonable, as in your sketch, to use 4 segments, it is o.k. as well. > > In the particular case of TCP, we do not know the best window size in advance and employ an estimation scheme. What I have in mind is to split up TCP congestion control along the path and so be able to use different estimation schemes along the individual segments. And you're correct, as others are (I got some PM on this one): window size 1 (segment) may not be adequate in any case. Good, that was my point? Now, you'll have to admit: 1) no one knows the number of store and forward hops nor the latency in advance so you have to guess (or create some kind of cross-layer mechanism? Good luck with that?) The first hop that your TCP/IP stack sees is the GGSN in the GPRS network, and there are many store and forward nodes between them. 2) back-pressure congestion control is actually implemented in SS7 networks. (LLSU frames) The consequence of it is that a congestion somewhere creates congestion upstream and that's not good (that happened between Free-mobile and Orange in France not so long ago, as far as I know). Actually the fact that the congestion goes back upstream when no proper congestion control is used is a good argument against fountain code: links upstream of the congestion get congested? (Which is why, I guess, fair queueing is mandatory if you're going to change the paradigm?) Martin From Jon.Crowcroft at cl.cam.ac.uk Tue Mar 12 06:26:03 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Tue, 12 Mar 2013 13:26:03 +0000 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: <513DCBDB.30703@web.de> References: <513DCBDB.30703@web.de> Message-ID: SLAs are far more politics than technics... but more importantly, GPRS has a lot of protocol cruft (though less than 3G and 4G - just look at fast dormancy and tail energy use in those nets, if you want a laugh)... this protocol stuff (as Martin Heusse has indicated) masks the details of the wireless channel under layers of behaviours so a latency SLA above the packet radio +service+ layer has to include the expected 95centile of packet loss (due to noise/interference) and impact of ARQ in the radio link layer protocol, below IP (and therefore hidden from TCP too).... anyhow, standards organisations only ever agree to publish SLAs if they are unbelievelable conservative:) In missive <513DCBDB.30703 at web.de>, Detlef Bosau typed: >>Because of the recent discussion on congestion control, let me please >>refer to the following table, >>which is taken from >>"European Telecommunications Standards Institute. Digital cellular >>telecommunications system (phase 2+); General Packet Radio Service >>(GPRS); Service description; Stage 1. ETSI Standard EN 301 113 >>V6.1.1, 1998." >> >>and to my understanding describes the SDU delivery times via GPRS from=20 >>the SGSN to the mobile. >> >> >> >>GPRS Delay Classes >> >> >> >> >> >> >> >> >> >> >> >> >>Hopefully, this table appears on the list, otherwise I would to have to=20 >>write it down in ASCII characters. >> >>First, we can model this transport latency using the terms=20 >>"serialization delay" and "propagation delay". In GPRS the maximum cell=20 >>radius is about 32 kilometers, IIRC, so the propagation latency is=20 >>certainly less than 0,1 milliseconds. Hence we can simply neglect the=20 >>the propagation latency in this case. >> >>So let's talk about the "serialization delay". For 1024 octets, this may=20 >>be up to 375 seconds, for 128 octets, it may be up to 250 seconds. >>In the first example, the resulting throughput is about 22.8 bit/second. >> >>The first question is, whether or not the RTT (the table above shows STT=20 >>from the SGSN to the terminal) is stationary, so that we can derive some=20 >>kind of RTO. >> >>BTW: Deriving an RTO from an observed RTT via Chebycheff/Cantelli/Edge=20 >>is simply ridiculous here: The RTO is nothing but a, say, 0.95 quantile=20 >>and would be 375 seconds here, which is far to long for any practical=20 >>use. On the other hand, GPRS uses transport blocks / radio blocks for=20 >>transmission and has a quite precise knowledge of the distance=20 >>Antenna/Terminal (necessary for the GSM timing advance) and hence a much=20 >>more realistic RTO for its own recovery layer. >> >>I strongly expect objections here because I didn't mention the=20 >>appropriate reliability classes for the aforementioned delay classes.=20 >>IIRC, the "QoS Profile" for delay class 3 ensures an SDU corruption=20 >>probability less than 10^-9. So the recovery layer in that case is=20 >>extremely strong. Particularly, any loss differentiation=20 >>(corruption/congestion) is simply not necessary here. From TCP's point=20 >>of view, corruption is negligible here. >> >> >>The second question is how we can explain the "serialization delay" and=20 >>which consequences must be drawn from a "serialization delay" 375 seconds. >> >>I occasionally refered to "PERFORMANCE EVALUATION OF A >>TCP PROXY IN WCDMA NETWORKS" by Meyer, Holtzke, Sachs. IEEE Wireless=20 >>Communications October 2003. >> >>Throughout this paper, the authors talk about a "latency bandwidth=20 >>product" where "bandwidth" is the GPRS gross data rate 384 kBit/s. Even=20 >>a WCDMA "bandwidth", i.e. 2 MBit/s is mentioned. >> >>So the reader is made to expect a "path capacity" 384 kbit/s * 375=20 >>seconds =3D 144.000 kbit. (750 Mbit respectively.) >> >>And of course, this huge path capacity should be utilized by an=20 >>appropriate initial TCP window. >> >>Now, neither the air interface in GPRS or UMTS has a path capacity=20 >>comparable to a 5 1/4" floppy disk nor the "serialization" of a 1024=20 >>octed SDU using a data rate 2 MBit/s lasts 375 seconds. >> >>So, the interpretation of the delay als "serialization time" is at=20 >>least, say, strange, the so called "latency bandwidth" product in this=20 >>case is simply an abuse of Little's formula. >> >>First of all, the "mean" value and the 0.95 quantiles in the table above=20 >>indicate that the transport latency exhibits an extreme skew. So, the=20 >>immediate question is, whether the expectations for service time, rate=20 >>of arrival and jobs in the system exist at all and hence whether or not=20 >>Little's law is applicable. >> >>Second, what are the jobs in the "system"? Packets sent via GPRS or UMTS=20 >>are typically split up into a sequence of RLP blocks, so there are=20 >>blocks for new transmissions, there are blocks for repeated=20 >>transmissions, there are blocks for RLP control, hence the data to be=20 >>transmitted (represented by the first transmission only) are only a part=20 >>of the traffic in flight. And because GPRS offers only little adaptivity=20 >>in its channel- and line-coding, but QoS profiles with an extremely low=20 >>SDU corruption ratio, I strongly believe, that the payload interesting=20 >>for higher layers is only a minor part of the traffic in flight. >> >>I did not yet get any sound explanation for the high transport times in=20 >>GPRS. However, I think the major part is more or less queueing delay. >> >>And because the real air interface has hardly any "transient storage=20 >>capacity" at all, I think, a sliding window approach for GPRS networks=20 >>is completely inappropriate. We should use stop 'n wait here and that's i= >>t. >> >>Detlef >> >> >> >> >> cheers jon From detlef.bosau at web.de Tue Mar 12 08:16:49 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 12 Mar 2013 16:16:49 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: References: <513DCBDB.30703@web.de> <513E330E.6080102@web.de> <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> <513E5A53.9040605@web.de> Message-ID: <513F46E1.5000705@web.de> Am 12.03.2013 13:14, schrieb Martin Heusse: > Le 11 mars 2013 ? 23:27, Detlef Bosau a ?crit : > >> In general, sliding window addresses the work conservation. When this can be achieved with one segment, it's o.k. When it is reasonable, as in your sketch, to use 4 segments, it is o.k. as well. >> >> In the particular case of TCP, we do not know the best window size in advance and employ an estimation scheme. What I have in mind is to split up TCP congestion control along the path and so be able to use different estimation schemes along the individual segments. And you're correct, as others are (I got some PM on this one): window size 1 (segment) may not be adequate in any case. > Good, that was my point? :-) > Now, you'll have to admit: Have I? ;-) > 1) no one knows the number of store and forward hops nor the latency in advance so you have to guess (or create some kind of cross-layer mechanism? Good luck with that?) The first hop that your TCP/IP stack sees is the GGSN in the GPRS network, and there are many store and forward nodes between them. That's why I think we should split up the path. There are segments with known storage capacity - in these cases knowledge is better than any guess. And there are segments with unknown capacity, for these we need a guess. However, I doubt that the guess done by VJCC is adequate which includes a GPRS link. > 2) back-pressure congestion control is actually implemented in SS7 networks. (LLSU frames) The consequence of it is that a congestion somewhere creates congestion upstream and that's not good (that happened between Free-mobile and Orange in France not so long ago, as far as I know). > > Actually the fact that the congestion goes back upstream when no proper congestion control is used is a good argument against fountain code: links upstream of the congestion get congested? (Which is why, I guess, fair queueing is mandatory if you're going to change the paradigm?) At the moment, I ask questions. Actually, these questions are anything but trivial, and I'm afraid this will hold true for the answers as well. Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From touch at isi.edu Tue Mar 12 13:13:12 2013 From: touch at isi.edu (Joe Touch) Date: Tue, 12 Mar 2013 13:13:12 -0700 Subject: [e2e] Why do we need congestion control? In-Reply-To: <51387351.2060502@isae.fr> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> <51387351.2060502@isae.fr> Message-ID: <513F8C58.2090705@isi.edu> On 3/7/2013 3:00 AM, Emmanuel Lochin wrote: > On 07/03/2013 10:15, Detlef Bosau wrote: >> >> In addition to erasure codes: >> >> TCP provides /reliable/ transport. >> >> In the general case, you neither know your corruption ratio nor your >> drop ratio. So you cannot really determine a necessary "code >> strength", as you cannot predict the necessary attempts of >> retransmissions. >> >> The game erasure codes vs. retransmissions seems like running in a >> vicious circle to me. > Hi Detlef > > Both are complementary for me : you are faster with ARQ over small RTT > and faster with erasure coding over long-delay link. They are complementary: FEC (including erasure codes) always completes in finite time, but has a nonzero probability it will fail (i.e., that the data won't get through at all) ARQ always gets data through with 100% probability when it completes, but has a nonzero chance of taking an arbitrary long time to do so In both cases, you compensate for error by adding delay* (either coding over longer sequences or waiting for feedback). For fast links, ARQ's feedback loop can help. For high loss links, FEC's anticipation of loss can help. Neither one solves every problem completely, though. Joe *you can also compensate for delay by tolerating more error, if that's the trade-off you're interested in. --- From detlef.bosau at web.de Tue Mar 12 14:35:08 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 12 Mar 2013 22:35:08 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <513F8C58.2090705@isi.edu> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> <51387351.2060502@isae.fr> <513F8C58.2090705@isi.edu> Message-ID: <513F9F8C.2030402@web.de> Am 12.03.2013 21:13, schrieb Joe Touch: > They are complementary: > Perhaps, the German word "komplement?r" has a somewhat other connotation than "complementary" and perhaps, this confuses me here. (I have to ask for some patience when my English is not as good as it should be, I'm no native speaker.) > FEC (including erasure codes) always completes in finite time, > but has a nonzero probability it will fail (i.e., that the > data won't get through at all) > > ARQ always gets data through with 100% probability when > it completes, but has a nonzero chance of taking an > arbitrary long time to do so > > In both cases, you compensate for error by adding delay* (either > coding over longer sequences or waiting for feedback). > You cann summarize the whole thing perhaps in that way: - We can transmit a packet in bounded time, however with a non zero probability of failure. - We can reliably transmit a packet, however with a non zero probability of exceeding any bounded time. > For fast links, ARQ's feedback loop can help. > > For high loss links, FEC's anticipation of loss can help. > > Neither one solves every problem completely, though. > No objection here. > Joe > > *you can also compensate for delay by tolerating more error, if that's > the trade-off you're interested in. Currently I'm focussed on TCP. So my focus is more the delay introduced by reliable transmission.--- -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From vitacaishun at gmail.com Tue Mar 12 20:42:30 2013 From: vitacaishun at gmail.com (shun cai) Date: Wed, 13 Mar 2013 11:42:30 +0800 Subject: [e2e] Do we need congestion control for unicast traffic with intra-session network coding Message-ID: Hi, I am thinking of the congestion control problem for MORE-like traffic in Wireless Mesh networks, and get perplexed by some questions. I do apprecitate for your kind help. 1. MORE-like unicast traffic uses multipath routing with intra-session network coding, in which packets are randomly linearly encoded at both the source and the intermediates nodes. Specifically, Source s first divides the original message into batches, each containing K packets of the same length. It then generates and broadcasts random linearly combined packets within the current batch. Intermediates buffer the overheard packets, and then re-encode them before forwarding. Destination t recovers the original batch by collecting sufficient number of encoded packets, and then sends ACK to s so as to trigger the next batch until the whole message is delivered. 2. Packets belong to current batch should buffered at intermediate nodes, does the buffer here refer to the MAC queue or a cache at upper layer (e.g. socket buffer, or a cache in memory) . In my opinion, the received belong to a current batch will occupy the MAC queue for quite a long time before the whole batch is delivered to the destionation, which causes the MAC queue overflow very easily. So the better way is to buffer thesed packets at upper layer, right ? 3. If the packets are buffered at upper layer, the MORE traffic is less likely to be the reason of the congestion at routers, right? As the coded packets is generated and sent to MAC queue only when the MAC is able to transmit , at any time, there is at most one packet for each coded traffic in the MAC queue. 3. If the conjecture in item 2 is true, do we need any congestion control for MORE-like traffic? Regards, Kara -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130313/2a744901/attachment.html From Jon.Crowcroft at cl.cam.ac.uk Wed Mar 13 01:34:32 2013 From: Jon.Crowcroft at cl.cam.ac.uk (Jon Crowcroft) Date: Wed, 13 Mar 2013 08:34:32 +0000 Subject: [e2e] Do we need congestion control for unicast traffic with intra-session network coding In-Reply-To: References: Message-ID: A lot of people who looked at Mesh Networks a while back concluded that building a multihop network with contention MACs at each hop was a losing proposition - your reasoning below is a major part of why - probably one of my fave bits of work was Ed Knightly's system at Rice University, which basically did resource allocation of some kind or other - there's a sequence of papers of his http://www.informatik.uni-trier.de/~ley/pers/hd/k/Knightly:Edward_W=.html [some interesting ones on modifying 802.11 too) there's a lot of other work in similar space, but just mentioning one i've read more of... one way to picture this is that contention nets fare badly under load, so if you go through several contended hops towards the center of an urban mesh network, the residual goodput after n hops is gonna look like 1/nth (or worse) of what you'd get at the edges (for a uniform random traffic matrix) due to traffic concentration - if your peak capacity is 1/e, and decreases as you exceed the peak load, then 1/ne is going to look pretty terrible.. of course, a lot of mesh networks are actually multihop access networks, and might be a lot more tree structured, so you might do better (or a lot worse if the tree is upside down:) In missive , shun cai typed: >>Hi, >> >> I am thinking of the congestion control problem for MORE-like traffic >>in Wireless Mesh networks, and get perplexed by some questions. I do >>apprecitate for your kind help. >> >> 1. MORE-like unicast traffic uses multipath routing with intra-session >>network coding, in which packets are randomly linearly encoded at both the >>source and the intermediates nodes. Specifically, Source s first divides >>the original message into batches, each containing K packets of the same >>length. It then generates and broadcasts random linearly combined packets >>within the current batch. Intermediates buffer the overheard packets, and >>then re-encode them before forwarding. Destination t recovers the original >>batch by collecting sufficient number of encoded packets, and then sends >>ACK to s so as to trigger the next batch until the whole message is >>delivered. >> >> 2. Packets belong to current batch should buffered at intermediate >>nodes, does the buffer here refer to the MAC queue or a cache at upper >>layer (e.g. socket buffer, or a cache in memory) . >> In my opinion, the received belong to a current batch will occupy the >>MAC queue for quite a long time before the whole batch is delivered to >>the destionation, which causes the MAC queue overflow very easily. So >>the better way is to buffer thesed packets at upper layer, right ? >> >>3. If the packets are buffered at upper layer, the MORE traffic is less >>likely to be the reason of the congestion at routers, right? As the coded >>packets is generated and sent to MAC queue only when the MAC is able to >>transmit , at any time, there is at most one packet for each coded traffic >>in the MAC queue. >> >>3. If the conjecture in item 2 is true, do we need any congestion control >>for MORE-like traffic? >> >> >> >>Regards, >>Kara >> >>--bcaec51d20a41ba85004d7c632c5 >>Content-Type: text/html; charset=ISO-8859-1 >>Content-Transfer-Encoding: quoted-printable >> >>Hi,

=A0=A0=A0 I am thinking of the congestion control problem for= >>=A0 MORE-like traffic in Wireless Mesh networks, and get=20 >>perplexed by some questions. I do apprecitate for your kind help.

= >>=A0=A0 1. MORE-like unicast=A0 traffic uses multipath routing with intra-se= >>ssion network coding, in which packets are randomly linearly encoded at bot= >>h the source and the intermediates nodes.=A0 Specifically, Source s first d= >>ivides the original message into batches, each containing K packets of the = >>same length. It then generates and broadcasts random linearly combined pack= >>ets within the current batch. Intermediates buffer the overheard packets, a= >>nd then re-encode them before forwarding. Destination t recovers the origin= >>al batch by collecting sufficient number of encoded packets, and then sends= >> ACK to s so as to trigger the next batch until the whole message is delive= >>red.
>> >>
=A0 2. Packets belong to current batch=A0 should buffered at=20 >>intermediate nodes, does=A0 the buffer here refer to the MAC queue >> or a cache at upper layer (e.g. socket buffer, or=A0 a cache in memory) . >>
=A0=A0=A0=A0 In my opinion,=A0 the received belong to a current batch = >>will=20 >>occupy the MAC queue=A0 for=A0 quite a long time before the whole batch is= >>=20 >>delivered to the destionation, which causes=A0 the=A0 MAC queue overflow=20 >>very easily.=A0 So the better way is to buffer thesed packets at upper=20 >>layer, right ?
>>
3. If the packets are buffered at upper layer,=A0 the MORE traffic is= >>=20 >>less likely to be the reason of the congestion at routers, right?=A0 As=20 >>the coded packets is=A0 generated and sent to MAC queue=A0 only when the MA= >>C is able to >> transmit , at any time, there is at most one packet for each coded=20 >>traffic in the MAC queue.
>>
3. If the conjecture in item 2 is true, do we need any congestion contr= >>ol for MORE-like traffic?



Regards,
Kara

>r>

>> >>--bcaec51d20a41ba85004d7c632c5-- cheers jon From detlef.bosau at web.de Wed Mar 13 10:52:45 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 13 Mar 2013 18:52:45 +0100 Subject: [e2e] Wireless Networks. An Example: GPRS. In-Reply-To: References: <513DCBDB.30703@web.de> <513E330E.6080102@web.de> <0501C87E-8129-4C07-907B-DFD34FA946A1@imag.fr> <513E5A53.9040605@web.de> Message-ID: <5140BCED.3030008@web.de> Just me again. Am 12.03.2013 13:14, schrieb Martin Heusse: > 1) no one knows the number of store and forward hops nor the latency > in advance so you have to guess (or create some kind of cross-layer > mechanism? Good luck with that?) The first hop that your TCP/IP stack > sees is the GGSN in the GPRS network, and there are many store and > forward nodes between them. I agree with you that we need to know "somehow", how many packets can be kept in flight. However, how is this known in wireless networks? That's one interesting question! When the "only link" is a GPRS link (admittedly not only the air interface but the other necessary nodes as well) or some other wireless link technology, how do you know the "path capacity"? Up to now, I think we have a certain loss differentiation problem, so VJCC will fail here. So, how do we handle this? Add 10 Ethernet links in advance and 10 afterwards and solve the problem end 2 end? That's the core of my question. A congestion control strategy which cannot successfully deal with a single link is not fixed by adding links in advance and links after "the problem". A correct e2e congestion control strategy will certainly work for each single link or link or switching node along the path! Or don't you agree here? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From touch at isi.edu Thu Mar 14 13:16:58 2013 From: touch at isi.edu (Joe Touch) Date: Thu, 14 Mar 2013 13:16:58 -0700 Subject: [e2e] Why do we need congestion control? In-Reply-To: <513F9F8C.2030402@web.de> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> <51387351.2060502@isae.fr> <513F8C58.2090705@isi.edu> <513F9F8C.2030402@web.de> Message-ID: <5142303A.6050007@isi.edu> On 3/12/2013 2:35 PM, Detlef Bosau wrote: > Am 12.03.2013 21:13, schrieb Joe Touch: >> They are complementary: >> > > Perhaps, the German word "komplement?r" has a somewhat other connotation > than "complementary" and perhaps, this confuses me here. > (I have to ask for some patience when my English is not as good as it > should be, I'm no native speaker.) No worries. Your English is much better than my German ;-) >> FEC (including erasure codes) always completes in finite time, >> but has a nonzero probability it will fail (i.e., that the >> data won't get through at all) >> >> ARQ always gets data through with 100% probability when >> it completes, but has a nonzero chance of taking an >> arbitrary long time to do so >> >> In both cases, you compensate for error by adding delay* (either >> coding over longer sequences or waiting for feedback). >> > > You cann summarize the whole thing perhaps in that way: > > - We can transmit a packet in bounded time, however with a non zero > probability of failure. > - We can reliably transmit a packet, however with a non zero probability > of exceeding any bounded time. Exactly. >> For fast links, ARQ's feedback loop can help. >> >> For high loss links, FEC's anticipation of loss can help. >> >> Neither one solves every problem completely, though. >> > > No objection here. >> Joe >> >> *you can also compensate for delay by tolerating more error, if that's >> the trade-off you're interested in. > > Currently I'm focussed on TCP. So my focus is more the delay introduced > by reliable transmission.--- Yes; I mention the alternative - of tolerating more error to reduce delay - because that was my PhD thesis, FWIW. Joe From detlef.bosau at web.de Fri Mar 15 16:22:37 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 16 Mar 2013 00:22:37 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <5142303A.6050007@isi.edu> References: <51385985.2000405@web.de> <51385AB8.3050500@web.de> <51387351.2060502@isae.fr> <513F8C58.2090705@isi.edu> <513F9F8C.2030402@web.de> <5142303A.6050007@isi.edu> Message-ID: <5143AD3D.9070705@web.de> Am 14.03.2013 21:16, schrieb Joe Touch: > > > On 3/12/2013 2:35 PM, Detlef Bosau wrote: >> Am 12.03.2013 21:13, schrieb Joe Touch: >>> They are complementary: >>> >> >> Perhaps, the German word "komplement?r" has a somewhat other connotation >> than "complementary" and perhaps, this confuses me here. >> (I have to ask for some patience when my English is not as good as it >> should be, I'm no native speaker.) > > No worries. Your English is much better than my German ;-) OMG, what shall I expect here? ;-) > >> >> You cann summarize the whole thing perhaps in that way: >> >> - We can transmit a packet in bounded time, however with a non zero >> probability of failure. >> - We can reliably transmit a packet, however with a non zero probability >> of exceeding any bounded time. > > Exactly. Puh.... We have an agreement :-) > >> Currently I'm focussed on TCP. So my focus is more the delay introduced >> by reliable transmission.--- > > Yes; I mention the alternative - of tolerating more error to reduce > delay - because that was my PhD thesis, FWIW. Do you want to tolerate more error on the application side? In that case, you would drop the traditional TCP as a "reliable byte stream". Detlef > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From fred at cisco.com Sat Mar 16 14:00:41 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 16 Mar 2013 21:00:41 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: Message-ID: <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> Keshav: Good to hear from you. It's been a while since we chatted. The IETF has decided that it needs to update RFC 2309, which is a statement from the End-to-End Research Group encouraging vendors and operators to implement AQM, and specifically RED, to cooperate with TCP-and-etc congestion control mechanisms. To that end, I took it upon myself to write a proposed update. At this point, it's literally that, and could use serious review by people who know more about it than I. "I am an egg." Discussion will be on that list, so I'm inviting folks on end-to-end at postel.org to join it. https://www.ietf.org/mailman/listinfo/aqm aqm at ietf.org If you do, fair warning: you are now as much a "member" of the IETF as I am. The document I have posted, and solicit comment on, is http://tools.ietf.org/html/draft-baker-aqm-recommendation "IETF Recommendations Regarding Active Queue Management", Fred Baker, 15-Mar-13 AQM will be discussed on this list, and in a BOF (I'm told) at IETF 87 in Berlin next summer. > From: "Fred Baker (fred)" > Subject: Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-00.txt > Date: March 15, 2013 7:51:43 PM MDT > To: "aqm at ietf.org" > > Somewhat with my heart in my hands, given discussion on this list about text I botched and about RFC 2309's recommendation of RED, I have taken it upon myself to do a wholesale replacement of RFC 2309. I'd appreciate people's comments - especially from the original authors of RFC 2309. > > For comparison and review purposes, you may like to look at a diff from RFC 2309. If so, go to > http://tools.ietf.org/rfcdiff > and give it two URLs: > http://www.rfc-editor.org/rfc/rfc2309.txt > http://www.ietf.org/id/draft-baker-aqm-recommendation-00.txt > >> >> A new version of I-D, draft-baker-aqm-recommendation-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >> >> Filename: draft-baker-aqm-recommendation >> Revision: 00 >> Title: IETF Recommendations Regarding Active Queue Management >> Creation date: 2013-03-15 >> Group: Individual Submission >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-00.txt >> Status: http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation >> Htmlized: http://tools.ietf.org/html/draft-baker-aqm-recommendation >> >> >> Abstract: >> This memo presents recommendations to the Internet community >> concerning measures to improve and preserve Internet performance. It >> presents a strong recommendation for testing, standardization, and >> widespread deployment of active queue management in routers, to >> improve the performance of today's Internet. It also urges a >> concerted effort of research, measurement, and ultimate deployment of >> router mechanisms to protect the Internet from flows that are not >> sufficiently responsive to congestion notification. >> >> >> >> >> The IETF Secretariat From mattmathis at google.com Sat Mar 16 18:26:17 2013 From: mattmathis at google.com (Matt Mathis) Date: Sat, 16 Mar 2013 21:26:17 -0400 Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> References: <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> Message-ID: On Sat, Mar 16, 2013 at 5:00 PM, Fred Baker (fred) wrote: > The IETF has decided that it needs to update RFC 2309, I'm curious what this means? Who is "the IETF"? As far as I am concerned, the big problem with 2309 (by perhaps 2 order of magnitude) is that is was ignored, not that it gives bad advice. While it is true that today it could give somewhat better advice, that isn't where the problem lies. Yes there are still unanswered questions and more opportunity to be found in the current algorithms, but drop tail is 2 orders of magnitude worse than any of them. Anybody shipping droptail today is ripping off their customers. period. We know better. You know algorithms that are better, I know you do. There is no requirement for any standardization either. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. From l.wood at surrey.ac.uk Sat Mar 16 18:47:58 2013 From: l.wood at surrey.ac.uk (l.wood@surrey.ac.uk) Date: Sun, 17 Mar 2013 01:47:58 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> References: , <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> Message-ID: <290E20B455C66743BE178C5C84F124081A49EEF28E@EXMB01CMS.surrey.ac.uk> Fred, the IETF is not one thing. Did the request to update RFC2309 come from the IESG (currently lacking transport expertise, I see - big fuss on ietf at ietf.org), the IAB, a WG, BOF, or other? Your update backs away from engineering specifics in favour of generalities; it is very much a political, not an engineering, document. In backing away from recommending RED, it does nothing to fix RED. (See http://gettys.wordpress.com/2010/12/17/red-in-a-different-light/ and the 'RED in a different light' section down the page for details of bugs in RED.) For example, your draft concludes: "Internet routers SHOULD implement some active queue management mechanism to manage queue lengths," but doesn't say how. Imagine if in 1986 an RFC said: "Internet hosts SHOULD implement some congestion control mechanism to manage TCP packet transmission" and just left it at that. Problem solved! I am unable to grok why the RFC series specifies TCP congestion control behaviour in minute detail in standards documents, and yet does not do so for router behaviour affecting that selfsame congestion control. (Is this to leave competitive advantage to router manufacturers? Letting the market decide? Because congestion control isn't really that important? No idea.) Please first document the fixes to RED in a draft intended for RFC publication, and _then_ try updating a document encouraging people to implement it in routers. thanks, Lloyd Wood http://sat-net.com/L.Wood/ I am but an egghead. ________________________________________ From: end2end-interest-bounces at postel.org [end2end-interest-bounces at postel.org] On Behalf Of Fred Baker (fred) [fred at cisco.com] Sent: 16 March 2013 21:00 To: Srinivasan Keshav Cc: end2end-interest at postel.org Subject: Re: [e2e] Why do we need congestion control? Keshav: Good to hear from you. It's been a while since we chatted. The IETF has decided that it needs to update RFC 2309, which is a statement from the End-to-End Research Group encouraging vendors and operators to implement AQM, and specifically RED, to cooperate with TCP-and-etc congestion control mechanisms. To that end, I took it upon myself to write a proposed update. At this point, it's literally that, and could use serious review by people who know more about it than I. "I am an egg." Discussion will be on that list, so I'm inviting folks on end-to-end at postel.org to join it. https://www.ietf.org/mailman/listinfo/aqm aqm at ietf.org If you do, fair warning: you are now as much a "member" of the IETF as I am. The document I have posted, and solicit comment on, is http://tools.ietf.org/html/draft-baker-aqm-recommendation "IETF Recommendations Regarding Active Queue Management", Fred Baker, 15-Mar-13 AQM will be discussed on this list, and in a BOF (I'm told) at IETF 87 in Berlin next summer. > From: "Fred Baker (fred)" > Subject: Re: [aqm] New Version Notification for draft-baker-aqm-recommendation-00.txt > Date: March 15, 2013 7:51:43 PM MDT > To: "aqm at ietf.org" > > Somewhat with my heart in my hands, given discussion on this list about text I botched and about RFC 2309's recommendation of RED, I have taken it upon myself to do a wholesale replacement of RFC 2309. I'd appreciate people's comments - especially from the original authors of RFC 2309. > > For comparison and review purposes, you may like to look at a diff from RFC 2309. If so, go to > http://tools.ietf.org/rfcdiff > and give it two URLs: > http://www.rfc-editor.org/rfc/rfc2309.txt > http://www.ietf.org/id/draft-baker-aqm-recommendation-00.txt > >> >> A new version of I-D, draft-baker-aqm-recommendation-00.txt >> has been successfully submitted by Fred Baker and posted to the >> IETF repository. >> >> Filename: draft-baker-aqm-recommendation >> Revision: 00 >> Title: IETF Recommendations Regarding Active Queue Management >> Creation date: 2013-03-15 >> Group: Individual Submission >> Number of pages: 17 >> URL: http://www.ietf.org/internet-drafts/draft-baker-aqm-recommendation-00.txt >> Status: http://datatracker.ietf.org/doc/draft-baker-aqm-recommendation >> Htmlized: http://tools.ietf.org/html/draft-baker-aqm-recommendation >> >> >> Abstract: >> This memo presents recommendations to the Internet community >> concerning measures to improve and preserve Internet performance. It >> presents a strong recommendation for testing, standardization, and >> widespread deployment of active queue management in routers, to >> improve the performance of today's Internet. It also urges a >> concerted effort of research, measurement, and ultimate deployment of >> router mechanisms to protect the Internet from flows that are not >> sufficiently responsive to congestion notification. >> >> >> >> >> The IETF Secretariat From fred at cisco.com Sat Mar 16 19:24:55 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Sun, 17 Mar 2013 02:24:55 +0000 Subject: [e2e] Why do we need congestion control? In-Reply-To: References: <8C48B86A895913448548E6D15DA7553B7D59C8@xmb-rcd-x09.cisco.com> Message-ID: <8C48B86A895913448548E6D15DA7553B7D7F57@xmb-rcd-x09.cisco.com> I'll suggest that you look at the minutes from TSVAREA for the arguments and discussion. The key factor, though, is that RED, which RFC 2309 makes a great point on, has been widely implemented in commercial product from multiple vendors, but because it requires parameterization operationally, has not been not widely turned on. We now have at least two AQM algorithms on the table that auto-tune. As such, while the general statement of 2309 is a good one - that we need to implement AQM procedures - the specific one it recommends turned out to not be operationally useful. As to the specific statement that Lloyd seeks, and notes that the TCP community argues for one specific answer, I'll note that operationally-deployed TCP has more than one answer. There is Microsoft's Congestion Control algorithm, NewReno in FreeBSD, and CUBIC in Linux. There are other algorithms such as CAIA CDG that also fill the bottleneck in a path but manage to do so without challenging the cliff, which at least in my opinion is a superior model. Similarly, it is difficult to argue that everyone has to implement the same AQM algorithm. What is reasonable without doubt is that whatever algorithm is implemented, the requirement is that it manage queue depths to a statistically shallow queue. From dhavey at yahoo.com Sat Mar 16 20:25:25 2013 From: dhavey at yahoo.com (Daniel Havey) Date: Sat, 16 Mar 2013 20:25:25 -0700 (PDT) Subject: [e2e] Why do we need congestion control? Message-ID: <1363490725.39918.YahooMailClassic@web163005.mail.bf1.yahoo.com> Hi Fred, > We now have at least two AQM algorithms on the table that > auto-tune. > > As such, while the general statement of 2309 is a good one - > that we need to implement AQM procedures - the specific one > it recommends turned out to not be operationally useful. > > As to the specific statement that Lloyd seeks, and notes > that the TCP community argues for one specific answer, I'll > note that operationally-deployed TCP has more than one > answer. Well, perhaps all of the TCP community does not argue for one specific answer.? Let's think about Joe's thesis. They are complementary: FEC (including erasure codes) always completes in finite time, but has a nonzero probability it will fail (i.e., that the data won't get through at all) ARQ always gets data through with 100% probability when it completes, but has a nonzero chance of taking an arbitrary long time to do so This tells us that if we have horrible RTT then TCP retransmission will be a drag. However, if we have a nice RTT then TCP retransmission is what we want. One solution does not fit all. ...Daniel > There is Microsoft's Congestion Control algorithm, > NewReno in FreeBSD, and CUBIC in Linux. There are other > algorithms such as CAIA CDG that also fill the bottleneck in > a path but manage to do so without challenging the cliff, > which at least in my opinion is a superior model. > > Similarly, it is difficult to argue that everyone has to > implement the same AQM algorithm. What is reasonable without > doubt is that whatever algorithm is implemented, the > requirement is that it manage queue depths to a > statistically shallow queue. > From detlef.bosau at web.de Sun Mar 17 11:29:23 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 17 Mar 2013 19:29:23 +0100 Subject: [e2e] Why do we need congestion control? In-Reply-To: <1363490725.39918.YahooMailClassic@web163005.mail.bf1.yahoo.com> References: <1363490725.39918.YahooMailClassic@web163005.mail.bf1.yahoo.com> Message-ID: <51460B83.4050404@web.de> O.k., I just asked fro additional space for my mailbox because of the expected responses. Isn't AQM nothing else than some kind of "sophistically discard" packets? Any discarded packet is a potential retransmission. So, don't we run into the risk of suffering from a retransmission collapse? The more I think about it, the more I think that all this AQM stuff does not really /solve /a problem but /causes/ a problem. In some private message, the sender remarked: "A congestion control scheme that causes congestion - funny." Wouldn't it be the better alternative to avoid congestion than to fix it? Detlef Am 17.03.2013 04:25, schrieb Daniel Havey: > Hi Fred, > > >> We now have at least two AQM algorithms on the table that >> auto-tune. >> >> As such, while the general statement of 2309 is a good one - >> that we need to implement AQM procedures - the specific one >> it recommends turned out to not be operationally useful. >> >> As to the specific statement that Lloyd seeks, and notes >> that the TCP community argues for one specific answer, I'll >> note that operationally-deployed TCP has more than one >> answer. > Well, perhaps all of the TCP community does not argue for one specific answer. > > Let's think about Joe's thesis. > > They are complementary: > > FEC (including erasure codes) always completes in finite time, > but has a nonzero probability it will fail (i.e., that the > data won't get through at all) > > ARQ always gets data through with 100% probability when > it completes, but has a nonzero chance of taking an > arbitrary long time to do so > > This tells us that if we have horrible RTT then TCP retransmission will be a drag. However, if we have a nice RTT then TCP retransmission is what we want. > > One solution does not fit all. > > ...Daniel > >> There is Microsoft's Congestion Control algorithm, >> NewReno in FreeBSD, and CUBIC in Linux. There are other >> algorithms such as CAIA CDG that also fill the bottleneck in >> a path but manage to do so without challenging the cliff, >> which at least in my opinion is a superior model. >> >> Similarly, it is difficult to argue that everyone has to >> implement the same AQM algorithm. What is reasonable without >> doubt is that whatever algorithm is implemented, the >> requirement is that it manage queue depths to a >> statistically shallow queue. >> > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130317/a7ae2301/attachment-0001.html From detlef.bosau at web.de Mon Mar 18 16:39:48 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 00:39:48 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> Message-ID: <5147A5C4.4070301@web.de> Am 09.03.2013 14:31, schrieb Fred Baker (fred): > I'm personally of the opinion that loss-based congestion controls are > inefficient, for the simple reason that a mechanism that tunes to the > knee will generally achieve the same bit rate end to end as one that > tunes to the cliff (they will both, given that they have enough data > to do so, fill the bottleneck); However, one that tunes to the cliff > has to assume and account for some amount of self-inflicted loss, > which implies recovery delays and a reduction in end to end bit rate > comparable to the retransmission rate. CAIA CDG has, I think, > characteristics that would enable it to eliminate a number of data > center issues and issues on the wide wooly Internet. Yes, we need some > form of congestion control. We have proven that to ourselves time and > again. The question is "with what characteristics, seeking to achieve > what goal?" From what you say it becomes clear, that "congestion control" pursues at least three goals. 1.: Stability (in the sense of "no congestion loss"). 2.: Probing/Tuning (to the knee or to the cliff, that doesn't really matter here). 3.: Resource sharing / scheduling. These goals are intertwined, while the first one is the easiest to accomplish: Simply obey the conservation principle and you're done. The interesting issues are the second and the third one. Particularly for the third one, I'm not quite sure whether we really focus on the correct resource here. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Mar 19 03:08:08 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 11:08:08 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5147A5C4.4070301@web.de> References: <5134DDB5.70103@isi.edu>, <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> Message-ID: <51483908.2040602@web.de> Am 19.03.2013 00:39, schrieb Detlef Bosau: > > > From what you say it becomes clear, that "congestion control" pursues > at least three goals. > > 1.: Stability (in the sense of "no congestion loss"). > 2.: Probing/Tuning (to the knee or to the cliff, that doesn't really > matter here). > 3.: Resource sharing / scheduling. > > These goals are intertwined, while the first one is the easiest to > accomplish: Simply obey the conservation principle and you're done. > > The interesting issues are the second and the third one. > > Particularly for the third one, I'm not quite sure whether we really > focus on the correct resource here. > O.k., in some private mail, I was told that all these three goals are wrong, so I conclude that none of the aforementioned points is a goal of congestion control. Obviously, I did not understand any of the papers and PhD theses I read through the last decade. Hence, the remaining question is: Why do we need congestion control? (My bitter answer is: It's not the question whether we need it. It's the question why we don't do it. All these probing and dropping approaches only blow up the original retransmission collapse problem like Lehmann Brothers blew up our financial system!) -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From scott.brim at gmail.com Tue Mar 19 03:50:07 2013 From: scott.brim at gmail.com (Scott Brim) Date: Tue, 19 Mar 2013 06:50:07 -0400 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51483908.2040602@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> Message-ID: On Tuesday, March 19, 2013, Detlef Bosau wrote: > Am 19.03.2013 00:39, schrieb Detlef Bosau: > >> >> >> From what you say it becomes clear, that "congestion control" pursues at >> least three goals. >> >> 1.: Stability (in the sense of "no congestion loss"). >> 2.: Probing/Tuning (to the knee or to the cliff, that doesn't really >> matter here). >> 3.: Resource sharing / scheduling. >> >> These goals are intertwined, while the first one is the easiest to >> accomplish: Simply obey the conservation principle and you're done. >> >> The interesting issues are the second and the third one. >> >> Particularly for the third one, I'm not quite sure whether we really >> focus on the correct resource here. >> >> > O.k., in some private mail, I was told that all these three goals are > wrong, so I conclude that none of the aforementioned points is a goal of > congestion control. Obviously, I did not understand any of the papers and > PhD theses I read through the last decade. > > Hence, the remaining question is: Why do we need congestion control? > My answer: Our goal is to enhance overall user experience, and CC aids this because it allows differential treatment of traffic types, and enhances goodput within each type. swb -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130319/d062c999/attachment.html From detlef.bosau at web.de Tue Mar 19 06:21:45 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 14:21:45 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> Message-ID: <51486669.2090808@web.de> Looks like quite some moving target to me. I only repeat my three goals - because these are not invented by me but (nearly word by word) from the papers by Van Jacobson and Raj Jain. Hence, the famous quote by Mark Twain comes to my mind: "//Having lost sight of our goals, we redouble our efforts" I think, the main purpose of the discussion should be to clearly identify what we want to achieve at all. From what I read in the list and in some PM, I doubt that we have a congruent understanding of our goals. Detlef Am 19.03.2013 11:50, schrieb Scott Brim: > On Tuesday, March 19, 2013, Detlef Bosau wrote: > > Am 19.03.2013 00:39, schrieb Detlef Bosau: > > > > From what you say it becomes clear, that "congestion control" > pursues at least three goals. > > 1.: Stability (in the sense of "no congestion loss"). > 2.: Probing/Tuning (to the knee or to the cliff, that doesn't > really matter here). > 3.: Resource sharing / scheduling. > -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130319/aef21525/attachment.html From faber at isi.edu Tue Mar 19 12:31:33 2013 From: faber at isi.edu (Ted Faber) Date: Tue, 19 Mar 2013 12:31:33 -0700 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <51486669.2090808@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> Message-ID: <20130319193133.GF50149@vim.isi.edu> On Tue, Mar 19, 2013 at 02:21:45PM +0100, Detlef Bosau wrote: > Looks like quite some moving target to me. > > I only repeat my three goals - because these are not invented by me but > (nearly word by word) from the papers by Van Jacobson and Raj Jain. Let's be precise. Your sources are impeccable, but you're picking out the mechanisms and not the problem. Jain's A Timeout-Based Congestion Control Scheme for Window Flow-Controlled Networks in JSAC 1986 is beautifully clear on the spirit of the issue: A strategy to reduce the impact of overload in a network is called congestion control. He goes on to clarify: We distinguish between the terms flow control and congestion control as follows. Flow control is an agreement between a source and a destination to limit the flow of packets without taking into account the load on the network. The purpose of flow control is to ensure that a packet arriving at a destination will find a buffer there. Congestion control is primarily concerned with controlling the traffic to reduce overload on the network. Flow control limits traffic based on buffer availability at the destination, whereas, congestion control limits traffic based on buffer availability at intermediate nodes. Flow control is a bipartisan agreement Congestion control is a social (network-wide) law. Different connections on a network can choose different flow control strategies but nodes on the network should follow the same congestion control strategy, if it is to be useful. Keshav's thesis (http://dl.acm.org/citation.cfm?id=115995 ) takes this further, recognizing that each user perceives congestion - Jain's network overload - differently. He posits a utility/load tradeoff which nicely frames the problem. Congestion is perceived by a user when asking the network for more service results in less utility. I try to download another movie and all the things I'm doing suffer unacceptably. Congestion control is about trying to keep the network providing more utility for increasing load for the most users. That's a lot of jibbering to say that we need congestion control so that the #%$%^ network is worth using. > Hence, the famous quote by Mark Twain comes to my mind: "//Having lost > sight of our goals, we redouble our efforts" I believe you've saddled Mr. Clemens with another statement he never made. Citation? -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130319/3023f097/attachment.bin From detlef.bosau at web.de Tue Mar 19 12:41:00 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 20:41:00 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> Message-ID: <5148BF4C.1050108@web.de> Am 19.03.2013 11:50, schrieb Scott Brim: > > My answer: Our goal is to enhance overall user experience, What is "overall user experience"? Dave Reed always points to the experienced latency here. For some reasons, I sometimes want primarily high throughput. Jain (with reference to Len Kleinrock) points to the quotient Throughput/RTT. Are there incompatible views around? -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From sergey.gorinsky at imdea.org Tue Mar 19 14:29:42 2013 From: sergey.gorinsky at imdea.org (Sergey Gorinsky) Date: Tue, 19 Mar 2013 22:29:42 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5148BF4C.1050108@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <5148BF4C.1050108@web.de> Message-ID: <003601ce24e8$deb52870$9c1f7950$@gorinsky@imdea.org> Detlef, > What is "overall user experience"? Dave Reed always points to the experienced latency here. > For some reasons, I sometimes want primarily high throughput. You can have it both ways - low latency or high throughput, e.g., see M. Podlesny and S. Gorinsky, "Leveraging the Rate-Delay Trade-off for Service Differentiation in Multi-Provider Networks", IEEE Journal on Selected Areas in Communications, 29(5), pp. 997-1008, May 2011, http://fourier.networks.imdea.org/~sergey_gorinsky/pdf/JSAC_Leveraging_Rate- Delay.pdf Sergey From detlef.bosau at web.de Tue Mar 19 14:37:54 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 22:37:54 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <20130319193133.GF50149@vim.isi.edu> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> <20130319193133.GF50149@vim.isi.edu> Message-ID: <5148DAB2.8040704@web.de> Am 19.03.2013 20:31, schrieb Ted Faber: >> Hence, the famous quote by Mark Twain comes to my mind: "//Having lost >> sight of our goals, we redouble our efforts" > I believe you've saddled Mr. Clemens with another statement he never > made. Citation? Unfortunately I only no the second sources on the Internet....... *shame no me*. However, what you wrote is no contradiction to what I said? Nevertheless, this does not match quite some notes I got via PM.... Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Tue Mar 19 15:54:14 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Tue, 19 Mar 2013 23:54:14 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5148DAB2.8040704@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> <20130319193133.GF50149@vim.isi.edu> <5148DAB2.8040704@web.de> Message-ID: <5148EC96.3050102@web.de> Am 19.03.2013 22:37, schrieb Detlef Bosau: > Am 19.03.2013 20:31, schrieb Ted Faber: >>> Hence, the famous quote by Mark Twain comes to my mind: "//Having lost >>> sight of our goals, we redouble our efforts" >> I believe you've saddled Mr. Clemens with another statement he never >> made. Citation? > > Unfortunately I only no the second sources on the Internet....... > *shame no me*. > > However, what you wrote is no contradiction to what I said? > > Nevertheless, this does not match quite some notes I got via PM.... > > Detlef > Perhaps, a certain confusion results from the combination of "avoiding overload" (as you said) and resource sharing / scheduling. It's that combination which makes things difficult. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From faber at isi.edu Tue Mar 19 16:06:15 2013 From: faber at isi.edu (Ted Faber) Date: Tue, 19 Mar 2013 16:06:15 -0700 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <5148DAB2.8040704@web.de> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> <20130319193133.GF50149@vim.isi.edu> <5148DAB2.8040704@web.de> Message-ID: <20130319230615.GC1945@vim.isi.edu> On Tue, Mar 19, 2013 at 10:37:54PM +0100, Detlef Bosau wrote: > However, what you wrote is no contradiction to what I said? You're talking about some mechanisms used to solve the problem those other folks described. That isn't a contradiction, but I think you're missing the forest for the trees. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130319/3772bfd8/attachment.bin From detlef.bosau at web.de Wed Mar 20 04:34:37 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Mar 2013 12:34:37 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <20130319230615.GC1945@vim.isi.edu> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> <20130319193133.GF50149@vim.isi.edu> <5148DAB2.8040704@web.de> <20130319230615.GC1945@vim.isi.edu> Message-ID: <51499ECD.1010308@web.de> Am 20.03.2013 00:06, schrieb Ted Faber: > On Tue, Mar 19, 2013 at 10:37:54PM +0100, Detlef Bosau wrote: >> However, what you wrote is no contradiction to what I said? > You're talking about some mechanisms used to solve the problem those > other folks described. That isn't a contradiction, but I think you're > missing the forest for the trees. > Fine. And so, it is not reasonable to review the purpose of congestion control? Sometimes, I don't have the impression that I miss the forest for the trees, but we argue for different forests here. Forest 1: Stability. (Nearly forgotten, hardly mentioned in many PhD theses I read throughout the last decade, the only .) BTW: This forest is quite interesting, because from the system theory perspective, the often so called "buffer bloat problem" may well be a stability problem. (BTW2: This forest is mentioned in the congavoid paper in a footnote - I strongly suspect this one of the most ignored footnotes in computer science.) Forest 2: A reasonable trade off between work conservation on the one hand and acceptable delay on the other. IIRC this is Raj Jain's forest. Forest 3: Sharing and allocation of resources. IIRC the most comprehensive, if to my understanding not that widely accepted, work in this direction is Keshav's PhD thesis. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Wed Mar 20 05:02:03 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Wed, 20 Mar 2013 13:02:03 +0100 Subject: [e2e] Congestion control as a hot topic in IETF In-Reply-To: <20130319230615.GC1945@vim.isi.edu> References: <5134DDB5.70103@isi.edu> <2A886F9088894347A3BE0CC5B7A85F3E9AA0F399F6@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <8C48B86A895913448548E6D15DA7553B7C6B35@xmb-rcd-x09.cisco.com> <5147A5C4.4070301@web.de> <51483908.2040602@web.de> <51486669.2090808@web.de> <20130319193133.GF50149@vim.isi.edu> <5148DAB2.8040704@web.de> <20130319230615.GC1945@vim.isi.edu> Message-ID: <5149A53B.9070102@web.de> Am 20.03.2013 00:06, schrieb Ted Faber: > On Tue, Mar 19, 2013 at 10:37:54PM +0100, Detlef Bosau wrote: >> However, what you wrote is no contradiction to what I said? > You're talking about some mechanisms used to solve the problem those > other folks described. That isn't a contradiction, but I think you're > missing the forest for the trees. > Fine. And so, it is not reasonable to review the purpose of congestion control? Sometimes, I don't have the impression that I miss the forest for the trees, but we argue for different forests here. Forest 1: Stability. (Nearly forgotten, hardly mentioned in many PhD theses I read throughout the last decade, the only .) BTW: This forest is quite interesting, because from the system theory perspective, the often so called "buffer bloat problem" may well be a stability problem. (BTW2: This forest is mentioned in the congavoid paper in a footnote - I strongly suspect this one of the most ignored footnotes in computer science.) Forest 2: A reasonable trade off between work conservation on the one hand and acceptable delay on the other. IIRC this is Raj Jain's forest. Forest 3: Sharing and allocation of resources. IIRC the most comprehensive, if to my understanding not that widely accepted, work in this direction is Keshav's PhD thesis. (Sorry for me sending this twice, I'm to stupid to correctly send an e-mail....) Unfortunately, I only read some of Keshav's papers and I'm still to read the whole thesis. Forest 4: Finding the right trade-offs. From Dave Reed I know that he is strongly focussed on the overall delay. Some guys criticize the pure focus on throughput and mostly work conservation. (I'm sometimes told I must not talk about German politics here, but the "idle is evil" paradigm is the very core of quite some politics, be it the working morale of evangelic chistian churches or the work of the well known sociologist Max Weber.) The quotient (throughput / delay) is at least a possible trade off here. Perhaps, it is neither the only one nor the best one. But when some guys argue with "knee" and "cliff" here, they refer to the well known picture by Jain/Kleinrock. IIRC it was Joe Touch wo said (some time ago) the Internet may not give as always the resources we want, but we always get the resources we need. Actually, I see two extremes: Dedicated resources e.g. as in the IntServ architecture (which is, to a certain degree, nothing else as a reinvented circuit switching system) on the one hand, "chaotic swarm intelligence" and collective praying on the other. Now, the very purpose of our discussion, please correct me if I'm wrong, is to find a reasonable way in the middle - and that's what we are used to call "Best Effort". -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From lars at netapp.com Thu Mar 21 10:05:56 2013 From: lars at netapp.com (Eggert, Lars) Date: Thu, 21 Mar 2013 17:05:56 +0000 Subject: [e2e] Fwd: New Non-WG Mailing List: aqm -- Active Queue Management References: <20130320194153.2133.60344.idtracker@ietfa.amsl.com> Message-ID: Potentially of interest. Begin forwarded message: > From: IETF Secretariat > Subject: New Non-WG Mailing List: aqm -- Active Queue Management > Date: March 20, 2013 12:41:53 PDT > To: IETF Announcement List > Cc: , Martin Stiemerling > > > A new IETF non-working group email list has been created. > > List address: aqm at ietf.org > Archive: http://www.ietf.org/mail-archive/web/aqm/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/aqm > > Purpose: This list is for discussing requirements, recommendations, algorithms, evaluation techniques, and other topics related to active queue > management algorithms and methods for protecting flows from one > another at a bottleneck. > > For additional information, please contact the list administrators. > From detlef.bosau at web.de Thu Mar 28 09:48:39 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Mar 2013 17:48:39 +0100 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? Message-ID: <51547467.20607@web.de> Perhaps my question is a stupid one, however, can someone help me here? Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From oliver at net.t-labs.tu-berlin.de Thu Mar 28 11:38:28 2013 From: oliver at net.t-labs.tu-berlin.de (Oliver Hohlfeld) Date: Thu, 28 Mar 2013 19:38:28 +0100 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <51547467.20607@web.de> References: <51547467.20607@web.de> Message-ID: <51548E24.5050504@net.t-labs.tu-berlin.de> Hi, > Perhaps my question is a stupid one, however, can someone help me here? While there is a lack of evidence, I tend to believe the answer is no for most networks. Let me briefly elaborate on this issue. It is hard to provide a definite answer due to the multitude of possible devices and configurations. I tried conducting a survey of typical hardware combinations and talk to more operators, but had to give up at some point. Signs of buffer bloat: - I remember having read reports of queuing delays of up to one second in the Level 3 network. Unfortunately, I can't find the reference any more. Contra buffer bloat: - By working with a tier-1 network, I never found evidence for potential buffer bloat in their core and aggregation network (might be different for other networks). The aggregation network has been put under load and none of the devices showed excessive queuing. In fact, queuing delays were minimal. In the core, the buffers are "reasonably" sized and don't allow for excessive queuing. - Typical buffer sizes are around 100ms. Juniper "M-Series" routers are at 200ms. - While it is theoretically possible to have bloated buffers in the core, affording excessive buffering is getting more expensive / infeasible with increasing line card speed (e.g., 100GE). - The switching infrastructure in the aggregation network is typically not equipped with a lot of buffer space. In conclusion, from what I have seen so far, I believe that buffer bloat is mostly a problem at the edge. Oliver From detlef.bosau at web.de Thu Mar 28 12:31:00 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Thu, 28 Mar 2013 20:31:00 +0100 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <51548E24.5050504@net.t-labs.tu-berlin.de> References: <51547467.20607@web.de> <51548E24.5050504@net.t-labs.tu-berlin.de> Message-ID: <51549A74.30509@web.de> Am 28.03.2013 19:38, schrieb Oliver Hohlfeld: > Hi, > >> Perhaps my question is a stupid one, however, can someone help me here? > > While there is a lack of evidence, I tend to believe the answer > is no for most networks. > > Let me briefly elaborate on this issue. It is hard to provide a > definite answer due to the multitude of possible devices and > configurations. I tried conducting a survey of typical hardware > combinations and talk to more operators, but had to give up at some > point. > > Signs of buffer bloat: > - I remember having read reports of queuing delays of up to > one second in the Level 3 network. Unfortunately, I can't > find the reference any more. > > Contra buffer bloat: Sounds a bit as if buffer bloat is rarely "directly observed" but typically concluded from symptoms? > - By working with a tier-1 network, I never found evidence for potential > buffer bloat in their core and aggregation network (might be > different for other networks). The aggregation network has been put > under load and none of the devices showed excessive queuing. In > fact, queuing delays were minimal. > In the core, the buffers are "reasonably" sized and don't allow for > excessive queuing. > Hence, buffer bloat is anticipated by appropriate network design here? In other words: The tier-1 network is designed that way that tier-1 routers hardly are the bottlenecks for any flow? > - Typical buffer sizes are around 100ms. Juniper "M-Series" routers > are at 200ms. > > - While it is theoretically possible to have bloated buffers in the > core, affording excessive buffering is getting more expensive / > infeasible with increasing line card speed (e.g., 100GE). > > - The switching infrastructure in the aggregation network is > typically not equipped with a lot of buffer space. > > In conclusion, from what I have seen so far, I believe that buffer > bloat is mostly a problem at the edge. > > Oliver -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From booloo at ucsc.edu Thu Mar 28 12:42:55 2013 From: booloo at ucsc.edu (Mark Boolootian) Date: Thu, 28 Mar 2013 12:42:55 -0700 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <51548E24.5050504@net.t-labs.tu-berlin.de> References: <51547467.20607@web.de> <51548E24.5050504@net.t-labs.tu-berlin.de> Message-ID: > Let me briefly elaborate on this issue. It is hard to provide a > definite answer due to the multitude of possible devices and > configurations. I tried conducting a survey of typical hardware > combinations and talk to more operators, but had to give up at some > point. While not directly relevant to Detlef's question, I'll offer a pointer to some collected data on switch buffer capacity (L2/L3) for the benefit of anyone who cares: http://people.ucsc.edu/~warner/buffer.html From dhavey at yahoo.com Thu Mar 28 13:31:39 2013 From: dhavey at yahoo.com (Daniel Havey) Date: Thu, 28 Mar 2013 13:31:39 -0700 (PDT) Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? Message-ID: <1364502699.15279.YahooMailClassic@web163001.mail.bf1.yahoo.com> Having just finished my proposal and regained the ability to think about stuff, I'm going to agree with Oliver. I have no studies and I have no evidence.? However, I have a nice analysis ;^)? The ISP's edge router has a rate limiter because they want to sell us bandwidth.? However, they also don't want to drop those packets because they already did all the work of getting them to the edge router. This is a very likely place for bloat. Hmmmm, actually I do have a study: End-to-end Detection of ISP Traffic Shaping using Active and Passive Methods, Partha Kanuparthy and Constantine Dovrolis This is a large study with lots and lots of users all over the place. Check the paper for details, but, it indicates that token buckets are prevalent. If this is true, it is easy to imagine that the ISP's are configuring the queues on their edge routers so that they don't drop packets easily. ...Daniel --- On Thu, 3/28/13, Oliver Hohlfeld wrote: > From: Oliver Hohlfeld > Subject: Re: [e2e] Do we have buffer bloat on edge routers or on core routers? > To: end2end-interest at postel.org > Date: Thursday, March 28, 2013, 11:38 AM > Hi, > > > Perhaps my question is a stupid one, however, can > someone help me here? > > While there is a lack of evidence, I tend to believe the > answer > is no for most networks. > > Let me briefly elaborate on this issue. It is hard to > provide a > definite answer due to the multitude of possible devices > and > configurations. I tried conducting a survey of typical > hardware > combinations and talk to more operators, but had to give up > at some > point. > > Signs of buffer bloat: > - I remember having read reports of queuing delays of up to > ? one second in the Level 3 network. Unfortunately, I > can't > ? find the reference any more. > > Contra buffer bloat: > - By working with a tier-1 network, I never found evidence > for potential > ? buffer bloat in their core and aggregation network > (might be > ? different for other networks). The aggregation > network has been put > ? under load and none of the devices showed excessive > queuing. In > ? fact, queuing delays were minimal. > ? In the core, the buffers are "reasonably" sized and > don't allow for > ? excessive queuing. > > - Typical buffer sizes are around 100ms. Juniper "M-Series" > routers > ? are at 200ms. > > - While it is theoretically possible to have bloated buffers > in the > ? core, affording excessive buffering is getting more > expensive / > ? infeasible with increasing line card speed (e.g., > 100GE). > > - The switching infrastructure in the aggregation network > is > ? typically not equipped with a lot of buffer space. > > In conclusion, from what I have seen so far, I believe that > buffer > bloat is mostly a problem at the edge. > > Oliver > From detlef.bosau at web.de Sat Mar 30 07:29:15 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sat, 30 Mar 2013 15:29:15 +0100 Subject: [e2e] How many TCP flows fit in the Internet? Message-ID: <5156F6BB.8050901@web.de> After some days of thinking, I think this question is a huge part of the buffer bloat discussion re-framed. I think it is one of the sacred cows in our community, that a connect() call will not fail with an "Insufficient Ressources Error" and a TCP flow once it is established will hardly be terminated for an actual resource shortage. So basically, many of us expect an infinite number of flows being possible on the Internet - though we (me) are not always aware of this fact, and then wonder about the consequences. Of course, I can fit 10^10 TCP flows on an 10 MBit/s Ethernet link. However, I should not expect too much throughput (or goodput respectively) for the individual flows. Among all strategies of congestion control, in VJCC I miss the real establishment of the two by far most obvious.: In case of congestion 1. reduce the rate of existing flows. (In VJCC and actually existing TCP Implementations we hardly can reduce a flow's rate beyond 1MSS/CWND. Exept perhaps by employing a pacing scheme, however I'm not quite clear yet about possible consequences.) 2. reduce the number of flows. "Soft" version: Block out new flows. "Hard" version: Terminate existing ones. (Just to make this clear: We don't want to deliver the Internet from individual packets. In case of overload, we want to deliver the Internet from sources of load. When your classroom is overcrowded, you first shut the door that nobody will come in any more - and if this does not suffice you will ask some persons to leave the room. In this picture, AQM appears to me as if we opened the window - and the persons in the room throw out their handkerchiefs.) The hard version rises the question, which flows should be terminated and - even more important: How do applications deal with flow termination / flow re-routing and of course, with respect to re-routing, how to we achieve a load sensitive routing in the Internet? Sometimes I think, one of our sacred cows is the "perpetual motion machine cow": "There is infinite capacity in the Internet and we all can use it each and every day." Actually, the Internet has limited, if huge, capacity and the issue is to share this in a reasonable manner. Detlef (asking for more capacity for his mailbox. It's interesting - and actually inspiring - to see how many people lurk on this list and hardly write anything here, but are often interested in interesting discussions off list.) -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From algold at lncc.br Sat Mar 30 09:02:12 2013 From: algold at lncc.br (Alexandre Grojsgold) Date: Sat, 30 Mar 2013 13:02:12 -0300 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <1364502699.15279.YahooMailClassic@web163001.mail.bf1.yahoo.com> References: <1364502699.15279.YahooMailClassic@web163001.mail.bf1.yahoo.com> Message-ID: <51570C84.2070308@lncc.br> On 28-03-2013 17:31, Daniel Havey wrote: > Having just finished my proposal and regained the ability to think about stuff, I'm going to agree with Oliver. > > I have no studies and I have no evidence. However, I have a nice analysis ;^) The ISP's edge router has a rate limiter because they want to sell us bandwidth. However, they also don't want to drop those packets because they already did all the work of getting them to the edge router. > > This is a very likely place for bloat. I don't know ... if the "excessive" packets are part of a long living flow (large file xfer, voice conference, etc...) the ISP would rather drop a few packets early, and doing so signal the source that it must packet rate, than allow a big buffer to grow and mess up all flows. > > Hmmmm, actually I do have a study: > End-to-end Detection of ISP Traffic Shaping using Active and Passive Methods, Partha Kanuparthy and Constantine Dovrolis > > This is a large study with lots and lots of users all over the place. Check the paper for details, but, it indicates that token buckets are prevalent. If this is true, it is easy to imagine that the ISP's are configuring the queues on their edge routers so that they don't drop packets easily. > > ...Daniel > > --- On Thu, 3/28/13, Oliver Hohlfeld wrote: > >> From: Oliver Hohlfeld >> Subject: Re: [e2e] Do we have buffer bloat on edge routers or on core routers? >> To: end2end-interest at postel.org >> Date: Thursday, March 28, 2013, 11:38 AM >> Hi, >> >>> Perhaps my question is a stupid one, however, can >> someone help me here? >> >> While there is a lack of evidence, I tend to believe the >> answer >> is no for most networks. >> >> Let me briefly elaborate on this issue. It is hard to >> provide a >> definite answer due to the multitude of possible devices >> and >> configurations. I tried conducting a survey of typical >> hardware >> combinations and talk to more operators, but had to give up >> at some >> point. >> >> Signs of buffer bloat: >> - I remember having read reports of queuing delays of up to >> one second in the Level 3 network. Unfortunately, I >> can't >> find the reference any more. >> >> Contra buffer bloat: >> - By working with a tier-1 network, I never found evidence >> for potential >> buffer bloat in their core and aggregation network >> (might be >> different for other networks). The aggregation >> network has been put >> under load and none of the devices showed excessive >> queuing. In >> fact, queuing delays were minimal. >> In the core, the buffers are "reasonably" sized and >> don't allow for >> excessive queuing. >> >> - Typical buffer sizes are around 100ms. Juniper "M-Series" >> routers >> are at 200ms. >> >> - While it is theoretically possible to have bloated buffers >> in the >> core, affording excessive buffering is getting more >> expensive / >> infeasible with increasing line card speed (e.g., >> 100GE). >> >> - The switching infrastructure in the aggregation network >> is >> typically not equipped with a lot of buffer space. >> >> In conclusion, from what I have seen so far, I believe that >> buffer >> bloat is mostly a problem at the edge. >> >> Oliver >> > -- Laborat?rio Nacional de Computa??o Cient?fica http://www.lncc.br *Alexandre L. Grojsgold* (24) 2233-6003 / (21) 8011-5593 / (21) 2275-9945 r:15 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130330/e01ad3b6/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: graphics1 Type: image/jpeg Size: 3096 bytes Desc: not available Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20130330/e01ad3b6/graphics1.jpe From fred at cisco.com Sat Mar 30 15:11:34 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Sat, 30 Mar 2013 22:11:34 +0000 Subject: [e2e] Do we have buffer bloat on edge routers or on core routers? In-Reply-To: <51547467.20607@web.de> References: <51547467.20607@web.de> Message-ID: <8C48B86A895913448548E6D15DA7553B7EBBB3@xmb-rcd-x09.cisco.com> On Mar 28, 2013, at 9:48 AM, Detlef Bosau wrote: > Perhaps my question is a stupid one, however, can someone help me here? Typically, buffer bloat is reported in broadband networks, in the CPE router or the CMTS/BRAS that it connects to. That is the reason for RFC 6057; certain applications have the behavior of overloading broadband networks, preventing the service provider from delivering service as advertised to all of his customers consistently, and making him do something to schedule traffic. It is also observed in wifi networks, typically when heavily used, such as in metropolitan or conference wifi. A place folks might not think too hard about, but where switch manufacturers think about it, is in input-queued switches. Imagine I have many ingresses receiving traffic for the same egress, and all are at the same speed. I now have the classic situation of having the possibility of many inputs feeding the same queue and as a result overloading the queue; in this case, the ingresses are not only different, but on different cards and therefore different queue controllers. This is where we find ourselves interested not only in queue depth but actual time or expected time in queue; if the oldest packet in a queue is 10 or 15 ms in queue, even though the total amount of traffic in a queue is only 2-3 ms worth, I might want to start signaling to data sources. Mark Allman recently published a paper, in which he says that his massively over-provisioned FIOS network doesn't seem to have this problem, so he doesn't think it's a real problem. I see a lot of papers that commit the six philosophers fallacy (six blind philosophers approach an elephant, feel the part closest to them, and describe the elephant - "it's like a tree", "no, it's like a snake", "no, it's like a wall"...). Another is the paper that looked at one of the best engineered backbones in the world, measured traffic on high capacity fiber that was all rate shaped by coming through relatively low speed broadband links, and concluded that all traffic in the Internet showed little if any variation or queuing - and hence, we could almost live without queues at all. Leland's paper on self-similar Ethernet traffic (which is actually incorrect; it's heavy-tailed, not self-similar) was a surprise to the academic community because of the same basic fallacy. yes, buffer bloat happens. If it doesn't happen in a specific network, that's a good thing and I'm happy for the network. The primary way that network designers can reduce buffer bloat is over-provisioning. But there are applications that will drive to over-use any bandwidth given. At the point where over-provisioning makes a financial impact on the operator, expect him to do something to manage his costs. From detlef.bosau at web.de Sun Mar 31 04:10:24 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 31 Mar 2013 13:10:24 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <5156F6BB.8050901@web.de> References: <5156F6BB.8050901@web.de> Message-ID: <515819A0.7070405@web.de> I got some criticism on my post yesterday, so I think I should elaborate at least on one point. However, a general remark in the beginning. I have a strong focus on TCP here. Of course, TCP is neither the only protocol in the world nor the only one that may cause grief in some circumstances. The distinguishing property of TCP is responsiveness. TCP reacts upon packet loss, which is seen as load indicator, by reducing the load offered to the network. In TCP, responsiveness is (mainly) achieved by protocol means while for other protocols, e.g. voice streaming, responsiveness is often left to the application. It makes hence sense to have a look at TCP and understand how congestion, buffer bloat etc. can be handled and take this as a model for other protocols. Back to the point. Am 30.03.2013 15:29, schrieb Detlef Bosau: > ... > Among all strategies of congestion control, in VJCC I miss the real > establishment of the two by far most obvious.: > In case of congestion > 1. reduce the rate of existing flows. (In VJCC and actually existing > TCP Implementations we hardly can reduce a flow's rate beyond > 1MSS/CWND. Exept perhaps by employing a pacing scheme, however I'm not > quite clear yet about possible consequences.) Yesterday, I was told TCP can well reduce it's rate beyond 1 MSS/CWND. Now, to my understanding this is not possible with the pure sliding window mechanism itself. A TCP socket must not send anything else than a "complete TCP frame", with our without payload. It cannot send, say, "two bytes only". So a congestion window of, say, 3 bytes or less wouldn't make any sense. Of course, the GOODPUT (and that's what I was pointed to yesterday) can be arbitrarily low: In case of a packet being not acknowledged in time a sending socket does it's usual time out handling, including a timer backoff RTO *= 2; So, when a switch along the path cannot forward a packet due to insufficient queue capacity, the packet remains unacknowledged and is hence retransmitted. So, while the switch delivers the net from the "overload" imposed by this packet (the packet is dropped) the sender will repeat this packet over and over, until a user defined time out is exceeded or the packet is eventually acknowledged. This reduces GOODPUT. AND it causes additional network load, i.e. by retransmissions. So, we have the classical choice between Skylla and Charybdis here. Either we drop packets - and cause retransmissions, or we add buffer space to the switch and allow for buffer bloat. In the first case, the perceived goodput is reduced by timer back off, in the second case the rate CWND/RTT is reduced by increasing the RTT by increasing the queueing latency. Neither of these is a reasonable reduction of THROUGHPUT which deliveres the network from load. As I said above, I don't discuss ping or voice streams or online games here, resource sharing, load control and congestion control in non responsive protocols is left to the application. -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From mattmathis at google.com Sun Mar 31 11:08:39 2013 From: mattmathis at google.com (Matt Mathis) Date: Sun, 31 Mar 2013 11:08:39 -0700 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <515819A0.7070405@web.de> References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> Message-ID: You may have overlooked one additional important detail: Linux TCP ignores the requirement in RFC 2018 that the SACK scoreboard be cleared on a timeout. As a consequence, Linux TCP can attain total goodput=throughput for a single forward path bottleneck with average window size way below one segment. This is because it will not retransmit segments that are delivered. This region has important theoretical interest (it evades congestion collapse!) but is irrelevant from an operational perspective (nobody want to use a network that is so congested that the average available capacity is measured in bits per second.) There has been some work on multiple forward bottlenecks, which can exhibit congestion collapse (e.g. dead vs zombie packets). I believe that these cases are well understood in the "decongestion control" work, etc. I don't know how well the bidirectional high loss case has been studied, but feels mathematically straight forward. It does matter if TCP loss probing is in effect (see Nandita's Internet Draft). There is an errata against 2018, with the relevant details. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Mar 31, 2013 at 4:10 AM, Detlef Bosau wrote: > I got some criticism on my post yesterday, so I think I should elaborate at > least on one point. > > However, a general remark in the beginning. I have a strong focus on TCP > here. Of course, TCP is neither the only protocol in the world nor the only > one that may cause grief in some circumstances. The distinguishing property > of TCP is responsiveness. TCP reacts upon packet loss, which is seen as load > indicator, by reducing the load offered to the network. In TCP, > responsiveness is (mainly) achieved by protocol means while for other > protocols, e.g. voice streaming, responsiveness is often left to the > application. It makes hence sense to have a look at TCP and understand how > congestion, buffer bloat etc. can be handled and take this as a model for > other protocols. > > Back to the point. > > Am 30.03.2013 15:29, schrieb Detlef Bosau: >> >> ... >> >> Among all strategies of congestion control, in VJCC I miss the real >> establishment of the two by far most obvious.: >> In case of congestion >> 1. reduce the rate of existing flows. (In VJCC and actually existing TCP >> Implementations we hardly can reduce a flow's rate beyond 1MSS/CWND. Exept >> perhaps by employing a pacing scheme, however I'm not quite clear yet about >> possible consequences.) > > > Yesterday, I was told TCP can well reduce it's rate beyond 1 MSS/CWND. Now, > to my understanding this is not possible with the pure sliding window > mechanism itself. A TCP socket must not send anything else than a "complete > TCP frame", with our without payload. It cannot send, say, "two bytes only". > So a congestion window of, say, 3 bytes or less wouldn't make any sense. > > Of course, the GOODPUT (and that's what I was pointed to yesterday) can be > arbitrarily low: In case of a packet being not acknowledged in time a > sending socket does it's usual time out handling, including a timer backoff > > RTO *= 2; > > So, when a switch along the path cannot forward a packet due to insufficient > queue capacity, the packet remains unacknowledged and is hence > retransmitted. So, while the switch delivers the net from the "overload" > imposed by this packet (the packet is dropped) the sender will repeat this > packet over and over, until a user defined time out is exceeded or the > packet is eventually acknowledged. > > This reduces GOODPUT. > > AND > > it causes additional network load, i.e. by retransmissions. > > So, we have the classical choice between Skylla and Charybdis here. Either > we drop packets - and cause retransmissions, or we add buffer space to the > switch and allow for buffer bloat. In the first case, the perceived goodput > is reduced by timer back off, in the second case the rate CWND/RTT is > reduced by increasing the RTT by increasing the queueing latency. Neither of > these is a reasonable reduction of THROUGHPUT which deliveres the network > from load. > > As I said above, I don't discuss ping or voice streams or online games here, > resource sharing, load control and congestion control in non responsive > protocols is left to the application. > > > -- > ------------------------------------------------------------------ > Detlef Bosau > Galileistra?e 30 > 70565 Stuttgart Tel.: +49 711 5208031 > mobile: +49 172 6819937 > skype: detlef.bosau > ICQ: 566129673 > detlef.bosau at web.de http://www.detlef-bosau.de > From detlef.bosau at web.de Sun Mar 31 11:18:45 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Sun, 31 Mar 2013 20:18:45 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> Message-ID: <51587E05.4000307@web.de> Am 31.03.2013 20:08, schrieb Matt Mathis: > You may have overlooked one additional important detail: > > Linux TCP ignores the requirement in RFC 2018 that the SACK scoreboard Admittedly, I did not have SACK in mind. > be cleared on a timeout. As a consequence, Linux TCP can attain total > goodput=throughput for a single forward path bottleneck with average > window size way below one segment. However, I usually look into the RFC and don't take Linux as a standard. Nevertheless, you exactly got my point. > This is because it will not > retransmit segments that are delivered. Hence, the average number of data in flight may be less than one segment, which can be achieved by TCP pacing as well, however I'm still to understand the paper on pacing by Aggarval, Savage and Anderson, because they point to some deficiencies of pacing, so there may be some issues. > This region has important > theoretical interest (it evades congestion collapse!) but is > irrelevant from an operational perspective (nobody want to use a > network that is so congested that the average available capacity is > measured in bits per second.) Extremely interesting. Many thanks! Detlef -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de From detlef.bosau at web.de Sun Mar 31 15:22:57 2013 From: detlef.bosau at web.de (Detlef Bosau) Date: Mon, 01 Apr 2013 00:22:57 +0200 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: References: <5156F6BB.8050901@web.de> <515819A0.7070405@web.de> Message-ID: <5158B741.1030206@web.de> Am 31.03.2013 20:08, schrieb Matt Mathis: > retransmit segments that are delivered. This region has important > theoretical interest (it evades congestion collapse!) but is > irrelevant from an operational perspective (nobody want to use a > network that is so congested that the average available capacity is > measured in bits per second.) Particularly on this one. I agree that no one wants to use a overloaded network. However, as long as we have no actual limit for the number of flows along the path, the situation of network overload may happen now and then. The reason why I thought about this issue at all is still that I want to understand the buffer bloat phenomenon and the recent posts on that matter indicate that buffer bloat could be a consequence from network overload. Of course in combination with too large buffers on routers/switches. However, if we want to avoid buffer bloat and strictly encourage the use of reasonably limited buffer space, the problem would become more obvious. Particularly as flows wouldn't be simply "dropped" from the network but would suffer from a huge number of packet drops / retransmissions which would throttle the flows' goodputs. Hence throttling a flow's /throughput /may increase a flow's /goodput/. (The quote is credited to several persons: "If you're hurry go slow.") -- ------------------------------------------------------------------ Detlef Bosau Galileistra?e 30 70565 Stuttgart Tel.: +49 711 5208031 mobile: +49 172 6819937 skype: detlef.bosau ICQ: 566129673 detlef.bosau at web.de http://www.detlef-bosau.de -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20130401/40265422/attachment.html From fred at cisco.com Sun Mar 31 17:24:41 2013 From: fred at cisco.com (Fred Baker (fred)) Date: Mon, 1 Apr 2013 00:24:41 +0000 Subject: [e2e] How many TCP flows fit in the Internet? In-Reply-To: <5156F6BB.8050901@web.de> References: <5156F6BB.8050901@web.de> Message-ID: <8C48B86A895913448548E6D15DA7553B7ECC8D@xmb-rcd-x09.cisco.com> On Mar 30, 2013, at 7:29 AM, Detlef Bosau wrote: > Actually, the Internet has limited, if huge, capacity and the issue is to share this in a reasonable manner. Numbers in the integer space may be very large, but are generally finite. Yes, one can have only so many simultaneously-active active TCP sessions on any given link that actually accomplish something. The next question is how to figure out what "so many" means. I suspect that the most useful number is related somehow to a measure of bandwidth. If we assume that a mouse might move one MSS each way, or an elephant will want to move one MSS per RTT for several RTTs, the question is the duration of an MSS on the wire and the duration of a typical RTT; you're probably not going to have more active sessions simultaneously than some small multiple of the ratio of RTT to MSS. That question, of course, has similarities to the question of how many angels can dance on the head of a pin. That will perhaps have as a limiting function the ratio of the surface area of a head of a pin to the sole of an angel's foot. But when dancing, don't angels sometimes have their feet in the air? TCP will have the same problem.