From nobody Tue Nov 1 08:56:29 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847D5129ADB for ; Tue, 1 Nov 2016 08:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku0mUVEzWG7h for ; Tue, 1 Nov 2016 08:56:26 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DD712957A for ; Tue, 1 Nov 2016 08:56:03 -0700 (PDT) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87_RC121) id 1c1bPs-0001pG-5e for tcpm@ietf.org (return-path ); Tue, 01 Nov 2016 15:56:00 +0000 References: <147792042334.32506.9174702720038902578.idtracker@ietfa.amsl.com> To: tcpm@ietf.org From: Jeremy Harris X-Forwarded-Message-Id: <147792042334.32506.9174702720038902578.idtracker@ietfa.amsl.com> Message-ID: Date: Tue, 1 Nov 2016 15:55:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <147792042334.32506.9174702720038902578.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-harris-estab-wscale-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 15:56:28 -0000 Dear All, I have submitted a draft extending the use of the TCP Wscale option. Comments and suggestions are welcome. -- Jeremy -------- Forwarded Message -------- Subject: New Version Notification for draft-harris-estab-wscale-00.txt Date: Mon, 31 Oct 2016 06:27:03 -0700 From: internet-drafts@ietf.org To: Jeremy Harris A new version of I-D, draft-harris-estab-wscale-00.txt has been successfully submitted by Jeremy Harris and posted to the IETF repository. Name: draft-harris-estab-wscale Revision: 00 Title: WSCALE options in established TCP connections Document date: 2016-10-31 Group: Individual Submission Pages: 3 URL: https://www.ietf.org/internet-drafts/draft-harris-estab-wscale-00.txt Status: https://datatracker.ietf.org/doc/draft-harris-estab-wscale/ Htmlized: https://tools.ietf.org/html/draft-harris-estab-wscale-00 Abstract: The TCP Window Scale option modifies the interpretation of packets in a flow but is transmitted only at the start of the connection. As such there is a problem for observability and fault-finding, since a packet capture by a third party may miss the start of a relevant connection. This document describes the use of TCP options to provide the scale values during a connection. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Nov 1 15:36:32 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665612961A; Tue, 1 Nov 2016 15:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSSqOVhzmOQR; Tue, 1 Nov 2016 15:36:23 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id 62A0A129589; Tue, 1 Nov 2016 15:36:23 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 0F18817B64; Tue, 1 Nov 2016 15:36:23 -0700 (PDT) Date: Tue, 1 Nov 2016 15:36:22 -0700 From: hiren panchasara To: Bob Briscoe Message-ID: <20161101223622.GW71456@strugglingcoder.info> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PpfQBwiAIZcuDX26" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tcpm IETF list , AQM IETF list , tsvwg IETF list , TCP Prague List Subject: Re: [tcpm] [tcpPrague] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2016 22:36:24 -0000 --PpfQBwiAIZcuDX26 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Bob, A tiny correction in-line: On 11/01/16 at 12:02P, Bob Briscoe wrote: [snip] > * Data Centre TCP (DCTCP) for > o Linux (in the mainline kernel ) > o FreeBSD patch > https://svnweb.freebsd.org/base?view=revision&revision=r277054 It's been integrated in mainline FreeBSD for quite some time now. :-) Thanks for the whole writeup, btw. Cheers, Hiren --PpfQBwiAIZcuDX26 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF7BAABCgBmBQJYGRjjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lLKwH+N/rsPQuE9jqdWNHS++j39q0 3kXUQd9y/5i4vLas95wmYDeywfR5l/v07uB5T+ybT3TPBaEwIyzYAp4iF9SHoMIz +BB0K6sDPqRvgfABiJ/mz6pet6aVq0OPfIVxTY0SU0ehA98cGVdmyT2ld2ORI1Q5 mEl0qM/YmrXPpEdcfjowm8JIrdkJZrlr9RyGROmN0YXnB0vKI0fml7zhe7I4/chN wntaZ0p36YKdk20/2TG9GtznCeaAzuoK5YV+xkogB0HN+ALkfGobH8RRSNf3JodP IyCGqunWI80HP6QFYjtHspChIkvM5ETj3dWrFLeCYY8BGfHmXEs/mfYZkwLvyw== =fPO9 -----END PGP SIGNATURE----- --PpfQBwiAIZcuDX26-- From nobody Fri Nov 4 10:51:08 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2DC129446 for ; Fri, 4 Nov 2016 10:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGlryBIyPWTN for ; Fri, 4 Nov 2016 10:51:04 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34958129442 for ; Fri, 4 Nov 2016 10:51:03 -0700 (PDT) Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 319C627853A for ; Sat, 5 Nov 2016 02:51:02 +0900 (JST) Received: by mail-vk0-f43.google.com with SMTP id w194so73346306vkw.2 for ; Fri, 04 Nov 2016 10:51:02 -0700 (PDT) X-Gm-Message-State: ABUngveE7m3TgJLNCsVKX2SjQ/vgSDzpB9bKWAeCAnQiU5URauwch64rAZpVxhjNLD78fPVj3P0caaOQsq1owA== X-Received: by 10.31.216.4 with SMTP id p4mr10796527vkg.51.1478281860659; Fri, 04 Nov 2016 10:51:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.84.152 with HTTP; Fri, 4 Nov 2016 10:51:00 -0700 (PDT) From: Yoshifumi Nishida Date: Fri, 4 Nov 2016 10:51:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm-chairs@tools.ietf.org" Subject: [tcpm] current draft agenda for Seoul meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2016 17:51:06 -0000 Hi, I uploaded the current agenda plan for Seoul meeting on the following URL. Please note that this is still tentative and things might be changed. If you have comments, suggestions or questions, please let us know. https://www.ietf.org/proceedings/97/agenda/agenda-97-tcpm-00.txt Thanks! -- tcpm co-chairs From nobody Tue Nov 8 16:16:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542531298D5; Tue, 8 Nov 2016 16:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igLK25I65Hxk; Tue, 8 Nov 2016 16:16:22 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F50129443; Tue, 8 Nov 2016 16:16:22 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DE9FD50B8FBB1; Wed, 9 Nov 2016 00:16:15 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uA90GJDG003568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Nov 2016 00:16:20 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uA90FAXZ007567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Nov 2016 01:16:19 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Wed, 9 Nov 2016 01:16:18 +0100 From: "Scharf, Michael (Nokia - DE)" To: Carles Gomez Montenegro , "lwip@ietf.org" , "tcpm@ietf.org Extensions" Thread-Topic: [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt] Thread-Index: AQHSM3N8XbK/bgtr5USLkNUwp0et86DPv4Nw Date: Wed, 9 Nov 2016 00:16:18 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B68E11@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <563cd49c505340a559cded05282a3dc6.squirrel@webmail.entel.upc.edu> In-Reply-To: <563cd49c505340a559cded05282a3dc6.squirrel@webmail.entel.upc.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp-constrained-node-networks-01.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 00:16:25 -0000 Hi,=20 I like this version better than the former one. Yet, I still have quite a n= umber of observations: 1/ Target of the document (Best Current Practice) The survey in the Appendix is very useful and it would be good to expand it= . It states: 7.2. lwIP lwIP is a TCP/IP stack, targetted for 8- and 16-bit microcontrollers. lwIP has a total code size of ~14 kB to ~22 kB (which comprises memory management, checksumming, network interfaces, IP, ICMP and TCP), and a TCP code size of ~9 kB to ~14 kB [Dunk]. In contrast with uIP, lwIP decouples applications from the network stack. lwIP supports a TCP transmission window greater than a single segment, as well as buffering of incoming and outcoming data. Other implemented mechanisms comprise slow start, congestion avoidance, fast retransmit and fast recovery. SACK and Window Scale are not implemented. So, it seems to me that the guidance written in the document (only a single= window etc.) is actually *not* the best current practice actually used in = lightweight implementations. So, to me the document needs significant chang= es to cover the lwIP implementation correctly, which I think would be appro= priate. Or does the document target only environments for which this lwIP stack doe= s not apply? 2/ Section 2 I think you should better define the what exactly you mean by Constrained-N= ode Networks. For instance, is this limited to 6LoWPAN? What about some of = the emerging 4G/5G radio interfaces that focus on energy constrained device= s? Does the same guidance really apply to all (radio) networks? 2/ Section 4.2 Maximum Segment Size (MSS) I think this section would first benefit from a wider survey of link techno= logies before coming to conclusions. This sentence needs rewording regarding the "in any case", which could be r= ead in different ways in particular in isolation: "In any case, the TCP MSS= must not be set to a value leading to an IPv6 datagram size exceeding 1280= bytes." The next sentence also needs rewording: "If a link layer technology used by= a constrained device offers a link layer MTU greater than 1280 bytes, it i= s still useful to set the MSS so that IPv6 datagram size does not exceed 12= 80 bytes, in order to avoid issues due to Internet links that do not suppor= t greater MTUs." The Internet as a whole has means to handle MTUs larger th= an 1280 bytes, so this guidance seems not in general "useful".=20 3/ Section 4.3. Window Size =20 Why does this document include this recommendation even if there are releva= nt lightweight stacks that can do much better? I think what is more appropriate would be a wording such as: "A TCP stack c= an reduce the implementation complexity by advertising a TCP window size of= one MSS, and also transmit at most one MSS of unacknowledged data, at the = cost of decreased performance." And the following sentence should probably replace "use" by "allow": "For d= evices that can afford greater TCP window size, it may be useful to use win= dow sizes of at least five MSSs, in order to allow Fast Retransmit and Fast= Recovery [RFC5681]." If a sender has larger window sizes, it has to implem= ent congestion control, and as a result the window size will be variable. A= fter an RTO, it can be as low as one MSS and is thus less than 5 MSS. I cou= ld read this sentence as suggesting a fixed minimum window size, which is n= ot appropriate. 4/ Section 4.4. RTO estimation This section must be entirely rewritten. First of all, this section should = cite draft-ietf-tcpm-rto-consider and consider the guidance therein (in par= ticular Section 3). One of the key insights of draft-ietf-tcpm-rto-consider= is that there is typically no single best algorithm, as there are always t= radeoffs. If this conclusion was wrong, this document would have to explici= tly explain why. draft-ietf-tsvwg-rfc5405bis could also be referenced. To me, the key aspect that this section should probably discuss is that if = a sender uses only very small window sizes and can hardly use fast retransm= it (or even SACK), the RTO algorithm has a larger impact on the performance= than for a more powerful TCP stack. This may open room for some algorithm = tuning. But then the downsides of doing that should also be discussed (e.g.= , spurious timeouts etc.).=20 5/ Section 4.5. TCP connection lifetime I think in this section you should better separate what a TCP stack should = support, or not, and how the TCP stack should be used by applications, e.g.= , whether to close connections or not. 6/ Section 4.6. Explicit congestion notification As motivation for ECN the text notes "As transactional data size decreases,= the probability of detecting congestion by the presence of three duplicate= ACKs decreases." But three DUPACKs are quite impossible if the sender foll= ows Section 4.3, right? 7/ Section TCP options The sentence "A TCP implementation for a constrained device that uses a single-MSS TCP= receive or transmit window size will benefit from not supporting, and igno= ring if received, the following TCP options: Window scale [RFC1323], TCP Ti= mestamps [RFC1323], Selective Acknowledgements (SACK) and SACK-Permitted [R= FC2018]." should at least be reworded to=20 "A TCP implementation for a constrained device that uses a single-MSS TCP= receive or transmit window size may not benefit supporting from the follow= ing TCP options: Window scale [RFC1323], TCP Timestamps [RFC1323], Selectiv= e Acknowledgements (SACK) and SACK-Permitted [RFC2018]." I do not believe that RFC 2119 language of the form "Other TCP options SHOU= LD NOT be used, in keeping with the principle of lightweight operation." is= appropriate, in particular since it may also exclude future new TCP option= s that specifically target lightweight operation.=20 Also, this section may have to consider TFO options as this is discussed el= sewhere in the draft. 8/ Section 4.8. Delayed Acknowledgments I think the last paragraph in this section should be moved earlier in the d= ocument, i.e., the document should probably explain early the different typ= es of workloads in a CCN as well as their possibly different needs regardin= g TCP stack configuration. The assumption that most communication sizes is = smaller than one MSS is very fundamental and if it is violated, a lot of th= e reasoning in the document does not apply. 9/ Section 5. Security Considerations I am not a security expert but here is a question: If an attacker knows tha= t a TCP stack only uses a window of one MSS (because it sits in a CCN), and= if some packet can be passively intercepted, isn't the likelihood of succe= ssfully injecting segments into an established TCP connection larger? Another aspect to be mentioned is that certain TCP options can improve TCP = security (e.g., MD5, TCP-AO) but come along with complexity. Thanks Michael > -----Original Message----- > From: Lwip [mailto:lwip-bounces@ietf.org] On Behalf Of Carles Gomez Monte= negro > Sent: Monday, October 31, 2016 1:36 PM > To: lwip@ietf.org; tcpm@ietf.org Extensions > Subject: [Lwip] [Fwd: New Version Notification for draft-gomez-lwig-tcp- > constrained-node-networks-01.txt] >=20 > Dear LWIG and TCPM WGs, >=20 > Please find below pointers to our update of the TCP over Constrained-Node > Networks I-D. >=20 > In this version we expand the document while trying to address many of th= e > comments received on -00. The main changes are: >=20 > - Remove RFC 2119 language and rather document how TCP can be used in CNN= s >=20 > - Illustrate scenario (e.g. constrained to unconstrained device...) >=20 > - 'Allow' window greater than 1 MSS (and Fast recovery & Fast retransmit) >=20 > - Add TCP Fast Open subsection >=20 > - Add Delayed ACKs section >=20 > - Improve section on TCP options >=20 > - Collect implementation details (Annex) >=20 > Note that the home WG for this work is LWIG (as discussed in Berlin). >=20 > Thanks a lot for the feedback received so far. Comments on -01 are welcom= e > and appreciated! >=20 > Cheers, >=20 > Carles and Jon >=20 >=20 >=20 >=20 > ---------------------------- Original Message ---------------------------= - > Subject: New Version Notification for > draft-gomez-lwig-tcp-constrained-node-networks-01.txt > From: internet-drafts@ietf.org > Date: Mon, October 31, 2016 1:13 pm > To: "Jon Crowcroft" > "Carles Gomez" > -------------------------------------------------------------------------= - >=20 >=20 > A new version of I-D, draft-gomez-lwig-tcp-constrained-node-networks-01.t= xt > has been successfully submitted by Carles Gomez and posted to the > IETF repository. >=20 > Name: draft-gomez-lwig-tcp-constrained-node-networks > Revision: 01 > Title: TCP over Constrained-Node Networks > Document date: 2016-10-31 > Group: Individual Submission > Pages: 13 > URL: > https://www.ietf.org/internet-drafts/draft-gomez-lwig-tcp-constrained-nod= e- > networks-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gomez-lwig-tcp-constrained-node- > networks/ > Htmlized: > https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-network= s-01 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-gomez-lwig-tcp-constrained-node= - > networks-01 >=20 > Abstract: > This document provides a profile for the Transmission Control > Protocol (TCP) over Constrained-Node Networks (CNNs). The > overarching goal is to offer simple measures to allow for lightweight > TCP implementation and suitable operation in such environments. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > Lwip mailing list > Lwip@ietf.org > https://www.ietf.org/mailman/listinfo/lwip From nobody Thu Nov 10 15:21:46 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7690129886 for ; Thu, 10 Nov 2016 15:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zkjk8eMt8RpV for ; Thu, 10 Nov 2016 15:21:42 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D158129477 for ; Thu, 10 Nov 2016 15:21:41 -0800 (PST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BD8332785BC for ; Fri, 11 Nov 2016 08:21:39 +0900 (JST) Received: by mail-ua0-f181.google.com with SMTP id 12so428951uas.2 for ; Thu, 10 Nov 2016 15:21:39 -0800 (PST) X-Gm-Message-State: ABUngvePUITHz4oTHgdUXfO9pD4cSNoVF5hzAysyIftij97t9bIW8ZwGnk3tYJwTDkyvLCdS3PeqhE/Ce1WKOA== X-Received: by 10.176.2.167 with SMTP id 36mr104335uah.41.1478820098355; Thu, 10 Nov 2016 15:21:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.152 with HTTP; Thu, 10 Nov 2016 15:21:37 -0800 (PST) In-Reply-To: References: <147792042334.32506.9174702720038902578.idtracker@ietfa.amsl.com> From: Yoshifumi Nishida Date: Thu, 10 Nov 2016 15:21:37 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Harris Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] Fwd: New Version Notification for draft-harris-estab-wscale-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2016 23:21:45 -0000 Hi Jeremy, I think this is simple protocol and might be useful for some middle points that analyze network traffic. I have the following comments on the draft. 1: This might be beneficial for middle points that want to do some network analysis. However, I don't see benefits for sender and receiver. So, unless there are strong relationships between network analysis app and sender/receiver, sender/receiver won't have good motivation to implement and activate this feature. However, such relationship might not always exist. 2: For the same reason, it seems to be difficult for senders to decide whether activate this feature or not. Also, it's difficult to decide the interval for sending this option as it totally depends on network analysis apps. It seems that the draft presumes to use one fixed value for interval, but I'm not sure if we can find a proper value as I guess the requirements can be varied for some reasons. 3: The requirements in Section 2.3 won't be needed as it's already stated in Section 2.2 in RFC7323. So, I think this proposal will require sender-only modification. (which is better than updating both sides) 4: I think you'll need to refer RFC7323 instead of 1323 as 1323 is obsoleted. Thanks, -- Yoshi On Tue, Nov 1, 2016 at 8:55 AM, Jeremy Harris wrote: > Dear All, > > I have submitted a draft extending the use of the TCP Wscale option. > Comments and suggestions are welcome. > > -- > Jeremy > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-harris-estab-wscale-00.txt > Date: Mon, 31 Oct 2016 06:27:03 -0700 > From: internet-drafts@ietf.org > To: Jeremy Harris > > > A new version of I-D, draft-harris-estab-wscale-00.txt > has been successfully submitted by Jeremy Harris and posted to the > IETF repository. > > Name: draft-harris-estab-wscale > Revision: 00 > Title: WSCALE options in established TCP connections > Document date: 2016-10-31 > Group: Individual Submission > Pages: 3 > URL: > https://www.ietf.org/internet-drafts/draft-harris-estab-wscale-00.txt > Status: https://datatracker.ietf.org/doc/draft-harris-estab-wscale/ > Htmlized: https://tools.ietf.org/html/draft-harris-estab-wscale-00 > > > Abstract: > The TCP Window Scale option modifies the interpretation of packets in > a flow but is transmitted only at the start of the connection. As > such there is a problem for observability and fault-finding, since a > packet capture by a third party may miss the start of a relevant > connection. This document describes the use of TCP options to > provide the scale values during a connection. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Nov 11 14:05:30 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA71293F9 for ; Fri, 11 Nov 2016 14:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.897 X-Spam-Level: X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1W4ir-jY5CH for ; Fri, 11 Nov 2016 14:05:26 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C3312946B for ; Fri, 11 Nov 2016 14:05:26 -0800 (PST) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 77E022783B7 for ; Sat, 12 Nov 2016 07:05:24 +0900 (JST) Received: by mail-vk0-f53.google.com with SMTP id x186so23976840vkd.1 for ; Fri, 11 Nov 2016 14:05:24 -0800 (PST) X-Gm-Message-State: ABUngvdXquQt/30oCSkjRicKwHOFvAgQQ4Bu7MEbSTgJKOLhiB+maINJ60qyaCvITuHZ42b66MY3jVEvr3nFIA== X-Received: by 10.31.92.84 with SMTP id q81mr3637531vkb.88.1478901919674; Fri, 11 Nov 2016 14:05:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.152 with HTTP; Fri, 11 Nov 2016 14:05:19 -0800 (PST) From: Yoshifumi Nishida Date: Fri, 11 Nov 2016 14:05:19 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary=001a114e3b7c947bdc05410daf66 Archived-At: Subject: [tcpm] Slides for TCPM meeting in Seoul X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 22:05:28 -0000 --001a114e3b7c947bdc05410daf66 Content-Type: text/plain; charset=UTF-8 Hello presenters for Seoul meeting Please make sure to send your slide by ** Sunday (11/13) morning ** to chairs. We appreciate your cooperation! FYI, the current agenda is listed on the following link. https://datatracker.ietf.org/meeting/97/agenda/tcpm/ Thanks, -- tcpm co-chairs --001a114e3b7c947bdc05410daf66 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello presenters for Seoul meeting

Please make sure= to send your slide by ** Sunday (11/13) morning ** to chairs.
We appre= ciate your cooperation!

FYI, the current agenda is listed on the fo= llowing link.
https://datatracker.ietf.org/meeting/97/agenda/tcpm/

Than= ks,
--
tcpm co-chairs
--001a114e3b7c947bdc05410daf66-- From nobody Sun Nov 13 11:52:00 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF61294A3 for ; Sun, 13 Nov 2016 11:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Q7WRgep-iwj for ; Sun, 13 Nov 2016 11:51:56 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0090.outbound.protection.outlook.com [104.47.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329E012941A for ; Sun, 13 Nov 2016 11:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9OBAOKcN2NFNgUxxOcaDzUytQKKZq08FRk4S80jRbbo=; b=O7qXWIoI0Rr6yr41/3XV82LEYkLNelh9m8OnWRBq3PKBp4AFJgxELfPE3mx1KDXX5ol/MROqWHjmee5rV70v/uw3IOQBL4bagBGLPH+DS1F9AhTQkkpErz22IQTQyB+LZBE2rfAKnPYEQ8K8LRqduaycYAnZLKUKnOQgf+sKEy8= Received: from BY2PR03MB011.namprd03.prod.outlook.com (10.255.240.37) by BY2PR03MB012.namprd03.prod.outlook.com (10.255.240.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 13 Nov 2016 19:51:51 +0000 Received: from BY2PR03MB011.namprd03.prod.outlook.com ([169.254.14.33]) by BY2PR03MB011.namprd03.prod.outlook.com ([169.254.14.33]) with mapi id 15.01.0659.028; Sun, 13 Nov 2016 19:51:50 +0000 From: Praveen Balasubramanian To: "Scharf, Michael (Nokia - DE)" , "tcpm@ietf.org" Thread-Topic: Small nits in draft-ietf-tcpm-dctcp-02 Thread-Index: AdItMbsIl8Rgybz4SguDBFLZWDr53QQtZaVA Date: Sun, 13 Nov 2016 19:51:50 +0000 Message-ID: References: <655C07320163294895BBADA28372AF5D48B3D718@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D48B3D718@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:f::584] x-microsoft-exchange-diagnostics: 1; BY2PR03MB012; 7:z5ri83AFiXZQ2Q3vBIm/xf+btd4ml4kmqKBTInxRkY2YiHOJ123l5BES4sStFwevKTqKmZnjdxGJfe42FAdPUYuLO2c9cR+ThqV3nOCq1w1lyx0NE7u21zKcYcTZl223too3rvYWyQOE/8WYkx42mxizkss2xLOsjPcOBOj1K6+sKrrXUr342qbgKWSr21BmMxME0ACWO1AibJqp0rWZOqbQwcD5J11aq9YytmUkMASXkEDjVeJFpwKU/iMiUHPzlOR6vUio30M3ucw4H01cM9FNk9Aq8CFLosFBEb9YD8ce9+gvaen1I09sChGVyRLxIQr/t9raVZs/ZZZ52mXcQm4e8jWdOQyycbpNVGq3uRYrL3RnRZEW3qJC3xQdCyP3 x-ms-office365-filtering-correlation-id: 474294d7-db92-4293-8c4f-08d40bfe8257 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR03MB012; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BY2PR03MB012; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB012; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(336003)(189002)(199003)(377454003)(51914003)(13464003)(10290500002)(76576001)(87936001)(586003)(3280700002)(4326007)(54356999)(5005710100001)(230783001)(5660300001)(229853002)(10090500001)(33656002)(106356001)(8990500004)(105586002)(122556002)(50986999)(99286002)(92566002)(2906002)(102836003)(6116002)(86362001)(7846002)(101416001)(76176999)(81156014)(81166006)(97736004)(8936002)(2950100002)(9686002)(305945005)(5001770100001)(8676002)(86612001)(2501003)(7736002)(7696004)(189998001)(2900100001)(68736007)(74316002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB012; H:BY2PR03MB011.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 19:51:50.1520 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB012 Archived-At: Cc: "draft-ietf-tcpm-dctcp@tools.ietf.org" Subject: Re: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 19:51:58 -0000 Thanks for the review Michael. Inline prefixed with >>. -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (Nok= ia - DE) Sent: Sunday, October 23, 2016 6:31 AM To: tcpm@ietf.org Cc: draft-ietf-tcpm-dctcp@tools.ietf.org Subject: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02 Hi, As we want to move forward the DCTCP document, I had (again) a look at the = current version. I run into three nits that should be simple to fix: Section 1: "The queue must be short enough to absorb incast bursts without = excessive packet loss." Is this "short" really the intended meaning here? >> "short" indeed seems incorrect. Replacing with "long" in the next update= .=20 Figure 1: "m" is not introduced as far as I can see; this is only an editor= ial issue. >> Adding a sentence to introduce m as the delayed ACK frequency.=20 Section 8: The security considerations could probably comment on, or refer = to, the statements on security concerns in Section 3.4 ("The security conce= rns addressed by both these RFCs might not apply in controlled environments= like datacenters, and it might not be necessary to cater to both the prese= nce of non-ECN servers."). This would result in a more comprehensive Sectio= n 8. >> Removal of discussion of the security aspect in Section 3.4 makes sense.= Left in the recommendation in this section and moved the security impact t= o Section 8. Thanks Michael _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Sun Nov 13 13:10:53 2016 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7109D129432; Sun, 13 Nov 2016 13:10:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147907144845.5599.7971732507942066417.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 13:10:48 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-03.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:10:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions of the IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Lars Eggert Dave Thaler Praveen Balasubramanian Glenn Judd Filename : draft-ietf-tcpm-dctcp-03.txt Pages : 15 Date : 2016-11-13 Abstract: This informational memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic. DCTCP uses improved Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow-buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. DCTCP as described in this draft is applicable to deployments in controlled environments like datacenters but it MUST NOT be deployed over the public Internet without additional measures, as detailed in Section 5. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 13 15:31:54 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26C512965D for ; Sun, 13 Nov 2016 15:31:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLe_VGtshdCb for ; Sun, 13 Nov 2016 15:31:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA41B1295D0 for ; Sun, 13 Nov 2016 15:31:50 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id E122C5D33BCD7; Sun, 13 Nov 2016 23:31:44 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uADNVlw6015229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 13 Nov 2016 23:31:47 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uADNVkCe020403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2016 00:31:46 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.251]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 00:31:46 +0100 From: "Scharf, Michael (Nokia - DE)" To: Praveen Balasubramanian , "tcpm@ietf.org" Thread-Topic: Small nits in draft-ietf-tcpm-dctcp-02 Thread-Index: AdItMbsIl8Rgybz4SguDBFLZWDr53QQtZaVAAAen4dA= Date: Sun, 13 Nov 2016 23:31:45 +0000 Message-ID: <655C07320163294895BBADA28372AF5D48B78AD0@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D48B3D718@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-tcpm-dctcp@tools.ietf.org" Subject: Re: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 23:31:53 -0000 Thanks Praveen. The updated document -03 addresses my review. Michael > -----Original Message----- > From: Praveen Balasubramanian [mailto:pravb@microsoft.com] > Sent: Sunday, November 13, 2016 8:52 PM > To: Scharf, Michael (Nokia - DE); tcpm@ietf.org > Cc: draft-ietf-tcpm-dctcp@tools.ietf.org > Subject: RE: Small nits in draft-ietf-tcpm-dctcp-02 >=20 > Thanks for the review Michael. Inline prefixed with >>. >=20 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Scharf, Michael (N= okia > - DE) > Sent: Sunday, October 23, 2016 6:31 AM > To: tcpm@ietf.org > Cc: draft-ietf-tcpm-dctcp@tools.ietf.org > Subject: [tcpm] Small nits in draft-ietf-tcpm-dctcp-02 >=20 > Hi, >=20 > As we want to move forward the DCTCP document, I had (again) a look at th= e > current version. >=20 > I run into three nits that should be simple to fix: >=20 > Section 1: "The queue must be short enough to absorb incast bursts withou= t > excessive packet loss." Is this "short" really the intended meaning here? >=20 > >> "short" indeed seems incorrect. Replacing with "long" in the next upda= te. >=20 > Figure 1: "m" is not introduced as far as I can see; this is only an edit= orial > issue. >=20 > >> Adding a sentence to introduce m as the delayed ACK frequency. >=20 > Section 8: The security considerations could probably comment on, or refe= r to, > the statements on security concerns in Section 3.4 ("The security concern= s > addressed by both these RFCs might not apply in controlled environments l= ike > datacenters, and it might not be necessary to cater to both the presence = of > non-ECN servers."). This would result in a more comprehensive Section 8. >=20 > >> Removal of discussion of the security aspect in Section 3.4 makes sens= e. > Left in the recommendation in this section and moved the security impact = to > Section 8. >=20 > Thanks >=20 > Michael > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 14 08:01:41 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4F12941A for ; Sun, 13 Nov 2016 11:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKNMZRLAYg-E for ; Sun, 13 Nov 2016 11:52:20 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0131.outbound.protection.outlook.com [104.47.34.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484D612961A for ; Sun, 13 Nov 2016 11:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+FMpILQSkhSl+cxpJAgttyrgucu31eli+CLfXiNz35g=; b=df4aOAa12IEtNZt9yjTfGp2MsHwlFJYirSkMS3E9POnyNP4UehrtiFGjAlH6kSP+TA9gH/fttND7qFRv8Tv4lZX3lEbtj3GKbKmsO9dyBpJRWwRgoEA4/V9Fa1mkAE1M0FmSk6KrA3+Ibo1tM7osxuPBMo+ZVnd5B+/gH18LGOE= Received: from BY2PR03MB011.namprd03.prod.outlook.com (10.255.240.37) by BY2PR03MB012.namprd03.prod.outlook.com (10.255.240.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Sun, 13 Nov 2016 19:52:17 +0000 Received: from BY2PR03MB011.namprd03.prod.outlook.com ([169.254.14.33]) by BY2PR03MB011.namprd03.prod.outlook.com ([169.254.14.33]) with mapi id 15.01.0659.028; Sun, 13 Nov 2016 19:52:16 +0000 From: Praveen Balasubramanian To: Bob Briscoe Thread-Topic: Review of draft-ietf-tcpm-dctcp-01 Thread-Index: AQHRGMDBGTpsEllovUSobL5AqqWT0Z6S8nXAgb25KACAfKLFwA== Date: Sun, 13 Nov 2016 19:52:15 +0000 Message-ID: References: <563CF0F7.6070302@bobbriscoe.net> <71a48e5c-c992-de4d-12c3-7779ee702bd6@bobbriscoe.net> In-Reply-To: <71a48e5c-c992-de4d-12c3-7779ee702bd6@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-originating-ip: [2001:4898:80e8:f::584] x-microsoft-exchange-diagnostics: 1; BY2PR03MB012; 7:rQALbJWPV2HVZEreN5+L+UkYQ0FmBTvMHinkcQ2TObz54AiRTjbl61pheWCyPAMNFNrBSx04s8uVLrpdtq6r4mDKzZ1oQ1P55geVONy/qQC4ZpETmolzxFCYSj7tkccXRXFUdLLeYlcgIGnBP3yij+0lMu4SKTVtUkDo0MNKVkI+VNw+OZk4pjyRPyCMFobsOCdS0w6F2kCqHcPd+KFUjQ09U0o1d1k4suc9pZT0/vyS+z8eW80UAri5mLpzwEvVE2cIIK62IIcDXuGea7Br5UJ9jKWQDZHxr3NOk0UZTznNgU08Mcg7U5obQNmSoOPnfvxSCHbwwyoKGrs1y4sxTxESqKJFhLBY9ky5ANqAK1RrQr8pn6bTNi3XsmdsMgFI x-ms-office365-filtering-correlation-id: 738c3d8d-b02e-4987-ebcf-08d40bfe91b3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BY2PR03MB012; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(189930954265078)(222014917165493)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BY2PR03MB012; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB012; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(189002)(199003)(377454003)(51914003)(24454002)(10290500002)(76576001)(87936001)(586003)(3280700002)(4326007)(54356999)(5005710100001)(230783001)(5660300001)(106116001)(229853002)(10090500001)(33656002)(106356001)(8990500004)(105586002)(122556002)(50986999)(99286002)(92566002)(2906002)(15395725005)(102836003)(6116002)(790700001)(86362001)(7846002)(101416001)(7906003)(76176999)(81156014)(81166006)(97736004)(8936002)(2950100002)(9686002)(110136003)(8676002)(86612001)(7736002)(7696004)(189998001)(2900100001)(68736007)(74316002)(6916009)(3660700001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB012; H:BY2PR03MB011.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB0117403DA329375E35CB146B6BD0BY2PR03MB011namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 19:52:15.8920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB012 Archived-At: X-Mailman-Approved-At: Mon, 14 Nov 2016 08:01:38 -0800 Cc: tcpm IETF list Subject: Re: [tcpm] Review of draft-ietf-tcpm-dctcp-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 19:52:23 -0000 --_000_BY2PR03MB0117403DA329375E35CB146B6BD0BY2PR03MB011namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmV2aWV3IEJvYi4gSW5saW5lIHByZWZpeGVkIGJ5ID4+DQoNCkZyb206 IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IFRodXJzZGF5 LCBBdWd1c3QgMTgsIDIwMTYgOTozNiBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxw cmF2YkBtaWNyb3NvZnQuY29tPg0KQ2M6IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDENCg0KUHJhdmVl biwNCg0KT24gMTcvMDcvMTYgMjE6MjUsIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIHdyb3RlOg0K VGhhbmtzIEJvYi4gU29ycnkgZm9yIHRoZSA8cmlkaWN1bG91cz4gZGVsYXkuDQpbQkJdIEFuZCBu b3cgc29ycnkgZm9yIG15IGRlbGF5LiBJIHRyaWVkIHRvIGZpbmlzaCB0aGlzIGVtYWlsIGEgbnVt YmVyIG9mIHRpbWVzLCBidXQga2VwdCBnZXR0aW5nIGludGVycnVwdGVkLg0KDQpDb21tZW50cyBp bmxpbmUgcHJlZml4ZWQgYnkgPFByYXZlZW4+LiBNb3N0IG9mIHRoZXNlIGVkaXRzIHdpbGwgYmUg aW4gdGhlIG5leHQgcmV2aXNpb24uDQpbQkJdIEkndmUgdHJpZWQgdmVyeSBoYXJkIHRvIG9ubHkg Y29tbWVudCB3aGVyZSBJIHJlYWxseSBkbyB0aGluayB0aGVyZSBpcyBzdGlsbCBhIHByb2JsZW0g KGV2ZW4gaWYgbWlub3IpLCBhbmQgc3VnZ2VzdGVkIHNwZWNpZmljIHRleHQgdG8gaGVscCB5b3Uu Li4NCg0KDQoNClRoYW5rcw0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJp c2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDYsIDIwMTUgMTA6MjcgQU0NClRvOiBQ cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT48bWFpbHRvOnByYXZi QG1pY3Jvc29mdC5jb20+OyBFR0dFUlQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbT48bWFpbHRvOmxh cnNAbmV0YXBwLmNvbT47IFN0ZXBoZW4gQmVuc2xleSA8c2JlbnNAbWljcm9zb2Z0LmNvbT48bWFp bHRvOnNiZW5zQG1pY3Jvc29mdC5jb20+OyBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQu Y29tPjxtYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29tPjsgZ2xlbm4uanVkZEBtb3JnYW5zdGFu bGV5LmNvbTxtYWlsdG86Z2xlbm4uanVkZEBtb3JnYW5zdGFubGV5LmNvbT4NCkNjOiB0Y3BtIElF VEYgbGlzdCA8dGNwbUBpZXRmLm9yZz48bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZXZpZXcgb2YgZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTAxDQoNClByYXZlZW4gJiBjby1hdXRob3Jz LA0KDQpBcyBwcm9taXNlZCwgaGVyZSdzIG15IHJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tZGN0 Y3AtMDENCg0KR2VuZXJhbCBDb21tZW50cw0KDQpJbiBnZW5lcmFsLCBpbiB0aGUgY29tbWVudHMg YmVsb3cgSSBoYXZlIHRyaWVkIHRvIHJlZHVjZSB0aGUgbXVsdGlwbGUgYXNzdW1wdGlvbnMgYWJv dXQgY29udHJvbGxlZCBlbnZpcm9ubWVudHMgZG93biB0byB0aGUgb25lIGFzc3VtcHRpb24gdGhh dCB0aGV5IGFyZSBjb250cm9sbGVkIGJ5IGEgc2luZ2xlIGF1dGhvcml0eS4gSSBiZWxpZXZlIERD VENQIGNhbiB3b3JrIHdpdGhvdXQgdGhlIG90aGVyIGFzc3VtcHRpb25zLCBzbyB0aGUgZm9sbG93 aW5nIGRvIG5vdCBhcHBseSBpbiBhbGwgY29udHJvbGxlZCBlbnZpcm9ubWVudHM6DQogICogbm90 IGFsd2F5cyBsb3cgUlRUIChlLmcuIGludGVyLURDIHNjZW5hcmlvcywgb3IgZ2xvYmFsIHByaXZh dGUgbmV0d29ya3MpDQogICogbm90IGFsd2F5cyBubyByaXNrIG9mIHRyYWZmaWMgYXR0YWNrcyAo ZS5nLiBpbnRlcm5hbGx5IGFycmFuZ2VkIGF0dGFja3MpDQpJIG1heSBoYXZlIG1pc3NlZCBzb21l IG90aGVyIG9jY3VycmVuY2VzIG9mIHRoZXNlIGFzc3VtcHRpb25zLCBzbyBwbHMgZmVlbCBmcmVl IHRvIHNlZWsgb3V0IHRoZW0gYWxsLg0KDQoNCjxQcmF2ZWVuPiBEQ1RDUCBjYW4gYmUgZXh0ZW5k ZWQgdG8gb3RoZXIgZW52aXJvbm1lbnRzIGJ1dCB0aGlzIGRyYWZ0IGRvZXMgbm90IGNvdmVyIGFu eSBvZiB0aGF0LiBJdCBpcyBleHBsaWNpdGx5IGZvciBkZXBsb3ltZW50IGluIGEgZGF0YWNlbnRl ciB3aGVyZSB0aGUgUlRUIGlzIGxvdyBhbmQgdGhlcmUgaXMgbm8gcmlzayBvZiBpbnRlcm5hbCBh dHRhY2suIFdlIGNhbm5vdCBjb3ZlciBvdGhlciBzY2VuYXJpb3MgdGhhdCBoYXZlIG5vdCBiZWVu IHRlc3RlZCBvciBkZXBsb3llZC4gQWxsIHRoZSBrbm93biBkZXBsb3ltZW50cyBhcmUgaW4gY29u dHJvbGxlZCBkYXRhY2VudGVycy4gVGhlIFRDUCBQcmFndWUgZWZmb3J0IHNob3VsZCByZXN1bHQg aW4gYSBkcmFmdCB0aGF0IGNvdmVycyBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IHdpbGwg bWFrZSBEQ1RDUCB3b3JrIHdlbGwgb24gaGlnaCBsYXRlbmN5IGxpbmtzLg0KDQoNCk1hbnkgb2Yg dGhlIGNvbW1lbnRzIGFyZ3VlIHdpdGggeW91ciBjaG9pY2VzIG9mIE1VU1QsIFNIT1VMRCwgTUFZ IGV0Yy4gVGhpcyBtaWdodCBzZWVtIG5pdC1waWNraW5nLCBnaXZlbiB0aGUgcHJpbWFyeSBwdXJw b3NlIGlzIHRvIGRvY3VtZW50IHRoZSBhbGdvLiBIb3dldmVyLCBpdCB3b3VsZCBiZSB3cm9uZyB0 byByZXF1aXJlIHRoaW5ncyB0aGF0IGFyZW4ndCByZXF1aXJlZCBvciB0byBhbGxvdyBleGNlcHRp b25zIHdoZW4gZXhjZXB0aW9ucyB3b3VsZCBub3QgYmUgaW50ZXJvcGVyYWJsZS4gQW4gYWx0ZXJu YXRpdmUgYXBwcm9hY2ggd291bGQgYmUgdG8ganVzdCByZW1vdmUgYWxsIGNhcGl0YWxpc2VkIGxh bmd1YWdlLg0KDQoNCjxQcmF2ZWVuPiBJIGFtIGZpbmUgd2l0aCByZW1vdmluZyBzdWNoIGNhcGl0 YWxpemF0aW9uIGV4Y2VwdCBmb3Igd2hlbiByZW1vdmluZyBpdCB3aWxsIGxlYWQgdG8gaW50ZXJv cCBwcm9ibGVtcyBiZXR3ZWVuIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgRENUQ1AuIEkg YW0gcmVzcG9uZGluZyB0byBlYWNoIGNvbW1lbnQgYmVsb3cgYW5kIGFkZGluZyB3aGV0aGVyIHRo ZSBuZXcgcmV2aXNpb24gd2lsbCBmaXggaXQgbm90Lg0KDQpTZWN0aW9uLWJ5LXNlY3Rpb24gcmV2 aWV3Lg0KDQpBYnN0cmFjdA0KDQpJIHRoaW5rIGl0IG5lZWRzIHRvIGhhdmUgYW4gYXBwbGljYWJp bGl0eSBzdGF0ZW1lbnQgaW4gdGhlIGFic3RyYWN0IChhbmQgaW50cm9kdWN0aW9uKSB0aGF0IHJl ZmVycyB0byB0aGUgZGVwbG95bWVudCBhbmQgaW1wbGVtZW50YXRpb24gc3RhdHVzIHNlY3Rpb25z IGF0IHRoZSBlbmQuIFNvbWV0aGluZyBsaWtlOg0KDQoiVGhpcyBpcyBhbiBpbmZvcm1hdGlvbmFs IHNwZWNpZmljYXRpb24gb2YgdGhlIGltcGxlbWVudGF0aW9uIG9mIERDVENQIGluIE1pY3Jvc29m dCBXaW5kb3dzIFNlcnZlciAyMDEyLiBJdCBpcyBhcHBsaWNhYmxlIHRvIGRlcGxveW1lbnRzIGlu IGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIGxpa2UgZGF0YSBjZW50cmVzIGJ1dCBpdCBNVVNUIE5P VCBiZSBkZXBsb3llZCBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQgd2l0aG91dCBhZGRpdGlvbmFs IG1lYXN1cmVzLCBhcyBkZXRhaWxlZCBpbiBzZWN0aW9ucyA0LTYuICINCg0KDQo8UHJhdmVlbj4g VGhpcyBpcyBhbHJlYWR5IGFkZHJlc3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uLiBJIGRvbuKAmXQg c2VlIHRoZSB2YWx1ZSBvZiByZXBlYXRpbmcgaXQgbXVsdGlwbGUgdGltZXMuIEFuIGltcGxlbWVu dGVyIHdpbGwgcmVhZCB0aGUgaW50cm9kdWN0aW9uLiBJZiB5b3Ugc3RpbGwgZmVlbCBzdHJvbmds eSwgd2UgY2FuIGFkZCBpdCB0byB0aGUgYWJzdHJhY3QgYW5kIHJlbW92ZSBpdCBmcm9tIHRoZSBp bnRyb2R1Y3Rpb24gc2VjdGlvbi4gVGhpcyBkcmFmdCB3aWxsIG5vdCBjb3ZlciBhbnkgYWRkaXRp b25hbCBtZWFzdXJlcyB0aGF0IGFyZSBpbnRlbmRlZCBmb3IgZGVwbG95bWVudHMgb3V0c2lkZSB0 aGUgZGF0YWNlbnRlciDigJMgdGhhdOKAmXMgbm90IHRoZSBpbnRlbmRlZCBwdXJwb3NlLg0KW0JC XSBJdCBpcyB2ZXJ5IGNvbW1vbiBmb3IgdGhlIElFVEYgdG8gcmVxdWlyZSBldmVuIG11Y2ggbGVz cyBtaW5vciBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudHMgdG8gYmUgaGlnaGxpZ2h0ZWQgaW4gdGhl IGFic3RyYWN0IChlLmcuIHNlZSBURk8gUkZDKS4gVGhpcyBpcyBiZWNhdXNlIG5vd2FkYXlzIGlt cGxlbWVudGVycyAvIHJlYWRlcnMgb2Z0ZW4gc2tpcCBpbnRyb2R1Y3RvcnkgdGV4dCBhc3N1bWlu ZyB0aGV5IHVuZGVyc3RhbmQgdGhlIHByb2JsZW0sIGV0Yy4gYW5kIHRoZXkganVzdCBzY2FuIGZv ciB0aGUgbm9ybWF0aXZlIHBhcnRzLiBBbnlvbmUgcmVhZGluZyBhbiBJRVRGIFJGQ3MgYXNzdW1l cyB0aGUgY29udGV4dCBpcyB0aGUgcHVibGljIEludGVybmV0LCBzbyBhbnkgUkZDIHRoYXQgZG9l c24ndCBoYXZlIHRoYXQgY29udGV4dCBuZWVkcyB0byBmbGFnIHRoYXQuIEkga25vdyB0aGUgbmFt ZSBzYXlzIERhdGEgQ2VudHJlLCBidXQgdGhlIGFic3RyYWN0IG5lZWRzIHRvIGV4cGxhaW4gdGhh dCB0aGlzIGlzIG5vdCBhbiBJRVRGIFJGQyB0aGF0IGlzIHN0YW5kYXJkaXppbmcgRENUQ1AgZm9y IHRoZSBwdWJsaWMgSW50ZXJuZXQuDQoNCklmIHlvdSBzdGlsbCBkb24ndCB0aGluayBzbywgd2Ug c2hvdWxkIHB1dCB0aGlzIHRvIHRoZSBXRyAod2hpY2ggd2lsbCBzbG93IGl0IGRvd24pLg0KDQoN Cj4+IEFscmlnaHQgaW5jbHVkaW5nIHRleHQgdG8gZXhwbGljaXRseSBzYXkgc28uDQoNCg0KMS4g SW50cm8NCnMvaXRzIG1hbnkgc2VydmVycy8NCiAvdGhlaXIgbWFueSBzZXJ2ZXJzLw0KDQoNCjxQ cmF2ZWVuPiBGaXhlZCBpbiBuZXh0IHJldmlzaW9uLg0KDQoNCiIuLi5saW1pdGVkIHF1ZXVlIGNh cGFjaXRpZXMuLi4iDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGUgbW90aXZhdGlvbiBoYXMgYmVlbiBh YmJyZXZpYXRlZCwgYnV0IEkgdGhpbmsgdGhpcyBoYXMgbG9zdCB0b28gbXVjaC4gUGVyaGFwcyBt ZW50aW9uIG1lbW9yeSBzaGFyZWQgYmV0d2VlbiBpbnRlcmZhY2VzLCBzbyBlaXRoZXIgYmxvYXRl ZCBidWZmZXJzIG9yIHRvbyBsaXR0bGUsIG1ha2luZyB0cmFmZmljIHN1c2NlcHRpYmxlIHRvIHBh Y2tldCBsb3NzZXM/DQoNCiAgIFtSRkMzMTY4XSBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIHVz aW5nIEV4cGxpY2l0IENvbmdlc3Rpb24NCiAgIE5vdGlmaWNhdGlvbiAoRUNOKSBmcm9tIHRoZSBz d2l0Y2hlcyBmb3IgZWFybHkgZGV0ZWN0aW9uIG9mDQogICBjb25nZXN0aW9uLCByYXRoZXIgdGhh biB3YWl0aW5nIGZvciBwYWNrZXQgbG9zcyB0byBvY2N1ci4NCg0KVGhpcyBpc24ndCBjb3JyZWN0 LiAzMTY4IHJlcXVpcmVzIEVDTiBtYXJraW5nIHRvIG9jY3VyIG5vIGVhcmxpZXIgdGhhbiBkcm9w LiBJdCBpcyBwcmVjaXNlbHkgdGhhdCAzMTY4IGRvZXMgbm90IGFsbG93IGVhcmx5IG1hcmtpbmcg dW5sZXNzIHRoZXJlIGlzIGFsc28gZWFybHkgZHJvcCB0aGF0IGlzIHRoZSBwcm9ibGVtLg0KDQoN CjxQcmF2ZWVuPiBGaXhlZCBpbiBuZXh0IHJldmlzaW9uLg0KDQoNCiAgIEl0IGlzIHJlY29tbWVu ZGVkIHRoYXQgRENUQ1AgYmUgZGVwbG95ZWQuLi4NCg0KInJlY29tbWVuZGVkIiBpcyB0b28gd2Vh ay4gSSBzdWdnZXN0IHlvdSB1c2Ugc29tZXRoaW5nIGxpa2UgdGhlIGFwcGxpY2FiaWxpdHkgdGV4 dCBnaXZlbiBhYm92ZSwgYm90aCBoZXJlIGFuZCBpbiB0aGUgYWJzdHJhY3QuDQoNCjxQcmF2ZWVu PiBBZGRlZCB0aGUgd29yZCDigJxvbmx54oCdIHRvIG1ha2UgdGhpcyBzdHJvbmdlciBwZXIgTWlj aGFlbOKAmXMgcmV2aWV3LiBGaXhlZCBpbiBuZXh0IHJldmlzaW9uLg0KW0JCXSBJIHN1Z2dlc3Qg dGhlIGFwcGxpY2FiaWxpdHkgcGFyYSAoaGVyZSBpbiB0aGUgaW50cm8pIHJlZmVycyBmb3J3YXJk IHRvIHNlY3Rpb24gNSBmb3IgZGV0YWlscyAoZS5nLiBzbyB5b3UgZG9uJ3QgaGF2ZSB0byBleHBs YWluIHdoeSBpdCBzaG91bGRuJ3QgYmUgZGVwbG95ZWQgaW4gdGhlIGludHJvKS4NCg0KPj4gQWRk ZWQNCg0KDQoyLiBUZXJtaW5vbG9neQ0KDQpTdWdnZXN0IHlvdSBleHBsYWluIHRoYXQgY2FwaXRh bGlzZWQgd29yZHMgYXJlIG5vdCBxdWl0ZSB0aGUgc2FtZSBhcyBpbiBtb3N0IFJGQ3M6DQoiTm9y bWF0aXZlIGxhbmd1YWdlIGlzIHVzZWQgdG8gZGVzY3JpYmUgaG93IG5lY2Vzc2FyeSB0aGUgdmFy aW91cyBhc3BlY3RzIG9mIHRoZSBNaWNyb3NvZnQgaW1wbGVtZW50YXRpb24gYXJlIGZvciBpbnRl cm9wZXJhYmlsaXR5LCBidXQgZXZlbiBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIHdpdGhvdXQg dGhlIG1lYXN1cmVzIGluIHNlY3Rpb25zIDQtNiB3b3VsZCBzdGlsbCBvbmx5IGJlIHNhZmUgdG8g ZGVwbG95IGluIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzLiINCg0KDQo8UHJhdmVlbj4gRmFpciBl bm91Z2guIEFkZGVkIHRleHQgaW4gbmV4dCByZXZpc2lvbi4NCg0KDQozLiBEQ1RDUCBBbGdvDQoN ClRoZSB0aHJlZSBidWxsZXRzIHNheSBubyBtb3JlIHRoYW4gInRoaXMgaXMgbm9ybWFsIHN0dWZm Ii4gV291bGQgaXQgYmUgYmV0dGVyIHRvIHN1cHBsZW1lbnQgZWFjaCBzZW50ZW5jZSB3aXRoIGEg YnJpZWYgcGhyYXNlIHNheWluZyB3aGF0IGlzIGRpZmZlcmVudCBhYm91dCBlYWNoIGFzcGVjdCBj b21wYXJlZCB0byBSRkMzMTY4Pw0KDQoNCjxQcmF2ZWVuPiBUaGUgZ29hbCBoZXJlIGl0IHRvIGRl c2NyaWJlIHRoZSBjaGFuZ2VzIG5lZWRlZCBvbiB0b3Agb2YgMzE2OCBzbyBJIGRvbuKAmXQgdGhp bmsgZnVydGhlciBleHBsYW5hdGlvbiBpcyBuZWNlc3NhcnkuDQoNCg0KMy4xIE1hcmtpbmcNCg0K VGhpcyBuZWVkcyB0byBzYXkgc29tZXRoaW5nIGFib3V0IGhvdyB5b3UgbWFyayB0aGUgSVAgaGVh ZGVyIGZyb20gTDIuIEkgc3VnZ2VzdCB5b3UgcmVmZXIgdG8gdGhlIHVwLWFuZC1mb3J3YXJkIG1v ZGUgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tZW5jYXAuDQoNCg0KPFByYXZlZW4+IFdoeSBpcyB0 aGF0IHJlbGV2YW50IHRvIHRoaXMgZG9jdW1lbnQ/IEl0IGlzIG5vdCBpbnRlbmRlZCBhcyBhIHNw ZWNpZmljYXRpb24gZm9yIG9wZXJhdGlvbiBvZiBMMiBzd2l0Y2hlcy4gV29u4oCZdCBmaXguDQpb QkJdIFdlbGwsIHlvdSBzcGVjaWZ5IGEgbG90IGFib3V0IHRoZSBtYXJraW5nIGFsZ28sIGUuZy4N CksgPiAoUlRUICogIEMpLzcNCg0KQSBzaW1wbGUgc29sdXRpb24gd291bGQgYmU6IHMvc3dpdGNo L0wzIHN3aXRjaC8NCg0KSSBqdXN0IHRob3VnaHQgdGhhdCBhIHJlYWRlciB3b3VsZCB0aGluaywg IllvdSBzYXkgc3dpdGNoZXMgKGkuZS4gTDIgZGV2aWNlcykgbWFyayB0aGUgSVAgaGVhZGVyIC0g aG93IGNhbiB0aGF0IHdvcms/IiB1bmxlc3MgeW91IGV4cGxhaW4uDQoNCg0KPj4gRmFpciBlbm91 Z2gsIENoYW5nZWQgdG8gTDMgc3dpdGNoZXMgYW5kIHJvdXRlcnMuDQoNCg0KDQpzL3NlbmRpbmcg cmF0ZS8NCiAvbGluayByYXRlLw0KDQoNCg0KPFByYXZlZW4+IEZpeGVkIGluIG5leHQgcmV2aXNp b24NCg0KDQoNCjMuMg0KDQpDVVJSRU5UOg0KDQogICAxLiAgSWYgdGhlIENFIGNvZGVwb2ludCBp cyBzZXQgYW5kIERDVENQLkNFIGlzIGZhbHNlLCBzZW5kIGFuIEFDSyBmb3INCg0KICAgICAgIGFu eSBwcmV2aW91c2x5IHVuYWNrbm93bGVkZ2VkIHBhY2tldHMgYW5kIHNldCBEQ1RDUC5DRSB0byB0 cnVlLg0KDQoNCg0KICAgMi4gIElmIHRoZSBDRSBjb2RlcG9pbnQgaXMgbm90IHNldCBhbmQgRENU Q1AuQ0UgaXMgdHJ1ZSwgc2VuZCBhbiBBQ0sNCg0KICAgICAgIGZvciBhbnkgcHJldmlvdXNseSB1 bmFja25vd2xlZGdlZCBwYWNrZXRzIGFuZCBzZXQgRENUQ1AuQ0UgdG8NCg0KICAgICAgIGZhbHNl Lg0KU1VHR0VTVEVEOg0KDQogICAxLiAgSWYgdGhlIENFIGNvZGVwb2ludCBpcyBzZXQgYW5kIERD VENQLkNFIGlzIGZhbHNlLCBzZXQgRENUQ1AuQ0UgdG8NCg0KICAgICAgIHRydWUgYW5kIHNlbmQg YW4gQUNLIGZvciBhbnkgcHJldmlvdXNseSB1bmFja25vd2xlZGdlZCBwYWNrZXRzLg0KDQoNCg0K ICAgMi4gIElmIHRoZSBDRSBjb2RlcG9pbnQgaXMgbm90IHNldCBhbmQgRENUQ1AuQ0UgaXMgdHJ1 ZSwgc2V0IERDVENQLkNFDQoNCiAgICAgICB0byBmYWxzZSBhbmQgc2VuZCBhbiBBQ0sgZm9yIGFu eSBwcmV2aW91c2x5IHVuYWNrbm93bGVkZ2VkIHBhY2tldHMuDQogICAgVGhlIGZpZ3VyZSB3b3Vs ZCBoYXZlIHRvIGJlIGNoYW5nZWQgdG8gYmUgY29uc2lzdGVudCB0b28uDQpSQVRJT05BTEU6DQpJ ZiB0aGUgcmVjZWl2ZXIgY2hhbmdlcyBEQ1RDUC5DRSAvYWZ0ZXIvIHNlbmRpbmcgdGhlIEFDSyBs aWtlIHRoaXMsIGl0IGRlbGF5cyBlYWNoIHNpZ25hbCB1bnRpbCB0aGUgZm9sbG93aW5nIEFDSyBp cyBzZW50LiBUaGF0IGNvdWxkIGFkZCBhIGRlbGF5IG9mIGFueXRoaW5nIGZyb20gMSB0byBtIHBh Y2tldHMuIEkndmUgbmV2ZXIgdW5kZXJzdG9vZCB3aHkgdGhlIG9yZGVyIG9mIHRoZXNlIG9wZXJh dGlvbnMgd2FzIHNwZWNpZmllZCBpbiB0aGlzIHdheS4gSWYgdGhlcmUgaXMgbm8gcmVhc29uLCB0 aGVuIEkgc3VnZ2VzdCB0aGF0IGl0IGlzIHNwZWNpZmllZCBpbiB0aGUgb3Bwb3NpdGUgb3JkZXIs IGFzIEkgZGVzY3JpYmUgYWJvdmUuDQoNCkEgbm90ZSBjb3VsZCBiZSBhZGRlZCB0byBzYXkgdGhl IFdpbmRvd3MgU2VydmVyIDEyIGltcGxlbWVudGF0aW9uIGRvZXMgdGhlc2Ugc3RlcHMgaW4gcmV2 ZXJzZSBvcmRlciwgYnV0IHRoZSBvcmRlciBzcGVjaWZpZWQgaXMgcHJlZmVycmVkIGJlY2F1c2Ug aXQgcmVkdWNlcyBzaWduYWxsaW5nIGRlbGF5IGFuZCBoYXMgbm8gaW50ZXJvcGVyYWJpbGl0eSBp c3N1ZXMgd2l0aCB0aGUgb3JpZ2luYWwgV2luZG93cyBpbXBsZW1lbnRhdGlvbi4NCjxQcmF2ZWVu PiBXb27igJl0IGZpeC4gVGhpcyBpcyBob3cgdGhlIFdpbmRvd3MgaW1wbGVtZW50YXRpb24gYmVo YXZlcyBzbyB0aGUgb3JkZXJpbmcgaXMgcmVxdWlyZWQuIEJvdGggdGhlIHBhcGVyIGFuZCB0aGUg ZHJhZnQgYXJlIGNvbnNpc3RlbnQgaW4gdGhpcy4NCltCQl0gVGhlIHBhcGVyIGFuZCB0aGUgZHJh ZnQgYXJlIG5vdCBjb25zaXN0ZW50LiBJbiB0aGUgZHJhZnQsIHRoZSBsYWJlbHMgb24gdGhlIHRv cCBhbmQgYm90dG9tIGFycm93cyBpbiB0aGUgZGlhZ3JhbSBoYXZlIGJlZW4gc3dpdGNoZWQgcm91 bmQgcmVsYXRpdmUgdG8gdGhvc2UgaW4gdGhlIHBhcGVyLg0KDQpIb3dldmVyLCB0aGUgdGV4dCBp biB0aGUgZHJhZnQgaGFzIG5vdCAoeWV0PykgYmVlbiBjaGFuZ2VkIHRvIHJlZmxlY3QgdGhpcy4N Cg0KVGhlcmUgaXMgbm8gZGVsYXkgYmVpbmcgaW50cm9kdWNlZCBoZXJlLiBUaGlzIEFDSyBpcyBz ZW50IGltbWVkaWF0ZWx5IHNvIHRoZSBvcmRlciBkb2VzIG5vdCBtYXR0ZXIuDQoNCltCQl0gSSBh Z3JlZSB0aGF0IHRoZSBBQ0sgaXRzZWxmIGlzIG5vdCBkZWxheWVkLiBIb3dldmVyLCBldmVuIHRo byBhIENFIGhhcyBiZWVuIHJlY2VpdmVkLCBmZWVkYmFjayBvZiB0aGlzIGV2ZW50IGlzIGhlbGQg YmFjayB1bnRpbCB0aGUgbmV4dCBBQ0suDQoNClRoaXMgaXMgYSBtaW5vciAndW5uZWNlc3Nhcnkg ZGVsYXknIGJ1Zy4NCiogSSBiZWxpZXZlIGl0IHdhcyBmaXhlZCBpbiB0aGUgRnJlZUJTRCBpbXBs ZW1lbnRhdGlvbiBhZnRlciBJIHBvaW50ZWQgaXQgb3V0Lg0KKiBJJ3ZlIGp1c3QgY2hlY2tlZCB0 aGUgTGludXggY29kZSwgYW5kIGl0J3Mgbm90IGJlZW4gZml4ZWQgdGhlcmUuDQoqIE9idmlvdXNs eSBJIGNhbm5vdCBzZWUgdGhlIFdpbmRvd3Mgc291cmNlIGNvZGUuDQoNCklmIHRoaXMgYnVnIGlz IHN0aWxsIGluIHRoZSBXaW5kb3dzIGltcGxlbWVudGF0aW9uLCBpdCdzIHVwIHRvIHlvdSBpZiB5 b3UgYWxzbyB3YW50IHRoZSBzcGVjIHRvIHJlcXVpcmUgdGhhdCB0aGUgYnVncyBhcmUgaW1wbGVt ZW50ZWQgZXhhY3RseSBhcyB0aGV5IGFyZSBpbiBXaW5kb3dzIDspDQoNCg0KPj4gVGhlcmUgYXJl IHR3byBzZXBhcmF0ZSBpc3N1ZXMgaGVyZS4gT25lIGlzIHRoYXQgdGhlIHBhY2tldCB0aGF0IHRy aWdnZXJzIHRoZSBDRSBzdGF0ZSB0byBjaGFuZ2UgbXVzdCBpdHNlbGYgbm90IGJlIGFjY291bnRl ZCBmb3IgaW4gdGhlIGltbWVkaWF0ZSBBQ0suIEkgdGhpbmsgdGhlIHRleHQgbWFrZXMgdGhpcyBj bGVhciB3aXRoIHRoZSB1c2Ugb2YgdGhlIHdvcmQg4oCccHJldmlvdXNseSB1bmFja25vd2xlZGdl ZCBwYWNrZXRz4oCdLiBJIGFtIGFkZGluZyBhIHNlbnRlbmNlIHRvIGVuc3VyZSB0aGF0IHRoaXMg aXMgaW50ZXJwcmV0ZWQgY29ycmVjdGx5IG90aGVyd2lzZSB0aGVyZSBjYW4gYmUgYSBjaGFuZ2Ug aW4gaG93IGFscGhhIGlzIGNvbXB1dGVkIGlmIHRoZSBwYWNrZXQgd2FzIGEgZGF0YSBwYWNrZXQu IFRoZSBvdGhlciBpc3N1ZSBpcyB0aGF0IHRoZSB0cmFuc2l0aW9uIHBhY2tldCBpdHNlbGYgd2ls bCBub3QgYmUgQUNLZWQgaW1tZWRpYXRlbHkgYW5kIEkgZG9u4oCZdCBzZWUgdGhhdCBhcyBhbiBp c3N1ZS4gV2l0aCBkYXRhIGNlbnRlciBsYXRlbmNpZXMgYW5kIHRoZSBndWlkYW5jZSBhcm91bmQg dXNpbmcgYSBzaG9ydCBkZWxheWVkIEFDSyB0aW1lb3V0IHRoZSB1bm5lY2Vzc2FyeSBkZWxheSBp cyBub3QgYSBiaWcgaXNzdWUuIEFsc28sIHRoZSBkZWxheSBpcyBvbmx5IHByZXNlbnQgaWYgdGhl cmUgYXJlIG5vIHN1YnNlcXVlbnQgcGFja2V0cyBvZiB0aGUgZmxvdyBpbiBmbGlnaHQgd2hpY2gg c2hvdWxkIGJlIHJhcmUuDQoNCg0KDQoNCg0KDQogICBUaGUgaGFuZGxpbmcgb2YgdGhlICJDb25n ZXN0aW9uIFdpbmRvdyBSZWR1Y2VkIiAoQ1dSKSBiaXQgaXMgYWxzbw0KDQogICBleGFjdGx5IGFz IHBlciBbUkZDMzE2ODxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZnJmYzMxNjgmZGF0 YT0wMSU3YzAxJTdjcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdjYTU3MmIwYmE4ZTFiNDdkM2U0NGEw OGQyZTZkN2UwM2YlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9 Q2U5bTVxMFh6a2JRTldFYjFycW1YcnF4MTJVZjRMRHNjclVBejVDNzhlWSUzZD5dIGluY2x1ZGlu ZyBbUkZDMzE2OC1FUlJBVEEzNjM5PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmZHJh ZnQtaWV0Zi10Y3BtLWRjdGNwLTAxJTIzcmVmLVJGQzMxNjgtRVJSQVRBMzYzOSZkYXRhPTAxJTdj MDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4ZDJlNmQ3 ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT13REp2JTJi Y3lwWGo1bGF5Znp2UUdoWFlxQjZrd2w4bFclMmZwZFE0aVlnMmNOOCUzZD5dLiAgVGhhdCBpcywg b24NCg0KICAgcmVjZWlwdCBvZiBhIHNlZ21lbnQgd2l0aCBib3RoIHRoZSBDRSBhbmQgQ1dSIGJp dHMgc2V0LCBDV1IgaXMNCg0KICAgcHJvY2Vzc2VkIGZpcnN0IGFuZCB0aGVuIEVDRSBpcyBwcm9j ZXNzZWQuDQpFdmVuIHRobyB0aGlzIGlzIHRoZSByZWNlaXZlciBzZWN0aW9uLCBJIHN1Z2dlc3Q6 DQpzL1RoZSBoYW5kbGluZy9SZWNlaXZlciBoYW5kbGluZy8NCg0KDQo8UHJhdmVlbj4gSXNu4oCZ dCB0aGlzIGFzc3VtZWQgYnkgYSByZWFkZXIgZmFtaWxpYXIgd2l0aCAzMTY4PyBCdXQgdGhpcyBp cyBhIG1pbm9yIGVkaXRvcmlhbCBmaXggc28gZml4ZWQgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoN CldoYXRldmVyLCB0aGlzIGNhbm5vdCBiZSBjb3JyZWN0LiBBIERDVENQIHJlY2VpdmVyIHN1cmVs eSBkb2VzIG5vdGhpbmcgb24gcmVjZWlwdCBvZiBDV1IsIHdoZXJlYXMgYW4gUkZDMzE2OCByZWNl aXZlciBkb2VzIHNvbWV0aGluZy4gQSBEQ1RDUCByZWNlaXZlciBjZXJ0YWlubHkgY2Fubm90IGRv IGV4YWN0bHkgd2hhdCBSRkMzMTY4IHNheXMsIGJlY2F1c2UgdGhhdCBzYXlzIHN0b3Agc2V0dGlu ZyBFQ0Ugb24gcmVjZWlwdCBvZiBDV1IgdW50aWwgdGhlIG5leHQgQ0UgYXJyaXZlcywgd2hpY2gg d291bGQgc3VyZWx5IGJyZWFrIHRoaXMgZmVlZGJhY2sgcHJvdG9jb2wuDQoNCg0KPFByYXZlZW4+ IEkgZG9u4oCZdCBzZWUgd2h5IHRoaXMgd291bGQgYnJlYWsgdGhlIGZlZWRiYWNrIHByb3RvY29s LiBUaGUgcmVjZWl2ZXIgd2lsbCBzdGFydCBlY2hvaW5nIGFnYWluIGFzIHNvb24gYXMgaXQgc2Vl cyB0aGUgZmlyc3QgQ0UgYXJyaXZlcyBhZ2Fpbi4gSWYgcGFja2V0IGhhcyBib3RoIENXUiBhbmQg Q0Ugc2V0IHRoZW4gQ0UgdGFrZXMgcHJlY2VkZW5jZSBhbmQgdGhlIGVjaG9pbmcgaXMgZG9uZS4N CltCQl0gSSdtIG5vdCBzYXlpbmcgaXQgYnJlYWtzIHRoZSBmZWVkYmFjayBwcm90b2NvbC4gSSdt IGp1c3Qgc2F5aW5nIGl0J3MgY29uZnVzaW5nIGZvciB0aGUgcmVhZGVyLg0KDQpPZiBjb3Vyc2Us IHdoZW4gdGhlIHJlY2VpdmVyIGlzIGFscmVhZHkgbm90IGRvaW5nIHNvbWV0aGluZywgaWdub3Jp bmcgYSBzaWduYWwgdG8gc3RvcCBoYXMgdGhlIHNhbWUgb3V0Y29tZSBhcyBzdG9wcGluZy4gSG93 ZXZlciwgZGVzY3JpYmluZyB0aGlzIGFzICJoYW5kbGluZyBDV1IgLi4uIGlzIGFsc28gZXhhY3Rs eSBhcyBwZXIgUkZDMzE2OCIgaXMgbWlzbGVhZGluZyBmb3IgdGhlIHJlYWRlci9pbXBsZW1lbnRl ci4NCg0KSSBndWVzcyBjaGFuZ2luZyB0byAiaGFuZGxpbmcgQ1dSIC4uLiBpcyBhcyBwZXIgUkZD MzE2OCIgd291bGQgYmUgYSBjb21wcm9taXNlLg0KDQoNCj4+IEZpeGVkIHRoaXMgdG8gcmVtb3Zl IOKAnGV4YWN0bHnigJ0uDQoNCjMuMw0KDQogICBEQ1RDUC5BbHBoYSwgd2hpY2ggaXMgaW5pdGlh bGl6ZWQgdG8gMSBhbmQgTVVTVCBiZSB1cGRhdGVkDQoNCiAgIGFzIGZvbGxvd3M6DQpzL01VU1Qv U0hPVUxELw0KQW5kIGFkZCAiQW4gYWx0ZXJuYXRpdmUgY29uZ2VzdGlvbiBhdm9pZGFuY2UgYWxn b3JpdGhtIE1BWSBiZSB1c2VkLCBidXQgaXQgTVVTVCBsZWFkIHRvIGZsb3cgcmF0ZSBpbnZlcnNl bHkgcHJvcG9ydGlvbmFsIHRvIDEvTSIuDQoNClJhdGlvbmFsZTogVGhlcmUgYXJlIG1hbnkgd2F5 cyB0byBpbXBsZW1lbnQgaW50ZXJvcGVyYWJsZSAxL3AgY2MuIFRoaXMgaXMganVzdCBvbmUuDQoN CjxQcmF2ZWVuPiBBbHRlcm5hdGUgYWxnb3JpdGhtcyBhcmUgb3V0IG9mIHNjb3BlIG9mIHRoaXMg ZHJhZnQuIFdlIGNhbm5vdCBzYXkgd2l0aG91dCBpbnRlcm9wIHRlc3RpbmcgaWYgYSBkaWZmZXJl bnQgYWxnb3JpdGhtIHdpbGwgcGVyZm9ybSB3ZWxsIGluIGRhdGFjZW50ZXJzIG9yIGludGVyb3Ag d2VsbCB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gSWYgdGhlcmUgYXJlIG90aGVyIHdh eXMgdG8gaW1wbGVtZW50IDEvcCB0aGV5IHNob3VsZCBiZSBjb3ZlcmVkIGJ5IG90aGVyIGRyYWZ0 cy4gVGhpcyBkcmFmdCB3aWxsIG9ubHkgZGVzY3JpYmUgdGhlIGFsZ29yaXRobSB0aGF0IGhhcyBi ZWVuIHRlc3RlZCBhbmQgZGVwbG95ZWQuIFRoYXQgc2FpZCBJIGFtIHdpbGxpbmcgdG8gbWFrZSBp dCBhIFNIT1VMRCBzbyBmaXhlZCBpbiB0aGUgbmV4dCByZXZpc2lvbi4NCg0KDQoNCiAgIERDVENQ LkJ5dGVzU2VudA0KVGhpcyB2YXJpYWJsZSBhY3R1YWxseSBjb3VudHMgYnl0ZXMgcmVjZWl2ZWQu IGl0J3MgcHJldHR5IGNvbmZ1c2luZyB0byBjYWxsIGl0IEJ5dGVzU2VudC4NCg0KDQo8UHJhdmVl bj4gTm8sIHRoaXMgaXMgdHJhY2tpbmcgYnl0ZXMgdGhhdCBoYXZlIGJlZW4gc2VudC4NCltCQl0g SSBtZWFudCBpdCBjb3VudHMgYnl0ZXMgbm93IGFja25vd2xlZGdlZCBhcyByZWNlaXZlZCBieSB0 aGUgb3RoZXIgZW5kICh3aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgYnl0ZXMgc2VudCBieSB0aGlz IGVuZCkuDQpEQ1RDUC5CeXRlc0Fja2VkIHdvdWxkIGhhdmUgYmVlbiBtb3JlIG1lYW5pbmdmdWwu IEknbSBub3QgaW5zaXN0aW5nIG9uIHRoaXMgLSB0aGUgb3JpZ2luYWwgY29tbWVudCB3YXMganVz dCB0byBpbXByb3ZlIGNvbXByZWhlbnNpYmlsaXR5Lg0KDQoNCj4+ICBGYWlyIGVub3VnaCBub3cg SSBzZWUgd2hhdCB5b3UgbWVhbnQuIFVwZGF0aW5nIHRvIEJ5dGVzQWNrZWQNCg0KDQpzL1RDUCBT QUNLIG9wdGlvbnMgW1JGQzIwMThdIGFyZSBpZ25vcmVkLi8NCiAvVGhlIHNlbmRlciBNVVNUIGln bm9yZSBUQ1AgU0FDSyBvcHRpb25zIFtSRkMyMDE4XSBmb3IgdGhpcyBjb21wdXRhdGlvbi4vDQpS QVRJT05BTEU6DQogIGEpIEkgdGhpbmsgdGhlIGlkZWEgaXMgdG8gaWdub3JlIENFIG1hcmtzIGFm dGVyIGEgZ2FwIGJlY2F1c2UsIGlmIHRoZSBnYXAgYmVjb21lcyBjb25zaWRlcmVkIGEgbG9zcywg dGhlIHJlc3BvbnNlIHRvIGxvc3Mgd2lsbCBvdmVycmlkZSBhbnkgbmVlZCB0byBjb3VudCBpbmNv bWluZyBDRSBtYXJrcyBmb3IgdGhlIGZvbGxvd2luZyByb3VuZCB0cmlwLiBIb3dldmVyLCBpZiB0 aGUgZ2FwIGlzIGZpbGxlZCBiZWZvcmUgaXQgaXMgY29uc2lkZXJlZCBhIGxvc3Mge05vdGUgMX0s IHRoZW4gQ0UgbWFya3MgdGhhdCB3ZXJlIGlnbm9yZWQgYmVjYXVzZSB0aGV5IGFycml2ZWQgYWZ0 ZXIgYSBnYXAgd2lsbCBuZWVkIHRvIGJlICJ1bmlnbm9yZWQiLg0KICBiKSBXZSBuZWVkIHRvIG1h a2UgY2xlYXIgdGhhdCBTQUNLIGlzIG5vdCBpZ25vcmVkIGFsdG9nZXRoZXIsIG9ubHkgZm9yIHRo aXMgY29tcHV0YXRpb24uDQoNCntOb3RlIDF9OiBJIGNhbiB0aGluayBvZiB0d28gY2FzZXM6DQoq IExlc3MgdGhhbiB0aHJlZSBkdXBhY2tzIHRoZW4gdGhlIGdhcCBpcyBmaWxsZWQNCiogVGhlIGdh cCBpcyBmaWxsZWQgYnkgYSBkZWxheWVkIHNlZ21lbnQgc28gdGhhdCBhbiBlYXJsaWVyIHJldHJh bnNtaXNzaW9uIHdhcyBzcHVyaW91cw0KPFByYXZlZW4+IE9rIEkgd2lsbCB1cGRhdGUgdGhlIHRl eHQuDQoNCg0KDQp0aGUgc2VuZGVyIE1VU1QgdXBkYXRlIGN3bmQgYXMgZm9sbG93czoNCg0KICAg ICAgY3duZCA9IGN3bmQgKiAoMSAtIERDVENQLkFscGhhIC8gMikNCnMvTVVTVC9TSE9VTEQvDQpS YXRpb25hbGU6IEFsdGVybmF0aXZlIGludGVyb3BlcmFibGUgcmVzcG9uc2UgZnVuY3Rpb25zIGFy ZSBwb3NzaWJsZS4gRm9yIGluc3RhbmNlIGFuIGFsZ29yaXRobSBsaWtlIFJlbGVudGxlc3MgVENQ IHRoYXQgc2ltcGx5IHJlZHVjZXMgY3duZCBieSBoYWxmIHRoZSBzaXplIG9mIGFueSBDRS1tYXJr ZWQgc2VnbWVudC4gVGhlbiB0aGVyZSBpcyBubyBBbHBoYSBhbmQgbm8gZyB2YXJpYWJsZS4NCg0K DQoNCjxQcmF2ZWVuPiBGaXhlZA0KDQoNCg0KQ1VSUkVOVDoNCg0KICAgSnVzdCBhcyBzcGVjaWZp ZWQgaW4gW1JGQzMxNjg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZyZmMzMTY4JmRh dGE9MDElN2MwMSU3Y3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Y2E1NzJiMGJhOGUxYjQ3ZDNlNDRh MDhkMmU2ZDdlMDNmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRh PUNlOW01cTBYemtiUU5XRWIxcnFtWHJxeDEyVWY0TERzY3JVQXo1Qzc4ZVklM2Q+XSwgVENQIHNo b3VsZCBub3QgcmVhY3QgdG8gY29uZ2VzdGlvbg0KDQogICBpbmRpY2F0aW9ucyBtb3JlIHRoYW4g b25jZSBmb3IgZXZlcnkgd2luZG93IG9mIGRhdGEuDQpTVUdHRVNURUQ6DQoNCiAgIEp1c3QgYXMg c3BlY2lmaWVkIGluIFtSRkMzMTY4PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmcmZj MzE2OCZkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0 N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT1DZTltNXEwWHprYlFOV0ViMXJxbVhycXgxMlVmNExEc2NyVUF6NUM3OGVZJTNkPl0s IERDVENQIGRvZXMgbm90IHJlYWN0IHRvIGNvbmdlc3Rpb24NCg0KICAgaW5kaWNhdGlvbnMgbW9y ZSB0aGFuIG9uY2UgZm9yIGV2ZXJ5IHdpbmRvdyBvZiBkYXRhLg0KSSBkb24ndCBrbm93IHdoZXRo ZXIgeW91IGludGVuZGVkIHRoaXMgdG8gYmUgYW4gdXBwZXItY2FzZSBTSE9VTEQgTk9ULiBJZiBz bywgSSB3b3VsZCBhcmd1ZSBhZ2FpbnN0IHRoaXMgYmVpbmcgbm9ybWF0aXZlLCBiZWNhdXNlIGl0 IGlzbid0IG5lY2Vzc2FyeSBmb3IgaW50ZXJvcDsgdGhlcmVmb3JlIEkndmUgc3VnZ2VzdGVkIGF2 b2lkaW5nIGhlICdzaG91bGQnIHdvcmQuDQoNCg0KPFByYXZlZW4+IEZpeGVkDQoNCg0KDQoNCiAg IFRoZSBzZXR0aW5nIG9mDQoNCiAgIHRoZSAiQ29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCIgKENX UikgYml0IGlzIGFsc28gZXhhY3RseSBhcyBwZXINCg0KICAgW1JGQzMxNjg8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29s cy5pZXRmLm9yZyUyZmh0bWwlMmZyZmMzMTY4JmRhdGE9MDElN2MwMSU3Y3ByYXZiJTQwbWljcm9z b2Z0LmNvbSU3Y2E1NzJiMGJhOGUxYjQ3ZDNlNDRhMDhkMmU2ZDdlMDNmJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUNlOW01cTBYemtiUU5XRWIxcnFtWHJxeDEy VWY0TERzY3JVQXo1Qzc4ZVklM2Q+XS4NCg0KDQoNCg0KSXQgaXMgd3JvbmcgdG8gc2F5ICJleGFj dGx5Ii4gVGhlIHNlbmRlciBjZXJ0YWlubHkgc2V0cyBDV1Igd2hlbiBpdCBkb2VzIGEgY29uZ2Vz dGlvbiByZXNwb25zZS4gQnV0IGluIERDVENQIHRoZSBjb25nZXN0aW9uIHJlc3BvbnNlIG9jY3Vy cyBldmVyeSBSVFQsIHRyaWdnZXJlZCBieSBpdHMgb3duIG1lYXN1cmVtZW50LXBlcmlvZCBsb2dp Yywgd2hlcmVhcyBpbiBSRkMzMTY4IGl0IGlzIHRyaWdnZXJlZCBieSB0aGUgYXJyaXZhbCBvZiBh biBFQ0UgYWZ0ZXIgdGhlIEFDSyBvZiBhbnkgcHJldmlvdXMgc2VnbWVudCBpdCBzZW50IHdpdGgg Q1dSIHNldC4NCg0KSSB0aGluayBpdCBpcyB3b3J0aCBzYXlpbmcgdGhhdCBzZXR0aW5nIENXUiBp cyBuZWNlc3NhcnkgZm9yIHNhZmV0eSwgb3RoZXJ3aXNlIGluIHRoZSBjYXNlIHdoZXJlIHRoZXJl IGhhcyBiZWVuIGEgY29uZmlndXJhdGlvbiBtYW5hZ2VtZW50IGVycm9yIGFuZCB0aGUgcmVjZWl2 ZXIgY29tcGxpZXMgd2l0aCBSRkMgMzE2OCBub3QgRENUQ1AsIGl0IHdpbGwgY29udGludWUgc2Vu ZGluZyBFQ0UgZm9yIGV2ZXIgYW5kIHN0YXJ2ZSB0aGUgc2Vzc2lvbi4NCg0KSXQgbWlnaHQgaGVs cCB0byBleHBsaWNpdGx5IGNvbmZpcm0gdGhhdDoNCiJPdGhlciBhc3BlY3RzIG9mIFRDUCBjb25n ZXN0aW9uIGF2b2lkYW5jZSBhbmQgY29udHJvbCBzdWNoIGFzIHRoZSBzbG93IHN0YXJ0IHBoYXNl IGFyZSBubyBkaWZmZXJlbnQgdG8gdGhvc2UgaW4gUkZDNTY4MS4iDQoNCg0KDQo8UHJhdmVlbj4g Rml4ZWQgdGhhdCBDV1IgaXMgbmVlZGVkIGZvciBzYWZldHkuIE5vdCBhZGRpbmcgdGhlIHRleHQg YXJvdW5kIDU2ODEsIGl0IGlzIHByZXN1bWVkLg0KDQoNCjMuNCBTWU4sIFNZTi1BQ0ssIFJTVA0K DQogICBbUkZDMzE2OF0gcmVxdWlyZXMgdGhhdCBhIGNvbXBsaWFudCBUQ1AgTVVTVCBOT1Qgc2V0 IEVDVCBvbiBTWU4gb3INCiAgIFNZTi1BQ0sgcGFja2V0cy4NCg0Kcy9NVVNUIE5PVC8nTVVTVCBO T1QnLw0KUmF0aW9uYWxlOiBCZXN0IHRvIG1ha2UgaXQgY2xlYXIgdGhpcyBpcyBxdW90aW5nIGEg bm9ybWF0aXZlIHN0YXRlbWVudCBpbiBhbm90aGVyIFJGQywgYmVjYXVzZSBpdCBpcyBnb2luZyB0 byBiZSBjb250cmFkaWN0ZWQuDQpbQkJdIEkgZG9uJ3Qga25vdyB3aGV0aGVyIHlvdSBzYXcgdGhp cyBvbmUgLSBpdCdzIG5vdCBiZWVuIGNoYW5nZWQgaW4gZHJhZnQtMDIuDQoNCkkgc3VnZ2VzdGVk IGFkZGluZyBxdW90ZXMgYXJvdW5kICdNVVNUIE5PVCcuIFRoaXMgaXMgZ29vZCBwcmFjdGljZSB3 aGVuIHF1b3RpbmcgYW5vdGhlciBSRkMuIE90aGVyd2lzZSwgdG8gYSBjYXJlbGVzcyByZWFkZXIg KG9yIG5vbi1uYXRpdmUgRW5nbGlzaCBzcGVha2VyKSwgaXQgY2FuIGxvb2sgbGlrZSBpdCBpcyBh bHNvIGEgcmVxdWlyZW1lbnQgb2YgdGhpcyBSRkMuDQoNCg0KPj4gQ2hhbmdlZCB0byBsb3dlciBj YXNlIHNvIGFzIHRvIG5vdCBiZSBtaXNsZWFkaW5nIGFyb3VuZCBiZWluZyBhbiBhc2sgb2YgdGhp cyBSRkMuDQoNCkNVUlJFTlQNCg0KICAgVGhlc2UgUkZDcywgaG93ZXZlciwgYXJlDQoNCiAgIGlu dGVuZGVkIGZvciBnZW5lcmFsIEludGVybmV0IHVzZSwgYW5kIGRvIG5vdCBkaXJlY3RseSBhcHBs eSB0byBhDQoNCiAgIGNvbnRyb2xsZWQgZGF0YWNlbnRlciBlbnZpcm9ubWVudC4NCg0KLi4uDQoN CiAgIEZvciBEQ1RDUCBjb25uZWN0aW9ucywgdGhlIHNlbmRlcg0KDQogICBTSE9VTEQgc2V0IEVD VCBmb3IgU1lOLCBTWU4tQUNLIGFuZCBSU1QgcGFja2V0cy4NClNVR0dFU1RFRDoNCg0KICAgQWxz bywgYSBTWU4gaXMgc2VudCBiZWZvcmUgdGhlIEVDTi1jYXBhYmlsaXR5IGhhcyBiZWVuDQogICBu ZWdvdGlhdGVkLCBzbyBpZiBpdCBpcyBDRS1tYXJrZWQsIGEgbm9uLUVDTiBUQ1Agc2VydmVyIHdv dWxkIG5vdA0KICAgcmVjb2duaXNlIHRoZSBtYXJraW5nLiBSRkMgMzE2OCBkb2VzIG5vdCBzcGVj aWZ5IHRoZSBFQ04gZmllbGQgb24NCiAgIGEgUlNULiBUaGUgc2VjdXJpdHkgY29uY2VybnMgYWRk cmVzc2VkIGJ5IHRoZXNlIFJGQ3MNCiAgIG1pZ2h0IG5vdCBhcHBseSBpbiBjb250cm9sbGVkIGVu dmlyb25tZW50cyBsaWtlIGRhdGEgY2VudHJlcywgYW5kDQogICBpdCBtaWdodCBub3QgYmUgbmVj ZXNzYXJ5IHRvIGNhdGVyIGZvciB0aGUgcHJlc2VuY2Ugb2Ygbm9uLUVDTg0KICAgc2VydmVycy4N Ci4uLg0KDQogICBUaGVyZWZvcmUsIHRoZSBzZW5kZXIgTVVTVCBzZXQgRUNUIGZvciBTWU4vQUNL IGFuZCBSU1QgcGFja2V0cyBhbmQgYQ0KDQogICBjb25maWd1cmF0aW9uIG9wdGlvbiBTSE9VTEQg YmUgcHJvdmlkZWQgdG8gc2V0IEVDVCBmb3IgU1lOcy4NClJBVElPTkFMRToNCiAgIFRoZSBkcmFm dCBzaG91bGQgYXZvaWQgYXNzdW1pbmcgdGhhdCBzZWN1cml0eSBjb25jZXJucyBkbyBub3QgYXBw bHkgaW4gYWxsIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzLg0KTk9URToNCiAgIFRoaXMgbWlnaHQg bm90IHJlZmxlY3QgdGhlIHdheSB5b3VyIGltcGxlbWVudGF0aW9uIGlzIGNvZGVkLCBzbyB5b3Ug bWlnaHQgd2FudCB0byBtYWtlIHRoYXQgY2xlYXIuDQoNCg0KPFByYXZlZW4+IEFkZGluZyBzb21l IHRleHQgYXJvdW5kIHNlY3VyaXR5IGNvbmNlcm5zLg0KW0JCXSBUaGUgc2VjdXJpdHkgc2VudGVu Y2UgeW91IGhhdmUgYWRkZWQgaW4gZHJhZnQtMDIgZG9lc24ndCBtYWtlIHNlbnNlIHdoZXJlIGl0 IGlzLiBJdCBvdWdodCB0byBoYXZlIGJlZW4gYWRkZWQgb25jZSBzZW50ZW5jZSBlYXJsaWVyIChh bmQgaXQgd291bGQgYmUgYmV0dGVyIHRvIHN0YXJ0IGEgbmV3IHBhcmEpLiBTcGVjaWZpY2FsbHk6 DQpDVVJSRU5UOg0KICAgICAgICAgICAgICAgIGJlIGRyb3BwZWQgd2l0aCBoaWdoIHByb2JhYmls aXR5LiAgRm9yIERDVENQIGNvbm5lY3Rpb25zLCB0aGUgc2VuZGVyDQogICAgICAgICAgICAgICAg U0hPVUxEIHNldCBFQ1QgZm9yIFNZTiwgU1lOLUFDSyBhbmQgUlNUIHBhY2tldHMuICBUaGUgc2Vj dXJpdHkNCiAgICAgICAgICAgICAgICBjb25jZXJucyBhZGRyZXNzZWQgYnkgYm90aCB0aGVzZSBS RkNzIG1pZ2h0IG5vdCBhcHBseSBpbiBjb250cm9sbGVkDQogICAgICAgICAgICAgICAgZW52aXJv bm1lbnRzIGxpa2UgZGF0YWNlbnRlcnMsIGFuZCBpdCBtaWdodCBub3QgYmUgbmVjZXNzYXJ5IHRv IGNhdGVyDQogICAgICAgICAgICAgICAgdG8gYm90aCB0aGUgcHJlc2VuY2Ugb2Ygbm9uLUVDTiBz ZXJ2ZXJzLg0KU1VHR0VTVEVEOg0KICAgICAgICAgICAgICAgIGJlIGRyb3BwZWQgd2l0aCBoaWdo IHByb2JhYmlsaXR5Lg0KPE5FVyBQQVJBPg0KICAgICAgICAgICAgICAgIFRoZSBzZWN1cml0eSBj b25jZXJucyBhZGRyZXNzZWQgYnkgYm90aCB0aGVzZSBSRkNzIG1pZ2h0IG5vdCBhcHBseSBpbiBj b250cm9sbGVkDQogICAgICAgICAgICAgICAgZW52aXJvbm1lbnRzIGxpa2UgZGF0YWNlbnRlcnMs IGFuZCBpdCBtaWdodCBub3QgYmUgbmVjZXNzYXJ5IHRvIGNhdGVyDQogICAgICAgICAgICAgICAg Zm9yIHRoZSBwcmVzZW5jZSBvZiBub24tRUNOIHNlcnZlcnMuIEZvciBEQ1RDUCBjb25uZWN0aW9u cywgdGhlIHNlbmRlcg0KICAgICAgICAgICAgICAgIFNIT1VMRCBzZXQgRUNUIGZvciBTWU4sIFNZ Ti1BQ0sgYW5kIFJTVCBwYWNrZXRzLg0KDQooTm90ZSBJIGFsc28gZml4ZWQgYSBnbGl0Y2ggYWZ0 ZXIgImNhdGVyIi4pDQoNCg0KPj4gRml4ZWQgdHlwb3MgYnV0IHJlbW92ZWQgc2VjdXJpdHkgaW1w bGljYXRpb25zIGZyb20gdGhpcyBzZWN0aW9uIGFuZCBtb3ZlZCB0aGVtIGludG8gc2VjdGlvbiA4 IChzZWN1cml0eSkuDQoNCg0KDQo0LiBJbXBsZW1lbnRhdGlvbiBJc3N1ZXMNCg0KQ1VSUkVOVDoN Cg0KICAgdGhlIGltcGxlbWVudGF0aW9uIE1VU1QgY2hvb3NlIGEgc3VpdGFibGUNCg0KICAgZXN0 aW1hdGlvbiBnYWluLiAgW0RDVENQMTA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZk cmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtRENUQ1AxMCZkYXRhPTAxJTdjMDElN2NwcmF2 YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3Yzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0zM2RSVVV4eU5hMnRjWDB4 SnRNbDEybld3eklkSFphNmoza2dBTDFkeElNJTNkPl0gcHJvdmlkZXMgYSB0aGVvcmV0aWNhbCBi YXNpcw0KU1VHR0VTVDoNCg0KICAgdGhlIGltcGxlbWVudGF0aW9uIHdpbGwgbmVlZCB0byBjaG9v c2UgYSBzdWl0YWJsZQ0KDQogICBlc3RpbWF0aW9uIGdhaW4uICBbQURDVENQMTA8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0 b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtRENU Q1AxMCZkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0 N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZzZGF0YT0zM2RSVVV4eU5hMnRjWDB4SnRNbDEybld3eklkSFphNmoza2dBTDFkeElNJTNkPl0g cHJvdmlkZXMgYSB0aGVvcmV0aWNhbCBiYXNpcyAuLi4NClJBVElPTkFMRToNCiAgIGEpIEFzIGFi b3ZlLCB0aGlzIGlzIG9ubHkgb25lIHdheSB0byBpbXBsZW1lbnQgdGhlIGNjLCBhbmQgb3RoZXJz IGNvdWxkIHdlbGwgcHJvdmUgdG8gYmUgaW50ZXJvcGVyYWJsZSB3aGVuIHRlc3RlZC4NCiAgIGIp IE1vcmUgcGFydGljdWxhcmx5LCBpdCB3b3VsZCBiZSBiZXR0ZXIgZm9yIGFuIGltcGxlbWVudGF0 aW9uIHRvIGFkYXB0IHRoZSBlc3RpbWF0aW9uIGdhaW4gdG8gdGhlIFJUVCwgc28gdGhlIHNwZWMg b3VnaHQgbm90IHRvIGltcGx5IHRoYXQgb25lIHZhbHVlIGhhcyB0byBiZSBjaG9zZW4uDQogICBj KSBUaGUgbGF0ZXIgcGFwZXIgW0FEQ1RDUDEwXSBwcm92aWRlcyBhIGNvcnJlY3RlZCB3YXkgdG8g ZGV0ZXJtaW5lIHRoZSBnYWluLiBGcm9tIG1lbW9yeSAoSSdtIG9mZmxpbmUgYXQgdGhlIG1vKSBp dCBhdCBsZWFzdCBtYWtlcyB0aHJvdWdocHV0IGludmVyc2VseSBwcm9wb3J0aW9uYWwgdG8gMS9S VFQsIHdoZXJlYXMgdGhlIGFwcHJvYWNoIGluIFtEQ1RDUDEwXSBtYWRlIGl0IGludmVyc2VseSBw cm9wb3J0aW9uYWwgdG8gMS8oUlRUXjIpLiBJIGJlbGlldmUgdGhlIExpbnV4IGltcGxlbWVudGF0 aW9uIHVzZXMgdGhlIFtBRENUQ1AxMF0gYXBwcm9hY2guDQoNCjxQcmF2ZWVuPiBGYWlyIGVub3Vn aC4gVXBkYXRlZC4NCg0KDQogICBUaGUgaW1wbGVtZW50YXRpb24gbXVzdCBhbHNvIGRlY2lkZSB3 aGVuIHRvIHVzZSBEQ1RDUC4NCg0KLi4uDQoNCiAgIGxpa2VseSBpbiB0aGUgc2FtZSBkYXRhY2Vu dGVyIG5ldHdvcmsuDQpUaGUgMm5kICYgM3JkIHBhcmFzIGFyZSBhIG1peCBvZiBpbXBsZW1lbnRh dGlvbiBhbmQgZGVwbG95bWVudCBpc3N1ZXMsIGJ1dCBtb3N0bHkgZGVwbG95bWVudCwgc28gdGhl eSBtaWdodCBiZSBiZXR0ZXIgbW92ZWQgdG8gdGhlIGRlcGxveW1lbnQgaXNzdWVzIHNlY3Rpb24u DQoNCg0KDQo8UHJhdmVlbj4gSSB0aGluayB0aGV5IGFyZSBtYWlubHkgaW1wbGVtZW50YXRpb24g aXNzdWVzIOKAkyB0aGUgZmFjdCB0aGF0IGEgbGFjayBvZiBuZWdvdGlhdGlvbiBtZWNoYW5pc20g cGxhY2VzIGEgYnVyZGVuIG9uIHRoZSBpbXBsZW1lbnRhdGlvbiB0byBwcm92aWRlIGtub2JzIG9y IGhldXJpc3RpY3MgdG8gdXNlIERDVENQLg0KDQoNCg0KQ1VSUkVOVDoNCg0KICAgSXQgaXMgUkVD T01NRU5ERUQgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBkZWFsIHdpdGggbG9zcyBlcGlzb2RlcyBp bg0KDQogICB0aGUgc2FtZSB3YXkgYXMgY29udmVudGlvbmFsIFRDUC4NCg0KLi4uDQoNCiAgIERD VENQIGltcGxlbWVudGF0aW9uIE1BWSBhbHNvIGFsbG93IGNvbmZpZ3VyYXRpb24gb2YgcmVzZXR0 aW5nIHRoZQ0KDQogICB2YWx1ZSBvZiBEQ1RDUC5BbHBoYSBhcyBwYXJ0IG9mIHByb2Nlc3Npbmcg YW55IGxvc3MgZXBpc29kZXMuDQpTVUdHRVNURUQ6IE1vdmUgdGhpcyB3aG9sZSBwYXJhIHRvIDMu MyBTZW5kZXIgQmVoYXZpb3VyIHNlY3Rpb24sIGFuZDoNCg0KICAgQW4gaW1wbGVtZW50YXRpb24g TVVTVCBkZWFsIHdpdGggbG9zcyBlcGlzb2RlcyBpbg0KDQogICB0aGUgc2FtZSB3YXkgYXMgY29u dmVudGlvbmFsIFRDUC4NCg0KLi4uDQoNCiAgIERDVENQIGltcGxlbWVudGF0aW9uIFNIT1VMRCBh bHNvIHJlc2V0IHRoZQ0KDQogICB2YWx1ZSBvZiBEQ1RDUC5BbHBoYSBhcyBwYXJ0IG9mIHByb2Nl c3NpbmcgYW55IGxvc3MgZXBpc29kZXMuDQoNCiAgIFRoaXMgYXNwZWN0IG9mIHRoZSBiZWhhdmlv dXIgTUFZIGJlIGNvbmZpZ3VyYWJsZS4NClJBVElPTkFMRToNCiAgIGEpIFRoZXJlIHdvdWxkIG5l dmVyIGJlIGEgY2FzZSBmb3Igbm90IGZhbGxpbmcgYmFjayB0byBjb252ZW50aW9uYWwgVENQICAo b3IgZG8geW91IGhhdmUgb25lPyksIHNvICJSRUNPTU1FTkRFRCIgaXMgdG9vIHdlYWsuDQogICBi KSBJIGhhdmUgdHJpZWQgdG8gaW50ZXJwcmV0IHdoYXQgeW91IG1pZ2h0IGhhdmUgbWVhbnQgYWJv dXQgcmVzZXR0aW5nIEFscGhhLiBJJ20gbm90IHN1cmUgd2h5IHlvdSB0aGluayBpdCBtaWdodCBu ZWVkIHRvIGJlIGNvbmZpZ3VyYWJsZSB0aG91Z2g/DQo8UHJhdmVlbj4gWWVzIHRoaXMgaXMgYSB1 c2VmdWwgc3VnZ2VzdGlvbi4gTWFraW5nIGxvc3MgaGFuZGxpbmcgYSBtdXN0IGluIHNlbmRlciBz ZWN0aW9uLiBSZXNldCBvZiBhbHBoYSB3YXMgZGlzY3Vzc2VkIGluIHRjcG0gbGlzdCwgYW5kIExp bnV4IGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIGl0Lg0KDQoNCg0KICAgLi4uaXQgaXMgYWxzbyBS RUNPTU1FTkRFRCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGFsbG93DQoNCiAgIGNvbmZpZ3VyYXRp b24gb2YgcmVzdGFydGluZyB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgKGN3bmQpIG9mIGlkbGUNCg0K ICAgRENUQ1AgY29ubmVjdGlvbnMNCldoZXJlIHNwZWNpYWwgaW1wbGVtZW50YXRpb24gbWVhc3Vy ZXMgYXJlIG5lY2Vzc2FyeSBmb3IgbG93IFJUVCwgdGhlc2Ugc2hvdWxkIGJlIHJlbGF0ZWQgdG8g dGhlIG1lYXN1cmVkIFJUVCwgbm90IGhhcmQtY29kZWQuIFRoZXJlIGlzIGFuIGFzc3VtcHRpb24g aW4gYSBudW1iZXIgb2YgcGxhY2VzICB0aGF0ICJkYXRhIGNlbnRyZSIgaW1wbGllcyBsb3cgUlRU LiBPZiBjb3Vyc2UgdGhpcyBpcyB0cnVlIGluIGEgc2luZ2xlIERDLCBidXQgSSBiZWxpZXZlIHRo ZSB0aGUgc2luZ2xlIGFkbWluIGFzcGVjdCBvZiBhIERDIGlzIHdoYXQgY2hhcmFjdGVyaXNlcyBE Q1RDUCwgbm90IHRoZSBsb3cgUlRUIGFzcGVjdC4gV2l0aCB0aGUgbW9kaWZpY2F0aW9ucyBpbiBb QURDVENQXSwgRENUQ1AgZ2VuZXJhbGlzZXMgdG8gYSBuZXR3b3JrIHdpdGggbGFyZ2VyIFJUVHMg YXMgbG9uZyBhcyBpdCBpcyBzdGlsbCAgb3BlcmF0ZWQgYnkgYSBzaW5nbGUgYWRtaW4uDQoNCg0K DQo8UHJhdmVlbj4gdGhpcyBwYXJhZ3JhcGggaGFzIG5vdyBiZWVuIHJlbW92ZWQgcGVyIE1pY2hh ZWxz4oCZIGZlZWRiYWNrLg0KDQoNCkNVUlJFTlQ6DQogICBbUkZDMzE2OF0gZm9yYmlkcyB0aGUg RUNOLW1hcmtpbmcgb2YgcHVyZSBBQ0sgcGFja2V0cywgYmVjYXVzZSBvZiB0aGUNCiAgIGluYWJp bGl0eSBvZiBUQ1AgdG8gbWl0aWdhdGUgQUNLLXBhdGggY29uZ2VzdGlvbiBhbmQgcHJvdG9jb2wt d2lzZQ0KICAgcHJlZmVyZW50aWFsIHRyZWF0bWVudCBieSByb3V0ZXJzLiAgSG93ZXZlciwgZHJv cHBpbmcgcHVyZSBBQ0tzIC0NCiAgIHJhdGhlciB0aGFuIEVDTiBtYXJraW5nIHRoZW0gLSBoYXMg ZGlzYWR2YW50YWdlcyBmb3IgdHlwaWNhbA0KICAgZGF0YWNlbnRlciB0cmFmZmljIHBhdHRlcm5z LiAgQmVjYXVzZSBvZiB0aGUgcHJldmFsZW5jZSBvZiBidXJzdHkNCiAgIHRyYWZmaWMgcGF0dGVy bnMgdGhhdCBmZWF0dXJlIHRyYW5zaWVudCBjb25nZXN0aW9uLCBkcm9wcGluZyBvZiBBQ0tzDQog ICBjYXVzZXMgc3Vic2VxdWVudCByZXRyYW5zbWlzc2lvbnMuIEl0IGlzIFJFQ09NTUVOREVEIHRo YXQgYW4NCiAgIGltcGxlbWVudGF0aW9uIHByb3ZpZGUgYSBjb25maWd1cmF0aW9uIGtub2IgdGhh dCB3aWxsIGNhdXNlIEVDVCB0byBiZSBzZXQNCiAgIG9uIHN1Y2ggY29udHJvbCBwYWNrZXMsIHdo aWNoIGNhbiBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZSBzdWNoDQogICBjb25jZXJucyBk byBub3QgYXBwbHkuDQpTVUdHRVNURUQ6DQogICBbUkZDMzE2OF0gZm9yYmlkcyB0aGUgRUNOLW1h cmtpbmcgb2YgcHVyZSBBQ0sgcGFja2V0cywgYmVjYXVzZSBvZiB0aGUNCiAgIGluYWJpbGl0eSBv ZiBUQ1AgdG8gbWl0aWdhdGUgQUNLLXBhdGggY29uZ2VzdGlvbiBhbmQgdGhlIGV4dHJhDQogICBh ZHZhbnRhZ2UgdG8gaW5qZWN0aW9uIGF0dGFja2VycyB0aGF0IEVDTiBpcyBwZXJjZWl2ZWQgdG8g b2ZmZXIuDQogICBGb3IgdGhlIGxhdHRlciByZWFzb24gUkZDIDMxNjggYWxzbyBmb3JiaWRzIEVD Ti1tYXJraW5nIG9mDQogICByZXRyYW5zbWlzc2lvbnMsIHdpbmRvdyBwcm9iZXMgYW5kIFJTVHMu DQoNCiAgIEhvd2V2ZXIsIGRyb3BwaW5nIGFsbCB0aGVzZSBjb250cm9sIHBhY2tldHMgLQ0KICAg cmF0aGVyIHRoYW4gRUNOIG1hcmtpbmcgdGhlbSAtIGhhcyBjb25zaWRlcmFibGUgcGVyZm9ybWFu Y2UNCiAgIGRpc2FkdmFudGFnZXMuICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGFuDQogICBpbXBs ZW1lbnRhdGlvbiBwcm92aWRlIGEgY29uZmlndXJhdGlvbiBrbm9iIHRoYXQgd2lsbCBjYXVzZSBF Q1QgdG8gYmUgc2V0DQogICBvbiBzdWNoIGNvbnRyb2wgcGFja2VzLCB3aGljaCBjYW4gYmUgdXNl ZCBpbiBlbnZpcm9ubWVudHMgd2hlcmUgc3VjaA0KICAgY29uY2VybnMgZG8gbm90IGFwcGx5Lg0K Tk9URToNCiAgIFRoaXMgbWlnaHQgbm90IHJlZmxlY3QgdGhlIHdheSB5b3VyIGltcGxlbWVudGF0 aW9uIGlzIGNvZGVkLCBzbyB5b3UgbWlnaHQgd2FudCB0byBtYWtlIHRoYXQgY2xlYXIuDQoNCg0K DQoNCjxQcmF2ZWVuPiBGaXhlZA0KW0JCXSBBIG5ldyBjb21tZW50Li4uDQoNCkFzIHBvaW50ZWQg b3V0IGluIGRyYWZ0LWJhZ3Vsby10c3Z3Zy1nZW5lcmFsaXplZC1lY24tMDAsIFJGQzMxNjggb25s eSB0YWxrcyBhYm91dCBpbmplY3Rpb24gYXR0YWNrcyB3aXRoIHJldHJhbnNtaXNzaW9ucyAobm90 IEFDS3MgZXRjKS4gQnV0IHlvdSBpbXBseSBpbmplY3Rpb24gYXR0YWNrcyB3ZXJlIHRoZSBjb25j ZXJuIGZvciBvdGhlciBjb250cm9sIHBhY2tldHMgYXMgd2VsbC4NCg0KSSdtIG5vdCBpbnNpc3Rp bmcgeW91IGNoYW5nZSB0aGlzLiBIb3dldmVyLCB1bndhcnJhbnRlZCBhY2N1c2F0aW9ucyBvZiBz ZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMgdGVuZCB0byBzdGljaywgd2hldGhlciBvciBub3QgdGhl eSBhcmUgY29ycmVjdC4gU28gaXQgd291bGQgYmUgYmV0dGVyIG5vdCB0byB0aHJvdyBtdWQgYXJv dW5kIG9udG8gZXZlbiBtb3JlIGNvbnRyb2wgcGFja2V0cyB0aGFuIFJGQzMxNjggZGlkLg0KDQoN Cg0KPj4gTW9kaWZpZWQgdGhpcyB0byByZW1vdmUgdGhhdCBzdWdnZXN0aW9uLg0KDQoNCg0KDQpD aGVlcnMNCg0KDQpCb2INCg0KDQoNCg0KNS4gRGVwbG95bWVudCBJc3N1ZXMNCg0KICAgSWYNCg0K ICAgdGhlIHRyYWZmaWMgaW4gdGhlIGRhdGFjZW50ZXIgaXMgYSBtaXggb2YgY29udmVudGlvbmFs IFRDUCBhbmQgRENUQ1AsDQoNCiAgIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgRENUQ1AgdHJhZmZp YyBiZSBzZWdyZWdhdGVkIGZyb20gY29udmVudGlvbmFsDQoNCiAgIFRDUCB0cmFmZmljLg0KSW4g YSBkYXRhIGNlbnRyZSAob3IgYW55d2hlcmUpLCBpcyB0aGVyZSBhbnkgY2FzZSB3aGVyZSBub3Qg c2VncmVnYXRpbmcgdGhlbSB3b3VsZCBtYWtlIHNlbnNlPyBJZiBub3QsIHRoaXMgbmVlZHMgdG8g YmUgYSBNVVNULCBub3QganVzdCBhIFJFQ09NTUVOREVELiBJIGNhbiBpbWFnaW5lIGNhc2VzIHdo ZXJlIHRoZXJlIGlzIG5vIGxvbmctcnVubmluZyBjb252ZW50aW9uYWwgVENQIG9yIG5vIGxvbmct cnVubmluZyBEQ1RDUCwgYnV0IHRoYXQncyBjb3ZlcmVkIGJ5IHRoZSAiaWYiIGF0IHRoZSBzdGFy dCBvZiB0aGUgc2VudGVuY2UuDQoNCllvdSBtaWdodCB3YW50IHRvIHJlZmVyIHRvIGRyYWZ0LWJy aXNjb2UtYXFtLWR1YWxxLWNvdXBsZWQgYXMgYW5vdGhlciBzZWdyZWdhdGlvbiBhcHByb2FjaCBo ZXJlIHRvby4NCg0KICAgU2luY2UgRENUQ1AgcmVsaWVzIG9uIGNvbmdlc3Rpb24gbWFya2luZyBi eSB0aGUgc3dpdGNoZXMsIERDVENQIGNhbg0KDQogICBvbmx5IGJlIGRlcGxveWVkIGluIGRhdGFj ZW50ZXJzIHdoZXJlIHRoZSBlbnRpcmUgbmV0d29yaw0KDQogICBpbmZyYXN0cnVjdHVyZSBzdXBw b3J0cyBFQ04uDQpTdXJlbHksIHRoZSAiZmFsbC1iYWNrIHRvIGNvbnZlbnRpb25hbCBUQ1Agb24g bG9zcyIgcnVsZSBtZWFucyB5b3UgY2FuIGRlbGV0ZSB0aGlzIGNvbnN0cmFpbnQuDQoNCjxQcmF2 ZWVuPiBSZXdvcmRlZCB0byBpbXBseSB0aGF0IERDVENQIHdpbGwgb25seSB3b3JrIGFzIGV4cGVj dGVkIGluIHN1Y2ggY2FzZXMuDQoNCg0KICAgQQ0KDQogICB2YXJpYW50IG9mIERDVENQIHRoYXQg Y2FuIGJlIGRlcGxveWVkIHVuaWxhdGVyYWxseSBhbmQgb25seSByZXF1aXJlcw0KDQogICBzdGFu ZGFyZCBFQ04gYmVoYXZpb3IgaGFzIGJlZW4gZGVzY3JpYmVkIGluIFtPRENUQ1A8aHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0 b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtT0RD VENQJmRhdGE9MDElN2MwMSU3Y3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Y2E1NzJiMGJhOGUxYjQ3 ZDNlNDRhMDhkMmU2ZDdlMDNmJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JnNkYXRhPVp3ZkowTGdIUTN2ayUyYk1EMHdpaWE1eUxyY01NU1VCY0dnUFlYbWVSdThoRSUzZD5d W0JTRENBTl0sDQoNCldoaWNoIHBhcnQgb2YgInN0YW5kYXJkIEVDTiBiZWhhdmlvdXIiIGRvIHlv dSBtZWFuPyBUaGUgaG9zdCBwYXJ0PyBUaGUgbmV0d29yayBwYXJ0PyBUaGUgcmVjZWl2ZXIgcGFy dD8gQW5kICJjYW4gYmUgZGVwbG95ZWQgdW5pbGF0ZXJhbGx5IiBvdWdodCB0byBiZSBpbiB0aGUg YWN0aXZlIHZvaWNlIG5vdCB0aGUgcGFzc2l2ZSwgd2hpY2ggd291bGQgaGVscCByZXNvbHZlIHRo ZSBhbWJpZ3VpdHkgdG9vLg0KDQpJIGhhdmVuJ3QgcmVhZCBbT0RDVENQXSBhbmQgW0JTRENBTl0g KEknbSBvZmZsaW5lIG9uIGEgcGxhbmUgYXQgdGhlIG1vKS4gQXJlIHRoZXkgc2ltaWxhciB0byAi SW5zdGFudCBFQ04iIGluIFtXdTEyXSBsaXN0ZWQgYmVsb3c/IElmIG5vdCwgdGhhdCBjb3VsZCBi ZSByZWZlcnJlZCB0byBhcyB3ZWxsIGZvciBhIHRlY2huaXF1ZSB0aGF0IHVzZXMgdGhlIHJlZ3Vs YXIgRUNOIGhvc3QgYmVoYXZpb3VyLg0KDQoNCg0KPFByYXZlZW4+IFRoaXMgZWRpdCBwcmVkYXRl cyBtZSBhbmQgIEkgZG9u4oCZdCBoYXZlIHRoZSBmdWxsIGNvbnRleHQsIEkgYW0gbGVhdmluZyB0 aGlzIGFzIGlzLg0KDQoNCg0KNi4gS25vd24gSXNzdWVzDQoNCkZpcnN0IHBhcmEgY291bGQgcmVm ZXIgdG8gYXBwZW5kaXggQSBvZiBSRkM3NTYwLCB3aGljaCBkZXNjcmliZXMgdGhlIHByb2JsZW0g cHJlY2lzZWx5Lg0KDQoNCg0KDQpBIG1ldGhvZCBmb3IgaW1wcm92aW5nIHRoZSBmYWlybmVzcyBv ZiBEQ1RDUCBoYXMgYmVlbiBwcm9wb3NlZA0KDQogICBpbiBbQURDVENQPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMu aWV0Zi5vcmclMmZodG1sJTJmZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTAxJTIzcmVmLUFEQ1RDUCZk YXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0 YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0 YT1lZFUyVFBHcEx2eUZHdmdvY0RSSmlZUlF5akNUJTJmV0VPZ1MyTXdtd3pZdVUlM2Q+XSwgYnV0 IHJlcXVpcmVzIGFkZGl0aW9uYWwgZXhwZXJpbWVudGFsIGV2YWx1YXRpb24uDQpzL2ZhaXJuZXNz L1JUVCBmYWlybmVzcy8NCg0KKEluIG91ciBleHBlcmltZW50cywgaXQncyBtdWNoIGJldHRlciB0 aGFuIHdpdGhvdXQuKQ0KDQoNCg0KPFByYXZlZW4+IEdvYWwgaXMgdG8gY2l0ZSBvdGhlciB3b3Jr IHRoYXQgY2FuIGFkZHJlc3MgcG90ZW50aWFsIGlzc3Vlcy4gSXQgaXMgbm90IGEgcmVjb21tZW5k YXRpb24uIHMvZmFpcm5lc3MvUlRUIGZhaXJuZXNzLyBGaXhlZCBpbiBuZXh0IHJldmlzaW9uLg0K DQoNCjExLiBSZWZlcmVuY2VzDQoNCkkgdGhpbmsgdGhlIGZvbGxvd2luZyBhcmUgY2l0ZWQgbm9y bWF0aXZlbHksIG5vdCBqdXN0IGluZm9ybWF0aXZlbHk6DQpSRkM1NjgxLCBSRkM1NTYyLg0KDQpB ZGRpdGlvbmFsIGluZm9ybWF0aW9uYWwgUmVmZXJlbmNlOg0KDQpbV3UxMl0gV3UsIEguLCBKdSwg Si4sIEx1LCBHLiwgR3VvLCBDLiwgWGlvbmcsIFkuICYgWmhhbmcsIFkuLCAiVHVuaW5nIEVDTiBm b3IgRGF0YSBDZW50ZXIgTmV0d29ya3MsIiBJbjogUHJvY2VlZGluZ3Mgb2YgdGhlIDh0aCBJbnRl cm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gRW1lcmdpbmcgTmV0d29ya2luZyBFeHBlcmltZW50cyBh bmQgVGVjaG5vbG9naWVzIENvTkVYVCAnMTIgcHAuMjUtMzYgQUNNICgyMDEyKQ0KDQoNCg0KPFBy YXZlZW4+IENpdGF0aW9uIHRvIFJGQ3MgdXBkYXRlZCBhcyBub3JtYXRpdmUuIE5vdCBpbmNsdWRp bmcgdGhlIG5ldyByZWZlcmVuY2Ugc2luY2UgZXZlbiB0aG91Z2ggaXQgbWF5IGJlIHJlbGV2YW50 IOKAkyBpdCB3YXMgbm90IHVzZWQgYXMgYSByZWZlcmVuY2UgaW4gd3JpdGluZyB0aGUgZHJhZnQu DQoNCg0KVGhhdCdzIGl0LiBIVEguDQoNCg0KQm9iDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJv YiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29l Lm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzYSUyZiUyZmJvYmJyaXNjb2UubmV0JTJmJmRhdGE9MDElN2MwMSU3Y3ByYXZiJTQwbWlj cm9zb2Z0LmNvbSU3Y2E1NzJiMGJhOGUxYjQ3ZDNlNDRhMDhkMmU2ZDdlMDNmJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPWlFdmhXajlGQ1BveldBcDhybnhrNVZa ZE5GJTJmdjdXN2FEMUNwNE14T2lTcyUzZD4NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJy aXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0 Lw0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_BY2PR03MB0117403DA329375E35CB146B6BD0BY2PR03MB011namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp ZjsNCgljb2xvcjpibGFjazt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlRoYW5rcyBmb3IgdGhlIHJldmlldyBC b2IuIElubGluZSBwcmVmaXhlZCBieSAmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29l IFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgQXVndXN0IDE4LCAyMDE2IDk6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdGNw bSBJRVRGIGxpc3QgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi10Y3BtLWRjdGNwLTAxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Q cmF2ZWVuLDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDE3LzA3LzE2IDIxOjI1LCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIEJvYi4gU29ycnkgZm9yIHRoZSAmbHQ7 cmlkaWN1bG91cyZndDsgZGVsYXkuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQl0gQW5kIG5vdyBzb3JyeSBmb3Ig bXkgZGVsYXkuIEkgdHJpZWQgdG8gZmluaXNoIHRoaXMgZW1haWwgYSBudW1iZXIgb2YgdGltZXMs IGJ1dCBrZXB0IGdldHRpbmcgaW50ZXJydXB0ZWQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5Db21tZW50cyBpbmxpbmUgcHJlZml4ZWQgYnkgJmx0O1ByYXZlZW4mZ3Q7LiBNb3N0IG9m IHRoZXNlIGVkaXRzIHdpbGwgYmUgaW4gdGhlIG5leHQgcmV2aXNpb24uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkJd IEkndmUgdHJpZWQgdmVyeSBoYXJkIHRvIG9ubHkgY29tbWVudCB3aGVyZSBJIHJlYWxseSBkbyB0 aGluayB0aGVyZSBpcyBzdGlsbCBhIHByb2JsZW0gKGV2ZW4gaWYgbWlub3IpLCBhbmQgc3VnZ2Vz dGVkIHNwZWNpZmljIHRleHQgdG8gaGVscCB5b3UuLi48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PiBCb2IgQnJpc2NvZSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0 Ij5tYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldDwvYT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgNiwgMjAxNSAxMDoy NyBBTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj4mbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZn dDs8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjsgRUdHRVJULCBMYXJzDQo8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSI+Jmx0O2xhcnNAbmV0YXBwLmNvbSZn dDs8L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjsgU3RlcGhlbiBCZW5zbGV5DQo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNiZW5zQG1pY3Jvc29mdC5jb20iPiZsdDtzYmVuc0BtaWNy b3NvZnQuY29tJmd0OzwvYT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+OyBEYXZlIFRo YWxlcg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkdGhhbGVyQG1pY3Jvc29mdC5jb20iPiZsdDtk dGhhbGVyQG1pY3Jvc29mdC5jb20mZ3Q7PC9hPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 Ij47DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmdsZW5uLmp1ZGRAbW9yZ2Fuc3RhbmxleS5jb20i PmdsZW5uLmp1ZGRAbW9yZ2Fuc3RhbmxleS5jb208L2E+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxicj4NCjxiPkNjOjwvYj4gdGNwbSBJRVRGIGxpc3QgPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzp0Y3BtQGlldGYub3JnIj4mbHQ7dGNwbUBpZXRmLm9yZyZndDs8L2E+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZXZpZXcgb2YgZHJhZnQt aWV0Zi10Y3BtLWRjdGNwLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlByYXZlZW4gJmFtcDsgY28tYXV0aG9ycyw8YnI+DQo8YnI+DQpBcyBwcm9t aXNlZCwgaGVyZSdzIG15IHJldmlldyBvZiBkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDE8YnI+DQo8 YnI+DQo8Yj48dT5HZW5lcmFsIENvbW1lbnRzPGJyPg0KPC91PjwvYj48YnI+DQpJbiBnZW5lcmFs LCBpbiB0aGUgY29tbWVudHMgYmVsb3cgSSBoYXZlIHRyaWVkIHRvIHJlZHVjZSB0aGUgbXVsdGlw bGUgYXNzdW1wdGlvbnMgYWJvdXQgY29udHJvbGxlZCBlbnZpcm9ubWVudHMgZG93biB0byB0aGUg b25lIGFzc3VtcHRpb24gdGhhdCB0aGV5IGFyZSBjb250cm9sbGVkIGJ5IGEgc2luZ2xlIGF1dGhv cml0eS4gSSBiZWxpZXZlIERDVENQIGNhbiB3b3JrIHdpdGhvdXQgdGhlIG90aGVyIGFzc3VtcHRp b25zLCBzbyB0aGUgZm9sbG93aW5nDQogZG8gbm90IGFwcGx5IGluIGFsbCBjb250cm9sbGVkIGVu dmlyb25tZW50czo8YnI+DQombmJzcDsgKiBub3QgYWx3YXlzIGxvdyBSVFQgKGUuZy4gaW50ZXIt REMgc2NlbmFyaW9zLCBvciBnbG9iYWwgcHJpdmF0ZSBuZXR3b3Jrcyk8YnI+DQombmJzcDsgKiBu b3QgYWx3YXlzIG5vIHJpc2sgb2YgdHJhZmZpYyBhdHRhY2tzIChlLmcuIGludGVybmFsbHkgYXJy YW5nZWQgYXR0YWNrcyk8YnI+DQpJIG1heSBoYXZlIG1pc3NlZCBzb21lIG90aGVyIG9jY3VycmVu Y2VzIG9mIHRoZXNlIGFzc3VtcHRpb25zLCBzbyBwbHMgZmVlbCBmcmVlIHRvIHNlZWsgb3V0IHRo ZW0gYWxsLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1ByYXZlZW4mZ3Q7IERDVENQ IGNhbiBiZSBleHRlbmRlZCB0byBvdGhlciBlbnZpcm9ubWVudHMgYnV0IHRoaXMgZHJhZnQgZG9l cyBub3QgY292ZXIgYW55IG9mIHRoYXQuIEl0IGlzIGV4cGxpY2l0bHkgZm9yIGRlcGxveW1lbnQg aW4gYSBkYXRhY2VudGVyIHdoZXJlDQogdGhlIFJUVCBpcyBsb3cgYW5kIHRoZXJlIGlzIG5vIHJp c2sgb2YgaW50ZXJuYWwgYXR0YWNrLiBXZSBjYW5ub3QgY292ZXIgb3RoZXIgc2NlbmFyaW9zIHRo YXQgaGF2ZSBub3QgYmVlbiB0ZXN0ZWQgb3IgZGVwbG95ZWQuIEFsbCB0aGUga25vd24gZGVwbG95 bWVudHMgYXJlIGluIGNvbnRyb2xsZWQgZGF0YWNlbnRlcnMuIFRoZSBUQ1AgUHJhZ3VlIGVmZm9y dCBzaG91bGQgcmVzdWx0IGluIGEgZHJhZnQgdGhhdCBjb3ZlcnMgYWRkaXRpb25hbCByZXF1aXJl bWVudHMNCiB0aGF0IHdpbGwgbWFrZSBEQ1RDUCB3b3JrIHdlbGwgb24gaGlnaCBsYXRlbmN5IGxp bmtzLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk1hbnkgb2YgdGhlIGNvbW1lbnRzIGFyZ3VlIHdpdGgg eW91ciBjaG9pY2VzIG9mIE1VU1QsIFNIT1VMRCwgTUFZIGV0Yy4gVGhpcyBtaWdodCBzZWVtIG5p dC1waWNraW5nLCBnaXZlbiB0aGUgcHJpbWFyeSBwdXJwb3NlIGlzIHRvIGRvY3VtZW50IHRoZSBh bGdvLiBIb3dldmVyLCBpdCB3b3VsZCBiZSB3cm9uZyB0byByZXF1aXJlIHRoaW5ncyB0aGF0IGFy ZW4ndCByZXF1aXJlZCBvciB0byBhbGxvdyBleGNlcHRpb25zIHdoZW4gZXhjZXB0aW9ucyB3b3Vs ZA0KIG5vdCBiZSBpbnRlcm9wZXJhYmxlLiBBbiBhbHRlcm5hdGl2ZSBhcHByb2FjaCB3b3VsZCBi ZSB0byBqdXN0IHJlbW92ZSBhbGwgY2FwaXRhbGlzZWQgbGFuZ3VhZ2UuPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgSSBhbSBmaW5lIHdpdGggcmVtb3Zpbmcgc3Vj aCBjYXBpdGFsaXphdGlvbiBleGNlcHQgZm9yIHdoZW4gcmVtb3ZpbmcgaXQgd2lsbCBsZWFkIHRv IGludGVyb3AgcHJvYmxlbXMgYmV0d2VlbiBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIG9mDQog RENUQ1AuIEkgYW0gcmVzcG9uZGluZyB0byBlYWNoIGNvbW1lbnQgYmVsb3cgYW5kIGFkZGluZyB3 aGV0aGVyIHRoZSBuZXcgcmV2aXNpb24gd2lsbCBmaXggaXQgbm90Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+PHU+U2VjdGlvbi1ieS1zZWN0 aW9uIHJldmlldy48YnI+DQo8L3U+PC9iPjxicj4NCjxiPkFic3RyYWN0PGJyPg0KPC9iPjxicj4N CkkgdGhpbmsgaXQgbmVlZHMgdG8gaGF2ZSBhbiBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBpbiB0 aGUgYWJzdHJhY3QgKGFuZCBpbnRyb2R1Y3Rpb24pIHRoYXQgcmVmZXJzIHRvIHRoZSBkZXBsb3lt ZW50IGFuZCBpbXBsZW1lbnRhdGlvbiBzdGF0dXMgc2VjdGlvbnMgYXQgdGhlIGVuZC4gU29tZXRo aW5nIGxpa2U6PGJyPg0KPGJyPg0KJnF1b3Q7VGhpcyBpcyBhbiBpbmZvcm1hdGlvbmFsIHNwZWNp ZmljYXRpb24gb2YgdGhlIGltcGxlbWVudGF0aW9uIG9mIERDVENQIGluIE1pY3Jvc29mdCBXaW5k b3dzIFNlcnZlciAyMDEyLiBJdCBpcyBhcHBsaWNhYmxlIHRvIGRlcGxveW1lbnRzIGluIGNvbnRy b2xsZWQgZW52aXJvbm1lbnRzIGxpa2UgZGF0YSBjZW50cmVzIGJ1dCBpdCBNVVNUIE5PVCBiZSBk ZXBsb3llZCBvdmVyIHRoZSBwdWJsaWMgSW50ZXJuZXQgd2l0aG91dCBhZGRpdGlvbmFsIG1lYXN1 cmVzLA0KIGFzIGRldGFpbGVkIGluIHNlY3Rpb25zIDQtNi4gJnF1b3Q7PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgVGhpcyBpcyBhbHJlYWR5IGFkZHJlc3NlZCBp biB0aGUgaW50cm9kdWN0aW9uLiBJIGRvbuKAmXQgc2VlIHRoZSB2YWx1ZSBvZiByZXBlYXRpbmcg aXQgbXVsdGlwbGUgdGltZXMuIEFuIGltcGxlbWVudGVyIHdpbGwgcmVhZCB0aGUgaW50cm9kdWN0 aW9uLg0KIElmIHlvdSBzdGlsbCBmZWVsIHN0cm9uZ2x5LCB3ZSBjYW4gYWRkIGl0IHRvIHRoZSBh YnN0cmFjdCBhbmQgcmVtb3ZlIGl0IGZyb20gdGhlIGludHJvZHVjdGlvbiBzZWN0aW9uLiBUaGlz IGRyYWZ0IHdpbGwgbm90IGNvdmVyIGFueSBhZGRpdGlvbmFsIG1lYXN1cmVzIHRoYXQgYXJlIGlu dGVuZGVkIGZvciBkZXBsb3ltZW50cyBvdXRzaWRlIHRoZSBkYXRhY2VudGVyIOKAkyB0aGF04oCZ cyBub3QgdGhlIGludGVuZGVkIHB1cnBvc2UuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQl0gSXQgaXMgdmVyeSBj b21tb24gZm9yIHRoZSBJRVRGIHRvIHJlcXVpcmUgZXZlbiBtdWNoIGxlc3MgbWlub3IgYXBwbGlj YWJpbGl0eSBzdGF0ZW1lbnRzIHRvIGJlIGhpZ2hsaWdodGVkIGluIHRoZSBhYnN0cmFjdCAoZS5n LiBzZWUgVEZPIFJGQykuIFRoaXMgaXMgYmVjYXVzZSBub3dhZGF5cyBpbXBsZW1lbnRlcnMgLyBy ZWFkZXJzIG9mdGVuIHNraXAgaW50cm9kdWN0b3J5IHRleHQgYXNzdW1pbmcgdGhleQ0KIHVuZGVy c3RhbmQgdGhlIHByb2JsZW0sIGV0Yy4gYW5kIHRoZXkganVzdCBzY2FuIGZvciB0aGUgbm9ybWF0 aXZlIHBhcnRzLiBBbnlvbmUgcmVhZGluZyBhbiBJRVRGIFJGQ3MgYXNzdW1lcyB0aGUgY29udGV4 dCBpcyB0aGUgcHVibGljIEludGVybmV0LCBzbyBhbnkgUkZDIHRoYXQgZG9lc24ndCBoYXZlIHRo YXQgY29udGV4dCBuZWVkcyB0byBmbGFnIHRoYXQuIEkga25vdyB0aGUgbmFtZSBzYXlzIERhdGEg Q2VudHJlLCBidXQgdGhlIGFic3RyYWN0DQogbmVlZHMgdG8gZXhwbGFpbiB0aGF0IHRoaXMgaXMg bm90IGFuIElFVEYgUkZDIHRoYXQgaXMgc3RhbmRhcmRpemluZyBEQ1RDUCBmb3IgdGhlIHB1Ymxp YyBJbnRlcm5ldC4NCjxicj4NCjxicj4NCklmIHlvdSBzdGlsbCBkb24ndCB0aGluayBzbywgd2Ug c2hvdWxkIHB1dCB0aGlzIHRvIHRoZSBXRyAod2hpY2ggd2lsbCBzbG93IGl0IGRvd24pLjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7Jmd0OyBBbHJp Z2h0IGluY2x1ZGluZyB0ZXh0IHRvIGV4cGxpY2l0bHkgc2F5IHNvLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGJyPg0KPGI+MS4gSW50cm88YnI+DQo8L2I+cy9pdHMgbWFueSBzZXJ2ZXJzLzxicj4N CiZuYnNwOy90aGVpciBtYW55IHNlcnZlcnMvPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bHQ7UHJhdmVlbiZndDsgRml4ZWQgaW4gbmV4dCByZXZpc2lvbi48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4N CiZxdW90Oy4uLmxpbWl0ZWQgcXVldWUgY2FwYWNpdGllcy4uLiZxdW90OyA8YnI+DQpJIHVuZGVy c3RhbmQgdGhhdCB0aGUgbW90aXZhdGlvbiBoYXMgYmVlbiBhYmJyZXZpYXRlZCwgYnV0IEkgdGhp bmsgdGhpcyBoYXMgbG9zdCB0b28gbXVjaC4gUGVyaGFwcyBtZW50aW9uIG1lbW9yeSBzaGFyZWQg YmV0d2VlbiBpbnRlcmZhY2VzLCBzbyBlaXRoZXIgYmxvYXRlZCBidWZmZXJzIG9yIHRvbyBsaXR0 bGUsIG1ha2luZyB0cmFmZmljIHN1c2NlcHRpYmxlIHRvIHBhY2tldCBsb3NzZXM/PGJyPg0KPGJy Pg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgW1JGQzMx NjhdIGRlc2NyaWJlcyBhIG1lY2hhbmlzbSBmb3IgdXNpbmcgRXhwbGljaXQgQ29uZ2VzdGlvbjwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IE5vdGlmaWNh dGlvbiAoRUNOKSBmcm9tIHRoZSBzd2l0Y2hlcyBmb3IgZWFybHkgZGV0ZWN0aW9uIG9mPC90dD48 YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbmdlc3Rpb24sIHJhdGhlciB0aGFuIHdhaXRpbmcgZm9y IHBhY2tldCBsb3NzIHRvIG9jY3VyLjwvdHQ+PGJyPg0KPC9zcGFuPjxicj4NClRoaXMgaXNuJ3Qg Y29ycmVjdC4gMzE2OCByZXF1aXJlcyBFQ04gbWFya2luZyB0byBvY2N1ciBubyBlYXJsaWVyIHRo YW4gZHJvcC4gSXQgaXMgcHJlY2lzZWx5IHRoYXQgMzE2OCBkb2VzIG5vdCBhbGxvdyBlYXJseSBt YXJraW5nIHVubGVzcyB0aGVyZSBpcyBhbHNvIGVhcmx5IGRyb3AgdGhhdCBpcyB0aGUgcHJvYmxl bS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBGaXhlZCBpbiBu ZXh0IHJldmlzaW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBEQ1RDUCBiZSBk ZXBsb3llZC4uLjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48YnI+DQo8L3NwYW4+PGJyPg0K JnF1b3Q7cmVjb21tZW5kZWQmcXVvdDsgaXMgdG9vIHdlYWsuIEkgc3VnZ2VzdCB5b3UgdXNlIHNv bWV0aGluZyBsaWtlIHRoZSBhcHBsaWNhYmlsaXR5IHRleHQgZ2l2ZW4gYWJvdmUsIGJvdGggaGVy ZSBhbmQgaW4gdGhlIGFic3RyYWN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmx0O1ByYXZlZW4mZ3Q7IEFkZGVkIHRoZSB3b3JkIOKAnG9ubHnigJ0gdG8gbWFrZSB0aGlzIHN0 cm9uZ2VyIHBlciBNaWNoYWVs4oCZcyByZXZpZXcuIEZpeGVkIGluIG5leHQgcmV2aXNpb24uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bQkJdIEkgc3VnZ2VzdCB0aGUgYXBwbGljYWJpbGl0eSBwYXJhIChoZXJlIGluIHRo ZSBpbnRybykgcmVmZXJzIGZvcndhcmQgdG8gc2VjdGlvbiA1IGZvciBkZXRhaWxzIChlLmcuIHNv IHlvdSBkb24ndCBoYXZlIHRvIGV4cGxhaW4gd2h5IGl0IHNob3VsZG4ndCBiZSBkZXBsb3llZCBp biB0aGUgaW50cm8pLjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+Jmd0OyZndDsgQWRkZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NCjxiPjIuIFRlcm1pbm9s b2d5PGJyPg0KPC9iPjxicj4NClN1Z2dlc3QgeW91IGV4cGxhaW4gdGhhdCBjYXBpdGFsaXNlZCB3 b3JkcyBhcmUgbm90IHF1aXRlIHRoZSBzYW1lIGFzIGluIG1vc3QgUkZDczo8YnI+DQomcXVvdDtO b3JtYXRpdmUgbGFuZ3VhZ2UgaXMgdXNlZCB0byBkZXNjcmliZSBob3cgbmVjZXNzYXJ5IHRoZSB2 YXJpb3VzIGFzcGVjdHMgb2YgdGhlIE1pY3Jvc29mdCBpbXBsZW1lbnRhdGlvbiBhcmUgZm9yIGlu dGVyb3BlcmFiaWxpdHksIGJ1dCBldmVuIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbnMgd2l0aG91 dCB0aGUgbWVhc3VyZXMgaW4gc2VjdGlvbnMgNC02IHdvdWxkIHN0aWxsIG9ubHkgYmUgc2FmZSB0 byBkZXBsb3kgaW4gY29udHJvbGxlZCBlbnZpcm9ubWVudHMuJnF1b3Q7PGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgRmFpciBlbm91Z2guIEFkZGVkIHRleHQgaW4g bmV4dCByZXZpc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8 Yj4zLiBEQ1RDUCBBbGdvPGJyPg0KPC9iPjxicj4NClRoZSB0aHJlZSBidWxsZXRzIHNheSBubyBt b3JlIHRoYW4gJnF1b3Q7dGhpcyBpcyBub3JtYWwgc3R1ZmYmcXVvdDsuIFdvdWxkIGl0IGJlIGJl dHRlciB0byBzdXBwbGVtZW50IGVhY2ggc2VudGVuY2Ugd2l0aCBhIGJyaWVmIHBocmFzZSBzYXlp bmcgd2hhdCBpcyBkaWZmZXJlbnQgYWJvdXQgZWFjaCBhc3BlY3QgY29tcGFyZWQgdG8gUkZDMzE2 OD88YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBUaGUgZ29hbCBo ZXJlIGl0IHRvIGRlc2NyaWJlIHRoZSBjaGFuZ2VzIG5lZWRlZCBvbiB0b3Agb2YgMzE2OCBzbyBJ IGRvbuKAmXQgdGhpbmsgZnVydGhlciBleHBsYW5hdGlvbiBpcyBuZWNlc3NhcnkuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCjxiPjMuMSBNYXJraW5nPGJyPg0KPC9iPjxicj4NClRoaXMgbmVlZHMgdG8g c2F5IHNvbWV0aGluZyBhYm91dCBob3cgeW91IG1hcmsgdGhlIElQIGhlYWRlciBmcm9tIEwyLiBJ IHN1Z2dlc3QgeW91IHJlZmVyIHRvIHRoZSB1cC1hbmQtZm9yd2FyZCBtb2RlIG9mIGRyYWZ0LWll dGYtdHN2d2ctZWNuLWVuY2FwLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1ByYXZl ZW4mZ3Q7IFdoeSBpcyB0aGF0IHJlbGV2YW50IHRvIHRoaXMgZG9jdW1lbnQ/IEl0IGlzIG5vdCBp bnRlbmRlZCBhcyBhIHNwZWNpZmljYXRpb24gZm9yIG9wZXJhdGlvbiBvZiBMMiBzd2l0Y2hlcy4g V29u4oCZdCBmaXguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkJdIFdlbGwsIHlvdSBzcGVjaWZ5IGEgbG90IGFib3V0 IHRoZSBtYXJraW5nIGFsZ28sIGUuZy4gPGJyPg0KSyAmZ3Q7IChSVFQgKiZuYnNwOyBDKS83PGJy Pg0KPGJyPg0KQSBzaW1wbGUgc29sdXRpb24gd291bGQgYmU6IHMvc3dpdGNoL0wzIHN3aXRjaC8g PGJyPg0KPGJyPg0KSSBqdXN0IHRob3VnaHQgdGhhdCBhIHJlYWRlciB3b3VsZCB0aGluaywgJnF1 b3Q7WW91IHNheSBzd2l0Y2hlcyAoaS5lLiBMMiBkZXZpY2VzKSBtYXJrIHRoZSBJUCBoZWFkZXIg LSBob3cgY2FuIHRoYXQgd29yaz8mcXVvdDsgdW5sZXNzIHlvdSBleHBsYWluLjxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPiZndDsmZ3Q7IEZhaXIgZW5vdWdoLCBDaGFuZ2VkIHRvIEwzIHN3 aXRjaGVzIGFuZCByb3V0ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQpzL3NlbmRpbmcgcmF0ZS88YnI+DQombmJzcDsvbGluayByYXRlLzxi cj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1By YXZlZW4mZ3Q7IEZpeGVkIGluIG5leHQgcmV2aXNpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxicj4NCjxiPjMuMiA8YnI+DQo8L2I+PGJyPg0KQ1VSUkVOVDo8bzpwPjwv bzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IDEuJm5ic3A7IElmIHRoZSBDRSBjb2RlcG9pbnQg aXMgc2V0IGFuZCBEQ1RDUC5DRSBpcyBmYWxzZSwgc2VuZCBhbiBBQ0sgZm9yPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFueSBwcmV2 aW91c2x5IHVuYWNrbm93bGVkZ2VkIHBhY2tldHMgYW5kIHNldCBEQ1RDUC5DRSB0byB0cnVlLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyAyLiZuYnNwOyBJZiB0aGUgQ0UgY29kZXBvaW50IGlzIG5vdCBzZXQgYW5kIERDVENQ LkNFIGlzIHRydWUsIHNlbmQgYW4gQUNLPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBhbnkgcHJldmlvdXNseSB1bmFja25vd2xl ZGdlZCBwYWNrZXRzIGFuZCBzZXQgRENUQ1AuQ0UgdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZmFsc2UuPG86cD48L286cD48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U1VHR0VTVEVEOjxvOnA+PC9vOnA+PC9wPg0KPHBy ZT4mbmJzcDsmbmJzcDsgMS4mbmJzcDsgSWYgdGhlIENFIGNvZGVwb2ludCBpcyBzZXQgYW5kIERD VENQLkNFIGlzIGZhbHNlLCBzZXQgRENUQ1AuQ0UgdG8gPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJ1ZSBhbmQgc2VuZCBh biBBQ0sgZm9yIGFueSBwcmV2aW91c2x5IHVuYWNrbm93bGVkZ2VkIHBhY2tldHMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 IDIuJm5ic3A7IElmIHRoZSBDRSBjb2RlcG9pbnQgaXMgbm90IHNldCBhbmQgRENUQ1AuQ0UgaXMg dHJ1ZSwgc2V0IERDVENQLkNFPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGZhbHNlIGFuZCBzZW5kIGFuIEFDSyBmb3IgYW55IHBy ZXZpb3VzbHkgdW5hY2tub3dsZWRnZWQgcGFja2V0cy48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGZpZ3VyZSB3b3VsZCBoYXZlIHRvIGJl IGNoYW5nZWQgdG8gYmUgY29uc2lzdGVudCB0b28uPGJyPg0KUkFUSU9OQUxFOjxicj4NCklmIHRo ZSByZWNlaXZlciBjaGFuZ2VzIERDVENQLkNFIC9hZnRlci8gc2VuZGluZyB0aGUgQUNLIGxpa2Ug dGhpcywgaXQgZGVsYXlzIGVhY2ggc2lnbmFsIHVudGlsIHRoZSBmb2xsb3dpbmcgQUNLIGlzIHNl bnQuIFRoYXQgY291bGQgYWRkIGEgZGVsYXkgb2YgYW55dGhpbmcgZnJvbSAxIHRvIG0gcGFja2V0 cy4gSSd2ZSBuZXZlciB1bmRlcnN0b29kIHdoeSB0aGUgb3JkZXIgb2YgdGhlc2Ugb3BlcmF0aW9u cyB3YXMgc3BlY2lmaWVkIGluIHRoaXMNCiB3YXkuIElmIHRoZXJlIGlzIG5vIHJlYXNvbiwgdGhl biBJIHN1Z2dlc3QgdGhhdCBpdCBpcyBzcGVjaWZpZWQgaW4gdGhlIG9wcG9zaXRlIG9yZGVyLCBh cyBJIGRlc2NyaWJlIGFib3ZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpBIG5vdGUgY291bGQgYmUgYWRkZWQgdG8gc2F5IHRoZSBXaW5kb3dzIFNlcnZlciAxMiBpbXBs ZW1lbnRhdGlvbiBkb2VzIHRoZXNlIHN0ZXBzIGluIHJldmVyc2Ugb3JkZXIsIGJ1dCB0aGUgb3Jk ZXIgc3BlY2lmaWVkIGlzIHByZWZlcnJlZCBiZWNhdXNlIGl0IHJlZHVjZXMgc2lnbmFsbGluZyBk ZWxheSBhbmQgaGFzIG5vIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIHdpdGggdGhlIG9yaWdpbmFs IFdpbmRvd3MgaW1wbGVtZW50YXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBXb27igJl0IGZp eC4gVGhpcyBpcyBob3cgdGhlIFdpbmRvd3MgaW1wbGVtZW50YXRpb24gYmVoYXZlcyBzbyB0aGUg b3JkZXJpbmcgaXMgcmVxdWlyZWQuIEJvdGggdGhlIHBhcGVyIGFuZCB0aGUgZHJhZnQgYXJlIGNv bnNpc3RlbnQgaW4gdGhpcy4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JCXSBUaGUgcGFwZXIgYW5kIHRoZSBkcmFm dCBhcmUgbm90IGNvbnNpc3RlbnQuIEluIHRoZSBkcmFmdCwgdGhlIGxhYmVscyBvbiB0aGUgdG9w IGFuZCBib3R0b20gYXJyb3dzIGluIHRoZSBkaWFncmFtIGhhdmUgYmVlbiBzd2l0Y2hlZCByb3Vu ZCByZWxhdGl2ZSB0byB0aG9zZSBpbiB0aGUgcGFwZXIuDQo8YnI+DQo8YnI+DQpIb3dldmVyLCB0 aGUgdGV4dCBpbiB0aGUgZHJhZnQgaGFzIG5vdCAoeWV0PykgYmVlbiBjaGFuZ2VkIHRvIHJlZmxl Y3QgdGhpcy4gPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBubyBkZWxheSBiZWlu ZyBpbnRyb2R1Y2VkIGhlcmUuIFRoaXMgQUNLIGlzIHNlbnQgaW1tZWRpYXRlbHkgc28gdGhlIG9y ZGVyIGRvZXMgbm90IG1hdHRlci4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KW0JCXSBJIGFncmVlIHRoYXQg dGhlIEFDSyBpdHNlbGYgaXMgbm90IGRlbGF5ZWQuIEhvd2V2ZXIsIGV2ZW4gdGhvIGEgQ0UgaGFz IGJlZW4gcmVjZWl2ZWQsIGZlZWRiYWNrIG9mIHRoaXMgZXZlbnQgaXMgaGVsZCBiYWNrIHVudGls IHRoZSBuZXh0IEFDSy4NCjxicj4NCjxicj4NClRoaXMgaXMgYSBtaW5vciAndW5uZWNlc3Nhcnkg ZGVsYXknIGJ1Zy4gPGJyPg0KKiBJIGJlbGlldmUgaXQgd2FzIGZpeGVkIGluIHRoZSBGcmVlQlNE IGltcGxlbWVudGF0aW9uIGFmdGVyIEkgcG9pbnRlZCBpdCBvdXQuIDxicj4NCiogSSd2ZSBqdXN0 IGNoZWNrZWQgdGhlIExpbnV4IGNvZGUsIGFuZCBpdCdzIG5vdCBiZWVuIGZpeGVkIHRoZXJlLiA8 YnI+DQoqIE9idmlvdXNseSBJIGNhbm5vdCBzZWUgdGhlIFdpbmRvd3Mgc291cmNlIGNvZGUuIDxi cj4NCjxicj4NCklmIHRoaXMgYnVnIGlzIHN0aWxsIGluIHRoZSBXaW5kb3dzIGltcGxlbWVudGF0 aW9uLCBpdCdzIHVwIHRvIHlvdSBpZiB5b3UgYWxzbyB3YW50IHRoZSBzcGVjIHRvIHJlcXVpcmUg dGhhdCB0aGUgYnVncyBhcmUgaW1wbGVtZW50ZWQgZXhhY3RseSBhcyB0aGV5IGFyZSBpbiBXaW5k b3dzIDspPGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jmd0OyZndDsgVGhlcmUgYXJlIHR3 byBzZXBhcmF0ZSBpc3N1ZXMgaGVyZS4gT25lIGlzIHRoYXQgdGhlIHBhY2tldCB0aGF0IHRyaWdn ZXJzIHRoZSBDRSBzdGF0ZSB0byBjaGFuZ2UgbXVzdCBpdHNlbGYgbm90IGJlIGFjY291bnRlZCBm b3IgaW4gdGhlIGltbWVkaWF0ZSBBQ0suIEkgdGhpbmsgdGhlIHRleHQgbWFrZXMgdGhpcyBjbGVh ciB3aXRoIHRoZSB1c2Ugb2YgdGhlDQogd29yZCDigJxwcmV2aW91c2x5IDwvc3Bhbj51bmFja25v d2xlZGdlZCBwYWNrZXRz4oCdLiBJIGFtIGFkZGluZyBhIHNlbnRlbmNlIHRvIGVuc3VyZSB0aGF0 IHRoaXMgaXMgaW50ZXJwcmV0ZWQgY29ycmVjdGx5IG90aGVyd2lzZSB0aGVyZSBjYW4gYmUgYSBj aGFuZ2UgaW4gaG93IGFscGhhIGlzIGNvbXB1dGVkIGlmIHRoZSBwYWNrZXQgd2FzIGEgZGF0YSBw YWNrZXQuIFRoZSBvdGhlciBpc3N1ZSBpcyB0aGF0IHRoZSB0cmFuc2l0aW9uIHBhY2tldCBpdHNl bGYNCiB3aWxsIG5vdCBiZSBBQ0tlZCBpbW1lZGlhdGVseSBhbmQgSSBkb27igJl0IHNlZSB0aGF0 IGFzIGFuIGlzc3VlLiBXaXRoIGRhdGEgY2VudGVyIGxhdGVuY2llcyBhbmQgdGhlIGd1aWRhbmNl IGFyb3VuZCB1c2luZyBhIHNob3J0IGRlbGF5ZWQgQUNLIHRpbWVvdXQgdGhlIHVubmVjZXNzYXJ5 IGRlbGF5IGlzIG5vdCBhIGJpZyBpc3N1ZS4gQWxzbywgdGhlIGRlbGF5IGlzIG9ubHkgcHJlc2Vu dCBpZiB0aGVyZSBhcmUgbm8gc3Vic2VxdWVudCBwYWNrZXRzDQogb2YgdGhlIGZsb3cgaW4gZmxp Z2h0IHdoaWNoIHNob3VsZCBiZSByYXJlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IFRoZSBoYW5kbGluZyBvZiB0aGUgJnF1b3Q7Q29uZ2VzdGlvbiBXaW5kb3cg UmVkdWNlZCZxdW90OyAoQ1dSKSBiaXQgaXMgYWxzbzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyBleGFjdGx5IGFzIHBlciBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9y ZyUyZmh0bWwlMmZyZmMzMTY4JmFtcDtkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9Q2U5bTVxMFh6a2JRTldFYjFycW1YcnF4MTJV ZjRMRHNjclVBejVDNzhlWSUzZCIgdGl0bGU9IiZxdW90O1RoZSBBZGRpdGlvbiBvZiBFeHBsaWNp dCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB0byBJUCZxdW90OyI+UkZDMzE2ODwvYT5d IGluY2x1ZGluZyBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFm dC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtUkZDMzE2OC1FUlJBVEEzNjM5JmFtcDtkYXRhPTAx JTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4ZDJl NmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9 d0RKdiUyYmN5cFhqNWxheWZ6dlFHaFhZcUI2a3dsOGxXJTJmcGRRNGlZZzJjTjglM2QiPlJGQzMx NjgtRVJSQVRBMzYzOTwvYT5dLiZuYnNwOyBUaGF0IGlzLCBvbjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyByZWNlaXB0IG9mIGEgc2VnbWVudCB3aXRoIGJvdGggdGhlIENFIGFu ZCBDV1IgYml0cyBzZXQsIENXUiBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBwcm9jZXNzZWQgZmlyc3QgYW5kIHRoZW4gRUNFIGlzIHByb2Nlc3NlZC48bzpwPjwvbzpwPjwv cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5FdmVuIHRobyB0aGlzIGlzIHRoZSByZWNlaXZl ciBzZWN0aW9uLCBJIHN1Z2dlc3Q6PGJyPg0Kcy9UaGUgaGFuZGxpbmcvUmVjZWl2ZXIgaGFuZGxp bmcvPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgSXNu4oCZdCB0 aGlzIGFzc3VtZWQgYnkgYSByZWFkZXIgZmFtaWxpYXIgd2l0aCAzMTY4PyBCdXQgdGhpcyBpcyBh IG1pbm9yIGVkaXRvcmlhbCBmaXggc28gZml4ZWQgaW4gdGhlIG5leHQgcmV2aXNpb24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpXaGF0ZXZlciwg dGhpcyBjYW5ub3QgYmUgY29ycmVjdC4gQSBEQ1RDUCByZWNlaXZlciBzdXJlbHkgZG9lcyBub3Ro aW5nIG9uIHJlY2VpcHQgb2YgQ1dSLCB3aGVyZWFzIGFuIFJGQzMxNjggcmVjZWl2ZXIgZG9lcyBz b21ldGhpbmcuIEEgRENUQ1AgcmVjZWl2ZXIgY2VydGFpbmx5IGNhbm5vdCBkbyBleGFjdGx5IHdo YXQgUkZDMzE2OCBzYXlzLCBiZWNhdXNlIHRoYXQgc2F5cyBzdG9wIHNldHRpbmcgRUNFIG9uIHJl Y2VpcHQgb2YgQ1dSIHVudGlsDQogdGhlIG5leHQgQ0UgYXJyaXZlcywgd2hpY2ggd291bGQgc3Vy ZWx5IGJyZWFrIHRoaXMgZmVlZGJhY2sgcHJvdG9jb2wuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbHQ7UHJhdmVlbiZndDsgSSBkb27igJl0IHNlZSB3aHkgdGhpcyB3b3VsZCBicmVhayB0 aGUgZmVlZGJhY2sgcHJvdG9jb2wuIFRoZSByZWNlaXZlciB3aWxsIHN0YXJ0IGVjaG9pbmcgYWdh aW4gYXMgc29vbiBhcyBpdCBzZWVzIHRoZSBmaXJzdCBDRSBhcnJpdmVzIGFnYWluLg0KIElmIHBh Y2tldCBoYXMgYm90aCBDV1IgYW5kIENFIHNldCB0aGVuIENFIHRha2VzIHByZWNlZGVuY2UgYW5k IHRoZSBlY2hvaW5nIGlzIGRvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bQkJdIEknbSBub3Qgc2F5aW5nIGl0IGJy ZWFrcyB0aGUgZmVlZGJhY2sgcHJvdG9jb2wuIEknbSBqdXN0IHNheWluZyBpdCdzIGNvbmZ1c2lu ZyBmb3IgdGhlIHJlYWRlci48YnI+DQo8YnI+DQpPZiBjb3Vyc2UsIHdoZW4gdGhlIHJlY2VpdmVy IGlzIGFscmVhZHkgbm90IGRvaW5nIHNvbWV0aGluZywgaWdub3JpbmcgYSBzaWduYWwgdG8gc3Rv cCBoYXMgdGhlIHNhbWUgb3V0Y29tZSBhcyBzdG9wcGluZy4gSG93ZXZlciwgZGVzY3JpYmluZyB0 aGlzIGFzICZxdW90O2hhbmRsaW5nIENXUiAuLi4gaXMgYWxzbyBleGFjdGx5IGFzIHBlciBSRkMz MTY4JnF1b3Q7IGlzIG1pc2xlYWRpbmcgZm9yIHRoZSByZWFkZXIvaW1wbGVtZW50ZXIuPGJyPg0K PGJyPg0KSSBndWVzcyBjaGFuZ2luZyB0byAmcXVvdDtoYW5kbGluZyBDV1IgLi4uIGlzIGFzIHBl ciBSRkMzMTY4JnF1b3Q7IHdvdWxkIGJlIGEgY29tcHJvbWlzZS48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+Jmd0OyZndDsgRml4ZWQgdGhpcyB0byByZW1vdmUg4oCc ZXhhY3RseeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxicj4NCjxiPjMuMyA8L2I+PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwO0RDVENQLkFscGhhLCB3aGljaCBpcyBpbml0aWFsaXplZCB0byAxIGFuZCBNVVNU IGJlIHVwZGF0ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXMgZm9sbG93 czo8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zL01VU1QvU0hPVUxE Lzxicj4NCkFuZCBhZGQgJnF1b3Q7QW4gYWx0ZXJuYXRpdmUgY29uZ2VzdGlvbiBhdm9pZGFuY2Ug YWxnb3JpdGhtIE1BWSBiZSB1c2VkLCBidXQgaXQgTVVTVCBsZWFkIHRvIGZsb3cgcmF0ZSBpbnZl cnNlbHkgcHJvcG9ydGlvbmFsIHRvIDEvTSZxdW90Oy48YnI+DQo8YnI+DQpSYXRpb25hbGU6IFRo ZXJlIGFyZSBtYW55IHdheXMgdG8gaW1wbGVtZW50IGludGVyb3BlcmFibGUgMS9wIGNjLiBUaGlz IGlzIGp1c3Qgb25lLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7UHJh dmVlbiZndDsgQWx0ZXJuYXRlIGFsZ29yaXRobXMgYXJlIG91dCBvZiBzY29wZSBvZiB0aGlzIGRy YWZ0LiBXZSBjYW5ub3Qgc2F5IHdpdGhvdXQgaW50ZXJvcCB0ZXN0aW5nIGlmIGEgZGlmZmVyZW50 IGFsZ29yaXRobSB3aWxsIHBlcmZvcm0gd2VsbCBpbiBkYXRhY2VudGVycw0KIG9yIGludGVyb3Ag d2VsbCB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4gSWYgdGhlcmUgYXJlIG90aGVyIHdh eXMgdG8gaW1wbGVtZW50IDEvcCB0aGV5IHNob3VsZCBiZSBjb3ZlcmVkIGJ5IG90aGVyIGRyYWZ0 cy4gVGhpcyBkcmFmdCB3aWxsIG9ubHkgZGVzY3JpYmUgdGhlIGFsZ29yaXRobSB0aGF0IGhhcyBi ZWVuIHRlc3RlZCBhbmQgZGVwbG95ZWQuIFRoYXQgc2FpZCBJIGFtIHdpbGxpbmcgdG8gbWFrZSBp dCBhIFNIT1VMRCBzbyBmaXhlZA0KIGluIHRoZSBuZXh0IHJldmlzaW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwcmU+Jm5ic3A7Jm5ic3A7IERDVENQLkJ5dGVzU2VudDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPlRoaXMgdmFyaWFibGUgYWN0dWFsbHkgY291bnRzIGJ5dGVzIHJlY2VpdmVk LiBpdCdzIHByZXR0eSBjb25mdXNpbmcgdG8gY2FsbCBpdCBCeXRlc1NlbnQuPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgTm8sIHRoaXMgaXMgdHJhY2tpbmcgYnl0ZXMgdGhh dCBoYXZlIGJlZW4gc2VudC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W0JCXSBJIG1lYW50IGl0IGNvdW50cyBieXRl cyBub3cgYWNrbm93bGVkZ2VkIGFzIHJlY2VpdmVkIGJ5IHRoZSBvdGhlciBlbmQgKHdoaWNoIGlz IG5vdCB0aGUgc2FtZSBhcyBieXRlcyBzZW50IGJ5IHRoaXMgZW5kKS4NCjxicj4NCkRDVENQLkJ5 dGVzQWNrZWQgd291bGQgaGF2ZSBiZWVuIG1vcmUgbWVhbmluZ2Z1bC4gSSdtIG5vdCBpbnNpc3Rp bmcgb24gdGhpcyAtIHRoZSBvcmlnaW5hbCBjb21tZW50IHdhcyBqdXN0IHRvIGltcHJvdmUgY29t cHJlaGVuc2liaWxpdHkuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPiZndDsmZ3Q7Jm5ic3A7IEZhaXIgZW5vdWdoIG5vdyBJIHNlZSB3aGF0IHlvdSBtZWFu dC4gVXBkYXRpbmcgdG8gQnl0ZXNBY2tlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0Kcy9UQ1AgU0FDSyBvcHRp b25zIFtSRkMyMDE4XSBhcmUgaWdub3JlZC4vPGJyPg0KJm5ic3A7L1RoZSBzZW5kZXIgTVVTVCBp Z25vcmUgVENQIFNBQ0sgb3B0aW9ucyBbUkZDMjAxOF0gZm9yIHRoaXMgY29tcHV0YXRpb24uLzxi cj4NClJBVElPTkFMRTogPGJyPg0KJm5ic3A7IGEpIEkgdGhpbmsgdGhlIGlkZWEgaXMgdG8gaWdu b3JlIENFIG1hcmtzIGFmdGVyIGEgZ2FwIGJlY2F1c2UsIGlmIHRoZSBnYXAgYmVjb21lcyBjb25z aWRlcmVkIGEgbG9zcywgdGhlIHJlc3BvbnNlIHRvIGxvc3Mgd2lsbCBvdmVycmlkZSBhbnkgbmVl ZCB0byBjb3VudCBpbmNvbWluZyBDRSBtYXJrcyBmb3IgdGhlIGZvbGxvd2luZyByb3VuZCB0cmlw LiBIb3dldmVyLCBpZiB0aGUgZ2FwIGlzIGZpbGxlZCBiZWZvcmUgaXQgaXMgY29uc2lkZXJlZA0K IGEgbG9zcyB7Tm90ZSAxfSwgdGhlbiBDRSBtYXJrcyB0aGF0IHdlcmUgaWdub3JlZCBiZWNhdXNl IHRoZXkgYXJyaXZlZCBhZnRlciBhIGdhcCB3aWxsIG5lZWQgdG8gYmUgJnF1b3Q7dW5pZ25vcmVk JnF1b3Q7Lg0KPGJyPg0KJm5ic3A7IGIpIFdlIG5lZWQgdG8gbWFrZSBjbGVhciB0aGF0IFNBQ0sg aXMgbm90IGlnbm9yZWQgYWx0b2dldGhlciwgb25seSBmb3IgdGhpcyBjb21wdXRhdGlvbi48YnI+ DQo8YnI+DQp7Tm90ZSAxfTogSSBjYW4gdGhpbmsgb2YgdHdvIGNhc2VzOjxicj4NCiogTGVzcyB0 aGFuIHRocmVlIGR1cGFja3MgdGhlbiB0aGUgZ2FwIGlzIGZpbGxlZDxicj4NCiogVGhlIGdhcCBp cyBmaWxsZWQgYnkgYSBkZWxheWVkIHNlZ21lbnQgc28gdGhhdCBhbiBlYXJsaWVyIHJldHJhbnNt aXNzaW9uIHdhcyBzcHVyaW91czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1ByYXZlZW4mZ3Q7IE9rIEkgd2lsbCB1cGRhdGUg dGhlIHRleHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHByZT50aGUgc2VuZGVyIE1VU1QgdXBkYXRlIGN3bmQgYXMgZm9sbG93czo8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY3du ZCA9IGN3bmQgKiAoMSAtIERDVENQLkFscGhhIC8gMik8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5zL01VU1QvU0hPVUxELzxicj4NClJhdGlvbmFsZTogQWx0ZXJuYXRp dmUgaW50ZXJvcGVyYWJsZSByZXNwb25zZSBmdW5jdGlvbnMgYXJlIHBvc3NpYmxlLiBGb3IgaW5z dGFuY2UgYW4gYWxnb3JpdGhtIGxpa2UgUmVsZW50bGVzcyBUQ1AgdGhhdCBzaW1wbHkgcmVkdWNl cyBjd25kIGJ5IGhhbGYgdGhlIHNpemUgb2YgYW55IENFLW1hcmtlZCBzZWdtZW50LiBUaGVuIHRo ZXJlIGlzIG5vIEFscGhhIGFuZCBubyBnIHZhcmlhYmxlLjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1ByYXZlZW4mZ3Q7IEZpeGVkPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpDVVJSRU5UOjxvOnA+PC9vOnA+ PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSnVzdCBhcyBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmdG9vbHMuaWV0Zi5vcmclMmZodG1sJTJmcmZjMzE2OCZhbXA7ZGF0YT0wMSU3YzAxJTdj cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdjYTU3MmIwYmE4ZTFiNDdkM2U0NGEwOGQyZTZkN2UwM2Yl N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUNlOW01cTBY emtiUU5XRWIxcnFtWHJxeDEyVWY0TERzY3JVQXo1Qzc4ZVklM2QiIHRpdGxlPSImcXVvdDtUaGUg QWRkaXRpb24gb2YgRXhwbGljaXQgQ29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gSVAm cXVvdDsiPlJGQzMxNjg8L2E+XSwgVENQIHNob3VsZCBub3QgcmVhY3QgdG8gY29uZ2VzdGlvbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbmRpY2F0aW9ucyBtb3JlIHRoYW4g b25jZSBmb3IgZXZlcnkgd2luZG93IG9mIGRhdGEuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+U1VHR0VTVEVEOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJz cDsgSnVzdCBhcyBzcGVjaWZpZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmdG9vbHMuaWV0Zi5vcmcl MmZodG1sJTJmcmZjMzE2OCZhbXA7ZGF0YT0wMSU3YzAxJTdjcHJhdmIlNDBtaWNyb3NvZnQuY29t JTdjYTU3MmIwYmE4ZTFiNDdkM2U0NGEwOGQyZTZkN2UwM2YlN2M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUNlOW01cTBYemtiUU5XRWIxcnFtWHJxeDEyVWY0 TERzY3JVQXo1Qzc4ZVklM2QiIHRpdGxlPSImcXVvdDtUaGUgQWRkaXRpb24gb2YgRXhwbGljaXQg Q29uZ2VzdGlvbiBOb3RpZmljYXRpb24gKEVDTikgdG8gSVAmcXVvdDsiPlJGQzMxNjg8L2E+XSwg RENUQ1AgZG9lcyBub3QgcmVhY3QgdG8gY29uZ2VzdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBpbmRpY2F0aW9ucyBtb3JlIHRoYW4gb25jZSBmb3IgZXZlcnkgd2luZG93 IG9mIGRhdGEuPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkb24n dCBrbm93IHdoZXRoZXIgeW91IGludGVuZGVkIHRoaXMgdG8gYmUgYW4gdXBwZXItY2FzZSBTSE9V TEQgTk9ULiBJZiBzbywgSSB3b3VsZCBhcmd1ZSBhZ2FpbnN0IHRoaXMgYmVpbmcgbm9ybWF0aXZl LCBiZWNhdXNlIGl0IGlzbid0IG5lY2Vzc2FyeSBmb3IgaW50ZXJvcDsgdGhlcmVmb3JlIEkndmUN CiBzdWdnZXN0ZWQgYXZvaWRpbmcgaGUgJ3Nob3VsZCcgd29yZC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPiZsdDtQcmF2 ZWVuJmd0OyBGaXhlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cHJlPiZuYnNwOyZuYnNwOyBUaGUgc2V0dGluZyBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyB0aGUgJnF1b3Q7Q29uZ2VzdGlvbiBXaW5kb3cgUmVkdWNlZCZxdW90OyAoQ1dS KSBiaXQgaXMgYWxzbyBleGFjdGx5IGFzIHBlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZyZmMzMTY4 JmFtcDtkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0 N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZhbXA7c2RhdGE9Q2U5bTVxMFh6a2JRTldFYjFycW1YcnF4MTJVZjRMRHNjclVBejVDNzhlWSUz ZCIgdGl0bGU9IiZxdW90O1RoZSBBZGRpdGlvbiBvZiBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlm aWNhdGlvbiAoRUNOKSB0byBJUCZxdW90OyI+UkZDMzE2ODwvYT5dLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCBpcyB3cm9uZyB0byBzYXkgJnF1b3Q7ZXhhY3RseSZx dW90Oy4gVGhlIHNlbmRlciBjZXJ0YWlubHkgc2V0cyBDV1Igd2hlbiBpdCBkb2VzIGEgY29uZ2Vz dGlvbiByZXNwb25zZS4gQnV0IGluIERDVENQIHRoZSBjb25nZXN0aW9uIHJlc3BvbnNlIG9jY3Vy cyBldmVyeSBSVFQsIHRyaWdnZXJlZCBieSBpdHMgb3duIG1lYXN1cmVtZW50LXBlcmlvZA0KIGxv Z2ljLCB3aGVyZWFzIGluIFJGQzMxNjggaXQgaXMgdHJpZ2dlcmVkIGJ5IHRoZSBhcnJpdmFsIG9m IGFuIEVDRSBhZnRlciB0aGUgQUNLIG9mIGFueSBwcmV2aW91cyBzZWdtZW50IGl0IHNlbnQgd2l0 aCBDV1Igc2V0Ljxicj4NCjxicj4NCkkgdGhpbmsgaXQgaXMgd29ydGggc2F5aW5nIHRoYXQgc2V0 dGluZyBDV1IgaXMgbmVjZXNzYXJ5IGZvciBzYWZldHksIG90aGVyd2lzZSBpbiB0aGUgY2FzZSB3 aGVyZSB0aGVyZSBoYXMgYmVlbiBhIGNvbmZpZ3VyYXRpb24gbWFuYWdlbWVudCBlcnJvciBhbmQg dGhlIHJlY2VpdmVyIGNvbXBsaWVzIHdpdGggUkZDIDMxNjggbm90IERDVENQLCBpdCB3aWxsIGNv bnRpbnVlIHNlbmRpbmcgRUNFIGZvciBldmVyIGFuZCBzdGFydmUgdGhlIHNlc3Npb24uPGJyPg0K PGJyPg0KSXQgbWlnaHQgaGVscCB0byBleHBsaWNpdGx5IGNvbmZpcm0gdGhhdDogPGJyPg0KJnF1 b3Q7T3RoZXIgYXNwZWN0cyBvZiBUQ1AgY29uZ2VzdGlvbiBhdm9pZGFuY2UgYW5kIGNvbnRyb2wg c3VjaCBhcyB0aGUgc2xvdyBzdGFydCBwaGFzZSBhcmUgbm8gZGlmZmVyZW50IHRvIHRob3NlIGlu IFJGQzU2ODEuJnF1b3Q7PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgRml4ZWQgdGhhdCBDV1IgaXMgbmVlZGVkIGZvciBz YWZldHkuIE5vdCBhZGRpbmcgdGhlIHRleHQgYXJvdW5kIDU2ODEsIGl0IGlzIHByZXN1bWVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KPGI+My40IFNZTiwgU1lOLUFDSywgUlNUPGJyPg0KPC9iPjxicj4N Cjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFtSRkMzMTY4 XSByZXF1aXJlcyB0aGF0IGEgY29tcGxpYW50IFRDUCBNVVNUIE5PVCBzZXQgRUNUIG9uIFNZTiBv cjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IFNZTi1B Q0sgcGFja2V0cy48L3R0Pjxicj4NCjwvc3Bhbj48YnI+DQpzL01VU1QgTk9ULydNVVNUIE5PVCcv PGJyPg0KUmF0aW9uYWxlOiBCZXN0IHRvIG1ha2UgaXQgY2xlYXIgdGhpcyBpcyBxdW90aW5nIGEg bm9ybWF0aXZlIHN0YXRlbWVudCBpbiBhbm90aGVyIFJGQywgYmVjYXVzZSBpdCBpcyBnb2luZyB0 byBiZSBjb250cmFkaWN0ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQl0gSSBkb24ndCBrbm93IHdoZXRoZXIgeW91IHNhdyB0 aGlzIG9uZSAtIGl0J3Mgbm90IGJlZW4gY2hhbmdlZCBpbiBkcmFmdC0wMi48YnI+DQo8YnI+DQpJ IHN1Z2dlc3RlZCBhZGRpbmcgcXVvdGVzIGFyb3VuZCAnTVVTVCBOT1QnLiBUaGlzIGlzIGdvb2Qg cHJhY3RpY2Ugd2hlbiBxdW90aW5nIGFub3RoZXIgUkZDLiBPdGhlcndpc2UsIHRvIGEgY2FyZWxl c3MgcmVhZGVyIChvciBub24tbmF0aXZlIEVuZ2xpc2ggc3BlYWtlciksIGl0IGNhbiBsb29rIGxp a2UgaXQgaXMgYWxzbyBhIHJlcXVpcmVtZW50IG9mIHRoaXMgUkZDLjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7Jmd0OyBDaGFuZ2VkIHRvIGxvd2Vy IGNhc2Ugc28gYXMgdG8gbm90IGJlIG1pc2xlYWRpbmcgYXJvdW5kIGJlaW5nIGFuIGFzayBvZiB0 aGlzIFJGQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCkNVUlJFTlQ8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRo ZXNlIFJGQ3MsIGhvd2V2ZXIsIGFyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBpbnRlbmRlZCBmb3IgZ2VuZXJhbCBJbnRlcm5ldCB1c2UsIGFuZCBkbyBub3QgZGlyZWN0bHkg YXBwbHkgdG8gYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjb250cm9sbGVk IGRhdGFjZW50ZXIgZW52aXJvbm1lbnQuPG86cD48L286cD48L3ByZT4NCjxwcmU+Li4uPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEZvciBEQ1RDUCBjb25uZWN0aW9ucywgdGhl IHNlbmRlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTSE9VTEQgc2V0IEVD VCBmb3IgU1lOLCBTWU4tQUNLIGFuZCBSU1QgcGFja2V0cy48bzpwPjwvbzpwPjwvcHJlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5TVUdHRVNURUQ6PGJyPg0KPGJyPg0KPHR0PjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgQWxzbywgYSBTWU4gaXMgc2VudCBiZWZv cmUgdGhlIEVDTi1jYXBhYmlsaXR5IGhhcyBiZWVuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYi Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgbmVnb3RpYXRlZCwgc28gaWYgaXQgaXMgQ0UtbWFya2Vk LCBhIG5vbi1FQ04gVENQIHNlcnZlciB3b3VsZCBub3Q8L3R0Pjxicj4NCjx0dD4mbmJzcDsmbmJz cDsgcmVjb2duaXNlIHRoZSBtYXJraW5nLiBSRkMgMzE2OCBkb2VzIG5vdCBzcGVjaWZ5IHRoZSBF Q04gZmllbGQgb24gPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGEgUlNULiBUaGUgc2VjdXJp dHkgY29uY2VybnMgYWRkcmVzc2VkIGJ5IHRoZXNlIFJGQ3MgPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IG1pZ2h0IG5vdCBhcHBseSBpbiBjb250cm9sbGVkIGVudmlyb25tZW50cyBsaWtlIGRh dGEgY2VudHJlcywgYW5kIDwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpdCBtaWdodCBub3Qg YmUgbmVjZXNzYXJ5IHRvIGNhdGVyIGZvciB0aGUgcHJlc2VuY2Ugb2Ygbm9uLUVDTiA8L3R0Pjxi cj4NCjx0dD4mbmJzcDsmbmJzcDsgc2VydmVycy48L3R0Pjxicj4NCjx0dD4uLi48L3R0Pjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZXJlZm9yZSwgdGhlIHNlbmRl ciBNVVNUIHNldCBFQ1QgZm9yIFNZTi9BQ0sgYW5kIFJTVCBwYWNrZXRzIGFuZCBhIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO2NvbmZpZ3VyYXRpb24gb3B0aW9uIFNI T1VMRCBiZSBwcm92aWRlZCB0byBzZXQgRUNUIGZvciBTWU5zLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlJBVElPTkFMRTo8YnI+DQombmJzcDsmbmJzcDsgVGhlIGRy YWZ0IHNob3VsZCBhdm9pZCBhc3N1bWluZyB0aGF0IHNlY3VyaXR5IGNvbmNlcm5zIGRvIG5vdCBh cHBseSBpbiBhbGwgY29udHJvbGxlZCBlbnZpcm9ubWVudHMuPGJyPg0KTk9URTo8YnI+DQombmJz cDsmbmJzcDsgVGhpcyBtaWdodCBub3QgcmVmbGVjdCB0aGUgd2F5IHlvdXIgaW1wbGVtZW50YXRp b24gaXMgY29kZWQsIHNvIHlvdSBtaWdodCB3YW50IHRvIG1ha2UgdGhhdCBjbGVhci48YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBBZGRpbmcgc29tZSB0ZXh0IGFy b3VuZCBzZWN1cml0eSBjb25jZXJucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltCQl0gVGhlIHNlY3VyaXR5IHNlbnRl bmNlIHlvdSBoYXZlIGFkZGVkIGluIGRyYWZ0LTAyIGRvZXNuJ3QgbWFrZSBzZW5zZSB3aGVyZSBp dCBpcy4gSXQgb3VnaHQgdG8gaGF2ZSBiZWVuIGFkZGVkIG9uY2Ugc2VudGVuY2UgZWFybGllciAo YW5kIGl0IHdvdWxkIGJlIGJldHRlciB0byBzdGFydCBhIG5ldyBwYXJhKS4gU3BlY2lmaWNhbGx5 Ojxicj4NCkNVUlJFTlQ6PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgZHJvcHBlZCB3aXRoIGhpZ2ggcHJv YmFiaWxpdHkuJm5ic3A7IEZvciBEQ1RDUCBjb25uZWN0aW9ucywgdGhlIHNlbmRlciZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxicj4NCjx0dD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0hPVUxEIHNldCBFQ1QgZm9yIFNZTiwgU1lOLUFD SyBhbmQgUlNUIHBhY2tldHMuJm5ic3A7IFRoZSBzZWN1cml0eSZuYnNwOyZuYnNwOyZuYnNwOw0K PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGNvbmNlcm5zIGFkZHJlc3NlZCBieSBi b3RoIHRoZXNlIFJGQ3MgbWlnaHQgbm90IGFwcGx5IGluIGNvbnRyb2xsZWQmbmJzcDsmbmJzcDsm bmJzcDsNCjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBlbnZpcm9ubWVudHMgbGlr ZSBkYXRhY2VudGVycywgYW5kIGl0IG1pZ2h0IG5vdCBiZSBuZWNlc3NhcnkgdG8gY2F0ZXImbmJz cDsmbmJzcDsmbmJzcDsNCjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyB0byBib3Ro IHRoZSBwcmVzZW5jZSBvZiBub24tRUNOIHNlcnZlcnMuPC90dD48YnI+DQo8L3NwYW4+U1VHR0VT VEVEOjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGRyb3BwZWQgd2l0aCBoaWdoIHByb2JhYmlsaXR5LiZu YnNwOw0KPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPjxicj4NCjx0dD4mbHQ7TkVXIFBBUkEm Z3Q7PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBz ZWN1cml0eSBjb25jZXJucyBhZGRyZXNzZWQgYnkgYm90aCB0aGVzZSBSRkNzIG1pZ2h0IG5vdCBh cHBseSBpbiBjb250cm9sbGVkJm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3R0Pjxicj4NCjx0dD4mbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsgZW52aXJvbm1lbnRzIGxpa2UgZGF0YWNlbnRlcnMsIGFuZCBpdCBtaWdo dCBub3QgYmUgbmVjZXNzYXJ5IHRvIGNhdGVyJm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3R0Pjxicj4N Cjx0dD4mbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgZm9yIHRoZSBwcmVzZW5jZSBvZiBub24tRUNOIHNlcnZl cnMuIEZvciBEQ1RDUCBjb25uZWN0aW9ucywgdGhlIHNlbmRlciZuYnNwOyZuYnNwOyZuYnNwOw0K PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNIT1VMRCBz ZXQgRUNUIGZvciBTWU4sIFNZTi1BQ0sgYW5kIFJTVCBwYWNrZXRzLiZuYnNwOyA8L3R0Pjwvc3Bh bj48YnI+DQo8YnI+DQooTm90ZSBJIGFsc28gZml4ZWQgYSBnbGl0Y2ggYWZ0ZXIgJnF1b3Q7Y2F0 ZXImcXVvdDsuKTxicj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 Ij4mZ3Q7Jmd0OyBGaXhlZCB0eXBvcyBidXQgcmVtb3ZlZCBzZWN1cml0eSBpbXBsaWNhdGlvbnMg ZnJvbSB0aGlzIHNlY3Rpb24gYW5kIG1vdmVkIHRoZW0gaW50byBzZWN0aW9uIDggKHNlY3VyaXR5 KS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K PGI+NC4gSW1wbGVtZW50YXRpb24gSXNzdWVzPGJyPg0KPC9iPjxicj4NCkNVUlJFTlQ6PG86cD48 L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgaW1wbGVtZW50YXRpb24gTVVTVCBjaG9v c2UgYSBzdWl0YWJsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBlc3RpbWF0 aW9uIGdhaW4uJm5ic3A7IFs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUy ZmRyYWZ0LWlldGYtdGNwbS1kY3RjcC0wMSUyM3JlZi1EQ1RDUDEwJmFtcDtkYXRhPTAxJTdjMDEl N2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4ZDJlNmQ3ZTAz ZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9MzNkUlVV eHlOYTJ0Y1gweEp0TWwxMm5Xd3pJZEhaYTZqM2tnQUwxZHhJTSUzZCIgdGl0bGU9IiZxdW90O0Rh dGEgQ2VudGVyIFRDUCAoRENUQ1ApJnF1b3Q7Ij5EQ1RDUDEwPC9hPl0gcHJvdmlkZXMgYSB0aGVv cmV0aWNhbCBiYXNpcyA8bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5T VUdHRVNUOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIGltcGxlbWVudGF0 aW9uIHdpbGwgbmVlZCB0byBjaG9vc2UgYSBzdWl0YWJsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBlc3RpbWF0aW9uIGdhaW4uJm5ic3A7IFs8YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnRv b2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWlldGYtdGNwbS1kY3RjcC0wMSUyM3JlZi1EQ1RD UDEwJmFtcDtkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThl MWI0N2QzZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdjMSZhbXA7c2RhdGE9MzNkUlVVeHlOYTJ0Y1gweEp0TWwxMm5Xd3pJZEhaYTZqM2tnQUwxZHhJ TSUzZCIgdGl0bGU9IiZxdW90O0RhdGEgQ2VudGVyIFRDUCAoRENUQ1ApJnF1b3Q7Ij5BRENUQ1Ax MDwvYT5dIHByb3ZpZGVzIGEgdGhlb3JldGljYWwgYmFzaXMgLi4uPG86cD48L286cD48L3ByZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+UkFUSU9OQUxFOjxicj4NCiZuYnNwOyZuYnNwOyBhKSBBcyBhYm92 ZSwgdGhpcyBpcyBvbmx5IG9uZSB3YXkgdG8gaW1wbGVtZW50IHRoZSBjYywgYW5kIG90aGVycyBj b3VsZCB3ZWxsIHByb3ZlIHRvIGJlIGludGVyb3BlcmFibGUgd2hlbiB0ZXN0ZWQuPGJyPg0KJm5i c3A7Jm5ic3A7IGIpIE1vcmUgcGFydGljdWxhcmx5LCBpdCB3b3VsZCBiZSBiZXR0ZXIgZm9yIGFu IGltcGxlbWVudGF0aW9uIHRvIGFkYXB0IHRoZSBlc3RpbWF0aW9uIGdhaW4gdG8gdGhlIFJUVCwg c28gdGhlIHNwZWMgb3VnaHQgbm90IHRvIGltcGx5IHRoYXQgb25lIHZhbHVlIGhhcyB0byBiZSBj aG9zZW4uPGJyPg0KJm5ic3A7Jm5ic3A7IGMpIFRoZSBsYXRlciBwYXBlciBbQURDVENQMTBdIHBy b3ZpZGVzIGEgY29ycmVjdGVkIHdheSB0byBkZXRlcm1pbmUgdGhlIGdhaW4uIEZyb20gbWVtb3J5 IChJJ20gb2ZmbGluZSBhdCB0aGUgbW8pIGl0IGF0IGxlYXN0IG1ha2VzIHRocm91Z2hwdXQgaW52 ZXJzZWx5IHByb3BvcnRpb25hbCB0byAxL1JUVCwgd2hlcmVhcyB0aGUgYXBwcm9hY2ggaW4gW0RD VENQMTBdIG1hZGUgaXQgaW52ZXJzZWx5IHByb3BvcnRpb25hbCB0byAxLyhSVFReMikuDQogSSBi ZWxpZXZlIHRoZSBMaW51eCBpbXBsZW1lbnRhdGlvbiB1c2VzIHRoZSBbQURDVENQMTBdIGFwcHJv YWNoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+Jmx0O1ByYXZlZW4mZ3Q7IEZhaXIgZW5vdWdoLiBVcGRhdGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwcmU+Jm5ic3A7Jm5ic3A7IFRoZSBpbXBsZW1lbnRhdGlvbiBtdXN0IGFsc28gZGVjaWRlIHdo ZW4gdG8gdXNlIERDVENQLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyAmbmJzcDtsaWtlbHkgaW4gdGhlIHNhbWUgZGF0YWNlbnRlciBuZXR3 b3JrLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSAybmQgJmFt cDsgM3JkIHBhcmFzIGFyZSBhIG1peCBvZiBpbXBsZW1lbnRhdGlvbiBhbmQgZGVwbG95bWVudCBp c3N1ZXMsIGJ1dCBtb3N0bHkgZGVwbG95bWVudCwgc28gdGhleSBtaWdodCBiZSBiZXR0ZXIgbW92 ZWQgdG8gdGhlIGRlcGxveW1lbnQgaXNzdWVzIHNlY3Rpb24uPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbHQ7UHJhdmVlbiZndDsgSSB0aGluayB0 aGV5IGFyZSBtYWlubHkgaW1wbGVtZW50YXRpb24gaXNzdWVzIOKAkyB0aGUgZmFjdCB0aGF0IGEg bGFjayBvZiBuZWdvdGlhdGlvbiBtZWNoYW5pc20gcGxhY2VzIGEgYnVyZGVuIG9uIHRoZSBpbXBs ZW1lbnRhdGlvbiB0byBwcm92aWRlDQoga25vYnMgb3IgaGV1cmlzdGljcyB0byB1c2UgRENUQ1Au PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpDVVJSRU5UOjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbiBp bXBsZW1lbnRhdGlvbiBkZWFsIHdpdGggbG9zcyBlcGlzb2RlcyBpbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgc2FtZSB3YXkgYXMgY29udmVudGlvbmFsIFRDUC48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsgJm5i c3A7RENUQ1AgaW1wbGVtZW50YXRpb24gTUFZIGFsc28gYWxsb3cgY29uZmlndXJhdGlvbiBvZiBy ZXNldHRpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHZhbHVlIG9m IERDVENQLkFscGhhIGFzIHBhcnQgb2YgcHJvY2Vzc2luZyBhbnkgbG9zcyBlcGlzb2Rlcy48bzpw PjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TVUdHRVNURUQ6IE1vdmUgdGhp cyB3aG9sZSBwYXJhIHRvIDMuMyBTZW5kZXIgQmVoYXZpb3VyIHNlY3Rpb24sIGFuZDo8bzpwPjwv bzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEFuIGltcGxlbWVudGF0aW9uIE1VU1QgZGVhbCB3 aXRoIGxvc3MgZXBpc29kZXMgaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg dGhlIHNhbWUgd2F5IGFzIGNvbnZlbnRpb25hbCBUQ1AuPG86cD48L286cD48L3ByZT4NCjxwcmU+ Li4uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7ICZuYnNwO0RDVENQIGltcGxlbWVudGF0 aW9uIFNIT1VMRCBhbHNvIHJlc2V0IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyB2YWx1ZSBvZiBEQ1RDUC5BbHBoYSBhcyBwYXJ0IG9mIHByb2Nlc3NpbmcgYW55IGxvc3Mg ZXBpc29kZXMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMg YXNwZWN0IG9mIHRoZSBiZWhhdmlvdXIgTUFZIGJlIGNvbmZpZ3VyYWJsZS48bzpwPjwvbzpwPjwv cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij5SQVRJT05BTEU6PGJyPg0KJm5ic3A7Jm5ic3A7IGEpIFRo ZXJlIHdvdWxkIG5ldmVyIGJlIGEgY2FzZSBmb3Igbm90IGZhbGxpbmcgYmFjayB0byBjb252ZW50 aW9uYWwgVENQJm5ic3A7IChvciBkbyB5b3UgaGF2ZSBvbmU/KSwgc28gJnF1b3Q7UkVDT01NRU5E RUQmcXVvdDsgaXMgdG9vIHdlYWsuPGJyPg0KJm5ic3A7Jm5ic3A7IGIpIEkgaGF2ZSB0cmllZCB0 byBpbnRlcnByZXQgd2hhdCB5b3UgbWlnaHQgaGF2ZSBtZWFudCBhYm91dCByZXNldHRpbmcgQWxw aGEuIEknbSBub3Qgc3VyZSB3aHkgeW91IHRoaW5rIGl0IG1pZ2h0IG5lZWQgdG8gYmUgY29uZmln dXJhYmxlIHRob3VnaD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmx0O1ByYXZl ZW4mZ3Q7IFllcyB0aGlzIGlzIGEgdXNlZnVsIHN1Z2dlc3Rpb24uIE1ha2luZyBsb3NzIGhhbmRs aW5nIGEgbXVzdCBpbiBzZW5kZXIgc2VjdGlvbi4gUmVzZXQgb2YgYWxwaGEgd2FzIGRpc2N1c3Nl ZCBpbiB0Y3BtIGxpc3QsIGFuZCBMaW51eCBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBpdC4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJz cDsgLi4uaXQgaXMgYWxzbyBSRUNPTU1FTkRFRCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIGFsbG93 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyYXRpb24gb2YgcmVz dGFydGluZyB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgKGN3bmQpIG9mIGlkbGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgRENUQ1AgY29ubmVjdGlvbnM8bzpwPjwvbzpwPjwvcHJl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGVyZSBzcGVjaWFsIGltcGxlbWVudGF0aW9uIG1l YXN1cmVzIGFyZSBuZWNlc3NhcnkgZm9yIGxvdyBSVFQsIHRoZXNlIHNob3VsZCBiZSByZWxhdGVk IHRvIHRoZSBtZWFzdXJlZCBSVFQsIG5vdCBoYXJkLWNvZGVkLiBUaGVyZSBpcyBhbiBhc3N1bXB0 aW9uIGluIGEgbnVtYmVyIG9mIHBsYWNlcyZuYnNwOyB0aGF0DQogJnF1b3Q7ZGF0YSBjZW50cmUm cXVvdDsgaW1wbGllcyBsb3cgUlRULiBPZiBjb3Vyc2UgdGhpcyBpcyB0cnVlIGluIGEgc2luZ2xl IERDLCBidXQgSSBiZWxpZXZlIHRoZSB0aGUgc2luZ2xlIGFkbWluIGFzcGVjdCBvZiBhIERDIGlz IHdoYXQgY2hhcmFjdGVyaXNlcyBEQ1RDUCwgbm90IHRoZSBsb3cgUlRUIGFzcGVjdC4gV2l0aCB0 aGUgbW9kaWZpY2F0aW9ucyBpbiBbQURDVENQXSwgRENUQ1AgZ2VuZXJhbGlzZXMgdG8gYSBuZXR3 b3JrIHdpdGggbGFyZ2VyIFJUVHMNCiBhcyBsb25nIGFzIGl0IGlzIHN0aWxsJm5ic3A7IG9wZXJh dGVkIGJ5IGEgc2luZ2xlIGFkbWluLiA8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyB0aGlzIHBhcmFncmFwaCBoYXMgbm93 IGJlZW4gcmVtb3ZlZCBwZXIgTWljaGFlbHPigJkgZmVlZGJhY2suPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+ DQpDVVJSRU5UOjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7 Jm5ic3A7IFtSRkMzMTY4XSBmb3JiaWRzIHRoZSBFQ04tbWFya2luZyBvZiBwdXJlIEFDSyBwYWNr ZXRzLCBiZWNhdXNlIG9mIHRoZTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IGluYWJpbGl0eSBvZiBUQ1AgdG8gbWl0aWdhdGUgQUNLLXBhdGggY29uZ2Vz dGlvbiBhbmQgcHJvdG9jb2wtd2lzZTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBwcmVmZXJl bnRpYWwgdHJlYXRtZW50IGJ5IHJvdXRlcnMuJm5ic3A7IEhvd2V2ZXIsIGRyb3BwaW5nIHB1cmUg QUNLcyAtPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHJhdGhlciB0aGFuIEVDTiBtYXJraW5n IHRoZW0gLSBoYXMgZGlzYWR2YW50YWdlcyBmb3IgdHlwaWNhbDwvdHQ+PGJyPg0KPHR0PiZuYnNw OyZuYnNwOyBkYXRhY2VudGVyIHRyYWZmaWMgcGF0dGVybnMuJm5ic3A7IEJlY2F1c2Ugb2YgdGhl IHByZXZhbGVuY2Ugb2YgYnVyc3R5PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IHRyYWZmaWMg cGF0dGVybnMgdGhhdCBmZWF0dXJlIHRyYW5zaWVudCBjb25nZXN0aW9uLCBkcm9wcGluZyBvZiBB Q0tzPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNhdXNlcyBzdWJzZXF1ZW50IHJldHJhbnNt aXNzaW9ucy4gSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZu YnNwOyBpbXBsZW1lbnRhdGlvbiBwcm92aWRlIGEgY29uZmlndXJhdGlvbiBrbm9iIHRoYXQgd2ls bCBjYXVzZSBFQ1QgdG8gYmUgc2V0PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG9uIHN1Y2gg Y29udHJvbCBwYWNrZXMsIHdoaWNoIGNhbiBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZSBz dWNoIDwvdHQ+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IGNvbmNlcm5zIGRvIG5vdCBhcHBseS48 L3R0Pjxicj4NCjwvc3Bhbj5TVUdHRVNURUQ6PGJyPg0KPHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsgW1JGQzMxNjhdIGZvcmJpZHMgdGhlIEVDTi1tYXJraW5n IG9mIHB1cmUgQUNLIHBhY2tldHMsIGJlY2F1c2Ugb2YgdGhlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDss c2VyaWYiPjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgaW5hYmlsaXR5IG9mIFRDUCB0byBtaXRpZ2F0 ZSBBQ0stcGF0aCBjb25nZXN0aW9uIGFuZCB0aGUgZXh0cmEgPC90dD48YnI+DQo8dHQ+Jm5ic3A7 Jm5ic3A7IGFkdmFudGFnZSB0byBpbmplY3Rpb24gYXR0YWNrZXJzIHRoYXQgRUNOIGlzIHBlcmNl aXZlZCB0byBvZmZlci4gPC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEZvciB0aGUgbGF0dGVy IHJlYXNvbiBSRkMgMzE2OCBhbHNvIGZvcmJpZHMgRUNOLW1hcmtpbmcgb2YgPC90dD48YnI+DQo8 dHQ+Jm5ic3A7Jm5ic3A7IHJldHJhbnNtaXNzaW9ucywgd2luZG93IHByb2JlcyBhbmQgUlNUcy4g PC90dD48YnI+DQo8YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IEhvd2V2ZXIsIGRyb3BwaW5nIGFsbCB0 aGVzZSBjb250cm9sIHBhY2tldHMgLTwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyByYXRoZXIg dGhhbiBFQ04gbWFya2luZyB0aGVtIC0gaGFzIGNvbnNpZGVyYWJsZSBwZXJmb3JtYW5jZSA8L3R0 Pjxicj4NCjx0dD4mbmJzcDsmbmJzcDsgZGlzYWR2YW50YWdlcy4mbmJzcDsgSXQgaXMgUkVDT01N RU5ERUQgdGhhdCBhbjwvdHQ+PGJyPg0KPHR0PiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiBw cm92aWRlIGEgY29uZmlndXJhdGlvbiBrbm9iIHRoYXQgd2lsbCBjYXVzZSBFQ1QgdG8gYmUgc2V0 PC90dD48YnI+DQo8dHQ+Jm5ic3A7Jm5ic3A7IG9uIHN1Y2ggY29udHJvbCBwYWNrZXMsIHdoaWNo IGNhbiBiZSB1c2VkIGluIGVudmlyb25tZW50cyB3aGVyZSBzdWNoIDwvdHQ+DQo8YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IGNvbmNlcm5zIGRvIG5vdCBhcHBseS48L3R0Pjwvc3Bhbj48YnI+DQpOT1RF Ojxicj4NCiZuYnNwOyZuYnNwOyBUaGlzIG1pZ2h0IG5vdCByZWZsZWN0IHRoZSB3YXkgeW91ciBp bXBsZW1lbnRhdGlvbiBpcyBjb2RlZCwgc28geW91IG1pZ2h0IHdhbnQgdG8gbWFrZSB0aGF0IGNs ZWFyLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmx0O1ByYXZlZW4mZ3Q7IEZpeGVkPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b QkJdIEEgbmV3IGNvbW1lbnQuLi48YnI+DQo8YnI+DQpBcyBwb2ludGVkIG91dCBpbiBkcmFmdC1i YWd1bG8tdHN2d2ctZ2VuZXJhbGl6ZWQtZWNuLTAwLCBSRkMzMTY4IG9ubHkgdGFsa3MgYWJvdXQg aW5qZWN0aW9uIGF0dGFja3Mgd2l0aCByZXRyYW5zbWlzc2lvbnMgKG5vdCBBQ0tzIGV0YykuIEJ1 dCB5b3UgaW1wbHkgaW5qZWN0aW9uIGF0dGFja3Mgd2VyZSB0aGUgY29uY2VybiBmb3Igb3RoZXIg Y29udHJvbCBwYWNrZXRzIGFzIHdlbGwuPGJyPg0KPGJyPg0KSSdtIG5vdCBpbnNpc3RpbmcgeW91 IGNoYW5nZSB0aGlzLiBIb3dldmVyLCB1bndhcnJhbnRlZCBhY2N1c2F0aW9ucyBvZiBzZWN1cml0 eSB2dWxuZXJhYmlsaXRpZXMgdGVuZCB0byBzdGljaywgd2hldGhlciBvciBub3QgdGhleSBhcmUg Y29ycmVjdC4gU28gaXQgd291bGQgYmUgYmV0dGVyIG5vdCB0byB0aHJvdyBtdWQgYXJvdW5kIG9u dG8gZXZlbiBtb3JlIGNvbnRyb2wgcGFja2V0cyB0aGFuIFJGQzMxNjggZGlkLjxicj4NCjxicj4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7Jmd0OyBNb2Rp ZmllZCB0aGlzIHRvIHJlbW92ZSB0aGF0IHN1Z2dlc3Rpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KQ2hlZXJzPGJy Pg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxicj4NCjxiPjUuIERlcGxveW1lbnQg SXNzdWVzPC9iPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgSWY8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhlIHRyYWZmaWMgaW4gdGhlIGRhdGFjZW50ZXIg aXMgYSBtaXggb2YgY29udmVudGlvbmFsIFRDUCBhbmQgRENUQ1AsPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7ICZuYnNwO2l0IGlzIFJFQ09NTUVOREVEIHRoYXQgRENUQ1AgdHJhZmZpYyBi ZSBzZWdyZWdhdGVkIGZyb20gY29udmVudGlvbmFsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IFRDUCB0cmFmZmljLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PkluIGEgZGF0YSBjZW50cmUgKG9yIGFueXdoZXJlKSwgaXMgdGhlcmUgYW55IGNhc2Ugd2hlcmUg bm90IHNlZ3JlZ2F0aW5nIHRoZW0gd291bGQgbWFrZSBzZW5zZT8gSWYgbm90LCB0aGlzIG5lZWRz IHRvIGJlIGEgTVVTVCwgbm90IGp1c3QgYSBSRUNPTU1FTkRFRC4gSSBjYW4gaW1hZ2luZSBjYXNl cyB3aGVyZSB0aGVyZQ0KIGlzIG5vIGxvbmctcnVubmluZyBjb252ZW50aW9uYWwgVENQIG9yIG5v IGxvbmctcnVubmluZyBEQ1RDUCwgYnV0IHRoYXQncyBjb3ZlcmVkIGJ5IHRoZSAmcXVvdDtpZiZx dW90OyBhdCB0aGUgc3RhcnQgb2YgdGhlIHNlbnRlbmNlLjxicj4NCjxicj4NCllvdSBtaWdodCB3 YW50IHRvIHJlZmVyIHRvIGRyYWZ0LWJyaXNjb2UtYXFtLWR1YWxxLWNvdXBsZWQgYXMgYW5vdGhl ciBzZWdyZWdhdGlvbiBhcHByb2FjaCBoZXJlIHRvby48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5i c3A7Jm5ic3A7IFNpbmNlIERDVENQIHJlbGllcyBvbiBjb25nZXN0aW9uIG1hcmtpbmcgYnkgdGhl IHN3aXRjaGVzLCBEQ1RDUCBjYW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsg b25seSBiZSBkZXBsb3llZCBpbiBkYXRhY2VudGVycyB3aGVyZSB0aGUgZW50aXJlIG5ldHdvcms8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5mcmFzdHJ1Y3R1cmUgc3VwcG9y dHMgRUNOLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlN1cmVseSwgdGhlICZx dW90O2ZhbGwtYmFjayB0byBjb252ZW50aW9uYWwgVENQIG9uIGxvc3MmcXVvdDsgcnVsZSBtZWFu cyB5b3UgY2FuIGRlbGV0ZSB0aGlzIGNvbnN0cmFpbnQuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij4mbHQ7UHJhdmVlbiZndDsgUmV3b3JkZWQgdG8gaW1wbHkgdGhh dCBEQ1RDUCB3aWxsIG9ubHkgd29yayBhcyBleHBlY3RlZCBpbiBzdWNoIGNhc2VzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5i c3A7Jm5ic3A7IEE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdmFyaWFudCBv ZiBEQ1RDUCB0aGF0IGNhbiBiZSBkZXBsb3llZCB1bmlsYXRlcmFsbHkgYW5kIG9ubHkgcmVxdWly ZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3RhbmRhcmQgRUNOIGJlaGF2 aW9yIGhhcyBiZWVuIGRlc2NyaWJlZCBpbiBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5pZXRmLm9y ZyUyZmh0bWwlMmZkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtT0RDVENQJmFtcDtkYXRh PTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2QzZTQ0YTA4 ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2Rh dGE9WndmSjBMZ0hRM3ZrJTJiTUQwd2lpYTV5THJjTU1TVUJjR2dQWVhtZVJ1OGhFJTNkIiB0aXRs ZT0iJnF1b3Q7SW1wcm92aW5nIFRyYW5zbWlzc2lvbiBQZXJmb3JtYW5jZSB3aXRoIE9uZS0gU2lk ZWQgRGF0YWNlbnRlciBUQ1AmcXVvdDsiPk9EQ1RDUDwvYT5dW0JTRENBTl0sPG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KV2hpY2ggcGFydCBvZiAmcXVvdDtz dGFuZGFyZCBFQ04gYmVoYXZpb3VyJnF1b3Q7IGRvIHlvdSBtZWFuPyBUaGUgaG9zdCBwYXJ0PyBU aGUgbmV0d29yayBwYXJ0PyBUaGUgcmVjZWl2ZXIgcGFydD8gQW5kICZxdW90O2NhbiBiZSBkZXBs b3llZCB1bmlsYXRlcmFsbHkmcXVvdDsgb3VnaHQgdG8gYmUgaW4gdGhlIGFjdGl2ZSB2b2ljZSBu b3QgdGhlIHBhc3NpdmUsIHdoaWNoIHdvdWxkIGhlbHAgcmVzb2x2ZSB0aGUgYW1iaWd1aXR5IHRv by48YnI+DQo8YnI+DQpJIGhhdmVuJ3QgcmVhZCBbT0RDVENQXSBhbmQgW0JTRENBTl0gKEknbSBv ZmZsaW5lIG9uIGEgcGxhbmUgYXQgdGhlIG1vKS4gQXJlIHRoZXkgc2ltaWxhciB0byAmcXVvdDtJ bnN0YW50IEVDTiZxdW90OyBpbiBbV3UxMl0gbGlzdGVkIGJlbG93PyBJZiBub3QsIHRoYXQgY291 bGQgYmUgcmVmZXJyZWQgdG8gYXMgd2VsbCBmb3IgYSB0ZWNobmlxdWUgdGhhdCB1c2VzIHRoZSBy ZWd1bGFyIEVDTiBob3N0IGJlaGF2aW91ci48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBUaGlzIGVkaXQgcHJlZGF0ZXMg bWUgYW5kJm5ic3A7IEkgZG9u4oCZdCBoYXZlIHRoZSBmdWxsIGNvbnRleHQsIEkgYW0gbGVhdmlu ZyB0aGlzIGFzIGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K PGI+Ni4gS25vd24gSXNzdWVzPGJyPg0KPC9iPjxicj4NCkZpcnN0IHBhcmEgY291bGQgcmVmZXIg dG8gYXBwZW5kaXggQSBvZiBSRkM3NTYwLCB3aGljaCBkZXNjcmliZXMgdGhlIHByb2JsZW0gcHJl Y2lzZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT5BIG1ldGhvZCBmb3Ig aW1wcm92aW5nIHRoZSBmYWlybmVzcyBvZiBEQ1RDUCBoYXMgYmVlbiBwcm9wb3NlZDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbiBbPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ0b29scy5p ZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC1pZXRmLXRjcG0tZGN0Y3AtMDElMjNyZWYtQURDVENQJmFt cDtkYXRhPTAxJTdjMDElN2NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN2NhNTcyYjBiYThlMWI0N2Qz ZTQ0YTA4ZDJlNmQ3ZTAzZiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZh bXA7c2RhdGE9ZWRVMlRQR3BMdnlGR3Znb2NEUkppWVJReWpDVCUyZldFT2dTMk13bXd6WXVVJTNk IiB0aXRsZT0iJnF1b3Q7QW5hbHlzaXMgb2YgRENUQ1A6IFN0YWJpbGl0eSwgQ29udmVyZ2VuY2Us IGFuZCBGYWlybmVzcyZxdW90OyI+QURDVENQPC9hPl0sIGJ1dCByZXF1aXJlcyBhZGRpdGlvbmFs IGV4cGVyaW1lbnRhbCBldmFsdWF0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPnMvZmFpcm5lc3MvUlRUIGZhaXJuZXNzLzxicj4NCjxicj4NCihJbiBvdXIgZXhw ZXJpbWVudHMsIGl0J3MgbXVjaCBiZXR0ZXIgdGhhbiB3aXRob3V0Lik8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBHb2Fs IGlzIHRvIGNpdGUgb3RoZXIgd29yayB0aGF0IGNhbiBhZGRyZXNzIHBvdGVudGlhbCBpc3N1ZXMu IEl0IGlzIG5vdCBhIHJlY29tbWVuZGF0aW9uLiBzL2ZhaXJuZXNzL1JUVCBmYWlybmVzcy8gRml4 ZWQgaW4gbmV4dCByZXZpc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCjxiPjExLiBSZWZlcmVuY2Vz PGJyPg0KPC9iPjxicj4NCkkgdGhpbmsgdGhlIGZvbGxvd2luZyBhcmUgY2l0ZWQgbm9ybWF0aXZl bHksIG5vdCBqdXN0IGluZm9ybWF0aXZlbHk6PGJyPg0KUkZDNTY4MSwgUkZDNTU2Mi48YnI+DQo8 YnI+DQpBZGRpdGlvbmFsIGluZm9ybWF0aW9uYWwgUmVmZXJlbmNlOjxicj4NCjxicj4NCltXdTEy XSBXdSwgSC4sIEp1LCBKLiwgTHUsIEcuLCBHdW8sIEMuLCBYaW9uZywgWS4gJmFtcDsgWmhhbmcs IFkuLCAmcXVvdDtUdW5pbmcgRUNOIGZvciBEYXRhIENlbnRlciBOZXR3b3JrcywmcXVvdDsgSW46 IFByb2NlZWRpbmdzIG9mIHRoZSA4dGggSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIEVtZXJn aW5nIE5ldHdvcmtpbmcgRXhwZXJpbWVudHMgYW5kIFRlY2hub2xvZ2llcyBDb05FWFQgJzEyIHBw LjI1LTM2IEFDTSAoMjAxMik8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZsdDtQcmF2ZWVuJmd0OyBDaXRhdGlvbiB0byBSRkNzIHVwZGF0ZWQgYXMg bm9ybWF0aXZlLiBOb3QgaW5jbHVkaW5nIHRoZSBuZXcgcmVmZXJlbmNlIHNpbmNlIGV2ZW4gdGhv dWdoIGl0IG1heSBiZSByZWxldmFudCDigJMgaXQgd2FzIG5vdCB1c2VkIGFzIGEgcmVmZXJlbmNl DQogaW4gd3JpdGluZyB0aGUgZHJhZnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGF0J3MgaXQuIEhU SC48YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZib2JicmlzY29lLm5l dCUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdjYTU3MmIwYmE4 ZTFiNDdkM2U0NGEwOGQyZTZkN2UwM2YlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3YzEmYW1wO3NkYXRhPWlFdmhXajlGQ1BveldBcDhybnhrNVZaZE5GJTJmdjdXN2FEMUNwNE14 T2lTcyUzZCI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9i b2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29l Lm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB0117403DA329375E35CB146B6BD0BY2PR03MB011namprd_-- From nobody Mon Nov 14 21:42:56 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F108F129673 for ; Mon, 14 Nov 2016 21:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln89DD0nSj0k for ; Mon, 14 Nov 2016 21:42:52 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9CFA129542 for ; Mon, 14 Nov 2016 21:42:52 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id q124so171047717itd.1 for ; Mon, 14 Nov 2016 21:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=6VQhOVoruLbWdUGxWYuoT6DZ/5AnlSt4YwHkvvyiTmc=; b=Y5woD1zsKRKOtuo0LOfI1eS3zYyO4WY3GHCvvxHmJUwTWnW3cQFMgv605ABpF88nel 0/GatLljPsdIpozI2QGsuiTt0ZGeox2a5z615wD1WFQsbP1eOdGrgtrJpKo3mZRrpfjQ VAikbSXuvesUlXpRFLwuhsRwa1toYOSKAmXnybhXDLFY+5IuM6YRtYgS3vo3kU9fHWx2 XaA2bJSsEnrtYZF0VqsR0C/1S3lRSWDyvtcxbTnZ9VGHGkpNiT+tAhfjHHwbbzFBkCiz Y4x0xcz2RNMDR8q1dveanpEgnm6THUMNFKruYtTrv/i81YGBHCAaeGyC8/pdLql8U8gb xJvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6VQhOVoruLbWdUGxWYuoT6DZ/5AnlSt4YwHkvvyiTmc=; b=I+4W8xINZrZjQieFWM6GELlY6fLI9uJga0J+MfX3s6f1mzzd3mfzIeVFINn9DLyj6X lJntwT5P5SGpQFcyz+xJIy6pOvhH68fmJTWRvpMDmMXPj/vMZWY1Am+XPX/0JnQP4xn1 P6wlZCu3fQrtJIhyEz4FSNKeqlRdu/4VCoifxT6iB3Ib37fTjOMjH2QpCu48mw7eDdCc 4DTNtO6Y46j2yxTDenEIkcyxyU5hmNdUfYNU9ot+f2dXyS2KAEuJzgZ71zCOo07xbFrb LvRk82I4mG0Xdxmyyxi0CM7Y1ktsDhTA1m6t9LhP5bQqwFVuKNgDBle1nHSvPplPrY1e Hcwg== X-Gm-Message-State: ABUngvctmQ2Y+hRTwyfoGXZLhqKPQQPkAllrextdXrgVk6lvmcsFF0jYxmuDqLJ65YtRfpLqN5aAH4heSKOgIivn X-Received: by 10.36.61.207 with SMTP id n198mr1683053itn.60.1479188571701; Mon, 14 Nov 2016 21:42:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.0.225 with HTTP; Mon, 14 Nov 2016 21:42:11 -0800 (PST) From: Yuchung Cheng Date: Tue, 15 Nov 2016 14:42:11 +0900 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary=001a114444565fa0830541506d4e Archived-At: Subject: [tcpm] BBR congestion control presentation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2016 05:42:54 -0000 --001a114444565fa0830541506d4e Content-Type: text/plain; charset=UTF-8 hi folks, Neal and I are presenting a new congestion control called BBR (for TCP/QUIC) in the upcoming ICCRG meeting at 3:50p. I just thought tcpm people might be interested as it is very relevant to TCP development. Yuchung --001a114444565fa0830541506d4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hi folks,

Neal and I are presenting a n= ew congestion control called BBR (for TCP/QUIC) in the upcoming ICCRG meeti= ng at 3:50p. I just thought tcpm people might be interested as it is very r= elevant to TCP development.

Yuchung

=

--001a114444565fa0830541506d4e-- From nobody Tue Nov 15 17:00:07 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52532129530 for ; Tue, 15 Nov 2016 17:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yj1MAdi-tIr9 for ; Tue, 15 Nov 2016 17:00:04 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776C2126CD8 for ; Tue, 15 Nov 2016 17:00:04 -0800 (PST) Received: from [125.177.184.81] (port=33689 helo=[192.168.219.101]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c6oa2-0001f7-PU; Wed, 16 Nov 2016 01:00:03 +0000 From: Bob Briscoe To: Neal Cardwell Message-ID: <67dbb3ef-4671-8b91-fc51-538e8c890544@bobbriscoe.net> Date: Wed, 16 Nov 2016 00:59:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5CC7A0FC15734EFC881758E9" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list Subject: [tcpm] Ref to timestamp negotiation draft (expired) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:00:06 -0000 This is a multi-part message in MIME format. --------------5CC7A0FC15734EFC881758E9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Neil, [re-sending from correct address, so it is acceptable to the tcpm list] As promised in the discussion just now about your timer negotiation talk in tcpm, here's the previous draft on a similar subject: Additional negotiation in the TCP Timestamp Option field during the TCP handshake This was originally prompted by the research here (see section 3.1 for the timestamp discussion), which you might also be interested in: Chirping for Congestion Control - Implementation Feasibility Bob PS. I can recommend a good search engine to find stuff like this :) -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------5CC7A0FC15734EFC881758E9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Neil, [re-sending from correct address, so it is acceptable to the tcpm list]

As promised in the discussion just now about your timer negotiation talk in tcpm, here's the previous draft on a similar subject:
Additional negotiation in the TCP Timestamp Option field during the TCP handshake

This was originally prompted by the research here (see section 3.1 for the timestamp discussion), which you might also be interested in:
Chirping for Congestion Control - Implementation Feasibility



Bob

PS. I can recommend a good search engine to find stuff like this :)


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------5CC7A0FC15734EFC881758E9-- From nobody Wed Nov 16 01:55:51 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3CA129664 for ; Wed, 16 Nov 2016 01:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiP8Bc5W15BF for ; Wed, 16 Nov 2016 01:55:47 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93EA129695 for ; Wed, 16 Nov 2016 01:55:47 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id z62so54904076oiz.1 for ; Wed, 16 Nov 2016 01:55:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AIam0LC8TMzo/dVVYwF2plxsyp8qLbRBmKw5osJw9/Y=; b=Z/z53P8fb1n98+cejI7/mFqye6awa9qusxvx8UFzT+QOdKCPziu4vRF2n0oG8cqkpb gakOdAkz/+TC9+YqxpNpoU96Sihrp96Xw2zqKiOivdQrWQeNFsE9I3JKSvp2fbtggY+b KVdI35+XFXsZPnfoFuFMQ3WzNAuBOkei67J8sg7MNb7EgtgipUXws9S6e37DNwkfABVk TQIbf9EzqSxDZzG/ugCFQ/ShXFyi1puqkSpb18Tpz9ZdsEMzZTSSenqCLq7j0F505ZWP tYGP0XbdOpq9y1GZmhgd9Ko6HFNVi9L4An7cXY6eTnXDR1PdTGSw53d+co+j3gg4ulAV a+4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AIam0LC8TMzo/dVVYwF2plxsyp8qLbRBmKw5osJw9/Y=; b=CrzcIfJDb2NWPBAUMNOZ+r1n2ACSC2JWzmEYn4bpt0vhz9rGhncV8ETSfIXLA/as2q tagrhAdqzHr9VBqTb54X94+DZ/YtnO0ZpJR2x3fKnRad897g+bdUcji762iNXwUBGdFs V8UTnrqyvUNlC68H4UTOAGGVoj1Nnl4TOlcqnNUpNw1O6LiWRoQZ2JnbP6q4fPqICaIF WSQhzVUXJ5aTR85Bm3p4ZqS64HLWCziEjDNhAJMupFexyi/Ite4TATjr53GEqME01kSs 9dUMT4k/GaW2rwxQA5583kvdZFzzTpevz6OP2GV1aJ7P7GBePlzfDrxwTjikgBWFgDen 1WlQ== X-Gm-Message-State: ABUngveg7GjBVMobWC/2cJLxFhiA75x0ZIK9Ca1yZD/bpgTrWYJv0dFRvXHuCeGl8h4sybvx0cQToEcB8ypWPzCY X-Received: by 10.202.79.203 with SMTP id d194mr1431022oib.46.1479290146838; Wed, 16 Nov 2016 01:55:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.199.17 with HTTP; Wed, 16 Nov 2016 01:55:16 -0800 (PST) In-Reply-To: <67dbb3ef-4671-8b91-fc51-538e8c890544@bobbriscoe.net> References: <67dbb3ef-4671-8b91-fc51-538e8c890544@bobbriscoe.net> From: Neal Cardwell Date: Wed, 16 Nov 2016 18:55:16 +0900 Message-ID: To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a113d816eb917c10541681376 Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] Ref to timestamp negotiation draft (expired) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 09:55:49 -0000 --001a113d816eb917c10541681376 Content-Type: text/plain; charset=UTF-8 Great. Thanks, Bob. We'll take a look at these... neal On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe wrote: > Neil, [re-sending from correct address, so it is acceptable to the tcpm > list] > > As promised in the discussion just now about your timer negotiation talk > in tcpm, here's the previous draft on a similar subject: > Additional negotiation in the TCP Timestamp Option field during the TCP > handshake > > > This was originally prompted by the research here (see section 3.1 for the > timestamp discussion), which you might also be interested in: > Chirping for Congestion Control - Implementation Feasibility > > > > > Bob > > PS. I can recommend a good search engine to find stuff like this :) > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > --001a113d816eb917c10541681376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great. Thanks, Bob. We'll take a look at these...
=
neal

On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe <ietf@bobbris= coe.net> wrote:
=20 =20 =20
Neil, [re-sending from correct address, so it is acceptable to the tcpm list]

As promised in the discussion just now about your timer negotiation talk in tcpm, here's the previous draft on a similar subject:
Additional negotiation in the TCP Timestamp Option field during the TCP handshake

This was originally prompted by the research here (see section 3.1 for the timestamp discussion), which you might also be interested in:
Chirping for Congestion Control - Implementation Feasibility



Bob

PS. I can recommend a good search engine to find stuff like this :)


--=20
________________________________________________________________
Bob Briscoe                               h=
ttp://bobbriscoe.net/

--001a113d816eb917c10541681376-- From nobody Sat Nov 19 07:40:29 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E2D128B44; Sat, 19 Nov 2016 07:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRxUdeL5UvMH; Sat, 19 Nov 2016 07:40:20 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E2C12950F; Sat, 19 Nov 2016 07:40:19 -0800 (PST) Received: from [85.133.27.70] (port=46054 helo=[192.168.212.35]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c87kV-00042g-Pt; Sat, 19 Nov 2016 15:40:17 +0000 From: Bob Briscoe To: Mirja Kuehlewind References: <147791289909.32484.2914298988666416427.idtracker@ietfa.amsl.com> <82E99853-7EE1-46E5-B82F-4A09814F6715@tik.ee.ethz.ch> <0e03a023-fde6-1a8d-e534-62784ad4701d@bobbriscoe.net> <73935f41-fa95-d136-1b3d-85778be9c7df@bobbriscoe.net> Message-ID: Date: Sat, 19 Nov 2016 13:57:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <73935f41-fa95-d136-1b3d-85778be9c7df@bobbriscoe.net> Content-Type: multipart/alternative; boundary="------------C0522C4F03029748F1697AE4" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List Subject: Re: [tcpm] New Version Notification for draft-ietf-tcpm-accurate-ecn-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2016 15:40:23 -0000 This is a multi-part message in MIME format. --------------C0522C4F03029748F1697AE4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Mirja, During the discussion on draft-briscoe-tsvwg-ecn-l4s-id, you raised the concern about the CE marking being ambiguous (it could have been ECT(0) or ECT(1) before marking). The draft says why there is a low risk CE marks will arrive at a second bottleneck, and why the risk of causing spurious retransmissions is lower still (there have to be >3 contiguous CE markings from the upstream queue). It's quoted below for your convenience. I think we should also the following to this text (as pointed out recently by Koen): "On the plus side, misclassifying a CE-marked Classic packet delivers the congestion notification to the end-to-end transport without any Classic queuing delay. " Risk of reordering classic CE packets: Having to classify all CE packets as L4S risks some classic CE packets arriving early, which is a form of reordering. Reordering can cause the TCP sender to retransmit spuriously. However, one or two packets delivered early does not cause any spurious retransmissions because the subsequent packets continue to move the cumulative acknowledgement boundary forwards. Anyway, the risk of reordering would be low, because: i) it is quite unusual to experience more than one bottleneck queue on a path; ii) even then, reordering would only occur if there was simultaneous mixing of classic and L4S traffic, which would be more unlikely in an access link, which is where most bottlenecks are located; iii) even then, spurious retransmissions would only occur if a contiguous sequence of three or more classic CE packets from one bottleneck arrived at the next, which should in itself happen very rarely with a good AQM. The risk would be completely eliminated in AQMs that were transport-aware (but they should not need to be); Bob On 12/11/16 16:04, Bob Briscoe wrote: > Mirja, > > Sorry, it's become rather hard to follow my replies, given sent in > pieces. I've tagged the questions and answers to make it clearer: > > On 12/11/16 12:53, Bob Briscoe wrote: >> Mirja, >> >> The previous response only addressed your first question, 'cos I sent >> in haste ( I had to go offline to board the flight). Below I address >> the other questions. >> >> On 12/11/16 12:21, Bob Briscoe wrote: >>> Mirja, >>> >>> It's great you've managed to find time to finish the implementation >>> - well done! >>> Pity I didn't find time to reply sooner :O >>> inline... >>> >>> >>> On 31/10/16 12:00, Mirja Kühlewind wrote: >>>> Hi Bob, hi Richard, >>>> >>>> I’ve submitted a new version of this draft with only minor changes. >>>> I finished my implementation but still have to do some testing. >>>> Current code is here: >>>> >>>> https://github.com/mirjak/linux-accecn >>>> >>>> This is really not tested carefully I but have right now some >>>> problems with my testing environment… anyway wanted to submit a new >>>> draft version before the deadline. However, given my current >>>> implementation is, as far as I can tell now, complete, I believe >>>> the spec is fins. >>>> >>>> I only have a few comments/questions regarding the fall-back rules >>>> we describe in the drafts (sec. 3.2.4): >>>> *Q1 *- we don’t say anything about retransmitting the SYN. Should a >>>> retransmitted SYN try to negotiate AccECN or not, or are we relying >>>> on the classic ECN fall-back rules in this case (which would be >>>> clearing the ECN flags)? >>> *A1 *- Good point - I was (we were?) thinking about the option being >>> blocked by a middlebox, but not the AccECN flags in the main header. >>> >>> We need to allow plenty of implementer choice here, but give a good >>> default. The default depends on how likely an AccECN SYN will be >>> dropped because of the AccECN flags. I think your tests [PAM paper] >>> found no drop due to these flags. >>> >>> So, here's some suggesting text: >>> >>> Measurement tests [PAM paper] so far have found that it is extremely >>> rate for middleboxes to drop a SYN just because all three ECN flags >>> are set (i.e. it is negotiating to use AccECN). Therefore, if the >>> sender of an initial AccECN SYN times out waiting for the SYN/ACK it >>> will more likely be due to congestion loss than middlebox >>> interference. This suggests the following strategy will maximize the >>> chances of using AccECN while minimizing delay. >>> >>> If the sender of an AccECN SYN times out before receiving the >>> SYN/ACK, the sender SHOULD attempt to negotiate the use of AccECN at >>> least one more time by continuing to set all three TCP ECN flags on >>> the first retransmitted SYN. If this first retransmission also fails >>> to be acknowledged, the sender SHOULD send subsequent >>> retransmissions of the SYN without any ECN flags set. >>> >>> This adds delay, but no more delay than normal, if the cause was >>> congestion. In the case that a middlebox drops an AccECN (or ECN) >>> SYN deliberately, this strategy will add delay, but current >>> measurements show this case is likely to be rare. >>> >>> Implementers MAY use other fall-back strategies if they >>> are found to be more effective (e.g. attempting >>> to retransmit an AccECN SYN more than once, (most appropriate during >>> high levels of congestion); or falling back to classic ECN feedback >>> rather than non-ECN). > , or cached knowledge associated with the remote host. >>> >>> Nit in 3.2.4: s/tha/that/ >>> >>> I believe there was a bug where the Linux connection-manager got >>> into a black-holing state if it didn't support the TFO option. Even >>> tho the bug was fixed, there are likely to be bugged Linux routers >>> out there. So we need to check the black hole doesn't apply to >>> AccECN SYNs as well. If it does, we will need to suggest restarting >>> a new connection as a fall-back. I'll check the details. >>> >>> >>> Bob >>> >>> >>>> *Q2* - What if we receive a second SYN with AccECN negotiation? We >>>> would probably send a SYNACK that negotiates AccECN but no Option, >>>> assuming that the SYNACK was lost, right? And then probably also go >>>> into a mode where we don’t send the option anymore..? We don’t say >>>> anything about this case in the draft. >> *A2* - The trouble is that SYN/ACKs are just as likely to be lost due >> to congestion (e.g. found this in our L4S testing). But I agree that, >> in this case, I think send the SYN/ACK without the option, but try to >> include the option pretty soon afterwards. >> >> Rest of email will follow when I land... >> >> >> Bob >> >>>> *Q3* - Also should we add a sentence that one could monitor the >>>> segments that carry an option and if it is much more likely that >>>> such a segment would be lost, then disable sending the option? Of >>>> current that only works for segments that carry data as well. > *A3* Yes. 3.2.4 seems like the best place for that as well. >>>> *Q4* - And finally we probably should to add an experimentation >>>> section, where we say that the question which fallbacks are >>>> actually needed must be investigated by experimentation. (Currently >>>> I only implemented clearing of the ECN flags when retransmitting a >>>> segment with the SYN flag set). Then we could also move any text we >>>> would like to keep from Appendix C into this section. > > *A4* - We have 1.3 for this: "Experiment Goals". We could add a > sentence saying most of the issues that need experimental verification > concern path traversal. >>>> *Q5* - Also another side mark: I currently implemented AccECN and >>>> increase the respective counters but don’t use them of course. >>>> Maybe we should add one section in the draft that is directed to >>>> people that would like to use these counters of an existing >>>> implementation, e.g. adding a warning that counters might not >>>> increase even if AccECN is negotiation because options could be >>>> stripped, and that the CE packet counter could increase differently >>>> as it includes control packets without data and therefore usually >>>> both values should be checked… we say this all in the draft >>>> somewhere but maybe it be good to has this summarized in some kind >>>> of ‚usage‘ section…? > > *A5* Yes. Perhaps "AccECN Usage Examples" > > And this would be a good place to talk about behaviour that depends on > other parallel updates to ECN that are in progress (whether > experimental or PS), e.g.: > > ecn-fallback: > Perhaps this (informative?) usage section could also repeat relevant > stuff from ecn-fallback that isn't specific to AccECN, but applies > generally to ECN TCP. > > generalized-ecn: > This usage section would also be a good place to address open issue #3 > (Appx C). But I'm not clear where to define the normative behaviour > concerning the interationc between ECT control packets and AccECN. It > would be really odd to talk about the details of AccECN counters in > generalized-ecn. But it is hard to talk about generalized ECN in the > AccECN draft, because it is not yet a WG draft, and we really don't > want to hold back AccECN. > > *More Nits** > *In 3.3: > s/intervene/intervenes/ >>>> >>>> I guess we could prepare these changes (if any) and submit IETF >>>> Monday (if not today again) and ask for wglc in tcpm…? >>>> >>>> Mirja >>>> >>>> >>>> >>>>> Am 31.10.2016 um 12:21 schrieb internet-drafts@ietf.org: >>>>> >>>>> >>>>> A new version of I-D, draft-ietf-tcpm-accurate-ecn-02.txt >>>>> has been successfully submitted by Mirja Kühlewind and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-ietf-tcpm-accurate-ecn >>>>> Revision: 02 >>>>> Title: More Accurate ECN Feedback in TCP >>>>> Document date: 2016-10-31 >>>>> Group: tcpm >>>>> Pages: 37 >>>>> URL: >>>>> https://www.ietf.org/internet-drafts/draft-ietf-tcpm-accurate-ecn-02.txt >>>>> >>>>> Status: >>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ >>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02 >>>>> Diff: >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-02 >>>>> >>>>> Abstract: >>>>> Explicit Congestion Notification (ECN) is a mechanism where >>>>> network >>>>> nodes can mark IP packets instead of dropping them to indicate >>>>> incipient congestion to the end-points. Receivers with an ECN- >>>>> capable transport protocol feed back this information to the >>>>> sender. >>>>> ECN is specified for TCP in such a way that only one feedback >>>>> signal >>>>> can be transmitted per Round-Trip Time (RTT). Recently, new TCP >>>>> mechanisms like Congestion Exposure (ConEx) or Data Center TCP >>>>> (DCTCP) need more accurate ECN feedback information whenever more >>>>> than one marking is received in one RTT. This document >>>>> specifies an >>>>> experimental scheme to provide more than one feedback signal >>>>> per RTT >>>>> in the TCP header. Given TCP header space is scarce, it overloads >>>>> the three existing ECN-related flags in the TCP header and >>>>> provides >>>>> additional information in a new TCP option. >>>>> >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> The IETF Secretariat >>> >> > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------C0522C4F03029748F1697AE4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Mirja,

During the discussion on draft-briscoe-tsvwg-ecn-l4s-id, you raised the concern about the CE marking being ambiguous (it could have been ECT(0) or ECT(1) before marking). The draft says why there is a low risk CE marks will arrive at a second bottleneck, and why the risk of causing spurious retransmissions is lower still (there have to be >3 contiguous CE markings from the upstream queue). It's quoted below for your convenience.

I think we should also the following to this text (as pointed out recently by Koen):
    "On the plus side, misclassifying a CE-marked Classic packet delivers the congestion notification to the end-to-end transport without any Classic queuing delay. "


   Risk of reordering classic CE packets:  Having to classify all CE
      packets as L4S risks some classic CE packets arriving early, which
      is a form of reordering.  Reordering can cause the TCP sender to
      retransmit spuriously.  However, one or two packets delivered
      early does not cause any spurious retransmissions because the
      subsequent packets continue to move the cumulative acknowledgement
      boundary forwards.  Anyway, the risk of reordering would be low,
      because: i) it is quite unusual to experience more than one
      bottleneck queue on a path; ii) even then, reordering would only
      occur if there was simultaneous mixing of classic and L4S traffic,
      which would be more unlikely in an access link, which is where
      most bottlenecks are located; iii) even then, spurious
      retransmissions would only occur if a contiguous sequence of three
      or more classic CE packets from one bottleneck arrived at the
      next, which should in itself happen very rarely with a good AQM.
      The risk would be completely eliminated in AQMs that were
      transport-aware (but they should not need to be);


Bob

On 12/11/16 16:04, Bob Briscoe wrote:
Mirja,

Sorry, it's become rather hard to follow my replies, given sent in pieces. I've tagged the questions and answers to make it clearer:

On 12/11/16 12:53, Bob Briscoe wrote:
Mirja,

The previous response only addressed your first question, 'cos I sent in haste ( I had to go offline to board the flight). Below I address the other questions.

On 12/11/16 12:21, Bob Briscoe wrote:
Mirja,

It's great you've managed to find time to finish the implementation - well done!
Pity I didn't find time to reply sooner :O
inline...


On 31/10/16 12:00, Mirja Kühlewind wrote:
Hi Bob, hi Richard,

I’ve submitted a new version of this draft with only minor changes. I finished my implementation but still have to do some testing. Current code is here:

https://github.com/mirjak/linux-accecn

This is really not tested carefully I but have right now some problems with my testing environment… anyway wanted to submit a new draft version before the deadline. However, given my current implementation is, as far as I can tell now, complete, I believe the spec is fins.

I only have a few comments/questions regarding the fall-back rules we describe in the drafts (sec. 3.2.4):
Q1 - we don’t say anything about retransmitting the SYN. Should a retransmitted SYN try to negotiate AccECN or not, or are we relying on the classic ECN fall-back rules in this case (which would be clearing the ECN flags)?
A1 - Good point - I was (we were?) thinking about the option being blocked by a middlebox, but not the AccECN flags in the main header.

We need to allow plenty of implementer choice here, but give a good default. The default depends on how likely an AccECN SYN will be dropped because of the AccECN flags. I think your tests [PAM paper] found no drop due to these flags.

So, here's some suggesting text:

Measurement tests [PAM paper] so far have found that it is extremely rate for middleboxes to drop a SYN just because all three ECN flags are set (i.e. it is negotiating to use AccECN). Therefore, if the sender of an initial AccECN SYN times out waiting for the SYN/ACK it will more likely be due to congestion loss than middlebox interference. This suggests the following strategy will maximize the chances of using AccECN while minimizing delay.

If the sender of an AccECN SYN times out before receiving the SYN/ACK, the sender SHOULD attempt to negotiate the use of AccECN at least one more time by continuing to set all three TCP ECN flags on the first retransmitted SYN. If this first retransmission also fails to be acknowledged, the sender SHOULD send subsequent retransmissions of the SYN without any ECN flags set.

This adds delay, but no more delay than normal, if the cause was congestion. In the case that a middlebox drops an AccECN (or ECN) SYN deliberately, this strategy will add delay, but current measurements show this case is likely to be rare.

Implementers MAY use other fall-back strategies if they
are found to be more effective (e.g. attempting
to retransmit an AccECN SYN more than once, (most appropriate during
high levels of congestion); or falling back to classic ECN feedback
rather than non-ECN).
, or cached knowledge associated with the remote host.

Nit in 3.2.4: s/tha/that/

I believe there was a bug where the Linux connection-manager got into a black-holing state if it didn't support the TFO option. Even tho the bug was fixed, there are likely to be bugged Linux routers out there. So we need to check the black hole doesn't apply to AccECN SYNs as well. If it does, we will need to suggest restarting a new connection as a fall-back. I'll check the details.


Bob


Q2 - What if we receive a second SYN with AccECN negotiation? We would probably send a SYNACK that negotiates AccECN but no Option, assuming that the SYNACK was lost, right? And then probably also go into a mode where we don’t send the option anymore..? We don’t say anything about this case in the draft.
A2 - The trouble is that SYN/ACKs are just as likely to be lost due to congestion (e.g. found this in our L4S testing). But I agree that, in this case, I think send the SYN/ACK without the option, but try to include the option pretty soon afterwards.

Rest of email will follow when I land...


Bob

Q3 - Also should we add a sentence that one could monitor the segments that carry an option and if it is much more likely that such a segment would be lost, then disable sending the option? Of current that only works for segments that carry data as well.
A3 Yes. 3.2.4 seems like the best place for that as well.
Q4 - And finally we probably should to add an experimentation section, where we say that the question which fallbacks are actually needed must be investigated by experimentation. (Currently I only implemented clearing of the ECN flags when retransmitting a segment with the SYN flag set). Then we could also move any text we would like to keep from Appendix C into this section.

A4 - We have 1.3 for this: "Experiment Goals". We could add a sentence saying most of the issues that need experimental verification concern path traversal.
Q5 - Also another side mark: I currently implemented AccECN and increase the respective counters but don’t use them of course. Maybe we should add one section in the draft that is directed to people that would like to use these counters of an existing implementation, e.g. adding a warning that counters might not increase even if AccECN is negotiation because options could be stripped, and that the CE packet counter could increase differently as it includes control packets without data and therefore usually both values should be checked… we say this all in the draft somewhere but maybe it be good to has this summarized in some kind of ‚usage‘ section…?

A5 Yes. Perhaps "AccECN Usage Examples"

And this would be a good place to talk about behaviour that depends on other parallel updates to ECN that are in progress (whether experimental or PS), e.g.:

ecn-fallback:
Perhaps this (informative?) usage section could also repeat relevant stuff from ecn-fallback that isn't specific to AccECN, but applies generally to ECN TCP.

generalized-ecn:
This usage section would also be a good place to address open issue #3 (Appx C). But I'm not clear where to define the normative behaviour concerning the interationc between ECT control packets and AccECN. It would be really odd to talk about the details of AccECN counters in generalized-ecn. But it is hard to talk about generalized ECN in the AccECN draft, because it is not yet a WG draft, and we really don't want to hold back AccECN.

More Nits
In 3.3:
s/intervene/intervenes/

I guess we could prepare these changes (if any) and submit IETF Monday (if not today again) and ask for wglc in tcpm…?

Mirja



Am 31.10.2016 um 12:21 schrieb internet-drafts@ietf.org:


A new version of I-D, draft-ietf-tcpm-accurate-ecn-02.txt
has been successfully submitted by Mirja Kühlewind and posted to the
IETF repository.

Name:        draft-ietf-tcpm-accurate-ecn
Revision:    02
Title:        More Accurate ECN Feedback in TCP
Document date:    2016-10-31
Group:        tcpm
Pages:        37
URL: https://www.ietf.org/internet-drafts/draft-ietf-tcpm-accurate-ecn-02.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02
Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-02

Abstract:
   Explicit Congestion Notification (ECN) is a mechanism where network
   nodes can mark IP packets instead of dropping them to indicate
   incipient congestion to the end-points.  Receivers with an ECN-
   capable transport protocol feed back this information to the sender.
   ECN is specified for TCP in such a way that only one feedback signal
   can be transmitted per Round-Trip Time (RTT).  Recently, new TCP
   mechanisms like Congestion Exposure (ConEx) or Data Center TCP
   (DCTCP) need more accurate ECN feedback information whenever more
   than one marking is received in one RTT.  This document specifies an
   experimental scheme to provide more than one feedback signal per RTT
   in the TCP header.  Given TCP header space is scarce, it overloads
   the three existing ECN-related flags in the TCP header and provides
   additional information in a new TCP option.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat 



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------C0522C4F03029748F1697AE4-- From nobody Sun Nov 20 14:24:34 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D951294A7 for ; Sun, 20 Nov 2016 14:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7i3LowcHxiBX for ; Sun, 20 Nov 2016 14:24:31 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE02128874 for ; Sun, 20 Nov 2016 14:24:31 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id v84so142782959oie.3 for ; Sun, 20 Nov 2016 14:24:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mN0b3ulUuV5IqIcGn2N1fjfksZyOnJjpAx2cQRBxlzY=; b=TNrW37sIK2OGVQLNqmE1YoBhu1ak3m5eUu+GGAiIXly+oGgX5w6g33/f/Go9r73ToU iz11oLvQLkRXhQjPQ7AfT8jZLrD+xkshXV/zJbipMO0ib+Qw32Hdgi6pvyVIKlkOFp/J fH0wmgWBqZyKQRI/uwaL9Rc5jnte9+OrqNOdExEJ4/pn28qNWrvXo62Ia/vjALm14Q9U IExbsqzc6irEFeqovtxCPfe2+fZ6L2JU2yszcaTUeIdQ9ErOQrCJOu+lUxxT37f8VxGE TWd0rY2uR4t/LzBV01Fwrr+Q6HONbnO0lTFYS4a2/v/UPm3/WLBNziEp+iiFCbRHmNBn PMoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mN0b3ulUuV5IqIcGn2N1fjfksZyOnJjpAx2cQRBxlzY=; b=BmvyGQgRNS4SK/svc95nKxBv5OeZig7f/aO/c6tro6Fdmp7rxTSmT43ocPqPbkHwgv 9QQbqJbHVGgg24EhFg8P7d3cMO0nY03UTp42eCbwvGt32iDNyMY3TQatGqhSbzPvI5N1 3AvP0eNYcPuCQaa86DX2cbl5q1yA3SKLmyJiEiVEEXdgHbAOCs6hqvF2OQ3GvWxQLIJR YXY3XqNx1wCVLsf5o717MDShj1dlNsBoWU1xE0kZLvILo3kxIk6vCYbnQvHGOS8+dnd2 wx57F5n2tTSAeAEdQapUaXbqWD/D7H1HlOZh4fxEROmIkjEbHTNrmpmso2+Piv/XT1U5 Mf3g== X-Gm-Message-State: AKaTC03nag3NVHrkPd7CUlTVQ4kArTMO6dElUWj1dTN7+8gS2DCXU8DEsZYmIWpX30hnNrvKQX9o+8kP3oNZvoXX X-Received: by 10.157.53.50 with SMTP id o47mr6396505otc.19.1479680670865; Sun, 20 Nov 2016 14:24:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.199.17 with HTTP; Sun, 20 Nov 2016 14:23:59 -0800 (PST) From: Neal Cardwell Date: Sun, 20 Nov 2016 17:23:59 -0500 Message-ID: To: Stephen Bensley , "Eggert, Lars" , Dave Thaler , Praveen Balasubramanian , Glenn Judd , "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [tcpm] draft-ietf-tcpm-dctcp-03 and cwnd increase X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 22:24:33 -0000 In reading https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-03 I noticed the passage: A DCTCP sender MUST deal with loss episodes in the same way as conventional TCP. In case of a timeout or fast retransmit or any change in delay (for delay based congestion control), the cwnd and other state variables like ssthresh must be changed in the same way that a conventional TCP would have changed them. However, I couldn't find a corresponding passage in the draft about how cwnd is increased. I didn't see a mention of the word "increase", or slow start, or congestion avoidance, or a reference to DCTCP inheriting RFC5681 behavior for cwnd increase. The SIGCOMM 2010 paper is clear on this point: "The only difference between a DCTCP sender and a TCP sender is in how each reacts to receiving an ACK with the ECN-Echo flag set. Other features of TCP such as slow start, additive increase in congestion avoidance, or recovery from packet lost are left unchanged." And the Linux DCTCP code is clear as well, since it uses tcp_reno_cong_avoid(), meaning it inherits the standard Reno behavior of slow start and congestion avoidance. So I presume the intent of the IETF standard DCTCP would be the same as the SIGCOMM 2010 DCTCP paper and Linux DCTCP code, which is to say cwnd increase would be like Reno/RFC5681. But IMHO it would be useful for the draft to have explicit language to this effect as well. Apologies if I just missed it. cheers, neal From nobody Mon Nov 21 06:28:02 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82547129A75; Mon, 21 Nov 2016 06:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfPvuGB5g2zo; Mon, 21 Nov 2016 06:27:42 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5781112967D; Mon, 21 Nov 2016 06:27:42 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1c8pZM-0002aP-4u; Mon, 21 Nov 2016 15:27:40 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 39DBBB0025A; Mon, 21 Nov 2016 15:27:57 +0100 (CET) To: Bob Briscoe , tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list References: From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Mon, 21 Nov 2016 15:27:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1479738460. Archived-At: Subject: Re: [tcpm] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 14:27:44 -0000 Hi Bob and all, see below. Am 01.11.2016 um 01:02 schrieb Bob Briscoe: > A few people have been working away to specify and document all the > aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) > service, which held a successful BoF in Berlin. As the decision was to > try to work across multiple WGs, I thought it would be useful to give ... Thanks for putting this together. > * Dual Queue Coupled AQM > o With Curvy RED for Linux (access available shortly) > o With PI2 for Linux [*UPDATED*] I'll repeat my concerns that I already expressed at the L4S BOF in Berlin: While I agree that we probably need to separate low-delay congestion control schemes from traditional "queue-filling" congestion schemes, I strongly suggest to avoid putting a congestion control-specific coupling scheme into the network (a classic case for applying the "end-to-end arguments in system design"). The current Dual queue coupled AQM proposal has got a coupling based on a congestion control specific dropping law p_C=(p_L/2)². So if congestion control schemes change then this coupling needs to be adapted. For example, the currently proposed scheme may fail if that vast majority of TCP traffic is using BBR other some other forthcoming CC scheme instead of Cubic, Reno, Compound etc. The same applies to draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping likelihood is defined. Regards, Roland From nobody Tue Nov 22 06:35:15 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE543129A31; Tue, 22 Nov 2016 06:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hCvR9R4Aa6X; Tue, 22 Nov 2016 06:35:10 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3666129A32; Tue, 22 Nov 2016 06:35:08 -0800 (PST) X-AuditID: c1b4fb2d-0bbff70000000994-3d-5834579a78fc Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 2B.25.02452.A9754385; Tue, 22 Nov 2016 15:35:07 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 22 Nov 2016 15:35:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JSHM/0OUFhHIn5RGOnp/Kg57Lkxpn9QEhr1rxGpBHc=; b=glHPGBWAUAIijOAoorT9dOIIFXuUwyyNuSpIjsfYeYuCsAc8zughLWCroYACjZfvH+sNtl8I03Tv0JXRJNHw72MERxtq2GolkN7eQZ50bDDTVEqHKgQPX0msj508XyYuPIIWl8jpncUbymTFDXUwSF9RfqACvwYhkuQEDqn6tMg= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Tue, 22 Nov 2016 14:35:05 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0747.006; Tue, 22 Nov 2016 14:35:05 +0000 From: Ingemar Johansson S To: "Bless, Roland (TM)" , Bob Briscoe , tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list Thread-Topic: [tcpPrague] [aqm] L4S status update Thread-Index: AQHSRDIMrBiIIyXAnkeCaadJdlnwcqDlDZUg Date: Tue, 22 Nov 2016 14:35:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.89] x-ms-office365-filtering-correlation-id: 62566d1f-6b6e-4083-9074-08d412e4c093 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB348; x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:6yJcwqJnmZQ9ndDPm4o1Q4nSqtQmLg+a7XDcw7Ixf7GtXwjLgYor9ipjwZAe/FzcgcGKyGS6bbiXnD+/KE9XF+g3BomcG2plWUnuP92oT3Kc9Avzf0+woQk0/GIRt5NGUigCw2KRwISUNYcsXTBJmz/jHNF0eb1mV/VEjn1/Eunoj8cYam0v4/32S2IhHfPO4WIwGJYVtg1JTN5Yt3FSixOhQ5u4TyropBQa63VnUcfa40YbbcKD/aMjn0xAwcjzbbf60bzaQ3DWPapF5zhJycUgNVzf78ifC9hKwFIlK1N33+BHhkcDJscxsxgCzFvYxNHZKXhg5+zQ1r22HAShKadQfK5sC2nvesLeffirGmqw+NiyCQjKmAui5ZeOY+C/CZXiL0ttDAaCn2chqauhs6hf/3UJT3q7iNMk0dqAMNFvNzvcnHTbh23KsjcGTu1NHr92hmj8Bk+kWyYlGncOLg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6041248); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(13464003)(189002)(5001770100001)(97736004)(3846002)(68736007)(15650500001)(8676002)(3660700001)(229853002)(106356001)(6116002)(106116001)(92566002)(105586002)(561944003)(101416001)(107886002)(102836003)(189998001)(76176999)(50986999)(7736002)(33656002)(74316002)(2950100002)(7846002)(8936002)(305945005)(2906002)(54356999)(2900100001)(76576001)(7696004)(2171001)(81156014)(6506003)(3280700002)(38730400001)(122556002)(66066001)(5660300001)(86362001)(77096005)(81166006)(9686002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 14:35:05.7240 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOXsvex1OTkvxcZnUyKBS81atFFEQEqkwi7YkqKFvupwX9pqk 9EFKA29llJWGOctMNzMcZlZe560huiQlMy9kZl4KQYJllub2GvTtd87v/5yH5+EwhKSMkjLq 5DRWm6zSyGgRWaJ8ofC+rwhU+g5+wfLaVjd59ycdJV8qukvJG83lAnlxVgcp7/k2TofSEfOT b6mIysplQYSuoomIImJEwXGsRp3OaveGnBMlGGazyVS99NKPgd9kFrrukoccGMCB8Ef/ks5D IkaC6xD0DjZT/OENgvlsi92QuJCA/Kl2oa1EgosF0HYlmk/1IKhYsVA2QeNgqDFZkU044wkE Y/nDhE1sxr4wUTBL29gZ+4F+7bWQZ3/In+izZ0jsCUN3bpI2FuMYqO0uWH+IWe+ghWrDeRs6 4CCY78+0JRDeCpPWCXuawK4wOl0u4MfBUNlsIXh2gbnPqxSfj4WlD4UUf78Nequ/0zwfhZaq 3I38EVjMrrYPDDifhKuNA0JeqGG1v2+jIAh0OUaCD40i6DG2Il64Q4mpc0PUU2C1dAr4dbHw 5GkO4hchhfGh3A12h9mxFqoI7Sr9bwqefWCk+DbN8x6oqlggSu172QTmkmlSh0g9cuFYjkuK 9w/wYbXqWI5LSfZJZtOMaP3TdDSseDchw0KYCWEGyRzFvuEBSgmlSucykkwIGELmLB6KDFRK xHGqjExWm3JWe1HDcia0hSFlruL9NZMKCY5XpbGJLJvKav9ZAeMgzUK39GvPux6cDk+ifkmj ew1Rha11D6eE1uLl2huvjksPqcvi2ttiHT0F7EzcA2TNTAw7DEFOHl4/RW1zc8eEl0NO3Htc YfqaoukMLZPNDAd3Pao/czJgu+vigUjjKT9zptrsRD/7GDPTOezutmPExePavoaIg15tRo8L O9/1livC3stILkHlt5vQcqq//orvVDADAAA= Archived-At: Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 14:35:13 -0000 Hi Roland + others. As regards to comments around other new congestion control algorithms and t= hat they may need adapted dropping likelihood relation between a classic qu= eue and L4S queue. I have not tried out but I suspect that BBR may get an unfair treatment, at= the same time it is possible that other delay based CCs may suffer.=20 They question however if this is a major problem?, one may as well see this= as an incentive to switch over to scalable congestion controls and L4S ? T= here is after all no requirement to stick to a particular congestion contro= l no matter what. ? The question whether or not endpoint dependency should be built into the ne= tworks is of course a valid question but given that the state of the art c= ongestion controls like Reno and Cubic rely on a 1/sqrt(p) function then th= at is perhaps OK ?.=20 There will for a foreseeable time come updated endpoint based congestion co= ntrol algorithms that are optimized for one thing or the other (I am guilt= y too :-). However if one can distinguish between two classes (classic and = L4S) where classic belong to the 1/sqrt(p) family then I believe that it is= possible to solve the problem. If we try find a solution where classic =3D= "all sorts of non-scalable non-L4S dependent congestion controls" then I b= elieve that we easily end up in big problems. /Ingemar > -----Original Message----- > From: Bless, Roland (TM) [mailto:roland.bless@kit.edu] > Sent: den 21 november 2016 15:28 > To: Bob Briscoe ; tsvwg IETF list ; > TCP Prague List ; AQM IETF list ; tcpm > IETF list > Subject: Re: [tcpPrague] [aqm] L4S status update >=20 > Hi Bob and all, >=20 > see below. >=20 > Am 01.11.2016 um 01:02 schrieb Bob Briscoe: > > A few people have been working away to specify and document all the > > aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) > > service, which held a successful BoF in Berlin. As the decision was to > > try to work across multiple WGs, I thought it would be useful to give .= .. >=20 > Thanks for putting this together. >=20 > > * Dual Queue Coupled AQM > > o With Curvy RED for Linux (access available shortly) > > o With PI2 for Linux > > [*UPDATED*] >=20 > I'll repeat my concerns that I already expressed at the L4S BOF in Berlin= : >=20 > While I agree that we probably need to separate low-delay congestion > control schemes from traditional "queue-filling" congestion schemes, I > strongly suggest to avoid putting a congestion control-specific coupling > scheme into the network (a classic case for applying the "end-to-end > arguments in system design"). > The current Dual queue coupled AQM proposal has got a coupling based on a > congestion control specific dropping law p_C=3D(p_L/2)=B2. So if congesti= on > control schemes change then this coupling needs to be adapted. For > example, the currently proposed scheme may fail if that vast majority of = TCP > traffic is using BBR other some other forthcoming CC scheme instead of > Cubic, Reno, Compound etc. The same applies to draft-briscoe-tsvwg-ecn- > l4s-id, section 2.5, where the dropping likelihood is defined. >=20 > Regards, > Roland >=20 From nobody Tue Nov 22 08:45:59 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384CE1297A7; Tue, 22 Nov 2016 08:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oo6pQmvr9HVs; Tue, 22 Nov 2016 08:45:42 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298321296CA; Tue, 22 Nov 2016 08:45:42 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1c9ECR-0004rn-Ei; Tue, 22 Nov 2016 17:45:39 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 2D3FBB00254; Tue, 22 Nov 2016 17:45:58 +0100 (CET) To: Ingemar Johansson S , Bob Briscoe , tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list References: From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <70104ef0-3747-9b47-dcb7-be54fe454443@kit.edu> Date: Tue, 22 Nov 2016 17:45:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1479833139. Archived-At: Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 16:45:44 -0000 Hi Ingemar, my point was that it's probably better to refrain from building CC-specific behavior into network elements as the CC algorithms may evolve faster and in more flexible ways than we can foresee. Thus, it would be good to have a separation (or coupling) scheme that actually doesn't depend on the 1/sqrt(p) dropping law. Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S: > As regards to comments around other new congestion control algorithms > and that they may need adapted dropping likelihood relation between a > classic queue and L4S queue. I have not tried out but I suspect that > BBR may get an unfair treatment, at the same time it is possible that > other delay based CCs may suffer. It would be interesting to see what happens if BBR is sorted into the L4S queue in comparison to what happens if BBR is sorted into the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)). > They question however if this is a major problem?, one may as well > see this as an incentive to switch over to scalable congestion > controls and L4S ? There is after all no requirement to stick to a > particular congestion control no matter what. ? Yes, and that's why I find that built-in coupling law too limiting. > The question whether or not endpoint dependency should be built into > the networks is of course a valid question but given that the state > of the art congestion controls like Reno and Cubic rely on a > 1/sqrt(p) function then that is perhaps OK ?. There will for a > foreseeable time come updated endpoint based congestion control > algorithms that are optimized for one thing or the other (I am > guilty too :-). However if one can distinguish between two classes > (classic and L4S) where classic belong to the 1/sqrt(p) family then I > believe that it is possible to solve the problem. If we try find a > solution where classic = "all sorts of non-scalable non-L4S dependent > congestion controls" then I believe that we easily end up in big > problems. I'm not sure. Maybe we have a class of "queue-filling" CCs and a class of low-delay targeted CCs. Regards, Roland From nobody Tue Nov 22 11:09:56 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EA7129E84; Tue, 22 Nov 2016 11:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vpxT9PSdtGh; Tue, 22 Nov 2016 11:09:42 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B91B129B4C; Tue, 22 Nov 2016 11:09:42 -0800 (PST) Received: from [31.185.252.113] (port=55476 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1c9GRn-0001V6-Qt; Tue, 22 Nov 2016 19:09:40 +0000 To: "Bless, Roland (TM)" References: From: Bob Briscoe Message-ID: Date: Tue, 22 Nov 2016 19:09:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AD7E6DDACF9AC164C6863BEB" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list , AQM IETF list , tsvwg IETF list , TCP Prague List Subject: Re: [tcpm] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 19:09:46 -0000 This is a multi-part message in MIME format. --------------AD7E6DDACF9AC164C6863BEB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Roland, I share your concern about cc-specific AQMs. But that is not a good characterization of what we're doing. On the current Internet, everything is meant to be somewhat "friendly" to the original TCP cc (now spec'd in RFC5681). All sorts of cc's work alongside that, with slightly different "fairness" properties, and only one AQM is needed to cover them all. Nonetheless, Reno is the "lamest", so everyone has to try to "Do (not much) Harm" to the lamest. *Is any AQM CC-neutral?** *Note rule 5 in the AQM Guidelines [RFC7567] "AQM algorithms SHOULD NOT interpret specific transport protocol behaviors." In general, the advice in that section is sound, but I don't think we realized at that time just how subtle this issue is. Since then, I discovered that the autotuning parameter table in the PIE algorithm is designed very precisely around the 1/sqrt(p) rule of Reno (see Fig 5 in the PI^2 paper ). Similarly, the sqrt control law in Codel claims to be dependent on Reno {Note 1}. The point is that these AQMs still work fine with Cubic, Compound, Westwood, etc, because all these ccs were designed to interwork with Reno. {Note 2} The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID spec) is to enable a shift to a completely different "norm", but still coexist with all the 'Classic' cc's that coexisted around the old "norm". The new norm is intended to be just as fuzzy as the old norm {Note 3}. The idea is two fuzzy clouds of congestion controls, around an old and a new norm that are related together. *BBR** *I believe BBR attempts to be 'friendly' to loss-based flows when competing in the same queue. But it's still research, and we don't yet know how good it is at that in all scenarios, although we do have code to test now. Given BBR currently sets Not-ECT, it would classify itself into the Classic queue of a DualQ AQM, and if it coexists with Reno it /should/ coexist with L4S traffic in the other queue. See Koen's recent posting about this. There would be nothing to stop someone designing a variant of BBR that coexisted in the L4S queue with Scalable CCs like DCTCP (the point being that if the bottleneck was not DualQ it would keep delay low and if if the bottleneck was DualQ it would benefit even more from the lower queuing delay there). However, it would have to be a bit more careful about its whole round trip of queue probing, to avoid increasing the delay in the L4S queue. You'll see that I suggested to Neil Cardwell that they consider probing with a few packets rather than a whole window, e.g. the chirping technique that Mirja and I looked into back in 2010 was designed to find the same knee between rate increase and delay increase, with far fewer packets. I thought of a better way of using chirping a few weeks ago, so I will be returning to that too. *Specs** *There is no statement that all L4S cc's MUST adhere to a 1/p rule. The L4S ID draft says: "The inverse proportionality requirement above is worded as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility when defining these specifications." I hope that 'SHOULD' is fuzzy enough - I suspect adding more words would make it less fuzzy. But I would welcome wording to make it even more fuzzy if you would like to engage in wordsmithing. Nonetheless, we are trying to steer a path between a rock and a hard place. Because, to shift to a much calmer waters beyond the rocks, we have to define some number to relate L4S to Classic. I am wary because when ECN was specified, there were attempts to define ECN as different to drop. However, ECN originally ended up "the same as drop" because no-one could muster enough backing behind any particular number to relate the two, so the number '1' won by default (ie. ECN = 1 * drop^1 ). Bob {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time. {Note 2} Actually, I don't believe PIE would work that well with Cubic at v high BDP, once it was far from Reno-friendly, but that's only intuition from the stability analysis, not from actual testing. {Note 3} Indeed, at the moment, when DCTCP is on its own in the L4S queue of the DualQ AQM as coded now, it hits up against a step threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just because we didn't want to change too much about DCTCP at one time. But it's also got some nice properties. This will all need to be discussed as the DualQ AQM is specified more deeply. On 21/11/16 14:27, Bless, Roland (TM) wrote: > Hi Bob and all, > > see below. > > Am 01.11.2016 um 01:02 schrieb Bob Briscoe: >> A few people have been working away to specify and document all the >> aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) >> service, which held a successful BoF in Berlin. As the decision was to >> try to work across multiple WGs, I thought it would be useful to give ... > Thanks for putting this together. > >> * Dual Queue Coupled AQM >> o With Curvy RED for Linux (access available shortly) >> o With PI2 for Linux [*UPDATED*] > I'll repeat my concerns that I already expressed at the L4S BOF in Berlin: > > While I agree that we probably need to separate low-delay congestion > control schemes from traditional "queue-filling" congestion schemes, > I strongly suggest to avoid putting a congestion control-specific > coupling scheme into the network (a classic case for applying the > "end-to-end arguments in system design"). > The current Dual queue coupled AQM proposal has got a coupling based on > a congestion control specific dropping law p_C=(p_L/2)². So if > congestion control schemes change then this coupling needs to be > adapted. For example, the currently proposed scheme may fail if that > vast majority of TCP traffic is using BBR other some other forthcoming > CC scheme instead of Cubic, Reno, Compound etc. The same applies to > draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping > likelihood is defined. > > Regards, > Roland > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------AD7E6DDACF9AC164C6863BEB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Roland,

I share your concern about cc-specific AQMs. But that is not a good characterization of what we're doing.

On the current Internet, everything is meant to be somewhat "friendly" to the original TCP cc (now spec'd in RFC5681). All sorts of cc's work alongside that, with slightly different "fairness" properties, and only one AQM is needed to cover them all. Nonetheless, Reno is the "lamest", so everyone has to try to "Do (not much) Harm" to the lamest.

Is any AQM CC-neutral?
Note rule 5 in the AQM Guidelines [RFC7567]
      "AQM algorithms SHOULD NOT interpret specific transport protocol behaviors."
In general, the advice in that section is sound, but I don't think we realized at that time just how subtle this issue is.

Since then, I discovered that the autotuning parameter table in the PIE algorithm is designed very precisely around the 1/sqrt(p) rule of Reno (see Fig 5 in the PI^2 paper). Similarly, the sqrt control law in Codel claims to be dependent on Reno {Note 1}.

The point is that these AQMs still work fine with Cubic, Compound, Westwood, etc, because all these ccs were designed to interwork with Reno. {Note 2}

The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID spec) is to enable a shift to a completely different "norm", but still coexist with all the 'Classic' cc's that coexisted around the old "norm". The new norm is intended to be just as fuzzy as the old norm {Note 3}. The idea is two fuzzy clouds of congestion controls, around an old and a new norm that are related together.

BBR
I believe BBR attempts to be 'friendly' to loss-based flows when competing in the same queue. But it's still research, and we don't yet know how good it is at that in all scenarios, although we do have code to test now. Given BBR currently sets Not-ECT, it would classify itself into the Classic queue of a DualQ AQM, and if it coexists with Reno it /should/ coexist with L4S traffic in the other queue. See Koen's recent posting about this.

There would be nothing to stop someone designing a variant of BBR that coexisted in the L4S queue with Scalable CCs like DCTCP (the point being that if the bottleneck was not DualQ it would keep delay low and if if the bottleneck was DualQ it would benefit even more from the lower queuing delay there). However, it would have to be a bit more careful about its whole round trip of queue probing, to avoid increasing the delay in the L4S queue. You'll see that I suggested to Neil Cardwell that they consider probing with a few packets rather than a whole window, e.g. the chirping technique that Mirja and I looked into back in 2010 was designed to find the same knee between rate increase and delay increase, with far fewer packets. I thought of a better way of using chirping a few weeks ago, so I will be returning to that too.

Specs
There is no statement that all L4S cc's MUST adhere to a 1/p rule. The L4S ID draft says:
  "The inverse proportionality requirement above is worded
   as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
   when defining these specifications."

I hope that 'SHOULD' is fuzzy enough - I suspect adding more words would make it less fuzzy. But I would welcome wording to make it even more fuzzy if you would like to engage in wordsmithing.

Nonetheless, we are trying to steer a path between a rock and a hard place. Because, to shift to a much calmer waters beyond the rocks, we have to define some number to relate L4S to Classic. I am wary because when ECN was specified, there were attempts to define ECN as different to drop. However, ECN originally ended up "the same as drop" because no-one could muster enough backing behind any particular number to relate the two, so the number '1' won by default (ie. ECN = 1 * drop^1 ).


Bob

{Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time.

{Note 2} Actually, I don't believe PIE would work that well with Cubic at v high BDP, once it was far from Reno-friendly, but that's only intuition from the stability analysis, not from actual testing.

{Note 3} Indeed, at the moment, when DCTCP is on its own in the L4S queue of the DualQ AQM as coded now, it hits up against a step threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just because we didn't want to change too much about DCTCP at one time. But it's also got some nice properties. This will all need to be discussed as the DualQ AQM is specified more deeply.


On 21/11/16 14:27, Bless, Roland (TM) wrote:
Hi Bob and all,

see below.

Am 01.11.2016 um 01:02 schrieb Bob Briscoe:

A few people have been working away to specify and document all the
aspects of the new Low Latency, Low Loss, Scalable throughput (L4S)
service, which held a successful BoF in Berlin. As the decision was to
try to work across multiple WGs, I thought it would be useful to give ...

Thanks for putting this together.


  * Dual Queue Coupled AQM
      o With Curvy RED for Linux (access available shortly)
      o With PI2 for Linux <https://github.com/olgabo/dualpi2> [*UPDATED*]

I'll repeat my concerns that I already expressed at the L4S BOF in Berlin:

While I agree that we probably need to separate low-delay congestion
control schemes from traditional "queue-filling" congestion schemes,
I strongly suggest to avoid putting a congestion control-specific
coupling scheme into the network (a classic case for applying the
"end-to-end arguments in system design").
The current Dual queue coupled AQM proposal has got a coupling based on
a congestion control specific dropping law p_C=(p_L/2)². So if
congestion control schemes change then this coupling needs to be
adapted. For example, the currently proposed scheme may fail if that
vast majority of TCP traffic is using BBR other some other forthcoming
CC scheme instead of Cubic, Reno, Compound etc. The same applies to
draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping
likelihood is defined.

Regards,
 Roland



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------AD7E6DDACF9AC164C6863BEB-- From nobody Tue Nov 22 12:37:43 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8492A129B72; Tue, 22 Nov 2016 12:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eBdAbwW3yhe; Tue, 22 Nov 2016 12:37:28 -0800 (PST) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ED0F129795; Tue, 22 Nov 2016 12:37:28 -0800 (PST) Received: by mail-qt0-x243.google.com with SMTP id n6so4243626qtd.0; Tue, 22 Nov 2016 12:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3SsoJplVkMmbgtJhxpx8FPieAh4oV/A4yIIM2kcOOYw=; b=tj1OVwjr6aCyPIlwJgCpfZykO2ZYnQpsiIt6yAtq5Y6Bd186XXIfAVNgxqY90+vWqY bv8mU5w2xXkYpm3dEd2t0h2iP9Q6r1z2/y+Y3YSb+6G4tC47tdz++Qx2Nv+uhEvKwSvD 7xAQWdUCQUnj5BKZLza0n6Gw4bklSnMhocxVdT55b+VaV27wKhBP++0Iq5XPFcztE2oZ 0RuXq3iAxGxpHUpI+VyCLLhjU6o6gnBrl4WBobRd5wHFS5dxAqu0kt6Xob2TcoSKXTWs BPkeHkDkrJDLFyrP8lcZ+YtHU1kgMWPwWV/T7Z+pm2xCFw8mIRtvi8wzBg7ztDOsDPJE fpYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3SsoJplVkMmbgtJhxpx8FPieAh4oV/A4yIIM2kcOOYw=; b=KcmK+NEDK1vb18CYBhcJe30jYJQcn+HG+0xH5Ue3BfZ7A6nHZBPupGE8V8FcDEmqqI SqIsgIaf2/noQqVVvNXHrVDfq9hx8htcppgwfMLNTD2Hgm6hEKZNJP9STvPH9q9RCC+4 ZwUssGxSHbxyFXI138GhbH2TMvZBxiGm9Is+BkFZXA4UiEHme7+FoHa22hJ32/Bjs7EA wRIDFAVppS8d3RG5nTDne5mz8EFYmyt/5UIkI1d0grTHVFhv4MbnvjfXsVVgSOx2SrDz GuEHvbL5ibYtfmD1KpiR4vxo9n1fiaeliG55EwSYQz3O+qO5tiwQl3O2mnxg9xMHUZ4R Vx9A== X-Gm-Message-State: AKaTC01BxFTDj0BdAQu9pBU0p8cjPgOXhHfcjBmZ7c8y37/77jf3iOPHwwgXH12yi7siBg== X-Received: by 10.25.32.19 with SMTP id g19mr4977942lfg.162.1479847047464; Tue, 22 Nov 2016 12:37:27 -0800 (PST) Received: from [192.168.100.13] (37-33-82-144.bb.dnainternet.fi. [37.33.82.144]) by smtp.gmail.com with ESMTPSA id e78sm6616283lfg.23.2016.11.22.12.37.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Nov 2016 12:37:26 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Tue, 22 Nov 2016 22:37:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <053CE5B0-1879-4A2B-B4E9-8BCDDE5BA482@gmail.com> References: To: Bob Briscoe X-Mailer: Apple Mail (2.3124) Archived-At: Cc: TCP Prague List , tcpm IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tcpm] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:37:35 -0000 > On 22 Nov, 2016, at 21:09, Bob Briscoe wrote: >=20 > {Note 1} I have never got a good answer to my questions on aqm@ietf as = to why a sqrt that controls the shrinkage of the spacing between dropped = packets has something to do with the steady state law of Reno, = particularly because the law leads to linear growth in p over time. If you have intervals between events which follow a 1/sqrt(N) sequence, = where N is the number of preceding events, you get an event frequency = which increases linearly with time. This applies directly to Codel=92s = signalling strategy, which is to start at one mark per (assumed) RTT, = and to increase the marking frequency if that was insufficient to = control the queue. When you have multiple Reno flows sharing a single queue, there is a = sqrt(N) factor in several of the characteristics, where N is the number = of flows. When such a shared link becomes saturated, all of the flows = must be signalled to slow down, but for stochastic reasons it=92ll = probably take more than N signalling events to do so. Increasing the = signalling frequency while the queue remains insufficiently controlled = has a good chance of quickly finding all the flows, while dropping = relatively few packets (of non-ECN flows). I=92m reasonably convinced that Codel is a near-optimal solution to = congestion signalling on TCP-friendly flows. Regrettably, the latter = are not the only type of traffic actually found on the Internet. Really, the central assumption of Codel is that each flow requires only = one congestion signal event per RTT to cause it to back off. Codel = stops working well on traffic which doesn=92t obey that assumption (a = linear increase in drop frequency is inadequate to mitigate a flood - = you need to work with drop probabilities for that), but it *does* work = acceptably well with multiple flows sharing a queue, due to this = operating-point search. - Jonathan Morton From nobody Wed Nov 23 13:39:21 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B0B1294C0 for ; Wed, 23 Nov 2016 13:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=fail (1024-bit key) reason="fail (message has been altered)" header.from=David.Black@dell.com header.d=dell.com; dkim=pass (1024-bit key) header.d=dell.com header.b=dX341+wl; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=rsa.com header.b=qUURBSGB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNXefYrvONpP for ; Wed, 23 Nov 2016 13:39:18 -0800 (PST) Received: from esa7.dell-outbound.iphmx.com (esa7.dell-outbound.iphmx.com [68.232.153.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B7A12943C for ; Wed, 23 Nov 2016 13:39:18 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=simple; q=dns; h=Received:From:Received:Received:X-DKIM:DKIM-Signature: X-DKIM:Received:Received:Received:To:Subject:Thread-Topic: Thread-Index:Date:Message-ID:References:In-Reply-To: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-Transfer-Encoding:MIME-Version: X-Sentrion-Hostname:X-RSA-Classifications; b=gugDBG4qOhEfqKfLRQec19iEzFRb4ZIfslEwIcSnEtUAUpbcKQPYhJwU SbF/nrDebl2AxSvTyYgaJ22J7/sG5WmQH685hH4mEPhUvR22fmVxwE3iL F9in/YuTXM22hDRRtcb+xud43mnEWGhfCrzWLQZ2uDcXC7VDntfhigePW 0=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1479937158; x=1511473158; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TFPxdBCm0ryHkKfVP66J5WgiR7CiTi7BOmgHLZxHKw4=; b=dX341+wlE3TgkeONgJn38JzBFzjHqkOIpImXcM7z4sg0biqLcWr0pToF 9vGqG0eiOVdEGoSpl0vHGoJZG0tFrtMijYK1Ir/8I+O1Zrchgz/T0u3NJ kaCzaO3aksejvGRz7WVW9X0AMT1ZH5eHC/tq7Zm0Ne5EPvPoByt1GUJe+ Y=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa7.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2016 15:39:17 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Nov 2016 03:39:16 +0600 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd05.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uANLdFUg007074 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Nov 2016 16:39:16 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com uANLdFUg007074 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=rsa.com; s=jan2013; t=1479937156; bh=O5RelGjwZwilD4MaGEDIvyIJ8nw=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=qUURBSGBBFPN2fbxXNoImJ88W98lRupKI3qmKh/AzWWXeWBg4WPH9VYJ5uRnvPWfb raB317JXuhuZh3sTX03Kj5mNowMAgZXaOI998WCaykEb7x8hCSZ4c0cRNrE4Y6MPIC 2J82OiTIxnORm5Kk1NBv2A8GabwPVD6hf44QUFXI= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd05.lss.emc.com uANLdFUg007074 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor) for ; Wed, 23 Nov 2016 16:38:50 -0500 Received: from MXHUB304.corp.emc.com (MXHUB304.corp.emc.com [10.146.3.30]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id uANLcxhB015006 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL) for ; Wed, 23 Nov 2016 16:38:59 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB304.corp.emc.com ([10.146.3.30]) with mapi id 14.03.0266.001; Wed, 23 Nov 2016 16:38:59 -0500 To: "tcpm@ietf.org" Thread-Topic: The TSVWG WG has placed draft-black-tsvwg-ecn-experimentation in state "Call For Adoption By WG Issued" Thread-Index: AQHSRa7MvcnAWEbP8EWhcvJZ/Jo4DaDnEmpggAAGFlA= Date: Wed, 23 Nov 2016 21:38:58 +0000 Message-ID: References: <147992201755.8320.2637448149704654629.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tcpm] FW: The TSVWG WG has placed draft-black-tsvwg-ecn-experimentation in state "Call For Adoption By WG Issued" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:39:20 -0000 RllJLCBwbGVhc2UgY29tbWVudCBvbiB0aGUgVFNWV0cgbGlzdCwgVGhhbmtzLCAtLURhdmlkDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCbGFjaywgRGF2aWQNClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMjMsIDIwMTYgNDoyNSBQTQ0KVG86IHRzdndnQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3RzdndnXSBUaGUgVFNWV0cgV0cgaGFzIHBsYWNlZCBkcmFmdC1ibGFjay10c3Z3Zy1l Y24tZXhwZXJpbWVudGF0aW9uIGluIHN0YXRlICJDYWxsIEZvciBBZG9wdGlvbiBCeSBXRyBJc3N1 ZWQiDQoNCldyaXR0ZW4gYXMgZHJhZnQgYXV0aG9yLCAqbm90KiBXRyBjaGFpciwgaGVyZSBhcmUg YSBmZXcgbW9yZSBkZXRhaWxzLg0KDQo+IEZvbGxvd2luZyBkaXNjdXNzaW9uIGF0IHRoZSBJRVRG IG1lZXRpbmcgaW4gU2VvdWwsIHRoaXMgZW1haWwgc3RhcnRzIGENCj4gZm9ybWFsIGFkb3B0aW9u IGNhbGwgZm9yIHRoZSBhYm92ZSBwcm9jZXNzIGRyYWZ0LiBUaGUgZHJhZnQsIGlmIGFkb3B0ZWQN Cj4gd2lsbCBmb3JtIHRoZSAqQkFTSVMqIGZvciBhIFBTIFVwZGF0ZSB0byBSRkMgMzE2OCwgYWxs b3dpbmcgdGhlIHdheSBmb3INCj4gZXhwZXJpbWVudGF0aW9uIHVzaW5nIHRoZSBFQ1QgY29kZXBv aW50IGJ5IHB1YmxpY2F0aW9uIG9mIEV4cGVyaW1lbnRhbA0KPiBSRkNzLiBUaGUgZG9jdW1lbnQg YWxzbyBwcm9wb3NlcyBlbmRpbmcgdGhlIHByZXZpb3VzIElFVEYgZXhwZXJpbWVudA0KPiBrbm93 biBhcyB0aGUgIkVDTiBOb25jZSIuDQoNClRoaXMgZHJhZnQgYWxzbyBlbmFibGVzIGV4cGVyaW1l bnRhdGlvbiB3aXRoIGRpZmZlcmVudCBzZW5kZXIgcmVzcG9uc2VzDQp0byBFQ04tZGV0ZWN0ZWQg Y29uZ2VzdGlvbiAoQ0UtbWFya2VkIHBhY2tldHMpIGJ5IGNvbXBhcmlzb24gdG8gZHJvcHMsDQph bmQgd2l0aCB1c2Ugb2YgRUNOIG9uIFRDUCBjb250cm9sIHBhY2tldHMgYW5kIHJldHJhbnNtaXR0 ZWQgcGFja2V0cy4NCkRyYWZ0cyBmb3IgdGhlc2UgdHdvIGFyZWFzIG9mIGV4cGVyaW1lbnRhdGlv biBhcmUgYmVpbmcgaGFuZGxlZCBieQ0KdGhlIFRDUE0gV0cgLSBpbiBjb250cmFzdCwgTDRTIGlz IGV4cGVjdGVkIHRvIGJlIGhhbmRsZWQgYnkgdGhlIFRTVldHDQpXRy4gIEFsc28sIHRoZSBFQ1Qg Y29kZXBvaW50IGludGVuZGVkIGZvciBleHBlcmltZW50YXRpb24gaXMgRUNUKDEpLg0KDQpJIHdh bnQgdG8gZW1waGFzaXplICIqQkFTSVMqIiBhYm92ZS4gIFRoaXMgaXMgb25seSBhbiBhZG9wdGlv biBjYWxsIC0gdGhlIHRleHQNCmluIHRoaXMgZHJhZnQgd2lsbCBhbG1vc3QgY2VydGFpbmx5IGJl IG1vZGlmaWVkIGJlZm9yZSB0aGUgV0cgaXMgZG9uZSB3aXRoIHRoaXMNCmRyYWZ0Lg0KDQpPcHBv c2luZyBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0IGlzIGVmZmVjdGl2ZWx5IHRha2luZyB0aGUgcG9z aXRpb24gdGhhdCBvbmUgb3INCm1vcmUgb2YgdGhlIHJlZmVyZW5jZWQgZXhwZXJpbWVudHMgYXJl IHZlcnkgYmFkIGlkZWFzIHRoYXQgc2hvdWxkIG5vdCBiZQ0KcHVyc3VlZC4NCg0KVGhhbmtzLCAt LURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSUVURiBTZWNy ZXRhcmlhdCBbbWFpbHRvOmlldGYtc2VjcmV0YXJpYXQtcmVwbHlAaWV0Zi5vcmddDQo+IFNlbnQ6 IFdlZG5lc2RheSwgTm92ZW1iZXIgMjMsIDIwMTYgMTI6MjcgUE0NCj4gVG86IHRzdndnQGlldGYu b3JnOyB0c3Z3Zy1jaGFpcnNAaWV0Zi5vcmc7IGRyYWZ0LWJsYWNrLXRzdndnLWVjbi0NCj4gZXhw ZXJpbWVudGF0aW9uQGlldGYub3JnDQo+IFN1YmplY3Q6IFRoZSBUU1ZXRyBXRyBoYXMgcGxhY2Vk IGRyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24gaW4NCj4gc3RhdGUgIkNhbGwg Rm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCINCj4gDQo+IA0KPiBUaGUgVFNWV0cgV0cgaGFzIHBs YWNlZCBkcmFmdC1ibGFjay10c3Z3Zy1lY24tZXhwZXJpbWVudGF0aW9uIGluIHN0YXRlDQo+IENh bGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCAoZW50ZXJlZCBieSBHb3JyeSBGYWlyaHVyc3Qp DQo+IA0KPiBUaGUgZG9jdW1lbnQgaXMgYXZhaWxhYmxlIGF0DQo+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJsYWNrLXRzdndnLWVjbi1leHBlcmltZW50YXRpb24vDQo+ IA0KPiANCj4gQ29tbWVudDoNCj4gRm9sbG93aW5nIGRpc2N1c3Npb24gYXQgdGhlIElFVEYgbWVl dGluZyBpbiBTZW91bCwgdGhpcyBlbWFpbCBzdGFydHMgYQ0KPiBmb3JtYWwgYWRvcHRpb24gY2Fs bCBmb3IgdGhlIGFib3ZlIHByb2Nlc3MgZHJhZnQuIFRoZSBkcmFmdCwgaWYgYWRvcHRlZA0KPiB3 aWxsIGZvcm0gdGhlICpCQVNJUyogZm9yIGEgUFMgVXBkYXRlIHRvIFJGQyAzMTY4LCBhbGxvd2lu ZyB0aGUgd2F5IGZvcg0KPiBleHBlcmltZW50YXRpb24gdXNpbmcgdGhlIEVDVCBjb2RlcG9pbnQg YnkgcHVibGljYXRpb24gb2YgRXhwZXJpbWVudGFsDQo+IFJGQ3MuIFRoZSBkb2N1bWVudCBhbHNv IHByb3Bvc2VzIGVuZGluZyB0aGUgcHJldmlvdXMgSUVURiBleHBlcmltZW50DQo+IGtub3duIGFz IHRoZSAiRUNOIE5vbmNlIi4NCj4gDQo+IENvbW1lbnRzIGFyZSB3ZWxjb21lIG9uIHRoZSBsaXN0 IHRvIGluZGljYXRlIGlmIHN1Y2ggYSBkb2N1bWVudCBpcw0KPiBjb25zaWRlcmVkIHVzZWZ1bCBm b3IgdGhlIElFVEYgdG8gcHVibGlzaCwgb3IgZXhwcmVzc2luZyBjb25jZXJucyBhYm91dA0KPiBh bnkgb2YgdGhlc2UgdG9waWNzLiBZb3UgbWF5IGFsc28gc2VuZCBjb21tZW50cyBvbiB0aGUgY3Vy cmVudCB0ZXh0IChhbmQNCj4gdGhlc2UgYXJlIHdlbGNvbWUpLCBidXQsIGlmIHlvdSBkbywgcGxl YXNlIGFsc28gY2xlYXJseSBpbmRpY2F0ZSBpZiB5b3UNCj4gc3VwcG9ydCB0aGUgcHJvZ3Jlc3Mg b2Ygd29yayBvbiB0aGlzIHRvcGljIHdpdGhpbiBUU1ZXRy4NCj4gDQo+IEFsbCBjb21tZW50cyBu ZWVkIHRvIGJlIHJlY2VpdmVkIGJ5IDl0aCBEZWMgMjAxNiwgYWZ0ZXIgd2hpY2ggYSBkZWNpc2lv bg0KPiB3aWxsIGJlIG1hZGUgb24gaG93IHRvIHByb2dyZXNzLiAoWW91IG1heSByZWFkIGFib3V0 IHRoZSBhZG9wdGlvbiBwcm9jZXNzDQo+IGluIFJGQzcyMjEuKQ0K From nobody Thu Nov 24 09:06:18 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BC3129489; Thu, 24 Nov 2016 09:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ve_rbaBVwfZ; Thu, 24 Nov 2016 09:06:10 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2F81295F2; Thu, 24 Nov 2016 08:57:17 -0800 (PST) Received: from i72t450mh.tm.uni-karlsruhe.de ([141.3.71.47]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587 iface 141.3.10.81 id 1c9xKl-0000bW-Tj; Thu, 24 Nov 2016 17:57:15 +0100 To: Bob Briscoe , "Bless, Roland (TM)" References: From: Mario Hock Message-ID: <67730f0d-7ee4-1366-1aaf-847b73e6b146@kit.edu> Date: Thu, 24 Nov 2016 17:57:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1480006635. Archived-At: Cc: TCP Prague List , tcpm IETF list , AQM IETF list , tsvwg IETF list Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 17:06:11 -0000 Hello Bob and Roland, I followed your discussion and want to share my opinion, here. (Comments inline). Am 22.11.2016 um 20:09 schrieb Bob Briscoe: > *Is any AQM CC-neutral?** > *Note rule 5 in the > AQM Guidelines [RFC7567] > "AQM algorithms SHOULD NOT interpret specific transport protocol > behaviors." > In general, the advice in that section is sound, but I don't think we > realized at that time just how subtle this issue is. > > Since then, I discovered that the autotuning parameter table in the PIE > algorithm is designed very precisely around the 1/sqrt(p) rule of Reno > (see Fig 5 in the PI^2 paper ). > Similarly, the sqrt control law in Codel claims to be dependent on Reno > {Note 1}. > > The point is that these AQMs still work fine with Cubic, Compound, > Westwood, etc, because all these ccs were designed to interwork with > Reno. {Note 2} The reason that the AQMs also work with these CCs is because the CCs still have a lot in common with TCP Reno, like that they use a congestion window, that they increase the CWnd up until packet loss etc. Also the 1/sqrt(p)-law is still, more or less, applicable to them. For newer CCs like BBR or PCC, the 1/sqrt(p) does not apply. They are based i.a. on throughput vs. loss/delay probing. BRR, for example, does not even use a congestion window (at least not in the same way as the other CCs do). > The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID > spec) is to enable a shift to a completely different "norm", but still > coexist with all the 'Classic' cc's that coexisted around the old > "norm". The new norm is intended to be just as fuzzy as the old norm > {Note 3}. The idea is two fuzzy clouds of congestion controls, around an > old and a new norm that are related together. I agree with the general idea. But from that reasoning newer CCs, like BBR, belong into the "new" queue, where L4S lives in! If they don't belong in the same queue as L4S, then the queues should not be coupled in the way you propose. This coupling prevents any innovation in the non-L4S queue. > > *BBR** > *I believe BBR attempts to be 'friendly' to loss-based flows when > competing in the same queue. But it's still research, and we don't yet > know how good it is at that in all scenarios, although we do have code > to test now. Given BBR currently sets Not-ECT, it would classify itself > into the Classic queue of a DualQ AQM, and if it coexists with Reno it > /should/ coexist with L4S traffic in the other queue. See Koen's recent > posting > > about this. > > There would be nothing to stop someone designing a variant of BBR that > coexisted in the L4S queue with Scalable CCs like DCTCP (the point being > that if the bottleneck was not DualQ it would keep delay low and if if > the bottleneck was DualQ it would benefit even more from the lower > queuing delay there). However, it would have to be a bit more careful > about its whole round trip of queue probing, to avoid increasing the > delay in the L4S queue. You'll see that I suggested to Neil Cardwell > that they consider probing with a few packets rather than a whole > window, e.g. the chirping > technique that Mirja > and I looked into back in 2010 was designed to find the same knee > between rate increase and delay increase, with far fewer packets. I > thought of a better way of using chirping a few weeks ago, so I will be > returning to that too. I think L4S is not studied well enough, yet to be standardized in a way that other low delay approaches must adjust to the L4S concepts. There is at least BBR, PCC, nv (New Vegas) currently under development that all bring in fresh ideas how congestion control could be made in the future. Standardizing L4S as "the" new concept without intensively study other approaches is just too soon. If we want to act now, we should focus on a solution that enables new approaches in congestion control but is not tailored to either Reno/Cubic or L4S/DCTCP. Otherwise more research is required how we want the future of congestion control look like. Best regards, Mario Hock From nobody Thu Nov 24 12:48:11 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23E9129CD5; Thu, 24 Nov 2016 12:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iao9TOjApXZS; Thu, 24 Nov 2016 12:48:05 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D5C129CBD; Thu, 24 Nov 2016 12:48:04 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1cA0w7-0006CM-EE; Thu, 24 Nov 2016 21:48:03 +0100 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 26ABDB0033C; Thu, 24 Nov 2016 21:48:25 +0100 (CET) From: "Bless, Roland (TM)" To: Bob Briscoe References: Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> Date: Thu, 24 Nov 2016 21:48:02 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1480020483. Archived-At: Cc: tcpm IETF list , AQM IETF list , tsvwg IETF list , TCP Prague List Subject: Re: [tcpm] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 20:48:08 -0000 Hi Bob, see comments inline, please. Am 22.11.2016 um 20:09 schrieb Bob Briscoe: > I share your concern about cc-specific AQMs. But that is not a good > characterization of what we're doing. Yep, but it's part of what you're proposing. > On the current Internet, everything is meant to be somewhat "friendly" > to the original TCP cc (now spec'd in RFC5681). All sorts of cc's work > alongside that, with slightly different "fairness" properties, and only > one AQM is needed to cover them all. Nonetheless, Reno is the "lamest", > so everyone has to try to "Do (not much) Harm" to the lamest. Yes, and that's actually a deployment problem we agree on. Congestion control (CC) innovation is obstructed by the old loss-based CC so some separation mechanism would be good to let room for low-delay CCs. > *Is any AQM CC-neutral?** > *Note rule 5 in the > AQM Guidelines [RFC7567] > "AQM algorithms SHOULD NOT interpret specific transport protocol > behaviors." > In general, the advice in that section is sound, but I don't think we > realized at that time just how subtle this issue is. I think that AQMs could be in fact designed CC neutral to a large extent, but every CC reacts probably different to the drop/ECN signals. So the dropping strategy implemented by the AQM will always cause a CC-specific reaction. Some AQMs therefore may achieve better results if they are tuned to specific CC behavior (but my e2e argument would also apply here), however, right now it's not that easy to change AQM implementations, esp. those implemented in hardware. > Since then, I discovered that the autotuning parameter table in the PIE > algorithm is designed very precisely around the 1/sqrt(p) rule of Reno > (see Fig 5 in the PI^2 paper ). > Similarly, the sqrt control law in Codel claims to be dependent on Reno > {Note 1}. > The point is that these AQMs still work fine with Cubic, Compound, > Westwood, etc, because all these ccs were designed to interwork with > Reno. {Note 2} > > The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID > spec) is to enable a shift to a completely different "norm", but still > coexist with all the 'Classic' cc's that coexisted around the old > "norm". The new norm is intended to be just as fuzzy as the old norm > {Note 3}. The idea is two fuzzy clouds of congestion controls, around an > old and a new norm that are related together. Yes, and I support that basic idea to introduce network support for separating flows with different CC schemes. However, I'd like to have a solution that doesn't build in a specific coupling law, otherwise we will end up with having either TCP friendly or DCTCP friendly CC schemes. > *BBR** > *I believe BBR attempts to be 'friendly' to loss-based flows when > competing in the same queue. But it's still research, and we don't yet > know how good it is at that in all scenarios, although we do have code I'm not sure how friendly/fair BBR is actually to other CCs, but L4S is also still research... > to test now. Given BBR currently sets Not-ECT, it would classify itself > into the Classic queue of a DualQ AQM, and if it coexists with Reno it > /should/ coexist with L4S traffic in the other queue. See Koen's recent > posting > > about this. Hmm, from what I understood so far BBR reacts differently to packet loss than Reno/Cubic etc. So that coupling by dropping probability may not work correctly in this case, because BBR will not react according to 1/sqrt(p) (cf. the FAQ from the BBR slide set presented at IETF97, https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf) > There would be nothing to stop someone designing a variant of BBR that > coexisted in the L4S queue with Scalable CCs like DCTCP (the point being > that if the bottleneck was not DualQ it would keep delay low and if if > the bottleneck was DualQ it would benefit even more from the lower > queuing delay there). However, it would have to be a bit more careful > about its whole round trip of queue probing, to avoid increasing the > delay in the L4S queue. You'll see that I suggested to Neil Cardwell > that they consider probing with a few packets rather than a whole > window, e.g. the chirping > technique that Mirja > and I looked into back in 2010 was designed to find the same knee > between rate increase and delay increase, with far fewer packets. I > thought of a better way of using chirping a few weeks ago, so I will be > returning to that too. That would be interesting... > *Specs** > *There is no statement that all L4S cc's MUST adhere to a 1/p rule. The > L4S ID draft says: > "The inverse proportionality requirement above is worded > as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility > when defining these specifications." I found two MUSTs in these contexts: draft-briscoe-tsvwg-aqm-dualq-coupled-00: In order to prevent starvation of Classic traffic by scalable L4S traffic (e.g. DCTCP) the drop probability of Classic traffic MUST be proportional to the square of the marking probability of L4S traffic, In other words, the power to which p_L is raised in Eqn. (1) MUST be 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 2.5: The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST be roughly proportional to the square of the likelihood that it would have marked it if it had been an L4S packet (p_L). That is p_C ~= (p_L / k)^2 > I hope that 'SHOULD' is fuzzy enough - I suspect adding more words would > make it less fuzzy. But I would welcome wording to make it even more > fuzzy if you would like to engage in wordsmithing. > > Nonetheless, we are trying to steer a path between a rock and a hard > place. Because, to shift to a much calmer waters beyond the rocks, we > have to define some number to relate L4S to Classic. I am wary because > when ECN was specified, there were attempts to define ECN as different > to drop. However, ECN originally ended up "the same as drop" because > no-one could muster enough backing behind any particular number to > relate the two, so the number '1' won by default (ie. ECN = 1 * drop^1 ). That's a different discussion. > Bob > > {Note 1} I have never got a good answer to my questions on aqm@ietf as > to why a sqrt that controls the shrinkage of the spacing between dropped > packets has something to do with the steady state law of Reno, > particularly because the law leads to linear growth in p over time. Yep. However, according to our experiments Codel's dropping law seems to achieve a quite reasonable loss desynchronization. > {Note 2} Actually, I don't believe PIE would work that well with Cubic > at v high BDP, once it was far from Reno-friendly, but that's only > intuition from the stability analysis, not from actual testing. We tested PIE at 10GB/s and it worked with Cubic similarly as at low speeds. > {Note 3} Indeed, at the moment, when DCTCP is on its own in the L4S > queue of the DualQ AQM as coded now, it hits up against a step > threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just > because we didn't want to change too much about DCTCP at one time. But > it's also got some nice properties. This will all need to be discussed > as the DualQ AQM is specified more deeply. So probably it would be good to find out what is the common denominator of _new_ L4S-like CCs (not only considering DCTCP) and what is a common denominator for CCs in the other class. Regards, Roland > On 21/11/16 14:27, Bless, Roland (TM) wrote: >> Hi Bob and all, >> >> see below. >> >> Am 01.11.2016 um 01:02 schrieb Bob Briscoe: >>> A few people have been working away to specify and document all the >>> aspects of the new Low Latency, Low Loss, Scalable throughput (L4S) >>> service, which held a successful BoF in Berlin. As the decision was to >>> try to work across multiple WGs, I thought it would be useful to give ... >> Thanks for putting this together. >> >>> * Dual Queue Coupled AQM >>> o With Curvy RED for Linux (access available shortly) >>> o With PI2 for Linux [*UPDATED*] >> I'll repeat my concerns that I already expressed at the L4S BOF in Berlin: >> >> While I agree that we probably need to separate low-delay congestion >> control schemes from traditional "queue-filling" congestion schemes, >> I strongly suggest to avoid putting a congestion control-specific >> coupling scheme into the network (a classic case for applying the >> "end-to-end arguments in system design"). >> The current Dual queue coupled AQM proposal has got a coupling based on >> a congestion control specific dropping law p_C=(p_L/2)². So if >> congestion control schemes change then this coupling needs to be >> adapted. For example, the currently proposed scheme may fail if that >> vast majority of TCP traffic is using BBR other some other forthcoming >> CC scheme instead of Cubic, Reno, Compound etc. The same applies to >> draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping >> likelihood is defined. >> >> Regards, >> Roland From nobody Fri Nov 25 06:49:21 2016 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDAE12997C; Fri, 25 Nov 2016 06:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ME2Xv-rzNXSS; Fri, 25 Nov 2016 06:49:10 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1BF129ED3; Fri, 25 Nov 2016 06:23:28 -0800 (PST) Received: from [31.185.252.113] (port=34505 helo=[192.168.0.3]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cAHPS-00044q-M1; Fri, 25 Nov 2016 14:23:26 +0000 To: Jonathan Morton References: <053CE5B0-1879-4A2B-B4E9-8BCDDE5BA482@gmail.com> From: Bob Briscoe Message-ID: Date: Fri, 25 Nov 2016 14:23:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <053CE5B0-1879-4A2B-B4E9-8BCDDE5BA482@gmail.com> Content-Type: multipart/alternative; boundary="------------CD4B2AF5D5C493A6434C123F" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tsvwg IETF list , tcpm IETF list , TCP Prague List , AQM IETF list Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 14:49:15 -0000 This is a multi-part message in MIME format. --------------CD4B2AF5D5C493A6434C123F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Jonathan, On 22/11/16 20:37, Jonathan Morton wrote: >> On 22 Nov, 2016, at 21:09, Bob Briscoe wrote: >> >> {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time. > If you have intervals between events which follow a 1/sqrt(N) sequence, where N is the number of preceding events, you get an event frequency which increases linearly with time. Yes, I pointed that out originally . And Toke confirmed in response that it did indeed happen in practice. > This applies directly to Codel’s signalling strategy, which is to start at one mark per (assumed) RTT, and to increase the marking frequency if that was insufficient to control the queue. > > When you have multiple Reno flows sharing a single queue, there is a sqrt(N) factor in several of the characteristics, where N is the number of flows. When such a shared link becomes saturated, all of the flows must be signalled to slow down, but for stochastic reasons it’ll probably take more than N signalling events to do so. Increasing the signalling frequency while the queue remains insufficiently controlled has a good chance of quickly finding all the flows, while dropping relatively few packets (of non-ECN flows). Just throwing a square root in "somewhere", doesn't mean it is the correct "somewhere". A stated goal of the sqrt in the CoDel control law is to match the 1/sqrt(p) in TCP Reno's window formula. Quite aside from whether that is a correct goal, it isn't even doing that: * ACK-clocked load (number of flows, N) is proportional to 1/cwnd, ie. proportional to sqrt(p) [see 2nd para of section 4 of PI2 paper ] * because CoDel applies a sqrt to the interval between drops, it results in a linear increase in p with time (because the sqrt effectively gets squared - see the simple maths in my original posting about this ). So, the question is: "Why is a linear increase in p (starting from 0) good for controlling load from N flows, where N is proportional to sqrt(p)?" > > I’m reasonably convinced that Codel is a near-optimal solution to congestion signalling on TCP-friendly flows. The word "optimal" has a precise meaning. I think you mean simply "I am predisposed to CoDel." Whether the control law increases p linearly with time or by the sqrt, or by any function of time, is not the point anyway. Time is not the correct unit for this control law. The CoDel control law has no variables in it (other than the point at which it starts) that depend on any feature of the traffic. Once the CoDel control law starts, it just blindly increases until it reaches a high enough drop level to control the traffic. So the higher p needs to be, the longer it takes. And the lower p needs to be, the more it will overshoot within a round trip. A constant increase in p with time, and no dependency on the traffic is just plain wrong. No way will that result in anything that anyone could prove was "optimal" even if you put caveats around it like "near-optimal" or "reasonably convincingly near-optimal". Perhaps this helps you to see why claims of near-optimality say more about the political or religious zeal of the person making the claim, than they do about CoDel itself. > Regrettably, the latter are not the only type of traffic actually found on the Internet. > > Really, the central assumption of Codel is that each flow requires only one congestion signal event per RTT to cause it to back off. Codel stops working well on traffic which doesn’t obey that assumption (a linear increase in drop frequency is inadequate to mitigate a flood - you need to work with drop probabilities for that), but it *does* work acceptably well with multiple flows sharing a queue, due to this operating-point search. Similarly, isn't the phrase "acceptably well" another way of saying "We don't need to consider any other AQM that might be better at handling a wider range of load scenarios"? Even though there is already an alternative available that increases the drop level dependent on how fast the queue is growing. This religious belief in a particular technology is not healthy. Please can we have some objectivity here. Regards Bob > > - Jonathan Morton > > _______________________________________________ > tcpPrague mailing list > tcpPrague@ietf.org > https://www.ietf.org/mailman/listinfo/tcpprague -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------CD4B2AF5D5C493A6434C123F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Jonathan,

On 22/11/16 20:37, Jonathan Morton wrote:

      

        
On 22 Nov, 2016, at 21:09, Bob Briscoe <ietf@bobbriscoe.net> wrote:

{Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time.


      

      
If you have intervals between events which follow a 1/sqrt(N) sequence, where N is the number of preceding events, you get an event frequency which increases linearly with time.  

    

    Yes, I pointed that out originally.
    And Toke confirmed in response that it did indeed happen in
    practice.

    

      
This applies directly to Codel’s signalling strategy, which is to start at one mark per (assumed) RTT, and to increase the marking frequency if that was insufficient to control the queue.

When you have multiple Reno flows sharing a single queue, there is a sqrt(N) factor in several of the characteristics, where N is the number of flows.  When such a shared link becomes saturated, all of the flows must be signalled to slow down, but for stochastic reasons it’ll probably take more than N signalling events to do so.  Increasing the signalling frequency while the queue remains insufficiently controlled has a good chance of quickly finding all the flows, while dropping relatively few packets (of non-ECN flows).

    

    Just throwing a square root in "somewhere", doesn't mean it is the
    correct "somewhere". 

    

    A stated goal of the sqrt in the CoDel control law is to match the
    1/sqrt(p) in TCP Reno's window formula. Quite aside from whether
    that is a correct goal, it isn't even doing that:

    * ACK-clocked load (number of flows, N) is proportional to 1/cwnd,
    ie. proportional to sqrt(p) [see 2nd para of section 4 of PI2 paper]

    * because CoDel applies a sqrt to the interval between drops, it
    results in a linear increase in p with time (because the sqrt
    effectively gets squared - see the simple maths in my
      original posting about this).

    

    So, the question is: "Why is a linear increase in p (starting from
    0) good for controlling load from N flows, where N is proportional
    to sqrt(p)?"

    

    

      

I’m reasonably convinced that Codel is a near-optimal solution to congestion signalling on TCP-friendly flows.  

    

    The word "optimal" has a precise meaning. I think you mean simply "I
    am predisposed to CoDel."

    

    Whether the control law increases p linearly with time or by the
    sqrt, or by any function of time, is not the point anyway. Time is
    not the correct unit for this control law. The CoDel control law has
    no variables in it (other than the point at which it starts) that
    depend on any feature of the traffic. Once the CoDel control law
    starts, it just blindly increases until it reaches a high enough
    drop level to control the traffic. So the higher p needs to be, the
    longer it takes. And the lower p needs to be, the more it will
    overshoot within a round trip.

    

    A constant increase in p with time, and no dependency on the traffic
    is just plain wrong.

    

    No way will that result in anything that anyone could prove was
    "optimal" even if you put caveats around it like "near-optimal" or
    "reasonably convincingly near-optimal".

    

    Perhaps this helps you to see why claims of near-optimality say more
    about the political or religious zeal of the person making the
    claim, than they do about CoDel itself.

    

    

      
Regrettably, the latter are not the only type of traffic actually found on the Internet.

Really, the central assumption of Codel is that each flow requires only one congestion signal event per RTT to cause it to back off.  Codel stops working well on traffic which doesn’t obey that assumption (a linear increase in drop frequency is inadequate to mitigate a flood - you need to work with drop probabilities for that), but it *does* work acceptably well with multiple flows sharing a queue, due to this operating-point search.

    

    Similarly, isn't the phrase "acceptably well" another way of saying
    "We don't need to consider any other AQM that might be better at
    handling a wider range of load scenarios"? Even though there is
    already an alternative available that increases the drop level
    dependent on how fast the queue is growing.

    

    This religious belief in a particular technology is not healthy.
    Please can we have some objectivity here.

    

    Regards

    

    

    

    Bob

    

      

 - Jonathan Morton

_______________________________________________
tcpPrague mailing list
tcpPrague@ietf.org
https://www.ietf.org/mailman/listinfo/tcpprague


    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------CD4B2AF5D5C493A6434C123F--


From nobody Fri Nov 25 10:34:27 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCAE1296BE; Fri, 25 Nov 2016 10:34:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level: 
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWID__NAOo8v; Fri, 25 Nov 2016 10:34:20 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BF61296A9; Fri, 25 Nov 2016 10:34:19 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 42AA2550D022B; Fri, 25 Nov 2016 18:34:14 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAPIYE1G016438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Nov 2016 18:34:17 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAPIYBSA013555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Nov 2016 18:34:11 GMT
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.65]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 25 Nov 2016 19:34:11 +0100
From: "De Schepper, Koen (Nokia - BE)" 
To: "Bless, Roland (TM)" , Ingemar Johansson S , Bob Briscoe , =?iso-8859-1?Q?Dave_T=E4ht?= , tsvwg IETF list , TCP Prague List , AQM IETF list , tcpm IETF list 
Thread-Topic: [aqm] [tcpPrague]  L4S status update
Thread-Index: AQHSRN/m0o5ivGe0/ES9p3WGLO/u/KDp+ZvA
Date: Fri, 25 Nov 2016 18:34:10 +0000
Message-ID: 
References:    <70104ef0-3747-9b47-dcb7-be54fe454443@kit.edu>
In-Reply-To: <70104ef0-3747-9b47-dcb7-be54fe454443@kit.edu>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tcpm] [aqm] [tcpPrague]  L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Nov 2016 18:34:22 -0000

Hi Roland, Ingemar, Bob, Dave,

I see congestion control mainly as an inter-flow-protocol that regulates ho=
w to share the bandwidth. Up to now it was agreed to adapt the rate to 1/sq=
rt(p).=20

Any congestion control deviating from this rule has been proven to fail. Ig=
noring drop will get you either pushed away, or you push away other traffic=
. I think most people agree with this?

Also BBR will face the same problem if it keeps on ignoring drop. I tried a=
 few long BBR flows next to long Cubic flows on our L4S testbed and current=
ly (depending on the RTT, rate and queue size) it either starves itself, st=
arves Cubic, or oscillate between the 2 previous cases over 20 second inter=
vals. I also tried only BBR flows on a PIE AQM. Same story there, either hi=
gh drop (15%), no drop or oscillations, also depending on the same paramete=
rs. Try it yourself and see... I see a lot of value in the other BBR mechan=
isms though, but not the drop ignoring aspects.

I don't see solutions without network support when new congestion controls =
ignore drop and still need to support other tcp flows which are deployed no=
w...... Up to now there are at least 2 network supported solutions:  DualQ =
Coupling that is an inter-protocol-translator (and therefor needs to know b=
oth protocols) and complete flow isolation like FQ which is the inter-flow-=
protocol inhibitor (for all flows) and takes over the end-systems role to s=
hare the BW (so not really according to the end-to-end principle).

For L4S, our main goal should be to define a new inter-flow-protocol betwee=
n L4S flows (L4S drafts assumes rate adapted based on ect(1) marking probab=
ility). Ones this is decided, we can couple it to the Classic drop/mark law=
. The network needs to support the coupling, as it is the only one that kno=
ws the drop and the marking of both classes. It depends on the end-systems,=
 but it is according to the end-to-end principle, because it is the least a=
nd most simple role that the network can have.

If a delay based protocol can be defined (like rate =3D F(queue delay)? ) t=
hen it could also be coupled to a classic drop probability with network sup=
port. But I don't think there is a proposal available. Also I don't think a=
 delay based protocol can achieve the same low latency results as an explic=
it signal.

Koen.


> -----Original Message-----
> From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Bless, Roland (TM)
> Sent: dinsdag 22 november 2016 17:46
> To: Ingemar Johansson S ; Bob Briscoe
> ; tsvwg IETF list ; TCP Prague List
> ; AQM IETF list ; tcpm IETF list
> 
> Subject: Re: [aqm] [tcpPrague] L4S status update
>=20
> Hi Ingemar,
>=20
> my point was that it's probably better to refrain from
> building CC-specific behavior into network elements as the
> CC algorithms may evolve faster and in more flexible ways
> than we can foresee. Thus, it would be good to have a separation
> (or coupling) scheme that actually doesn't depend on the
> 1/sqrt(p) dropping law.
>=20
> Am 22.11.2016 um 15:35 schrieb Ingemar Johansson S:
> > As regards to comments around other new congestion control algorithms
> > and that they may need adapted dropping likelihood relation between a
> > classic queue and L4S queue. I have not tried out but I suspect that
> > BBR may get an unfair treatment, at the same time it is possible that
> > other delay based CCs may suffer.
>=20
> It would be interesting to see what happens if BBR is sorted into
> the L4S queue in comparison to what happens if BBR is sorted into
> the classic queue (BBR isn't reacting to loss according to 1/sqrt(p)).
>=20
> > They question however if this is a major problem?, one may as well
> > see this as an incentive to switch over to scalable congestion
> > controls and L4S ? There is after all no requirement to stick to a
> > particular congestion control no matter what. ?
>=20
> Yes, and that's why I find that built-in coupling law too limiting.
>=20
> > The question whether or not endpoint dependency should be built into
> > the networks is of course  a valid question but given that the state
> > of the art congestion controls like Reno and Cubic rely on a
> > 1/sqrt(p) function then that is perhaps OK ?. There will for a
> > foreseeable time come updated endpoint based congestion control
> > algorithms that are optimized  for one thing or the other (I am
> > guilty too :-). However if one can distinguish between two classes
> > (classic and L4S) where classic belong to the 1/sqrt(p) family then I
> > believe that it is possible to solve the problem. If we try find a
> > solution where classic =3D "all sorts of non-scalable non-L4S dependent
> > congestion controls" then I believe that we easily end up in big
> > problems.
>=20
> I'm not sure. Maybe we have a class of "queue-filling" CCs and
> a class of low-delay targeted CCs.
>=20
> Regards,
>  Roland
>=20
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm


From nobody Mon Nov 28 05:21:43 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8C71295C0; Mon, 28 Nov 2016 05:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level: 
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsEF9is_yc5o; Mon, 28 Nov 2016 05:21:40 -0800 (PST)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FCB1295B6; Mon, 28 Nov 2016 05:21:39 -0800 (PST)
Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id F149E2784FE; Mon, 28 Nov 2016 22:21:37 +0900 (JST)
Received: by mail-vk0-f54.google.com with SMTP id 137so73070776vkl.0; Mon, 28 Nov 2016 05:21:37 -0800 (PST)
X-Gm-Message-State: AKaTC03LeDxYcO+/nZK8xlSIUxKc6d5gbDPty8YsGB4cThT5fqPV3RrPwkdtMnf1GIx7MuHNjcW8NHeWnW8TcA==
X-Received: by 10.31.5.132 with SMTP id 126mr6368410vkf.164.1480339296059; Mon, 28 Nov 2016 05:21:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.84.152 with HTTP; Mon, 28 Nov 2016 05:21:35 -0800 (PST)
From: Yoshifumi Nishida 
Date: Mon, 28 Nov 2016 05:21:35 -0800
X-Gmail-Original-Message-ID: 
Message-ID: 
To: "tcpm@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: "tcpm-chairs@ietf.org" 
Subject: [tcpm] draft minute for Seoul meeting
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 13:21:42 -0000

Hello,
I've just uploaded draft version of minutes for Seoul meeting on the
following URL.

https://www.ietf.org/proceedings/97/minutes/minutes-97-tcpm-00.txt

Please let the chairs know if you have comments or questions or some updates.

Thanks,
--
Yoshi


From nobody Mon Nov 28 15:07:58 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0812A088; Mon, 28 Nov 2016 15:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJ3ly8AfwlBt; Mon, 28 Nov 2016 15:07:41 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55AD312A0A3; Mon, 28 Nov 2016 15:07:37 -0800 (PST)
Received: from cm-84.210.215.55.getinternet.no ([84.210.215.55]:53898 helo=[192.168.0.129]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cBV1L-0005j5-Dw; Mon, 28 Nov 2016 23:07:35 +0000
To: Mario Hock , "Bless, Roland (TM)" 
References:    <67730f0d-7ee4-1366-1aaf-847b73e6b146@kit.edu>
From: Bob Briscoe 
Message-ID: <88f008a0-cd51-9a4b-7d79-c5824ffc5472@bobbriscoe.net>
Date: Mon, 28 Nov 2016 23:07:34 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <67730f0d-7ee4-1366-1aaf-847b73e6b146@kit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Cc: tsvwg IETF list , tcpm IETF list , TCP Prague List , AQM IETF list 
Subject: Re: [tcpm] [aqm] [tcpPrague] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Nov 2016 23:07:44 -0000

Mario,

On 24/11/16 16:57, Mario Hock wrote:
> Hello Bob and Roland,
>
> I followed your discussion and want to share my opinion, here. 
> (Comments inline).
>
> Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
>> *Is any AQM CC-neutral?**
>> *Note rule 5  in the
>> AQM Guidelines [RFC7567]
>>       "AQM algorithms SHOULD NOT interpret specific transport protocol
>> behaviors."
>> In general, the advice in that section is sound, but I don't think we
>> realized at that time just how subtle this issue is.
>>
>> Since then, I discovered that the autotuning parameter table in the PIE
>> algorithm is designed very precisely around the 1/sqrt(p) rule of Reno
>> (see Fig 5 in the PI^2 paper ).
>> Similarly, the sqrt control law in Codel claims to be dependent on Reno
>> {Note 1}.
>>
>> The point is that these AQMs still work fine with Cubic, Compound,
>> Westwood, etc, because all these ccs were designed to interwork with
>> Reno. {Note 2}
>
> The reason that the AQMs also work with these CCs is because the CCs 
> still have a lot in common with TCP Reno, like that they use a 
> congestion window, that they increase the CWnd up until packet loss 
> etc. Also the 1/sqrt(p)-law is still, more or less, applicable to them.
>
> For newer CCs like BBR or PCC, the 1/sqrt(p) does not apply. They are 
> based i.a. on throughput vs. loss/delay probing. BRR, for example, 
> does not even use a congestion window (at least not in the same way as 
> the other CCs do).
>
>
>> The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID
>> spec) is to enable a shift to a completely different "norm", but still
>> coexist with all the 'Classic' cc's that coexisted around the old
>> "norm". The new norm is intended to be just as fuzzy as the old norm
>> {Note 3}. The idea is two fuzzy clouds of congestion controls, around an
>> old and a new norm that are related together.
>
> I agree with the general idea. But from that reasoning newer CCs, like 
> BBR, belong into the "new" queue, where L4S lives in!
[BB] That's not for you (or I) to say.

The designer of a new CC can choose to innovate within Classic queues or 
L4S. Whichever they choose, they would set the identifier that 
classifies their packets into the appropriate queue, and they would have 
to coexist with the other behaviours in that queue.

We defined L4S as a framework to encourage innovation with new CCs in 
the L4S queue (because it's easier to deploy very nice properties), but 
please don't assume we were trying to mandate that! Also, if considering 
defining a CC with respect to L4S, bear in mind that L4S is only aiming 
for experimental status in the IETF at present.

L4S is not defined as "anything new must go here".


>
> If they don't belong in the same queue as L4S, then the queues should 
> not be coupled in the way you propose. This coupling prevents any 
> innovation in the non-L4S queue.
[BB] Not at all.

>
>
>>
>> *BBR**
>> *I believe BBR attempts to be 'friendly' to loss-based flows when
>> competing in the same queue. But it's still research, and we don't yet
>> know how good it is at that in all scenarios, although we do have code
>> to test now. Given BBR currently sets Not-ECT, it would classify itself
>> into the Classic queue of a DualQ AQM, and if it coexists with Reno it
>> /should/ coexist with L4S traffic in the other queue. See Koen's recent
>> posting
>> 
>> about this.
>>
>> There would be nothing to stop someone designing a variant of BBR that
>> coexisted in the L4S queue with Scalable CCs like DCTCP (the point being
>> that if the bottleneck was not DualQ it would keep delay low and if if
>> the bottleneck was DualQ it would benefit even more from the lower
>> queuing delay there). However, it would have to be a bit more careful
>> about its whole round trip of queue probing, to avoid increasing the
>> delay in the L4S queue. You'll see that I suggested to Neil Cardwell
>> that they consider probing with a few packets rather than a whole
>> window, e.g. the chirping
>>  technique that Mirja
>> and I looked into back in 2010 was designed to find the same knee
>> between rate increase and delay increase, with far fewer packets. I
>> thought of a better way of using chirping a few weeks ago, so I will be
>> returning to that too.
>
> I think L4S is not studied well enough, yet to be standardized in a 
> way that other low delay approaches must adjust to the L4S concepts.
[BB] They don't have to. L4S is aiming for experimental status at 
present. Strictly, other low delay experimental protocols only have to 
prove they coexist with standards track CCs (ie. Reno). In practice, any 
new experimental CC also has to prove it co-exists with the deployed 
base, whether standards track or not (e.g. Cubic, Compound etc). If L4S 
becomes part of the deployed base, it will have got there on its own 
merits, then other experiments that come along later will certainly have 
to interwork.

But anyway, as explained above, this should be no more difficult than 
interworking with Reno in the Classic queue, as if L4S was not there. 
Then interworking with L4S should come for free.

>
> There is at least BBR, PCC, nv (New Vegas) currently under development 
> that all bring in fresh ideas how congestion control could be made in 
> the future. Standardizing L4S as "the" new concept without intensively 
> study other approaches is just too soon.
[BB] I hope I've convinced you that L4S doesn't preclude any of these.

L4S is certainly different in that it is not a CC, rather it is a new 
space for easier CC experimentation. Another difference from all the CCs 
you mention above was the goal of persuading network operators of the 
benefit of creating such a space; because L4S is about improving the 
information flow between network and hosts. But none of that stops other 
CCs using the old space for experimentation.

>
> If we want to act now, we should focus on a solution that enables new 
> approaches in congestion control but is not tailored to either 
> Reno/Cubic or L4S/DCTCP. Otherwise more research is required how we 
> want the future of congestion control look like.
[BB] No-one is stopping you proposing something concrete.

You will, however, need an implementation, and proof that app 
performance has significant benefits, and a group of people interested 
in working on the idea, and .... This all takes work and time. Work on 
what has become L4S first started in 2012, see:
1) Wu, H., Ju, J., Lu, G., Guo, C., Xiong, Y. & Zhang, Y., "Tuning ECN 
for Data Center Networks," In: Proceedings of the 8th International 
Conference on Emerging Networking Experiments and Technologies CoNEXT 
'12 pp.25-36 ACM (2012)
2) http://www.bobbriscoe.net/present.html#1207tsvarea-dctcp

The choice of 1/p as a definition of the new L4S experimentation space 
was not arbitrary. There are numerous benefits to the number of 
congestion signals per RTT being * much higher and
* invariant with flow rate.
You will see further research that exploits these properties soon...

Cheers


Bob

>
> Best regards,
>
> Mario Hock
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Mon Nov 28 16:45:33 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7A212A1E1; Mon, 28 Nov 2016 16:45:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwLcoNquzcB; Mon, 28 Nov 2016 16:45:29 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B69D12A1DF; Mon, 28 Nov 2016 16:45:29 -0800 (PST)
Received: from cm-84.210.215.55.getinternet.no ([84.210.215.55]:54067 helo=[192.168.0.129]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cBWY3-0004aH-BF; Tue, 29 Nov 2016 00:45:27 +0000
To: "Bless, Roland (TM)" 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu>
From: Bob Briscoe 
Message-ID: <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>
Date: Tue, 29 Nov 2016 00:45:26 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Cc: TCP Prague List , tcpm IETF list , AQM IETF list , tsvwg IETF list 
Subject: Re: [tcpm] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 00:45:32 -0000

Roland,

On 24/11/16 20:48, Bless, Roland (TM) wrote:
> Hi Bob,
>
> see comments inline, please.
>
> Am 22.11.2016 um 20:09 schrieb Bob Briscoe:
>> I share your concern about cc-specific AQMs. But that is not a good
>> characterization of what we're doing.
> Yep, but it's part of what you're proposing.
>
>> On the current Internet, everything is meant to be somewhat "friendly"
>> to the original TCP cc (now spec'd in RFC5681). All sorts of cc's work
>> alongside that, with slightly different "fairness" properties, and only
>> one AQM is needed to cover them all. Nonetheless, Reno is the "lamest",
>> so everyone has to try to "Do (not much) Harm" to the lamest.
> Yes, and that's actually a deployment problem we agree on. Congestion
> control (CC) innovation is obstructed by the old loss-based CC so some
> separation mechanism would be good to let room for low-delay CCs.
>
>> *Is any AQM CC-neutral?**
>> *Note rule 5  in the
>> AQM Guidelines [RFC7567]
>>        "AQM algorithms SHOULD NOT interpret specific transport protocol
>> behaviors."
>> In general, the advice in that section is sound, but I don't think we
>> realized at that time just how subtle this issue is.
> I think that AQMs could be in fact designed CC neutral to a large
> extent, but every CC reacts probably different to the drop/ECN signals.
> So the dropping strategy implemented by the AQM will always cause a
> CC-specific reaction. Some AQMs therefore may achieve better results if
> they are tuned to specific CC behavior (but my e2e argument would also
> apply here), however, right now it's not that easy to change AQM
> implementations, esp. those implemented in hardware.
I am particularly worried about embedding fq in the Internet. That is 
far worse than embedding a subtly different performance improvement for 
certain congestion controls. With fq, the network determines the precise 
departure time of each packet, completely overriding the host's choice, 
without any understanding of what the applications is trying to achieve.

Even worse, in Jan 2017, I am told that fq_CoDel will become hard coded 
into the Linux WiFi drivers, without even a framework to dynamically 
load any alternative(s). Of course, we can add such a framework, but we 
are seeing Linux become the next major middlebox problem. It might be 
excusable if there were not sound alternatives available,... but there are.
>
>> Since then, I discovered that the autotuning parameter table in the PIE
>> algorithm is designed very precisely around the 1/sqrt(p) rule of Reno
>> (see Fig 5 in the PI^2 paper ).
>> Similarly, the sqrt control law in Codel claims to be dependent on Reno
>> {Note 1}.
>> The point is that these AQMs still work fine with Cubic, Compound,
>> Westwood, etc, because all these ccs were designed to interwork with
>> Reno. {Note 2}
>>
>> The idea of L4S (and specifically the DualQ Coupled AQM and the L4S ID
>> spec) is to enable a shift to a completely different "norm", but still
>> coexist with all the 'Classic' cc's that coexisted around the old
>> "norm". The new norm is intended to be just as fuzzy as the old norm
>> {Note 3}. The idea is two fuzzy clouds of congestion controls, around an
>> old and a new norm that are related together.
> Yes, and I support that basic idea to introduce network support for
> separating flows with different CC schemes. However, I'd like to have a
> solution that doesn't build in a specific coupling law, otherwise we
> will end up with having either TCP friendly or DCTCP friendly CC schemes.
And your proposal is...?

Also, what exactly is your rationale for not wanting a coupling law? It 
feels nice not to tie anything down. However, when hosts have fuzziness 
around both norms, additional fuzziness between the norms would just add 
an unnecessary dimension of uncertainty for no benefit.


As I just explained to Mario, the choice of "inversely proportional to 
marking probability" as the principle behind the new L4S space was not 
arbitrary.

     Congestion signals per round trip = probability of congestion 
signal * packets per round trip
        = p * W
where W is the window, and p is marking probability.

L4S is defined for
     W ~= k/p
where k is a constant.

So, L4S Congestion signals per round trip = p * W
                                                                  ~= k

That is, L4S is defined so that congestion signals per round trip is 
invariant as flow rate scales. That's an extremely important property..


>
>> *BBR**
>> *I believe BBR attempts to be 'friendly' to loss-based flows when
>> competing in the same queue. But it's still research, and we don't yet
>> know how good it is at that in all scenarios, although we do have code
> I'm not sure how friendly/fair BBR is actually to other CCs,
See Koen's recent post.
> but L4S is also still research...
Well, L4S is more a space in which research can flourish. And also a 
space where there's an initial CC (DCTCP) already deployed in 3 OSs, 
with a lot of deployment experience in controlled environments, and it's 
showing pretty cool results over the Internet, even though DCTCP wasn't 
designed for the Internet.

I call L4S and incrementally deployable clean-slate.
>
>> to test now. Given BBR currently sets Not-ECT, it would classify itself
>> into the Classic queue of a DualQ AQM, and if it coexists with Reno it
>> /should/ coexist with L4S traffic in the other queue. See Koen's recent
>> posting
>> 
>> about this.
> Hmm, from what I understood so far BBR reacts differently to packet loss
> than Reno/Cubic etc. So that coupling by dropping probability may not
> work correctly in this case, because BBR will not react according to
> 1/sqrt(p) (cf. the FAQ from the BBR slide set presented at IETF97,
> https://www.ietf.org/proceedings/97/slides/slides-97-iccrg-bbr-congestion-control-02.pdf)
Well, it's BBR's problem to show that it can interwork with the existing 
Internet first (and I am not including L4S in "the existing Internet" yet).
>
>> There would be nothing to stop someone designing a variant of BBR that
>> coexisted in the L4S queue with Scalable CCs like DCTCP (the point being
>> that if the bottleneck was not DualQ it would keep delay low and if if
>> the bottleneck was DualQ it would benefit even more from the lower
>> queuing delay there). However, it would have to be a bit more careful
>> about its whole round trip of queue probing, to avoid increasing the
>> delay in the L4S queue. You'll see that I suggested to Neil Cardwell
>> that they consider probing with a few packets rather than a whole
>> window, e.g. the chirping
>>  technique that Mirja
>> and I looked into back in 2010 was designed to find the same knee
>> between rate increase and delay increase, with far fewer packets. I
>> thought of a better way of using chirping a few weeks ago, so I will be
>> returning to that too.
> That would be interesting...
>
>> *Specs**
>> *There is no statement that all L4S cc's MUST adhere to a 1/p rule. The
>> L4S ID draft says:
>>    "The inverse proportionality requirement above is worded
>>     as a 'SHOULD' rather than a 'MUST' to allow reasonable flexibility
>>     when defining these specifications."
> I found two MUSTs in these contexts:
>
> draft-briscoe-tsvwg-aqm-dualq-coupled-00:
>     In order to prevent
>     starvation of Classic traffic by scalable L4S traffic (e.g.  DCTCP)
>     the drop probability of Classic traffic MUST be proportional to the
>     square of the marking probability of L4S traffic, In other words, the
>     power to which p_L is raised in Eqn. (1) MUST be 2.
>
> https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02
> 2.5:
>     The likelihood that an AQM drops a Not-ECT Classic packet (p_C) MUST
>     be roughly proportional to the square of the likelihood that it would
>     have marked it if it had been an L4S packet (p_L).  That is
>
>        p_C ~= (p_L / k)^2
They are deliberate MUSTs, linking together the meaning of the two 
congestion signals that a network queue applies. Neither constrains 
hosts; the SHOULD in the host behaviour is deliberately more liberal to 
hosts.

The network is given freedom to flex the constant of proportionality (k 
in the above equation), but not the long-term scaling exponent (the 
square). That allows networks and equipment vendors to differentiate 
themselves, without compromising long term scaling.

Given hosts have flex around both "norms", if the network flexed the 
scaling relationship between the "norms" as well, it would add another 
dimension of uncertainty to the system, with no benefit.

>
>> I hope that 'SHOULD' is fuzzy enough - I suspect adding more words would
>> make it less fuzzy. But I would welcome wording to make it even more
>> fuzzy if you would like to engage in wordsmithing.
>>
>> Nonetheless, we are trying to steer a path between a rock and a hard
>> place. Because, to shift to a much calmer waters beyond the rocks, we
>> have to define some number to relate L4S to Classic. I am wary because
>> when ECN was specified, there were attempts to define ECN as different
>> to drop. However, ECN originally ended up "the same as drop" because
>> no-one could muster enough backing behind any particular number to
>> relate the two, so the number '1' won by default (ie. ECN = 1 * drop^1 ).
> That's a different discussion.
Well, no. Think of it as push-back against your earlier sentence: "I'd 
like to have a solution that doesn't build in a specific coupling law".

We are proposing the square coupling law at the IETF precisely because, 
without a standard, no-one would be able to design a CC and be able to 
say anything about how it shares out capacity.
>
>> Bob
>>
>> {Note 1} I have never got a good answer to my questions on aqm@ietf as
>> to why a sqrt that controls the shrinkage of the spacing between dropped
>> packets has something to do with the steady state law of Reno,
>> particularly because the law leads to linear growth in p over time.
> Yep. However, according to our experiments Codel's dropping law seems to
> achieve a quite reasonable loss desynchronization.
>
>> {Note 2} Actually, I don't believe PIE would work that well with Cubic
>> at v high BDP, once it was far from Reno-friendly, but that's only
>> intuition from the stability analysis, not from actual testing.
> We tested PIE at 10GB/s and it worked with Cubic similarly as at
> low speeds.
OK.
>
>> {Note 3} Indeed, at the moment, when DCTCP is on its own in the L4S
>> queue of the DualQ AQM as coded now, it hits up against a step
>> threshold, which makes it behave as 1/p^2, not 1/p. For now, that's just
>> because we didn't want to change too much about DCTCP at one time. But
>> it's also got some nice properties. This will all need to be discussed
>> as the DualQ AQM is specified more deeply.
> So probably it would be good to find out what is the common denominator
> of _new_ L4S-like CCs (not only considering DCTCP) and what is a common
> denominator for CCs in the other class.
The text proposal to answer this is in the ecn-l4s-id draft.

Pls feel free to suggest specific text improvements.

Cheers




Bob
>
> Regards,
>   Roland
>
>
>> On 21/11/16 14:27, Bless, Roland (TM) wrote:
>>> Hi Bob and all,
>>>
>>> see below.
>>>
>>> Am 01.11.2016 um 01:02 schrieb Bob Briscoe:
>>>> A few people have been working away to specify and document all the
>>>> aspects of the new Low Latency, Low Loss, Scalable throughput (L4S)
>>>> service, which held a successful BoF in Berlin. As the decision was to
>>>> try to work across multiple WGs, I thought it would be useful to give ...
>>> Thanks for putting this together.
>>>
>>>>    * Dual Queue Coupled AQM
>>>>        o With Curvy RED for Linux (access available shortly)
>>>>        o With PI2 for Linux  [*UPDATED*]
>>> I'll repeat my concerns that I already expressed at the L4S BOF in Berlin:
>>>
>>> While I agree that we probably need to separate low-delay congestion
>>> control schemes from traditional "queue-filling" congestion schemes,
>>> I strongly suggest to avoid putting a congestion control-specific
>>> coupling scheme into the network (a classic case for applying the
>>> "end-to-end arguments in system design").
>>> The current Dual queue coupled AQM proposal has got a coupling based on
>>> a congestion control specific dropping law p_C=(p_L/2)². So if
>>> congestion control schemes change then this coupling needs to be
>>> adapted. For example, the currently proposed scheme may fail if that
>>> vast majority of TCP traffic is using BBR other some other forthcoming
>>> CC scheme instead of Cubic, Reno, Compound etc. The same applies to
>>> draft-briscoe-tsvwg-ecn-l4s-id, section 2.5, where the dropping
>>> likelihood is defined.
>>>
>>> Regards,
>>>   Roland
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Mon Nov 28 17:20:45 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E2B12A21E; Mon, 28 Nov 2016 17:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAG6i-weNPMo; Mon, 28 Nov 2016 17:20:35 -0800 (PST)
Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F6912A221; Mon, 28 Nov 2016 17:20:34 -0800 (PST)
Received: by mail-lf0-x242.google.com with SMTP id o141so11210007lff.1; Mon, 28 Nov 2016 17:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OiOmfyqcJqsOd825itUq4zUfXsbVCUWq74Rb8yPGjVk=; b=gU/5NdxvG2Pw4+1eelBOjcIotfXj410rBdKML6eF0JEFvAQmzV8fYXOAcw4dpT/0Or ehc/bEVgRAv62le03ZhIO4grTn3EB/Er3KwWA9vMBgdUwdHbLudYQPikcWMPL0yOq/GL P36wVjCk52k2SPjY6D9tN8uo+c1tEZgT9XOwy2y8luDaMFTu3Hl2r0aXwha8XAfm85Ad xln/tqDyrlXBkOBfewUJ+2A5n6qxKdc3hfOJCT0zkdtG1jR6ydIxiPYfG2w/spWZoQ+R igmvCeaNDrPU045z/2axdIHLyW6uK8x6fS/BF5zAoyEPfbyT4Tvyd1zbvqXMHRnw5LW4 RCKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OiOmfyqcJqsOd825itUq4zUfXsbVCUWq74Rb8yPGjVk=; b=KwlZmpMe8Xo0x4wBwVsf4T5mMbgffW94uraYkSlYJKxC4wFKR5XldXSAokEDuoVE/8 Ebv+6zT7ZPbBohNcKpQwhrotnReQWPKGDbWspqvkk3yokycPCpxgT8ScyhjFmgi4oVrw GBiquVOun3IxQIHHUnOyVBczlFLogvzootOat9qY4T0aVpfip4vf9dF2bmkwXzvmu6GE G/ycGPdGlwQtWgwy+9k6tvq8xjK+b6sWVQjqfs+Mpt2W5mefvDUavGqSXNCzjz1nPOIZ mlxccJTat2vUjyxKL7zzmTVxRYK4A2VdVwRhXwRjluZIS/ckAtZqHti3VtF7H4EzWTeZ iv/w==
X-Gm-Message-State: AKaTC039hoA9LRHDU33CZCQcxrLZYfeHVY055/DScNc4KcD0ARX1+R14CGROt0s6q/4EVQ==
X-Received: by 10.46.76.2 with SMTP id z2mr12038514lja.32.1480382432404; Mon, 28 Nov 2016 17:20:32 -0800 (PST)
Received: from [192.168.100.13] (37-33-82-144.bb.dnainternet.fi. [37.33.82.144]) by smtp.gmail.com with ESMTPSA id 125sm13206839ljj.26.2016.11.28.17.20.30 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Nov 2016 17:20:31 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton 
In-Reply-To: <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>
Date: Tue, 29 Nov 2016 03:20:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>
To: Bob Briscoe 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list 
Subject: Re: [tcpm] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 01:20:36 -0000

> On 29 Nov, 2016, at 02:45, Bob Briscoe  wrote:
>=20
> I am particularly worried about embedding fq in the Internet. That is =
far worse than embedding a subtly different performance improvement for =
certain congestion controls. With fq, the network determines the precise =
departure time of each packet, completely overriding the host's choice, =
without any understanding of what the applications is trying to achieve.

You don=E2=80=99t seem to be very fond of *either* component of =
fq_codel, then.  A shame, since it works very well in practice.

What fq_codel does is identify latency-sensitive flows by the fact that =
they are not taking up their fair share of the bandwidth.  Packets =
belonging to these flows are typically delivered *immediately* and =
*without loss*.  This is a far cry from =E2=80=9Ccompletely overriding =
the hosts=E2=80=99s choice=E2=80=9D of timing, as you claim.

In fact, I would actually be grateful if you retracted that particular =
claim.

It must be emphasised, though, that flow-isolating AQMs are not designed =
for the Internet core - there are just too many individual flows to =
manage.  Their place is at the edge, on either end of last-mile links, =
where the bottlenecks are most apparent.  For core, backhaul and peering =
links, plain AQM is sufficient and much easier to implement.

> Even worse, in Jan 2017, I am told that fq_CoDel will become hard =
coded into the Linux WiFi drivers, without even a framework to =
dynamically load any alternative(s). Of course, we can add such a =
framework, but we are seeing Linux become the next major middlebox =
problem. It might be excusable if there were not sound alternatives =
available,... but there are.

This tight integration is because it was necessary to solve some =
serious, long-standing problems with Linux wifi, which couldn=E2=80=99t =
be solved satisfactorily at the qdisc layer because information about =
wifi-specific things was needed - and there were *no* practical =
alternatives which actually solved the problem, otherwise we=E2=80=99d =
have used them.

Wifi is also a last-mile technology, and it is often the bottleneck in =
several types of practical deployment.  Large conferences are a =
particular example.  I=E2=80=99m rather looking forward to seeing the =
first large conference to deploy the new Linux wifi stuff, and seeing =
whether it has made the typical load there easier to cope with.  It =
probably has.

 - Jonathan Morton


From nobody Mon Nov 28 18:55:58 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570D712A266 for ; Mon, 28 Nov 2016 18:55:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level: 
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy3Z76eNCuNh for ; Mon, 28 Nov 2016 18:55:50 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C446B12A259 for ; Mon, 28 Nov 2016 18:55:49 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id c21so256174318ioj.1 for ; Mon, 28 Nov 2016 18:55:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jkMOP/KHQzSi2auJF5ZhlJuZm6xyOw++BktHAv0Lkhs=; b=m9ZieNeEpGGS+q83lG7dnx8AD/BUbqQh7RahH63XjuRNxx2F7qoBfkDt6D/CogE5wH kiSgQpS3Yaj0tNew3QsTA7vQoiRZphFApXkPLNZbAxlKm79KWZ4V63wh8TGQPISKP5Dm y/IIVw9vz07lmL+NFXkeSoNZ8AXf6cFHOvGp+Zcclk+c/HfcczTERYK24kCGlmlLabiA mCZtQCLOi1okWITHR9C/KVBkeBDjtJHgVcyD4Gyo//JEfs20YVpaCkE3IwgIi7nucfx3 XPsnvQJ5ayHDmFhZ330H9gU8cWv5tRGe3MXD/smoKrfL6Sio8lC3F7PxE66ycKiG4Fxq oYUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jkMOP/KHQzSi2auJF5ZhlJuZm6xyOw++BktHAv0Lkhs=; b=kL43HC8eHFBstMRpXSzrzoLGICGGS5plM7u4fKrU8umDcPMb9/nQCpVBVK2Z71RbuD mIzHjY7E36Ced2iOR+7ysGVELbzX6WTWX7ZQ2jH7B886SthqXOI3YqUkD6nHJ/kyIgYI UI6cXg56ujx1M34JMoZewjDIHbxEG7jQ9O9cwmKucWqtP0RuIVY338EVNESZCcxyVyjq dMgfpYDDFY1iqh4W86brArHBkuJLut1R9pFFkFt2fyeZqNSkur1t2cs7wk+T0+dVn0kt L3xxlOg9SScmDchACpLJCoV6ydGRWve8yPaWrRXFCCDKgR1WUW6TZWVHD3LERShnu4gb i0Vw==
X-Gm-Message-State: AKaTC02r7imBuJPJUJI631d5YTfgTVk2n8yQ/3mFMl31G+sKRlBIYVZ5iWYApYD1QbLPgmT2XayUdncCAWcHbGGC
X-Received: by 10.36.178.9 with SMTP id u9mr21501591ite.80.1480388148902; Mon, 28 Nov 2016 18:55:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.252.199 with HTTP; Mon, 28 Nov 2016 18:55:28 -0800 (PST)
In-Reply-To: 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net> 
From: Matt Mathis 
Date: Mon, 28 Nov 2016 18:55:28 -0800
Message-ID: 
To: Jonathan Morton 
Content-Type: multipart/alternative; boundary=f403045d9db6bf22fe054267b9bd
Archived-At: 
Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list 
Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 02:55:53 -0000

--f403045d9db6bf22fe054267b9bd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Bob's point is that fq_anything forfeits any mechanism for an application
or user to imply the value of the traffic by how much congestion they are
willing to inflict on other traffic.

This concept is the foundation of ConEx and related technologies which
could move the capacity allocation problem into the economic domain.  This
actually makes a lot of sense.    However, after investing a lot of time in
it over the years (in collaboration with Bob etal), I have come to believe
that this only makes sense for enforcing financially equitable use of a
deliberately undersized network.    Building capacity is generally cheaper
than building the congestion instrumentation.....

That said, fq_anything does not work at core router scale.

Note that there are two views, each of which is self consistent:

1) You need fq_* to isolate flows; prioritization must be done with
IP/TOS/DSCP bits; aggressive flows can't hurt other flows; low delays
require that flows sharing a Q to be nice to each other and respond to AQM
2) Uniform AQM/drop/mark per packet permits shared economic view of the
value of the traffic (e.g. a price) ; traffic is prioritized by how
aggressive of CC you choose; low delay [is/should be] a design property of
the shared CC and AQM algorithms.

If you have a way to create proper incentives about congestion (e.g. price
and chargeback), #2 is probably a strong system; if that fails #1 is
probably stronger.

Note that half solutions or solutions split between the models don't work.
period.  Arguing about incomplete systems that are missing some of the
parts is pointless because they don't work at some level (often layer 8 or
9).

Drop tail counts as "neither", so even partial deployment of anything can
be an improvement.

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 Mon, Nov 28, 2016 at 5:20 PM, Jonathan Morton 
wrote:

>
> > On 29 Nov, 2016, at 02:45, Bob Briscoe  wrote:
> >
> > I am particularly worried about embedding fq in the Internet. That is
> far worse than embedding a subtly different performance improvement for
> certain congestion controls. With fq, the network determines the precise
> departure time of each packet, completely overriding the host's choice,
> without any understanding of what the applications is trying to achieve.
>
> You don=E2=80=99t seem to be very fond of *either* component of fq_codel,=
 then.  A
> shame, since it works very well in practice.
>
> What fq_codel does is identify latency-sensitive flows by the fact that
> they are not taking up their fair share of the bandwidth.  Packets
> belonging to these flows are typically delivered *immediately* and *witho=
ut
> loss*.  This is a far cry from =E2=80=9Ccompletely overriding the hosts=
=E2=80=99s choice=E2=80=9D
> of timing, as you claim.
>
> In fact, I would actually be grateful if you retracted that particular
> claim.
>
> It must be emphasised, though, that flow-isolating AQMs are not designed
> for the Internet core - there are just too many individual flows to
> manage.  Their place is at the edge, on either end of last-mile links,
> where the bottlenecks are most apparent.  For core, backhaul and peering
> links, plain AQM is sufficient and much easier to implement.
>
> > Even worse, in Jan 2017, I am told that fq_CoDel will become hard coded
> into the Linux WiFi drivers, without even a framework to dynamically load
> any alternative(s). Of course, we can add such a framework, but we are
> seeing Linux become the next major middlebox problem. It might be excusab=
le
> if there were not sound alternatives available,... but there are.
>
> This tight integration is because it was necessary to solve some serious,
> long-standing problems with Linux wifi, which couldn=E2=80=99t be solved
> satisfactorily at the qdisc layer because information about wifi-specific
> things was needed - and there were *no* practical alternatives which
> actually solved the problem, otherwise we=E2=80=99d have used them.
>
> Wifi is also a last-mile technology, and it is often the bottleneck in
> several types of practical deployment.  Large conferences are a particula=
r
> example.  I=E2=80=99m rather looking forward to seeing the first large co=
nference
> to deploy the new Linux wifi stuff, and seeing whether it has made the
> typical load there easier to cope with.  It probably has.
>
>  - Jonathan Morton
>
> _______________________________________________
> tcpPrague mailing list
> tcpPrague@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpprague
>

--f403045d9db6bf22fe054267b9bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Bob's point is that fq_anything forfeits any mechanism=
 for an application or user to imply the value of the traffic by how much c=
ongestion they are willing to inflict on other traffic.

=
This concept is the foundation of ConEx and related technologies which coul=
d move the capacity allocation problem into the economic domain.=C2=A0 This=
 actually makes a lot of sense. =C2=A0 =C2=A0However, after investing a lot=
 of time in it over the years (in collaboration with Bob etal), I have come=
 to believe that this only makes sense for enforcing financially equitable =
use of a deliberately undersized network. =C2=A0 =C2=A0Building capacity is=
 generally cheaper than building the congestion instrumentation.....
<=
div>
That said, fq_anything does not work at core router scal=
e.

Note that there are two views, each of which is=
 self consistent:

1) You need fq_* to isolate flow=
s; prioritization must be done with IP/TOS/DSCP bits; aggressive flows can&=
#39;t hurt other flows; low delays require that flows sharing a Q to be nic=
e to each other and respond to AQM
2) Uniform AQM/drop/mark per p=
acket permits shared economic view of the value of the traffic (e.g. a pric=
e)=C2=A0; traffic is prioritized by how aggressive of CC you choose; low de=
lay [is/should be] a design property of the shared CC and AQM algorithms.

If you have a way to create proper incentives about=
 congestion (e.g. price and chargeback), #2 is probably a strong system; if=
 that fails #1 is probably stronger.

Note that hal=
f solutions or solutions split between the models don't work. period.=
=C2=A0 Arguing about incomplete systems that are missing some of the parts =
is pointless because they don't work at some level (often layer 8 or 9)=
.

Drop tail counts as "neither", so even=
 partial deployment of anything can be an improvement.

Thanks,
--MM--The best way to predict the future is to create it. =C2=A0- Alan Kay
<=
br>Privacy matters!=C2=A0 We know from recent events that people are using =
our services to speak in defiance of unjust governments. =C2=A0 We treat pr=
ivacy and security as matters of life and death, because for some users, th=
ey are.


On Mon, Nov 28, 2016 at 5:20 PM, Jonathan Mo=
rton <chromatix99@gmail.com> wrote:


> On 29 Nov, 2016, at 02:45, Bob Briscoe <ietf@bobbriscoe.net> wrote:

>

> I am particularly worried about embedding fq in the Internet. That is =
far worse than embedding a subtly different performance improvement for cer=
tain congestion controls. With fq, the network determines the precise depar=
ture time of each packet, completely overriding the host's choice, with=
out any understanding of what the applications is trying to achieve.



You don=E2=80=99t seem to be very fond of *either* component of fq_c=
odel, then.=C2=A0 A shame, since it works very well in practice.



What fq_codel does is identify latency-sensitive flows by the fact that the=
y are not taking up their fair share of the bandwidth.=C2=A0 Packets belong=
ing to these flows are typically delivered *immediately* and *without loss*=
.=C2=A0 This is a far cry from =E2=80=9Ccompletely overriding the hosts=E2=
=80=99s choice=E2=80=9D of timing, as you claim.



In fact, I would actually be grateful if you retracted that particular clai=
m.



It must be emphasised, though, that flow-isolating AQMs are not designed fo=
r the Internet core - there are just too many individual flows to manage.=
=C2=A0 Their place is at the edge, on either end of last-mile links, where =
the bottlenecks are most apparent.=C2=A0 For core, backhaul and peering lin=
ks, plain AQM is sufficient and much easier to implement.



> Even worse, in Jan 2017, I am told that fq_CoDel will become hard code=
d into the Linux WiFi drivers, without even a framework to dynamically load=
 any alternative(s). Of course, we can add such a framework, but we are see=
ing Linux become the next major middlebox problem. It might be excusable if=
 there were not sound alternatives available,... but there are.



This tight integration is because it was necessary to solve some ser=
ious, long-standing problems with Linux wifi, which couldn=E2=80=99t be sol=
ved satisfactorily at the qdisc layer because information about wifi-specif=
ic things was needed - and there were *no* practical alternatives which act=
ually solved the problem, otherwise we=E2=80=99d have used them.



Wifi is also a last-mile technology, and it is often the bottleneck in seve=
ral types of practical deployment.=C2=A0 Large conferences are a particular=
 example.=C2=A0 I=E2=80=99m rather looking forward to seeing the first larg=
e conference to deploy the new Linux wifi stuff, and seeing whether it has =
made the typical load there easier to cope with.=C2=A0 It probably has.



=C2=A0- Jonathan Morton




_______________________________________________

tcpPrague mailing list

tcpPrague@ietf.org

https://www.ietf.org/mailman/listinfo/tcpprague<=
/a>





--f403045d9db6bf22fe054267b9bd--


From nobody Mon Nov 28 19:42:33 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43E51294F2; Mon, 28 Nov 2016 19:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2uW8ryP8TtH; Mon, 28 Nov 2016 19:42:16 -0800 (PST)
Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5908012945A; Mon, 28 Nov 2016 19:42:16 -0800 (PST)
Received: by mail-lf0-x241.google.com with SMTP id o141so11408362lff.1; Mon, 28 Nov 2016 19:42:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H38vsGm3lLVUb1pXAvPmM94o0lBUrJ8kxEo/85EYNM8=; b=zwHDBh39O2AP6Z0iISzJxWsJvxqWqPxdDkzISJlR7czMHScRMo+KRyqFGWYsMGLQ+v 8F31IvJfng0usvisKmcyYMG9Budo7d8c+sZRU7wRdcg0LCRYaUH84i2QzxMnR3ZwSXLK SSihx4P6qtNo02L/advWxgZqJIXGjsiCVqgD9XORUSOm55/2KcaXla7SWH1oq2jXdhwP a3nH+w3Jn9v0eSncGhX02ENTuOZTpync1zlvhaaqzBywOSAfTyKuA9hzpz1hCiGm2ab+ JD4/mDFfXTt+nWz5gFnb83ph0L2H2rb4hgFW2BayTHGHiyIMOQWGceF5rDfgeJOhH6mj hhRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=H38vsGm3lLVUb1pXAvPmM94o0lBUrJ8kxEo/85EYNM8=; b=CBE6HAV4injevT8ioO1oPlUlsTk7tDFci4dw7UM9iZjGSTiiSiLmoRgSzzdARse2tC jYG2LMHj3fXxtNIL3kcSozfv7ifYhbtsExte5VfPdvWhELGgMrXYmUwK95Xl4e6gyvU0 6lW4S6i90+GyqHgoCo+JPYv6b/m+tBzqdGi2dTmUpZau5Daop3sm/zThKimy74TlSAEv 3zisqwaNGVxDIPGrPCy3DV6QTUNE8tdiicn0tTsxDw5dG1bbxI6lG5HjTSYVe3ni89QC VDSOIEm8iKr3s6qOlE5EscpHXsJ2jSql6lHDNAgRl2GOYXypv5qNR3PVGBTgsZjnR2hG RH8g==
X-Gm-Message-State: AKaTC00zzr2W5vU/bbDppj0yashXmeh6YlNL6GJv60Ev8Ug5FExnE/JBFjC1TqHtO/vcHA==
X-Received: by 10.46.69.137 with SMTP id s131mr12405559lja.26.1480390934462; Mon, 28 Nov 2016 19:42:14 -0800 (PST)
Received: from [192.168.100.13] (37-33-82-144.bb.dnainternet.fi. [37.33.82.144]) by smtp.gmail.com with ESMTPSA id u63sm13156328lja.34.2016.11.28.19.42.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Nov 2016 19:42:13 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton 
In-Reply-To: 
Date: Tue, 29 Nov 2016 05:42:11 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>  
To: Matt Mathis 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list 
Subject: Re: [tcpm] [tcpPrague] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Nov 2016 03:42:19 -0000

> On 29 Nov, 2016, at 04:55, Matt Mathis  wrote:
>=20
> Bob's point is that fq_anything forfeits any mechanism for an =
application or user to imply the value of the traffic by how much =
congestion they are willing to inflict on other traffic.

Yes, it does.

I actually consider that a good thing, because most applications will, =
given the choice, choose to inflict more congestion on other traffic in =
order to boost their own performance.  There are honourable exceptions, =
but it=E2=80=99s not a behaviour we can solely rely on.

For example, Steam uses between four and eight parallel TCP streams (I =
can=E2=80=99t figure out what the number depends on) to receive game =
updates, when one or two would already saturate most domestic Internet =
connections.  This magnifies the impact on other things the user might =
be doing with that connection, such as - ironically enough - playing =
multiplayer games.  You=E2=80=99d think Valve, of all companies, would =
keep that in mind.

> This concept is the foundation of ConEx and related technologies which =
could move the capacity allocation problem into the economic domain.

=E2=80=9CEconomic domain=E2=80=9D only works if there is a financial =
cost borne by the causer of the congestion.  Good luck making that work, =
in a world where IoT device manufacturers don=E2=80=99t bear the costs =
of DDoSes launched through them.

> That said, fq_anything does not work at core router scale.

Correct.

> Note that there are two views, each of which is self consistent:
>=20
> 1) You need fq_* to isolate flows; prioritization must be done with =
IP/TOS/DSCP bits; aggressive flows can't hurt other flows; low delays =
require that flows sharing a Q to be nice to each other and respond to =
AQM

=E2=80=A6or that different flows are carefully kept in different queues.

Cake uses set-associative flow hashing to achieve flow isolation much =
more reliably than the current version of fq_codel.

Cake also applies Codel and BLUE in parallel, each covering a different =
AQM regime - BLUE takes over if and when Codel fails to control a =
particular queue.  If both Codel and BLUE fail to control the queue, =
Cake uses head-drops from the longest queue to remain within a total =
memory budget.  All of these avoid penalising well-behaved traffic =
whenever possible.

Cake also has mechanisms which consider =E2=80=9Cper host=E2=80=9D =
fairness simultaneously with =E2=80=9Cper flow=E2=80=9D fairness.  =
Incidentally, the Linux wifi got =E2=80=9Cper station airtime =
fairness=E2=80=9D along with the fq_codel upgrade, achieving a similar =
aim by different means.

SFB uses a Bloom filter to a similar end, though that=E2=80=99s not =
strictly an FQ qdisc.

> 2) Uniform AQM/drop/mark per packet permits shared economic view of =
the value of the traffic (e.g. a price) ; traffic is prioritized by how =
aggressive of CC you choose; low delay [is/should be] a design property =
of the shared CC and AQM algorithms.

It=E2=80=99s fair to say that =E2=80=9Cuniform AQM=E2=80=9D is the only =
mechanism available at the core level, mainly because there are too many =
flows there to treat individually.  But at that level, network =
engineering is supposedly all about providing sufficient link capacity =
so that AQM of any kind is unnecessary, because there is no congestion.  =
Still, plain AQM is a valid and potentially useful mitigation against =
transient overloads.

There are exceptions.  Some ISPs have been known to deliberately =
restrict peering capacity in certain directions to deliberately cause =
congestion to specific types of traffic, supposedly as a financial =
lever.  These ISPs would not be interested in applying AQM to reduce the =
impact of this deliberately-induced congestion.

I do have to ask, though, what protection this =E2=80=9Cshared economic =
view" provides against a single bulk flow which simply ignores all =
congestion signals?

> If you have a way to create proper incentives about congestion (e.g. =
price and chargeback), #2 is probably a strong system; if that fails #1 =
is probably stronger.
>=20
> Note that half solutions or solutions split between the models don't =
work. period.  Arguing about incomplete systems that are missing some of =
the parts is pointless because they don't work at some level (often =
layer 8 or 9).

Indeed.  I=E2=80=99m not aware of any =E2=80=9Ccomplete=E2=80=9D systems =
in category 2 - and I don=E2=80=99t count =E2=80=9Cdata caps=E2=80=9D =
among them, unpopular though they are.

 - Jonathan Morton


From nobody Tue Nov 29 19:46:19 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7C01299A1; Tue, 29 Nov 2016 19:46:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6QjOiZcVW8y; Tue, 29 Nov 2016 19:46:10 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079FE129D2A; Tue, 29 Nov 2016 19:40:38 -0800 (PST)
Received: from dair-2506.local (c-73-202-26-20.hsd1.ca.comcast.net [73.202.26.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 07F4621341; Wed, 30 Nov 2016 03:40:34 +0000 (UTC)
To: Jonathan Morton , Matt Mathis 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>   
From: =?UTF-8?Q?Dave_T=c3=a4ht?= 
Message-ID: 
Date: Tue, 29 Nov 2016 19:40:31 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: tcpm IETF list , tsvwg IETF list , TCP Prague List , AQM IETF list 
Subject: Re: [tcpm] [aqm] [tcpPrague] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2016 03:46:12 -0000

The advantages of FQ are probably more widespread than people think.

* Switches tend to multiplex between ports, thus mixing up traffic
naturally.

* Most modern ethernet cards expose 8-64 queues - why? because this
provides clear paths for multiple cpus to forward them - it's not
network related at all! - 1gig cards typically have 8, 10gig, 64.

While 8 induces a severe birthday problem, 64 is generally "just fine"
and in either case, large amounts of mixed traffic respond reasonably to
even only a few queues.

I don't see the trend to ever more hardware queues subsiding, as it's
a function of the number of cores, which keeps going up and up.

* Google'd hosts - and those of a few cloudy providers - long ago
switched to sch_fq which also interleaves (and paces) flows at an
appropriate burst level on a 1ms interval. So source flows are getting
fq'd on an ever more regular basis.

So when the assertion is made that fq is impossible on core routers, I
have to point to the fact that much of the traffic traversing them have
already had a great deal of mixing already applied to it by devices
downstream, AND most core routers have more than one link they are
aggregating via multiplexing in the first place.

That's the FQ in the core and datacenter today. I view the side-effects
of the 1 cpu per hw queue as essentially accomplishing all the fq
needed, AND that applying a single aqm to all those flows is well nigh
impossible as these flows MUST be spread across cores to reach these rates.

...

I see no future in hardware designs that can scale past 25Gbit that do
not do some form of parallelism across flows. This again, is something
that already essentially happens within vlans and with multiple
forwarding lookup tables in those.

100Gbit devices are 4 25GB queues wired together, at minimum. Etc.

(Most of our problems nowadays btw, is on rx, not tx - it's really hard
to do all the work required on the rx side!)

In terms of fq_codel -

For strong reasons (birthday problem) we settled on 1024 queues as a
good general purpose number that works well in practice on real data on
real loads, for speeds between 0 and 10Gbits, for homes and small
business. Initially.

We are now seeing people deploy fq_codel successfully on mid-range
systems with 64 hardware queues at 10Gbit - 64K fq_codel'd queues.

Whether or not the aqm part is that effective with that many queues on
real traffic is beyond me. I've had no complaints - as the alternative -
no aqm, no fq - is far worse.

...

The early experiments with fq_pie (not the bsd version, the sch_fq
derived version) showed something like a 12% (don't quote me!)
improvement in the aqm performance by presenting a more equitable
distribution of test traffic (that is presently over-bursty, created by
bursty things like IWXX, tso/gso/gro offloads, and so on).

I was happy with that result, but cognizant that so much test traffic
looks *nothing like* real traffic. Real traffic does not consist of the
long sustained loads so beloved of experimenters and theorists.

The benchmarks I care about most are voip, videoconferencing, gaming,
dns, tls setup, page load time, and anything else that demands low
latency, of course.

...

Cake has pushed the limits of the possible, with the 8 way set
associative idea making for the perfect fq all the math is based on,
I rather would like more folk testing it - it's stable enough now, and
backported as far back as linux 3.14. I am still unsure of the various
mods to the aqm algo - the new per host fq within fq feature (a common
feature request), the denatting, and the optional shaper is a major
advance, and the classification ideas needing further evaluation.

It seems eminently possible to add l4s ideas to it, as soon as someone
gets around to a usable ect(1) patch for tcp ecn negotiation.

When last I tried it, it could push 17GBit through a 40Gbit card, where
pfifo fast did about 27 on a single core/hw queue benchmark. We were
bottlenecking on rx! to be unable to test harder than that.


From nobody Tue Nov 29 20:09:28 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8531294B7; Tue, 29 Nov 2016 20:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnu_8K0EPQOC; Tue, 29 Nov 2016 20:09:21 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D01E1129447; Tue, 29 Nov 2016 20:09:20 -0800 (PST)
Received: from dair-2506.local (c-73-202-26-20.hsd1.ca.comcast.net [73.202.26.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 1F02021341; Wed, 30 Nov 2016 04:09:17 +0000 (UTC)
To: Bob Briscoe , Jonathan Morton 
References:    <053CE5B0-1879-4A2B-B4E9-8BCDDE5BA482@gmail.com> 
From: =?UTF-8?Q?Dave_T=c3=a4ht?= 
Message-ID: 
Date: Tue, 29 Nov 2016 20:09:16 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: tcpm IETF list , AQM IETF list , tsvwg IETF list , TCP Prague List 
Subject: Re: [tcpm] [aqm] [tcpPrague] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2016 04:09:23 -0000

On 11/25/16 6:23 AM, Bob Briscoe wrote:
> Jonathan,
> 
> On 22/11/16 20:37, Jonathan Morton wrote:
>>> On 22 Nov, 2016, at 21:09, Bob Briscoe  wrote:
>>>
>>> {Note 1} I have never got a good answer to my questions on aqm@ietf as to why a sqrt that controls the shrinkage of the spacing between dropped packets has something to do with the steady state law of Reno, particularly because the law leads to linear growth in p over time.
>> If you have intervals between events which follow a 1/sqrt(N) sequence, where N is the number of preceding events, you get an event frequency which increases linearly with time.  

We do have a tendency to talk past each other regarding codel's rate.
the 1/sqrt(N) only applies during codel's initial seeking toward an
ideal drop rate. after that -

for 99.99999% of the time, after that, there is no definable *rate* in
codel - it varies based on the workload and the time spent above and
below the target. I really wish I'd produced an animation of this rather
than the first graph I did at stanford.

...

as for what that initial ramp has to do with reno or tcp's behaviors, it
seems to work, and we've tried other things that didn't work as well.
Give cake's variant a shot. You tell me.

> Yes, I pointed that out originally
> . And
> Toke confirmed in response that it did indeed happen in practice.
>> This applies directly to Codel’s signalling strategy, which is to start at one mark per (assumed) RTT, and to increase the marking frequency if that was insufficient to control the queue.
>>
>> When you have multiple Reno flows sharing a single queue, there is a sqrt(N) factor in several of the characteristics, where N is the number of flows.  When such a shared link becomes saturated, all of the flows must be signalled to slow down, but for stochastic reasons it’ll probably take more than N signalling events to do so.  Increasing the signalling frequency while the queue remains insufficiently controlled has a good chance of quickly finding all the flows, while dropping relatively few packets (of non-ECN flows).
> Just throwing a square root in "somewhere", doesn't mean it is the
> correct "somewhere".
> 
> A stated goal of the sqrt in the CoDel control law is to match the
> 1/sqrt(p) in TCP Reno's window formula. Quite aside from whether that is
> a correct goal, it isn't even doing that:
> * ACK-clocked load (number of flows, N) is proportional to 1/cwnd, ie.
> proportional to sqrt(p) [see 2nd para of section 4 of PI2 paper
> ]
> * because CoDel applies a sqrt to the interval between drops, it results
> in a linear increase in p with time (because the sqrt effectively gets
> squared - see the simple maths in my original posting about this
> ).
> 
> So, the question is: "Why is a linear increase in p (starting from 0)
> good for controlling load from N flows, where N is proportional to sqrt(p)?"

Why do you keep insisting that the rate is this rate? See above.

>>
>> I’m reasonably convinced that Codel is a near-optimal solution to congestion signalling on TCP-friendly flows.  
> The word "optimal" has a precise meaning. I think you mean simply "I am
> predisposed to CoDel."

I have yet to see one convincing benchmark or paper of a single queued
aqm that outperforms fq_codel.

We've done thousands over here. And shared the test data. And the tool.
What you got?

> 
> Whether the control law increases p linearly with time or by the sqrt,
> or by any function of time, is not the point anyway. Time is not the
> correct unit for this control law. The CoDel control law has no
> variables in it (other than the point at which it starts) that depend on
> any feature of the traffic. Once the CoDel control law starts, it just
> blindly increases until it reaches a high enough drop level to control
> the traffic. So the higher p needs to be, the longer it takes. And the
> lower p needs to be, the more it will overshoot within a round trip.

Sigh.

> 
> A constant increase in p with time, and no dependency on the traffic is
> just plain wrong.
> 
> No way will that result in anything that anyone could prove was
> "optimal" even if you put caveats around it like "near-optimal" or
> "reasonably convincingly near-optimal".
> 
> Perhaps this helps you to see why claims of near-optimality say more
> about the political or religious zeal of the person making the claim,
> than they do about CoDel itself.

Benchmarks, here. Not zeal.

> 
>> Regrettably, the latter are not the only type of traffic actually found on the Internet.
>>
>> Really, the central assumption of Codel is that each flow requires only one congestion signal event per RTT to cause it to back off.  Codel stops working well on traffic which doesn’t obey that assumption (a linear increase in drop frequency is inadequate to mitigate a flood - you need to work with drop probabilities for that), but it *does* work acceptably well with multiple flows sharing a queue, due to this operating-point search.
> Similarly, isn't the phrase "acceptably well" another way of saying "We
> don't need to consider any other AQM that might be better at handling a
> wider range of load scenarios"? Even though there is already an
> alternative available that increases the drop level dependent on how
> fast the queue is growing.
> 
> This religious belief in a particular technology is not healthy. Please
> can we have some objectivity here.

I really, really feel like this is really going overboard.

It took me this long to reply to this mail because of this bluster.

We have, on this side, published all the code, published every
benchmark, published the vast majority of our test data, and at every
point, shown fq_codel to be the win it is. Cake is a few percentage
points better in some respects. If some technology arrives worth
benchmarking then by god we'll benchmark it.

I don't know how to fall on our sword more than this.

So far as I know, to date, you - and very few on these lists - have
bothered to even try the production quality code we've made readily
available in now dozens of router distributions, and cheap hardware, in
any scenario. But I suspect millions now have. With no complaints. In
fact, near universal praise.

The religion is on your side, bob, not ours. I will always benchmark any
code you give me with the tools I have. My sole mission in life is to
beat bufferbloat in my lifetime.

I have tired of the dialog on these lists because since the bufferbloat
effort started, several billion machines has shipped without decent
queue management,
and I would much rather solve the problems as best I can, for those that
are willing to try the solutions we have developed so far.

- and especially - as we learn from the deployment, what other real
problems exist, to feed forward into the process.

Even then, even with the make-wifi-fast fq_codel and airtime fairness
patches for the ath9k still landing, we will at best, improve the
performance of only a few million more devices, in the hands of early
adopters, next year, a small fraction of the sold total. There are
hundreds of chipsets left to fix.

It's a big Internet. There's room for everyone's ideas on it. I look
forward to seeing yours reach a deployable state.



> Regards
> 
> 
> 
> Bob
>>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> tcpPrague mailing list
>> tcpPrague@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpprague
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 
> 
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
> 


From nobody Tue Nov 29 22:16:23 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA90126CD8; Tue, 29 Nov 2016 22:16:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level: 
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYsmtiTW8-JO; Tue, 29 Nov 2016 22:16:05 -0800 (PST)
Received: from mail.taht.net (mail.taht.net [176.58.107.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844EA129488; Tue, 29 Nov 2016 22:15:44 -0800 (PST)
Received: from dair-2506.local (c-73-202-26-20.hsd1.ca.comcast.net [73.202.26.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id D97FE21341; Wed, 30 Nov 2016 06:15:39 +0000 (UTC)
To: Jonathan Morton , Bob Briscoe 
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net> 
From: =?UTF-8?Q?Dave_T=c3=a4ht?= 
Message-ID: 
Date: Tue, 29 Nov 2016 22:15:37 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: tcpm IETF list , AQM IETF list , tsvwg IETF list , TCP Prague List 
Subject: Re: [tcpm] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2016 06:16:11 -0000

On 11/28/16 5:20 PM, Jonathan Morton wrote:

>> Even worse, in Jan 2017, I am told that fq_CoDel will become hard coded into the Linux WiFi drivers, without even a framework to dynamically load any alternative(s). Of course, we can add such a framework, but we are seeing Linux become the next major middlebox problem. It might be excusable if there were not sound alternatives available,... but there are.

A) As soon as the need for a pluggable framework arises, the linux wifi
architecture is now simple enough to do so. As it is the results are so
spectacular compared the previous "std" behavior that it will take some
doing to prove a different point. Reductions in latency under load of
over an order of magnitude, bandwidth improvements of 5x, stuff like
that... ( https://lwn.net/Articles/705884/ )

Given that this effort took 3 years out of multiple people's lives, and
a year of slow steady, patching out the old wifi engine, with thousands
of hours of testing and refinement, and a summer lost to fixing bugs, on
next to no budget...

http://blog.cerowrt.org/post/crypto_fq_bug/

I hope that more people give it a go soon (most of it is already
available in nightly builds of lede-project ar71xx based platforms, and
nearing shipment elsewhere in things like the turris omnia). There is at
least one bug left to fix, always.

The ECN support works beautifully, in particular, and this is the first
time in my life, since working on wifi in 1998, that I'd feel
comfortable deploying a single AP to multiple station solution in a
commercial multi-customer environment - (after a bit more testing in the
yurtlab campground testbed) - before now, only p2p was sanely saleable.

B) Secondly, FQ technology has always existed in wifi - many WISP
vendors altered the MAC to behave via TDMA - or called something TDMA
that was really SFQ. Some like ubnt, have even gone so far as
implementing full duplex over separate channels in their high end
airstream products, on top of that. FQ has long been a part of meraki's
product line. I don't know how cisco does their magic, but...

C) Airtime fairness first appeared as optional features in cisco and at
least one other manufacture's gear at least 6 years back. the problem it
solves was first described in 2003.

So it is ironically the inclusion of an aqm for the first time that is
the most novel feature of this make-wifi-fast work (on top of fq, and
with airtime fairness), integrated tightly. Very little work on aqm
technology prior to now has been applied to highly contended, half
duplex, lossy layer 2 medium systems, and I expect there will be much
more work to be done here.

So... it is far from "just linux" you need to deal with - and far less -
the initial patchset is for the ath9k chipset only, with the ath10k
running a bit behind, and the mt76 still floating in limbo. We are still
in search of other chipsets worth optimizing, with the hope we'll find
something that is in an android as well as at least one other 802.11ac
chipset. From a queue management perspective there is mu-mimo next
(which requires gang scheduling of up to 16 stations), reducing txop
size under contention, and dealing with currently excessive layer 2
retries sanely under contention.

BUT: from an engineering perspective, there are two other things wrong
with wifi that are more severe than these latter problems - the first
one - excessive channel scans - was seriously detrimental to voip and
videoconferencing and the air around the user - and is on its way to
being improved - bug and pending fix described here:

http://blog.cerowrt.org/post/disabling_channel_scans/

The second huge problem is that rate control, now that there is such a
large search space in wireless-n and ac - is no longer as quickly
effective as it needs to be - taking 10-20sec or more to settle in on a
good rate, when 100ms would be ideal. Work on fixing that (which also
leverages the all the work above) is hopefully coming along again
(google for minstrel-blues for some of the more public details)

These last four problems are much more severe than coming up with a
different fq, aqm, or airtime fairness algorithm is, and thus, most
worth focusing on next. Hopefully - someone *else* focusing on next -
I'm tired of working on microsecond timescales and would like to find a
new gig that relied on no timescale shorter than a season.

...

Certainly I hope that by january an ath9k laptop and an ath9k AP will
behave better than any linux system has behaved since 802.11b has,
certainly be superior to current LTE in all respects - but it will
probably be another 3-6 months before the major distros pick it up, and
we have not identified another common laptop wifi chipset that can be
improved in these ways.

(the core work mostly applies to APs, and does help a lot no matter the
client chipset or OS. I also hope to find someone working on an enodeb
to start applying the same algorithms in this timeframe)


> This tight integration is because it was necessary to solve some serious, long-standing problems with Linux wifi, which couldn’t be solved satisfactorily at the qdisc layer because information about wifi-specific things was needed - and there were *no* practical alternatives which actually solved the problem, otherwise we’d have used them.
> 
> Wifi is also a last-mile technology, and it is often the bottleneck in several types of practical deployment.  Large conferences are a particular example.  I’m rather looking forward to seeing the first large conference to deploy the new Linux wifi stuff, and seeing whether it has made the typical load there easier to cope with.  It probably has.

Hopefully the upcoming SCALE conference will be our first major
deployment test. If not, battlemesh, wlan slovinia, or sudoroom.

Or for all I know, open-mesh, eero, portal, meraki, and/or plume have
already picked up the code.


> 
>  - Jonathan Morton
> 
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
> 


From nobody Wed Nov 30 13:56:14 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D053129B6F; Wed, 30 Nov 2016 13:56:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level: 
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkkdsvRPqk6G; Wed, 30 Nov 2016 13:56:10 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C459F129A20; Wed, 30 Nov 2016 13:56:09 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6836F90A29E; Wed, 30 Nov 2016 16:56:08 -0500 (EST)
Date: Wed, 30 Nov 2016 16:56:08 -0500
From: John Leslie 
To: Jonathan Morton 
Message-ID: <20161130215608.GC98127@verdi>
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: 
Cc: AQM IETF list , tcpm IETF list , tsvwg IETF list , TCP Prague List 
Subject: Re: [tcpm] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Nov 2016 21:56:12 -0000

(could we agree to reduce the Cc list on this thread?)

Jonathan Morton  wrote:
>...
> What fq_codel does is identify latency-sensitive flows by the fact that
> they are not taking up their fair share of the bandwidth.  Packets
> belonging to these flows are typically delivered *immediately* and
> *without loss*.

   This is a nice feature; and I certainly don't mean to badmouth fq_codel.

   But it's guessing... And it depends on those flows being able to know
"their fair share" milliseconds in advance: which can fail on short notce.

   Better would be to identify latency-sensitive flows by a specific signal,
and continue to deliver a "fair share" of packets "immediately" and marked
to show the congestion.

   Consider voice traffic. Voice can be intelligible at rather low data
rates; but sounds much better at higher data rates. For conferencing uses,
low delay is pretty critical.

   Sudden reductions in data rate are annoying, but unexpected silence
while you wait for delayed packets are much worse; and losing track of
how much delay there actually is can be fatal.

   Low-latency is "nice" for all traffic; but I claim it's critical for
voice. (Of course, it's "critical" for some other things, too...)

+++++++++++++++++

   Ideally, each packet would carry an indication of a latency target,
beyond which it's less useful and congestion needs to be indicated. I
have been very disappointed that we designed IPv6 without leaving space
for this.

++++++++++++++++

   (Actually, we _did_ originally design for this: TTL was indended to be
decremented every second, whether or not forwarded. Alas, this was grossly
inadequate resolution; so this usage was abandoned.)

--
John Leslie 


From nobody Wed Nov 30 17:53:50 2016
Return-Path: 
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C32129671; Wed, 30 Nov 2016 17:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEtEo_kGvySs; Wed, 30 Nov 2016 17:53:42 -0800 (PST)
Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C62129BBC; Wed, 30 Nov 2016 17:53:39 -0800 (PST)
Received: by mail-lf0-x244.google.com with SMTP id p100so17565181lfg.2; Wed, 30 Nov 2016 17:53:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HFsnaGFHHHBFSunCWT5YINw57YiaXb236OS0SNOOA5k=; b=z9PL0wsxgjuXuEvkMz42KaCXaF5EPSsdtt1FlJQN5nzhqMOZ19r91LEhorHGKsykYJ eVZryu8g6YKRUqVL6ioErA+OR38MrSkolPyQdp3+Sk7KvtRNrEdDlGi9amNPzSiY1dqz qEyWBUGqbYYH5JxBHgPKwLBOFdZ2/MuHMBzixw4ibo9U3a0MDwyC0v/7OAe6pKsFpsXr 0S+tRqbH+IrMoaCqxg4KXnOsxjyEBn4FQQy8JNfX7XhLIpHaEwePZbDYY5cLxbxbdnuL 8MZp42Po8sbHRXAc9ZqKuuauWK5N7Q44TatfevqP4p0+2nxuhiRBDyd2NhuskIqRyDqz SqWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HFsnaGFHHHBFSunCWT5YINw57YiaXb236OS0SNOOA5k=; b=c/XFWK+82ZMluk+NQ7FQagmlPgp9BY+2zcQcAzxg2zwaJfCIY/ikOV4uzEQhOD+XV3 dsN8yIcYRKqSSbH7EiDVLUqEn6y6u7k1jGQ9+znH6Td5co1JkHf8n1p2IuDMLhOk4VEi k1icXNqmWf1KQCSb/xpAO6yZKSW9b+cej/xeB/pq+Niob2w52t8m5/nMDHs6IGyuME81 kYOz8dkl642TAdIOIgHs7mk5ZI7HjKzaJnaUTXwAgLusSWJzwoEu95G/sbI0qE0PMlRS KFRDVFdWN4727ik/A648TJLTsUDrjsT/FZqVds+AINXw01IjHjvisR8TUfTI/B9z14// NYBw==
X-Gm-Message-State: AKaTC03jj6VE997tVdP9qWhYGuYo4sVXi3hWradVveRTN/MnMnz+DZjxFx6djSunYIdGmg==
X-Received: by 10.25.67.85 with SMTP id m21mr11299886lfj.28.1480557218139; Wed, 30 Nov 2016 17:53:38 -0800 (PST)
Received: from [192.168.100.13] (37-33-82-144.bb.dnainternet.fi. [37.33.82.144]) by smtp.gmail.com with ESMTPSA id s7sm14870498lja.14.2016.11.30.17.53.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Nov 2016 17:53:37 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jonathan Morton 
In-Reply-To: <20161130215608.GC98127@verdi>
Date: Thu, 1 Dec 2016 03:53:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <83C0C0DF-AEA0-4607-86F6-21FB1712BC07@gmail.com>
References:    <627c9db2-a41f-917d-e639-c27df25bdc51@kit.edu> <39e0cfa7-2650-9d98-a933-7e7c016dc276@bobbriscoe.net>  <20161130215608.GC98127@verdi>
To: John Leslie 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: AQM IETF list , tcpm IETF list , tsvwg IETF list , TCP Prague List 
Subject: Re: [tcpm] [aqm] L4S status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Dec 2016 01:53:46 -0000

> On 30 Nov, 2016, at 23:56, John Leslie  wrote:
>=20
> Better would be to identify latency-sensitive flows by a specific =
signal,
> and continue to deliver a "fair share" of packets "immediately" and =
marked
> to show the congestion.

Cake does that, too.  It looks at Diffserv markings and sorts them into =
categories, each having a separate set of queues.  It even takes care to =
avoid both obvious incentives for using inappropriate DSCPs, and hard =
bandwidth caps where there is spare bandwidth to use - properties that =
few other Diffserv implementations achieve simultaneously.

All of the presets (except for a legacy =E2=80=9Cprecedence=E2=80=9D =
mode) recognise at least CS1 (for background traffic, which in theory =
BitTorrent should be using), TOS4 (often used by SSH), CS6 (for NTP), =
and VA/EF (for voice traffic) as distinct from best-effort traffic, and =
apply appropriate parameters.

A similar system can be built using multiple fq_codel instances and a =
classifier, and such a construction has been available as part of =
OpenWRT for some time.

In practice, not very much traffic carries an appropriate Diffserv code. =
 We=E2=80=99ve found the =E2=80=9Csparse =3D latency sensitive=E2=80=9D =
heuristic to be a good one in practice, both in Cake and in fq_codel.

 - Jonathan Morton