From owner-ecm@wyvern.aciri.org Tue Jan 2 14:01:16 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21474 for ; Tue, 2 Jan 2001 14:01:15 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f02IvPo87234 for ecm-outgoing; Tue, 2 Jan 2001 10:57:25 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from angelstreet.com (tnt15b-130.focal-chi.corecomm.net [216.214.210.130]) by wyvern.aciri.org (8.11.1/8.11.1) with SMTP id f02IvKX87223; Tue, 2 Jan 2001 10:57:21 -0800 (PST) (envelope-from invest@angelstreet.com) From: Subject: Private Market Comments Date: Tue, 2 Jan 2001 13:03:56 Message-Id: <616.814909.414129@angelstreet.com> Reply-To: invest@angelstreet.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ecm@aciri.org Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by wyvern.aciri.org id f02IvPp87234 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA21474 As 2000 has come to an end, the sophisticated investor must look back on one of the most entertaining, if not disheartening, years ever. The public markets, the ones followed by virtually everyone, were increasingly subjected to intense review and comment by the media- both investment professional and general interest. 2000 was the year everyone would get rich and thanks must be given to the kids with the great internet ideas. Since April, the world has changed and the easy, simple investment times have disappeared. As many commentators and academics have stated, the world has not changed- the sun still rises in the East, the Yankees are still the best team in baseball and the election clearly shows what America wants (well, two out of three isn’t bad). And more importantly, revenue and profits do matter. Other than for some scientists and researchers, great technology is not the objective. Being able to use that technology in ways that people value and that they are willing to pay for gives meaning to technological progress. The public market has realized that technology-driven companies without meaningful revenue and sustainable profit margins cannot be good long-term investments. We have all seen companies with wonderful technology survive only because more investment is put in; at some point that must stop. Given the strong correlation between the public and the private markets, what do these trends mean for private investment? Generally, this is a good and improving time for the private investor. Since valuations must ultimately reflect public market pricing (the most readily apparent and generally accepted valuation method), values for private companies are coming down to reasonable levels. This reflects two related facts- due to the liquidity disadvantage of private investments, they must always be valued at a discount to comparable public companies. As the prices for the traded companies fall, so too does the value of the privates. But of greater import is the cycle effect (yes, business cycles still exist). A private investment made now can mature and be ready for a liquidity transaction in two or three years when the cycle again turns up. Technology is still being developed (some say the pace of tech change continues to increase as research becomes more productive, reflecting the tools now available and the expandied knowledge base) and greater emphasis is being placed on how it addresses peoples’ wants and desires and their willingness to pay for it. These opportunities continue to arise and with better (i.e. lesser) valuation for the private investor. We also know that technology is proceeding as fast if not faster in areas outside of the internet and information tech areas- in life sciences, material sciences and many other areas. Additionally, more traditional, “old (i.e. real businesses selling products and services people have been and continue to want and pay for) economy” companies are using new tools and technologies to increase their own financial results. Now and for the foreseeable future is a good time to look for private investments. Just concentrate on businesses that can sell their products and services at prices that give them profit. And know the cycle will turn and the investment returns will be there. Remember- the one key asset private investors have always needed, and still need, is patience. It will be rewarded. You are receiving this email either because you have sent us email in the past, or you are on a list of on-line marketers requesting information on financial products and services. If this is not the case, please accept my sincerest apologies and reply with "remove" in the subject field. I will remove your name immediately! For more information please vist our web site, call or email. http://www.angelstreet.com Sincerely, Jason Meyers Angelstreet 312-836-1333 invest@angelstreet.com From owner-ecm@wyvern.aciri.org Fri Jan 26 06:27:57 2001 Received: from wyvern.aciri.org ([192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03955 for ; Fri, 26 Jan 2001 06:27:56 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f0QBNRm34406 for ecm-outgoing; Fri, 26 Jan 2001 03:23:27 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.iol.ie (mail1.mail.iol.ie [194.125.2.192]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f0QBNQX34401 for ; Fri, 26 Jan 2001 03:23:26 -0800 (PST) (envelope-from brennanr@iol.ie) Received: from antioch (c-airlock147.esatclear.ie [194.145.132.147]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id LAA73104 for ; Fri, 26 Jan 2001 11:23:23 GMT Message-Id: <200101261123.LAA73104@mail.iol.ie> From: "Rob + Helena" To: Subject: SCTP congestion control questions Date: Fri, 26 Jan 2001 11:27:20 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All, I have been running some SCTP congestion control simulations and I have the following questions about the specification. I realise that this is a bit off topic but I'm not entirely happy with the limited responses I got on the SIGTRAN list, see http://standards.nortelnetworks.com/scripts/wa.exe?A1=ind0101&L=sigtran#39 and any help you could give would be much appreciated. Specifically: 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd when retransmitting a packet? (Section 6.1 of the spec seems to state yes, but this means that FR is not very fast :-) as it must wait for approx 1/2 a window of duplicate SACKs to arrive before it can do the retransmit) 2. Is SCTP supposed to react with TCP-style FR in the case where it receives duplicate SACKS with no Gap Ack Blocks? (Generation of gap ack blocks is a "SHOULD" but the spec doesn't seem to explicitly require any FR proceedure except on reception of Gap Ack blocks, Sections 7 and 7.2.4) 3. The FR proceedure outlined in section 7.2.4 (especially the implementation note) seems to lead to multiple retransmits of the same packet in the case where there is a large number of duplicate ACKs arriving. (counter goes to 4, packet is FR'd, counter is reset, 4+ duplicate sacks arrive before 1 rtt => packet is FR'd again. This of course also drastically reduces ssthresh and cwnd.) 4. 1 Packet loss with large windows, high bandwidth and long rtts can lead to very large bursts of up to half a window of packets. Does the spec (or current best practice) address this? (1 pkt lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window of data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = full size of buffers, when this SACK arrives sender can transmit cwnd (ie 1/2 ssthresh) packets immediately) Thanks again Rob Brennan Dublin City University From owner-ecm@wyvern.aciri.org Fri Jan 26 09:40:21 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11804 for ; Fri, 26 Jan 2001 09:40:21 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f0QEcBn35483 for ecm-outgoing; Fri, 26 Jan 2001 06:38:11 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f0QEc5X35478 for ; Fri, 26 Jan 2001 06:38:05 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id IAA32538; Fri, 26 Jan 2001 08:38:01 -0600 Message-ID: <3A718BC6.5DB278F1@stewart.chicago.il.us> Date: Fri, 26 Jan 2001 08:37:58 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rob + Helena CC: ecm@aciri.org, Vern Paxson , Lixia Zhang Subject: Re: SCTP congestion control questions References: <200101261123.LAA73104@mail.iol.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob: Hmm, let me try to answer... I know we chatted on the sigtran side a bit ago, but I am not sure I saw your recent email. The nortelnetworks mail server seems to be in real SAD shape right now. I am not getting ANY mail from it and every post I send says it is not being delivered. I don't know if this is related to blackouts in Calif, or what ... Rob + Helena wrote: > > Hi All, > > I have been running some SCTP congestion control simulations > and I have the following questions about the specification. I > realise that this is a bit off topic but I'm not entirely happy > with the limited responses I got on the SIGTRAN list, see > http://standards.nortelnetworks.com/scripts/wa.exe?A1=ind0101&L=sigtran#39 > and any help you could give would be much appreciated. > > Specifically: > > 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd > when retransmitting a packet? > (Section 6.1 of the spec seems to state yes, but this means that FR > is not very fast :-) as it must wait for approx 1/2 a window of duplicate > SACKs to arrive before it can do the retransmit) Yes, as far as I know this is true. You must obey the cwnd (and rwnd) for FR to kick in. I agree this means that you end up waiting 1/2 a window before you do the FR... In all practicality the rwnd would not get in the way, since even if rwnd is set at 0, you will add back the size of the segment you wish to FR thus enabling the sending of it. It is the cwnd that will really gate you. Vern/Lixia jump in here and give an opinion please... > > 2. Is SCTP supposed to react with TCP-style FR in the case where it > receives duplicate SACKS with no Gap Ack Blocks? > (Generation of gap ack blocks is a "SHOULD" but the spec doesn't > seem to explicitly require any FR proceedure except on reception > of Gap Ack blocks, Sections 7 and 7.2.4) > Hmm, good question. Duplicate SACK's would not strictly cause a FR if NO GAP ACK blocks showed up in it. For example: ----TSN101------------> ----TSN102-----X ----TSN103-----X <----------ACK-101 XX---TSN101--> <---ACK-101(Dup list 101) There is a Duplicate list inside the SACK that would be filled with the duplicate. In this case SCTP would NOT consider a strike against TSN102 or 103 since they could well still be "in-flight" when the Duplicate ACK was sent. You count strikes ONLY when you receive an indication (i.e. the Gap Ack Block) that for sure a TSN is missing. > 3. The FR proceedure outlined in section 7.2.4 (especially the > implementation note) seems to lead to multiple retransmits of > the same packet in the case where there is a large number of > duplicate ACKs arriving. > (counter goes to 4, packet is FR'd, counter is reset, 4+ duplicate > sacks arrive before 1 rtt => packet is FR'd again. > This of course also drastically reduces ssthresh and cwnd.) Yes, has we discussed earlier, I think this needs to change in the BIS. Right now, as you rightly pointed out, the packet could get retransmitted multiple times (as long as the cwnd allows it). We will probably need some wording in the BIS to indicate that once a segment as received a FR it is no longer eligible for FR until AFTER a timeout. This is only harmful to the sender in reality causing a reduction in its sending rate that is un-needed. I don't think this is a big threat, but it sure does slow down SCTP on a long fat pipe :< Vern/Lixia comments please? > > 4. 1 Packet loss with large windows, high bandwidth and long rtts > can lead to very large bursts of up to half a window of packets. > Does the spec (or current best practice) address this? > (1 pkt lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window > of data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = > full size of buffers, when this SACK arrives sender can transmit > cwnd (ie 1/2 ssthresh) packets immediately) > I'am not sure I am following this... tell me if I have it right (not enought coffee yet :>) When you lose a packet due to FR you do the following: ssthesh = max(1/2cwnd, 2 MTU) cwnd = ssthresh So are you concerned that a missing packet when the SACK finally catches up causes the sender to send 1/2 the previous cwnd into the network? Your assuming then that the sender is using ordered delivery and only one stream and cannot deliver any of the data until the lost (FR'd) packet arrives. So I think your point here is that since you do not allow the FR until 1/2 a window later when the cwnd opens up, you end up with this giant burst (when the SACK arrives for the lost packet) when if you had been allowed to send the FR when you first noticed it (regardless of the cwnd) you would only have a 4 MTU unit burst to worry about (i.e. how many MTU's it took you to recognize the need to retransmit). If I grok this right, this supports your argument for letting a FR happen no matter if cwnd allows it or not. Now, in some ways this argues against the change you propose in 3. Since if we think about the spec the current way it is written here is what would happen.. WARNING: My math may be a tiny bit off here, due to my lack of adequet coffee :) But it still illustrates both Rob's point 3 above AND my point... Assume: 100 segments in flight PMTU: 1500 bytes rwnd: 300,000 bytes (big :>) cwnd: 150000 ssthresh: 300,000bytes each segment is exactly 1500 bytes. <---4 the strike arrives (against number 1)---- Mark for retransmission TSN1 ssthresh = 75000 cwnd = 75000 flightsize = 148500 <----50 SACK's arrive ----Retransmit TSN1----> (46 more SACK's still coming showing TSN1 missing) <----4 more SACK's arrive---- Mark for retransmission TSN1 ssthresh = 37500 cwnd = 37500 flightsize = 73500 <----25 more SACK's arrive ------Retransmit TSN1-------> (17 more SACK's still coming showing TSN1 missing) <----4 more SACK's arrive---- Mark for retransmission TSN1 ssthresh=18750 cwnd = 18750 flightsize = 34500 <---12 More SACK's arrive---- -----Retransmit TSN1-------> <------2 more SACKS and FINALLY TSN1 is acknowledged... So at this point, I can only send 12 MTU's into the network or so. Now this example is of course assuming no-multihoming, since this would change the picture somewhat :)... 12 MTU's is quite a bit smaller than the 50 MTU burst you mention (for this example). However if we fix 3 above, then yes we would need to fix the FR issue and allow FR even when the cwnd does not allow it. Vern/Lixia comments??? R > Thanks again > Rob Brennan > Dublin City University -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Fri Jan 26 13:13:00 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16668 for ; Fri, 26 Jan 2001 13:12:59 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f0QIAoH38425 for ecm-outgoing; Fri, 26 Jan 2001 10:10:50 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.iol.ie (mail1.mail.iol.ie [194.125.2.192]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f0QIAnX38420 for ; Fri, 26 Jan 2001 10:10:49 -0800 (PST) (envelope-from brennanr@iol.ie) Received: from antioch ([194.165.166.209]) by mail.iol.ie Sendmail (v8.9.3) with ESMTP id SAA24565; Fri, 26 Jan 2001 18:10:12 GMT Message-Id: <200101261810.SAA24565@mail.iol.ie> From: "Rob + Helena" To: "Randall R. Stewart" Cc: , "Vern Paxson" , "Lixia Zhang" Subject: Re: SCTP congestion control questions Date: Fri, 26 Jan 2001 18:13:32 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1162 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Again Randall, thanks for taking the time to reply. I've snipped much of the previous mail in this reply. ---------- > From: Randall R. Stewart > > Specifically: > > > > 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd > > when retransmitting a packet? > > (Section 6.1 of the spec seems to state yes, but this means that FR > > is not very fast :-) as it must wait for approx 1/2 a window of duplicate > > SACKs to arrive before it can do the retransmit) > > Yes, as far as I know this is true. You must obey the cwnd (and rwnd) > for FR to kick in. I agree this means that you end up waiting 1/2 a > window before you do the FR... In all practicality the rwnd would > not get in the way, since even if rwnd is set at 0, you will add > back the size of the segment you wish to FR thus enabling the > sending of it. It is the cwnd that will really gate you. > > Vern/Lixia jump in here and give an opinion please... I agree that this gives better throughput BUT my hunch is that perhaps if FR always ignores cwnd it might get too agressive in the case of multiple lost packets and persistant congestion :-( I will have to do more simulations. > > > > > 2. Is SCTP supposed to react with TCP-style FR in the case where it > > receives duplicate SACKS with no Gap Ack Blocks? > > (Generation of gap ack blocks is a "SHOULD" but the spec doesn't > > seem to explicitly require any FR proceedure except on reception > > of Gap Ack blocks, Sections 7 and 7.2.4) > > > Hmm, good question. Duplicate SACK's would not strictly cause > a FR if NO GAP ACK blocks showed up in it. For example: > > ----TSN101------------> > ----TSN102-----X > ----TSN103-----X > <----------ACK-101 > XX---TSN101--> > <---ACK-101(Dup list 101) > > There is a Duplicate list inside the SACK that would be filled with > the duplicate. In this case SCTP would NOT consider a strike against > TSN102 or 103 since they could well still be "in-flight" when the > Duplicate ACK was sent. You count strikes ONLY when you receive > an indication (i.e. the Gap Ack Block) that for sure a TSN is missing. I don't know what this has to do with SACK duplicate lists, just assume that a lazy implementation has not implemented the generation of Gap Ack blocks - in this case I beleive that under the current spec there is no way to detect loss(other than timeout). I believe that the current "SHOULD" should be changed to a "MUST" generate gap ack blocks. > > > > 4. 1 Packet loss with large windows, high bandwidth and long rtts > > can lead to very large bursts of up to half a window of packets. > > Does the spec (or current best practice) address this? > > (1 pkt lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window > > of data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = > > full size of buffers, when this SACK arrives sender can transmit > > cwnd (ie 1/2 ssthresh) packets immediately) > > > I'am not sure I am following this... tell me if I > have it right (not enought coffee yet :>) > > When you lose a packet due to FR you do the following: > > ssthesh = max(1/2cwnd, 2 MTU) > cwnd = ssthresh > > > So are you concerned that a missing packet when the SACK finally > catches up causes the sender to send 1/2 the previous cwnd into > the network? Your assuming then that the sender is using > ordered delivery and only one stream and cannot deliver any > of the data until the lost (FR'd) packet arrives. Yes, but there will still be problems with mixed streams or ordered data (although not as extreme of course). > So I think your point here is that since you do not allow the FR > until 1/2 a window later when the cwnd opens up, you end up > with this giant burst (when the SACK arrives for the lost packet) > when if you had been allowed to send the FR when you first noticed > it (regardless of the cwnd) you would only have a 4 MTU unit burst > to worry about (i.e. how many MTU's it took you to recognize the > need to retransmit). > > If I grok this right, this supports your argument for letting a > FR happen no matter if cwnd allows it or not. > > > Now, in some ways this argues against the change you propose in > 3. The change I suggested for 3 is that once a packet is FR'd it may not be FR'd again until after a retransmission timeout. From the literature this seems to be the standard, conservative approach. I don't understand how this impacts on my point 4 about bursts. > Since if we think about the spec the current way it is written > here is what would happen.. I think your maths is OK but I think that you are making a hidden assumption: That the gap counter is only reset when a packet is actually retransmitted. The spec says "The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit proceedure, the counter resets to 0.". If we interpret "the fast retransmit proceedure" to mean halving cwnd, marking data for rtx and (only if allowed) retransmitting data then the counter is reset immediately every time it reaches 4. This of course triggers a collapse to the min cwnd of 2*pathMTU when a lot of dup SACKs are in the pipe. rgds rob From owner-ecm@wyvern.aciri.org Fri Jan 26 15:48:06 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21212 for ; Fri, 26 Jan 2001 15:48:05 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f0QKkEi39842 for ecm-outgoing; Fri, 26 Jan 2001 12:46:14 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from stewart.chicago.il.us (dsl-64-128-23-213.telocity.com [64.128.23.213]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f0QKkDX39837 for ; Fri, 26 Jan 2001 12:46:13 -0800 (PST) (envelope-from randall@stewart.chicago.il.us) Received: from stewart.chicago.il.us (IDENT:randall@stewart.chicago.il.us [10.1.1.1]) by stewart.chicago.il.us (8.9.3/8.8.7) with ESMTP id OAA01419; Fri, 26 Jan 2001 14:46:24 -0600 Message-ID: <3A71E21F.F714C5F3@stewart.chicago.il.us> Date: Fri, 26 Jan 2001 14:46:23 -0600 From: "Randall R. Stewart" X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Rob + Helena CC: ecm@aciri.org, Vern Paxson , Lixia Zhang Subject: Re: SCTP congestion control questions References: <200101261810.SAA24565@mail.iol.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Rob + Helena wrote: > > Hi Again Randall, > > thanks for taking the time to reply. > I've snipped much of the previous mail in this reply. > > ---------- > > From: Randall R. Stewart > > > Specifically: > > > > > > 1. Should the SCTP fast retransmit proceedure respect cwnd/rwnd > > > when retransmitting a packet? > > > (Section 6.1 of the spec seems to state yes, but this means that FR > > > is not very fast :-) as it must wait for approx 1/2 a window of > duplicate > > > SACKs to arrive before it can do the retransmit) > > > > Yes, as far as I know this is true. You must obey the cwnd (and rwnd) > > for FR to kick in. I agree this means that you end up waiting 1/2 a > > window before you do the FR... In all practicality the rwnd would > > not get in the way, since even if rwnd is set at 0, you will add > > back the size of the segment you wish to FR thus enabling the > > sending of it. It is the cwnd that will really gate you. > > > > Vern/Lixia jump in here and give an opinion please... > > I agree that this gives better throughput BUT my hunch is that > perhaps if FR always ignores cwnd it might get too agressive > in the case of multiple lost packets and persistant congestion :-( > I will have to do more simulations. > > > > > > > > > 2. Is SCTP supposed to react with TCP-style FR in the case where it > > > receives duplicate SACKS with no Gap Ack Blocks? > > > (Generation of gap ack blocks is a "SHOULD" but the spec doesn't > > > seem to explicitly require any FR proceedure except on reception > > > of Gap Ack blocks, Sections 7 and 7.2.4) > > > > > Hmm, good question. Duplicate SACK's would not strictly cause > > a FR if NO GAP ACK blocks showed up in it. For example: > > > > ----TSN101------------> > > ----TSN102-----X > > ----TSN103-----X > > <----------ACK-101 > > XX---TSN101--> > > <---ACK-101(Dup list 101) > > > > There is a Duplicate list inside the SACK that would be filled with > > the duplicate. In this case SCTP would NOT consider a strike against > > TSN102 or 103 since they could well still be "in-flight" when the > > Duplicate ACK was sent. You count strikes ONLY when you receive > > an indication (i.e. the Gap Ack Block) that for sure a TSN is missing. > > I don't know what this has to do with SACK duplicate lists, just assume > that a lazy implementation has not implemented the generation of Gap > Ack blocks - in this case I beleive that under the current spec there is > no way to detect loss(other than timeout). I believe that the current > "SHOULD" should be changed to a "MUST" generate gap ack blocks. > Opps, I missed your point yes it should be a MUST... generating gap ack blocks I don't think should be a option since unlike TCP we will NOT count strikes without Gap Acks... > > > > > > 4. 1 Packet loss with large windows, high bandwidth and long rtts > > > can lead to very large bursts of up to half a window of packets. > > > Does the spec (or current best practice) address this? > > > (1 pkt lost => cwnd =1/2 ssthresh, receiver buffer fills with 1 window > > > of data => a_rwnd = 0, then retransmitted pkt arrives => a_rwnd = > > > full size of buffers, when this SACK arrives sender can transmit > > > cwnd (ie 1/2 ssthresh) packets immediately) > > > > > I'am not sure I am following this... tell me if I > > have it right (not enought coffee yet :>) > > > > When you lose a packet due to FR you do the following: > > > > ssthesh = max(1/2cwnd, 2 MTU) > > cwnd = ssthresh > > > > > > So are you concerned that a missing packet when the SACK finally > > catches up causes the sender to send 1/2 the previous cwnd into > > the network? Your assuming then that the sender is using > > ordered delivery and only one stream and cannot deliver any > > of the data until the lost (FR'd) packet arrives. > > Yes, but there will still be problems with mixed streams or ordered > data (although not as extreme of course). > > > So I think your point here is that since you do not allow the FR > > until 1/2 a window later when the cwnd opens up, you end up > > with this giant burst (when the SACK arrives for the lost packet) > > when if you had been allowed to send the FR when you first noticed > > it (regardless of the cwnd) you would only have a 4 MTU unit burst > > to worry about (i.e. how many MTU's it took you to recognize the > > need to retransmit). > > > > If I grok this right, this supports your argument for letting a > > FR happen no matter if cwnd allows it or not. > > > > > > Now, in some ways this argues against the change you propose in > > 3. > > The change I suggested for 3 is that once a packet is FR'd it may not > be FR'd again until after a retransmission timeout. From the literature > this seems to be the standard, conservative approach. I don't understand > how this impacts on my point 4 about bursts. > Because if FR is bound by the cwnd then since you are collapsing cwnd (in the worst case to two MTU's as you note below) you will not be sending a 1/2 window of data... at least with the spec in the current form... > > Since if we think about the spec the current way it is written > > here is what would happen.. > > I think your maths is OK but I think that you are making a hidden > assumption: > That the gap counter is only reset when a packet is actually retransmitted. > The spec says "The counter increments for each consecutive SACK reporting > the TSN hole. After reaching 4 and starting the fast retransmit proceedure, > the > counter resets to 0.". > > If we interpret "the fast retransmit proceedure" to mean halving cwnd, > marking > data for rtx and (only if allowed) retransmitting data then the counter is > reset > immediately every time it reaches 4. This of course triggers a collapse to > the min cwnd of 2*pathMTU when a lot of dup SACKs are in the pipe. > Which would make your point 4 completely invalid (besides the bad performance issues in SCTP). But see my other point was that if you do fix 3 (which I think we should) then we also MUST fix 4 (i.e. only one fast retransmit until a timer goes off). 1) We need to fix your item 3 by at least making it so that you DON'T keep retransmitting until a T-O a TSN you have done a fast-retransmit on. 2) Your simulations would be most welcome to see if we should need to ignore the cwnd and send the FR anyway.. not sure on this one. Since if we do NOT do that, problem 4 as you note above will occur... R > rgds > rob -- Randall R. Stewart randall@stewart.chicago.il.us or rrs@cisco.com 815-342-5222 (cell) 815-477-2127 (work) From owner-ecm@wyvern.aciri.org Mon Jan 29 17:32:44 2001 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10928 for ; Mon, 29 Jan 2001 17:32:43 -0500 (EST) Received: (from majordomo@localhost) by wyvern.aciri.org (8.11.1/8.11.1) id f0TMQTg73819 for ecm-outgoing; Mon, 29 Jan 2001 14:26:29 -0800 (PST) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by wyvern.aciri.org (8.11.1/8.11.1) with ESMTP id f0TMQRX73808; Mon, 29 Jan 2001 14:26:27 -0800 (PST) (envelope-from misterprivacy@hushmail.com) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp id 14NMkB-0002x0-00; Mon, 29 Jan 2001 22:25:51 +0000 Received: from [206.133.83.14] (helo=localhost) by dfw-mmp4.email.verio.net with esmtp id 14NMjt-0000QD-00; Mon, 29 Jan 2001 22:25:33 +0000 X-Sender: misterprivacy@hushmail.com From: Dave To: "customer" Date: Mon, 29 Jan 2001 13:42:02 -0500 Subject: I could go to JAIL for selling this CD! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__8022710_49322.15" Message-Id: Sender: owner-ecm@aciri.org Precedence: bulk This is a Multipart MIME message. ------=_NextPart_000_001__8022710_49322.15 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__8022710_49322.15 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4 OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250 cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250 IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51 dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5 b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250 Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9 MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48 L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48 L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5 IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1 aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52 ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7 IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0 IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7 IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250 PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1 cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5 b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3 aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48 L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91 IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52 ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93 IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250 Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5 Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0 cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2 NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2 NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2 NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48 Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+ PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0 ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2 Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250 IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250 IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2 NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9 IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0 b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9 KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0 d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6 Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9 MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48 aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5 b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93 d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5 IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+ WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+ ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8 YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+ U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91 IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3 LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3 cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0 aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg== ------=_NextPart_000_001__8022710_49322.15--