From nobody Wed Dec 2 09:45:24 2020 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 196853A14EA; Wed, 2 Dec 2020 09:45:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <160693111905.14242.11959921039067752382@ietfa.amsl.com> Date: Wed, 02 Dec 2020 09:45:19 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-14.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 17:45:19 -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 WG of the IETF. Title : The RACK-TLP loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-14.txt Pages : 31 Date : 2020-12-02 Abstract: This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-14 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-14 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 Thu Dec 3 00:03:02 2020 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 810AE3A07B3; Thu, 3 Dec 2020 00:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 cWWDoNBm4FvH; Thu, 3 Dec 2020 00:02:51 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA03A0D1C; Thu, 3 Dec 2020 00:02:43 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D0C1D280498; Thu, 3 Dec 2020 08:02:38 +0000 (UTC) To: Tom Herbert , Fernando Gont Cc: IPv6 Operations , tcpm , Mark Smith , Brian E Carpenter References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> From: Fernando Gont Message-ID: <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> Date: Thu, 3 Dec 2020 05:02:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 08:02:58 -0000 Hi, Tom, On 29/11/20 13:25, Tom Herbert wrote: >> Modulo the comments I've already made, I'm afraid we might be in the >> path of making the FL unusable... >> > > Fernanda,, > > I really don't understand how this makes the flow label "unusable", to > the contrary this is a useful case with good effect and justifies the > work in the host to set the field. In any case, it would be great if > you could provide the draft with the normative requirements that would > make the flow label "usable". Have the FL identify a flow. packets RTO'ing does not imply that the retransmissions belong to a different flow. FL changing for established sessions will break load-balancers. OTOH, one would still need to anylize what would happen if a SYN RTO-es, gets retransmitted, but both the original and the retransmitted SYN is delivered. > Please include requirements for both hosts and network nodes. If there > is going to the be a requirement that hosts MUST make a 1:1 mapping to > a transport connection and the flow label MUST be consistent for the > life of connection, then I would expect there to also be a requirement > that the flow label MUST be immutable by all devices in the path-- in > particular the requirement of RFC6437 would need to be updated: "A > forwarding node MUST either leave a non-zero flow label value > unchanged or change it only for compelling operational security > reasons..."-- if hosts are not allowed to change a field they are > primarily responsible for setting, then the network should not be > allowed to modify it either. I don't recall _(of the top of my head) why we ended up making the field mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it had to do with allowing middle-boxes to mitigate FL-based covert channels. If that's the case (Brian CC'ed) then, in retrospective, that seems to have been a bad idea. -- I was part of the discussion, so I take my share of blame. :-) > Additionally, if the underlying design principle is that flow > identification in a packet is immutable and persistent, then I'd like > to see the discussion on how that rectifies with NAT where > intermediate nodes routinely change IP addresses and transport port > numbers without the host endpoints' knowledge-- unlike the flow label, > port numbers are formally part of the transport connection > identification, so changing them in flight is far more invasive and > potentially harmful than changing the flow label (we've seen far more > problems caused by NAT than flow label due to NAT state evictions, > packets of a flow being re-routed to not hit the same NAT device, > etc.). You seem to be referring to IPv4 NAT, since IPv6 NPT does not modify the ports. That said, even if IPv6 NAT did, then as long as the FL is consistent from the outside, that's fine. (i.e., the FL remains constant from both the "external realm" pov, and also from the "internal realm" pov). Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 07:44:03 2020 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 935633A0EAA; Thu, 3 Dec 2020 07:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 qo-N9eojRrwy; Thu, 3 Dec 2020 07:44:00 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 406B43A0EA8; Thu, 3 Dec 2020 07:44:00 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 11so2119750oty.9; Thu, 03 Dec 2020 07:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=YbBL7UoB8stOdenoDlgvmWjmK0F9r/QusBVcjr2uzassJN4QyaRu4YT72i4RtHvahg Cvq57cdtNiqKFXPYXmYs25bVHEvRj0uOM4NNm5kvY40Izri3r36dqAhfWnFee8D7bKd0 n+HTgoBGUP2gMK/YLncMKcetKg/Ptw2wHCQ2na2dZDYoi4wQa6DOrT3TqylVDk/MoIX7 xsIbE7bWM8lkhj+4wSelSPjq3oIMpLa2xN/H/1EluIOGhidqbiAZi9BqcUhYzODdD2Ry TBVLlt/fVOYNMkiO4FNTf37Rz6t5aVEZFNfcsRJd6QHGHARW5CtQc8CzG/tJR2st/wf4 vMnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=bVKu1cdZRNcO4oWxP5x6mhBDIKaOBk1zREjKgdD1f/9n0BU7Z9BefrDdug7byTw/AP +Rkdb91nLrmq+6xYRRUWD0esFFjKszx5gZmbIREFmO9BwtIJiVtFHU4AUpOHsnWvmWHT NOBsEO2mDa4ihI/1PMIL1383veBJQ7XclGibzYY1KPKg7d7xW0CwNIHmWWhXowPVtspo S2roF0/wfmrGyYMo8MN2URwokK5TfsiSmF8pi25RHjYzMuwZAdbJD3Q8H2obHrJe+8ey HH8T6sRPks/b9Bq7cUMF04HU9mX6eGPvoZxF9Gaw2aLldRxgogC9QRIae6+faOPmDwfC 9BRA== X-Gm-Message-State: AOAM532z2hBA0Pd01lT//LXT4oBhfp5Di/MRpu+Hq6AEkDXzOzPPluhH 9G8iWv+xIwiWnGHnTHG+H9WQRCqTuWHnZHJN2lEnlOwL/t4= X-Google-Smtp-Source: ABdhPJz8I3Inx3vi4c5yjmgSdh3eJCyyi7m44gfgI9Ijar4SI8PQlahAB2F2Lgb9mRVyQ4Vz6QqOkiCrXVPa9efRYNo= X-Received: by 2002:a9d:62cb:: with SMTP id z11mr2444166otk.191.1607010239448; Thu, 03 Dec 2020 07:43:59 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> In-Reply-To: <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Erik Kline Date: Thu, 3 Dec 2020 07:43:48 -0800 Message-ID: To: Fernando Gont Cc: Tom Herbert , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 15:44:02 -0000 > > Please include requirements for both hosts and network nodes. If there > > is going to the be a requirement that hosts MUST make a 1:1 mapping to > > a transport connection and the flow label MUST be consistent for the > > life of connection, then I would expect there to also be a requirement > > that the flow label MUST be immutable by all devices in the path-- in > > particular the requirement of RFC6437 would need to be updated: "A > > forwarding node MUST either leave a non-zero flow label value > > unchanged or change it only for compelling operational security > > reasons..."-- if hosts are not allowed to change a field they are > > primarily responsible for setting, then the network should not be > > allowed to modify it either. > > I don't recall _(of the top of my head) why we ended up making the field > mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > had to do with allowing middle-boxes to mitigate FL-based covert > channels. If that's the case (Brian CC'ed) then, in retrospective, that > seems to have been a bad idea. -- I was part of the discussion, so I > take my share of blame. :-) My understanding/recollection is that since there were never any restrictions on modification of the flow label from the very beginning it wasn't super meaningful to try to close the barn door after all these years. From nobody Thu Dec 3 08:08:54 2020 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 38D073A0EB2; Thu, 3 Dec 2020 08:08:50 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 l-dL_QExK2jU; Thu, 3 Dec 2020 08:08:47 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D833A0E29; Thu, 3 Dec 2020 08:08:46 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C0E242803C8; Thu, 3 Dec 2020 16:08:42 +0000 (UTC) To: Erik Kline Cc: Tom Herbert , Fernando Gont , IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Fernando Gont Message-ID: <86de5b0a-73b1-320a-166b-152567d4e313@si6networks.com> Date: Thu, 3 Dec 2020 13:08:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 16:08:50 -0000 On 3/12/20 12:43, Erik Kline wrote: >>> Please include requirements for both hosts and network nodes. If there >>> is going to the be a requirement that hosts MUST make a 1:1 mapping to >>> a transport connection and the flow label MUST be consistent for the >>> life of connection, then I would expect there to also be a requirement >>> that the flow label MUST be immutable by all devices in the path-- in >>> particular the requirement of RFC6437 would need to be updated: "A >>> forwarding node MUST either leave a non-zero flow label value >>> unchanged or change it only for compelling operational security >>> reasons..."-- if hosts are not allowed to change a field they are >>> primarily responsible for setting, then the network should not be >>> allowed to modify it either. >> >> I don't recall _(of the top of my head) why we ended up making the field >> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it >> had to do with allowing middle-boxes to mitigate FL-based covert >> channels. If that's the case (Brian CC'ed) then, in retrospective, that >> seems to have been a bad idea. -- I was part of the discussion, so I >> take my share of blame. :-) > > My understanding/recollection is that since there were never any > restrictions on modification of the flow label from the very beginning > it wasn't super meaningful to try to close the barn door after all > these years. Well, yeah, but there was also no use of the FL, either ;-) . And for load-balancing among a group of servers, you need the FL to be stable for the life of the flow, or otherwise packet may end up ebig delivered to different servers. Otherwise, the FL is likely to be inored, and we'll continue figuring out what to use those 20 bits for... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 09:31:02 2020 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 4BA0B3A0A1C for ; Thu, 3 Dec 2020 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 hloNCCsEfcsh for ; Thu, 3 Dec 2020 09:30:59 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 DF0323A09C9 for ; Thu, 3 Dec 2020 09:30:58 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id qw4so4622444ejb.12 for ; Thu, 03 Dec 2020 09:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=JsyTgtjwWqbesx9WmpkjHKhgm+A20C2FRZrslv20jOhSfGD9v2vSiM5ssw7IH+btCi BPOVnEe9AAD5Lq6MY5xysJrmWPNGfsaKZWTlVL2wdN0tU6K+f+M0iLyihjBy+6NlxcmI r3Ahhp118YqZzr1HZV803K/jvSvmTJVykGIwrrDluiQuIAXRty3iZnwfsI03SywftN23 DnQqzGVhlFfAVZRd3fuv4lXwotdDeOeLjrwNZajhWVhgih0XWGAydaJil7KPDXlrpgQ4 Y84qtHGNptq5hE9dn++XdVONsHAPIW+mgtFvPaxD9xv4zPVc5ZVjTrMptXvw0NZzHvzt aHWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=RsHVcmpru377WIohyjcxISXt/ve1A2yVdIj11HRyALxI4tNkRCLNWXMoSMtt1gfLLg QFTT35A69yvfkt0VlaYr1+nHvsHJeYtm+4MYTB66wjoRRy6jjmLP8WcAZXN06cKw+Wv7 ECSUnwQ0RvBqN8HkTn5/WpYhCr3wBl43jIbUBQoJLTuR7MMaEqdeWGuroq1JSaRg7vt2 D51IFn4oUp4rmbR3ZZrhlUBFA0lTCrAh4H0IVWgV9ZHsy27SbWFqq6cWcocyJ4f/9CNk HFulZ0kM1wHJ9hieow+MMSd1V+DYTOFnVjmCzmZ/6OKwhX2MQArDkvjCKgM2EkPpsBiC PFvA== X-Gm-Message-State: AOAM532EEhs5n4UxeYNUxwtitrc4exZ9nFZcnfXIhmJqWVTpdHL+iGZI 1t2Vt/+7oPcMW/TjLjgqTrGEIm7EJnNR3a9JxG5eLA== X-Google-Smtp-Source: ABdhPJyQO3nqK6zp3jU+YFnu28S5HOMBcOTffN700tu6Btr61fvvq3fnPN22roqyXMbpJ59WDubFfLf7xkrU4VCYgjA= X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr3590035ejc.295.1607016656907; Thu, 03 Dec 2020 09:30:56 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> In-Reply-To: From: Tom Herbert Date: Thu, 3 Dec 2020 10:30:45 -0700 Message-ID: To: Erik Kline Cc: Fernando Gont , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 17:31:00 -0000 On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: > > > > Please include requirements for both hosts and network nodes. If there > > > is going to the be a requirement that hosts MUST make a 1:1 mapping to > > > a transport connection and the flow label MUST be consistent for the > > > life of connection, then I would expect there to also be a requirement > > > that the flow label MUST be immutable by all devices in the path-- in > > > particular the requirement of RFC6437 would need to be updated: "A > > > forwarding node MUST either leave a non-zero flow label value > > > unchanged or change it only for compelling operational security > > > reasons..."-- if hosts are not allowed to change a field they are > > > primarily responsible for setting, then the network should not be > > > allowed to modify it either. > > > > I don't recall _(of the top of my head) why we ended up making the field > > mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > > had to do with allowing middle-boxes to mitigate FL-based covert > > channels. If that's the case (Brian CC'ed) then, in retrospective, that > > seems to have been a bad idea. -- I was part of the discussion, so I > > take my share of blame. :-) > > My understanding/recollection is that since there were never any > restrictions on modification of the flow label from the very beginning > it wasn't super meaningful to try to close the barn door after all > these years. Erik, There are two apropos statements in RFC6437: "There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on unmodified and uniformly distributed flow labels; they have a "best effort" quality." "From an upper-layer viewpoint, a flow could consist of all packets in one direction of a specific transport connection or media stream. However, a flow is not necessarily 1:1 mapped to a transport connection." So building a load balancer, or any other intermediate network device, that *depends* on the flow label to be consistent for the life of a transport connection and 1:1 mapped to a transport connection is contrary to this guidance. The ship has already sailed on this in deployment, and even if the protocol requirements were to be sufficiently tightened that would take years to reach full effect and that would preclude other use cases where modifying the flow label is useful. If a stable 1:1 mapped identifier for transport ports is needed in the network layer, it might make sense to create a new HBH option for that. Personally, if I were building a load balancer I'd use neither the flow label nor transport ports for entropy, I'd look at using the destination address since 128 bits allows plenty of bits of entropy, it's consistent per transport flow and always set in an IPv6 packet. Tom Tom From nobody Thu Dec 3 11:29:17 2020 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 DB3483A08AB; Thu, 3 Dec 2020 11:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mQdgsDouTeRy; Thu, 3 Dec 2020 11:29:11 -0800 (PST) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 B6F703A08AE; Thu, 3 Dec 2020 11:29:10 -0800 (PST) Received: by mail-il1-x133.google.com with SMTP id v3so2993516ilo.5; Thu, 03 Dec 2020 11:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S5EJv2HjCwDF9Rsx/GmSUv1qH8/urHNbI3IO182n5ss=; b=C+Pw3mvB+RSID8av2LLv+Ydb2v/BIRViCHV79kc0ImQhP7iC3JYatRWct7/pOl/iWs 2NBVi/PBXQKFZme+QparemqGqMCJFmTCqK+CS48zEoFe+ha9RswkQYHQs0OUES4I2zKV NArjP0yzQhPleNNErz5U64WqR9fNXDZsIauXsiYV/vh7nftMrrToBa6iYYr27iuad/Ur B00hJ16p9rnYrZK2Q2xrrJOv1KvMOaQRiXjT7WdrlvNT6pudQrjxeMi7aGliKUXbVXO3 pwGzvaK/wkvM7oGk8TWEarzpQjhTVR0zLQh/NvFY92zHUsIZuA424eQWfSlk+0J6RRFZ xqRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S5EJv2HjCwDF9Rsx/GmSUv1qH8/urHNbI3IO182n5ss=; b=r54NrbQ4lXenJGeHZq2Rpr+x6bzo6awbpjIil6MujvhDaOqdQcYQetml0RoJGygP0E DlTKt5w0+N/pedd+vdajGIj8IaWLDxyI8+6FsQBGQBAU0CU8XpvylsQ4nrJ01WYKNOQS j6DZ5tTObG9cjI8+wvgI9OhJpe0U9pDMNDlpfO/PsRt8skHljpsP6W1p6NUMQuxutcR5 lsEm7XdpmISNNWHx31JRmkweVttD79dBx/lXphp8dWRXkKlLLWy07m7H9+F6TxQz2gg4 QOLb2NUoDsnc8Hte71fa8J8yVbiRlD3XaQj8FjxI31ZPp1hrDDfSXkGBwREzdl7ybbvZ q7mg== X-Gm-Message-State: AOAM5318MWrSYL9feZvvoKEhsZBpfcBEXA62vtp30kIGycrfE5ZbgLFQ NGnytiyg+gFYW+YymLFA7Cc63AGUfJfH3Uz2qtU= X-Google-Smtp-Source: ABdhPJyYQNQGD4ahtE2yFRKiMYbncP7ZfBV/fsKv0a0kp4VWUga4szmTgsLi09uXW8yx1bY3UbLqtbgrNA5wEe480+U= X-Received: by 2002:a92:680b:: with SMTP id d11mr758484ilc.287.1607023749766; Thu, 03 Dec 2020 11:29:09 -0800 (PST) MIME-Version: 1.0 References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> In-Reply-To: From: Martin Duke Date: Thu, 3 Dec 2020 11:28:58 -0800 Message-ID: To: "Scheffenegger, Richard" Cc: Mirja Kuehlewind , Neal Cardwell , "Scharf, Michael" , Bob Briscoe , Michael Tuexen , tcpm IETF list , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c0224605b5945fe4" Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 19:29:15 -0000 --000000000000c0224605b5945fe4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As an individual, I support 2 option codes. On Mon, Nov 23, 2020 at 4:43 AM Scheffenegger, Richard < Richard.Scheffenegger@netapp.com> wrote: > I am also in favor of using two distinct option codes. > > However, > > > Or I guess we could say that only one option should be used for a > connection. > > I am opposed to this - with two option codes, a sender should be free to > choose whichever he prevers at any one point; For example, if the sender = a > segment (e.g. may be the receiver side) has to update the EE1 couter, bu= t > also convey SACK information, it would be good to use the one, where the > EE1 field is first, and omit all remaining fields; > > Later in the same connection, that very same host may choose to update th= e > CE field together with some SACK information, and use the other codepoint > in order to preserve as much TCP option space for the SACK option... > > > As for extensibility: I would want to avoid that topic, and just specifiy > the three correct supported lengths here, and not mention (other than > ignoring "odd" fractionals of the 3-byte wide counters) what happens with > other lengths... > > > Richard Scheffenegger > > -----Urspr=C3=BCngliche Nachricht----- > Von: Mirja Kuehlewind > Gesendet: Montag, 23. November 2020 12:39 > An: Neal Cardwell ; Scharf, Michael < > Michael.Scharf@hs-esslingen.de>; Bob Briscoe > Cc: Yoshifumi Nishida ; tcpm IETF list ; > Scheffenegger, Richard ; Michael Tuexen > ; tcpm-chairs@ietf.org > Betreff: Re: [tcpm] AccECN field order > > NetApp Security WARNING: This is an external email. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > > > > Hi all, > > I think I also support two options as this is the most simple solution. > > We probably need to look at section 3.2.3.2. (Path Traversal of the AccEC= N > Option) again, as I think this section assumes mostly one option. Or I > guess we could say that only one option should be used for a connection. > > Regarding use of the option length for extensibility. I know new options > are hard to deploy but that=E2=80=99s the extensibility mechanism we have= with TCP. > Not sure we want to invent a new now. If we think we need more > extensibility for AccECN for any reason, we should specify valid option > length values that include a flags field now. > > Mirja > > > > > On 18. Nov 2020, at 01:03, Neal Cardwell wrote: > > > > As someone who contributes to a TCP implementation, I would put in a > vote for the "Two Option Kinds" proposal outlined in slide 6 here: > > > > > > https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor > > e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica > > tion-01#page=3D6 > > > > This approach has the virtue of simplicity, which hopefully may help > avoid middlebox bugs, speed standardization and development, and ease the > process of maintaining fast and stable implementations. > > > > neal > > > > > > On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael < > Michael.Scharf@hs-esslingen.de> wrote: > > Inline some comments [ms]. > > > > > > > > Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll not f= ollow-up forever > in this discussion. I don=E2=80=99t own running code and a lot of encodin= g details > mainly affect an implementation. > > > > > > > > IMHO the rest of the WG has to think about the option design more than > > me. So, this is mostly about triggering a discussion=E2=80=A6 > > > > > > > > From: Bob Briscoe > > Sent: Tuesday, November 17, 2020 1:20 PM > > To: Scharf, Michael ; Yoshifumi > > Nishida > > Cc: Michael Tuexen ; tcpm-chairs@ietf.org; > > Mirja Kuehlewind ; Scheffenegger, Richard > > ; tcpm IETF list > > Subject: Re: AccECN field order > > > > > > > > Michael, > > > > On 17/11/2020 08:10, Scharf, Michael wrote: > > > > Bob, > > > > > > > > I am fine with the two option kinds proposed in -13, but I don=E2=80=99= t buy > your arguments why this encoding is better than others. > > > > > > > > Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward comp= atibility=E2=80=9D > argument is a very compelling reason for two codepoints. All proposals I = am > aware of have their pros and cons. And I am not aware of a really > comprehensive discussion. At least neither the e-mail below nor today=E2= =80=99s > meeting discuss all tradeoffs I would investigate. > > > > > > [BB] You're right - the discussion below is useful and necessary. > > > > > > > > > > > > For instance, the benefit of the length encoding variant would be to > consume only one TCP option codepoint now. If we decided later to that a > flag byte is needed (say, at the end), a follow-up proposed standard coul= d > specify another option format with that flag byte, using a second codepoi= nt. > > > > > > [BB] > > * The new codepoint would require years to deploy (including in proxies= ) > before it works e2e. > > > > > > > > [ms] That may depend *a lot* on the environment. In environments where > ECN can get deployed today, say in datacenters, rolling out a new kernel > version may perhaps not be the biggest operational challenge. Also, proxi= es > may not be a significant problem in some of those cases. Deployment > roadmaps are very hard to predict. > > > > > > * Whereas the 'forward compatibility' approach tries to ensure that > AccECN implementations that are being built today will be ready to > interwork with a future extension. > > * In contrast, if your hypothetical new AccECN codepoint did need to be > deployed later, it would need to include a fall-back to the current AccEC= N > option when one peer doesn't understand the new codepoint. > > > > > > > > [ms] This is a reasonable point, albeit not a particularly strong one, > > given that the option is not really required for basic > > interoperability. Also, a hypothetical follow-up standard could > > include a way to explicitly request the option=E2=80=A6 > > > > > > * Fall-back would need to avoid a second round of handshake (given > > this is for low latency), which would only work reliably with an > > option on the SYN (because the 3rd ACK is unreliable) > > > > > > > > [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting Acc= ECN > option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cplease se= nd me the better AccECN > option B=E2=80=9D after the 3-WHS. It could be an upgrade, not a fallback= . Also, at > this point we don=E2=80=99t know what option B would be and in which cont= ext it > would be needed. Maybe other protocol features would require negotiation, > too. IMHO it is a solvable problem. > > > > > > * AccECN has so far avoided using any SYN option space, which is > important given that is the scarcest resource. > > > > > > > > [ms] Yep, but as long as no proposal needs SYN options, this is nothing > that would make one solution better than another. > > > > These days, extending TCP is like playing chess - we have to think > multiple moves ahead! > > > > > > > > [ms] There is one fundamental difference between chess and TCP: In ches= s > you precisely know the current situation and can predict all potential > moves in advance (albeit there are a lot). However, we don=E2=80=99t know= the > future evolution of TCP, ECN and the Internet as a whole, nor future > requirements. If we try to engineer a TCP extension for some potential > future, we may figure out later that reality is different from what we > designed for. As much as I appreciate your attempts to predict the future= , > it would be a big surprise to me if you could correctly predict what TCP > will be in 10 years from now. So, instead of trying to write specificatio= ns > that take into account future requirements, which are in fact just unknow= n, > it is more important for me to write effective, efficient and secure > specifications for what is currently known for sure. > > > > > > > > [ms] I *don=E2=80=99t* know for sure whether the current AccECN option = will be > needed, but I see quite some evidence that support of the AccECN option(s= ) > is not a top priority these days. That is also something to think about > when designing the details. > > > > > > > > I need to learn to articulate onto the list all my reasons for rejectin= g > certain parts of the design space. Sorry about that. > > > > Yes, I admit, the current proposal is at the cost of burning two TCP > option codepoints. However, you said yourself when you proposed this > approach, that they are not (currently) a scarce resource. Certainly not = as > scarce as option space. I just checked: roughly 15% of the option codepoi= nt > allocation space has been used so far. So that's where I would suggest we > compromise first. > > > > [ms] I made a similar calculation some years ago and came to a similar > conclusion. Investing two codepoints for AccECN is something we can > probably afford. But nonetheless we have to reason carefully why it is > really worth the effort. > > > > > > > > > > Regarding the resulting codepoint consumption (two option kinds) and th= e > addition of a flag byte, this approach would basically end up with the sa= me > result as the current proposal in -13 plus some hypothetical future > addition leveraging the length field beyond the currently known use. > > > > > > > > And, yes, the length encoding variant may be less flexible and/or > consume some more bits in some cases, but on the plus side it only needs > one codepoint now =E2=80=93 and given that it is entirely unclear whether= any > AccECN option will indeed be widely used in future, this is a big plus. T= he > fact that implementers are quite silent on the option design is not a goo= d > sign. > > > > > > [BB] Here's another possibility then. > > > > a) [K|L| EE1B | ECEB | EE0B ] > > b) [K|L| EE1B | ECEB | EE0B |F] if F =3D 0bXXXXXXX0 > > c) [K|L| EE0B | ECEB | EE1B |F] if F =3D 0bXXXXXXX1 > > > > We'd have to decide which order alternative (a) takes. I've picked EE1B > first only 'cos you're right that there is not currently as much pressure > (on the public Internet) for AccECN with ECT(0). > > > > =3D=3DLegend=3D=3D > > K: Kind (1B) > > L: Length (1B) > > ExxB: Echo xx byte counter > > F: Flags (1B) > > > > Alternatives a) and b) are equivalent, at least while the only allocate= d > flag is for field order. > > However, alternative b) is available in case other flags are allocated > > in future The flags byte can only be omitted if (L % 3 =3D=3D 2). > > The flags byte is considered present if (L % 3) =3D=3D 0. > > > > Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be assumed to > include a flags byte, and current implementations ignore the last byte. > > > > The flags byte is optional to implement (even if the AccECN option is > > implemented) If the server includes a flags byte on the SYN/ACK but the > client does not include one on the 3rd ACK or the first data packet, the > server assumes the client does not implement the flags byte and uses only > alternative a) for the remainder of the connection. > > > > > > [ms] I am not sure if we need that, but I take this as existence proof > that other encodings are possible. Personally, I think that other solutio= ns > would be doable if you took one bit from one or multiple counters for > format encoding. At least for some of the byte counters I don=E2=80=99t t= hink > taking one bit for other purposes would result in an Internet congestion > collapse=E2=80=A6 But, I have already said that the -13 proposal works fo= r me, so > I=E2=80=99ll not try to come up with another variant myself. > > > > > > > > To me, one potential difference between two proposals would be > incremental deployment. The proposal in -13 only has an advantage if > middleboxes such as firewalls will indeed pass TCP options with a format > that contains content beyond the (first) Accurate ECN standard (i.e., > currently unused length values). IMHO it is too early to know whether > firewalls would indeed allow this in future. > > > > > > > > From a security perspective, it is not clear to me whether allowing > arbitrary unspecified bytes in a TCP option is a good idea *at all*. It > will be interesting to hear the opinion from SEC area on that. Personally= , > I am not convinced that this really makes sense, but I my concerns are no= t > strong enough to formally push back. I=E2=80=99ll leave it to others to t= hink about > whether this is a bug or a feature. > > > > > > [BB] Well, let's first try to deal with security ourselves: > > * Octets that are explicitly declared as part of an option cannot be > used for a buffer overflow attack. I don't really need to, but I could ad= d > the following text to the forward compatibility wording: > > A receiver considers octets beyond those it uses, but within the > specified length, as if they are padding. > > * And such octets cannot be any different from the current ability of a > sender to add padding. So there's no new attack possible here. > > * And there's no need to specify a max length for any AccECN Option, > which would just unnecessarily limit flexibility. > > > > [ms] I have more thought about the covert channel that some unspecified > bytes in a standards track TCP option could offer=E2=80=A6 In particular = if the > AccECN option gets widely deployed and used, would some malicious users > find those bytes useful? For what? For instance, what in the AccECN > protocol design prevents use of these =E2=80=9Cpadding=E2=80=9D bytes as = super-cookie? To > me, it is much more important to think about abuse of whatever we > standardize *now*, instead of engineering for some entirely unknown futur= e. > I am not a security expert, but I suggest a careful analysis of any > security implications of the AccECN option. We seldomly specify new TCP > options and malicious users will certainly look for =E2=80=9Copportunitie= s=E2=80=9D in the > spec. So far, I don=E2=80=99t know whether that whole idea of forward com= patibility > is a feature or a bug. > > > > > > > > Michael > > > > > > > > Maybe one lesson learnt is that the document could have a non-normative > appendix that explains the rationale for the finally picked TCP option > encoding. That may also help if there are further questions whether two > codepoints are really required, e.g. by the IESG (if two codepoints are > still the design after WGLC). At least for past TCP option codepoint > allocations I recall some discussions late in the IETF process. In those > past cases, good arguments in an appendix and running code has helped a l= ot. > > > > > > [BB] I can do that. Appx B is already similar, giving Design Rationale > for the ACE field. > > > > > > Bob > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > From: Bob Briscoe > > Sent: Tuesday, November 17, 2020 6:10 AM > > To: Scharf, Michael ; Yoshifumi > > Nishida > > Cc: Michael Tuexen ; tcpm-chairs@ietf.org; > > Mirja Kuehlewind ; Scheffenegger, Richard > > ; tcpm IETF list > > Subject: Re: AccECN field order > > > > > > > > Michael, > > > > On 16/11/2020 17:36, Scharf, Michael wrote: > > > > Bob, > > > > > > > > One proposal using the length field with *one option codepoint only* > > is detailed in: > > https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo > > / > > > > > > > > It is the third option mentioned in this e-mail. One example would be t= o > use option length values 5/8/11 for one encoding type and option length > values 6/9/12 for the other encoding type (i.e., order of fields). Or one > could use some other combination of length values =E2=80=93 the only requ= irement is > that a certain value for the option length is only used by one of the > option formats. In that approach, the value of the length field would thu= s > directly describe the encoding of the option. Unless I miss something, th= is > would work and it would just require one option codepoint. > > > > > > > > Thus, alternatives to two option codepoints exist and I have explained > them on the list in March 2020. > > > > > > OK, sorry, yes, I remember this now. > > > > As I will explain in the AccECN status update talk today in virtual > Bangkok, the draft has made provision for different length values than > 5/8/11. It says existing implementations MUST accept length values other > than those currently defined. But then read in as many whole 3-byte field= s > as they can. > > > > This can be used to add a flags byte on the end in future, for > extensibility. Or any other form of extensibility the WG might decide in > the future. > > > > I know a flags byte at the end seems odd compared to at the beginning. > But (if decided it's needed in future) it's reasonably easy to implement = by > reading the whole option, then processing the last byte, before reading t= he > rest of the option. > > > > I believe you will agree that this is a better way to utilize different > lengths. > > > > And thank you for repeatedly emphasizing that you're happy with the > 2-kind scheme, or other alternatives. > > > > > > Bob > > > > > > > > > > > > > > Anyway, I don=E2=80=99t really care how the options are encoded as long= as the > receiver doesn=E2=80=99t need per-connection state for decoding a TCP opt= ion. So, > personally, I would be fine with using e.g. the length field as described > in my old e-mail. Or an additional flag byte. And one could come up with > further encodings, e.g., by using one or a few bits as a short =E2=80=9Ct= ype=E2=80=9D field > for each counter. This is all about protocol engineering. And all these > variants have their pros and cons. > > > > > > > > I am also fine with using two option codepoints as specified in -13; > this is probably the approach that consumes the least number of bits. > > > > > > > > Michael (w/o any hat) > > > > > > > > > > > > > > > > From: Bob Briscoe > > Sent: Monday, November 16, 2020 5:52 PM > > To: Yoshifumi Nishida > > Cc: Scharf, Michael ; Michael Tuexen > > ; tcpm-chairs@ietf.org; Mirja Kuehlewind > > ; Scheffenegger, Richard > > ; tcpm IETF list > > Subject: AccECN field order > > > > > > > > Yoshi, (adding the tcpm list in cc) > > > > On 05/11/2020 06:58, Yoshifumi Nishida wrote: > > > > Hi Bob, > > > > > > > > On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe wrote: > > > > Yoshi, > > > > On 04/11/2020 06:51, Yoshifumi Nishida wrote: > > > > Hi, folks, > > > > > > > > > > > > > > In my understanding, I'm not sure if we settled down on using two optio= n > kinds or encoding schemes for 24bits fields in acc ecn draft. > > > > So, I think there're still something to be clarified and hope things > will be settled at the meeting. > > > > > > [BB] I know a WG can change it's mind at any time. But I'd rather we > just clarified what a previous decision was, to avoid the need to keep > re-opening discussion on a question that have been decided then changed > three different ways already. > > > > My memory is not so good these days. I trusted that Michael S remembere= d > the decision correctly, and I seem to remember that decision being made. > > I've just checked the minutes of the last interim: > > > > https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 > > 1600/ and they mention Michael's proposal to use two kinds, but don't > > record any decision. > > The jabber log gives no clues about any decision. > > > > I can't find an audio or video recording. Can you point me at one? > > > > > > > > I thought that it's because there was no clear decision at the meeting. > > > > But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA > > > > Please let us know if you have any questions or opinions with regard to > this. > > > > > > [BB] I checked the Youtube link you sent below. > > > > First I think we're agreed no-one was fighting for us to keep the > previous way we did this (using the initial value of the field to set the > order for the connection). > > In my presentation I said there was strong resistance from Michael to d= o > it a different way. > > (also, offlist, the co-authors including me also didn't like this so > > much. And Ilpo said it made the implementation complex.) > > > > Then came the question of what we do instead. There were three > alternative proposals: > > a) use 2 option kinds > > b) add a flags byte > > c) somehow use the length field maybe > > > > Michael raised (c) in the meeting as a possibility, but no-one could > think how to distinguish two options of the same length but a different > field order using the length field. Michael said he'd post any ideas to t= he > list if he could think of any, but that didn't happen. > > > > So we're left choosing between (a) and (b). > > I said in the meeting (and on the list when discussing with Ilpo) that > I'd be happy to go with (b), but only if there was another use for a flag= . > Because it would consume 1B more options space in many packets, which is = a > scarce resource. > > > > Ilpo had a proposed use for another flag (to help synch counters after = a > loss), but I think the discussion about it ended that it wouldn't be > helpful, 'cos the way it worked depended on itself (circular logic). > > > > In conclusion, I don't think there was an explicit decision to go with = 2 > option kinds, but it ended up as the 'last person standing'. > > I like it. It's simple. And apparently option kinds are not such a > scarce resource. > > > > Perhaps we can ratify this in the WG tomorrow. > > > > > > Bob > > > > > > > > > > > > > > > > Thanks, > > > > -- > > > > Yoshi > > > > > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000c0224605b5945fe4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an individual, I support 2 option codes.

On Mon, Nov 23,= 2020 at 4:43 AM Scheffenegger, Richard <Richard.Scheffenegger@netapp.com> wrote:
I am also in favor of = using two distinct option codes.

However,

> Or I guess we could say that only one option should be used for a conn= ection.

I am opposed to this - with two option codes, a sender should be free to ch= oose whichever he prevers at any one point; For example, if the sender a se= gment (e.g. may be the receiver side)=C2=A0 has to update the EE1 couter, b= ut also convey SACK information, it would be good to use the one, where the= EE1 field is first, and omit all remaining fields;

Later in the same connection, that very same host may choose to update the = CE field together with some SACK information, and use the other codepoint i= n order to preserve as much TCP option space for the SACK option...


As for extensibility: I would want to avoid that topic, and just specifiy t= he three correct supported lengths here, and not mention (other than ignori= ng "odd" fractionals of the 3-byte wide counters) what happens wi= th other lengths...


Richard Scheffenegger

-----Urspr=C3=BCngliche Nachricht-----
Von: Mirja Kuehlewind <ietf@kuehlewind.net>
Gesendet: Montag, 23. November 2020 12:39
An: Neal Cardwell <ncardwell@google.com>; Scharf, Michael <Michael.Scharf@hs-esslingen= .de>; Bob Briscoe <ietf@bobbriscoe.net>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm IETF list <tcpm@ietf.org>; Scheffenegger, Richard= <= Richard.Scheffenegger@netapp.com>; Michael Tuexen <tuexen@fh-muenster.de>;= tcpm-chairs@ietf= .org
Betreff: Re: [tcpm] AccECN field order

NetApp Security WARNING: This is an external email. Do not click links or o= pen attachments unless you recognize the sender and know the content is saf= e.




Hi all,

I think I also support two options as this is the most simple solution.

We probably need to look at section 3.2.3.2. (Path Traversal of the AccECN = Option) again, as I think this section assumes mostly one option. Or I gues= s we could say that only one option should be used for a connection.

Regarding use of the option length for extensibility. I know new options ar= e hard to deploy but that=E2=80=99s the extensibility mechanism we have wit= h TCP. Not sure we want to invent a new now. If we think we need more exten= sibility for AccECN for any reason, we should specify valid option length v= alues that include a flags field now.

Mirja



> On 18. Nov 2020, at 01:03, Neal Cardwell <ncardwell@google.com> wrote:
>
> As someone who contributes to a TCP implementation, I would put in a= =C2=A0 vote for the "Two Option Kinds" proposal outlined in slide= 6 here:
>
>=C2=A0
> https://datatracker.ietf.= org/meeting/109/materials/slides-109-tcpm-mor
> e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica=
> tion-01#page=3D6
>
> This approach has the virtue of simplicity, which hopefully may help a= void middlebox bugs, speed standardization and development, and ease the pr= ocess of maintaining fast and stable implementations.
>
> neal
>
>
> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael <Michael.Scharf@hs-essling= en.de> wrote:
> Inline some comments [ms].
>
>
>
> Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll not = follow-up forever in this discussion. I don=E2=80=99t own running code and = a lot of encoding details mainly affect an implementation.
>
>
>
> IMHO the rest of the WG has to think about the option design more than=
> me. So, this is mostly about triggering a discussion=E2=80=A6
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 1:20 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi > Nishida <ns= d.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 17/11/2020 08:10, Scharf, Michael wrote:
>
> Bob,
>
>
>
> I am fine with the two option kinds proposed in -13, but I don=E2=80= =99t buy your arguments why this encoding is better than others.
>
>
>
> Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward com= patibility=E2=80=9D argument is a very compelling reason for two codepoints= . All proposals I am aware of have their pros and cons. And I am not aware = of a really comprehensive discussion. At least neither the e-mail below nor= today=E2=80=99s meeting discuss all tradeoffs I would investigate.
>
>
> [BB] You're right - the discussion below is useful and necessary.<= br> >
>
>
>
>
> For instance, the benefit of the length encoding variant would be to c= onsume only one TCP option codepoint now. If we decided later to that a fla= g byte is needed (say, at the end), a follow-up proposed standard could spe= cify another option format with that flag byte, using a second codepoint. >
>
> [BB]
> * The new codepoint would require years to deploy (including in proxie= s) before it works e2e.
>
>
>
> [ms] That may depend *a lot* on the environment. In environments where= ECN can get deployed today, say in datacenters, rolling out a new kernel v= ersion may perhaps not be the biggest operational challenge. Also, proxies = may not be a significant problem in some of those cases. Deployment roadmap= s are very hard to predict.
>
>
> * Whereas the 'forward compatibility' approach tries to ensure= that AccECN implementations that are being built today will be ready to in= terwork with a future extension.
> * In contrast, if your hypothetical new AccECN codepoint did need to b= e deployed later, it would need to include a fall-back to the current AccEC= N option when one peer doesn't understand the new codepoint.
>
>
>
> [ms] This is a reasonable point, albeit not a particularly strong one,=
> given that the option is not really required for basic
> interoperability. Also, a hypothetical follow-up standard could
> include a way to explicitly request the option=E2=80=A6
>
>
> * Fall-back would need to avoid a second round of handshake (given > this is for low latency), which would only work reliably with an
> option on the SYN (because the 3rd ACK is unreliable)
>
>
>
> [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting Ac= cECN option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cplease= send me the better AccECN option B=E2=80=9D after the 3-WHS. It could be a= n upgrade, not a fallback. Also, at this point we don=E2=80=99t know what o= ption B would be and in which context it would be needed. Maybe other proto= col features would require negotiation, too. IMHO it is a solvable problem.=
>
>
> * AccECN has so far avoided using any SYN option space, which is impor= tant given that is the scarcest resource.
>
>
>
> [ms] Yep, but as long as no proposal needs SYN options, this is nothin= g that would make one solution better than another.
>
> These days, extending TCP is like playing chess - we have to think mul= tiple moves ahead!
>
>
>
> [ms] There is one fundamental difference between chess and TCP: In che= ss you precisely know the current situation and can predict all potential m= oves in advance (albeit there are a lot). However, we don=E2=80=99t know th= e future evolution of TCP, ECN and the Internet as a whole, nor future requ= irements. If we try to engineer a TCP extension for some potential future, = we may figure out later that reality is different from what we designed for= . As much as I appreciate your attempts to predict the future, it would be = a big surprise to me if you could correctly predict what TCP will be in 10 = years from now. So, instead of trying to write specifications that take int= o account future requirements, which are in fact just unknown, it is more i= mportant for me to write effective, efficient and secure specifications for= what is currently known for sure.
>
>
>
> [ms] I *don=E2=80=99t* know for sure whether the current AccECN option= will be needed, but I see quite some evidence that support of the AccECN o= ption(s) is not a top priority these days. That is also something to think = about when designing the details.
>
>
>
> I need to learn to articulate onto the list all my reasons for rejecti= ng certain parts of the design space. Sorry about that.
>
> Yes, I admit, the current proposal is at the cost of burning two TCP o= ption codepoints. However, you said yourself when you proposed this approac= h, that they are not (currently) a scarce resource. Certainly not as scarce= as option space. I just checked: roughly 15% of the option codepoint alloc= ation space has been used so far. So that's where I would suggest we co= mpromise first.
>
> [ms] I made a similar calculation some years ago and came to a similar= conclusion. Investing two codepoints for AccECN is something we can probab= ly afford. But nonetheless we have to reason carefully why it is really wor= th the effort.
>
>
>
>
> Regarding the resulting codepoint consumption (two option kinds) and t= he addition of a flag byte, this approach would basically end up with the s= ame result as the current proposal in -13 plus some hypothetical future add= ition leveraging the length field beyond the currently known use.
>
>
>
> And, yes, the length encoding variant may be less flexible and/or cons= ume some more bits in some cases, but on the plus side it only needs one co= depoint now =E2=80=93 and given that it is entirely unclear whether any Acc= ECN option will indeed be widely used in future, this is a big plus. The fa= ct that implementers are quite silent on the option design is not a good si= gn.
>
>
> [BB] Here's another possibility then.
>
> a) [K|L| EE1B | ECEB | EE0B ]
> b) [K|L| EE1B | ECEB | EE0B |F]=C2=A0 =C2=A0 if F =3D 0bXXXXXXX0
> c) [K|L| EE0B | ECEB | EE1B |F]=C2=A0 =C2=A0 if F =3D 0bXXXXXXX1
>
> We'd have to decide which order alternative (a) takes. I've pi= cked EE1B first only 'cos you're right that there is not currently = as much pressure (on the public Internet) for AccECN with ECT(0).
>
> =3D=3DLegend=3D=3D
> K:=C2=A0 =C2=A0 Kind (1B)
> L:=C2=A0 =C2=A0 Length (1B)
> ExxB: Echo xx byte counter
> F:=C2=A0 =C2=A0 Flags (1B)
>
> Alternatives a) and b) are equivalent, at least while the only allocat= ed flag is for field order.
> However, alternative b) is available in case other flags are allocated=
> in future The flags byte can only be omitted if (L % 3 =3D=3D 2).
> The flags byte is considered present if (L % 3) =3D=3D 0.
>
> Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be assumed t= o include a flags byte, and current implementations ignore the last byte. >
> The flags byte is optional to implement (even if the AccECN option is =
> implemented) If the server includes a flags byte on the SYN/ACK but th= e client does not include one on the 3rd ACK or the first data packet, the = server assumes the client does not implement the flags byte and uses only a= lternative a) for the remainder of the connection.
>
>
> [ms] I am not sure if we need that, but I take this as existence proof= that other encodings are possible. Personally, I think that other solution= s would be doable if you took one bit from one or multiple counters for for= mat encoding. At least for some of the byte counters I don=E2=80=99t think = taking one bit for other purposes would result in an Internet congestion co= llapse=E2=80=A6 But, I have already said that the -13 proposal works for me= , so I=E2=80=99ll not try to come up with another variant myself.
>
>
>
> To me, one potential difference between two proposals would be increme= ntal deployment. The proposal in -13 only has an advantage if middleboxes s= uch as firewalls will indeed pass TCP options with a format that contains c= ontent beyond the (first) Accurate ECN standard (i.e., currently unused len= gth values). IMHO it is too early to know whether firewalls would indeed al= low this in future.
>
>
>
> From a security perspective, it is not clear to me whether allowing ar= bitrary unspecified bytes in a TCP option is a good idea *at all*. It will = be interesting to hear the opinion from SEC area on that. Personally, I am = not convinced that this really makes sense, but I my concerns are not stron= g enough to formally push back. I=E2=80=99ll leave it to others to think ab= out whether this is a bug or a feature.
>
>
> [BB] Well, let's first try to deal with security ourselves:
> * Octets that are explicitly declared as part of an option cannot be u= sed for a buffer overflow attack. I don't really need to, but I could a= dd the following text to the forward compatibility wording:
>=C2=A0 =C2=A0 =C2=A0A receiver considers octets beyond those it uses, b= ut within the specified length, as if they are padding.
> * And such octets cannot be any different from the current ability of = a sender to add padding. So there's no new attack possible here.
> * And there's no need to specify a max length for any AccECN Optio= n, which would just unnecessarily limit flexibility.
>
> [ms] I have more thought about the covert channel that some unspecifie= d bytes in a standards track TCP option could offer=E2=80=A6 In particular = if the AccECN option gets widely deployed and used, would some malicious us= ers find those bytes useful? For what? For instance, what in the AccECN pro= tocol design prevents use of these =E2=80=9Cpadding=E2=80=9D bytes as super= -cookie? To me, it is much more important to think about abuse of whatever = we standardize *now*, instead of engineering for some entirely unknown futu= re. I am not a security expert, but I suggest a careful analysis of any sec= urity implications of the AccECN option. We seldomly specify new TCP option= s and malicious users will certainly look for =E2=80=9Copportunities=E2=80= =9D in the spec. So far, I don=E2=80=99t know whether that whole idea of fo= rward compatibility is a feature or a bug.
>
>
>
> Michael
>
>
>
> Maybe one lesson learnt is that the document could have a non-normativ= e appendix that explains the rationale for the finally picked TCP option en= coding. That may also help if there are further questions whether two codep= oints are really required, e.g. by the IESG (if two codepoints are still th= e design after WGLC). At least for past TCP option codepoint allocations I = recall some discussions late in the IETF process. In those past cases, good= arguments in an appendix and running code has helped a lot.
>
>
> [BB] I can do that. Appx B is already similar, giving Design Rationale= for the ACE field.
>
>
> Bob
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 6:10 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi > Nishida <ns= d.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, Richard
> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 16/11/2020 17:36, Scharf, Michael wrote:
>
> Bob,
>
>
>
> One proposal using the length field with *one option codepoint only* <= br> > is detailed in:
> https://mailarchive.ietf.= org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo
> /
>
>
>
> It is the third option mentioned in this e-mail. One example would be = to use option length values 5/8/11 for one encoding type and option length = values 6/9/12 for the other encoding type (i.e., order of fields). Or one c= ould use some other combination of length values =E2=80=93 the only require= ment is that a certain value for the option length is only used by one of t= he option formats. In that approach, the value of the length field would th= us directly describe the encoding of the option. Unless I miss something, t= his would work and it would just require one option codepoint.
>
>
>
> Thus, alternatives to two option codepoints exist and I have explained= them on the list in March 2020.
>
>
> OK, sorry, yes, I remember this now.
>
> As I will explain in the AccECN status update talk today in virtual Ba= ngkok, the draft has made provision for different length values than 5/8/11= . It says existing implementations MUST accept length values other than tho= se currently defined. But then read in as many whole 3-byte fields as they = can.
>
> This can be used to add a flags byte on the end in future, for extensi= bility. Or any other form of extensibility the WG might decide in the futur= e.
>
> I know a flags byte at the end seems odd compared to at the beginning.= But (if decided it's needed in future) it's reasonably easy to imp= lement by reading the whole option, then processing the last byte, before r= eading the rest of the option.
>
> I believe you will agree that this is a better way to utilize differen= t lengths.
>
> And thank you for repeatedly emphasizing that you're happy with th= e 2-kind scheme, or other alternatives.
>
>
> Bob
>
>
>
>
>
>
> Anyway, I don=E2=80=99t really care how the options are encoded as lon= g as the receiver doesn=E2=80=99t need per-connection state for decoding a = TCP option. So, personally, I would be fine with using e.g. the length fiel= d as described in my old e-mail. Or an additional flag byte. And one could = come up with further encodings, e.g., by using one or a few bits as a short= =E2=80=9Ctype=E2=80=9D field for each counter. This is all about protocol = engineering. And all these variants have their pros and cons.
>
>
>
> I am also fine with using two option codepoints as specified in -13; t= his is probably the approach that consumes the least number of bits.
>
>
>
> Michael (w/o any hat)
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Monday, November 16, 2020 5:52 PM
> To: Yoshifumi Nishida <nsd.ietf@gmail.com>
> Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Michael Tuexe= n
> <tuexen@= fh-muenster.de>; tcpm-chairs@ietf.org; Mirja Kuehlewind
> <ietf@kueh= lewind.net>; Scheffenegger, Richard
> <Richard.Scheffenegger@netapp.com>; tcpm IETF list <tcpm@ietf.org>
> Subject: AccECN field order
>
>
>
> Yoshi, (adding the tcpm list in cc)
>
> On 05/11/2020 06:58, Yoshifumi Nishida wrote:
>
> Hi Bob,
>
>
>
> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Yoshi,
>
> On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>
> Hi, folks,
>
>
>
>
>
>
> In my understanding, I'm not sure if we settled down on using two = option kinds or encoding schemes for 24bits fields in acc ecn draft.
>
> So, I think there're still something to be clarified and hope thin= gs will be settled at the meeting.
>
>
> [BB] I know a WG can change it's mind at any time. But I'd rat= her we just clarified what a previous decision was, to avoid the need to ke= ep re-opening discussion on a question that have been decided then changed = three different ways already.
>
> My memory is not so good these days. I trusted that Michael S remember= ed the decision correctly, and I seem to remember that decision being made.=
> I've just checked the minutes of the last interim:
>=C2=A0 =C2=A0 =C2=A0
> https://datatracker.ietf.= org/doc/minutes-interim-2020-tcpm-01-20200429
> 1600/ and they mention Michael's proposal to use two kinds, but do= n't
> record any decision.
> The jabber log gives no clues about any decision.
>
> I can't find an audio or video recording. Can you point me at one?=
>
>
>
> I thought that it's because there was no clear decision at the mee= ting.
>
> But, you can check https://www.youtube.com/watch?v= =3DKsB0_Nb8-kA
>
> Please let us know if you have any questions or opinions with regard t= o this.
>
>
> [BB] I checked the Youtube link you sent below.
>
> First I think we're agreed no-one was fighting for us to keep the = previous way we did this (using the initial value of the field to set the o= rder for the connection).
> In my presentation I said there was strong resistance from Michael to = do it a different way.
> (also, offlist, the co-authors including me also didn't like this = so
> much. And Ilpo said it made the implementation complex.)
>
> Then came the question of what we do instead. There were three alterna= tive proposals:
> a) use 2 option kinds
> b) add a flags byte
> c) somehow use the length field maybe
>
> Michael raised (c) in the meeting as a possibility, but no-one could t= hink how to distinguish two options of the same length but a different fiel= d order using the length field. Michael said he'd post any ideas to the= list if he could think of any, but that didn't happen.
>
> So we're left choosing between (a) and (b).
> I said in the meeting (and on the list when discussing with Ilpo) that= I'd be happy to go with (b), but only if there was another use for a f= lag. Because it would consume 1B more options space in many packets, which = is a scarce resource.
>
> Ilpo had a proposed use for another flag (to help synch counters after= a loss), but I think the discussion about it ended that it wouldn't be= helpful, 'cos the way it worked depended on itself (circular logic). >
> In conclusion, I don't think there was an explicit decision to go = with 2 option kinds, but it ended up as the 'last person standing'.=
> I like it. It's simple. And apparently option kinds are not such a= scarce resource.
>
> Perhaps we can ratify this in the WG tomorrow.
>
>
> Bob
>
>
>
>
>
>
>
> Thanks,
>
> --
>
> Yoshi
>
>
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://bobbriscoe.net/=
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000c0224605b5945fe4-- From nobody Thu Dec 3 11:32:09 2020 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 160FF3A08D4 for ; Thu, 3 Dec 2020 11:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2GfSnepOvVql for ; Thu, 3 Dec 2020 11:32:05 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 4E8713A08B1 for ; Thu, 3 Dec 2020 11:32:05 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id n4so3255077iow.12 for ; Thu, 03 Dec 2020 11:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=At+tsy6mRHAls2spJn3cuRvAi9KQ5euCp4lmJ0TY5qE=; b=QycVHU73lULEyb8k9z5xWMCXiQ3P1A4UOLEW4cvy4Z2hSbBIAcIHHwZ8rJaUPfIxBk OvYtYzYlRD0xVpS2UMMvlgs4U5j/JM+uot6fH/Cc2x28qGoQoA71m4zJERJM3dnxqY1x XbCpEP3dVSERxjZZ6Tcf3dskUum/LZcXftoeK0cWUI+3n2JNFPhFIocrQuZbFuyD2z6Y p4J5jgAgmQ1/WvzO9si0LllpmSrVJfxIxHvjtaoPaXq7zviBM/8tzACozUoafjKhyBPN khR+s4tA9kjHx2dl3aNGFXiO/i3zfdYDFClE9cshbMcwS+ediAE/SOEmyoktKBecvCXk owPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=At+tsy6mRHAls2spJn3cuRvAi9KQ5euCp4lmJ0TY5qE=; b=MrRs9WkNoTiXFWowf0hsKWZoDkBB0IY8dInLJNXiLc8hVhsgvmZDoRUpI97Sx12ude Rhg1nW2asY3tEXi3VSSqj4/Q/M8sfzd7hFzVWHGhuuh+fb0ayx3P/NSP5qyrDtvWKjlP C3QXjSwxt89W9DkHVFs+j4eN477E22NxGOqjO2e7n7bWpcPvsO1xP1iomGUG71Gwl/QB BWwfDqLZuRf62tB27WEI+FCCQzPzCWm/Vcw4SYsi53EHsfVTQyHGi2tuhk7TBTlZae7g Y828O4N2/RXgUoHHiQralrESXRPebO9Guac3byM8rzKPVWgWoDY8scIhZgpa8iXNwzp+ aOww== X-Gm-Message-State: AOAM5319cFXSHu7fxt5TR8KokhWB0xeZ+22xJA825WaZte6AxwhYzXVO ShOwwVg+4vTXXBFQ/inaeg4BMkk0cZree6Tfk/7mMgtQCtA= X-Google-Smtp-Source: ABdhPJxl9x1d6fyrcaT6kkNmFgh+cfuLTwUsiJc0m61xpYkQXyZwWD7+9wp/G/SJxaL41PAeQWHoFqNupB35gP+9PPM= X-Received: by 2002:a05:6602:20ca:: with SMTP id 10mr931390ioz.51.1607023924592; Thu, 03 Dec 2020 11:32:04 -0800 (PST) MIME-Version: 1.0 References: <885d9aa0-50b2-3101-64b8-7a40f25ca612@erg.abdn.ac.uk> In-Reply-To: From: Martin Duke Date: Thu, 3 Dec 2020 11:31:53 -0800 Message-ID: To: Yuchung Cheng Cc: Neal Cardwell , Praveen Balasubramanian , "mattmathis=40google.com@dmarc.ietf.org" , "tcpm@ietf.org" , "ianswett=40google.com@dmarc.ietf.org" Content-Type: multipart/alternative; boundary="0000000000002bc54e05b5946a28" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Introduce RFC 6937 bis (Proportional Rate Reduction) as a tcpm work item? INPUT NEEDED X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 19:32:08 -0000 --0000000000002bc54e05b5946a28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am definitely in favor of taking widely-adopted Experimental documents and updating/upgrading them, including this one. On Fri, Nov 20, 2020 at 12:52 PM Yuchung Cheng wrote: > Thanks for everybody's reply and support > > One additional thing we authors would like more feedback on is ECN. The > current RFC and proposed -bis do not cover ECN handling. However in Linux= , > ECN handling uses the same PRR algorithm (aka "CWR" aka "cwnd reduction") > just like fast recovery. In other words, if RFC3168 or DCTCP triggers a > congestion window reduction, PRR takes over to control the transmission > until SND_UNA crosses SND.NXT upon reduction. > > This arrangement was inherented from the original Linux rate-halving > design before the PRR was introduced. This paper has details > https://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf > > Compared to fast recovery, this part of the implementation is far less > tested due to the lack of wide classic-ECN usage on the Internet. It's al= so > unclear how other PRR implementations have applied to ECN handling like > Linux does. Adding ECN handling in -bis PS makes me uneasy. > > On Thu, Nov 19, 2020 at 12:57 PM Neal Cardwell 40google.com@dmarc.ietf.org> wrote: > >> I am very supportive of updating PRR to PS status and adopting this as a >> TCPM work item. I will be happy to review the document as well. >> >> The "Tentative path forward" outlined by Matt sounds good to me. >> >> best, >> neal >> >> >> >> >> On Thu, Nov 19, 2020 at 12:37 PM Praveen Balasubramanian > 40microsoft.com@dmarc.ietf.org> wrote: >> >>> I am supportive of updating PRR to PS status and will review the >>> document. >>> >>> >>> >>> Re. QUIC. The current loss recovery spec for QUIC already refers to PRR >>> as a MAY and has similar other references to TCP RFCs without any >>> additional text for QUIC specific adaptations. The current title of RFC >>> 6937 scopes it to TCP: Proportional Rate Reduction for TCP. I also see >>> about 38 hits for the word TCP in the text. >>> >>> >>> >>> *From:* tcpm *On Behalf Of * Matt Mathis >>> *Sent:* Thursday, November 19, 2020 8:41 AM >>> *To:* Gorry Fairhurst ; Ian Swett >> 40google.com@dmarc.ietf.org> >>> *Cc:* tcpm@ietf.org Extensions >>> *Subject:* [EXTERNAL] Re: [tcpm] Introduce RFC 6937 bis (Proportional >>> Rate Reduction) as a tcpm work item? INPUT NEEDED >>> >>> >>> >>> If we can get away with a non-normative description of the heuristic, >>> QUIC is no problem at all. If we need normative descriptions, then T= CP >>> and QUIC have to be different, and we need to include normative referen= ces >>> to both recovery machines and recovery state variables, which are not i= n >>> scope for the current doc. >>> >>> >>> >>> I would prefer to stay with a non-normative description of the >>> heuristic, and scrub the rest of the document for language that conflic= ts >>> with QUIC. >>> >>> >>> Thanks, >>> >>> --MM-- >>> The best way to predict the future is to create it. - Alan Kay >>> >>> We must not tolerate intolerance; >>> >>> however our response must be carefully measured: >>> >>> too strong would be hypocritical and risks spiraling out of >>> control; >>> >>> too weak risks being mistaken for tacit approval. >>> >>> >>> >>> >>> >>> On Thu, Nov 19, 2020 at 6:37 AM Gorry Fairhurst >>> wrote: >>> >>> On 19/11/2020 14:20, Ian Swett wrote: >>> >>> I support this work. >>> >>> >>> >>> One question for authors and the group. This specification could be >>> applied to QUIC, but my memory is that there are some small changes to >>> adapt it correctly. Would noting those changes be in scope for this >>> document, a separate document in QUIC, or an exercise left to the reade= r? >>> I'd be happy to contribute any QUIC specific text if that's helpful. >>> >>> >>> >>> Thanks, Ian >>> >>> I'd hope the differences for QUIC ARE captured in the RFC series. If >>> they are small, it might be possible to add to this draft perhaps? >>> >>> Gorry >>> >>> >>> >>> On Thu, Nov 19, 2020 at 2:43 AM Scheffenegger, Richard >>> wrote: >>> >>> As the heuristic is the one major improvement over RFC6937, that is the >>> one area I am especially interested in. Currently working to have PRR i= n >>> FreeBSD, it would be the best time window to add this heuristig instead >>> of switching between the two variants in a static fashion. >>> >>> I support this and will certainly be reviewing the documents and provid= e >>> feedback! >>> >>> Richard >>> >>> >>> Am 19.11.2020 um 04:56 schrieb Matt Mathis: >>> > The authors of PRR would like to update PRR to Proposed Standard >>> > status. This entails introducing a new document as an tcpm work item= . >>> > >>> > *Please indicate (non) support and/or comment.* >>> > >>> > For more details see the tcpm meeting materials from IETF 109 >>> > minutes: >>> > https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-0= 0 >>> >>> > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 >>> >>> > >>> > There were about four "I support this work" remarks at the mic (not >>> > recorded in the minutes), and about as many in the Meetecho chat. >>> > >>> > Abridged IETF/tcpm/PRRbis slides: >>> > -- >>> > PRR recap (RFC6937 experimental) >>> > PRR is a special congestion control effective only during fast recove= ry >>> > >>> > * When inflight >=3D ssthresh, send at loss_beta*rate_before_loss (= e.g. >>> > loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cubic) >>> > * When inflight < ssthresh, send at the same or twice the >>> > delivery_rate (more later) >>> > * Used by all congestion control modules in Linux during fast >>> recovery >>> > o Can be more dominant than the actual C.C. for lossy flows >>> > that=E2=80=99re in fast recovery constantly (e.g. video strea= ming >>> > through policers) >>> > >>> > -- >>> > Current Status >>> > >>> > * >>> > >>> > PRR is widely deployed >>> > >>> > o >>> > >>> > At least three major OSs: Linux, Windows, (NetFlix) BSD >>> > >>> > o >>> > >>> > Vast majority of Web traffic for years >>> > >>> > * >>> > >>> > No changes to algorithms published in RFC 6937 >>> > >>> > o >>> > >>> > PRR-CRB - Conservative Reduction Bound - strict packet >>> > conversion during loss recovery >>> > >>> > o >>> > >>> > PRR-SSRB - Slowstart Reduction Bound - one extra segment per >>> ACK >>> > during loss recovery >>> > >>> > * >>> > >>> > 2015 Heuristic to dynamically select which reduction bound >>> > >>> > o >>> > >>> > Only use PRR-SSRB when making good forward progress >>> > >>> > + >>> > >>> > ACKs that advanced snd.una and report no new losses >>> > >>> > o >>> > >>> > Resolves some pathological cases with token bucket policers >>> > >>> > + >>> > >>> > CC estimates ssthresh before it can possibly measure the >>> > token rate >>> > >>> > + >>> > >>> > The heuristic makes the best of a bad situation >>> > >>> > -- >>> > Tentative path forward >>> > >>> > * >>> > >>> > Adopt as a tcpm work item >>> > >>> > * >>> > >>> > Update the text >>> > >>> > o >>> > >>> > Normative RFC 2119 language >>> > >>> > o >>> > >>> > Add MAY use the heuristic... >>> > >>> > o >>> > >>> > Trim redundant and obsolete language >>> > >>> > + >>> > >>> > RFC 6937 repeats itself and is much longer than necessary >>> > >>> > + >>> > >>> > Focus on what an implementer needs to know >>> > >>> > + >>> > >>> > Use non-normative references to RFC 6937 for prior >>> > measurement work, etc >>> > >>> > Thanks, >>> > --MM-- >>> > The best way to predict the future is to create it. - Alan Kay >>> > >>> > We must not tolerate intolerance; >>> > however our response must be carefully measured: >>> > too strong would be hypocritical and risks spiraling out >>> of >>> > control; >>> > too weak risks being mistaken for tacit approval. >>> > >>> > _______________________________________________ >>> > tcpm mailing list >>> > tcpm@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tcpm >>> >>> > >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> >>> _______________________________________________ >>> >>> tcpm mailing list >>> >>> tcpm@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000002bc54e05b5946a28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am definitely in favor of taking widely-adopted Experime= ntal documents and updating/upgrading them, including this one.

On Fri, Nov = 20, 2020 at 12:52 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:
Thanks= for everybody's reply and support

One additional t= hing we authors would like more feedback on is ECN. The current RFC and pro= posed -bis do not cover ECN handling. However in Linux, ECN handling uses t= he same PRR algorithm (aka "CWR" aka "cwnd reduction") = just like fast recovery. In other words, if RFC3168 or DCTCP triggers a con= gestion window reduction, PRR takes over to control the transmission until = SND_UNA crosses SND.NXT=C2=A0upon reduction.=C2=A0

This = arrangement was inherented from the original Linux rate-halving design befo= re the PRR was introduced. This paper has details=C2=A0htt= ps://www.cs.helsinki.fi/research/iwtcp/papers/linuxtcp.pdf

Compared to fast recovery, this part of the implementation is far le= ss tested due to the lack of wide classic-ECN usage on the Internet. It'= ;s also unclear how other PRR implementations have applied to ECN handling = like Linux does. Adding ECN handling in -bis PS makes me uneasy.

On Thu, Nov 19, 2020 at 12:57 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ie= tf.org> wrote:
I am very supportive of updating PRR to PS status an= d adopting this as a TCPM work item. I will be happy to review the document= as well.

The "Tentative path forward" outlined by Matt so= unds good to me.

best,
neal




On = Thu, Nov 19, 2020 at 12:37 PM Praveen Balasubramanian <pravb=3D40microsoft.co= m@dmarc.ietf.org> wrote:

I am supportive of updating PRR to PS status and wil= l review the document.

=C2=A0

Re. QUIC. The current loss recovery spec for QUIC al= ready refers to PRR as a MAY and has similar other references to TCP RFCs w= ithout any additional text for QUIC specific adaptations. The current title= of RFC 6937 scopes it to TCP: Proportional Rate Reduction for TCP. I also see about 38 hits for the word TCP in the t= ext.

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Matt Mathis
Sent: Thursday, November 19, 2020 8:41 AM
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>; Ian Swett <ianswett=3D40google.com@dma= rc.ietf.org>
Cc: tcpm@ietf.org= Extensions <tcpm= @ietf.org>
Subject: [EXTERNAL] Re: [tcpm] Introduce RFC 6937 bis (Proportional = Rate Reduction) as a tcpm work item? INPUT NEEDED

=C2=A0

If we can get away with a non-normative description = of the heuristic, QUIC is no problem at all.=C2=A0 =C2=A0 If we need normat= ive descriptions, then TCP and QUIC have to be different, and we need to in= clude normative references to both recovery machines and recovery state=C2=A0variables, which are not in scope for the= current doc.

=C2=A0

I would prefer to stay with a non-normative descript= ion of the heuristic, and scrub the rest of the document for language that = conflicts with QUIC.


Thanks,

--MM--
The best way to predict the future is to create it. =C2=A0- Alan Kay

We must not tolerate intolerance;

=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must= be carefully measured:=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong= would be hypocritical and risks spiraling out of control;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak r= isks being mistaken for tacit approval.

=C2=A0

=C2=A0

On Thu, Nov 19, 2020 at 6:37 AM Gorry Fairhurst <= gorry@erg.abdn.ac= .uk> wrote:

On 19/11/2020 14:20, Ian Swett wrote:<= /p>

I support this work.

=C2=A0

One question for authors and the group.=C2=A0 This s= pecification=C2=A0could be applied to QUIC, but my memory is that there are= some small changes to adapt it correctly.=C2=A0 Would noting those changes= be in scope for this document, a separate document in QUIC, or an exercise left to the reader?=C2=A0 I'd be happy to cont= ribute any QUIC specific text if that's helpful.

=C2=A0

Thanks, Ian

I'd hope the differences for QUIC ARE captured in the RFC series. If= they are small, it might be possible to add to this draft perhaps?

Gorry

=C2=A0

On Thu, Nov 19, 2020 at 2:43 AM Scheffenegger, Richa= rd <rs.ietf@gmx.at> wrote:

As the heuristic is the one major improvement over R= FC6937, that is the
one area I am especially interested in. Currently working to have PRR in FreeBSD, it would be the best time window to add this heuristig instead
of switching between the two variants in a static fashion.

I support this and will certainly be reviewing the documents and provide feedback!

Richard


Am 19.11.2020 um 04:56 schrieb Matt Mathis:
> The authors of PRR would like to update PRR to Proposed Standard
> status.=C2=A0 This entails introducing a new document as an tcpm work = item.
>
> *Please indicate (non) support and/or comment.*
>
> For more details see the tcpm meeting materials from IETF 109
> minutes:
> https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-00<= br> > slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00
>
> There were about four "I support this work" remarks at the m= ic (not
> recorded in the minutes), and about as many in the Meetecho chat.
>
> Abridged IETF/tcpm/PRRbis slides:
> --
> PRR =C2=A0recap (RFC6937 experimental)
> PRR is a special congestion control effective only during fast recover= y
>
>=C2=A0 =C2=A0* When inflight >=3D ssthresh, send at loss_beta*rate_b= efore_loss (e.g.
>=C2=A0 =C2=A0 =C2=A0loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 = for Cubic)
>=C2=A0 =C2=A0* When inflight < ssthresh, send at the same or twice t= he
>=C2=A0 =C2=A0 =C2=A0delivery_rate (more later)
>=C2=A0 =C2=A0* Used by all congestion control modules in Linux during f= ast recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o Can be more dominant than the actual C.C. = for lossy flows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0that=E2=80=99re in fast recovery cons= tantly (e.g. video streaming
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0through policers)
>
> --
> Current Status
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0PRR is widely deployed
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At least three major OSs: Linux, Wind= ows, (NetFlix) BSD
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Vast majority of Web traffic for year= s
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0No changes to algorithms published in RFC 6937
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRR-CRB - Conservative Reduction Boun= d - strict packet
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0conversion during loss recovery
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PRR-SSRB - Slowstart Reduction Bound = - one extra segment per ACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0during loss recovery
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A02015 Heuristic to dynamically select which reductio= n bound
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Only use PRR-SSRB when making good fo= rward progress
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ACKs that advanced snd.= una and report no new losses
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Resolves some pathological cases with= token bucket policers
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CC estimates ssthresh b= efore it can possibly measure the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token rate
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The heuristic makes the= best of a bad situation
>
> --
> Tentative path forward
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0Adopt as a tcpm work item
>
>=C2=A0 =C2=A0*
>
>=C2=A0 =C2=A0 =C2=A0Update the text
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Normative RFC 2119 language
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Add MAY use the heuristic...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0o
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Trim redundant and obsolete language<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6937 repeats itself= and is much longer than necessary
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Focus on what an implem= enter needs to know
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Use non-normative refer= ences to RFC 6937 for prior
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0measurement work, etc >
> Thanks,
> --MM--
> The best way to predict the future is to create it. =C2=A0- Alan Kay >
> We must not tolerate intolerance;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefull= y measured:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hy= pocritical and risks spiraling out of
> control;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being m= istaken for tacit approval.
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

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

=C2=A0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm=

=C2=A0

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000002bc54e05b5946a28-- From nobody Thu Dec 3 11:42:54 2020 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 4FD4D3A0C01; Thu, 3 Dec 2020 11:42:41 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mYbz3k9XNrk3; Thu, 3 Dec 2020 11:42:38 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28343A0BCC; Thu, 3 Dec 2020 11:42:37 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6304B283B84; Thu, 3 Dec 2020 19:42:34 +0000 (UTC) To: Tom Herbert , Erik Kline Cc: Fernando Gont , IPv6 Operations , tcpm References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Fernando Gont Message-ID: <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> Date: Thu, 3 Dec 2020 16:40:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 19:42:49 -0000 On 3/12/20 14:30, Tom Herbert wrote: [....] > > There are two apropos statements in RFC6437: > > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on unmodified and > uniformly distributed flow labels; they have a "best effort" quality." > > "From an upper-layer viewpoint, a flow could consist of all packets in > one direction of a specific transport connection or media stream. > However, a flow is not necessarily 1:1 mapped to a transport > connection." > > So building a load balancer, or any other intermediate network device, > that *depends* on the flow label to be consistent for the life of a > transport connection and 1:1 mapped to a transport connection is > contrary to this guidance. We don't need 1:1. We just need 1:N where N is how flows would be aggregated/grouped for the purpose of load-sharing. > The ship has already sailed on this in > deployment, and even if the protocol requirements were to be > sufficiently tightened that would take years to reach full effect and > that would preclude other use cases where modifying the flow label is > useful. If a stable 1:1 mapped identifier for transport ports is > needed in the network layer, it might make sense to create a new HBH > option for that. The above said, I would probably agree that if havinga non-stable FL breaks something, whatever it breaks is probably already broken, since there's not even a checksum to try to detect whether the IPv6 header has been corrupted. > Personally, if I were building a load balancer I'd > use neither the flow label nor transport ports for entropy, I'd look > at using the destination address since 128 bits allows plenty of bits > of entropy, it's consistent per transport flow and always set in an Problem is that if you have two systems that need a lot of banswitdth (e.g., they are transferring file via several TCP connections)< you wouldn't be able to load-share them -- since the result of the hash would be the sme for all TCP connections.... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 11:56:23 2020 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 BAF0B3A05F8; Thu, 3 Dec 2020 11:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xWrTUDD_NjKV; Thu, 3 Dec 2020 11:56:17 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 7563B3A0930; Thu, 3 Dec 2020 11:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kjh4z0DOE7ovsdPslv3PETmzracEiU3LEmbdceRFcS0=; b=bFgPl4m7mUf346VaNa8DA1lo7 0Rmn0d7Gkq8ml8x9akD5869neSRPCXyVrVnz2L6Lpz2aPMngZLG3SvL6OWzk5mKInKssePPTsb4WP 35UaMfKMers4YSVSs3BKL2lHdiCxxK4Pnr3g6paooRCEV6Usjhb+4RnJGGerzm4TF8nhVUB2rp2DH RXfabJqhMsX7tzzZoI1VLOB0o9w8WjMTww1EXyeyx/9+2sGqqOkEKVSxMIUugW984itnAxRsn51Cl 8XsAN2zNNCZVnBYUqOcAFlRZ9EdSXJYNT1zvzjCjG5J2iqLRiy49L9Fq3aJn3MFZxi32fE1necXLS IRwbENyOg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55417 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkui2-0034NS-7s; Thu, 03 Dec 2020 14:56:16 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_5E5EB7C9-E1C0-4EAC-A9BE-8632165096BA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 3 Dec 2020 11:56:09 -0800 Cc: "Scheffenegger, Richard" , tcpm IETF list , Michael Tuexen , Mirja Kuehlewind , "tcpm-chairs@ietf.org" Message-Id: References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net> <30781ea61a794131beafe9997ed9221a@hs-esslingen.de> <1c927b36-7228-91f3-4d58-6f3545c88a57@bobbriscoe.net> <5c3c4661887c43529b35bd5f47d10c2b@hs-esslingen.de> To: Martin Duke X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] AccECN field order X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 19:56:22 -0000 --Apple-Mail=_5E5EB7C9-E1C0-4EAC-A9BE-8632165096BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, I support one option only. I understand the issue with the extra byte - it makes all the different = lengths one byte longer, which seems prohibitive. However, why not simply use a bit out of the 24-bit counter? You = currently use only the 24 LSB anyway; how much worse would it be to use = only 23 bits? If so, that allows encoding the order in any of the lengths without = needing either an extra byte or two code points. FWIW, the end of Sec 2.2 refers to LSB as =E2=80=9Cbits=E2=80=9D; it = seems like it should be bytes. Joe > On Dec 3, 2020, at 11:28 AM, Martin Duke = wrote: >=20 > As an individual, I support 2 option codes. >=20 > On Mon, Nov 23, 2020 at 4:43 AM Scheffenegger, Richard = > wrote: > I am also in favor of using two distinct option codes. >=20 > However, >=20 > > Or I guess we could say that only one option should be used for a = connection. >=20 > I am opposed to this - with two option codes, a sender should be free = to choose whichever he prevers at any one point; For example, if the = sender a segment (e.g. may be the receiver side) has to update the EE1 = couter, but also convey SACK information, it would be good to use the = one, where the EE1 field is first, and omit all remaining fields; >=20 > Later in the same connection, that very same host may choose to update = the CE field together with some SACK information, and use the other = codepoint in order to preserve as much TCP option space for the SACK = option... >=20 >=20 > As for extensibility: I would want to avoid that topic, and just = specifiy the three correct supported lengths here, and not mention = (other than ignoring "odd" fractionals of the 3-byte wide counters) what = happens with other lengths...=20 >=20 >=20 > Richard Scheffenegger >=20 > -----Urspr=C3=BCngliche Nachricht----- > Von: Mirja Kuehlewind >=20 > Gesendet: Montag, 23. November 2020 12:39 > An: Neal Cardwell >; Scharf, Michael = >; Bob Briscoe = > > Cc: Yoshifumi Nishida >; tcpm IETF list >; Scheffenegger, Richard = >; Michael Tuexen = >; = tcpm-chairs@ietf.org > Betreff: Re: [tcpm] AccECN field order >=20 > NetApp Security WARNING: This is an external email. Do not click links = or open attachments unless you recognize the sender and know the content = is safe. >=20 >=20 >=20 >=20 > Hi all, >=20 > I think I also support two options as this is the most simple = solution. >=20 > We probably need to look at section 3.2.3.2. (Path Traversal of the = AccECN Option) again, as I think this section assumes mostly one option. = Or I guess we could say that only one option should be used for a = connection. >=20 > Regarding use of the option length for extensibility. I know new = options are hard to deploy but that=E2=80=99s the extensibility = mechanism we have with TCP. Not sure we want to invent a new now. If we = think we need more extensibility for AccECN for any reason, we should = specify valid option length values that include a flags field now. >=20 > Mirja >=20 >=20 >=20 > > On 18. Nov 2020, at 01:03, Neal Cardwell > wrote: > > > > As someone who contributes to a TCP implementation, I would put in a = vote for the "Two Option Kinds" proposal outlined in slide 6 here: > > > > =20 > > = https://datatracker.ietf.org/meeting/109/materials/slides-109-tcpm-mor = > > = e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica > > tion-01#page=3D6 > > > > This approach has the virtue of simplicity, which hopefully may help = avoid middlebox bugs, speed standardization and development, and ease = the process of maintaining fast and stable implementations. > > > > neal > > > > > > On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael = > = wrote: > > Inline some comments [ms]. > > > > > > > > Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll = not follow-up forever in this discussion. I don=E2=80=99t own running = code and a lot of encoding details mainly affect an implementation. > > > > > > > > IMHO the rest of the WG has to think about the option design more = than=20 > > me. So, this is mostly about triggering a discussion=E2=80=A6 > > > > > > > > From: Bob Briscoe > > > Sent: Tuesday, November 17, 2020 1:20 PM > > To: Scharf, Michael >; Yoshifumi=20 > > Nishida > > > Cc: Michael Tuexen >; tcpm-chairs@ietf.org = ;=20 > > Mirja Kuehlewind >; = Scheffenegger, Richard=20 > > >; tcpm IETF list = > > > Subject: Re: AccECN field order > > > > > > > > Michael, > > > > On 17/11/2020 08:10, Scharf, Michael wrote: > > > > Bob, > > > > > > > > I am fine with the two option kinds proposed in -13, but I don=E2=80=99= t buy your arguments why this encoding is better than others. > > > > > > > > Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward = compatibility=E2=80=9D argument is a very compelling reason for two = codepoints. All proposals I am aware of have their pros and cons. And I = am not aware of a really comprehensive discussion. At least neither the = e-mail below nor today=E2=80=99s meeting discuss all tradeoffs I would = investigate. > > > > > > [BB] You're right - the discussion below is useful and necessary. > > > > > > > > > > > > For instance, the benefit of the length encoding variant would be to = consume only one TCP option codepoint now. If we decided later to that a = flag byte is needed (say, at the end), a follow-up proposed standard = could specify another option format with that flag byte, using a second = codepoint. > > > > > > [BB] > > * The new codepoint would require years to deploy (including in = proxies) before it works e2e. > > > > > > > > [ms] That may depend *a lot* on the environment. In environments = where ECN can get deployed today, say in datacenters, rolling out a new = kernel version may perhaps not be the biggest operational challenge. = Also, proxies may not be a significant problem in some of those cases. = Deployment roadmaps are very hard to predict. > > > > > > * Whereas the 'forward compatibility' approach tries to ensure that = AccECN implementations that are being built today will be ready to = interwork with a future extension. > > * In contrast, if your hypothetical new AccECN codepoint did need to = be deployed later, it would need to include a fall-back to the current = AccECN option when one peer doesn't understand the new codepoint. > > > > > > > > [ms] This is a reasonable point, albeit not a particularly strong = one,=20 > > given that the option is not really required for basic=20 > > interoperability. Also, a hypothetical follow-up standard could=20 > > include a way to explicitly request the option=E2=80=A6 > > > > > > * Fall-back would need to avoid a second round of handshake (given=20= > > this is for low latency), which would only work reliably with an=20 > > option on the SYN (because the 3rd ACK is unreliable) > > > > > > > > [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting = AccECN option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cple= ase send me the better AccECN option B=E2=80=9D after the 3-WHS. It = could be an upgrade, not a fallback. Also, at this point we don=E2=80=99t = know what option B would be and in which context it would be needed. = Maybe other protocol features would require negotiation, too. IMHO it is = a solvable problem. > > > > > > * AccECN has so far avoided using any SYN option space, which is = important given that is the scarcest resource. > > > > > > > > [ms] Yep, but as long as no proposal needs SYN options, this is = nothing that would make one solution better than another. > > > > These days, extending TCP is like playing chess - we have to think = multiple moves ahead! > > > > > > > > [ms] There is one fundamental difference between chess and TCP: In = chess you precisely know the current situation and can predict all = potential moves in advance (albeit there are a lot). However, we don=E2=80= =99t know the future evolution of TCP, ECN and the Internet as a whole, = nor future requirements. If we try to engineer a TCP extension for some = potential future, we may figure out later that reality is different from = what we designed for. As much as I appreciate your attempts to predict = the future, it would be a big surprise to me if you could correctly = predict what TCP will be in 10 years from now. So, instead of trying to = write specifications that take into account future requirements, which = are in fact just unknown, it is more important for me to write = effective, efficient and secure specifications for what is currently = known for sure. > > > > > > > > [ms] I *don=E2=80=99t* know for sure whether the current AccECN = option will be needed, but I see quite some evidence that support of the = AccECN option(s) is not a top priority these days. That is also = something to think about when designing the details. > > > > > > > > I need to learn to articulate onto the list all my reasons for = rejecting certain parts of the design space. Sorry about that. > > > > Yes, I admit, the current proposal is at the cost of burning two TCP = option codepoints. However, you said yourself when you proposed this = approach, that they are not (currently) a scarce resource. Certainly not = as scarce as option space. I just checked: roughly 15% of the option = codepoint allocation space has been used so far. So that's where I would = suggest we compromise first. > > > > [ms] I made a similar calculation some years ago and came to a = similar conclusion. Investing two codepoints for AccECN is something we = can probably afford. But nonetheless we have to reason carefully why it = is really worth the effort. > > > > > > > > > > Regarding the resulting codepoint consumption (two option kinds) and = the addition of a flag byte, this approach would basically end up with = the same result as the current proposal in -13 plus some hypothetical = future addition leveraging the length field beyond the currently known = use. > > > > > > > > And, yes, the length encoding variant may be less flexible and/or = consume some more bits in some cases, but on the plus side it only needs = one codepoint now =E2=80=93 and given that it is entirely unclear = whether any AccECN option will indeed be widely used in future, this is = a big plus. The fact that implementers are quite silent on the option = design is not a good sign. > > > > > > [BB] Here's another possibility then. > > > > a) [K|L| EE1B | ECEB | EE0B ] > > b) [K|L| EE1B | ECEB | EE0B |F] if F =3D 0bXXXXXXX0 > > c) [K|L| EE0B | ECEB | EE1B |F] if F =3D 0bXXXXXXX1 > > > > We'd have to decide which order alternative (a) takes. I've picked = EE1B first only 'cos you're right that there is not currently as much = pressure (on the public Internet) for AccECN with ECT(0). > > > > =3D=3DLegend=3D=3D > > K: Kind (1B) > > L: Length (1B) > > ExxB: Echo xx byte counter > > F: Flags (1B) > > > > Alternatives a) and b) are equivalent, at least while the only = allocated flag is for field order. > > However, alternative b) is available in case other flags are = allocated=20 > > in future The flags byte can only be omitted if (L % 3 =3D=3D 2). > > The flags byte is considered present if (L % 3) =3D=3D 0. > > > > Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be assumed = to include a flags byte, and current implementations ignore the last = byte. > > > > The flags byte is optional to implement (even if the AccECN option = is=20 > > implemented) If the server includes a flags byte on the SYN/ACK but = the client does not include one on the 3rd ACK or the first data packet, = the server assumes the client does not implement the flags byte and uses = only alternative a) for the remainder of the connection. > > > > > > [ms] I am not sure if we need that, but I take this as existence = proof that other encodings are possible. Personally, I think that other = solutions would be doable if you took one bit from one or multiple = counters for format encoding. At least for some of the byte counters I = don=E2=80=99t think taking one bit for other purposes would result in an = Internet congestion collapse=E2=80=A6 But, I have already said that the = -13 proposal works for me, so I=E2=80=99ll not try to come up with = another variant myself. > > > > > > > > To me, one potential difference between two proposals would be = incremental deployment. The proposal in -13 only has an advantage if = middleboxes such as firewalls will indeed pass TCP options with a format = that contains content beyond the (first) Accurate ECN standard (i.e., = currently unused length values). IMHO it is too early to know whether = firewalls would indeed allow this in future. > > > > > > > > =46rom a security perspective, it is not clear to me whether = allowing arbitrary unspecified bytes in a TCP option is a good idea *at = all*. It will be interesting to hear the opinion from SEC area on that. = Personally, I am not convinced that this really makes sense, but I my = concerns are not strong enough to formally push back. I=E2=80=99ll leave = it to others to think about whether this is a bug or a feature. > > > > > > [BB] Well, let's first try to deal with security ourselves: > > * Octets that are explicitly declared as part of an option cannot be = used for a buffer overflow attack. I don't really need to, but I could = add the following text to the forward compatibility wording: > > A receiver considers octets beyond those it uses, but within the = specified length, as if they are padding. > > * And such octets cannot be any different from the current ability = of a sender to add padding. So there's no new attack possible here. > > * And there's no need to specify a max length for any AccECN Option, = which would just unnecessarily limit flexibility. > > > > [ms] I have more thought about the covert channel that some = unspecified bytes in a standards track TCP option could offer=E2=80=A6 = In particular if the AccECN option gets widely deployed and used, would = some malicious users find those bytes useful? For what? For instance, = what in the AccECN protocol design prevents use of these =E2=80=9Cpadding=E2= =80=9D bytes as super-cookie? To me, it is much more important to think = about abuse of whatever we standardize *now*, instead of engineering for = some entirely unknown future. I am not a security expert, but I suggest = a careful analysis of any security implications of the AccECN option. We = seldomly specify new TCP options and malicious users will certainly look = for =E2=80=9Copportunities=E2=80=9D in the spec. So far, I don=E2=80=99t = know whether that whole idea of forward compatibility is a feature or a = bug. > > > > > > > > Michael > > > > > > > > Maybe one lesson learnt is that the document could have a = non-normative appendix that explains the rationale for the finally = picked TCP option encoding. That may also help if there are further = questions whether two codepoints are really required, e.g. by the IESG = (if two codepoints are still the design after WGLC). At least for past = TCP option codepoint allocations I recall some discussions late in the = IETF process. In those past cases, good arguments in an appendix and = running code has helped a lot. > > > > > > [BB] I can do that. Appx B is already similar, giving Design = Rationale for the ACE field. > > > > > > Bob > > > > > > > > > > > > Michael > > > > > > > > > > > > > > > > From: Bob Briscoe > > > Sent: Tuesday, November 17, 2020 6:10 AM > > To: Scharf, Michael >; Yoshifumi=20 > > Nishida > > > Cc: Michael Tuexen >; tcpm-chairs@ietf.org = ;=20 > > Mirja Kuehlewind >; = Scheffenegger, Richard=20 > > >; tcpm IETF list = > > > Subject: Re: AccECN field order > > > > > > > > Michael, > > > > On 16/11/2020 17:36, Scharf, Michael wrote: > > > > Bob, > > > > > > > > One proposal using the length field with *one option codepoint only*=20= > > is detailed in:=20 > > = https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTvpC4BNMo = > > / > > > > > > > > It is the third option mentioned in this e-mail. One example would = be to use option length values 5/8/11 for one encoding type and option = length values 6/9/12 for the other encoding type (i.e., order of = fields). Or one could use some other combination of length values =E2=80=93= the only requirement is that a certain value for the option length is = only used by one of the option formats. In that approach, the value of = the length field would thus directly describe the encoding of the = option. Unless I miss something, this would work and it would just = require one option codepoint. > > > > > > > > Thus, alternatives to two option codepoints exist and I have = explained them on the list in March 2020. > > > > > > OK, sorry, yes, I remember this now. > > > > As I will explain in the AccECN status update talk today in virtual = Bangkok, the draft has made provision for different length values than = 5/8/11. It says existing implementations MUST accept length values other = than those currently defined. But then read in as many whole 3-byte = fields as they can. > > > > This can be used to add a flags byte on the end in future, for = extensibility. Or any other form of extensibility the WG might decide in = the future. > > > > I know a flags byte at the end seems odd compared to at the = beginning. But (if decided it's needed in future) it's reasonably easy = to implement by reading the whole option, then processing the last byte, = before reading the rest of the option. > > > > I believe you will agree that this is a better way to utilize = different lengths. > > > > And thank you for repeatedly emphasizing that you're happy with the = 2-kind scheme, or other alternatives. > > > > > > Bob > > > > > > > > > > > > > > Anyway, I don=E2=80=99t really care how the options are encoded as = long as the receiver doesn=E2=80=99t need per-connection state for = decoding a TCP option. So, personally, I would be fine with using e.g. = the length field as described in my old e-mail. Or an additional flag = byte. And one could come up with further encodings, e.g., by using one = or a few bits as a short =E2=80=9Ctype=E2=80=9D field for each counter. = This is all about protocol engineering. And all these variants have = their pros and cons. > > > > > > > > I am also fine with using two option codepoints as specified in -13; = this is probably the approach that consumes the least number of bits. > > > > > > > > Michael (w/o any hat) > > > > > > > > > > > > > > > > From: Bob Briscoe > > > Sent: Monday, November 16, 2020 5:52 PM > > To: Yoshifumi Nishida > > > Cc: Scharf, Michael >; Michael Tuexen=20 > > >; = tcpm-chairs@ietf.org ; Mirja Kuehlewind=20 > > >; Scheffenegger, = Richard=20 > > >; tcpm IETF list = > > > Subject: AccECN field order > > > > > > > > Yoshi, (adding the tcpm list in cc) > > > > On 05/11/2020 06:58, Yoshifumi Nishida wrote: > > > > Hi Bob, > > > > > > > > On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe > wrote: > > > > Yoshi, > > > > On 04/11/2020 06:51, Yoshifumi Nishida wrote: > > > > Hi, folks, > > > > > > > > > > > > > > In my understanding, I'm not sure if we settled down on using two = option kinds or encoding schemes for 24bits fields in acc ecn draft. > > > > So, I think there're still something to be clarified and hope things = will be settled at the meeting. > > > > > > [BB] I know a WG can change it's mind at any time. But I'd rather we = just clarified what a previous decision was, to avoid the need to keep = re-opening discussion on a question that have been decided then changed = three different ways already. > > > > My memory is not so good these days. I trusted that Michael S = remembered the decision correctly, and I seem to remember that decision = being made. > > I've just checked the minutes of the last interim: > > =20 > > = https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-20200429 = > > 1600/ and they mention Michael's proposal to use two kinds, but = don't=20 > > record any decision. > > The jabber log gives no clues about any decision. > > > > I can't find an audio or video recording. Can you point me at one? > > > > > > > > I thought that it's because there was no clear decision at the = meeting. > > > > But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA = > > > > Please let us know if you have any questions or opinions with regard = to this. > > > > > > [BB] I checked the Youtube link you sent below. > > > > First I think we're agreed no-one was fighting for us to keep the = previous way we did this (using the initial value of the field to set = the order for the connection). > > In my presentation I said there was strong resistance from Michael = to do it a different way. > > (also, offlist, the co-authors including me also didn't like this so=20= > > much. And Ilpo said it made the implementation complex.) > > > > Then came the question of what we do instead. There were three = alternative proposals: > > a) use 2 option kinds > > b) add a flags byte > > c) somehow use the length field maybe > > > > Michael raised (c) in the meeting as a possibility, but no-one could = think how to distinguish two options of the same length but a different = field order using the length field. Michael said he'd post any ideas to = the list if he could think of any, but that didn't happen. > > > > So we're left choosing between (a) and (b). > > I said in the meeting (and on the list when discussing with Ilpo) = that I'd be happy to go with (b), but only if there was another use for = a flag. Because it would consume 1B more options space in many packets, = which is a scarce resource. > > > > Ilpo had a proposed use for another flag (to help synch counters = after a loss), but I think the discussion about it ended that it = wouldn't be helpful, 'cos the way it worked depended on itself (circular = logic). > > > > In conclusion, I don't think there was an explicit decision to go = with 2 option kinds, but it ended up as the 'last person standing'. > > I like it. It's simple. And apparently option kinds are not such a = scarce resource. > > > > Perhaps we can ratify this in the WG tomorrow. > > > > > > Bob > > > > > > > > > > > > > > > > Thanks, > > > > -- > > > > Yoshi > > > > > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ = > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ = > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ = > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_5E5EB7C9-E1C0-4EAC-A9BE-8632165096BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

I support one = option only.

I = understand the issue with the extra byte - it makes all the different = lengths one byte longer, which seems prohibitive.
However, why not simply use a bit out = of the 24-bit counter? You currently use only the 24 LSB anyway; how = much worse would it be to use only 23 bits?

If so, that allows encoding the order = in any of the lengths without needing either an extra byte or two code = points.

FWIW, = the end of Sec 2.2 refers to LSB as =E2=80=9Cbits=E2=80=9D; it seems = like it should be bytes.

Joe

On = Dec 3, 2020, at 11:28 AM, Martin Duke <martin.h.duke@gmail.com> wrote:

As an individual, I support 2 option codes.

On Mon, Nov 23, 2020 at 4:43 AM Scheffenegger, = Richard <Richard.Scheffenegger@netapp.com> wrote:
I = am also in favor of using two distinct option codes.

However,

> Or I guess we could say that only one option should be used for a = connection.

I am opposed to this - with two option codes, a sender should be free to = choose whichever he prevers at any one point; For example, if the sender = a segment (e.g. may be the receiver side)  has to update the EE1 = couter, but also convey SACK information, it would be good to use the = one, where the EE1 field is first, and omit all remaining fields;

Later in the same connection, that very same host may choose to update = the CE field together with some SACK information, and use the other = codepoint in order to preserve as much TCP option space for the SACK = option...


As for extensibility: I would want to avoid that topic, and just = specifiy the three correct supported lengths here, and not mention = (other than ignoring "odd" fractionals of the 3-byte wide counters) what = happens with other lengths...


Richard Scheffenegger

-----Urspr=C3=BCngliche Nachricht-----
Von: Mirja Kuehlewind <ietf@kuehlewind.net>
Gesendet: Montag, 23. November 2020 12:39
An: Neal Cardwell <ncardwell@google.com>; Scharf, = Michael <Michael.Scharf@hs-esslingen.de>; Bob = Briscoe <ietf@bobbriscoe.net>
Cc: Yoshifumi Nishida <nsd.ietf@gmail.com>; tcpm IETF list = <tcpm@ietf.org>; Scheffenegger, Richard <Richard.Scheffenegger@netapp.com>; Michael Tuexen = <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org
Betreff: Re: [tcpm] AccECN field order

NetApp Security WARNING: This is an external email. Do not click links = or open attachments unless you recognize the sender and know the content = is safe.




Hi all,

I think I also support two options as this is the most simple = solution.

We probably need to look at section 3.2.3.2. (Path Traversal of the = AccECN Option) again, as I think this section assumes mostly one option. = Or I guess we could say that only one option should be used for a = connection.

Regarding use of the option length for extensibility. I know new options = are hard to deploy but that=E2=80=99s the extensibility mechanism we = have with TCP. Not sure we want to invent a new now. If we think we need = more extensibility for AccECN for any reason, we should specify valid = option length values that include a flags field now.

Mirja



> On 18. Nov 2020, at 01:03, Neal Cardwell <ncardwell@google.com> wrote:
>
> As someone who contributes to a TCP implementation, I would put in = a  vote for the "Two Option Kinds" proposal outlined in slide 6 = here:
>
> 
> https://datatracker.ietf.org/meeting/109/materials/slides-109-t= cpm-mor
> = e-accurate-ecn-feedback-in-tcp-ecn-adding-explicit-congestion-notifica
> tion-01#page=3D6
>
> This approach has the virtue of simplicity, which hopefully may = help avoid middlebox bugs, speed standardization and development, and = ease the process of maintaining fast and stable implementations.
>
> neal
>
>
> On Tue, Nov 17, 2020 at 9:25 AM Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> Inline some comments [ms].
>
>
>
> Given that I don=E2=80=99t ask for any text chances, I=E2=80=99ll = not follow-up forever in this discussion. I don=E2=80=99t own running = code and a lot of encoding details mainly affect an implementation.
>
>
>
> IMHO the rest of the WG has to think about the option design more = than
> me. So, this is mostly about triggering a discussion=E2=80=A6
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 1:20 PM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
> Nishida <nsd.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, = Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 17/11/2020 08:10, Scharf, Michael wrote:
>
> Bob,
>
>
>
> I am fine with the two option kinds proposed in -13, but I don=E2=80=99= t buy your arguments why this encoding is better than others.
>
>
>
> Most importantly, I don=E2=80=99t think that your =E2=80=9Cforward = compatibility=E2=80=9D argument is a very compelling reason for two = codepoints. All proposals I am aware of have their pros and cons. And I = am not aware of a really comprehensive discussion. At least neither the = e-mail below nor today=E2=80=99s meeting discuss all tradeoffs I would = investigate.
>
>
> [BB] You're right - the discussion below is useful and = necessary.
>
>
>
>
>
> For instance, the benefit of the length encoding variant would be = to consume only one TCP option codepoint now. If we decided later to = that a flag byte is needed (say, at the end), a follow-up proposed = standard could specify another option format with that flag byte, using = a second codepoint.
>
>
> [BB]
> * The new codepoint would require years to deploy (including in = proxies) before it works e2e.
>
>
>
> [ms] That may depend *a lot* on the environment. In environments = where ECN can get deployed today, say in datacenters, rolling out a new = kernel version may perhaps not be the biggest operational challenge. = Also, proxies may not be a significant problem in some of those cases. = Deployment roadmaps are very hard to predict.
>
>
> * Whereas the 'forward compatibility' approach tries to ensure that = AccECN implementations that are being built today will be ready to = interwork with a future extension.
> * In contrast, if your hypothetical new AccECN codepoint did need = to be deployed later, it would need to include a fall-back to the = current AccECN option when one peer doesn't understand the new = codepoint.
>
>
>
> [ms] This is a reasonable point, albeit not a particularly strong = one,
> given that the option is not really required for basic
> interoperability. Also, a hypothetical follow-up standard could
> include a way to explicitly request the option=E2=80=A6
>
>
> * Fall-back would need to avoid a second round of handshake (given =
> this is for low latency), which would only work reliably with an =
> option on the SYN (because the 3rd ACK is unreliable)
>
>
>
> [ms] I can=E2=80=99t follow. If an endpoint is unhappy with getting = AccECN option =E2=80=9CA=E2=80=9D from a peer, I could send a =E2=80=9Cple= ase send me the better AccECN option B=E2=80=9D after the 3-WHS. It = could be an upgrade, not a fallback. Also, at this point we don=E2=80=99t = know what option B would be and in which context it would be needed. = Maybe other protocol features would require negotiation, too. IMHO it is = a solvable problem.
>
>
> * AccECN has so far avoided using any SYN option space, which is = important given that is the scarcest resource.
>
>
>
> [ms] Yep, but as long as no proposal needs SYN options, this is = nothing that would make one solution better than another.
>
> These days, extending TCP is like playing chess - we have to think = multiple moves ahead!
>
>
>
> [ms] There is one fundamental difference between chess and TCP: In = chess you precisely know the current situation and can predict all = potential moves in advance (albeit there are a lot). However, we don=E2=80= =99t know the future evolution of TCP, ECN and the Internet as a whole, = nor future requirements. If we try to engineer a TCP extension for some = potential future, we may figure out later that reality is different from = what we designed for. As much as I appreciate your attempts to predict = the future, it would be a big surprise to me if you could correctly = predict what TCP will be in 10 years from now. So, instead of trying to = write specifications that take into account future requirements, which = are in fact just unknown, it is more important for me to write = effective, efficient and secure specifications for what is currently = known for sure.
>
>
>
> [ms] I *don=E2=80=99t* know for sure whether the current AccECN = option will be needed, but I see quite some evidence that support of the = AccECN option(s) is not a top priority these days. That is also = something to think about when designing the details.
>
>
>
> I need to learn to articulate onto the list all my reasons for = rejecting certain parts of the design space. Sorry about that.
>
> Yes, I admit, the current proposal is at the cost of burning two = TCP option codepoints. However, you said yourself when you proposed this = approach, that they are not (currently) a scarce resource. Certainly not = as scarce as option space. I just checked: roughly 15% of the option = codepoint allocation space has been used so far. So that's where I would = suggest we compromise first.
>
> [ms] I made a similar calculation some years ago and came to a = similar conclusion. Investing two codepoints for AccECN is something we = can probably afford. But nonetheless we have to reason carefully why it = is really worth the effort.
>
>
>
>
> Regarding the resulting codepoint consumption (two option kinds) = and the addition of a flag byte, this approach would basically end up = with the same result as the current proposal in -13 plus some = hypothetical future addition leveraging the length field beyond the = currently known use.
>
>
>
> And, yes, the length encoding variant may be less flexible and/or = consume some more bits in some cases, but on the plus side it only needs = one codepoint now =E2=80=93 and given that it is entirely unclear = whether any AccECN option will indeed be widely used in future, this is = a big plus. The fact that implementers are quite silent on the option = design is not a good sign.
>
>
> [BB] Here's another possibility then.
>
> a) [K|L| EE1B | ECEB | EE0B ]
> b) [K|L| EE1B | ECEB | EE0B |F]    if F =3D 0bXXXXXXX0
> c) [K|L| EE0B | ECEB | EE1B |F]    if F =3D 0bXXXXXXX1
>
> We'd have to decide which order alternative (a) takes. I've picked = EE1B first only 'cos you're right that there is not currently as much = pressure (on the public Internet) for AccECN with ECT(0).
>
> =3D=3DLegend=3D=3D
> K:    Kind (1B)
> L:    Length (1B)
> ExxB: Echo xx byte counter
> F:    Flags (1B)
>
> Alternatives a) and b) are equivalent, at least while the only = allocated flag is for field order.
> However, alternative b) is available in case other flags are = allocated
> in future The flags byte can only be omitted if (L % 3 =3D=3D = 2).
> The flags byte is considered present if (L % 3) =3D=3D 0.
>
> Forward compatibility: Options with (L % 3 =3D=3D 1) MUST be = assumed to include a flags byte, and current implementations ignore the = last byte.
>
> The flags byte is optional to implement (even if the AccECN option = is
> implemented) If the server includes a flags byte on the SYN/ACK but = the client does not include one on the 3rd ACK or the first data packet, = the server assumes the client does not implement the flags byte and uses = only alternative a) for the remainder of the connection.
>
>
> [ms] I am not sure if we need that, but I take this as existence = proof that other encodings are possible. Personally, I think that other = solutions would be doable if you took one bit from one or multiple = counters for format encoding. At least for some of the byte counters I = don=E2=80=99t think taking one bit for other purposes would result in an = Internet congestion collapse=E2=80=A6 But, I have already said that the = -13 proposal works for me, so I=E2=80=99ll not try to come up with = another variant myself.
>
>
>
> To me, one potential difference between two proposals would be = incremental deployment. The proposal in -13 only has an advantage if = middleboxes such as firewalls will indeed pass TCP options with a format = that contains content beyond the (first) Accurate ECN standard (i.e., = currently unused length values). IMHO it is too early to know whether = firewalls would indeed allow this in future.
>
>
>
> =46rom a security perspective, it is not clear to me whether = allowing arbitrary unspecified bytes in a TCP option is a good idea *at = all*. It will be interesting to hear the opinion from SEC area on that. = Personally, I am not convinced that this really makes sense, but I my = concerns are not strong enough to formally push back. I=E2=80=99ll leave = it to others to think about whether this is a bug or a feature.
>
>
> [BB] Well, let's first try to deal with security ourselves:
> * Octets that are explicitly declared as part of an option cannot = be used for a buffer overflow attack. I don't really need to, but I = could add the following text to the forward compatibility wording:
>     A receiver considers octets beyond those it = uses, but within the specified length, as if they are padding.
> * And such octets cannot be any different from the current ability = of a sender to add padding. So there's no new attack possible here.
> * And there's no need to specify a max length for any AccECN = Option, which would just unnecessarily limit flexibility.
>
> [ms] I have more thought about the covert channel that some = unspecified bytes in a standards track TCP option could offer=E2=80=A6 = In particular if the AccECN option gets widely deployed and used, would = some malicious users find those bytes useful? For what? For instance, = what in the AccECN protocol design prevents use of these =E2=80=9Cpadding=E2= =80=9D bytes as super-cookie? To me, it is much more important to think = about abuse of whatever we standardize *now*, instead of engineering for = some entirely unknown future. I am not a security expert, but I suggest = a careful analysis of any security implications of the AccECN option. We = seldomly specify new TCP options and malicious users will certainly look = for =E2=80=9Copportunities=E2=80=9D in the spec. So far, I don=E2=80=99t = know whether that whole idea of forward compatibility is a feature or a = bug.
>
>
>
> Michael
>
>
>
> Maybe one lesson learnt is that the document could have a = non-normative appendix that explains the rationale for the finally = picked TCP option encoding. That may also help if there are further = questions whether two codepoints are really required, e.g. by the IESG = (if two codepoints are still the design after WGLC). At least for past = TCP option codepoint allocations I recall some discussions late in the = IETF process. In those past cases, good arguments in an appendix and = running code has helped a lot.
>
>
> [BB] I can do that. Appx B is already similar, giving Design = Rationale for the ACE field.
>
>
> Bob
>
>
>
>
>
> Michael
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Tuesday, November 17, 2020 6:10 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Yoshifumi
> Nishida <nsd.ietf@gmail.com>
> Cc: Michael Tuexen <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org;
> Mirja Kuehlewind <ietf@kuehlewind.net>; Scheffenegger, = Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: Re: AccECN field order
>
>
>
> Michael,
>
> On 16/11/2020 17:36, Scharf, Michael wrote:
>
> Bob,
>
>
>
> One proposal using the length field with *one option codepoint = only*
> is detailed in:
> https://mailarchive.ietf.org/arch/msg/tcpm/zo-1OR0nRfhHocX8yvTv= pC4BNMo
> /
>
>
>
> It is the third option mentioned in this e-mail. One example would = be to use option length values 5/8/11 for one encoding type and option = length values 6/9/12 for the other encoding type (i.e., order of = fields). Or one could use some other combination of length values =E2=80=93= the only requirement is that a certain value for the option length is = only used by one of the option formats. In that approach, the value of = the length field would thus directly describe the encoding of the = option. Unless I miss something, this would work and it would just = require one option codepoint.
>
>
>
> Thus, alternatives to two option codepoints exist and I have = explained them on the list in March 2020.
>
>
> OK, sorry, yes, I remember this now.
>
> As I will explain in the AccECN status update talk today in virtual = Bangkok, the draft has made provision for different length values than = 5/8/11. It says existing implementations MUST accept length values other = than those currently defined. But then read in as many whole 3-byte = fields as they can.
>
> This can be used to add a flags byte on the end in future, for = extensibility. Or any other form of extensibility the WG might decide in = the future.
>
> I know a flags byte at the end seems odd compared to at the = beginning. But (if decided it's needed in future) it's reasonably easy = to implement by reading the whole option, then processing the last byte, = before reading the rest of the option.
>
> I believe you will agree that this is a better way to utilize = different lengths.
>
> And thank you for repeatedly emphasizing that you're happy with the = 2-kind scheme, or other alternatives.
>
>
> Bob
>
>
>
>
>
>
> Anyway, I don=E2=80=99t really care how the options are encoded as = long as the receiver doesn=E2=80=99t need per-connection state for = decoding a TCP option. So, personally, I would be fine with using e.g. = the length field as described in my old e-mail. Or an additional flag = byte. And one could come up with further encodings, e.g., by using one = or a few bits as a short =E2=80=9Ctype=E2=80=9D field for each counter. = This is all about protocol engineering. And all these variants have = their pros and cons.
>
>
>
> I am also fine with using two option codepoints as specified in = -13; this is probably the approach that consumes the least number of = bits.
>
>
>
> Michael (w/o any hat)
>
>
>
>
>
>
>
> From: Bob Briscoe <ietf@bobbriscoe.net>
> Sent: Monday, November 16, 2020 5:52 PM
> To: Yoshifumi Nishida <nsd.ietf@gmail.com>
> Cc: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; Michael Tuexen
> <tuexen@fh-muenster.de>; tcpm-chairs@ietf.org; Mirja Kuehlewind
> <ietf@kuehlewind.net>; Scheffenegger, Richard
> <Richard.Scheffenegger@netapp.com>; = tcpm IETF list <tcpm@ietf.org>
> Subject: AccECN field order
>
>
>
> Yoshi, (adding the tcpm list in cc)
>
> On 05/11/2020 06:58, Yoshifumi Nishida wrote:
>
> Hi Bob,
>
>
>
> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> Yoshi,
>
> On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>
> Hi, folks,
>
>
>
>
>
>
> In my understanding, I'm not sure if we settled down on using two = option kinds or encoding schemes for 24bits fields in acc ecn draft.
>
> So, I think there're still something to be clarified and hope = things will be settled at the meeting.
>
>
> [BB] I know a WG can change it's mind at any time. But I'd rather = we just clarified what a previous decision was, to avoid the need to = keep re-opening discussion on a question that have been decided then = changed three different ways already.
>
> My memory is not so good these days. I trusted that Michael S = remembered the decision correctly, and I seem to remember that decision = being made.
> I've just checked the minutes of the last interim:
>     
> https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-2= 0200429
> 1600/ and they mention Michael's proposal to use two kinds, but = don't
> record any decision.
> The jabber log gives no clues about any decision.
>
> I can't find an audio or video recording. Can you point me at = one?
>
>
>
> I thought that it's because there was no clear decision at the = meeting.
>
> But, you can check https://www.youtube.com/watch?v=3DKsB0_Nb8-kA
>
> Please let us know if you have any questions or opinions with = regard to this.
>
>
> [BB] I checked the Youtube link you sent below.
>
> First I think we're agreed no-one was fighting for us to keep the = previous way we did this (using the initial value of the field to set = the order for the connection).
> In my presentation I said there was strong resistance from Michael = to do it a different way.
> (also, offlist, the co-authors including me also didn't like this = so
> much. And Ilpo said it made the implementation complex.)
>
> Then came the question of what we do instead. There were three = alternative proposals:
> a) use 2 option kinds
> b) add a flags byte
> c) somehow use the length field maybe
>
> Michael raised (c) in the meeting as a possibility, but no-one = could think how to distinguish two options of the same length but a = different field order using the length field. Michael said he'd post any = ideas to the list if he could think of any, but that didn't happen.
>
> So we're left choosing between (a) and (b).
> I said in the meeting (and on the list when discussing with Ilpo) = that I'd be happy to go with (b), but only if there was another use for = a flag. Because it would consume 1B more options space in many packets, = which is a scarce resource.
>
> Ilpo had a proposed use for another flag (to help synch counters = after a loss), but I think the discussion about it ended that it = wouldn't be helpful, 'cos the way it worked depended on itself (circular = logic).
>
> In conclusion, I don't think there was an explicit decision to go = with 2 option kinds, but it ended up as the 'last person standing'.
> I like it. It's simple. And apparently option kinds are not such a = scarce resource.
>
> Perhaps we can ratify this in the WG tomorrow.
>
>
> Bob
>
>
>
>
>
>
>
> Thanks,
>
> --
>
> Yoshi
>
>
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
>
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
>
>
>
> --
> ________________________________________________________________
> Bob Briscoe                =                http://bobbriscoe.net/
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_5E5EB7C9-E1C0-4EAC-A9BE-8632165096BA-- From nobody Thu Dec 3 12:07:17 2020 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 78F673A0CD3 for ; Thu, 3 Dec 2020 12:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 PsdIW0lI4AVF for ; Thu, 3 Dec 2020 12:07:07 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 DA9733A0D02 for ; Thu, 3 Dec 2020 12:06:56 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id f23so5381326ejk.2 for ; Thu, 03 Dec 2020 12:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=xJhti7Zb9pYkM2bf/S93YLdLpdrbFu6Lc0dPGMNtw+iJkJnlsp/3Jp7LNT8Xnh3B4I 0ZB5jl26Fm6G6vO+AMe1n35sYtWyfwSovChi0RH87zdwKWRDLP8dR8/wkTBgWfE06awX 5Qjj9LBifqwJkIOWCYxzrAk5c3eJcdrjc7mybgRULWftWmDKNix8dN9+R5mi/Q4Hc2aJ eZphh1PQnWIWtqo7K2Ie0VZNqn8j2oFlL8+duOq4GsX0QsrYfIE1TdltxUQuldKkcukz z0r3vXhxsxdIUAPTXEIJZfaco2o7u5kEklzGXTB4DBMJmiVKCfOBRVfchlKi+KY/4VVx 4XTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=bGp40ujxFtT+/0ak6NnmG3XTLuBgNDlTjHdJjMR795wi9iorup9JbMD82uOKJsdGxP AsEj4RZMdrnt5/GQ9j9YlA0V8DkhGWa6NiJ8JwaS5kHURQHQr3OAR/LTVwuUEfcfTohq z9+gQ1iZzTrnXNLuIRaTr4shF4JaezeFv4y4yKV1xO8zZOx4R0VUxF0qcY0NZoElWBmA t0iS83ZmdEn4vIRJeMs11GHIGk6qtwBu/5y+G3WhNOapFPMCKRFuHMY8vSsbB82iIfoQ pB56vpzu6WkUJr7yCF9u85xBELc0Ji0kItXfnJ5IrC6XcWRDTdf3wJsZKGqzXm11I7Jm Exqg== X-Gm-Message-State: AOAM530KWTxSSGx2a9e78mq1gZmPN6Bzdn/rDG7MlLT/BvmL8NljsfML dwmLFhFzThUzP9EoG7bplcyMgUQ2no0x44FlOxqzvQ== X-Google-Smtp-Source: ABdhPJwYz/layhzIvh4CvZ7th7UFO/Yc/NNmwyyO68M5/RIcjwHogbYbdKamvckXC7IgCwS3hbXkxux+i5UYhUbIFx8= X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr4181798ejc.295.1607026014894; Thu, 03 Dec 2020 12:06:54 -0800 (PST) MIME-Version: 1.0 References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> In-Reply-To: <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> From: Tom Herbert Date: Thu, 3 Dec 2020 13:06:43 -0700 Message-ID: To: Fernando Gont Cc: Erik Kline , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 20:07:16 -0000 On Thu, Dec 3, 2020 at 12:42 PM Fernando Gont wrote: > > On 3/12/20 14:30, Tom Herbert wrote: > [....] > > > > There are two apropos statements in RFC6437: > > > > "There is no way to verify whether a flow label has been modified en > > route or whether it belongs to a uniform distribution. Therefore, no > > Internet-wide mechanism can depend mathematically on unmodified and > > uniformly distributed flow labels; they have a "best effort" quality." > > > > "From an upper-layer viewpoint, a flow could consist of all packets in > > one direction of a specific transport connection or media stream. > > However, a flow is not necessarily 1:1 mapped to a transport > > connection." > > > > So building a load balancer, or any other intermediate network device, > > that *depends* on the flow label to be consistent for the life of a > > transport connection and 1:1 mapped to a transport connection is > > contrary to this guidance. > > We don't need 1:1. We just need 1:N where N is how flows would be > aggregated/grouped for the purpose of load-sharing. > > > > > The ship has already sailed on this in > > deployment, and even if the protocol requirements were to be > > sufficiently tightened that would take years to reach full effect and > > that would preclude other use cases where modifying the flow label is > > useful. If a stable 1:1 mapped identifier for transport ports is > > needed in the network layer, it might make sense to create a new HBH > > option for that. > > The above said, I would probably agree that if havinga non-stable FL > breaks something, whatever it breaks is probably already broken, since Fernando, Not to belabor the point, but stable flow labels were never guaranteed, so if some node has a problem with non-stable flow labels then they are themselves broken because they are making an incorrect assumption. > there's not even a checksum to try to detect whether the IPv6 header has > been corrupted. > Neither is there checksum that covers the UDP port numbers when UDP checksum is zero. A "stable" identifier that the network can use to conclusively identify transport flows does not generally exist. > > > > Personally, if I were building a load balancer I'd > > use neither the flow label nor transport ports for entropy, I'd look > > at using the destination address since 128 bits allows plenty of bits > > of entropy, it's consistent per transport flow and always set in an > Problem is that if you have two systems that need a lot of banswitdth > (e.g., they are transferring file via several TCP connections)< you > wouldn't be able to load-share them -- since the result of the hash > would be the sme for all TCP connections.... > Use a different IP address per connection. This idea has already been brought up in the context of security since it could make it harder for malicious network observers to correlate different flows as having the same source, and the same principle could be applied to load balancers where each of the backends is assigned a block of IP addresses (like a /64). After that, it's a matter of getting clients to use some random address from the load balancer blocks (instead of always using one). IIRC, Brian Carpenter once suggested that we really didn't need port numbers any more since they could be part of the address-- for load balancers there might be some merit to that. Tom > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Dec 3 12:18:05 2020 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 81E4E3A0C5E; Thu, 3 Dec 2020 12:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 rEsAJ2NhXSdG; Thu, 3 Dec 2020 12:17:58 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 CF1823A0C64; Thu, 3 Dec 2020 12:17:57 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id w187so2066642pfd.5; Thu, 03 Dec 2020 12:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kEDGKP4sfCroZwuQ1m6T+B62pz/0WYqGJkbq/af38D0=; b=BM0srVnAxB6OzD5rI1HvPKyqbaKO7YVJvj/MlIq36GHUhdhh9Eg3mU23RIF5i32CBH Pd4a9Grla+Ko28SbsbqAyTZi4awDOSP0P9VJRceIrGcLeTwPrDFQ7cDbDxGdCNmPgSFr IWL+tmDatE6XnDoqV3U6ciloJW6VdF7yFV86twdR4cFZ71EyfLb4/3uoXjRi2zRFfo9s FWZtFFLGIV1iuih1DTBMHXZBtSZG7isClRIER9iGRJHzsmrmOQDPdT0xPXeSisynHcWI tqfVGTiN0PH1zWMyH2TcRYi7iY6ENerTmoY1kpcZ3EWw3UfJ2BsCdlYu9uhjUktXb4HZ iSIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kEDGKP4sfCroZwuQ1m6T+B62pz/0WYqGJkbq/af38D0=; b=FNS0mcY5lTa0CL31+pzwv11Y/24t/kXBaitLxufNP3lQDZg7UNc5ipV4GC7xfC4xNI oupBGp5CKvhVLHdYNa60c1TuOwn7fTxp1kJA5Fq+6HIOVR63/iXH6Yh1lwHFMc/vNueW 8tvJiCYvVUWVZqWgGgkLyQYfYkn8f8ge7e8ehA2aryqvr28scp0e3A9VPpfIB5/DkniR yU+rG2dCyUNEO+zkukv0biX0rWTTflxo6KtU2sBhELUVl8UpjldaPZC0/z6uvUbeCHYa jazCnL/L+ClK4KbWUWvhFdNQBqyfoaVDP4rgHq4sQ3AGrLIbc0/CdcFwDW8oY9Y9W5kE SJbg== X-Gm-Message-State: AOAM533JwTgoz1Utuhr5ZSkMTONXPEBLRw/W/e8nU/4sKX+r6iBR4ch2 wd9RZ0CF/wy+FtYz5gdoaZ0= X-Google-Smtp-Source: ABdhPJyT7qAWiTzVh7vy6L7onRvcGwGPiQC1thZmWfkJ43/b9jp6HKwf4pS4WEGtXpp0RipntecwHQ== X-Received: by 2002:a63:d90a:: with SMTP id r10mr4506831pgg.336.1607026677263; Thu, 03 Dec 2020 12:17:57 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id a16sm2647308pfl.125.2020.12.03.12.17.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 12:17:56 -0800 (PST) To: Tom Herbert , Erik Kline Cc: Fernando Gont , IPv6 Operations , tcpm , Fernando Gont References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Brian E Carpenter Message-ID: <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> Date: Fri, 4 Dec 2020 09:17:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 20:18:04 -0000 On 04-Dec-20 06:30, Tom Herbert wrote: > On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: >> >>>> Please include requirements for both hosts and network nodes. If there >>>> is going to the be a requirement that hosts MUST make a 1:1 mapping to >>>> a transport connection and the flow label MUST be consistent for the >>>> life of connection, then I would expect there to also be a requirement >>>> that the flow label MUST be immutable by all devices in the path-- in >>>> particular the requirement of RFC6437 would need to be updated: "A >>>> forwarding node MUST either leave a non-zero flow label value >>>> unchanged or change it only for compelling operational security >>>> reasons..."-- if hosts are not allowed to change a field they are >>>> primarily responsible for setting, then the network should not be >>>> allowed to modify it either. >>> >>> I don't recall _(of the top of my head) why we ended up making the field >>> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it >>> had to do with allowing middle-boxes to mitigate FL-based covert >>> channels. If that's the case (Brian CC'ed) then, in retrospective, that >>> seems to have been a bad idea. -- I was part of the discussion, so I >>> take my share of blame. :-) >> >> My understanding/recollection is that since there were never any >> restrictions on modification of the flow label from the very beginning >> it wasn't super meaningful to try to close the barn door after all >> these years. > > Erik, > > There are two apropos statements in RFC6437: > > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on unmodified and > uniformly distributed flow labels; they have a "best effort" quality." Yes, a MUST NOT is futile because it cannot be enforced. Also, the firewall folk seemed very insistent that they would change the flow label (or zero it) because paranoia. So specifying that if they changed it, they should do it consistently, seemed better than a MUST NOT which they would definitely ignore. > "From an upper-layer viewpoint, a flow could consist of all packets in > one direction of a specific transport connection or media stream. > However, a flow is not necessarily 1:1 mapped to a transport > connection." > > So building a load balancer, or any other intermediate network device, > that *depends* on the flow label to be consistent for the life of a > transport connection and 1:1 mapped to a transport connection is > contrary to this guidance. The ship has already sailed on this in > deployment, and even if the protocol requirements were to be > sufficiently tightened that would take years to reach full effect and > that would preclude other use cases where modifying the flow label is > useful. If a stable 1:1 mapped identifier for transport ports is > needed in the network layer, it might make sense to create a new HBH > option for that. Personally, if I were building a load balancer I'd > use neither the flow label nor transport ports for entropy, I'd look > at using the destination address since 128 bits allows plenty of bits > of entropy, it's consistent per transport flow and always set in an > IPv6 packet. But that doesn't help with server load balancing. For ECMP/LAG in a transit network, the DA alone doesn't help either, if a particular destination is prone to very heavy flows for some reason. And of course the ports don't help if they're encrypted. There's no simple answer here. Brian From nobody Thu Dec 3 12:39:07 2020 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 CE6CC3A0C81 for ; Thu, 3 Dec 2020 12:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 bm5rmnUaUz8O for ; Thu, 3 Dec 2020 12:38:56 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 91CC83A0C54 for ; Thu, 3 Dec 2020 12:38:52 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id jx16so5433465ejb.10 for ; Thu, 03 Dec 2020 12:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NIrav4tdAcakDCg0n7gnAvqr1Mn5aNrsxiqiFjmNwOU=; b=Eldg9cCt3VsCZru0t/MYk6TnPGRoZ0z9YbeRjy+CxTrIV1HR1Cla/V4roks76YPScc cdUuEx3cS/LvcKftzwEG6xXLrUhZAPCVteNlHMgLtC2ZEK4muNLxO6FVkqGRWkzvVMyS 1GKH8wGFvRUbgZnZFZX58Y/PsUjvfyjwnmunF1u0pjPE50cnRWQ0EE1GwqXOgtJUaT46 4MsR7Hv6NXy5f+eUT2wn4NbO5iWZcAYb3VsPuBG3MIftTFr9KRTpdrrrM6ILGLVoJ9ow StxAGPGBYvolI5FeERFXYVZX3TN9Z11pawKEm2b1OZCTC4uzRz5udT3f8+u8WBhLYzFY MUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NIrav4tdAcakDCg0n7gnAvqr1Mn5aNrsxiqiFjmNwOU=; b=r3ovONGIncdWIaoXF+osgLhoA4ao9W/JMOuwANMHfSSajRLbF7Fi5zWAdy7PIdxd3P T905GH4GrUV4/Y0b0tfQ2sY7H5dLR6meMML/pEAJ3S6g0LEmMNvPJVdD4azHe96cp9Bj g2BVmt+Brjd1FwIEWoLbM5fEmWyOXJB96icEfhd01oD8mL1elmlg85MaGQjN2Fcb2LR6 MrN+1RUDaNx/1peGapxMWsDkqtepkxpM1h0vjHMPAu49s2rP+nb6mGDWZ+05l53Fz3nW L3pHznqvEBOeph+lWSv8r3s61CoQw3kMUOjzf0ZQe083/TAZoIaWtsrYw7hElVNBZ5oo eTrw== X-Gm-Message-State: AOAM531N0C1Dt4B6pmcy3zwVqqaTnwDecf0T9t2NyXvQ4+0NOS0q1FIp bHgtDWgOH9709AI3fQuKXkZ0sWwD8jbBoy4ka6GqlQ== X-Google-Smtp-Source: ABdhPJzZzjuN8kyMl/2KzkfB5VN9VLQdYIkL7Ss22z65BHIUJXYdebynZmKFfPdsHOskTBjN54JrM0Dd+JC55vvg1Ow= X-Received: by 2002:a17:906:3294:: with SMTP id 20mr4211114ejw.239.1607027930742; Thu, 03 Dec 2020 12:38:50 -0800 (PST) MIME-Version: 1.0 References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> In-Reply-To: <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> From: Tom Herbert Date: Thu, 3 Dec 2020 13:38:39 -0700 Message-ID: To: Brian E Carpenter Cc: Erik Kline , Fernando Gont , IPv6 Operations , tcpm , Fernando Gont Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 20:39:05 -0000 On Thu, Dec 3, 2020 at 1:17 PM Brian E Carpenter wrote: > > On 04-Dec-20 06:30, Tom Herbert wrote: > > On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: > >> > >>>> Please include requirements for both hosts and network nodes. If there > >>>> is going to the be a requirement that hosts MUST make a 1:1 mapping to > >>>> a transport connection and the flow label MUST be consistent for the > >>>> life of connection, then I would expect there to also be a requirement > >>>> that the flow label MUST be immutable by all devices in the path-- in > >>>> particular the requirement of RFC6437 would need to be updated: "A > >>>> forwarding node MUST either leave a non-zero flow label value > >>>> unchanged or change it only for compelling operational security > >>>> reasons..."-- if hosts are not allowed to change a field they are > >>>> primarily responsible for setting, then the network should not be > >>>> allowed to modify it either. > >>> > >>> I don't recall _(of the top of my head) why we ended up making the field > >>> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > >>> had to do with allowing middle-boxes to mitigate FL-based covert > >>> channels. If that's the case (Brian CC'ed) then, in retrospective, that > >>> seems to have been a bad idea. -- I was part of the discussion, so I > >>> take my share of blame. :-) > >> > >> My understanding/recollection is that since there were never any > >> restrictions on modification of the flow label from the very beginning > >> it wasn't super meaningful to try to close the barn door after all > >> these years. > > > > Erik, > > > > There are two apropos statements in RFC6437: > > > > "There is no way to verify whether a flow label has been modified en > > route or whether it belongs to a uniform distribution. Therefore, no > > Internet-wide mechanism can depend mathematically on unmodified and > > uniformly distributed flow labels; they have a "best effort" quality." > > Yes, a MUST NOT is futile because it cannot be enforced. > > Also, the firewall folk seemed very insistent that they would change > the flow label (or zero it) because paranoia. So specifying that if they > changed it, they should do it consistently, seemed better than a MUST NOT > which they would definitely ignore. > > > "From an upper-layer viewpoint, a flow could consist of all packets in > > one direction of a specific transport connection or media stream. > > However, a flow is not necessarily 1:1 mapped to a transport > > connection." > > > > So building a load balancer, or any other intermediate network device, > > that *depends* on the flow label to be consistent for the life of a > > transport connection and 1:1 mapped to a transport connection is > > contrary to this guidance. The ship has already sailed on this in > > deployment, and even if the protocol requirements were to be > > sufficiently tightened that would take years to reach full effect and > > that would preclude other use cases where modifying the flow label is > > useful. If a stable 1:1 mapped identifier for transport ports is > > needed in the network layer, it might make sense to create a new HBH > > option for that. Personally, if I were building a load balancer I'd > > use neither the flow label nor transport ports for entropy, I'd look > > at using the destination address since 128 bits allows plenty of bits > > of entropy, it's consistent per transport flow and always set in an > > IPv6 packet. > > But that doesn't help with server load balancing. For ECMP/LAG in a > transit network, the DA alone doesn't help either, if a particular > destination is prone to very heavy flows for some reason. Brian, Specifically, that is a problem for a host that uses a _single_ IPv6 address for all its connections. What I am suggesting is to give hosts many addresses, which we already do anyway like when mobile devices and data center servers are assigned /64s. If a host then randomly chooses an address from that block for each connection it creates thenl the address 2-tuple contains all the entropy needed for purposes of load balancing, ECMP, etc. is contained in the source address. Addresses are guaranteed to be present and plaintext in each packet so no DPI required, they're as stable as any flow identifying information in a packet can be and they offer much more entropy than sixteen bits of port number of twenty bit flow label. Since the block address assignments or already happening, this seems more to be a host implementation matter where we perform address selection for a new connection by random selection in the block. It's on my wish list of things to implement :-) Tom > And of course > the ports don't help if they're encrypted. > > There's no simple answer here. > > Brian From nobody Fri Dec 4 05:02:17 2020 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 5BDAD3A0C6D; Fri, 4 Dec 2020 05:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 fibwtf3_iHlf; Fri, 4 Dec 2020 05:02:09 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FDF3A0C63; Fri, 4 Dec 2020 05:01:59 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 04 Dec 2020 15:01:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=vQl8WvUAQA3xdDVwk WnpL92FIeZDusv6GdyUVAa0H3w=; b=hUOXhh/kD6HJVwalWr4L2bwAJPd46c/xL tjKZpOXjLEpuwHGqfPLTMBK5gMHKY82CMBITlGc0cwok/eQJMO7FSi9MqPf8xrjL 15EBJATf4Sk3C5Qw8T5+QwzwBiX6ELfizK2cLbIrydCng1bR7q0SXEqOgmB89M+c nR0/LR4gI8= Received: from hp8x-60 (85-76-105-68-nat.elisa-mobile.fi [85.76.105.68]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Fri, 04 Dec 2020 15:01:50 +0200 id 00000000005A1C6A.000000005FCA333E.000043A3 Date: Fri, 4 Dec 2020 15:01:50 +0200 (EET) From: Markku Kojo To: last-call@ietf.org cc: IETF-Announce , tcpm@ietf.org, draft-ietf-tcpm-rack@ietf.org, tuexen@fh-muenster.de, draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs@ietf.org In-Reply-To: <160557473030.20071.3820294165818082636@ietfa.amsl.com> Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Last Call: (The RACK-TLPloss detection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 13:02:13 -0000 Hi all, I know this is a bit late but I didn't have time earlier to take look at this draft. Given that this RFC to be is standards track and RECOMMENDED to replace current DupAck-based loss detection, it is important that the spec is clear on its advice to those implementing it. Current text seems to lack important advice w.r.t congestion control, and even though the spec tries to decouple loss detection from congestion control and does not intend to modify existing standard congestion control some of the examples advice incorrect congestion control actions. Therefore, I think it is worth to correct the mistakes and take yet another look at a few implications of this specification. Sec. 3.4 (and elsewhere when discussing recovering a dropped retransmission): It is very useful that RACK-TLP allows for recovering dropped rexmits. However, it seems that the spec ignores the fact that loss of a retransmission is a loss in a successive window that requires reacting to congestion twice as per RFC 5681. This advice must be included in the specification because with RACK-TLP recovery of dropped rexmit takes place during the fast recovery which is very different from the other standard algorithms and therefore easy to miss when implementing this spec. Sec 9.3: In Section 9.3 it is stated that the only modification to the existing congestion control algorithms is that one outstanding loss probe can be sent even if the congestion window is fully used. This is fine, but the spec lacks the advice that if a new data segment is sent this extra segment MUST NOT be included when calculating the new value of ssthresh as per the equation (4) of RFC 5681. Such segment is an extra segment not allowed by cwnd, so it must be excluded from FlightSize, if the TLP probe detects loss or if there is no ack and RTO is needed to trigger loss recovery. In these cases the temporary over-commit is not accounted for as DupAck does not decrease FlightSize and in case of an RTO the next ACK comes too late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits including the segments transmitted via Limitid Transmit in the calculation of ssthresh. In Section 9.3 a few example scenarios are used to illustriate the intended operation of RACK-TLP. In the first example a sender has a congestion window (cwnd) of 20 segments on a SACK-enabled connection. It sends 10 data segments and all of them are lost. The text claims that without RACK-TLP the ending cwnd would be 4 segments due to congestion window validation. This is incorrect. As per RFC 7661 the sender MUST exit the non-validated phase upon an RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if the TCP sender uses the equation (4) of RFC 5681). The operation with RACK-TLP would inevitably result in congestion collapse if RACK-TLP behaves as described in the example because it restores the previous cwnd of 10 segments after the fast recovery and would not react to congestion at all! I think this is not the intended behavior by this spec but a mistake in the example. The ssthresh calculated in the beginning of loss recovery should be 5 segments as per RFC 6675 (and RFC 5681). Furthermore, it seems that this example with RACK-TLP refers to using PRR_SSRB which effectively implements regular slow start in this case(?). From congestion control point of view this is correct because the entire flight of data as well as ack clock was lost. However, as correctly discussed in Sec 2, congestion window must be reset to 1 MSS when an entire flight of data is and Ack clock is lost. But how can an implementor know what to do if she/he is not implementing the experimental PRR algrorithm? This spec articulates specifying an alternative for DupAck counting, indicating that TLP is used to trigger Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. This means that without an additional advise an implementation of this spec would just halve the cwnd and ssthresh and send a potentially very large burst of segments in the beginning of the Fast Recovery because there is no ack clock. So, this spec begs for an advise (MUST) when to slow start and reset cwnd and when not, or at least a discussion of this problem and some sort of advise what to do and what to avoid. And, maybe a recommendation to implement it with PRR? Another question relates to the use of TLP and adjusting timer(s) upon timeout. In the same example discussed above, it is clear that PTO that fires TLP is just a more aggressive retransmit timer with an alternative data segment to (re)transmit. Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in effect a retransmission timout and the timer(s) must be backed-off. This is not adviced in this specification. Whether it is the TCP RTO or PTO that should be backed-off is an open question. Otherwise, if the congestion is persistent and further transmission are also lost, RACK-TLP would not react to congestion properly but would keep retransmitting with "constant" timer value because new RTT estimate cannot be obtained. On a buffer bloated and heavily congested bottleneck this would easily result in sending at least one unnecessary retransmission per one delivered segment which is not advisable (e.g., when there are a huge number of applications sharing a constrained bottleneck and these applications are sending only one (or a few) segments and then waiting for an reply from the peer before sending another request). Additional notes: Sec 2.2: Example 2: "Lost retransmissions cause a resort to RTO recovery, since DUPACK-counting does not detect the loss of the retransmissions. Then the slow start after RTO recovery could cause burst losses again that severely degrades performance [POLICER16]." RTO reovery is done in slow start. The last sentence is confusing as there is no (new) slow-start after RTO recovery (or more precisely slow start continues until cwnd > ssthresh). Do you mean: if/when slow start still continues after RTO Recovery has repaired lost segments, it may cause burst losses again? Example 3: "If the reordering degree is beyond DupThresh, the DUPACK- counting can cause a spurious fast recovery and unnecessary congestion window reduction. To mitigate the issue, [RFC4653] adjusts DupThresh to half of the inflight size to tolerate the higher degree of reordering. However if more than half of the inflight is lost, then the sender has to resort to RTO recovery." This seems to be somewhat incorrect description of TCP-NCR specified in RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending new data segments on DupAcks that makes it likely to avoid an RTO in the given example scenario, if not too many of the the new data segments triggered by Extended Limited Transmit are lost. Sec. 3.5: "For example, consider a simple case where one segment was sent with an RTO of 1 second, and then the application writes more data, causing a second and third segment to be sent right before the RTO of the first segment expires. Suppose only the first segment is lost. Without RACK, upon RTO expiration the sender marks all three segments as lost and retransmits the first segment. When the sender receives the ACK that selectively acknowledges the second segment, the sender spuriously retransmits the third segment." This seems incorrect. When the sender receives the ACK that selectively acknowledges the second segment, it is a DupAck as per RFC 6675 and does not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the rexmit of the third segment is not allowad until the cumulative ACK of the first segment arrives. Best regards, /Markku On Mon, 16 Nov 2020, The IESG wrote: > > The IESG has received a request from the TCP Maintenance and Minor Extensions > WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection > algorithm for TCP' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document presents the RACK-TLP loss detection algorithm for TCP. > RACK-TLP uses per-segment transmit timestamps and selective > acknowledgements (SACK) and has two parts: RACK ("Recent > ACKnowledgment") starts fast recovery quickly using time-based > inferences derived from ACK feedback. TLP ("Tail Loss Probe") > leverages RACK and sends a probe packet to trigger ACK feedback to > avoid retransmission timeout (RTO) events. Compared to the widely > used DUPACK threshold approach, RACK-TLP detects losses more > efficiently when there are application-limited flights of data, lost > retransmissions, or data packet reordering events. It is intended to > be an alternative to the DUPACK threshold approach. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Fri Dec 4 15:35:18 2020 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 5D7E63A0E32; Fri, 4 Dec 2020 15:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 gUitAfVsZUdG; Fri, 4 Dec 2020 15:35:10 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2083A1083; Fri, 4 Dec 2020 15:35:07 -0800 (PST) Received: from [IPv6:2800:810:464:8164:896a:de13:c010:ff3a] (unknown [IPv6:2800:810:464:8164:896a:de13:c010:ff3a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 29AF2283AA7; Fri, 4 Dec 2020 23:35:02 +0000 (UTC) To: Tom Herbert , Brian E Carpenter Cc: Erik Kline , IPv6 Operations , tcpm , Fernando Gont References: <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> From: Fernando Gont Message-ID: <70c456f7-ce86-1bd2-a580-71524ce2606f@si6networks.com> Date: Thu, 3 Dec 2020 19:41:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] [v6ops] Flow Label Load Balancing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 23:35:14 -0000 Tom, On 3/12/20 17:38, Tom Herbert wrote: > On Thu, Dec 3, 2020 at 1:17 PM Brian E Carpenter > wrote: >> >> On 04-Dec-20 06:30, Tom Herbert wrote: >>> On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: [....] >> >> But that doesn't help with server load balancing. For ECMP/LAG in a >> transit network, the DA alone doesn't help either, if a particular >> destination is prone to very heavy flows for some reason. > > Brian, > > Specifically, that is a problem for a host that uses a _single_ IPv6 > address for all its connections. That that's the vast majority of current hosts - if not all. > What I am suggesting is to give hosts > many addresses, which we already do anyway like when mobile devices > and data center servers are assigned /64s. If a host then randomly > chooses an address from that block for each connection it creates > thenl the address 2-tuple contains all the entropy needed for purposes > of load balancing, ECMP, etc. is contained in the source address. > Addresses are guaranteed to be present and plaintext in each packet so > no DPI required, they're as stable as any flow identifying information > in a packet can be and they offer much more entropy than sixteen bits > of port number of twenty bit flow label. Agreed. Although that move is not-trivial: e.g. if you move from shared link to /64 per hosts, then stuff like mDNS breaks. There's also an API to be specifiied. P.S.: And, in the process, we have kind of burned 64-bits of the 128-bit IPv6 addresses, too... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Dec 4 15:57:43 2020 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 295D53A108F for ; Fri, 4 Dec 2020 15:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 ampYISUpbd2y for ; Fri, 4 Dec 2020 15:57:37 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 6D5373A1097 for ; Fri, 4 Dec 2020 15:57:34 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id l1so6886780wrb.9 for ; Fri, 04 Dec 2020 15:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GTh3TkLn5ogjgOgxmZaDelBzqlL0rm6+QAZmsH9wHkU=; b=lM8dYO8PyWux1hugrCnp1H0XWpoMDDxv02zv5tuhL67cAkgDzVVn9x1qOCJf0/VL+z aFAAB3NWJT+2Ha2mutWNRvJHb34pW68ZMo0aBmhtN4TYH3PADhs6ky9Auqw2osvjmDMD tw4SqZXr/vZ2/1AfyBIMfCgMEi9O8DyI8UYy1Jd7TjDMldVd1FmFT2teVT/g6NsTZfb3 tSjlhZu4VLctyPOO9T0tHnelYE/IvIJ7WL1AKe6vuOcpianvweGCE9zdiazKdbP4KKN7 wF/tWqfCaw5kh83uor2REpKn6stWD2uMxOL7AwwQeNXyRzn7OqelZFxt3HlglbgvMQRb cB5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GTh3TkLn5ogjgOgxmZaDelBzqlL0rm6+QAZmsH9wHkU=; b=e9OtPlss9Qv6ZgRfJ7Eoi6/L0B7Q8tEa1yXBR1StfZ+RKJrldnCx/fxOg+Vt6Tcssr mYmhWYOcBMASplgcRtFOqrlQ8TKXVrRvKWb7NxRHEkbK8qQjZk0tV2GXYEUoGWQZpDjK n4/kDxjj5oaiPEKXsYA/fbm1Bs3rgH8WjWd30Tx1ETT50gFB+Y58nl0TZ/lA4CNaWYzb +lmhENAD7rq2bI+aYj7Tbw351UoOvcTSff5sxn2R3ett8Hpi82QjH4a1HvvU0P9Qo2F+ ZNyhJC0yvBv5E0HOF1iv7pvVxCaH/TF2UiRRowwp4CVHjlcRZ7v8qB387R6oYa9jTXbb 7cdA== X-Gm-Message-State: AOAM531WbMIi7lDhgOk7k0VkcMWfFbrrXxU4PMcTTQJbty6BvvuEmmNe 1hQC04C81Xmn1dmFL1hQtRxI8rnQzJTrDHwcYIdEOw== X-Google-Smtp-Source: ABdhPJyc2X0p0a790UWDs69knu9tEH3b1FhUqinfGjH1kSKlMqams1Cr5WGiMWumpYrrWkeKCQkCs6AIobTaADJInNg= X-Received: by 2002:adf:ee12:: with SMTP id y18mr7420113wrn.231.1607126252519; Fri, 04 Dec 2020 15:57:32 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Yuchung Cheng Date: Fri, 4 Dec 2020 15:56:55 -0800 Message-ID: To: Markku Kojo Cc: last-call@ietf.org, IETF-Announce , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Last Call: (The RACK-TLPloss detection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 23:57:39 -0000 On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: > > Hi all, > > I know this is a bit late but I didn't have time earlier to take look at > this draft. > > Given that this RFC to be is standards track and RECOMMENDED to replace > current DupAck-based loss detection, it is important that the spec is > clear on its advice to those implementing it. Current text seems to > lack important advice w.r.t congestion control, and even though > the spec tries to decouple loss detection from congestion control > and does not intend to modify existing standard congestion control > some of the examples advice incorrect congestion control actions. > Therefore, I think it is worth to correct the mistakes and take > yet another look at a few implications of this specification. As you noted, the intention is to decouple the two as much as possible Unlike the 20 years ago where TCP loss detection and congestion control are essentially glued in one piece, the decoupling of the two (including modularizing congestion controls in implementations) has helped fueled many great inventions of new congestion controls. Codifying so-called-default C.C. reactions in the loss detection is a step backward that the authors try their best to avoid.To keep the document less "abstract / unclear" as many WGLC reviewers commented, we use examples to illustrate that includes CC actions. But the details of these CC actions are likely to become obsolete as CC continues to advance hopefully. > > Sec. 3.4 (and elsewhere when discussing recovering a dropped > retransmission): > > It is very useful that RACK-TLP allows for recovering dropped rexmits. > However, it seems that the spec ignores the fact that loss of a > retransmission is a loss in a successive window that requires reacting > to congestion twice as per RFC 5681. This advice must be included in > the specification because with RACK-TLP recovery of dropped rexmit > takes place during the fast recovery which is very different > from the other standard algorithms and therefore easy to miss > when implementing this spec. per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 "Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case." RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on this so I am not sure what clause you suggest to add to RACK-TLP. > > Sec 9.3: > > In Section 9.3 it is stated that the only modification to the existing > congestion control algorithms is that one outstanding loss probe > can be sent even if the congestion window is fully used. This is > fine, but the spec lacks the advice that if a new data segment is sent > this extra segment MUST NOT be included when calculating the new value > of ssthresh as per the equation (4) of RFC 5681. Such segment is an > extra segment not allowed by cwnd, so it must be excluded from > FlightSize, if the TLP probe detects loss or if there is no ack > and RTO is needed to trigger loss recovery. Why exclude TLP (or any data) from FlightSize? The congestion control needs precise accounting of the flight size to react to congestion properly. > > In these cases the temporary over-commit is not accounted for as DupAck > does not decrease FlightSize and in case of an RTO the next ACK comes too > late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits > including the segments transmitted via Limitid Transmit in the > calculation of ssthresh. > > In Section 9.3 a few example scenarios are used to illustriate the > intended operation of RACK-TLP. > > In the first example a sender has a congestion window (cwnd) of 20 > segments on a SACK-enabled connection. It sends 10 data segments > and all of them are lost. > > The text claims that without RACK-TLP the ending cwnd would be 4 segments > due to congestion window validation. This is incorrect. > As per RFC 7661 the sender MUST exit the non-validated phase upon an > RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if > the TCP sender uses the equation (4) of RFC 5681). > > The operation with RACK-TLP would inevitably result in congestion > collapse if RACK-TLP behaves as described in the example because > it restores the previous cwnd of 10 segments after the fast recovery > and would not react to congestion at all! I think this is not the > intended behavior by this spec but a mistake in the example. > The ssthresh calculated in the beginning of loss recovery should > be 5 segments as per RFC 6675 (and RFC 5681). To clarify, would this text look more clear? 'an ending cwnd set to the slow start threshold of 5 segments (half of the original congestion window of 10 segments)' > > Furthermore, it seems that this example with RACK-TLP refers to using > PRR_SSRB which effectively implements regular slow start in this > case(?). From congestion control point of view this is correct because > the entire flight of data as well as ack clock was lost. > > However, as correctly discussed in Sec 2, congestion window must be reset > to 1 MSS when an entire flight of data is and Ack clock is lost. But how > can an implementor know what to do if she/he is not implementing the > experimental PRR algrorithm? This spec articulates specifying an > alternative for DupAck counting, indicating that TLP is used to trigger > Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. > This means that without an additional advise an implementation of this > spec would just halve the cwnd and ssthresh and send a potentially very > large burst of segments in the beginning of the Fast Recovery because > there is no ack clock. So, this spec begs for an advise (MUST) when to > slow start and reset cwnd and when not, or at least a discussion of > this problem and some sort of advise what to do and what to avoid. > And, maybe a recommendation to implement it with PRR? It's wise to decouple loss detection (RACK-TLP) vs congestion/burst control (when to slow-start). The use of PRR is just an example to illustrate and not meant for a recommendation. Section 3 has a lengthy section to elaborate the key point of RACK-TLP is to maximize the chance of fast recovery. How C.C. governs the transmission dynamics after losses are detected are out of scope of this document in our authors' opinions. > > Another question relates to the use of TLP and adjusting timer(s) upon > timeout. In the same example discussed above, it is clear that PTO > that fires TLP is just a more aggressive retransmit timer with > an alternative data segment to (re)transmit. > > Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in > effect a retransmission timout and the timer(s) must be backed-off. > This is not adviced in this specification. Whether it is the TCP RTO > or PTO that should be backed-off is an open question. Otherwise, > if the congestion is persistent and further transmission are also lost, > RACK-TLP would not react to congestion properly but would keep > retransmitting with "constant" timer value because new RTT estimate > cannot be obtained. > On a buffer bloated and heavily congested bottleneck this would easily > result in sending at least one unnecessary retransmission per one > delivered segment which is not advisable (e.g., when there are a huge > number of applications sharing a constrained bottleneck and these > applications are sending only one (or a few) segments and then > waiting for an reply from the peer before sending another request). Thanks for pointing to the RFC. After TLP, RTO timers will exp-backoff (as usual) for stability reasons mentioned in sec 9.3 (didn't find 9.1 relevant). In your scenario, you presuppose the retransmission is unnecessary so obviously TLP is not good. Consider what happens without TLP where all the senders fire RTO spuriously and blow up the network. It is equally unfortunate behavior. "bdp insufficient of many flows" is a congestion control problem > > Additional notes: > > Sec 2.2: > > Example 2: > "Lost retransmissions cause a resort to RTO recovery, since > DUPACK-counting does not detect the loss of the retransmissions. > Then the slow start after RTO recovery could cause burst losses > again that severely degrades performance [POLICER16]." > > RTO reovery is done in slow start. The last sentence is confusing as > there is no (new) slow-start after RTO recovery (or more precisely > slow start continues until cwnd > ssthresh). Do you mean: if/when slow > start still continues after RTO Recovery has repaired lost segments, > it may cause burst losses again? I mean the slow start after (the start of) RTO recovery. HTH > > Example 3: > "If the reordering degree is beyond DupThresh, the DUPACK- > counting can cause a spurious fast recovery and unnecessary > congestion window reduction. To mitigate the issue, [RFC4653] > adjusts DupThresh to half of the inflight size to tolerate the > higher degree of reordering. However if more than half of the > inflight is lost, then the sender has to resort to RTO recovery." > > This seems to be somewhat incorrect description of TCP-NCR specified in > RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending > new data segments on DupAcks that makes it likely to avoid an RTO in > the given example scenario, if not too many of the the new data > segments triggered by Extended Limited Transmit are lost. sorry I don't see how the text is wrong describing RFC4653, specifically the algorithm in adjusting ssthresh > > Sec. 3.5: > > "For example, consider a simple case where one > segment was sent with an RTO of 1 second, and then the application > writes more data, causing a second and third segment to be sent right > before the RTO of the first segment expires. Suppose only the first > segment is lost. Without RACK, upon RTO expiration the sender marks > all three segments as lost and retransmits the first segment. When > the sender receives the ACK that selectively acknowledges the second > segment, the sender spuriously retransmits the third segment." > > This seems incorrect. When the sender receives the ACK that selectively > acknowledges the second segment, it is a DupAck as per RFC 6675 and does > not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the > rexmit of the third segment is not allowad until the cumulative ACK of > the first segment arrives. I don't see where RFC6675 forbids growing cwnd. Even if it does, I don't think it's a good thing (in RTO-slow-start) as DUPACK clearly indicates a delivery has been made. > > Best regards, > > /Markku > > > > On Mon, 16 Nov 2020, The IESG wrote: > > > > > The IESG has received a request from the TCP Maintenance and Minor Extensions > > WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection > > algorithm for TCP' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits final > > comments on this action. Please send substantive comments to the > > last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may > > be sent to iesg@ietf.org instead. In either case, please retain the beginning > > of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document presents the RACK-TLP loss detection algorithm for TCP. > > RACK-TLP uses per-segment transmit timestamps and selective > > acknowledgements (SACK) and has two parts: RACK ("Recent > > ACKnowledgment") starts fast recovery quickly using time-based > > inferences derived from ACK feedback. TLP ("Tail Loss Probe") > > leverages RACK and sends a probe packet to trigger ACK feedback to > > avoid retransmission timeout (RTO) events. Compared to the widely > > used DUPACK threshold approach, RACK-TLP detects losses more > > efficiently when there are application-limited flights of data, lost > > retransmissions, or data packet reordering events. It is intended to > > be an alternative to the DUPACK threshold approach. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Fri Dec 4 17:14:14 2020 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 C37C43A1125 for ; Fri, 4 Dec 2020 17:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Uw928NvWLeBA for ; Fri, 4 Dec 2020 17:14:07 -0800 (PST) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 CC50F3A112B for ; Fri, 4 Dec 2020 17:14:03 -0800 (PST) Received: by mail-yb1-xb29.google.com with SMTP id v92so7188558ybi.4 for ; Fri, 04 Dec 2020 17:14:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8bSff3TWjW8NALDMsGJeLRuLM6OpJkiYQiE2y/W7fgM=; b=o0I5ZCahZ3qJjJyfVYr/QPPDe9xqXcgEkkE8OoGkQ1ba1Yq38M0ai6NCE4tAMzvkI5 5qPhzUO7TRot6ndxsGDDd85zGMZAskc+3S4Y0prVSGo6SR5+FjTQ/9GGvC3ACUz2SeFk DocXn/LUOe/Y0JzJAufuPL1L/DV+hTKJUqIN02lbZxGFyiq22BkJeMieiBVK+b1hs4in +iLU8GH1mhK4xTVXpCo/fcf42EfHhbbSVfZ8C8GKXu2vi2j0yG4PwNpB58Lf9pHiMX6P TunlJAfmyILk821L5q2zZXIRmbY/pDjSFWiamZ4P1NahVrfHNZ5XKmma8WFtLLsKaSFR LbHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8bSff3TWjW8NALDMsGJeLRuLM6OpJkiYQiE2y/W7fgM=; b=EAh2SxbUo2Hs7+46Hk3DCV1oVgMUUUUKNJ0J/gtAhNSKAXY3AjBwDQWdM1y4NjDJwD ALf/GQ2f41baragJCKcpKZ2vG7aSqsPHwI9ttvTEwTKxULW33zjPfxrZki8zJ2OW2YRg raOl56dEVM+JisvpW6uC50pvg6tTxoZpATJfJTHG/EJilNZI9AFEi9Yw+m2jUAGmvBFg Llr0qtowWU6K1aw79/hhVqiOpkI1UdwepfLSzZyO+vWLLLrUWWWBtFoO21tO5NuNzrW4 p+SbDrVKHMvCSllcQ0deofEDE6h4N6lW0/nGn5Y3/52jY+OCPeSx91wd6/Cz/q9rCb5q GFWg== X-Gm-Message-State: AOAM5306Kwi33avwtfuXO0dMix3QUEa19qtIEwi9ZsC3rRMNOuJLWQQI uhYoZHR4dxTYUkyg/3uUeSHnDKTI8/3x8UlOTaGRzQ== X-Google-Smtp-Source: ABdhPJzc9mCtLNAynW6v5R30PNmdKoyw22Cp7gAOvOBkNbqFSpaVrdP8ho8wDn7AOuMev0THXujlgdT/U4CSrJWcSVw= X-Received: by 2002:a5b:f41:: with SMTP id y1mr9454876ybr.119.1607130842499; Fri, 04 Dec 2020 17:14:02 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Ian Swett Date: Fri, 4 Dec 2020 20:13:51 -0500 Message-ID: To: Yuchung Cheng Cc: Markku Kojo , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, Last Call , IETF-Announce , tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000f9ffd005b5ad4e32" Archived-At: Subject: Re: [tcpm] Last Call: (The RACK-TLPloss detection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 05 Dec 2020 01:14:13 -0000 --000000000000f9ffd005b5ad4e32 Content-Type: text/plain; charset="UTF-8" +1 to decoupling loss detection from congestion control. It ensures RACK does not need to not be updated every time a new congestion controller is standardized. On Fri, Dec 4, 2020 at 6:58 PM Yuchung Cheng wrote: > On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: > > > > Hi all, > > > > I know this is a bit late but I didn't have time earlier to take look at > > this draft. > > > > Given that this RFC to be is standards track and RECOMMENDED to replace > > current DupAck-based loss detection, it is important that the spec is > > clear on its advice to those implementing it. Current text seems to > > lack important advice w.r.t congestion control, and even though > > the spec tries to decouple loss detection from congestion control > > and does not intend to modify existing standard congestion control > > some of the examples advice incorrect congestion control actions. > > Therefore, I think it is worth to correct the mistakes and take > > yet another look at a few implications of this specification. > As you noted, the intention is to decouple the two as much as possible > > Unlike the 20 years ago where TCP loss detection and congestion > control are essentially glued in one piece, the decoupling of the two > (including modularizing congestion controls in implementations) has > helped fueled many great inventions of new congestion controls. > Codifying so-called-default C.C. reactions in the loss detection is a > step backward that the authors try their best to avoid.To keep the > document less "abstract / unclear" as many WGLC reviewers commented, > we use examples to illustrate that includes CC actions. But the > details of these CC actions are likely to become obsolete as CC > continues to advance hopefully. > > > > > Sec. 3.4 (and elsewhere when discussing recovering a dropped > > retransmission): > > > > It is very useful that RACK-TLP allows for recovering dropped rexmits. > > However, it seems that the spec ignores the fact that loss of a > > retransmission is a loss in a successive window that requires reacting > > to congestion twice as per RFC 5681. This advice must be included in > > the specification because with RACK-TLP recovery of dropped rexmit > > takes place during the fast recovery which is very different > > from the other standard algorithms and therefore easy to miss > > when implementing this spec. > > per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 > "Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion and, > therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > > RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on > this so I am not sure what clause you suggest to add to RACK-TLP. > > > > Sec 9.3: > > > > In Section 9.3 it is stated that the only modification to the existing > > congestion control algorithms is that one outstanding loss probe > > can be sent even if the congestion window is fully used. This is > > fine, but the spec lacks the advice that if a new data segment is sent > > this extra segment MUST NOT be included when calculating the new value > > of ssthresh as per the equation (4) of RFC 5681. Such segment is an > > extra segment not allowed by cwnd, so it must be excluded from > > FlightSize, if the TLP probe detects loss or if there is no ack > > and RTO is needed to trigger loss recovery. > > Why exclude TLP (or any data) from FlightSize? The congestion control > needs precise accounting of the flight size to react to congestion > properly. > > > > > In these cases the temporary over-commit is not accounted for as DupAck > > does not decrease FlightSize and in case of an RTO the next ACK comes too > > late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits > > including the segments transmitted via Limitid Transmit in the > > calculation of ssthresh. > > > > In Section 9.3 a few example scenarios are used to illustriate the > > intended operation of RACK-TLP. > > > > In the first example a sender has a congestion window (cwnd) of 20 > > segments on a SACK-enabled connection. It sends 10 data segments > > and all of them are lost. > > > > The text claims that without RACK-TLP the ending cwnd would be 4 segments > > due to congestion window validation. This is incorrect. > > As per RFC 7661 the sender MUST exit the non-validated phase upon an > > RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if > > the TCP sender uses the equation (4) of RFC 5681). > > > > The operation with RACK-TLP would inevitably result in congestion > > collapse if RACK-TLP behaves as described in the example because > > it restores the previous cwnd of 10 segments after the fast recovery > > and would not react to congestion at all! I think this is not the > > intended behavior by this spec but a mistake in the example. > > The ssthresh calculated in the beginning of loss recovery should > > be 5 segments as per RFC 6675 (and RFC 5681). > To clarify, would this text look more clear? > > 'an ending cwnd set to the slow start threshold of 5 segments (half of > the original congestion window of 10 segments)' > > > > > Furthermore, it seems that this example with RACK-TLP refers to using > > PRR_SSRB which effectively implements regular slow start in this > > case(?). From congestion control point of view this is correct because > > the entire flight of data as well as ack clock was lost. > > > > However, as correctly discussed in Sec 2, congestion window must be reset > > to 1 MSS when an entire flight of data is and Ack clock is lost. But how > > can an implementor know what to do if she/he is not implementing the > > experimental PRR algrorithm? This spec articulates specifying an > > alternative for DupAck counting, indicating that TLP is used to trigger > > Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. > > This means that without an additional advise an implementation of this > > spec would just halve the cwnd and ssthresh and send a potentially very > > large burst of segments in the beginning of the Fast Recovery because > > there is no ack clock. So, this spec begs for an advise (MUST) when to > > slow start and reset cwnd and when not, or at least a discussion of > > this problem and some sort of advise what to do and what to avoid. > > And, maybe a recommendation to implement it with PRR? > > It's wise to decouple loss detection (RACK-TLP) vs congestion/burst > control (when to slow-start). The use of PRR is just an example to > illustrate and not meant for a recommendation. > > Section 3 has a lengthy section to elaborate the key point of RACK-TLP > is to maximize the chance of fast recovery. How C.C. governs the > transmission dynamics after losses are detected are out of scope of > this document in our authors' opinions. > > > > > > Another question relates to the use of TLP and adjusting timer(s) upon > > timeout. In the same example discussed above, it is clear that PTO > > that fires TLP is just a more aggressive retransmit timer with > > an alternative data segment to (re)transmit. > > > > Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in > > effect a retransmission timout and the timer(s) must be backed-off. > > This is not adviced in this specification. Whether it is the TCP RTO > > or PTO that should be backed-off is an open question. Otherwise, > > if the congestion is persistent and further transmission are also lost, > > RACK-TLP would not react to congestion properly but would keep > > retransmitting with "constant" timer value because new RTT estimate > > cannot be obtained. > > On a buffer bloated and heavily congested bottleneck this would easily > > result in sending at least one unnecessary retransmission per one > > delivered segment which is not advisable (e.g., when there are a huge > > number of applications sharing a constrained bottleneck and these > > applications are sending only one (or a few) segments and then > > waiting for an reply from the peer before sending another request). > > Thanks for pointing to the RFC. After TLP, RTO timers will > exp-backoff (as usual) for stability reasons mentioned in sec 9.3 > (didn't find 9.1 relevant). In your scenario, you presuppose the > retransmission is unnecessary so obviously TLP is not good. Consider > what happens without TLP where all the senders fire RTO spuriously and > blow up the network. It is equally unfortunate behavior. "bdp > insufficient of many flows" is a congestion control problem > > > > > > Additional notes: > > > > Sec 2.2: > > > > Example 2: > > "Lost retransmissions cause a resort to RTO recovery, since > > DUPACK-counting does not detect the loss of the retransmissions. > > Then the slow start after RTO recovery could cause burst losses > > again that severely degrades performance [POLICER16]." > > > > RTO reovery is done in slow start. The last sentence is confusing as > > there is no (new) slow-start after RTO recovery (or more precisely > > slow start continues until cwnd > ssthresh). Do you mean: if/when slow > > start still continues after RTO Recovery has repaired lost segments, > > it may cause burst losses again? > I mean the slow start after (the start of) RTO recovery. HTH > > > > > > Example 3: > > "If the reordering degree is beyond DupThresh, the DUPACK- > > counting can cause a spurious fast recovery and unnecessary > > congestion window reduction. To mitigate the issue, [RFC4653] > > adjusts DupThresh to half of the inflight size to tolerate the > > higher degree of reordering. However if more than half of the > > inflight is lost, then the sender has to resort to RTO recovery." > > > > This seems to be somewhat incorrect description of TCP-NCR specified in > > RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending > > new data segments on DupAcks that makes it likely to avoid an RTO in > > the given example scenario, if not too many of the the new data > > segments triggered by Extended Limited Transmit are lost. > sorry I don't see how the text is wrong describing RFC4653, > specifically the algorithm in adjusting ssthresh > > > > > Sec. 3.5: > > > > "For example, consider a simple case where one > > segment was sent with an RTO of 1 second, and then the application > > writes more data, causing a second and third segment to be sent right > > before the RTO of the first segment expires. Suppose only the first > > segment is lost. Without RACK, upon RTO expiration the sender marks > > all three segments as lost and retransmits the first segment. When > > the sender receives the ACK that selectively acknowledges the second > > segment, the sender spuriously retransmits the third segment." > > > > This seems incorrect. When the sender receives the ACK that selectively > > acknowledges the second segment, it is a DupAck as per RFC 6675 and does > > not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the > > rexmit of the third segment is not allowad until the cumulative ACK of > > the first segment arrives. > I don't see where RFC6675 forbids growing cwnd. Even if it does, I > don't think it's a good thing (in RTO-slow-start) as DUPACK clearly > indicates a delivery has been made. > > > > > > Best regards, > > > > /Markku > > > > > > > > On Mon, 16 Nov 2020, The IESG wrote: > > > > > > > > The IESG has received a request from the TCP Maintenance and Minor > Extensions > > > WG (tcpm) to consider the following document: - 'The RACK-TLP loss > detection > > > algorithm for TCP' > > > as Proposed Standard > > > > > > The IESG plans to make a decision in the next few weeks, and solicits > final > > > comments on this action. Please send substantive comments to the > > > last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, > comments may > > > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > > > of the Subject line to allow automated sorting. > > > > > > Abstract > > > > > > > > > This document presents the RACK-TLP loss detection algorithm for TCP. > > > RACK-TLP uses per-segment transmit timestamps and selective > > > acknowledgements (SACK) and has two parts: RACK ("Recent > > > ACKnowledgment") starts fast recovery quickly using time-based > > > inferences derived from ACK feedback. TLP ("Tail Loss Probe") > > > leverages RACK and sends a probe packet to trigger ACK feedback to > > > avoid retransmission timeout (RTO) events. Compared to the widely > > > used DUPACK threshold approach, RACK-TLP detects losses more > > > efficiently when there are application-limited flights of data, lost > > > retransmissions, or data packet reordering events. It is intended to > > > be an alternative to the DUPACK threshold approach. > > > > > > > > > > > > > > > The file can be obtained via > > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000f9ffd005b5ad4e32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to decoupling loss detection from congestion control.= =C2=A0 It ensures RACK does not need to not be updated every time a new con= gestion controller is standardized.

On Fri, Dec 4, 2020 at 6:58 PM Yuchung C= heng <ycheng=3D40google.c= om@dmarc.ietf.org> wrote:
On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo <kojo@cs.helsinki.fi> w= rote:
>
> Hi all,
>
> I know this is a bit late but I didn't have time earlier to take l= ook at
> this draft.
>
> Given that this RFC to be is standards track and RECOMMENDED to replac= e
> current DupAck-based loss detection, it is important that the spec is<= br> > clear on its advice to those implementing it. Current text seems to > lack important advice w.r.t congestion control, and even though
> the spec tries to decouple loss detection from congestion control
> and does not intend to modify existing standard congestion control
> some of the examples advice incorrect congestion control actions.
> Therefore, I think it is worth to correct the mistakes and take
> yet another look at a few implications of this specification.
As you noted, the intention is to decouple the two as much as possible

Unlike the 20 years ago where TCP loss detection and congestion
control are essentially glued in one piece, the decoupling of the two
(including modularizing congestion controls in implementations) has
helped fueled many great inventions of new congestion controls.
Codifying so-called-default C.C. reactions in the loss detection is a
step backward that the authors try their best to avoid.To keep the
document less "abstract / unclear" as many WGLC reviewers comment= ed,
we use examples to illustrate that includes CC actions. But the
details of these CC actions are likely to become obsolete as CC
continues to advance hopefully.

>
> Sec. 3.4 (and elsewhere when discussing recovering a dropped
> retransmission):
>
> It is very useful that RACK-TLP allows for recovering dropped rexmits.=
> However, it seems that the spec ignores the fact that loss of a
> retransmission is a loss in a successive window that requires reacting=
> to congestion twice as per RFC 5681. This advice must be included in > the specification because with RACK-TLP recovery of dropped rexmit
> takes place during the fast recovery which is very different
> from the other standard algorithms and therefore easy to miss
> when implementing this spec.

per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc56= 81#section-4.3
"Loss in two successive windows of data, or the loss of a
=C2=A0 retransmission, should be taken as two indications of congestion and= ,
=C2=A0 =C2=A0therefore, cwnd (and ssthresh) MUST be lowered twice in this c= ase."

RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on
this so I am not sure what clause you suggest to add to RACK-TLP.
>
> Sec 9.3:
>
> In Section 9.3 it is stated that the only modification to the existing=
> congestion control algorithms is that one outstanding loss probe
> can be sent even if the congestion window is fully used. This is
> fine, but the spec lacks the advice that if a new data segment is sent=
> this extra segment MUST NOT be included when calculating the new value=
> of ssthresh as per the equation (4) of RFC 5681. Such segment is an > extra segment not allowed by cwnd, so it must be excluded from
> FlightSize, if the TLP probe detects loss or if there is no ack
> and RTO is needed to trigger loss recovery.

Why exclude TLP (or any data) from FlightSize? The congestion control
needs precise accounting of the flight size to react to congestion
properly.

>
> In these cases the temporary over-commit is not accounted for as DupAc= k
> does not decrease FlightSize and in case of an RTO the next ACK comes = too
> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohib= its
> including the segments transmitted via Limitid Transmit in the
> calculation of ssthresh.
>
> In Section 9.3 a few example scenarios are used to illustriate the
> intended operation of RACK-TLP.
>
>=C2=A0 =C2=A0In the first example a sender has a congestion window (cwn= d) of 20
>=C2=A0 =C2=A0segments on a SACK-enabled connection.=C2=A0 It sends 10 d= ata segments
>=C2=A0 =C2=A0and all of them are lost.
>
> The text claims that without RACK-TLP the ending cwnd would be 4 segme= nts
> due to congestion window validation. This is incorrect.
> As per RFC 7661 the sender MUST exit the non-validated phase upon an > RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments = if
> the TCP sender uses the equation (4) of RFC 5681).
>
> The operation with RACK-TLP would inevitably result in congestion
> collapse if RACK-TLP behaves as described in the example because
> it restores the previous cwnd of 10 segments after the fast recovery > and would not react to congestion at all! I think this is not the
> intended behavior by this spec but a mistake in the example.
> The ssthresh calculated in the beginning of loss recovery should
> be 5 segments as per RFC 6675 (and RFC 5681).
To clarify, would this text look more clear?

'an ending cwnd set to the slow start threshold of 5 segments (half of<= br> the original congestion window of 10 segments)'

>
> Furthermore, it seems that this example with RACK-TLP refers to using<= br> > PRR_SSRB which effectively implements regular slow start in this
> case(?). From congestion control point of view this is correct because=
> the entire flight of data as well as ack clock was lost.
>
> However, as correctly discussed in Sec 2, congestion window must be re= set
> to 1 MSS when an entire flight of data is and Ack clock is lost. But h= ow
> can an implementor know what to do if she/he is not implementing the > experimental PRR algrorithm? This spec articulates specifying an
> alternative for DupAck counting, indicating that TLP is used to trigge= r
> Fast Retransmit & Fast Recovery only, not a loss recovery in slow = start.
> This means that without an additional advise an implementation of this=
> spec would just halve the cwnd and ssthresh and send a potentially ver= y
> large burst of segments in the beginning of the Fast Recovery because<= br> > there is no ack clock. So, this spec begs for an advise (MUST) when to=
> slow start and reset cwnd and when not, or at least a discussion of > this problem and some sort of advise what to do and what to avoid.
> And, maybe a recommendation to implement it with PRR?

It's wise to decouple loss detection (RACK-TLP) vs congestion/burst
control (when to slow-start). The use of PRR is just an example to
illustrate and not meant for a recommendation.

Section 3 has a lengthy section to elaborate the key point of RACK-TLP
is to maximize the chance of fast recovery. How C.C. governs the
transmission dynamics after losses are detected are out of scope of
this document in our authors' opinions.


>
> Another question relates to the use of TLP and adjusting timer(s) upon=
> timeout. In the same example discussed above, it is clear that PTO
> that fires TLP is just a more aggressive retransmit timer with
> an alternative data segment to (re)transmit.
>
> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is = in
> effect a retransmission timout and the timer(s) must be backed-off. > This is not adviced in this specification. Whether it is the TCP RTO > or PTO that should be backed-off is an open question.=C2=A0 Otherwise,=
> if the congestion is persistent and further transmission are also lost= ,
> RACK-TLP would not react to congestion properly but would keep
> retransmitting with "constant" timer value because new RTT e= stimate
> cannot be obtained.
> On a buffer bloated and heavily congested bottleneck this would easily=
> result in sending at least one unnecessary retransmission per one
> delivered segment which is not advisable (e.g., when there are a huge<= br> > number of applications sharing a constrained bottleneck and these
> applications are sending only one (or a few) segments and then
> waiting for an reply from the peer before sending another request).
Thanks for pointing to the RFC.=C2=A0 After TLP, RTO timers will
exp-backoff (as usual) for stability reasons mentioned in sec 9.3
(didn't find 9.1 relevant). In your scenario, you presuppose the
retransmission is unnecessary so obviously TLP is not good. Consider
what happens without TLP where all the senders fire RTO spuriously and
blow up the network. It is equally unfortunate behavior. "bdp
insufficient of many flows" is a congestion control problem


>
> Additional notes:
>
> Sec 2.2:
>
> Example 2:
> "Lost retransmissions cause a=C2=A0 resort to RTO recovery, since=
>=C2=A0 =C2=A0DUPACK-counting does not detect the loss of the retransmis= sions.
>=C2=A0 =C2=A0Then the slow start after RTO recovery could cause burst l= osses
>=C2=A0 =C2=A0again that severely degrades performance [POLICER16]."= ;
>
> RTO reovery is done in slow start. The last sentence is confusing as > there is no (new) slow-start after RTO recovery (or more precisely
> slow start continues until cwnd > ssthresh). Do you mean: if/when s= low
> start still continues after RTO Recovery has repaired lost segments, > it may cause burst losses again?
I mean the slow start after (the start of) RTO recovery. HTH


>
> Example 3:
>=C2=A0 =C2=A0"If the reordering degree is beyond DupThresh, the DU= PACK-
>=C2=A0 =C2=A0 counting can cause a spurious fast recovery and unnecessa= ry
>=C2=A0 =C2=A0 congestion window reduction.=C2=A0 To mitigate the issue,= [RFC4653]
>=C2=A0 =C2=A0 adjusts DupThresh to half of the inflight size to tolerat= e the
>=C2=A0 =C2=A0 higher degree of reordering.=C2=A0 However if more than h= alf of the
>=C2=A0 =C2=A0 inflight is lost, then the sender has to resort to RTO re= covery."
>
> This seems to be somewhat incorrect description of TCP-NCR specified i= n
> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending=
> new data segments on DupAcks that makes it likely to avoid an RTO in > the given example scenario, if not too many of the the new data
> segments triggered by Extended Limited Transmit are lost.
sorry I don't see how the text is wrong describing RFC4653,
specifically the algorithm in adjusting ssthresh

>
> Sec. 3.5:
>
>=C2=A0 =C2=A0"For example, consider a simple case where one
>=C2=A0 =C2=A0segment was sent with an RTO of 1 second, and then the app= lication
>=C2=A0 =C2=A0writes more data, causing a second and third segment to be= sent right
>=C2=A0 =C2=A0before the RTO of the first segment expires.=C2=A0 Suppose= only the first
>=C2=A0 =C2=A0segment is lost.=C2=A0 Without RACK, upon RTO expiration t= he sender marks
>=C2=A0 =C2=A0all three segments as lost and retransmits the first segme= nt.=C2=A0 When
>=C2=A0 =C2=A0the sender receives the ACK that selectively acknowledges = the second
>=C2=A0 =C2=A0segment, the sender spuriously retransmits the third segme= nt."
>
> This seems incorrect. When the sender receives the ACK that selectivel= y
> acknowledges the second segment, it is a DupAck as per RFC 6675 and do= es
> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the=
> rexmit of the third segment is not allowad until the cumulative ACK of=
> the first segment arrives.
I don't see where RFC6675 forbids growing cwnd. Even if it does, I
don't think it's a good thing (in RTO-slow-start) as DUPACK clearly=
indicates a delivery has been made.


>
> Best regards,
>
> /Markku
>
>
>
> On Mon, 16 Nov 2020, The IESG wrote:
>
> >
> > The IESG has received a request from the TCP Maintenance and Mino= r Extensions
> > WG (tcpm) to consider the following document: - 'The RACK-TLP= loss detection
> > algorithm for TCP'
> >=C2=A0 <draft-ietf-tcpm-rack-13.txt> as Proposed Standard > >
> > The IESG plans to make a decision in the next few weeks, and soli= cits final
> > comments on this action. Please send substantive comments to the<= br> > > last-call= @ietf.org mailing lists by 2020-11-30. Exceptionally, comments may
> > be sent to ies= g@ietf.org instead. In either case, please retain the beginning
> > of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >=C2=A0 =C2=A0This document presents the RACK-TLP loss detection al= gorithm for TCP.
> >=C2=A0 =C2=A0RACK-TLP uses per-segment transmit timestamps and sel= ective
> >=C2=A0 =C2=A0acknowledgements (SACK) and has two parts: RACK (&quo= t;Recent
> >=C2=A0 =C2=A0ACKnowledgment") starts fast recovery quickly us= ing time-based
> >=C2=A0 =C2=A0inferences derived from ACK feedback.=C2=A0 TLP (&quo= t;Tail Loss Probe")
> >=C2=A0 =C2=A0leverages RACK and sends a probe packet to trigger AC= K feedback to
> >=C2=A0 =C2=A0avoid retransmission timeout (RTO) events.=C2=A0 Comp= ared to the widely
> >=C2=A0 =C2=A0used DUPACK threshold approach, RACK-TLP detects loss= es more
> >=C2=A0 =C2=A0efficiently when there are application-limited flight= s of data, lost
> >=C2=A0 =C2=A0retransmissions, or data packet reordering events.=C2= =A0 It is intended to
> >=C2=A0 =C2=A0be an alternative to the DUPACK threshold approach. > >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/dra= ft-ietf-tcpm-rack/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/tcpm > >

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000f9ffd005b5ad4e32-- From nobody Sun Dec 6 15:06:16 2020 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 C7E223A0D03; Sun, 6 Dec 2020 15:06:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: draft-ietf-tcpm-rack.all@ietf.org, last-call@ietf.org, tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160729596677.24036.14420451480687784125@ietfa.amsl.com> Reply-To: Peter Yee Date: Sun, 06 Dec 2020 15:06:06 -0800 Archived-At: Subject: [tcpm] Genart last call review of draft-ietf-tcpm-rack-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 23:06:07 -0000 Reviewer: Peter Yee Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tcpm-rack-14 Reviewer: Peter Yee Review Date: 2020-12-06 IETF LC End Date: 2020-11-30 IESG Telechat date: 2020-12-17 Summary: This is a well-written draft specifying an efficient scheme for detecting and recovering from TCP segment loss. There are a few minor nits that should be corrected prior to publication, but to the extent that I understand this specification, I don't see any major or minor flaws. [Ready with nits] Major issues: None Minor issues: None Nits/editorial comments: General: For all occurrences of "i.e." and "e.g.", make sure that they are consistently followed by a comma. (Like I said, nits.) Specific: Page 7, 1st paragraph, 3rd sentence: change: "DUPTHRESH" to "DupThresh". This appears to be only use of all caps for the term and it does not appear as such in RFC 6675. Page 9, Figure 1: while I understand what is being shown, I'm not a fan of having the "<--" followed by things like "Receive P0" as this is not a transmission by the TCP data receiver in the figure. The ACKs and SACKs are fine on those lines, but I think the receives should be shown on the same line as the sends. Page 9, Figure 1, step 7a: why is there no "receive SACK" as show in step 5a? Page 9, 1st paragraph under Figure 1: change "(P1, P2, P3, P4)" to "(P0, P1, P2, P3)" to match both the figure and the following text. Page 14, 1st paragraph after list item #2: change "round trip" to "round-trip". Page 16, 2nd paragraph: append a comma after "observed". Page 17, 1st paragraph, 1st sentence: append a comma after "temporary". Page 18, 1st paragraph after "now >=" formula, 1 sentence: change "round trip" to "round-trip". Page 18, 2nd to last paragraph, 1st sentence: change "left hand" to "left-hand". Page 20, 2nd to last paragraph, 2nd sentence: change "implementation-specific" to "implementation specific". Page 21, last paragraph, 1st sentence: the pointer to the earlier section is oddly constructed, using doubled single quotes and capitalization that doesn't even match the referenced section (6.1). It would be better, in my opinion, just to give a pointer to the section number. Page 25, item #3, 1st sentence: change "are" to "is" as flight is singular. Page 26, 1st partial paragraph, 1st full sentence: change "data-centers" to "data centers". Page 27, section 9.4, 1st sentence: delete "time" or alternatively insert "a" before "longer". From nobody Mon Dec 7 08:06:24 2020 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 9536F3A1406; Mon, 7 Dec 2020 08:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 WkZIp0M_fGpf; Mon, 7 Dec 2020 08:06:17 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC573A140F; Mon, 7 Dec 2020 08:06:14 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Mon, 07 Dec 2020 18:06:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=MTXXUYDj8YqGPQ2Wv 2KPHPiODYQEt5JgbiuXHgAaiCo=; b=j/Oz9M+XDt9ib4JqrjGC9e2kiQh20vhgJ NwjrI57KioaqJnIEo6w/lIMkZEXICmw7jL2lSVY/kMBZUlK3bxyYXbFQULsEG4GD Br2cAGSbuqCP+2+PRviAEn2TQ8K+qSst0ArtI6GPQJemmHcFkWomUte1BGaBdHMQ QP1qtNKGxY= Received: from hp8x-60 (85-76-105-28-nat.elisa-mobile.fi [85.76.105.28]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Mon, 07 Dec 2020 18:06:03 +0200 id 00000000005A01BC.000000005FCE52EB.000069B0 Date: Mon, 7 Dec 2020 18:06:03 +0200 (EET) From: Markku Kojo To: Yuchung Cheng cc: last-call@ietf.org, "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Last Call: (The RACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 16:06:20 -0000 Hi Yuchung, thanks for your reply. My major point is that IMHO this RACK-TLP specification should give the necessary advice w.r.t congestion control in cases when such advice is not available in the RFC series or is not that easy to interpreted correctly from the existing RFCs. Even though the CC principles were available in RFC series I believe you agree with me that getting detailed CC actions correct is sometimes quite hard, especially if one needs to interpret and apply them from another spec than what one is implementing. Please see more details inline below. In addition, we need to remember that this document is not meant only for TCP experts following the tcpm list and having deep understanding of congestion control but also those implementing TCP, for the very first time, for various appliances, for example. They do not have first hand experience in implementing TCP congestion control and deserve clear advice what to do. On Fri, 4 Dec 2020, Yuchung Cheng wrote: > On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: >> >> Hi all, >> >> I know this is a bit late but I didn't have time earlier to take look at >> this draft. >> >> Given that this RFC to be is standards track and RECOMMENDED to replace >> current DupAck-based loss detection, it is important that the spec is >> clear on its advice to those implementing it. Current text seems to >> lack important advice w.r.t congestion control, and even though >> the spec tries to decouple loss detection from congestion control >> and does not intend to modify existing standard congestion control >> some of the examples advice incorrect congestion control actions. >> Therefore, I think it is worth to correct the mistakes and take >> yet another look at a few implications of this specification. > As you noted, the intention is to decouple the two as much as possible > > Unlike the 20 years ago where TCP loss detection and congestion > control are essentially glued in one piece, the decoupling of the two > (including modularizing congestion controls in implementations) has > helped fueled many great inventions of new congestion controls. > Codifying so-called-default C.C. reactions in the loss detection is a > step backward that the authors try their best to avoid. While I fully agree with the general principle of decoupling loss detection from congestion control when it is possible without leaving open questions, I find it hard to get congestion control right with this spec in certain cases I raised just by following the current standards track CC specifications. The reason for this is that RACK-TLP introduces new ways to detect loss (i.e., not present in any earlier standard track RFC) and the current CC specifications do not provide correct CC actions for such cases as I try to point out below. > To keep the > document less "abstract / unclear" as many WGLC reviewers commented, > we use examples to illustrate that includes CC actions. But the > details of these CC actions are likely to become obsolete as CC > continues to advance hopefully. Agreed. But I would appreciate if the CC actions in the examples would correctly follow what is specified in the the current CC RFCs. And, I would suggest explicitly citing the RFC(s) that each of the examples is illustriating so that there is no doubt which CC variant the example is valid with. Then there is no problem with the correctness of the example either even if the cited RFC becomes later obsoleted. >> >> Sec. 3.4 (and elsewhere when discussing recovering a dropped >> retransmission): >> >> It is very useful that RACK-TLP allows for recovering dropped rexmits. >> However, it seems that the spec ignores the fact that loss of a >> retransmission is a loss in a successive window that requires reacting >> to congestion twice as per RFC 5681. This advice must be included in >> the specification because with RACK-TLP recovery of dropped rexmit >> takes place during the fast recovery which is very different >> from the other standard algorithms and therefore easy to miss >> when implementing this spec. > > per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 > "Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion and, > therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > > RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on > this so I am not sure what clause you suggest to add to RACK-TLP. Right, this is the CC *principle* in RFC 5681 I am refering to but I am afraid it is not enough to help one to correctly implement such lowering of cwnd (and ssthresh) twice when a loss of a retransmission is detected during Fast Recovery. Nor do RFCs clearly advice *when* this reduction must take place. Congestion control principles tell us that congestion must be reacted immediately when detected. But at the same time, standards track CC specifications react to congestion only once during Fast Recovery because the losses in the current window, which Fast Recovery repairs, occured during the same RTT. That is, the current CC specifications do not handle lost rexmits during Fast Recovery but, instead, the correct CC reaction to a loss of a rexmit is automatically achieved by those specifications via RTO when cwnd is explicitly reset upon RTO. Furthermore, the problem I am trying to point out is that there is no correct rule/formula available in the standards track RFCs that would give the correct way to reduce cwnd when the loss of rexmit is detected with RACK-TLP. I suggest everyone reading this message stops reading at this point for a while before continuing reading and figures out themselves what they think would be the correct equation to use in the standards RFC series to find the new halved value for cwnd when RACK-TLP detects a loss of a rexmit during Fast Recovery. I would appreciate a comment on the tcpm list from those who think they found the correct answer immediately and easily, and what was the formula to use. ... I think the best advice one may find by looking at RFC 6675 (and RFC 5681) is to set ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.2) Now, let's modify the example in Sec 3.4 of the draft: 1. Send P0, P1, P2, ..., P20 [Assume P1, ..., P20 dropped by network] 2. Receive P0, ACK P0 3a. 2RTTs after (2), TLP timer fires 3b. TLP: retransmits P20 ... 5a. Receive SACK for P20 5b. RACK: marks P1, ..., P20 lost set cwnd=ssthresh=FlightSize/2=10 5c. Retransmit P1, P2 (and some more depending on how CC implemented) [P1 retransmission dropped by network] Receive SACK P2 & P3 7a. RACK: marks P1 retransmission lost As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 7b. Retransmit P1 ... So, is the new value of the cwnd (10MSS) correct and halved twice? If not, where is the correct formula to do it? Before RFC 5681 was published we had a discussion on FlighSize and that during Fast Recovery it does not reflect the amount of segments in flight correctly but may also have a too large value. It was decided not to try to correct it because it only has an impact when RTO fires during Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too large ssthresh for RTO recovery in some cases was not considered that bad because a TCP sender anyway takes to most conservative CC action with the cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP enables detecting loss of a rexmit during Fast Recovery we have an unresolved problem. >> Sec 9.3: >> >> In Section 9.3 it is stated that the only modification to the existing >> congestion control algorithms is that one outstanding loss probe >> can be sent even if the congestion window is fully used. This is >> fine, but the spec lacks the advice that if a new data segment is sent >> this extra segment MUST NOT be included when calculating the new value >> of ssthresh as per the equation (4) of RFC 5681. Such segment is an >> extra segment not allowed by cwnd, so it must be excluded from >> FlightSize, if the TLP probe detects loss or if there is no ack >> and RTO is needed to trigger loss recovery. > > Why exclude TLP (or any data) from FlightSize? The congestion control > needs precise accounting of the flight size to react to congestion > properly. Because FlightSize does not always reflect the correct amount of data allowed by cwnd. When a TCP sender is not already in loss recovery and it detects loss, this loss indicates the congestion point for the TCP sender, i.e., how much data it can have outstanding. It is this amount of data that it must use in calculating the new value of cwnd (and ssthresh), so it must not include any data sent beyond the congestion point. When TLP sends a new data segment, it is beyond the congestion point and must not be included. Same holds for the segments sent via Limited Transmit: they are allowed to be send out by the packet conservation rule (DupAck indicates a pkt has left the network, but does not allow increasing cwnd), i.e., the actual amount of data in flight remains the same. >> In these cases the temporary over-commit is not accounted for as DupAck >> does not decrease FlightSize and in case of an RTO the next ACK comes too >> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits >> including the segments transmitted via Limitid Transmit in the >> calculation of ssthresh. >> >> In Section 9.3 a few example scenarios are used to illustriate the >> intended operation of RACK-TLP. >> >> In the first example a sender has a congestion window (cwnd) of 20 >> segments on a SACK-enabled connection. It sends 10 data segments >> and all of them are lost. >> >> The text claims that without RACK-TLP the ending cwnd would be 4 segments >> due to congestion window validation. This is incorrect. >> As per RFC 7661 the sender MUST exit the non-validated phase upon an >> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if >> the TCP sender uses the equation (4) of RFC 5681). >> >> The operation with RACK-TLP would inevitably result in congestion >> collapse if RACK-TLP behaves as described in the example because >> it restores the previous cwnd of 10 segments after the fast recovery >> and would not react to congestion at all! I think this is not the >> intended behavior by this spec but a mistake in the example. >> The ssthresh calculated in the beginning of loss recovery should >> be 5 segments as per RFC 6675 (and RFC 5681). > To clarify, would this text look more clear? > > 'an ending cwnd set to the slow start threshold of 5 segments (half of > the original congestion window of 10 segments)' This is correct, but please replace: (half of the original congestion window of 10 segments) --> (half of> the original FlightSize of 10 segments) cwnd in the example was 20 segments. Please also correct the ending cwnd for "without RACK" scenario. I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, my apologies. It MAENT equation (3) AND that results in ending cwnd of 5 and 2/5 MSS (not 5 and 1/2 MSS). NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then ending cwnd would be 6 and 1/6 MSS). >> >> Furthermore, it seems that this example with RACK-TLP refers to using >> PRR_SSRB which effectively implements regular slow start in this >> case(?). From congestion control point of view this is correct because >> the entire flight of data as well as ack clock was lost. >> >> However, as correctly discussed in Sec 2, congestion window must be reset >> to 1 MSS when an entire flight of data is and Ack clock is lost. But how >> can an implementor know what to do if she/he is not implementing the >> experimental PRR algrorithm? This spec articulates specifying an >> alternative for DupAck counting, indicating that TLP is used to trigger >> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. >> This means that without an additional advise an implementation of this >> spec would just halve the cwnd and ssthresh and send a potentially very >> large burst of segments in the beginning of the Fast Recovery because >> there is no ack clock. So, this spec begs for an advise (MUST) when to >> slow start and reset cwnd and when not, or at least a discussion of >> this problem and some sort of advise what to do and what to avoid. >> And, maybe a recommendation to implement it with PRR? > > It's wise to decouple loss detection (RACK-TLP) vs congestion/burst > control (when to slow-start). The use of PRR is just an example to > illustrate and not meant for a recommendation. I understand the use of PRR was just an example, but my point is that if one wants to implement RACK-TLP but does not intend to implement PRR but RFC 6675 then we do not have a rule in RFC 6675 to correctly implement CC for the case when an entire flight is lost and loss is detected with TLP. Congestion control principle for this is clear and also stated in this draft but IMHO it is not enough to ensure correct implementation. To my understanding we only have implementation experience for RACK-TLP only togerher with PRR, which has the necessary rule to handle this kind of scenario correctly. So, my question is how can one implement CC correctly without PRR such a scenario where entire inflight is lost? Which rule and where in the RFC series gives the necessary guidance to reset cwnd and slow start when TCP detets loss of an entire flight? > Section 3 has a lengthy section to elaborate the key point of RACK-TLP > is to maximize the chance of fast recovery. How C.C. governs the > transmission dynamics after losses are detected are out of scope of > this document in our authors' opinions. > > >> >> Another question relates to the use of TLP and adjusting timer(s) upon >> timeout. In the same example discussed above, it is clear that PTO >> that fires TLP is just a more aggressive retransmit timer with >> an alternative data segment to (re)transmit. >> >> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in >> effect a retransmission timout and the timer(s) must be backed-off. >> This is not adviced in this specification. Whether it is the TCP RTO >> or PTO that should be backed-off is an open question. Otherwise, >> if the congestion is persistent and further transmission are also lost, >> RACK-TLP would not react to congestion properly but would keep >> retransmitting with "constant" timer value because new RTT estimate >> cannot be obtained. >> On a buffer bloated and heavily congested bottleneck this would easily >> result in sending at least one unnecessary retransmission per one >> delivered segment which is not advisable (e.g., when there are a huge >> number of applications sharing a constrained bottleneck and these >> applications are sending only one (or a few) segments and then >> waiting for an reply from the peer before sending another request). > > Thanks for pointing to the RFC. After TLP, RTO timers will > exp-backoff (as usual) for stability reasons mentioned in sec 9.3 > (didn't find 9.1 relevant). My apologies for refering to the wrong section of RFC 2914, Yes, I meant Sec 9.3. > In your scenario, you presuppose the > retransmission is unnecessary so obviously TLP is not good. Consider > what happens without TLP where all the senders fire RTO spuriously and > blow up the network. It is equally unfortunate behavior. "bdp > insufficient of many flows" is a congestion control problem If (without TLP) RTO is spurious, it may result in unnecessary retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to detect and resolve it without TLP, so I don't find it as a problem. To clarify more, what I am concerned about. Think about a scenario where a (narrow) bottleneck becomes heavily congested by a huge number of competing senders such that the available capacity per sender is less than 1 segment (or << 1 MSS). This is a situation that network first enters before congestion collapse gets realized. So, it is extremely important that all CC and timer mechanisms handle it properly. Regular TCP handles it via RFC 6298 by backing off RTO expotentially and keeping this backed-off RTO until an new ACK is received for new data. This saves RACK-TLP from full congestion collapse. But consider what happens: even though RTO is backed off, each time a TCP sender manages to get one segment through (with cwnd = 1 MSS) it always first arms PTO with more or less constant value of 2*SRTT. If the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and TLP becomes spurious. After a spurious TLP, RTO expires (maybe more than once before exponential back-off of RTO results in large enough value) and a new RTT sample is not received. So, SRTT remains unchanged and even if sometimes a new sample is received, SRTT gets very slowly adjusted. As a result, each TCP sender would keep on sending a spurious TLP for each new segment resulting in at least 50% of the packets being unnecessary rexmitted and the utilization of the bottleneck is < 50%. This would not be a full congestion collapse but has unwanted symptoms towards congestion collapse (Note: there is no clear line for the level of reduction in delivery of useful data is considered as congestion collapse). >> >> Additional notes: >> >> Sec 2.2: >> >> Example 2: >> "Lost retransmissions cause a resort to RTO recovery, since >> DUPACK-counting does not detect the loss of the retransmissions. >> Then the slow start after RTO recovery could cause burst losses >> again that severely degrades performance [POLICER16]." >> >> RTO reovery is done in slow start. The last sentence is confusing as >> there is no (new) slow-start after RTO recovery (or more precisely >> slow start continues until cwnd > ssthresh). Do you mean: if/when slow >> start still continues after RTO Recovery has repaired lost segments, >> it may cause burst losses again? > I mean the slow start after (the start of) RTO recovery. HTH Tnx. I'd appreciate if the text could be clarified to reflect this more accurately. Maybe something along the lines(?): "Then the RTO recovery in slow start could cause burst losses again that severely degrades performance [POLICER16]." >> >> Example 3: >> "If the reordering degree is beyond DupThresh, the DUPACK- >> counting can cause a spurious fast recovery and unnecessary >> congestion window reduction. To mitigate the issue, [RFC4653] >> adjusts DupThresh to half of the inflight size to tolerate the >> higher degree of reordering. However if more than half of the >> inflight is lost, then the sender has to resort to RTO recovery." >> >> This seems to be somewhat incorrect description of TCP-NCR specified in >> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending >> new data segments on DupAcks that makes it likely to avoid an RTO in >> the given example scenario, if not too many of the the new data >> segments triggered by Extended Limited Transmit are lost. > sorry I don't see how the text is wrong describing RFC4653, > specifically the algorithm in adjusting ssthresh To my understanding RFC4653 initializes DupThresh to half of the inflight size in the beginning of the Extended Limited Transmit. Then on each DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd worth of DupAcks are received before packet loss is declared (or reordering detected). So, if I am not incorrect, loss of a half of the inflight does not necessarily result in RTO recovery with TCP-NCR. >> >> Sec. 3.5: >> >> "For example, consider a simple case where one >> segment was sent with an RTO of 1 second, and then the application >> writes more data, causing a second and third segment to be sent right >> before the RTO of the first segment expires. Suppose only the first >> segment is lost. Without RACK, upon RTO expiration the sender marks >> all three segments as lost and retransmits the first segment. When >> the sender receives the ACK that selectively acknowledges the second >> segment, the sender spuriously retransmits the third segment." >> >> This seems incorrect. When the sender receives the ACK that selectively >> acknowledges the second segment, it is a DupAck as per RFC 6675 and does >> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the >> rexmit of the third segment is not allowad until the cumulative ACK of >> the first segment arrives. > I don't see where RFC6675 forbids growing cwnd. Even if it does, I > don't think it's a good thing (in RTO-slow-start) as DUPACK clearly > indicates a delivery has been made. SACKed sequences with DUpAcks indicate that those sequences were delivered but it does not tell when they were sent. The basic principle of slow start is to reliably determine the available network capacity during slow start. Therefore, slow start must ensure it uses only segments sent during the slow start to increase cwnd. Otherwise, a TCP sender may encounter exactly the problem of unnecessary retransmission envisioned in this example of RACK-TCP draft (and increase cwnd on not valid Acks). RFC 6675 does re-specify DupAck with SACK option but it does not include the rule for slow start. Slow start is specified in RFC 5681. It is crystal clear in allowing increase in cwnd only on cumulative Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, page 6: During slow start, a TCP increments cwnd by at most SMSS bytes for each ACK received that cumulatively acknowledges new data. Maybe this example in the RACK-TLP draft was inspired by a incorrect implementation of SACK-based loss recovery? FYI: when we were finalizing RFC 6675 I suggested including also an algorithm for RTO recovery with SACK in RFC 6675. The reason was exactly that it might be not easy to gather info from multiple documents and hence help the implementor to have all necessary advice in a single document. This unfortunately did not get realized though. BR, /Markku >> >> Best regards, >> >> /Markku >> >> >> >> On Mon, 16 Nov 2020, The IESG wrote: >> >>> >>> The IESG has received a request from the TCP Maintenance and Minor Extensions >>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection >>> algorithm for TCP' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits final >>> comments on this action. Please send substantive comments to the >>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the beginning >>> of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document presents the RACK-TLP loss detection algorithm for TCP. >>> RACK-TLP uses per-segment transmit timestamps and selective >>> acknowledgements (SACK) and has two parts: RACK ("Recent >>> ACKnowledgment") starts fast recovery quickly using time-based >>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") >>> leverages RACK and sends a probe packet to trigger ACK feedback to >>> avoid retransmission timeout (RTO) events. Compared to the widely >>> used DUPACK threshold approach, RACK-TLP detects losses more >>> efficiently when there are application-limited flights of data, lost >>> retransmissions, or data packet reordering events. It is intended to >>> be an alternative to the DUPACK threshold approach. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ >>> >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> > From nobody Mon Dec 7 09:47:57 2020 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 F20FB3A1623; Mon, 7 Dec 2020 09:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sPbWzrOCvw34; Mon, 7 Dec 2020 09:47:53 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (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 6F0C03A15D3; Mon, 7 Dec 2020 09:47:51 -0800 (PST) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kmKc0-0001vu-VE; Mon, 07 Dec 2020 18:47:48 +0100 Received: from telia-5908b1-169.connect.netcom.no ([89.8.177.169] helo=[100.66.112.168]) by mail-mx06.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kmKbv-0004mB-VG; Mon, 07 Dec 2020 18:47:48 +0100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Michael Welzl Mime-Version: 1.0 (1.0) Date: Mon, 7 Dec 2020 18:47:38 +0100 Message-Id: References: Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, last-call@ietf.org, tcpm-chairs In-Reply-To: To: Markku Kojo X-Mailer: iPhone Mail (18B92) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 89.8.177.169 is neither permitted nor denied by domain of ifi.uio.no) client-ip=89.8.177.169; envelope-from=michawe@ifi.uio.no; helo=[100.66.112.168]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.003, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D265FA69E246178AC6E759615CA4BC967A338B5A Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (The RACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 17:47:57 -0000 Hi all, thanks for this discussion, and Markku for this long email, I found it very i= nteresting to read. Sorry for top posting but: Sent from my iPhone :-) .... so, just a comment about the backoff upon a lost rexmit in recovery: I= =E2=80=98d say that halving again is the right thing to do as it=E2=80=98s c= ertainly in the spirit of the cong.avoid & control paper which, iirc, motiva= tes halving ssthresh with an exponential backoff. this just allows to truly b= ackoff exponentially instead of halving once, followed by cwnd=3D1. regarding how to do it because flightsize may be wrong: perhaps i=E2=80=98m m= issing something, i=E2=80=98m not writing this with rfcs and rack-tlp open o= n the side.... but: surely rack-tlp also still has the =E2=80=9Epipe=E2=80=9C= variable? wouldn=E2=80=98t cwnd =3D ssthresh =3D pipe / 2 be the right thi= ng to do? cheers, michael > On 7 Dec 2020, at 17:07, Markku Kojo wrote: >=20 > =EF=BB=BFHi Yuchung, >=20 > thanks for your reply. My major point is that IMHO this RACK-TLP specifica= tion should give the necessary advice w.r.t congestion control in cases when= such advice is not available in the RFC series or is not that easy to inter= preted correctly from the existing RFCs. >=20 > Even though the CC principles were available in RFC series I believe you a= gree with me that getting detailed CC actions correct is sometimes quite har= d, especially if one needs to interpret and apply them from another spec tha= n what one is implementing. Please see more details inline below. >=20 > In addition, we need to remember that this document is not meant only for T= CP experts following the tcpm list and having deep understanding of congesti= on control but also those implementing TCP, for the very first time, for var= ious appliances, for example. They do not have first hand experience in impl= ementing TCP congestion control and deserve clear advice what to do. >=20 >> On Fri, 4 Dec 2020, Yuchung Cheng wrote: >>=20 >>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: >>>=20 >>> Hi all, >>>=20 >>> I know this is a bit late but I didn't have time earlier to take look at= >>> this draft. >>>=20 >>> Given that this RFC to be is standards track and RECOMMENDED to replace >>> current DupAck-based loss detection, it is important that the spec is >>> clear on its advice to those implementing it. Current text seems to >>> lack important advice w.r.t congestion control, and even though >>> the spec tries to decouple loss detection from congestion control >>> and does not intend to modify existing standard congestion control >>> some of the examples advice incorrect congestion control actions. >>> Therefore, I think it is worth to correct the mistakes and take >>> yet another look at a few implications of this specification. >> As you noted, the intention is to decouple the two as much as possible >>=20 >> Unlike the 20 years ago where TCP loss detection and congestion >> control are essentially glued in one piece, the decoupling of the two >> (including modularizing congestion controls in implementations) has >> helped fueled many great inventions of new congestion controls. >> Codifying so-called-default C.C. reactions in the loss detection is a >> step backward that the authors try their best to avoid. >=20 > While I fully agree with the general principle of decoupling loss detectio= n from congestion control when it is possible without leaving open questions= , I find it hard to get congestion control right with this spec in certain c= ases I raised just by following the current standards track CC specification= s. The reason for this is that RACK-TLP introduces new ways to detect loss (= i.e., not present in any earlier standard track RFC) and the current CC spec= ifications do not provide correct CC actions for such cases as I try to poin= t out below. >=20 >> To keep the >> document less "abstract / unclear" as many WGLC reviewers commented, >> we use examples to illustrate that includes CC actions. But the >> details of these CC actions are likely to become obsolete as CC >> continues to advance hopefully. >=20 > Agreed. But I would appreciate if the CC actions in the examples would cor= rectly follow what is specified in the the current CC RFCs. And, I would sug= gest explicitly citing the RFC(s) that each of the examples is illustriating= so that there is no doubt which CC variant the example is valid with. Then t= here is no problem with the correctness of the example either even if the ci= ted RFC becomes later obsoleted. >=20 >>>=20 >>> Sec. 3.4 (and elsewhere when discussing recovering a dropped >>> retransmission): >>>=20 >>> It is very useful that RACK-TLP allows for recovering dropped rexmits. >>> However, it seems that the spec ignores the fact that loss of a >>> retransmission is a loss in a successive window that requires reacting >>> to congestion twice as per RFC 5681. This advice must be included in >>> the specification because with RACK-TLP recovery of dropped rexmit >>> takes place during the fast recovery which is very different >>> from the other standard algorithms and therefore easy to miss >>> when implementing this spec. >>=20 >> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 >> "Loss in two successive windows of data, or the loss of a >> retransmission, should be taken as two indications of congestion and, >> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." >>=20 >> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on >> this so I am not sure what clause you suggest to add to RACK-TLP. >=20 > Right, this is the CC *principle* in RFC 5681 I am refering to but I am af= raid it is not enough to help one to correctly implement such lowering of cw= nd (and ssthresh) twice when a loss of a retransmission is detected during Fa= st Recovery. Nor do RFCs clearly advice *when* this reduction must take plac= e. >=20 > Congestion control principles tell us that congestion must be reacted imme= diately when detected. But at the same time, standards track CC specificatio= ns react to congestion only once during Fast Recovery because the losses in t= he current window, which Fast Recovery repairs, occured during the same RTT.= That is, the current CC specifications do not handle lost rexmits during Fa= st Recovery but, instead, the correct CC reaction to a loss of a rexmit is a= utomatically achieved by those specifications via RTO when cwnd is explicitl= y reset upon RTO. >=20 > Furthermore, the problem I am trying to point out is that there is no corr= ect rule/formula available in the standards track RFCs that would give the c= orrect way to reduce cwnd when the loss of rexmit is detected with RACK-TLP.= >=20 > I suggest everyone reading this message stops reading at this point for a w= hile before continuing reading and figures out themselves what they think wo= uld be the correct equation to use in the standards RFC series to find the n= ew halved value for cwnd when RACK-TLP detects a loss of a rexmit during Fas= t Recovery. I would appreciate a comment on the tcpm list from those who thi= nk they found the correct answer immediately and easily, and what was the fo= rmula to use. >=20 > ... >=20 > I think the best advice one may find by looking at RFC 6675 (and RFC 5681)= is to set >=20 > ssthresh =3D cwnd =3D (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.= 2) >=20 > Now, let's modify the example in Sec 3.4 of the draft: >=20 > 1. Send P0, P1, P2, ..., P20 > [Assume P1, ..., P20 dropped by network] >=20 > 2. Receive P0, ACK P0 > 3a. 2RTTs after (2), TLP timer fires > 3b. TLP: retransmits P20 > ... > 5a. Receive SACK for P20 > 5b. RACK: marks P1, ..., P20 lost > set cwnd=3Dssthresh=3DFlightSize/2=3D10 > 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > [P1 retransmission dropped by network] >=20 > Receive SACK P2 & P3 7a. RACK: marks P1 retransmission lost > As per RFC 6675: set cwnd=3Dssthresh=3DFlightSize/2=3D20/2=3D10 > 7b. Retransmit P1 > ... >=20 > So, is the new value of the cwnd (10MSS) correct and halved twice? If not,= where is the correct formula to do it? >=20 > Before RFC 5681 was published we had a discussion on FlighSize and that du= ring Fast Recovery it does not reflect the amount of segments in flight corr= ectly but may also have a too large value. It was decided not to try to corr= ect it because it only has an impact when RTO fires during Fast Recovery and= in such a case cwnd is reset to 1 MSS. Having too large ssthresh for RTO re= covery in some cases was not considered that bad because a TCP sender anyway= takes to most conservative CC action with the cwnd and would slow start fro= m cwnd =3D 1 MSS. But now when RACK-TLP enables detecting loss of a rexmit d= uring Fast Recovery we have an unresolved problem. >=20 >=20 >>> Sec 9.3: >>>=20 >>> In Section 9.3 it is stated that the only modification to the existing >>> congestion control algorithms is that one outstanding loss probe >>> can be sent even if the congestion window is fully used. This is >>> fine, but the spec lacks the advice that if a new data segment is sent >>> this extra segment MUST NOT be included when calculating the new value >>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an >>> extra segment not allowed by cwnd, so it must be excluded from >>> FlightSize, if the TLP probe detects loss or if there is no ack >>> and RTO is needed to trigger loss recovery. >>=20 >> Why exclude TLP (or any data) from FlightSize? The congestion control >> needs precise accounting of the flight size to react to congestion >> properly. >=20 > Because FlightSize does not always reflect the correct amount of data allo= wed by cwnd. When a TCP sender is not already in loss recovery and it detect= s loss, this loss indicates the congestion point for the TCP sender, i.e., h= ow much data it can have outstanding. It is this amount of data that it must= use in calculating the new value of cwnd (and ssthresh), so it must not inc= lude any data sent beyond the congestion point. When TLP sends a new data se= gment, it is beyond the congestion point and must not be included. Same hold= s for the segments sent via Limited Transmit: they are allowed to be send ou= t by the packet conservation rule (DupAck indicates a pkt has left the netwo= rk, but does not allow increasing cwnd), i.e., the actual amount of data in f= light remains the same. >=20 >>> In these cases the temporary over-commit is not accounted for as DupAck >>> does not decrease FlightSize and in case of an RTO the next ACK comes to= o >>> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibit= s >>> including the segments transmitted via Limitid Transmit in the >>> calculation of ssthresh. >>>=20 >>> In Section 9.3 a few example scenarios are used to illustriate the >>> intended operation of RACK-TLP. >>>=20 >>> In the first example a sender has a congestion window (cwnd) of 20 >>> segments on a SACK-enabled connection. It sends 10 data segments >>> and all of them are lost. >>>=20 >>> The text claims that without RACK-TLP the ending cwnd would be 4 segment= s >>> due to congestion window validation. This is incorrect. >>> As per RFC 7661 the sender MUST exit the non-validated phase upon an >>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if= >>> the TCP sender uses the equation (4) of RFC 5681). >>>=20 >>> The operation with RACK-TLP would inevitably result in congestion >>> collapse if RACK-TLP behaves as described in the example because >>> it restores the previous cwnd of 10 segments after the fast recovery >>> and would not react to congestion at all! I think this is not the >>> intended behavior by this spec but a mistake in the example. >>> The ssthresh calculated in the beginning of loss recovery should >>> be 5 segments as per RFC 6675 (and RFC 5681). >> To clarify, would this text look more clear? >>=20 >> 'an ending cwnd set to the slow start threshold of 5 segments (half of >> the original congestion window of 10 segments)' >=20 > This is correct, but please replace: >=20 > (half of the original congestion window of 10 segments) > --> > (half of> the original FlightSize of 10 segments) >=20 > cwnd in the example was 20 segments. >=20 > Please also correct the ending cwnd for "without RACK" scenario. > I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, m= y apologies. It MAENT equation (3) AND that results in ending cwnd of 5 and 2= /5 MSS (not 5 and 1/2 MSS). > NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then e= nding cwnd would be 6 and 1/6 MSS). >=20 >>>=20 >>> Furthermore, it seems that this example with RACK-TLP refers to using >>> PRR_SSRB which effectively implements regular slow start in this >>> case(?). =46rom congestion control point of view this is correct because= >>> the entire flight of data as well as ack clock was lost. >>>=20 >>> However, as correctly discussed in Sec 2, congestion window must be rese= t >>> to 1 MSS when an entire flight of data is and Ack clock is lost. But how= >>> can an implementor know what to do if she/he is not implementing the >>> experimental PRR algrorithm? This spec articulates specifying an >>> alternative for DupAck counting, indicating that TLP is used to trigger >>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start.= >>> This means that without an additional advise an implementation of this >>> spec would just halve the cwnd and ssthresh and send a potentially very >>> large burst of segments in the beginning of the Fast Recovery because >>> there is no ack clock. So, this spec begs for an advise (MUST) when to >>> slow start and reset cwnd and when not, or at least a discussion of >>> this problem and some sort of advise what to do and what to avoid. >>> And, maybe a recommendation to implement it with PRR? >>=20 >> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst >> control (when to slow-start). The use of PRR is just an example to >> illustrate and not meant for a recommendation. >=20 > I understand the use of PRR was just an example, but my point is that if o= ne wants to implement RACK-TLP but does not intend to implement PRR but RFC 6= 675 then we do not have a rule in RFC 6675 to correctly implement CC for the= case when an entire flight is lost and loss is detected with TLP. Congestio= n control principle for this is clear and also stated in this draft but IMHO= it is not enough to ensure correct implementation. >=20 > To my understanding we only have implementation experience for RACK-TLP on= ly togerher with PRR, which has the necessary rule to handle this kind of sc= enario correctly. >=20 > So, my question is how can one implement CC correctly without PRR such a s= cenario where entire inflight is lost? > Which rule and where in the RFC series gives the necessary guidance to res= et cwnd and slow start when TCP detets loss of an entire flight? >=20 >> Section 3 has a lengthy section to elaborate the key point of RACK-TLP >> is to maximize the chance of fast recovery. How C.C. governs the >> transmission dynamics after losses are detected are out of scope of >> this document in our authors' opinions. >>=20 >>=20 >>>=20 >>> Another question relates to the use of TLP and adjusting timer(s) upon >>> timeout. In the same example discussed above, it is clear that PTO >>> that fires TLP is just a more aggressive retransmit timer with >>> an alternative data segment to (re)transmit. >>>=20 >>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in= >>> effect a retransmission timout and the timer(s) must be backed-off. >>> This is not adviced in this specification. Whether it is the TCP RTO >>> or PTO that should be backed-off is an open question. Otherwise, >>> if the congestion is persistent and further transmission are also lost, >>> RACK-TLP would not react to congestion properly but would keep >>> retransmitting with "constant" timer value because new RTT estimate >>> cannot be obtained. >>> On a buffer bloated and heavily congested bottleneck this would easily >>> result in sending at least one unnecessary retransmission per one >>> delivered segment which is not advisable (e.g., when there are a huge >>> number of applications sharing a constrained bottleneck and these >>> applications are sending only one (or a few) segments and then >>> waiting for an reply from the peer before sending another request). >>=20 >> Thanks for pointing to the RFC. After TLP, RTO timers will >> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 >> (didn't find 9.1 relevant). >=20 > My apologies for refering to the wrong section of RFC 2914, Yes, I meant S= ec 9.3. >=20 >> In your scenario, you presuppose the >> retransmission is unnecessary so obviously TLP is not good. Consider >> what happens without TLP where all the senders fire RTO spuriously and >> blow up the network. It is equally unfortunate behavior. "bdp >> insufficient of many flows" is a congestion control problem >=20 > If (without TLP) RTO is spurious, it may result in unnecessary retransmiss= ions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to detect and resolv= e it without TLP, so I don't find it as a problem. >=20 > To clarify more, what I am concerned about. Think about a scenario where a= (narrow) bottleneck becomes heavily congested by a huge number of competing= senders such that the available capacity per sender is less than 1 segment (= or << 1 MSS). > This is a situation that network first enters before congestion collapse g= ets realized. So, it is extremely important that all CC and timer mechanisms= handle it properly. Regular TCP handles it via RFC 6298 by backing off RTO e= xpotentially and keeping this backed-off RTO until an new ACK is received fo= r new data. This saves RACK-TLP from full congestion collapse. But consider w= hat happens: even though RTO is backed off, each time a TCP sender manages t= o get one segment through (with cwnd =3D 1 MSS) it always first arms PTO wit= h more or less constant value of 2*SRTT. If the bottleneck is buffer bloated= the actual RTT easily exceeds 2*SRTT and TLP becomes spurious. After a spur= ious TLP, RTO expires (maybe more than once before exponential back-off of R= TO results in large enough value) and a new RTT sample is not received. So, S= RTT remains unchanged and even if sometimes a new sample is received, SRTT g= ets very slowly adjusted. As a result, each TCP sender would keep on sending= a spurious TLP for each new segment resulting in at least 50% of the packet= s being unnecessary rexmitted and the utilization of the bottleneck is < 50%= . This would not be a full congestion collapse but has unwanted symptoms tow= ards congestion collapse (Note: there is no clear line for the level of redu= ction in delivery of useful data is considered as congestion collapse). >=20 >=20 >>>=20 >>> Additional notes: >>>=20 >>> Sec 2.2: >>>=20 >>> Example 2: >>> "Lost retransmissions cause a resort to RTO recovery, since >>> DUPACK-counting does not detect the loss of the retransmissions. >>> Then the slow start after RTO recovery could cause burst losses >>> again that severely degrades performance [POLICER16]." >>>=20 >>> RTO reovery is done in slow start. The last sentence is confusing as >>> there is no (new) slow-start after RTO recovery (or more precisely >>> slow start continues until cwnd > ssthresh). Do you mean: if/when slow >>> start still continues after RTO Recovery has repaired lost segments, >>> it may cause burst losses again? >> I mean the slow start after (the start of) RTO recovery. HTH >=20 > Tnx. I'd appreciate if the text could be clarified to reflect this more ac= curately. Maybe something along the lines(?): >=20 > "Then the RTO recovery in slow start could cause burst > losses again that severely degrades performance [POLICER16]." >=20 >>>=20 >>> Example 3: >>> "If the reordering degree is beyond DupThresh, the DUPACK- >>> counting can cause a spurious fast recovery and unnecessary >>> congestion window reduction. To mitigate the issue, [RFC4653] >>> adjusts DupThresh to half of the inflight size to tolerate the >>> higher degree of reordering. However if more than half of the >>> inflight is lost, then the sender has to resort to RTO recovery." >>>=20 >>> This seems to be somewhat incorrect description of TCP-NCR specified in >>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending >>> new data segments on DupAcks that makes it likely to avoid an RTO in >>> the given example scenario, if not too many of the the new data >>> segments triggered by Extended Limited Transmit are lost. >> sorry I don't see how the text is wrong describing RFC4653, >> specifically the algorithm in adjusting ssthresh >=20 > To my understanding RFC4653 initializes DupThresh to half of the inflight s= ize in the beginning of the Extended Limited Transmit. Then on each DupAck i= t adjusts (recalculates) DupThresh again such that ideally a cwnd worth of D= upAcks are received before packet loss is declared (or reordering detected).= So, if I am not incorrect, loss of a half of the inflight does not necessar= ily result in RTO recovery with TCP-NCR. >=20 >>>=20 >>> Sec. 3.5: >>>=20 >>> "For example, consider a simple case where one >>> segment was sent with an RTO of 1 second, and then the application >>> writes more data, causing a second and third segment to be sent right >>> before the RTO of the first segment expires. Suppose only the first >>> segment is lost. Without RACK, upon RTO expiration the sender marks >>> all three segments as lost and retransmits the first segment. When >>> the sender receives the ACK that selectively acknowledges the second >>> segment, the sender spuriously retransmits the third segment." >>>=20 >>> This seems incorrect. When the sender receives the ACK that selectively >>> acknowledges the second segment, it is a DupAck as per RFC 6675 and does= >>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the >>> rexmit of the third segment is not allowad until the cumulative ACK of >>> the first segment arrives. >> I don't see where RFC6675 forbids growing cwnd. Even if it does, I >> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly >> indicates a delivery has been made. >=20 > SACKed sequences with DUpAcks indicate that those sequences were delivered= but it does not tell when they were sent. The basic principle of slow start= is to reliably determine the available network capacity during slow start. T= herefore, slow start must ensure it uses only segments sent during the slow s= tart to increase cwnd. Otherwise, a TCP sender may encounter exactly the pro= blem of unnecessary retransmission envisioned in this example of RACK-TCP dr= aft (and increase cwnd on not valid Acks). >=20 > RFC 6675 does re-specify DupAck with SACK option but it does not include t= he rule for slow start. Slow start is specified in RFC 5681. It is crystal c= lear in allowing increase in cwnd only on cumulative Acks, i.e., forbidding t= o increase cwnd on DupAcks (RFC 5681, Sec 3, > page 6: >=20 > During slow start, a TCP increments cwnd by at most SMSS bytes for > each ACK received that cumulatively acknowledges new data. >=20 > Maybe this example in the RACK-TLP draft was inspired by a incorrect imple= mentation of SACK-based loss recovery? >=20 > FYI: when we were finalizing RFC 6675 I suggested including also an algori= thm for RTO recovery with SACK in RFC 6675. The reason was exactly that it m= ight be not easy to gather info from multiple documents and hence help the i= mplementor to have all necessary advice in a single document. This unfortuna= tely did not get realized though. >=20 > BR, >=20 > /Markku >=20 >>>=20 >>> Best regards, >>>=20 >>> /Markku >>>=20 >>>=20 >>>=20 >>>> On Mon, 16 Nov 2020, The IESG wrote: >>>=20 >>>>=20 >>>> The IESG has received a request from the TCP Maintenance and Minor Exte= nsions >>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss dete= ction >>>> algorithm for TCP' >>>> as Proposed Standard >>>>=20 >>>> The IESG plans to make a decision in the next few weeks, and solicits f= inal >>>> comments on this action. Please send substantive comments to the >>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments= may >>>> be sent to iesg@ietf.org instead. In either case, please retain the beg= inning >>>> of the Subject line to allow automated sorting. >>>>=20 >>>> Abstract >>>>=20 >>>>=20 >>>> This document presents the RACK-TLP loss detection algorithm for TCP. >>>> RACK-TLP uses per-segment transmit timestamps and selective >>>> acknowledgements (SACK) and has two parts: RACK ("Recent >>>> ACKnowledgment") starts fast recovery quickly using time-based >>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") >>>> leverages RACK and sends a probe packet to trigger ACK feedback to >>>> avoid retransmission timeout (RTO) events. Compared to the widely >>>> used DUPACK threshold approach, RACK-TLP detects losses more >>>> efficiently when there are application-limited flights of data, lost >>>> retransmissions, or data packet reordering events. It is intended to >>>> be an alternative to the DUPACK threshold approach. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The file can be obtained via >>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ >>>>=20 >>>>=20 >>>>=20 >>>> No IPR declarations have been submitted directly on this I-D. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>=20 >>=20 >=20 > --=20 > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call From nobody Mon Dec 7 12:10:11 2020 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 6CB403A08E5 for ; Mon, 7 Dec 2020 12:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 xvGb_VEwI5_o for ; Mon, 7 Dec 2020 12:10:03 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 1C02D3A089A for ; Mon, 7 Dec 2020 12:10:03 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id v14so370389wml.1 for ; Mon, 07 Dec 2020 12:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a7CBnm8H4KDWw0IaAK1Cbi4FbmjrzdkD0TozRLhhe0g=; b=XA7zZo2C24FOLo24YcNv/R7RV845Jz0knzzRcnDvsa1r4tlLAB6ZYNbNcFg5gC1LkF w/idzFPO+0hiMz5MKHou+Fkatu/eKQ2Xx+4W9DJg2XwTnew1FS3m0ZdfFvpSxqd6HX1T JYdU99B1mUYTrPi1mF4wFiDIUkOfCkkuT69Ic3ZlsB7L256l67fNTO2mqPLJkCUC8/O3 hS1bIl9KaoYwCpIP4qBV/FaYchbIVh6+cnlRSxqyf0UfwdmFJPojOh1n1nOkNXZrac6U HQmkzufmsBr1HHsNboFux6pB1dl3LOWW2C0xQcjyx9hG0Goh7CBkhHESv8OUkURZSYuh CzSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a7CBnm8H4KDWw0IaAK1Cbi4FbmjrzdkD0TozRLhhe0g=; b=gS08qAtvbZ/3LmvuHNIcy45ZXXR+s4mwa2CqO7dYxX28YV+Gyz8m/gJ3/TuQcrs2+d HG4Tn4hsktmJ2yIjpY5R29pZtMPlDGxq5655wA/hnBZqSqtYngenWW4p9C+HsiBdVCBK PshIAkuwn60bh5vR922C36Y7qqzTyr96Cy0TwlEL2RQZhXUrLVlR3KaZc9XqchdwJmqs DoUoo1gS7yX1/DUveNviJNYK9xDs7+EY2BFE9CmXyskcq3gefqBTdJvkU2+ug7XxQZGy /NVJ0Zfskh5mUeq8rY9BvfLMknpJygqtNlb5S6FYu1q4OU60iy/Vw7Dw/uHcAovfGlKf CuVg== X-Gm-Message-State: AOAM531ue6x8p1FLfES9j+5UggDmfT52uNAFBDq9zP1/Um3cgBMnCwPm 8+Q+K5oJQBBIXHDKy/5/bG8iDwD1EdvJZhEnkdtT1A== X-Google-Smtp-Source: ABdhPJzJYU/to08mDjsSI6Z3EsJ5i+MyLhwKps+90YVEuoIw4v7W/yF8Y9AMzyTBCHM7pz7Zs6aFIfa3w7ZVdtkzjx0= X-Received: by 2002:a1c:804a:: with SMTP id b71mr525845wmd.21.1607371800625; Mon, 07 Dec 2020 12:10:00 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Yuchung Cheng Date: Mon, 7 Dec 2020 12:09:23 -0800 Message-ID: To: Markku Kojo Cc: last-call@ietf.org, "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Last Call: (The RACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 20:10:06 -0000 On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo wrote: > > Hi Yuchung, > > thanks for your reply. My major point is that IMHO this RACK-TLP > specification should give the necessary advice w.r.t congestion control > in cases when such advice is not available in the RFC series or is not > that easy to interpreted correctly from the existing RFCs. > > Even though the CC principles were available in RFC series I believe you > agree with me that getting detailed CC actions correct is sometimes quite > hard, especially if one needs to interpret and apply them from another > spec than what one is implementing. Please see more details inline below. > > In addition, we need to remember that this document is not meant only for > TCP experts following the tcpm list and having deep understanding of > congestion control but also those implementing TCP, for the very first > time, for various appliances, for example. They do not have first hand > experience in implementing TCP congestion control and deserve clear > advice what to do. > > On Fri, 4 Dec 2020, Yuchung Cheng wrote: > > > On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: > >> > >> Hi all, > >> > >> I know this is a bit late but I didn't have time earlier to take look at > >> this draft. > >> > >> Given that this RFC to be is standards track and RECOMMENDED to replace > >> current DupAck-based loss detection, it is important that the spec is > >> clear on its advice to those implementing it. Current text seems to > >> lack important advice w.r.t congestion control, and even though > >> the spec tries to decouple loss detection from congestion control > >> and does not intend to modify existing standard congestion control > >> some of the examples advice incorrect congestion control actions. > >> Therefore, I think it is worth to correct the mistakes and take > >> yet another look at a few implications of this specification. > > As you noted, the intention is to decouple the two as much as possible > > > > Unlike the 20 years ago where TCP loss detection and congestion > > control are essentially glued in one piece, the decoupling of the two > > (including modularizing congestion controls in implementations) has > > helped fueled many great inventions of new congestion controls. > > Codifying so-called-default C.C. reactions in the loss detection is a > > step backward that the authors try their best to avoid. > > While I fully agree with the general principle of decoupling loss > detection from congestion control when it is possible without leaving > open questions, I find it hard to get congestion control right with this > spec in certain cases I raised just by following the current standards > track CC specifications. The reason for this is that RACK-TLP introduces > new ways to detect loss (i.e., not present in any earlier standard track > RFC) and the current CC specifications do not provide correct CC actions > for such cases as I try to point out below. > > > To keep the > > document less "abstract / unclear" as many WGLC reviewers commented, > > we use examples to illustrate that includes CC actions. But the > > details of these CC actions are likely to become obsolete as CC > > continues to advance hopefully. > > Agreed. But I would appreciate if the CC actions in the examples would > correctly follow what is specified in the the current CC RFCs. And, I > would suggest explicitly citing the RFC(s) that each of the examples is > illustriating so that there is no doubt which CC variant the example > is valid with. Then there is no problem with the correctness of the > example either even if the cited RFC becomes later obsoleted. > > >> > >> Sec. 3.4 (and elsewhere when discussing recovering a dropped > >> retransmission): > >> > >> It is very useful that RACK-TLP allows for recovering dropped rexmits. > >> However, it seems that the spec ignores the fact that loss of a > >> retransmission is a loss in a successive window that requires reacting > >> to congestion twice as per RFC 5681. This advice must be included in > >> the specification because with RACK-TLP recovery of dropped rexmit > >> takes place during the fast recovery which is very different > >> from the other standard algorithms and therefore easy to miss > >> when implementing this spec. > > > > per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 > > "Loss in two successive windows of data, or the loss of a > > retransmission, should be taken as two indications of congestion and, > > therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > > > > RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on > > this so I am not sure what clause you suggest to add to RACK-TLP. > > Right, this is the CC *principle* in RFC 5681 I am refering to but I am > afraid it is not enough to help one to correctly implement such lowering > of cwnd (and ssthresh) twice when a loss of a retransmission is detected > during Fast Recovery. Nor do RFCs clearly advice *when* this reduction > must take place. > > Congestion control principles tell us that congestion must be reacted > immediately when detected. But at the same time, standards track CC > specifications react to congestion only once during Fast Recovery > because the losses in the current window, which Fast Recovery repairs, > occured during the same RTT. That is, the current CC specifications do > not handle lost rexmits during Fast Recovery but, instead, the correct CC > reaction to a loss of a rexmit is automatically achieved by those > specifications via RTO when cwnd is explicitly reset upon RTO. > > Furthermore, the problem I am trying to point out is that there is no > correct rule/formula available in the standards track RFCs that would > give the correct way to reduce cwnd when the loss of rexmit is detected > with RACK-TLP. > > I suggest everyone reading this message stops reading at this point > for a while before continuing reading and figures out themselves what > they think would be the correct equation to use in the standards RFC > series to find the new halved value for cwnd when RACK-TLP detects a loss > of a rexmit during Fast Recovery. I would appreciate a comment on the > tcpm list from those who think they found the correct answer immediately > and easily, and what was the formula to use. > > ... > > I think the best advice one may find by looking at RFC 6675 (and RFC > 5681) is to set > > ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.2) > > Now, let's modify the example in Sec 3.4 of the draft: > > 1. Send P0, P1, P2, ..., P20 > [Assume P1, ..., P20 dropped by network] > > 2. Receive P0, ACK P0 > 3a. 2RTTs after (2), TLP timer fires > 3b. TLP: retransmits P20 > ... > 5a. Receive SACK for P20 > 5b. RACK: marks P1, ..., P20 lost > set cwnd=ssthresh=FlightSize/2=10 > 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > [P1 retransmission dropped by network] > > Receive SACK P2 & P3 > 7a. RACK: marks P1 retransmission lost > As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > 7b. Retransmit P1 > ... > > So, is the new value of the cwnd (10MSS) correct and halved twice? If not, > where is the correct formula to do it? > > Before RFC 5681 was published we had a discussion on FlighSize and that > during Fast Recovery it does not reflect the amount of segments in > flight correctly but may also have a too large value. It was decided not > to try to correct it because it only has an impact when RTO fires during > Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too large > ssthresh for RTO recovery in some cases was not considered that bad > because a TCP sender anyway takes to most conservative CC action with the > cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP enables > detecting loss of a rexmit during Fast Recovery we have an unresolved > problem. > 1. Send P0, P1, P2, ..., P20 > [Assume P1, ..., P20 dropped by network] > > 2. Receive P0, ACK P0 > 3a. 2RTTs after (2), TLP timer fires > 3b. TLP: retransmits P20 > ... > 5a. Receive SACK for P20 > 5b. RACK: marks P1, ..., P20 lost > set cwnd=ssthresh=FlightSize/2=10 > 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > [P1 retransmission dropped by network] > > Receive SACK P2 & P3 > 7a. RACK: marks P1 retransmission lost > As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > 7b. Retransmit P1 To account for your points, IMO clearly stating the existing CC RFC interactions w/o mandating any C.C. actions are the best way to move forward. Here are the text diff I proposed: "Figure 1, above, illustrates ... Notice a subtle interaction with existing congestion control actions on event 7a. It essentially starts another new episode of congestion due to the detection of lost retransmission. Per RFC5681 (section 4.3) that loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion as a principle. But RFC6675 that introduces the pipe concept does not specify such a second window reduction. This document reminds RACK-TLP implementation to carefully consider the new multiple congestion episode cases in the corresponding congestion control." and to emphasize in section 9.3 Interaction with congestion control "9.3. Interaction with congestion control RACK-TLP intentionally decouples loss detection ... this appropriate. As mentioned in Figure 1 caption, RFC5681 mandates a principle that Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion, and therefore reacted separately. However implementation of RFC6675 pipe algorithm may not directly account for this newly detected congestion events properly. Therefore the documents reminds RACK-TLP implementation to carefully consider these implications in its corresponding congestion control. ..." > > > >> Sec 9.3: > >> > >> In Section 9.3 it is stated that the only modification to the existing > >> congestion control algorithms is that one outstanding loss probe > >> can be sent even if the congestion window is fully used. This is > >> fine, but the spec lacks the advice that if a new data segment is sent > >> this extra segment MUST NOT be included when calculating the new value > >> of ssthresh as per the equation (4) of RFC 5681. Such segment is an > >> extra segment not allowed by cwnd, so it must be excluded from > >> FlightSize, if the TLP probe detects loss or if there is no ack > >> and RTO is needed to trigger loss recovery. > > > > Why exclude TLP (or any data) from FlightSize? The congestion control > > needs precise accounting of the flight size to react to congestion > > properly. > > Because FlightSize does not always reflect the correct amount of data > allowed by cwnd. When a TCP sender is not already in loss recovery and > it detects loss, this loss indicates the congestion point for the TCP > sender, i.e., how much data it can have outstanding. It is this amount of > data that it must use in calculating the new value of cwnd (and > ssthresh), so it must not include any data sent beyond the congestion > point. When TLP sends a new data segment, it is beyond the congestion > point and must not be included. Same holds for the segments sent via > Limited Transmit: they are allowed to be send out by the packet > conservation rule (DupAck indicates a pkt has left the network, but does > not allow increasing cwnd), i.e., the actual amount of data in flight > remains the same. > > >> In these cases the temporary over-commit is not accounted for as DupAck > >> does not decrease FlightSize and in case of an RTO the next ACK comes too > >> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits > >> including the segments transmitted via Limitid Transmit in the > >> calculation of ssthresh. > >> > >> In Section 9.3 a few example scenarios are used to illustriate the > >> intended operation of RACK-TLP. > >> > >> In the first example a sender has a congestion window (cwnd) of 20 > >> segments on a SACK-enabled connection. It sends 10 data segments > >> and all of them are lost. > >> > >> The text claims that without RACK-TLP the ending cwnd would be 4 segments > >> due to congestion window validation. This is incorrect. > >> As per RFC 7661 the sender MUST exit the non-validated phase upon an > >> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if > >> the TCP sender uses the equation (4) of RFC 5681). > >> > >> The operation with RACK-TLP would inevitably result in congestion > >> collapse if RACK-TLP behaves as described in the example because > >> it restores the previous cwnd of 10 segments after the fast recovery > >> and would not react to congestion at all! I think this is not the > >> intended behavior by this spec but a mistake in the example. > >> The ssthresh calculated in the beginning of loss recovery should > >> be 5 segments as per RFC 6675 (and RFC 5681). > > To clarify, would this text look more clear? > > > > 'an ending cwnd set to the slow start threshold of 5 segments (half of > > the original congestion window of 10 segments)' > > This is correct, but please replace: > > (half of the original congestion window of 10 segments) > --> > (half of> the original FlightSize of 10 segments) sure will do > > cwnd in the example was 20 segments. > > Please also correct the ending cwnd for "without RACK" scenario. > I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, > my apologies. It MAENT equation (3) AND that results in ending cwnd of 5 > and 2/5 MSS (not 5 and 1/2 MSS). > NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then > ending cwnd would be 6 and 1/6 MSS). > > >> > >> Furthermore, it seems that this example with RACK-TLP refers to using > >> PRR_SSRB which effectively implements regular slow start in this > >> case(?). From congestion control point of view this is correct because > >> the entire flight of data as well as ack clock was lost. > >> > >> However, as correctly discussed in Sec 2, congestion window must be reset > >> to 1 MSS when an entire flight of data is and Ack clock is lost. But how > >> can an implementor know what to do if she/he is not implementing the > >> experimental PRR algrorithm? This spec articulates specifying an > >> alternative for DupAck counting, indicating that TLP is used to trigger > >> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. > >> This means that without an additional advise an implementation of this > >> spec would just halve the cwnd and ssthresh and send a potentially very > >> large burst of segments in the beginning of the Fast Recovery because > >> there is no ack clock. So, this spec begs for an advise (MUST) when to > >> slow start and reset cwnd and when not, or at least a discussion of > >> this problem and some sort of advise what to do and what to avoid. > >> And, maybe a recommendation to implement it with PRR? > > > > It's wise to decouple loss detection (RACK-TLP) vs congestion/burst > > control (when to slow-start). The use of PRR is just an example to > > illustrate and not meant for a recommendation. > > I understand the use of PRR was just an example, but my point is that if > one wants to implement RACK-TLP but does not intend to implement PRR but > RFC 6675 then we do not have a rule in RFC 6675 to correctly implement > CC for the case when an entire flight is lost and loss is detected with > TLP. Congestion control principle for this is clear and also stated in > this draft but IMHO it is not enough to ensure correct implementation. > > To my understanding we only have implementation experience for RACK-TLP > only togerher with PRR, which has the necessary rule to handle this kind > of scenario correctly. > > So, my question is how can one implement CC correctly without PRR such > a scenario where entire inflight is lost? > Which rule and where in the RFC series gives the necessary guidance to > reset cwnd and slow start when TCP detets loss of an entire flight? I think we're going in loops. To move forward it'd help if you suggest some text you like to change. > > > Section 3 has a lengthy section to elaborate the key point of RACK-TLP > > is to maximize the chance of fast recovery. How C.C. governs the > > transmission dynamics after losses are detected are out of scope of > > this document in our authors' opinions. > > > > > >> > >> Another question relates to the use of TLP and adjusting timer(s) upon > >> timeout. In the same example discussed above, it is clear that PTO > >> that fires TLP is just a more aggressive retransmit timer with > >> an alternative data segment to (re)transmit. > >> > >> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in > >> effect a retransmission timout and the timer(s) must be backed-off. > >> This is not adviced in this specification. Whether it is the TCP RTO > >> or PTO that should be backed-off is an open question. Otherwise, > >> if the congestion is persistent and further transmission are also lost, > >> RACK-TLP would not react to congestion properly but would keep > >> retransmitting with "constant" timer value because new RTT estimate > >> cannot be obtained. > >> On a buffer bloated and heavily congested bottleneck this would easily > >> result in sending at least one unnecessary retransmission per one > >> delivered segment which is not advisable (e.g., when there are a huge > >> number of applications sharing a constrained bottleneck and these > >> applications are sending only one (or a few) segments and then > >> waiting for an reply from the peer before sending another request). > > > > Thanks for pointing to the RFC. After TLP, RTO timers will > > exp-backoff (as usual) for stability reasons mentioned in sec 9.3 > > (didn't find 9.1 relevant). > > My apologies for refering to the wrong section of RFC 2914, Yes, I meant > Sec 9.3. > > > In your scenario, you presuppose the > > retransmission is unnecessary so obviously TLP is not good. Consider > > what happens without TLP where all the senders fire RTO spuriously and > > blow up the network. It is equally unfortunate behavior. "bdp > > insufficient of many flows" is a congestion control problem > > If (without TLP) RTO is spurious, it may result in unnecessary > retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to > detect and resolve it without TLP, so I don't find it as a problem. > > To clarify more, what I am concerned about. Think about a scenario where a > (narrow) bottleneck becomes heavily congested by a huge number of > competing senders such that the available capacity per sender is less > than 1 segment (or << 1 MSS). > This is a situation that network first enters before congestion collapse > gets realized. So, it is extremely important that all CC and timer > mechanisms handle it properly. Regular TCP handles it via RFC 6298 by > backing off RTO expotentially and keeping this backed-off RTO until an > new ACK is received for new data. This saves RACK-TLP from full congestion > collapse. But consider what happens: even though RTO is backed off, each > time a TCP sender manages to get one segment through (with cwnd = 1 MSS) > it always first arms PTO with more or less constant value of 2*SRTT. If > the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and > TLP becomes spurious. After a spurious TLP, RTO expires (maybe more than > once before exponential back-off of RTO results in large enough value) > and a new RTT sample is not received. So, SRTT remains unchanged and even > if sometimes a new sample is received, SRTT gets very slowly adjusted. As > a result, each TCP sender would keep on sending a spurious TLP for each > new segment resulting in at least 50% of the packets being unnecessary > rexmitted and the utilization of the bottleneck is < 50%. This would not > be a full congestion collapse but has unwanted symptoms towards > congestion collapse (Note: there is no clear line for the level of > reduction in delivery of useful data is considered as congestion > collapse). AFAIK you are saying: under extreme congestion shared by many short flows, RACK-TLP can cause more packet losses because of the more aggressive PTO timer. I agree and can add this to the "section 9.3". What authors disagree is that RTO must be back-off on the first instance if TLP is not acked. While your suggestion helps the congestion case, it may also hurt the recovery in other cases when the TLP is dropped due to light/burst/transient congestion. Arguing which scenarios matter more subjectively is not productive. So the question we need to look at is if RACK-TLP 2RTT-PTO + regular RTO-backoff is going to cause major stability issues in extreme congestion. My understanding based on my officemate Van Jacobson's explanation is, as long as there's eventual exponential backoff, we'll avoid the repeated shelling the network. As a matter of fact some major TCP (!= Linux) implementation has implemented linear backoff of first N RTOs before exp-backoff. > > > >> > >> Additional notes: > >> > >> Sec 2.2: > >> > >> Example 2: > >> "Lost retransmissions cause a resort to RTO recovery, since > >> DUPACK-counting does not detect the loss of the retransmissions. > >> Then the slow start after RTO recovery could cause burst losses > >> again that severely degrades performance [POLICER16]." > >> > >> RTO reovery is done in slow start. The last sentence is confusing as > >> there is no (new) slow-start after RTO recovery (or more precisely > >> slow start continues until cwnd > ssthresh). Do you mean: if/when slow > >> start still continues after RTO Recovery has repaired lost segments, > >> it may cause burst losses again? > > I mean the slow start after (the start of) RTO recovery. HTH > > Tnx. I'd appreciate if the text could be clarified to reflect this more > accurately. Maybe something along the lines(?): > > "Then the RTO recovery in slow start could cause burst > losses again that severely degrades performance [POLICER16]." > > >> > >> Example 3: > >> "If the reordering degree is beyond DupThresh, the DUPACK- > >> counting can cause a spurious fast recovery and unnecessary > >> congestion window reduction. To mitigate the issue, [RFC4653] > >> adjusts DupThresh to half of the inflight size to tolerate the > >> higher degree of reordering. However if more than half of the > >> inflight is lost, then the sender has to resort to RTO recovery." > >> > >> This seems to be somewhat incorrect description of TCP-NCR specified in > >> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending > >> new data segments on DupAcks that makes it likely to avoid an RTO in > >> the given example scenario, if not too many of the the new data > >> segments triggered by Extended Limited Transmit are lost. > > sorry I don't see how the text is wrong describing RFC4653, > > specifically the algorithm in adjusting ssthresh > > To my understanding RFC4653 initializes DupThresh to half of the inflight > size in the beginning of the Extended Limited Transmit. Then on each > DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd > worth of DupAcks are received before packet loss is declared (or > reordering detected). So, if I am not incorrect, loss of a half of the > inflight does not necessarily result in RTO recovery with TCP-NCR. Could you suggest the text you'd like on NCR description. > > >> > >> Sec. 3.5: > >> > >> "For example, consider a simple case where one > >> segment was sent with an RTO of 1 second, and then the application > >> writes more data, causing a second and third segment to be sent right > >> before the RTO of the first segment expires. Suppose only the first > >> segment is lost. Without RACK, upon RTO expiration the sender marks > >> all three segments as lost and retransmits the first segment. When > >> the sender receives the ACK that selectively acknowledges the second > >> segment, the sender spuriously retransmits the third segment." > >> > >> This seems incorrect. When the sender receives the ACK that selectively > >> acknowledges the second segment, it is a DupAck as per RFC 6675 and does > >> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the > >> rexmit of the third segment is not allowad until the cumulative ACK of > >> the first segment arrives. > > I don't see where RFC6675 forbids growing cwnd. Even if it does, I > > don't think it's a good thing (in RTO-slow-start) as DUPACK clearly > > indicates a delivery has been made. > > SACKed sequences with DUpAcks indicate that those sequences were > delivered but it does not tell when they were sent. The basic principle > of slow start is to reliably determine the available network capacity > during slow start. Therefore, slow start must ensure it uses only > segments sent during the slow start to increase cwnd. Otherwise, a TCP > sender may encounter exactly the problem of unnecessary retransmission > envisioned in this example of RACK-TCP draft (and increase cwnd on not > valid Acks). > > RFC 6675 does re-specify DupAck with SACK option but it does not include > the rule for slow start. Slow start is specified in RFC 5681. It is > crystal clear in allowing increase in cwnd only on cumulative > Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, > page 6: > > During slow start, a TCP increments cwnd by at most SMSS bytes for > each ACK received that cumulatively acknowledges new data. > > Maybe this example in the RACK-TLP draft was inspired by a incorrect > implementation of SACK-based loss recovery? > > FYI: when we were finalizing RFC 6675 I suggested including also an > algorithm for RTO recovery with SACK in RFC 6675. The reason was exactly > that it might be not easy to gather info from multiple documents and > hence help the implementor to have all necessary advice in a single > document. This unfortunately did not get realized though. I am honestly lost quibbling these RFC6675 implementations and feeling pedantic to these standards largely serve as guiding principles instead of line-by-line code. Is cwnd one packet bigger or smaller in this example making any different in advancing the Internet's capability to do better loss detection. I do not think so. At this point please suggest a text you like to change. > > BR, > > /Markku > > >> > >> Best regards, > >> > >> /Markku > >> > >> > >> > >> On Mon, 16 Nov 2020, The IESG wrote: > >> > >>> > >>> The IESG has received a request from the TCP Maintenance and Minor Extensions > >>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection > >>> algorithm for TCP' > >>> as Proposed Standard > >>> > >>> The IESG plans to make a decision in the next few weeks, and solicits final > >>> comments on this action. Please send substantive comments to the > >>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may > >>> be sent to iesg@ietf.org instead. In either case, please retain the beginning > >>> of the Subject line to allow automated sorting. > >>> > >>> Abstract > >>> > >>> > >>> This document presents the RACK-TLP loss detection algorithm for TCP. > >>> RACK-TLP uses per-segment transmit timestamps and selective > >>> acknowledgements (SACK) and has two parts: RACK ("Recent > >>> ACKnowledgment") starts fast recovery quickly using time-based > >>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") > >>> leverages RACK and sends a probe packet to trigger ACK feedback to > >>> avoid retransmission timeout (RTO) events. Compared to the widely > >>> used DUPACK threshold approach, RACK-TLP detects losses more > >>> efficiently when there are application-limited flights of data, lost > >>> retransmissions, or data packet reordering events. It is intended to > >>> be an alternative to the DUPACK threshold approach. > >>> > >>> > >>> > >>> > >>> The file can be obtained via > >>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > >>> > >>> > >>> > >>> No IPR declarations have been submitted directly on this I-D. > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> tcpm mailing list > >>> tcpm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tcpm > >>> > > From nobody Mon Dec 7 13:29:15 2020 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 3FD403A0B32 for ; Mon, 7 Dec 2020 13:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 bgJFv1Pb6QAx for ; Mon, 7 Dec 2020 13:29:11 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 869EE3A0B54 for ; Mon, 7 Dec 2020 13:29:11 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id a3so578104wmb.5 for ; Mon, 07 Dec 2020 13:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WbxZhbgLzlFf2+tLnm/vXdnIS7yQz7F+HiUQu6g7b1w=; b=plgCGoKsFYTfLZdDHVeTNoryKl2id40aOs0McYTyf1NkvC9XkYlVutlCqFOO74JNQs GrcIXKxhw+ArCYc4YS4FVjxJFNuvSLdqG9rleen4MnVwP4Vg4pHRghjqrIhZtFpWYPY8 7ecaRc3jDdCw1Hb+Zsjq3gJs0xk3sT5DIKqlvxyHAwNlZ+bDBnA8iQSo5sBy8ZTDXrFV QDjIJjEIS1lmTTnTl6OW/iyIVtxQwKcXof3qHXCXHh4bs0VtFJLE7mpEeMtyeiUGXA0/ z99Mwty0LuiZBQRY83EDuTvjxIWBn788PjS546bt6NEEv9allCCpx0GLt1xG6cuKyUEx QxIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WbxZhbgLzlFf2+tLnm/vXdnIS7yQz7F+HiUQu6g7b1w=; b=drhIxN9PJ4qwI75GoD+VcOksRvv1pGaxLiDQVU9Lrtgwruwsn+cZmSluMYooJB/1Cz 8UVOISpJVxkV2gaAp2P0lmM0UhD55zAyjXhRC6haNq5AMjxdjlGRqBOdw7me+BFsveX5 E2bg2SOZvrDiiJNoxlC4vzi0coqrqEknKy8B+hOnILid6x30C1zwQRJSkHYHlPCQp98e JNMQ451+oE5lFasVab6t7dIn50Gh4Y3Nuk6hPFoHGE+MtPGOMl47mzEPROw20vr4sAB8 mUKqAe1pFGZyXNEkdW7z7HvXmwslEAD0ExDmUAYH0BOVZ84T1nr0W1MtdJmOLJ1jGXHu AHDw== X-Gm-Message-State: AOAM53240Np33xmHc7vGtQqytIIy7GAwRFkLMZgboJ++cKR2cI4cRMKS 8frgPuib1nx+2tmEhew/+A7nIMiIb66H4M5ZHJot4g== X-Google-Smtp-Source: ABdhPJx2D4syy+NOSRJQWXdEseJO8eN50R6CTjLeH9rmbAVxDSvPxiyiOm0MFpvGWCtpklTdBT/82bRy24v21h1sv/w= X-Received: by 2002:a7b:c773:: with SMTP id x19mr743279wmk.127.1607376549523; Mon, 07 Dec 2020 13:29:09 -0800 (PST) MIME-Version: 1.0 References: <160729596677.24036.14420451480687784125@ietfa.amsl.com> In-Reply-To: <160729596677.24036.14420451480687784125@ietfa.amsl.com> From: Yuchung Cheng Date: Mon, 7 Dec 2020 13:28:32 -0800 Message-ID: To: Peter Yee Cc: gen-art@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, last-call@ietf.org, "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Genart last call review of draft-ietf-tcpm-rack-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 21:29:13 -0000 On Sun, Dec 6, 2020 at 3:06 PM Peter Yee via Datatracker wrote: > > Reviewer: Peter Yee > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-tcpm-rack-14 > Reviewer: Peter Yee > Review Date: 2020-12-06 > IETF LC End Date: 2020-11-30 > IESG Telechat date: 2020-12-17 > > Summary: This is a well-written draft specifying an efficient scheme for > detecting and recovering from TCP segment loss. There are a few minor nits that > should be corrected prior to publication, but to the extent that I understand > this specification, I don't see any major or minor flaws. [Ready with nits] Thanks for the review. We will make all the changes suggested in the next revision. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > General: > > For all occurrences of "i.e." and "e.g.", make sure that they are consistently > followed by a comma. (Like I said, nits.) > > Specific: > > Page 7, 1st paragraph, 3rd sentence: change: "DUPTHRESH" to "DupThresh". This > appears to be only use of all caps for the term and it does not appear as such > in RFC 6675. > > Page 9, Figure 1: while I understand what is being shown, I'm not a fan of > having the "<--" followed by things like "Receive P0" as this is not a > transmission by the TCP data receiver in the figure. The ACKs and SACKs are > fine on those lines, but I think the receives should be shown on the same line > as the sends. > > Page 9, Figure 1, step 7a: why is there no "receive SACK" as show in step 5a? good idea. we'll include that to make it more complete. > > Page 9, 1st paragraph under Figure 1: change "(P1, P2, P3, P4)" to "(P0, P1, > P2, P3)" to match both the figure and the following text. > > Page 14, 1st paragraph after list item #2: change "round trip" to "round-trip". > > Page 16, 2nd paragraph: append a comma after "observed". > > Page 17, 1st paragraph, 1st sentence: append a comma after "temporary". > > Page 18, 1st paragraph after "now >=" formula, 1 sentence: change "round trip" > to "round-trip". > > Page 18, 2nd to last paragraph, 1st sentence: change "left hand" to "left-hand". > > Page 20, 2nd to last paragraph, 2nd sentence: change "implementation-specific" > to "implementation specific". > > Page 21, last paragraph, 1st sentence: the pointer to the earlier section is > oddly constructed, using doubled single quotes and capitalization that doesn't > even match the referenced section (6.1). It would be better, in my opinion, > just to give a pointer to the section number. sorry will replace w/ section pointer directly > > Page 25, item #3, 1st sentence: change "are" to "is" as flight is singular. > > Page 26, 1st partial paragraph, 1st full sentence: change "data-centers" to > "data centers". > > Page 27, section 9.4, 1st sentence: delete "time" or alternatively insert "a" > before "longer". > > From nobody Tue Dec 8 10:06:59 2020 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 189D93A107F; Tue, 8 Dec 2020 10:06:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 q_Dnr53C_CPL; Tue, 8 Dec 2020 10:06:49 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A2A3A107D; Tue, 8 Dec 2020 10:06:47 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Tue, 08 Dec 2020 20:06:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=vmejLp NLtk34SPBpAhrdroiXV8uhZZF4JUQ0fuylZig=; b=cB7S3jeeQmgOAzoUkWpUKN A+16FtiLC6lQD5kp2FjAxkMcBuwWXdCoVXuEIqk4/p1ZEHi3cq/KVegfv4xqOHbA PXfjQ2t70bgZ+a54t4syIo9HMW7rMqSvFKAUaraKfgkVpGeR9YXrB7N6sZX0twOW 2MOZWexc9SnVYdzYc+42U= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Tue, 08 Dec 2020 20:06:44 +0200 id 00000000005A09C2.000000005FCFC0B4.00005953 Date: Tue, 8 Dec 2020 20:06:43 +0200 (EET) From: Markku Kojo To: Michael Welzl cc: Yuchung Cheng , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, last-call@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-22898-1607450804-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] [Last-Call] Last Call: (TheRACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Dec 2020 18:06:53 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-22898-1607450804-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi Michael, I am top posting, too (as this is a quite short answer to one point only)= . Thanks for the suggestion. I was also thinking of using pipe among first=20 options. Unfortunately, it is not that usable either, if you wish the=20 outcome to be "halving again" as you envisioned. In the example scenario, RACK-TLP first declares segments P1-19 lost and=20 segment P20 SACKed (my quick example marked segment P20 incorrectly lost,=20 sorry). When the loss of the segment P1 is detected, P2&3 are marked SACK= ed. This means that at this point pipe is empty, so it would result in=20 resetting cwnd (=3D 1), which is safe and the same as when detecting the=20 lost rexmit with RTO, but not what you are aiming for (halving again). Cheers, /Markku On Mon, 7 Dec 2020, Michael Welzl wrote: > Hi all, > > thanks for this discussion, and Markku for this long email, I found it = very interesting to read. Sorry for top posting but: > > Sent from my iPhone > :-) > > .... so, just a comment about the backoff upon a lost rexmit in recov= ery: I=E2=80=98d say that halving again is the right thing to do as it=E2= =80=98s certainly in the spirit of the cong.avoid & control paper which, = iirc, motivates halving ssthresh with an exponential backoff. this just a= llows to truly backoff exponentially instead of halving once, followed by = cwnd=3D1. > > regarding how to do it because flightsize may be wrong: perhaps i=E2=80= =98m missing something, i=E2=80=98m not writing this with rfcs and rack-t= lp open on the side.... but: surely rack-tlp also still has the =E2=80=9E= pipe=E2=80=9C variable? wouldn=E2=80=98t cwnd =3D ssthresh =3D pipe / 2 = be the right thing to do? > > cheers, > michael > >> On 7 Dec 2020, at 17:07, Markku Kojo wrote: >> >> =EF=BB=BFHi Yuchung, >> >> thanks for your reply. My major point is that IMHO this RACK-TLP speci= fication should give the necessary advice w.r.t congestion control in cas= es when such advice is not available in the RFC series or is not that eas= y to interpreted correctly from the existing RFCs. >> >> Even though the CC principles were available in RFC series I believe y= ou agree with me that getting detailed CC actions correct is sometimes qu= ite hard, especially if one needs to interpret and apply them from anothe= r spec than what one is implementing. Please see more details inline belo= w. >> >> In addition, we need to remember that this document is not meant only = for TCP experts following the tcpm list and having deep understanding of = congestion control but also those implementing TCP, for the very first ti= me, for various appliances, for example. They do not have first hand expe= rience in implementing TCP congestion control and deserve clear advice wh= at to do. >> >>> On Fri, 4 Dec 2020, Yuchung Cheng wrote: >>> >>>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wro= te: >>>> >>>> Hi all, >>>> >>>> I know this is a bit late but I didn't have time earlier to take loo= k at >>>> this draft. >>>> >>>> Given that this RFC to be is standards track and RECOMMENDED to repl= ace >>>> current DupAck-based loss detection, it is important that the spec i= s >>>> clear on its advice to those implementing it. Current text seems to >>>> lack important advice w.r.t congestion control, and even though >>>> the spec tries to decouple loss detection from congestion control >>>> and does not intend to modify existing standard congestion control >>>> some of the examples advice incorrect congestion control actions. >>>> Therefore, I think it is worth to correct the mistakes and take >>>> yet another look at a few implications of this specification. >>> As you noted, the intention is to decouple the two as much as possibl= e >>> >>> Unlike the 20 years ago where TCP loss detection and congestion >>> control are essentially glued in one piece, the decoupling of the two >>> (including modularizing congestion controls in implementations) has >>> helped fueled many great inventions of new congestion controls. >>> Codifying so-called-default C.C. reactions in the loss detection is a >>> step backward that the authors try their best to avoid. >> >> While I fully agree with the general principle of decoupling loss dete= ction from congestion control when it is possible without leaving open qu= estions, I find it hard to get congestion control right with this spec in = certain cases I raised just by following the current standards track CC s= pecifications. The reason for this is that RACK-TLP introduces new ways t= o detect loss (i.e., not present in any earlier standard track RFC) and t= he current CC specifications do not provide correct CC actions for such c= ases as I try to point out below. >> >>> To keep the >>> document less "abstract / unclear" as many WGLC reviewers commented, >>> we use examples to illustrate that includes CC actions. But the >>> details of these CC actions are likely to become obsolete as CC >>> continues to advance hopefully. >> >> Agreed. But I would appreciate if the CC actions in the examples would = correctly follow what is specified in the the current CC RFCs. And, I wou= ld suggest explicitly citing the RFC(s) that each of the examples is illu= striating so that there is no doubt which CC variant the example is valid = with. Then there is no problem with the correctness of the example either = even if the cited RFC becomes later obsoleted. >> >>>> >>>> Sec. 3.4 (and elsewhere when discussing recovering a dropped >>>> retransmission): >>>> >>>> It is very useful that RACK-TLP allows for recovering dropped rexmit= s. >>>> However, it seems that the spec ignores the fact that loss of a >>>> retransmission is a loss in a successive window that requires reacti= ng >>>> to congestion twice as per RFC 5681. This advice must be included in >>>> the specification because with RACK-TLP recovery of dropped rexmit >>>> takes place during the fast recovery which is very different >>>> from the other standard algorithms and therefore easy to miss >>>> when implementing this spec. >>> >>> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 >>> "Loss in two successive windows of data, or the loss of a >>> retransmission, should be taken as two indications of congestion and, >>> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." >>> >>> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on >>> this so I am not sure what clause you suggest to add to RACK-TLP. >> >> Right, this is the CC *principle* in RFC 5681 I am refering to but I a= m afraid it is not enough to help one to correctly implement such lowerin= g of cwnd (and ssthresh) twice when a loss of a retransmission is detecte= d during Fast Recovery. Nor do RFCs clearly advice *when* this reduction = must take place. >> >> Congestion control principles tell us that congestion must be reacted = immediately when detected. But at the same time, standards track CC speci= fications react to congestion only once during Fast Recovery because the = losses in the current window, which Fast Recovery repairs, occured during = the same RTT. That is, the current CC specifications do not handle lost r= exmits during Fast Recovery but, instead, the correct CC reaction to a lo= ss of a rexmit is automatically achieved by those specifications via RTO = when cwnd is explicitly reset upon RTO. >> >> Furthermore, the problem I am trying to point out is that there is no = correct rule/formula available in the standards track RFCs that would giv= e the correct way to reduce cwnd when the loss of rexmit is detected with = RACK-TLP. >> >> I suggest everyone reading this message stops reading at this point fo= r a while before continuing reading and figures out themselves what they = think would be the correct equation to use in the standards RFC series to = find the new halved value for cwnd when RACK-TLP detects a loss of a rexm= it during Fast Recovery. I would appreciate a comment on the tcpm list fr= om those who think they found the correct answer immediately and easily, = and what was the formula to use. >> >> ... >> >> I think the best advice one may find by looking at RFC 6675 (and RFC 5= 681) is to set >> >> ssthresh =3D cwnd =3D (FlightSize / 2) (RFC 6675, Sec 5, algorithm ste= p 4.2) >> >> Now, let's modify the example in Sec 3.4 of the draft: >> >> 1. Send P0, P1, P2, ..., P20 >> [Assume P1, ..., P20 dropped by network] >> >> 2. Receive P0, ACK P0 >> 3a. 2RTTs after (2), TLP timer fires >> 3b. TLP: retransmits P20 >> ... >> 5a. Receive SACK for P20 >> 5b. RACK: marks P1, ..., P20 lost >> set cwnd=3Dssthresh=3DFlightSize/2=3D10 >> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) >> [P1 retransmission dropped by network] >> >> Receive SACK P2 & P3 7a. RACK: marks P1 retransmission lost >> As per RFC 6675: set cwnd=3Dssthresh=3DFlightSize/2=3D20/2=3D10 >> 7b. Retransmit P1 >> ... >> >> So, is the new value of the cwnd (10MSS) correct and halved twice? If = not, where is the correct formula to do it? >> >> Before RFC 5681 was published we had a discussion on FlighSize and tha= t during Fast Recovery it does not reflect the amount of segments in flig= ht correctly but may also have a too large value. It was decided not to t= ry to correct it because it only has an impact when RTO fires during Fast = Recovery and in such a case cwnd is reset to 1 MSS. Having too large ssth= resh for RTO recovery in some cases was not considered that bad because a = TCP sender anyway takes to most conservative CC action with the cwnd and = would slow start from cwnd =3D 1 MSS. But now when RACK-TLP enables detec= ting loss of a rexmit during Fast Recovery we have an unresolved problem. >> >> >>>> Sec 9.3: >>>> >>>> In Section 9.3 it is stated that the only modification to the existi= ng >>>> congestion control algorithms is that one outstanding loss probe >>>> can be sent even if the congestion window is fully used. This is >>>> fine, but the spec lacks the advice that if a new data segment is se= nt >>>> this extra segment MUST NOT be included when calculating the new val= ue >>>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an >>>> extra segment not allowed by cwnd, so it must be excluded from >>>> FlightSize, if the TLP probe detects loss or if there is no ack >>>> and RTO is needed to trigger loss recovery. >>> >>> Why exclude TLP (or any data) from FlightSize? The congestion control >>> needs precise accounting of the flight size to react to congestion >>> properly. >> >> Because FlightSize does not always reflect the correct amount of data = allowed by cwnd. When a TCP sender is not already in loss recovery and it = detects loss, this loss indicates the congestion point for the TCP sender= , i.e., how much data it can have outstanding. It is this amount of data = that it must use in calculating the new value of cwnd (and ssthresh), so = it must not include any data sent beyond the congestion point. When TLP s= ends a new data segment, it is beyond the congestion point and must not b= e included. Same holds for the segments sent via Limited Transmit: they a= re allowed to be send out by the packet conservation rule (DupAck indicat= es a pkt has left the network, but does not allow increasing cwnd), i.e., = the actual amount of data in flight remains the same. >> >>>> In these cases the temporary over-commit is not accounted for as Dup= Ack >>>> does not decrease FlightSize and in case of an RTO the next ACK come= s too >>>> late. This is similar to the rule in RFC 5681 and RFC 6675 that proh= ibits >>>> including the segments transmitted via Limitid Transmit in the >>>> calculation of ssthresh. >>>> >>>> In Section 9.3 a few example scenarios are used to illustriate the >>>> intended operation of RACK-TLP. >>>> >>>> In the first example a sender has a congestion window (cwnd) of 20 >>>> segments on a SACK-enabled connection. It sends 10 data segments >>>> and all of them are lost. >>>> >>>> The text claims that without RACK-TLP the ending cwnd would be 4 seg= ments >>>> due to congestion window validation. This is incorrect. >>>> As per RFC 7661 the sender MUST exit the non-validated phase upon an >>>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segment= s if >>>> the TCP sender uses the equation (4) of RFC 5681). >>>> >>>> The operation with RACK-TLP would inevitably result in congestion >>>> collapse if RACK-TLP behaves as described in the example because >>>> it restores the previous cwnd of 10 segments after the fast recovery >>>> and would not react to congestion at all! I think this is not the >>>> intended behavior by this spec but a mistake in the example. >>>> The ssthresh calculated in the beginning of loss recovery should >>>> be 5 segments as per RFC 6675 (and RFC 5681). >>> To clarify, would this text look more clear? >>> >>> 'an ending cwnd set to the slow start threshold of 5 segments (half o= f >>> the original congestion window of 10 segments)' >> >> This is correct, but please replace: >> >> (half of the original congestion window of 10 segments) >> --> >> (half of> the original FlightSize of 10 segments) >> >> cwnd in the example was 20 segments. >> >> Please also correct the ending cwnd for "without RACK" scenario. >> I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd valu= e, my apologies. It MAENT equation (3) AND that results in ending cwnd of = 5 and 2/5 MSS (not 5 and 1/2 MSS). >> NB: and if a TCP sender implements entering CA when cwnd > ssthresh, t= hen ending cwnd would be 6 and 1/6 MSS). >> >>>> >>>> Furthermore, it seems that this example with RACK-TLP refers to usin= g >>>> PRR_SSRB which effectively implements regular slow start in this >>>> case(?). From congestion control point of view this is correct becau= se >>>> the entire flight of data as well as ack clock was lost. >>>> >>>> However, as correctly discussed in Sec 2, congestion window must be = reset >>>> to 1 MSS when an entire flight of data is and Ack clock is lost. But = how >>>> can an implementor know what to do if she/he is not implementing the >>>> experimental PRR algrorithm? This spec articulates specifying an >>>> alternative for DupAck counting, indicating that TLP is used to trig= ger >>>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow st= art. >>>> This means that without an additional advise an implementation of th= is >>>> spec would just halve the cwnd and ssthresh and send a potentially v= ery >>>> large burst of segments in the beginning of the Fast Recovery becaus= e >>>> there is no ack clock. So, this spec begs for an advise (MUST) when = to >>>> slow start and reset cwnd and when not, or at least a discussion of >>>> this problem and some sort of advise what to do and what to avoid. >>>> And, maybe a recommendation to implement it with PRR? >>> >>> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst >>> control (when to slow-start). The use of PRR is just an example to >>> illustrate and not meant for a recommendation. >> >> I understand the use of PRR was just an example, but my point is that = if one wants to implement RACK-TLP but does not intend to implement PRR b= ut RFC 6675 then we do not have a rule in RFC 6675 to correctly implement = CC for the case when an entire flight is lost and loss is detected with T= LP. Congestion control principle for this is clear and also stated in thi= s draft but IMHO it is not enough to ensure correct implementation. >> >> To my understanding we only have implementation experience for RACK-TL= P only togerher with PRR, which has the necessary rule to handle this kin= d of scenario correctly. >> >> So, my question is how can one implement CC correctly without PRR such = a scenario where entire inflight is lost? >> Which rule and where in the RFC series gives the necessary guidance to = reset cwnd and slow start when TCP detets loss of an entire flight? >> >>> Section 3 has a lengthy section to elaborate the key point of RACK-TL= P >>> is to maximize the chance of fast recovery. How C.C. governs the >>> transmission dynamics after losses are detected are out of scope of >>> this document in our authors' opinions. >>> >>> >>>> >>>> Another question relates to the use of TLP and adjusting timer(s) up= on >>>> timeout. In the same example discussed above, it is clear that PTO >>>> that fires TLP is just a more aggressive retransmit timer with >>>> an alternative data segment to (re)transmit. >>>> >>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it i= s in >>>> effect a retransmission timout and the timer(s) must be backed-off. >>>> This is not adviced in this specification. Whether it is the TCP RTO >>>> or PTO that should be backed-off is an open question. Otherwise, >>>> if the congestion is persistent and further transmission are also lo= st, >>>> RACK-TLP would not react to congestion properly but would keep >>>> retransmitting with "constant" timer value because new RTT estimate >>>> cannot be obtained. >>>> On a buffer bloated and heavily congested bottleneck this would easi= ly >>>> result in sending at least one unnecessary retransmission per one >>>> delivered segment which is not advisable (e.g., when there are a hug= e >>>> number of applications sharing a constrained bottleneck and these >>>> applications are sending only one (or a few) segments and then >>>> waiting for an reply from the peer before sending another request). >>> >>> Thanks for pointing to the RFC. After TLP, RTO timers will >>> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 >>> (didn't find 9.1 relevant). >> >> My apologies for refering to the wrong section of RFC 2914, Yes, I mea= nt Sec 9.3. >> >>> In your scenario, you presuppose the >>> retransmission is unnecessary so obviously TLP is not good. Consider >>> what happens without TLP where all the senders fire RTO spuriously an= d >>> blow up the network. It is equally unfortunate behavior. "bdp >>> insufficient of many flows" is a congestion control problem >> >> If (without TLP) RTO is spurious, it may result in unnecessary retrans= missions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to detect and = resolve it without TLP, so I don't find it as a problem. >> >> To clarify more, what I am concerned about. Think about a scenario whe= re a (narrow) bottleneck becomes heavily congested by a huge number of co= mpeting senders such that the available capacity per sender is less than = 1 segment (or << 1 MSS). >> This is a situation that network first enters before congestion collap= se gets realized. So, it is extremely important that all CC and timer mec= hanisms handle it properly. Regular TCP handles it via RFC 6298 by backin= g off RTO expotentially and keeping this backed-off RTO until an new ACK = is received for new data. This saves RACK-TLP from full congestion collap= se. But consider what happens: even though RTO is backed off, each time a = TCP sender manages to get one segment through (with cwnd =3D 1 MSS) it al= ways first arms PTO with more or less constant value of 2*SRTT. If the bo= ttleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and TLP b= ecomes spurious. After a spurious TLP, RTO expires (maybe more than once = before exponential back-off of RTO results in large enough value) and a n= ew RTT sample is not received. So, SRTT remains unchanged and even if som= etimes a new sample is received, SRTT gets very slowly adjusted. As a res= ult, each TCP sender would keep on sending a spurious TLP for each new se= gment resulting in at least 50% of the packets being unnecessary rexmitte= d and the utilization of the bottleneck is < 50%. This would not be a ful= l congestion collapse but has unwanted symptoms towards congestion collap= se (Note: there is no clear line for the level of reduction in delivery o= f useful data is considered as congestion collapse). >> >> >>>> >>>> Additional notes: >>>> >>>> Sec 2.2: >>>> >>>> Example 2: >>>> "Lost retransmissions cause a resort to RTO recovery, since >>>> DUPACK-counting does not detect the loss of the retransmissions. >>>> Then the slow start after RTO recovery could cause burst losses >>>> again that severely degrades performance [POLICER16]." >>>> >>>> RTO reovery is done in slow start. The last sentence is confusing as >>>> there is no (new) slow-start after RTO recovery (or more precisely >>>> slow start continues until cwnd > ssthresh). Do you mean: if/when sl= ow >>>> start still continues after RTO Recovery has repaired lost segments, >>>> it may cause burst losses again? >>> I mean the slow start after (the start of) RTO recovery. HTH >> >> Tnx. I'd appreciate if the text could be clarified to reflect this mor= e accurately. Maybe something along the lines(?): >> >> "Then the RTO recovery in slow start could cause burst >> losses again that severely degrades performance [POLICER16]." >> >>>> >>>> Example 3: >>>> "If the reordering degree is beyond DupThresh, the DUPACK- >>>> counting can cause a spurious fast recovery and unnecessary >>>> congestion window reduction. To mitigate the issue, [RFC4653] >>>> adjusts DupThresh to half of the inflight size to tolerate the >>>> higher degree of reordering. However if more than half of the >>>> inflight is lost, then the sender has to resort to RTO recovery." >>>> >>>> This seems to be somewhat incorrect description of TCP-NCR specified = in >>>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sendi= ng >>>> new data segments on DupAcks that makes it likely to avoid an RTO in >>>> the given example scenario, if not too many of the the new data >>>> segments triggered by Extended Limited Transmit are lost. >>> sorry I don't see how the text is wrong describing RFC4653, >>> specifically the algorithm in adjusting ssthresh >> >> To my understanding RFC4653 initializes DupThresh to half of the infli= ght size in the beginning of the Extended Limited Transmit. Then on each = DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd = worth of DupAcks are received before packet loss is declared (or reorderi= ng detected). So, if I am not incorrect, loss of a half of the inflight d= oes not necessarily result in RTO recovery with TCP-NCR. >> >>>> >>>> Sec. 3.5: >>>> >>>> "For example, consider a simple case where one >>>> segment was sent with an RTO of 1 second, and then the application >>>> writes more data, causing a second and third segment to be sent rig= ht >>>> before the RTO of the first segment expires. Suppose only the firs= t >>>> segment is lost. Without RACK, upon RTO expiration the sender mark= s >>>> all three segments as lost and retransmits the first segment. When >>>> the sender receives the ACK that selectively acknowledges the secon= d >>>> segment, the sender spuriously retransmits the third segment." >>>> >>>> This seems incorrect. When the sender receives the ACK that selectiv= ely >>>> acknowledges the second segment, it is a DupAck as per RFC 6675 and = does >>>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, t= he >>>> rexmit of the third segment is not allowad until the cumulative ACK = of >>>> the first segment arrives. >>> I don't see where RFC6675 forbids growing cwnd. Even if it does, I >>> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly >>> indicates a delivery has been made. >> >> SACKed sequences with DUpAcks indicate that those sequences were deliv= ered but it does not tell when they were sent. The basic principle of slo= w start is to reliably determine the available network capacity during sl= ow start. Therefore, slow start must ensure it uses only segments sent du= ring the slow start to increase cwnd. Otherwise, a TCP sender may encount= er exactly the problem of unnecessary retransmission envisioned in this e= xample of RACK-TCP draft (and increase cwnd on not valid Acks). >> >> RFC 6675 does re-specify DupAck with SACK option but it does not inclu= de the rule for slow start. Slow start is specified in RFC 5681. It is cr= ystal clear in allowing increase in cwnd only on cumulative Acks, i.e., f= orbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, >> page 6: >> >> During slow start, a TCP increments cwnd by at most SMSS bytes for >> each ACK received that cumulatively acknowledges new data. >> >> Maybe this example in the RACK-TLP draft was inspired by a incorrect i= mplementation of SACK-based loss recovery? >> >> FYI: when we were finalizing RFC 6675 I suggested including also an al= gorithm for RTO recovery with SACK in RFC 6675. The reason was exactly th= at it might be not easy to gather info from multiple documents and hence = help the implementor to have all necessary advice in a single document. T= his unfortunately did not get realized though. >> >> BR, >> >> /Markku >> >>>> >>>> Best regards, >>>> >>>> /Markku >>>> >>>> >>>> >>>>> On Mon, 16 Nov 2020, The IESG wrote: >>>> >>>>> >>>>> The IESG has received a request from the TCP Maintenance and Minor = Extensions >>>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss = detection >>>>> algorithm for TCP' >>>>> as Proposed Standard >>>>> >>>>> The IESG plans to make a decision in the next few weeks, and solici= ts final >>>>> comments on this action. Please send substantive comments to the >>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comm= ents may >>>>> be sent to iesg@ietf.org instead. In either case, please retain the = beginning >>>>> of the Subject line to allow automated sorting. >>>>> >>>>> Abstract >>>>> >>>>> >>>>> This document presents the RACK-TLP loss detection algorithm for T= CP. >>>>> RACK-TLP uses per-segment transmit timestamps and selective >>>>> acknowledgements (SACK) and has two parts: RACK ("Recent >>>>> ACKnowledgment") starts fast recovery quickly using time-based >>>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") >>>>> leverages RACK and sends a probe packet to trigger ACK feedback to >>>>> avoid retransmission timeout (RTO) events. Compared to the widely >>>>> used DUPACK threshold approach, RACK-TLP detects losses more >>>>> efficiently when there are application-limited flights of data, lo= st >>>>> retransmissions, or data packet reordering events. It is intended = to >>>>> be an alternative to the DUPACK threshold approach. >>>>> >>>>> >>>>> >>>>> >>>>> The file can be obtained via >>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ >>>>> >>>>> >>>>> >>>>> No IPR declarations have been submitted directly on this I-D. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>> >> >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > --=_script-22898-1607450804-0001-2-- From nobody Tue Dec 8 11:21:20 2020 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 E70203A1101; Tue, 8 Dec 2020 11:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_IMPORTANT=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 sKdL0L3iPD_h; Tue, 8 Dec 2020 11:21:10 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3591A3A10FE; Tue, 8 Dec 2020 11:21:07 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Tue, 08 Dec 2020 21:21:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=IQu59V6NITRC7gqZ3 3ygDRGIDpEh56MrZ2Yar1u+FVo=; b=eBKEwnCtxP1ndzfI9RwduBbW5DRUVtXMm VKUTMWuAjqF5mFmyZsf9rThyHi/K2HzH9AErml0apuDFOY2owNhV7p3FPxquYP/+ 7qQwyRwoS5fSMZYlRLnd33HQzDCyZPv7SdGI6PV5DREgALQfiT/tOxtxTAzlt/hg JBCbLdsYrU= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Tue, 08 Dec 2020 21:21:00 +0200 id 00000000005A09C2.000000005FCFD21C.00002CC9 Date: Tue, 8 Dec 2020 21:21:00 +0200 (EET) From: Markku Kojo To: Yuchung Cheng cc: last-call@ietf.org, "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 08 Dec 2020 19:21:14 -0000 Hi, please see inline. On Mon, 7 Dec 2020, Yuchung Cheng wrote: > On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo wrote: >> >> Hi Yuchung, >> >> thanks for your reply. My major point is that IMHO this RACK-TLP >> specification should give the necessary advice w.r.t congestion control >> in cases when such advice is not available in the RFC series or is not >> that easy to interpreted correctly from the existing RFCs. >> >> Even though the CC principles were available in RFC series I believe you >> agree with me that getting detailed CC actions correct is sometimes quite >> hard, especially if one needs to interpret and apply them from another >> spec than what one is implementing. Please see more details inline below. >> >> In addition, we need to remember that this document is not meant only for >> TCP experts following the tcpm list and having deep understanding of >> congestion control but also those implementing TCP, for the very first >> time, for various appliances, for example. They do not have first hand >> experience in implementing TCP congestion control and deserve clear >> advice what to do. >> >> On Fri, 4 Dec 2020, Yuchung Cheng wrote: >> >>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: >>>> >>>> Hi all, >>>> >>>> I know this is a bit late but I didn't have time earlier to take look at >>>> this draft. >>>> >>>> Given that this RFC to be is standards track and RECOMMENDED to replace >>>> current DupAck-based loss detection, it is important that the spec is >>>> clear on its advice to those implementing it. Current text seems to >>>> lack important advice w.r.t congestion control, and even though >>>> the spec tries to decouple loss detection from congestion control >>>> and does not intend to modify existing standard congestion control >>>> some of the examples advice incorrect congestion control actions. >>>> Therefore, I think it is worth to correct the mistakes and take >>>> yet another look at a few implications of this specification. >>> As you noted, the intention is to decouple the two as much as possible >>> >>> Unlike the 20 years ago where TCP loss detection and congestion >>> control are essentially glued in one piece, the decoupling of the two >>> (including modularizing congestion controls in implementations) has >>> helped fueled many great inventions of new congestion controls. >>> Codifying so-called-default C.C. reactions in the loss detection is a >>> step backward that the authors try their best to avoid. >> >> While I fully agree with the general principle of decoupling loss >> detection from congestion control when it is possible without leaving >> open questions, I find it hard to get congestion control right with this >> spec in certain cases I raised just by following the current standards >> track CC specifications. The reason for this is that RACK-TLP introduces >> new ways to detect loss (i.e., not present in any earlier standard track >> RFC) and the current CC specifications do not provide correct CC actions >> for such cases as I try to point out below. >> >>> To keep the >>> document less "abstract / unclear" as many WGLC reviewers commented, >>> we use examples to illustrate that includes CC actions. But the >>> details of these CC actions are likely to become obsolete as CC >>> continues to advance hopefully. >> >> Agreed. But I would appreciate if the CC actions in the examples would >> correctly follow what is specified in the the current CC RFCs. And, I >> would suggest explicitly citing the RFC(s) that each of the examples is >> illustriating so that there is no doubt which CC variant the example >> is valid with. Then there is no problem with the correctness of the >> example either even if the cited RFC becomes later obsoleted. >> >>>> >>>> Sec. 3.4 (and elsewhere when discussing recovering a dropped >>>> retransmission): >>>> >>>> It is very useful that RACK-TLP allows for recovering dropped rexmits. >>>> However, it seems that the spec ignores the fact that loss of a >>>> retransmission is a loss in a successive window that requires reacting >>>> to congestion twice as per RFC 5681. This advice must be included in >>>> the specification because with RACK-TLP recovery of dropped rexmit >>>> takes place during the fast recovery which is very different >>>> from the other standard algorithms and therefore easy to miss >>>> when implementing this spec. >>> >>> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 >>> "Loss in two successive windows of data, or the loss of a >>> retransmission, should be taken as two indications of congestion and, >>> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." >>> >>> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on >>> this so I am not sure what clause you suggest to add to RACK-TLP. >> >> Right, this is the CC *principle* in RFC 5681 I am refering to but I am >> afraid it is not enough to help one to correctly implement such lowering >> of cwnd (and ssthresh) twice when a loss of a retransmission is detected >> during Fast Recovery. Nor do RFCs clearly advice *when* this reduction >> must take place. >> >> Congestion control principles tell us that congestion must be reacted >> immediately when detected. But at the same time, standards track CC >> specifications react to congestion only once during Fast Recovery >> because the losses in the current window, which Fast Recovery repairs, >> occured during the same RTT. That is, the current CC specifications do >> not handle lost rexmits during Fast Recovery but, instead, the correct CC >> reaction to a loss of a rexmit is automatically achieved by those >> specifications via RTO when cwnd is explicitly reset upon RTO. >> >> Furthermore, the problem I am trying to point out is that there is no >> correct rule/formula available in the standards track RFCs that would >> give the correct way to reduce cwnd when the loss of rexmit is detected >> with RACK-TLP. >> >> I suggest everyone reading this message stops reading at this point >> for a while before continuing reading and figures out themselves what >> they think would be the correct equation to use in the standards RFC >> series to find the new halved value for cwnd when RACK-TLP detects a loss >> of a rexmit during Fast Recovery. I would appreciate a comment on the >> tcpm list from those who think they found the correct answer immediately >> and easily, and what was the formula to use. >> >> ... >> >> I think the best advice one may find by looking at RFC 6675 (and RFC >> 5681) is to set >> >> ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.2) >> >> Now, let's modify the example in Sec 3.4 of the draft: >> >> 1. Send P0, P1, P2, ..., P20 >> [Assume P1, ..., P20 dropped by network] >> >> 2. Receive P0, ACK P0 >> 3a. 2RTTs after (2), TLP timer fires >> 3b. TLP: retransmits P20 >> ... >> 5a. Receive SACK for P20 >> 5b. RACK: marks P1, ..., P20 lost >> set cwnd=ssthresh=FlightSize/2=10 >> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) >> [P1 retransmission dropped by network] >> >> Receive SACK P2 & P3 >> 7a. RACK: marks P1 retransmission lost >> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 >> 7b. Retransmit P1 >> ... >> >> So, is the new value of the cwnd (10MSS) correct and halved twice? If not, >> where is the correct formula to do it? >> >> Before RFC 5681 was published we had a discussion on FlighSize and that >> during Fast Recovery it does not reflect the amount of segments in >> flight correctly but may also have a too large value. It was decided not >> to try to correct it because it only has an impact when RTO fires during >> Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too large >> ssthresh for RTO recovery in some cases was not considered that bad >> because a TCP sender anyway takes to most conservative CC action with the >> cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP enables >> detecting loss of a rexmit during Fast Recovery we have an unresolved >> problem. > > > 1. Send P0, P1, P2, ..., P20 >> [Assume P1, ..., P20 dropped by network] >> >> 2. Receive P0, ACK P0 >> 3a. 2RTTs after (2), TLP timer fires >> 3b. TLP: retransmits P20 >> ... >> 5a. Receive SACK for P20 >> 5b. RACK: marks P1, ..., P20 lost >> set cwnd=ssthresh=FlightSize/2=10 >> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) >> [P1 retransmission dropped by network] >> >> Receive SACK P2 & P3 >> 7a. RACK: marks P1 retransmission lost >> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 >> 7b. Retransmit P1 > > To account for your points, IMO clearly stating the existing CC RFC > interactions w/o mandating any C.C. actions are the best way to move > forward. Here are the text diff I proposed: > > "Figure 1, above, illustrates ... > Notice a subtle interaction with existing congestion control actions > on event 7a. It essentially starts another new episode of congestion > due to the detection of lost retransmission. Per RFC5681 (section 4.3) > that loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion as a > principle. But RFC6675 that introduces the pipe concept does not > specify such a second window reduction. This document reminds RACK-TLP This is not quite correct characterization of RFC 6675. RFC 6675 does not repeat all guidelines of RFC 5681. RFC 6675 DOES specify the two indications of congestion implicitly by clearly stating in the intro that it follows the guidelines set in RFC 5681. And RFC 5681 articulates a set of MUSTs which ALL alternative loss recovery algorithms MUST follow in order to become RFCs. (*) RFC 5681, Sec 4.3 (pp. 12-13): "While this document does not standardize any of the specific algorithms that may improve fast retransmit/fast recovery, ... That is, ... Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion and, therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > implementation to carefully consider the new multiple congestion > episode cases in the corresponding congestion control." I am sorry to say that this is very fuzzy and leaves an implementer all alone what to do. More inportantly, AFAIK we have no discussion nor consensus in the IETF on what is the correct CC action when lost rexmit is detected. Should one reset cwnd like current CCs do, or would "halving again" be fine, or something else? IMHO this requires experimentation to decide. I assumed there is an implementation of RACK-TLP with corresponding CC actions and experimental results to devise what are the implications of the selected CC action(s) with various levels of congestion. But it seems we do not have such implementation nor experimental evidence? Am I wrong? I sincerely apologize that this got raised this late in the prosess and I know how irritating it may be. I like the idea of RACK-TLP and by no means my intention is not to hold up the process but the lack of evidence makes me quite concerned. In particular, when this document says that the current loss detection SHOULD be replaced in all implementations with RACK-TLP. > and to emphasize in section 9.3 Interaction with congestion control > > "9.3. Interaction with congestion control > > RACK-TLP intentionally decouples loss detection ... this appropriate. > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. Therefore the documents reminds RACK-TLP > implementation to carefully consider these implications in its > corresponding congestion control. > > ..." > > > >> >> >>>> Sec 9.3: >>>> >>>> In Section 9.3 it is stated that the only modification to the existing >>>> congestion control algorithms is that one outstanding loss probe >>>> can be sent even if the congestion window is fully used. This is >>>> fine, but the spec lacks the advice that if a new data segment is sent >>>> this extra segment MUST NOT be included when calculating the new value >>>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an >>>> extra segment not allowed by cwnd, so it must be excluded from >>>> FlightSize, if the TLP probe detects loss or if there is no ack >>>> and RTO is needed to trigger loss recovery. >>> >>> Why exclude TLP (or any data) from FlightSize? The congestion control >>> needs precise accounting of the flight size to react to congestion >>> properly. >> >> Because FlightSize does not always reflect the correct amount of data >> allowed by cwnd. When a TCP sender is not already in loss recovery and >> it detects loss, this loss indicates the congestion point for the TCP >> sender, i.e., how much data it can have outstanding. It is this amount of >> data that it must use in calculating the new value of cwnd (and >> ssthresh), so it must not include any data sent beyond the congestion >> point. When TLP sends a new data segment, it is beyond the congestion >> point and must not be included. Same holds for the segments sent via >> Limited Transmit: they are allowed to be send out by the packet >> conservation rule (DupAck indicates a pkt has left the network, but does >> not allow increasing cwnd), i.e., the actual amount of data in flight >> remains the same. >> >>>> In these cases the temporary over-commit is not accounted for as DupAck >>>> does not decrease FlightSize and in case of an RTO the next ACK comes too >>>> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits >>>> including the segments transmitted via Limitid Transmit in the >>>> calculation of ssthresh. >>>> >>>> In Section 9.3 a few example scenarios are used to illustriate the >>>> intended operation of RACK-TLP. >>>> >>>> In the first example a sender has a congestion window (cwnd) of 20 >>>> segments on a SACK-enabled connection. It sends 10 data segments >>>> and all of them are lost. >>>> >>>> The text claims that without RACK-TLP the ending cwnd would be 4 segments >>>> due to congestion window validation. This is incorrect. >>>> As per RFC 7661 the sender MUST exit the non-validated phase upon an >>>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if >>>> the TCP sender uses the equation (4) of RFC 5681). >>>> >>>> The operation with RACK-TLP would inevitably result in congestion >>>> collapse if RACK-TLP behaves as described in the example because >>>> it restores the previous cwnd of 10 segments after the fast recovery >>>> and would not react to congestion at all! I think this is not the >>>> intended behavior by this spec but a mistake in the example. >>>> The ssthresh calculated in the beginning of loss recovery should >>>> be 5 segments as per RFC 6675 (and RFC 5681). >>> To clarify, would this text look more clear? >>> >>> 'an ending cwnd set to the slow start threshold of 5 segments (half of >>> the original congestion window of 10 segments)' >> >> This is correct, but please replace: >> >> (half of the original congestion window of 10 segments) >> --> >> (half of> the original FlightSize of 10 segments) > > sure will do > >> >> cwnd in the example was 20 segments. >> >> Please also correct the ending cwnd for "without RACK" scenario. >> I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, >> my apologies. It MAENT equation (3) AND that results in ending cwnd of 5 >> and 2/5 MSS (not 5 and 1/2 MSS). >> NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then >> ending cwnd would be 6 and 1/6 MSS). >> >>>> >>>> Furthermore, it seems that this example with RACK-TLP refers to using >>>> PRR_SSRB which effectively implements regular slow start in this >>>> case(?). From congestion control point of view this is correct because >>>> the entire flight of data as well as ack clock was lost. >>>> >>>> However, as correctly discussed in Sec 2, congestion window must be reset >>>> to 1 MSS when an entire flight of data is and Ack clock is lost. But how >>>> can an implementor know what to do if she/he is not implementing the >>>> experimental PRR algrorithm? This spec articulates specifying an >>>> alternative for DupAck counting, indicating that TLP is used to trigger >>>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. >>>> This means that without an additional advise an implementation of this >>>> spec would just halve the cwnd and ssthresh and send a potentially very >>>> large burst of segments in the beginning of the Fast Recovery because >>>> there is no ack clock. So, this spec begs for an advise (MUST) when to >>>> slow start and reset cwnd and when not, or at least a discussion of >>>> this problem and some sort of advise what to do and what to avoid. >>>> And, maybe a recommendation to implement it with PRR? >>> >>> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst >>> control (when to slow-start). The use of PRR is just an example to >>> illustrate and not meant for a recommendation. >> >> I understand the use of PRR was just an example, but my point is that if >> one wants to implement RACK-TLP but does not intend to implement PRR but >> RFC 6675 then we do not have a rule in RFC 6675 to correctly implement >> CC for the case when an entire flight is lost and loss is detected with >> TLP. Congestion control principle for this is clear and also stated in >> this draft but IMHO it is not enough to ensure correct implementation. >> >> To my understanding we only have implementation experience for RACK-TLP >> only togerher with PRR, which has the necessary rule to handle this kind >> of scenario correctly. >> >> So, my question is how can one implement CC correctly without PRR such >> a scenario where entire inflight is lost? >> Which rule and where in the RFC series gives the necessary guidance to >> reset cwnd and slow start when TCP detets loss of an entire flight? > > I think we're going in loops. To move forward it'd help if you suggest > some text you like to change. Unfortunately I do not have an immediate solution. I assumed there is an implementation and you could enlighten what was the solution there and experimental results showing how it seems to work. If I have understood it correctly there is a solution/implementation and experience of RACK-TLP that works together with PRR but no solution/implementation nor experience how it works without PRR. Am I correct? Given my understanding of PRR, the problem of an entire flight being dropped is quite nicely solved with it. However, implementing RACK-TLP without PRR begs for a solution. Here is my current understanding: (1) RACK part is what can be called to "replace" DupAck counting (2) TLP part is effectively a new retransmission timeout to detect a loss of an entire flight of data (i.e., it is only invoked when a tail of the current flight becomes lost which equals to the case of losing an entire flight since all segments before the tail loss will get cumulatively Acked and hence these segments are not anymore a part of the current flight at the time the loss is detected. And we an assume application limited TCP sender. (3) Current CC principles require resetting cwnd in such a case and entering slow start (and so effectively does PRR though it is not explicitly stated in RFC 6937). Slow start avoids a big burst if the lost flight is big. (4) RACK-TLP would possibly like to allow that cwnd is set to a half of the lost flight and not to slow start. This means that the bigger the lost flight is, the bigger is the burst that gets transmitted at the beginning of the recovery which is bad. So, this approach would need at least a rule/advice for burst avoidance (slow start, pacing, ...). (5) When the lost flight is small (<= 4 segments) there is no difference in recovery efficiency between (3) and (4). If the lost flight is > 5 segments, then (4) takes less RTTs to complete the recovery but generates a burst. Note, even if pacing over one SRTT would be used, it is still a burst. Now, it would be useful to have experimental data to know how the size of the lost flight is distributed. Is it typically just a few segments as illustriated in the examples of the draft or is it often larger? My advice would be to add a rule that cwnd MUST be reset to 1 MSS and the sender MUST enter slow start if TLP detects loss of an entire flight. This would be safe. Otherwise, without experimental evidence from a wide range of different network conditions and workloads it feels unsafe to allow more aggressive approach. >>> Section 3 has a lengthy section to elaborate the key point of RACK-TLP >>> is to maximize the chance of fast recovery. How C.C. governs the >>> transmission dynamics after losses are detected are out of scope of >>> this document in our authors' opinions. >>> >>> >>>> >>>> Another question relates to the use of TLP and adjusting timer(s) upon >>>> timeout. In the same example discussed above, it is clear that PTO >>>> that fires TLP is just a more aggressive retransmit timer with >>>> an alternative data segment to (re)transmit. >>>> >>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in >>>> effect a retransmission timout and the timer(s) must be backed-off. >>>> This is not adviced in this specification. Whether it is the TCP RTO >>>> or PTO that should be backed-off is an open question. Otherwise, >>>> if the congestion is persistent and further transmission are also lost, >>>> RACK-TLP would not react to congestion properly but would keep >>>> retransmitting with "constant" timer value because new RTT estimate >>>> cannot be obtained. >>>> On a buffer bloated and heavily congested bottleneck this would easily >>>> result in sending at least one unnecessary retransmission per one >>>> delivered segment which is not advisable (e.g., when there are a huge >>>> number of applications sharing a constrained bottleneck and these >>>> applications are sending only one (or a few) segments and then >>>> waiting for an reply from the peer before sending another request). >>> >>> Thanks for pointing to the RFC. After TLP, RTO timers will >>> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 >>> (didn't find 9.1 relevant). >> >> My apologies for refering to the wrong section of RFC 2914, Yes, I meant >> Sec 9.3. >> >>> In your scenario, you presuppose the >>> retransmission is unnecessary so obviously TLP is not good. Consider >>> what happens without TLP where all the senders fire RTO spuriously and >>> blow up the network. It is equally unfortunate behavior. "bdp >>> insufficient of many flows" is a congestion control problem >> >> If (without TLP) RTO is spurious, it may result in unnecessary >> retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to >> detect and resolve it without TLP, so I don't find it as a problem. >> >> To clarify more, what I am concerned about. Think about a scenario where a >> (narrow) bottleneck becomes heavily congested by a huge number of >> competing senders such that the available capacity per sender is less >> than 1 segment (or << 1 MSS). >> This is a situation that network first enters before congestion collapse >> gets realized. So, it is extremely important that all CC and timer >> mechanisms handle it properly. Regular TCP handles it via RFC 6298 by >> backing off RTO expotentially and keeping this backed-off RTO until an >> new ACK is received for new data. This saves RACK-TLP from full congestion >> collapse. But consider what happens: even though RTO is backed off, each >> time a TCP sender manages to get one segment through (with cwnd = 1 MSS) >> it always first arms PTO with more or less constant value of 2*SRTT. If >> the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and >> TLP becomes spurious. After a spurious TLP, RTO expires (maybe more than >> once before exponential back-off of RTO results in large enough value) >> and a new RTT sample is not received. So, SRTT remains unchanged and even >> if sometimes a new sample is received, SRTT gets very slowly adjusted. As >> a result, each TCP sender would keep on sending a spurious TLP for each >> new segment resulting in at least 50% of the packets being unnecessary >> rexmitted and the utilization of the bottleneck is < 50%. This would not >> be a full congestion collapse but has unwanted symptoms towards >> congestion collapse (Note: there is no clear line for the level of >> reduction in delivery of useful data is considered as congestion >> collapse). > > AFAIK you are saying: under extreme congestion shared by many short > flows, RACK-TLP can cause more packet losses because of the more > aggressive PTO timer. I agree and can add this to the "section 9.3". No, that was not what I meant. This happens simply when enough flows are competing on the same bottleneck. It may be long flows or maybe applications with more or less continuous request-reply exhanges. E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is 500msecs and PMTU is 1500B, then a bit over 40 simultaneous flows would mean that the bottleneck becomes fully utilized with the equal share of roughly 1 MSS per flow. With a quite typical bottleneck buffer size roughly equaling to BDP, about 80+ flows would fill up the buffer as well and increase RTT >= 1 secs. A buffer bloated bottleneck buffer would mean even larger RTT and allow more flows sharing the bottleneck without loss. If the number of TCP flows is > 90 (or >> 90) RACK-TLP would ends up (almost) always unnecessarily retransmitting each new segment once (PTO being 1 sec or around 1 sec). RTO back-off after a few rounds saves each TCP sender from additional unnecessary rexmits but still ~ 50% of the deivered packets are not making any useful progress. If the bottleneck buffer is small, it would result in more losses as you suggest but would not be that much of problem because majority of the unnecessary rexmits would not get delivered over the bottleneck link. Instead, they wuold get dropped at the bottleneck. Unnecessary rexmits would just create extra load on the poth before the bottleneck (which of course is not a non-problem either). > What authors disagree is that RTO must be back-off on the first > instance if TLP is not acked. While your suggestion helps the > congestion case, it may also hurt the recovery in other cases when the > TLP is dropped due to light/burst/transient congestion. Arguing which > scenarios matter more subjectively is not productive. When RACK-TLP is required to be implemented by all TCP stacks, it is extremely important that it always works in a safe way and congestion is always the primary concern to get properly handled. Without arguing more, I just want to point out that TCP must work reasonably for all Internet users. That means it must not generate a situation where even a small minority of the Internet users often or almost always encounter severe problems with their connectivity. For example, also users in developing countries where possibly an entire village shares just one mobile (cellular, maybe 3G possibly only GPRS) connection for their Internet access and pays per amount of data should get reasonable TCP behavior. In such a case, I cannot agree with engineering that results in almost always getting only half of the already scarce bandwidth whle paying double price fot the useful data. But thinking about a way forward. Karn's algorithm would require backing off PTO even if you get Ack of PTO. Relaxing this does not sound me that bad at all, because there is often a pause before TLP and a TCP sender gets feedback, so apparently conditions are not that bad and loss recovery gets triggered (hopefully in slow start). If TLP is not acked, RTO is needed and recovery is completed in using RTO recovery in slow start. Now, if the RTO recovery is successful (no losses during RTO recovery), it should be quite likely that the TCP sender is able to successfully send also one new segment, because it enters CA when it is sending at the half of the previous rate. So, once you get Ack for the new segment, the TLP back off can be removed and it is unlikely that the TLP back off slowed down next loss detection. On the other hand, if the RTO recovery after an unsuccessful TLP is not successful (more losses are detected), it is quite likely that congestion has not been resolved. So, it is important to be conservative and have a backed-off PTO (or even turn it off) to avoid (further) unnecessary rexmits. If PTO is not backed of, I'd envision PTO mainly failing to get an Ack in such a case and thereby it not being that useful. This certainly would require experimental data in a heavily congested setting to really figure out the actual impact of different alternatives. > So the question we need to look at is if RACK-TLP 2RTT-PTO + regular > RTO-backoff is going to cause major stability issues in extreme > congestion. My understanding based on my officemate Van Jacobson's > explanation is, as long as there's eventual exponential backoff, we'll > avoid the repeated shelling the network. Right. But the problem is that with TLP as specified we do not have full exponential back off. It lacks Karn's clamped retransmit backoff (as it is called in Van Jacobson's seminal paper) which requires keeping backed-off timer of a retransmitted segment for the next (new) segment and ensures that there is eventual exponential backoff. Backing off just RTO is not enough, because "fixed" PTO for each new segment breaks this "back-off chain", that is, the exponential backoff is not continueed until there is evidence that congestion has been resolved (a cumulative Ack arrives for new data). But as I said, backing off RTO saves RACK-TLP from a full congestion collapse. Still, wasting 50% of the available network capacity in certain usage scenarios does not sound acceptable for me. > As a matter of fact some > major TCP (!= Linux) implementation has implemented linear backoff of > first N RTOs before exp-backoff. But that's quite ok as long as there is eventual exponential backoff, including Karn's clamped retransmit backoff. Linear back-off in the beginning just makes resolving (heavy) congestion a bit slower. >> >>>> >>>> Additional notes: >>>> >>>> Sec 2.2: >>>> >>>> Example 2: >>>> "Lost retransmissions cause a resort to RTO recovery, since >>>> DUPACK-counting does not detect the loss of the retransmissions. >>>> Then the slow start after RTO recovery could cause burst losses >>>> again that severely degrades performance [POLICER16]." >>>> >>>> RTO reovery is done in slow start. The last sentence is confusing as >>>> there is no (new) slow-start after RTO recovery (or more precisely >>>> slow start continues until cwnd > ssthresh). Do you mean: if/when slow >>>> start still continues after RTO Recovery has repaired lost segments, >>>> it may cause burst losses again? >>> I mean the slow start after (the start of) RTO recovery. HTH >> >> Tnx. I'd appreciate if the text could be clarified to reflect this more >> accurately. Maybe something along the lines(?): >> >> "Then the RTO recovery in slow start could cause burst >> losses again that severely degrades performance [POLICER16]." >> >>>> >>>> Example 3: >>>> "If the reordering degree is beyond DupThresh, the DUPACK- >>>> counting can cause a spurious fast recovery and unnecessary >>>> congestion window reduction. To mitigate the issue, [RFC4653] >>>> adjusts DupThresh to half of the inflight size to tolerate the >>>> higher degree of reordering. However if more than half of the >>>> inflight is lost, then the sender has to resort to RTO recovery." >>>> >>>> This seems to be somewhat incorrect description of TCP-NCR specified in >>>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending >>>> new data segments on DupAcks that makes it likely to avoid an RTO in >>>> the given example scenario, if not too many of the the new data >>>> segments triggered by Extended Limited Transmit are lost. >>> sorry I don't see how the text is wrong describing RFC4653, >>> specifically the algorithm in adjusting ssthresh >> >> To my understanding RFC4653 initializes DupThresh to half of the inflight >> size in the beginning of the Extended Limited Transmit. Then on each >> DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd >> worth of DupAcks are received before packet loss is declared (or >> reordering detected). So, if I am not incorrect, loss of a half of the >> inflight does not necessarily result in RTO recovery with TCP-NCR. > Could you suggest the text you'd like on NCR description. I'm not an expert nor closely acquainted with NCR. There might be many different packet loss patterns that may affect the behavior. So, my advice is to simply drop the last sentence starting with "However ...", because it seems incorrect and replace the second but last sentence: To mitigate the issue, [RFC4653] adjusts DupThresh to half of the inflight size to tolerate the higher degree of reordering. --> To mitigate the issue, TCP-NCR [RFC4653] increases the DupThresh from the current fixed value of three duplicate ACKs [RFC5681] to approximately a congestion window of data having left the network. >>>> >>>> Sec. 3.5: >>>> >>>> "For example, consider a simple case where one >>>> segment was sent with an RTO of 1 second, and then the application >>>> writes more data, causing a second and third segment to be sent right >>>> before the RTO of the first segment expires. Suppose only the first >>>> segment is lost. Without RACK, upon RTO expiration the sender marks >>>> all three segments as lost and retransmits the first segment. When >>>> the sender receives the ACK that selectively acknowledges the second >>>> segment, the sender spuriously retransmits the third segment." >>>> >>>> This seems incorrect. When the sender receives the ACK that selectively >>>> acknowledges the second segment, it is a DupAck as per RFC 6675 and does >>>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the >>>> rexmit of the third segment is not allowad until the cumulative ACK of >>>> the first segment arrives. >>> I don't see where RFC6675 forbids growing cwnd. Even if it does, I >>> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly >>> indicates a delivery has been made. >> >> SACKed sequences with DUpAcks indicate that those sequences were >> delivered but it does not tell when they were sent. The basic principle >> of slow start is to reliably determine the available network capacity >> during slow start. Therefore, slow start must ensure it uses only >> segments sent during the slow start to increase cwnd. Otherwise, a TCP >> sender may encounter exactly the problem of unnecessary retransmission >> envisioned in this example of RACK-TCP draft (and increase cwnd on not >> valid Acks). >> >> RFC 6675 does re-specify DupAck with SACK option but it does not include >> the rule for slow start. Slow start is specified in RFC 5681. It is >> crystal clear in allowing increase in cwnd only on cumulative >> Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, >> page 6: >> >> During slow start, a TCP increments cwnd by at most SMSS bytes for >> each ACK received that cumulatively acknowledges new data. >> >> Maybe this example in the RACK-TLP draft was inspired by a incorrect >> implementation of SACK-based loss recovery? >> >> FYI: when we were finalizing RFC 6675 I suggested including also an >> algorithm for RTO recovery with SACK in RFC 6675. The reason was exactly >> that it might be not easy to gather info from multiple documents and >> hence help the implementor to have all necessary advice in a single >> document. This unfortunately did not get realized though. > > I am honestly lost quibbling these RFC6675 implementations and feeling > pedantic to these standards largely serve as guiding principles > instead of line-by-line code. Is cwnd one packet bigger or smaller in > this example making any different in advancing the Internet's > capability to do better loss detection. I do not think so. Sorry, I don't understand what was quibbling here. I believe I did not argue anything about cwnd size with this example at hand in Sec. 3.5. My point is that it describes incorrect slow start behavior. Correctly implemented slow start does not have the problem illustriated in the example. > At this point please suggest a text you like to change. That is simple. Please remove the description of the behavior without RACK. Or correct it: the behavior would be exactly the same as with RACK, but the reason for not unnecessarily retransmitting third segment can be described to be different. And, please correct also the description with RACK. With RACK, third segment does not get unnecessarly rexmitted for the reason already indicated and also because cwnd=1 MSS. And, no new segments are allowed either by cwnd=1. Please remove also the last paragraph of the Sec. 3.5, it being also incorrect description of behavior. BR, /Markku >> >> BR, >> >> /Markku >> >>>> >>>> Best regards, >>>> >>>> /Markku >>>> >>>> >>>> >>>> On Mon, 16 Nov 2020, The IESG wrote: >>>> >>>>> >>>>> The IESG has received a request from the TCP Maintenance and Minor Extensions >>>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection >>>>> algorithm for TCP' >>>>> as Proposed Standard >>>>> >>>>> The IESG plans to make a decision in the next few weeks, and solicits final >>>>> comments on this action. Please send substantive comments to the >>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may >>>>> be sent to iesg@ietf.org instead. In either case, please retain the beginning >>>>> of the Subject line to allow automated sorting. >>>>> >>>>> Abstract >>>>> >>>>> >>>>> This document presents the RACK-TLP loss detection algorithm for TCP. >>>>> RACK-TLP uses per-segment transmit timestamps and selective >>>>> acknowledgements (SACK) and has two parts: RACK ("Recent >>>>> ACKnowledgment") starts fast recovery quickly using time-based >>>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") >>>>> leverages RACK and sends a probe packet to trigger ACK feedback to >>>>> avoid retransmission timeout (RTO) events. Compared to the widely >>>>> used DUPACK threshold approach, RACK-TLP detects losses more >>>>> efficiently when there are application-limited flights of data, lost >>>>> retransmissions, or data packet reordering events. It is intended to >>>>> be an alternative to the DUPACK threshold approach. >>>>> >>>>> >>>>> >>>>> >>>>> The file can be obtained via >>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ >>>>> >>>>> >>>>> >>>>> No IPR declarations have been submitted directly on this I-D. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> tcpm mailing list >>>>> tcpm@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>> >>> > From nobody Wed Dec 9 14:08:45 2020 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 789B03A11F1 for ; Wed, 9 Dec 2020 14:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 jHQm4FR4qOcM for ; Wed, 9 Dec 2020 14:08:41 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 B27163A138C for ; Wed, 9 Dec 2020 14:08:41 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id j26so2094390qtq.8 for ; Wed, 09 Dec 2020 14:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=ICIy6Tan6wTg/WKQi1lNesckpl35li7xHN7SQBEV8Es=; b=PtrKEcE8ZqTmM0W9VWxJoSbAvsdHlkZXHOWLX5/MThPpU41iN5M6O4hFqZtsh5laRD s9h+hbDxLK0W/GKYEG31BpkJf/TvIwVhr4g7JzVKj6rnxphhpvpqDZPF+YBICcCmKalT 3nyoaLj8FjzsddM56DrM0PY+06vNlE1PXriPrMbN4mkRjx4uwz1HLgvXIqnFNOG72+h6 qgSZklqgqM8iJZrmxw7hnnVIK2E8ItvS5rNdCYXOD0kVvr081hTVs4xPN4x2devhtnTR Od5AHe6EuJkqv8xwodJwwcGUFiXSgxGn88bS06DJ5OL+4DWhbybHUySQc1gXllrNPcKt sgCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=ICIy6Tan6wTg/WKQi1lNesckpl35li7xHN7SQBEV8Es=; b=IPSo3mqO6M9ZflzmPXWL/Q+h5OrVS7ydUuLN0abOC9JQ02585Ezq0q6TOoJ1dk3ate dy9cjoh/0dh+Mq2DcsW2GW/LO7dptMjCCh5g3E6Um0+NanynL3PUbdNxNAQ7i1BEkliR asu3MosDerifUu1HWq+Y4R895rZa5VrlSVsvvZtFEYc3Tt7mLZgsJT2RLSebNeTJv7bO DtxNTBjVdXYwtQ5RSD6dHqIDwXXmPY3Ms0XT7u07vPXNdMpjwuHRBL5RZSfA8yjUds0O Y6tb4PW6475jPFJ/yPmZpkBGaAnMgZnyiSfDzQZdInOn/MI2+JvQS+Iqj8soGf1q6+OP E6Bg== X-Gm-Message-State: AOAM530MFrjchPb7QBCUlkAHuwXMDVcx8Avcisd2eMmcA4zM8txDXg+c nKuMVPaZ5BOUgZlfJzotZPPrne5MJH48wrnm X-Google-Smtp-Source: ABdhPJwUw9VkCHWtgl41Se/weZXW+7yVyw9ooZNdEhkgZeAB0VJXDLcAZcoQ/97yyCUNCOL0yt5iKg== X-Received: by 2002:ac8:5ccc:: with SMTP id s12mr5465891qta.364.1607551720181; Wed, 09 Dec 2020 14:08:40 -0800 (PST) Received: from [192.168.1.114] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id a194sm859329qkc.70.2020.12.09.14.08.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 14:08:39 -0800 (PST) To: tcpm IETF list From: Wesley Eddy Message-ID: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> Date: Wed, 9 Dec 2020 17:08:37 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------B8F56A5E32F7F8BFBA8905A6" Content-Language: en-US Archived-At: Subject: [tcpm] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 22:08:44 -0000 This is a multi-part message in MIME format. --------------B8F56A5E32F7F8BFBA8905A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit During the IETF 109 meeting, we discussed what the 793bis document should say regarding the congestion control algorithm support expected for TCP implementations. For reference, the current draft says: 3.7.2.  TCP Congestion Control    RFC 1122 required implementation of Van Jacobson's congestion control    algorithm combining slow start with congestion avoidance. RFC 2581    provided IETF Standards Track description of this, along with fast    retransmit and fast recovery.  RFC 5681 is the current description of    these algorithms and is the current standard for TCP congestion    control.    A TCP endpoint MUST implement RFC 5681 (MUST-19).    Explicit Congestion Notification (ECN) was defined in RFC 3168 and is    an IETF Standards Track enhancement that has many benefits [47].    A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-    8). I think the sense of what people might agree that it should say is something like this (with changes marked in red): 3.7.2.  TCP Congestion Control    RFC 2914 explains the importance of congestion control for the Internet.    RFC 1122 required implementation of Van Jacobson's congestion control    algorithm combining slow start with congestion avoidance. RFC 2581    provided IETF Standards Track description of this, along with fast    retransmit and fast recovery.  RFC 5681 is the current description of    these algorithms and is the current standard for TCP congestion    control. A TCP endpoint MUST implement at least some basic congestion control algorithm suitable to avoid creating congestion collapse conditions (MUST-19). RFC 5681 is an exemplary algorithm on the IETF Standards Track that is broadly applicable.  Multiple other suitable algorithms exist and have been widely used.  CUBIC [RFC8312] and BBR are prominent examples that have been discussed at length in the IETF but not yet standardized.  Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint.    Explicit Congestion Notification (ECN) was defined in RFC 3168 and is    an IETF Standards Track enhancement that has many benefits [47].    A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-    8). This is an attempt at synthesizing from comments during the meeting (both audio and jabber chat) from Jana Iyengar, Jonathan Morton, Martin Duke, Praveen Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt Mathis, and Michael Scharf.  I think there is broad agreement that we wanted to move away from requiring 5681, but did want to cite it as a perfectly fine example or default, but also wanted to explicitly permit other reasonable choices at an implementer's discretion. Please discuss, especially if you disagree or have better ways to phrase this. --------------B8F56A5E32F7F8BFBA8905A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

During the IETF 109 meeting, we discussed what the 793bis document should say regarding the congestion control algorithm support expected for TCP implementations.

For reference, the current draft says:

3.7.2.  TCP Congestion Control

   RFC 1122 required implementation of Van Jacobson's congestion control
   algorithm combining slow start with congestion avoidance.  RFC 2581
   provided IETF Standards Track description of this, along with fast
   retransmit and fast recovery.  RFC 5681 is the current description of
   these algorithms and is the current standard for TCP congestion
   control.

   A TCP endpoint MUST implement RFC 5681 (MUST-19).

   Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
   an IETF Standards Track enhancement that has many benefits [47].

   A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-
   8).

I think the sense of what people might agree that it should say is something like this (with changes marked in red):

3.7.2.  TCP Congestion Control

   RFC 2914 explains the importance of congestion control for the Internet.

   RFC 1122 required implementation of Van Jacobson's congestion control
   algorithm combining slow start with congestion avoidance.  RFC 2581
   provided IETF Standards Track description of this, along with fast
   retransmit and fast recovery.  RFC 5681 is the current description of
   these algorithms and is the current standard for TCP congestion
   control.

   A TCP endpoint MUST implement at least some basic congestion control algorithm suitable to avoid creating congestion collapse conditions (MUST-19). RFC 5681 is an exemplary algorithm on the IETF Standards Track that is broadly applicable.  Multiple other suitable algorithms exist and have been widely used.  CUBIC [RFC8312] and BBR are prominent examples that have been discussed at length in the IETF but not yet standardized.  Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. 

   Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
   an IETF Standards Track enhancement that has many benefits [47].

   A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-
   8).

This is an attempt at synthesizing from comments during the meeting (both audio and jabber chat) from Jana Iyengar, Jonathan Morton, Martin Duke, Praveen Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt Mathis, and Michael Scharf.  I think there is broad agreement that we wanted to move away from requiring 5681, but did want to cite it as a perfectly fine example or default, but also wanted to explicitly permit other reasonable choices at an implementer's discretion.

Please discuss, especially if you disagree or have better ways to phrase this.


--------------B8F56A5E32F7F8BFBA8905A6-- From nobody Wed Dec 9 14:45:00 2020 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 542C13A1241 for ; Wed, 9 Dec 2020 14:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 cYSxwHJx4wEV for ; Wed, 9 Dec 2020 14:44:55 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640120.outbound.protection.outlook.com [40.107.64.120]) (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 AC6973A17CC for ; Wed, 9 Dec 2020 14:44:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FyQVsvkESFlf84Ncdb32Lr/BJ22mf+3sN9gHVXPd6eina1LBtibuIMvIwG4sbpGuyeYoJHVBSk1/5/fTfVW8OAm52A6xvd1644apjsaETu053aOZAQVCUflXxtdPzXYr5Er4zePqk2j9Q3H6nnY/0Hhba8muIkZ62c7kVN1LmUFouLm3QZQJernhWynYa6ZFSN+QxrAG5K/2uZPYf1ZIzf8EY5uwWdaIU+B2cGY7pyKkRe9DSTaoPeJJuXAnYcWq6iFZbmxfcZm5igI5N7P9l4HmGVJCb9SSckiv0IYM8Pe1ElmcL1KjBIBq8W05D8RFEKz2Xtb94D/HfcX+RL1e1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZSTiytkJp4acX09sylNV4MPv+vjpsxwv+/wwoOoxHw=; b=oDDy0MOb8sKnFOLbZGL7DBIOtpsCqnkNdDG6XDnnuXtG7jyZEcOYdnGSyBn8eT+iTyceSIGif3GhWeMMfRx0ulNTb6KqRXiRnw8WDginJOfovEGn3GxH4HgdcgWZPlUs8Ibn8YYqpFyIFXUcxnueMKe2kpx+9w+peJvMzKWMS0egtxsYmnhOF2JicdFZIqgJW9EkviqL05be6e9ZiFR9KcjPBBTagvPJwBSSUJjdADZXkkXe4Bc5FGneagXSNfCC3cBB/ABl6U6TuhMCVTdYNzq+Ns/Awo9Wc9ixQWrTMSrfYyKDDvoosjekYGRasRpAMFuAaX7DBt/xCnSWh3FTVg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nZSTiytkJp4acX09sylNV4MPv+vjpsxwv+/wwoOoxHw=; b=htMs9MugL/a2uNocNOp5mg0FT6f1w2K82pBbE+6giIhIva2FGLQ97kr423v6v7kkTErl5SNyRyDYizYPiSBUwBefWE6tDM+yqVbJktKV5rPiN0jwdqZ091NgdJLLWYG0S4+e3FgQhfNSL+yYpFQ2P67LqPG39yg5Hvh9U6F47Aw= Received: from (2603:10b6:804:14::18) by SN6PR00MB0429.namprd00.prod.outlook.com (2603:10b6:805:d::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3693.0; Wed, 9 Dec 2020 22:44:45 +0000 Received: from SN2PR00MB0176.namprd00.prod.outlook.com ([fe80::2c17:5c09:18e:90a1]) by SN2PR00MB0176.namprd00.prod.outlook.com ([fe80::2c17:5c09:18e:90a1%2]) with mapi id 15.20.3698.000; Wed, 9 Dec 2020 22:44:45 +0000 From: Praveen Balasubramanian To: "wes@mti-systems.com" , "tcpm@ietf.org" Thread-Topic: [EXTERNAL] [tcpm] 793bis wording on congestion control Thread-Index: AQHWznfoQapcHHMQkUyU0sWJ1cXfNanvXDEg Date: Wed, 9 Dec 2020 22:44:45 +0000 Message-ID: References: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> In-Reply-To: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=b7a24433-5b11-46c7-862d-a2e4fb14f799; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-09T22:42:25Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: mti-systems.com; dkim=none (message not signed) header.d=none;mti-systems.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:a:95ce:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: bab14661-1f80-43ca-39d7-08d89c9406a6 x-ms-traffictypediagnostic: SN6PR00MB0429: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZDW9K5mSNRbmegG/k6kG0aP44SkqLp6OZ2Ok4ouO0abxUjN5InSiW+fUKrkSBjarT6akyAtRs+ltQRdy9Mnmwb++P8MSVGKRNc9Ao9Y91w3tP/PPzw7VocPNqdEhzQbr5J9ifNIdvMJwcg5B1dXv/6YzEfwPy+T0FTXAQ5mSIy/mx4MF15jv2FUL3krzYTjtPFwAiuetnHPK9IHIsXS14oCRx+qMJuJIUBOdt8QwEWcENNSlhg163yRPCIoNgVh0CDafwEdBgPJuGX/Z6/ZXm1gjheoR2iObbnNwdmWq5+fdCRmqe6qp8WEYF0IURl6xKB8Zc0KRoxF580q/gzn/dv78UXShjAXCR04cdMtQYdHhEteaHFTtyGV9R52jNBDPboQP9919UWPkvp9rkmDkTA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN2PR00MB0176.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(376002)(366004)(53546011)(64756008)(66446008)(33656002)(71200400001)(8676002)(82950400001)(55016002)(66556008)(66946007)(82960400001)(8936002)(66574015)(10290500003)(86362001)(9686003)(52536014)(110136005)(83380400001)(508600001)(2906002)(8990500004)(5660300002)(186003)(76116006)(6506007)(66476007)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?MEJoYk1ack1zRk1URHRpZzRvUGhSdGFrSTNyZXVoaStmU2E4QWtwZ2NJK21o?= =?utf-8?B?Z0oraVAyZFpVUjkyYitlNWR0NU5LM2lBbERGMHRTK2g4UzRiN3M3OGg2Qi9p?= =?utf-8?B?ZVNGVWZaNmpyVTVhNC9lcDRyM1pLVWpRcnNFR2hLZmx1cndhVy8weGtMSDgz?= =?utf-8?B?bzBDZTNGdVZSODBsMDJUd0pqeE8wMjBVb2xvc3Y1ay82RW5qSENPS1dMVGF2?= =?utf-8?B?Qm1NeHFJenF2N094RzFDSzQ0eXRZdTBNWkVaL2p6NnRrbmY2aGdnRk9raGZw?= =?utf-8?B?SURDNHp1M3g3aW9EbFB5K1R0Qi9KcG9FbUZrcWdiNXNkeDNBYjZ1TDJlVWZX?= =?utf-8?B?eTloQUsyMUFIdCtOdzNtU2ZpNVphcDMrZ3ROdFBTUDFtSm1oWi9BVnc5T2hz?= =?utf-8?B?WTNWTU1MV2c3ZVR0MFF4a21ZcVcydmJhVWFNandpaU9Pa1djNTFiamJuSmJz?= =?utf-8?B?LzRZaGVIWlZDbGdTNHF0QUd4YURGSHlUdkhNVzNGTVYrTWFoK3pIcFdNQkpC?= =?utf-8?B?UG13endaNHE1VEIzcDFaakRXVERjdHc4dHR0YTZ1N3VucWNQbEZIWXgxazNN?= =?utf-8?B?K3Q4TEF0dHA5WkZycm5rcmRLd2wzSmVJNzIwVkFEWk5IQjY2dlFTaVc4c1h5?= =?utf-8?B?WHQ3eWpTNEhRckJoWnE5YjM0cWJ0aUJWMmwzWU44UnAvcG45QzVaSm1Fc2Vk?= =?utf-8?B?d0plOGlLdHBXdnp6S3o4c2R1M2cvVW5aUWxqcTUwN2pTMU1TLzZCbXUvekl0?= =?utf-8?B?MGVSdXhTTmlZeHNRQjZNQ1VXMG1CK3pNRlhFOWJJTU9CTkdyMEt1Y1VKWDc1?= =?utf-8?B?cmJZMlZleEZIY0llOXhtamFmTzdJWUxlU1FqYy9jSEJiMmVCcmhqU2JRSHFu?= =?utf-8?B?eUcwaTJSQjF4UVBTek04d1FDWUhXRnZqMm05ZzZJNDZ1bXVjYUtIR3FuTDd0?= =?utf-8?B?aWdidVVnbFZtTS93Q3kzM0ttYW51a3BYRWFrQ2FNRFVTcWVVcFkrV09BWitC?= =?utf-8?B?NUNDa1RIckdFRXkzTmpBNGZMN0dja2N6bXJlLzgxalpQMVlRTTlPWHBqbjNN?= =?utf-8?B?cnN6TWFzMnR4c21BWVplazA1azBBZVJrSE4rUEFLNHlFbytTbkZZU3BCU3li?= =?utf-8?B?LytrUENlM1hlQ1hhYmxFeVY2Y0cxSVFkWk9sTlZNQXpiS2pHcUFuUnFuN2VR?= =?utf-8?B?cmlmNDV5V1BoNkdYT0VsUGhhaTFlT0dpZmE5K3RCTVQzTGlCbDFONWVDSyth?= =?utf-8?B?cUxlYWppZFZEU1JpTmRKRS9DZDlLNlc2SHd3WUhYcE5mWm10Sm5VS09BQmp3?= =?utf-8?B?RUdodGtOOHJvbllDNlBRYno2RGF6T01vSEZQNzZkbEN4N0NDd0hIMFF3WXZj?= =?utf-8?B?MzV4NWkxZkJNT3VYdVNoSHBhK0ZjaW1zNCtsNi9xY3RLM0d3bUJPclB2c01y?= =?utf-8?B?VjllYXFacU1uSWIrK1c2amh6bkEzWkZVZUJKUGNUUDFpK05rcE1taXpVcW1F?= =?utf-8?Q?t0y2fbLXVdSkaQc+MsuGtySGPp/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN2PR00MB01769C238354FEB63479E2B1B6CC9SN2PR00MB0176namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN2PR00MB0176.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bab14661-1f80-43ca-39d7-08d89c9406a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 22:44:45.2615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CKyyQmzdiJbAAqBoLmqmMyUpCGY9XAnrKqVuiCXF4YVzZjhaEleTL51vwv7sbe+lr5ZhCdpCOKOI+eLtk21CHhVP8U0s0ircJtxoggHwMjk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0429 Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 22:44:58 -0000 --_000_SN2PR00MB01769C238354FEB63479E2B1B6CC9SN2PR00MB0176namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBsb29rcyBnb29kIHRvIG1lIGV4Y2VwdCB0aGF0IHRoZSByZWZlcmVuY2VzIHRvIENVQklD IGFuZCBCQlIgY2FuIGJlY29tZSBkYXRlZCBvdmVyIHRpbWUgYW5kIG1pZ2h0IGFsc28gZ2V0IHN0 YW5kYXJkaXplZC4gU28gSeKAmWQgb21pdCB0aGlzIHNlbnRlbmNlIOKAnENVQklDIFtSRkM4MzEy XSBhbmQgQkJSIGFyZSBwcm9taW5lbnQgZXhhbXBsZXMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2Vk IGF0IGxlbmd0aCBpbiB0aGUgSUVURiBidXQgbm90IHlldCBzdGFuZGFyZGl6ZWQu4oCdDQoNCkZy b206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFdlc2xleSBFZGR5 DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDksIDIwMjAgMjowOSBQTQ0KVG86IHRjcG0gSUVU RiBsaXN0IDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBbdGNwbV0gNzkzYmlz IHdvcmRpbmcgb24gY29uZ2VzdGlvbiBjb250cm9sDQoNCg0KRHVyaW5nIHRoZSBJRVRGIDEwOSBt ZWV0aW5nLCB3ZSBkaXNjdXNzZWQgd2hhdCB0aGUgNzkzYmlzIGRvY3VtZW50IHNob3VsZCBzYXkg cmVnYXJkaW5nIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtIHN1cHBvcnQgZXhwZWN0 ZWQgZm9yIFRDUCBpbXBsZW1lbnRhdGlvbnMuDQoNCkZvciByZWZlcmVuY2UsIHRoZSBjdXJyZW50 IGRyYWZ0IHNheXM6DQozLjcuMi4gIFRDUCBDb25nZXN0aW9uIENvbnRyb2wNCg0KICAgUkZDIDEx MjIgcmVxdWlyZWQgaW1wbGVtZW50YXRpb24gb2YgVmFuIEphY29ic29uJ3MgY29uZ2VzdGlvbiBj b250cm9sDQogICBhbGdvcml0aG0gY29tYmluaW5nIHNsb3cgc3RhcnQgd2l0aCBjb25nZXN0aW9u IGF2b2lkYW5jZS4gIFJGQyAyNTgxDQogICBwcm92aWRlZCBJRVRGIFN0YW5kYXJkcyBUcmFjayBk ZXNjcmlwdGlvbiBvZiB0aGlzLCBhbG9uZyB3aXRoIGZhc3QNCiAgIHJldHJhbnNtaXQgYW5kIGZh c3QgcmVjb3ZlcnkuICBSRkMgNTY4MSBpcyB0aGUgY3VycmVudCBkZXNjcmlwdGlvbiBvZg0KICAg dGhlc2UgYWxnb3JpdGhtcyBhbmQgaXMgdGhlIGN1cnJlbnQgc3RhbmRhcmQgZm9yIFRDUCBjb25n ZXN0aW9uDQogICBjb250cm9sLg0KDQogICBBIFRDUCBlbmRwb2ludCBNVVNUIGltcGxlbWVudCBS RkMgNTY4MSAoTVVTVC0xOSkuDQoNCiAgIEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9u IChFQ04pIHdhcyBkZWZpbmVkIGluIFJGQyAzMTY4IGFuZCBpcw0KICAgYW4gSUVURiBTdGFuZGFy ZHMgVHJhY2sgZW5oYW5jZW1lbnQgdGhhdCBoYXMgbWFueSBiZW5lZml0cyBbNDddLg0KDQogICBB IFRDUCBlbmRwb2ludCBTSE9VTEQgaW1wbGVtZW50IEVDTiBhcyBkZXNjcmliZWQgaW4gUkZDIDMx NjggKFNITEQtDQogICA4KS4NCg0KSSB0aGluayB0aGUgc2Vuc2Ugb2Ygd2hhdCBwZW9wbGUgbWln aHQgYWdyZWUgdGhhdCBpdCBzaG91bGQgc2F5IGlzIHNvbWV0aGluZyBsaWtlIHRoaXMgKHdpdGgg Y2hhbmdlcyBtYXJrZWQgaW4gcmVkKToNCg0KMy43LjIuICBUQ1AgQ29uZ2VzdGlvbiBDb250cm9s DQoNCiAgIFJGQyAyOTE0IGV4cGxhaW5zIHRoZSBpbXBvcnRhbmNlIG9mIGNvbmdlc3Rpb24gY29u dHJvbCBmb3IgdGhlIEludGVybmV0Lg0KDQogICBSRkMgMTEyMiByZXF1aXJlZCBpbXBsZW1lbnRh dGlvbiBvZiBWYW4gSmFjb2Jzb24ncyBjb25nZXN0aW9uIGNvbnRyb2wNCiAgIGFsZ29yaXRobSBj b21iaW5pbmcgc2xvdyBzdGFydCB3aXRoIGNvbmdlc3Rpb24gYXZvaWRhbmNlLiAgUkZDIDI1ODEN CiAgIHByb3ZpZGVkIElFVEYgU3RhbmRhcmRzIFRyYWNrIGRlc2NyaXB0aW9uIG9mIHRoaXMsIGFs b25nIHdpdGggZmFzdA0KICAgcmV0cmFuc21pdCBhbmQgZmFzdCByZWNvdmVyeS4gIFJGQyA1Njgx IGlzIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uIG9mDQogICB0aGVzZSBhbGdvcml0aG1zIGFuZCBp cyB0aGUgY3VycmVudCBzdGFuZGFyZCBmb3IgVENQIGNvbmdlc3Rpb24NCiAgIGNvbnRyb2wuDQoN CiAgIEEgVENQIGVuZHBvaW50IE1VU1QgaW1wbGVtZW50IGF0IGxlYXN0IHNvbWUgYmFzaWMgY29u Z2VzdGlvbiBjb250cm9sIGFsZ29yaXRobSBzdWl0YWJsZSB0byBhdm9pZCBjcmVhdGluZyBjb25n ZXN0aW9uIGNvbGxhcHNlIGNvbmRpdGlvbnMgKE1VU1QtMTkpLiBSRkMgNTY4MSBpcyBhbiBleGVt cGxhcnkgYWxnb3JpdGhtIG9uIHRoZSBJRVRGIFN0YW5kYXJkcyBUcmFjayB0aGF0IGlzIGJyb2Fk bHkgYXBwbGljYWJsZS4gIE11bHRpcGxlIG90aGVyIHN1aXRhYmxlIGFsZ29yaXRobXMgZXhpc3Qg YW5kIGhhdmUgYmVlbiB3aWRlbHkgdXNlZC4gIENVQklDIFtSRkM4MzEyXSBhbmQgQkJSIGFyZSBw cm9taW5lbnQgZXhhbXBsZXMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGF0IGxlbmd0aCBpbiB0 aGUgSUVURiBidXQgbm90IHlldCBzdGFuZGFyZGl6ZWQuICBNYW55IFRDUCBpbXBsZW1lbnRhdGlv bnMgc3VwcG9ydCBhIHNldCBvZiBhbHRlcm5hdGl2ZSBhbGdvcml0aG1zIHRoYXQgY2FuIGJlIGNv bmZpZ3VyZWQgZm9yIHVzZSBvbiB0aGUgZW5kcG9pbnQuDQoNCiAgIEV4cGxpY2l0IENvbmdlc3Rp b24gTm90aWZpY2F0aW9uIChFQ04pIHdhcyBkZWZpbmVkIGluIFJGQyAzMTY4IGFuZCBpcw0KICAg YW4gSUVURiBTdGFuZGFyZHMgVHJhY2sgZW5oYW5jZW1lbnQgdGhhdCBoYXMgbWFueSBiZW5lZml0 cyBbNDddLg0KDQogICBBIFRDUCBlbmRwb2ludCBTSE9VTEQgaW1wbGVtZW50IEVDTiBhcyBkZXNj cmliZWQgaW4gUkZDIDMxNjggKFNITEQtDQogICA4KS4NCg0KVGhpcyBpcyBhbiBhdHRlbXB0IGF0 IHN5bnRoZXNpemluZyBmcm9tIGNvbW1lbnRzIGR1cmluZyB0aGUgbWVldGluZyAoYm90aCBhdWRp byBhbmQgamFiYmVyIGNoYXQpIGZyb20gSmFuYSBJeWVuZ2FyLCBKb25hdGhhbiBNb3J0b24sIE1h cnRpbiBEdWtlLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiwgR29ycnkgRmFpcmh1cnN0LCBCb2Ig QnJpc2NvZSwgTWF0dCBNYXRoaXMsIGFuZCBNaWNoYWVsIFNjaGFyZi4gIEkgdGhpbmsgdGhlcmUg aXMgYnJvYWQgYWdyZWVtZW50IHRoYXQgd2Ugd2FudGVkIHRvIG1vdmUgYXdheSBmcm9tIHJlcXVp cmluZyA1NjgxLCBidXQgZGlkIHdhbnQgdG8gY2l0ZSBpdCBhcyBhIHBlcmZlY3RseSBmaW5lIGV4 YW1wbGUgb3IgZGVmYXVsdCwgYnV0IGFsc28gd2FudGVkIHRvIGV4cGxpY2l0bHkgcGVybWl0IG90 aGVyIHJlYXNvbmFibGUgY2hvaWNlcyBhdCBhbiBpbXBsZW1lbnRlcidzIGRpc2NyZXRpb24uDQoN ClBsZWFzZSBkaXNjdXNzLCBlc3BlY2lhbGx5IGlmIHlvdSBkaXNhZ3JlZSBvciBoYXZlIGJldHRl ciB3YXlzIHRvIHBocmFzZSB0aGlzLg0KDQoNCg== --_000_SN2PR00MB01769C238354FEB63479E2B1B6CC9SN2PR00MB0176namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyBsb29rcyBnb29kIHRvIG1lIGV4Y2VwdCB0aGF0IHRoZSByZWZlcmVuY2Vz IHRvIENVQklDIGFuZCBCQlIgY2FuIGJlY29tZSBkYXRlZCBvdmVyIHRpbWUgYW5kIG1pZ2h0IGFs c28gZ2V0IHN0YW5kYXJkaXplZC4gU28gSeKAmWQgb21pdCB0aGlzIHNlbnRlbmNlIOKAnENVQklD IFtSRkM4MzEyXSBhbmQgQkJSIGFyZSBwcm9taW5lbnQgZXhhbXBsZXMgdGhhdCBoYXZlIGJlZW4g ZGlzY3Vzc2VkIGF0IGxlbmd0aCBpbg0KIHRoZSBJRVRGIGJ1dCBub3QgeWV0IHN0YW5kYXJkaXpl ZC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiB0Y3BtICZsdDt0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxi Pk9uIEJlaGFsZiBPZiA8L2I+DQpXZXNsZXkgRWRkeTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIERlY2VtYmVyIDksIDIwMjAgMjowOSBQTTxicj4NCjxiPlRvOjwvYj4gdGNwbSBJRVRGIGxp c3QgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0g W3RjcG1dIDc5M2JpcyB3b3JkaW5nIG9uIGNvbmdlc3Rpb24gY29udHJvbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHA+RHVyaW5nIHRoZSBJRVRGIDEwOSBtZWV0aW5nLCB3ZSBkaXNjdXNzZWQgd2hhdCB0 aGUgNzkzYmlzIGRvY3VtZW50IHNob3VsZCBzYXkgcmVnYXJkaW5nIHRoZSBjb25nZXN0aW9uIGNv bnRyb2wgYWxnb3JpdGhtIHN1cHBvcnQgZXhwZWN0ZWQgZm9yIFRDUCBpbXBsZW1lbnRhdGlvbnMu PG86cD48L286cD48L3A+DQo8cD5Gb3IgcmVmZXJlbmNlLCB0aGUgY3VycmVudCBkcmFmdCBzYXlz OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjMuNy4yLiZuYnNwOyBUQ1AgQ29uZ2Vz dGlvbiBDb250cm9sPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFJGQyAxMTIyIHJlcXVpcmVkIGlt cGxlbWVudGF0aW9uIG9mIFZhbiBKYWNvYnNvbidzIGNvbmdlc3Rpb24gY29udHJvbDxicj4NCiZu YnNwOyZuYnNwOyBhbGdvcml0aG0gY29tYmluaW5nIHNsb3cgc3RhcnQgd2l0aCBjb25nZXN0aW9u IGF2b2lkYW5jZS4mbmJzcDsgUkZDIDI1ODE8YnI+DQombmJzcDsmbmJzcDsgcHJvdmlkZWQgSUVU RiBTdGFuZGFyZHMgVHJhY2sgZGVzY3JpcHRpb24gb2YgdGhpcywgYWxvbmcgd2l0aCBmYXN0PGJy Pg0KJm5ic3A7Jm5ic3A7IHJldHJhbnNtaXQgYW5kIGZhc3QgcmVjb3ZlcnkuJm5ic3A7IFJGQyA1 NjgxIGlzIHRoZSBjdXJyZW50IGRlc2NyaXB0aW9uIG9mPGJyPg0KJm5ic3A7Jm5ic3A7IHRoZXNl IGFsZ29yaXRobXMgYW5kIGlzIHRoZSBjdXJyZW50IHN0YW5kYXJkIGZvciBUQ1AgY29uZ2VzdGlv bjxicj4NCiZuYnNwOyZuYnNwOyBjb250cm9sLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBBIFRD UCBlbmRwb2ludCBNVVNUIGltcGxlbWVudCBSRkMgNTY4MSAoTVVTVC0xOSkuPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7IEV4cGxpY2l0IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIChFQ04pIHdhcyBk ZWZpbmVkIGluIFJGQyAzMTY4IGFuZCBpczxicj4NCiZuYnNwOyZuYnNwOyBhbiBJRVRGIFN0YW5k YXJkcyBUcmFjayBlbmhhbmNlbWVudCB0aGF0IGhhcyBtYW55IGJlbmVmaXRzIFs0N10uPGJyPg0K PGJyPg0KJm5ic3A7Jm5ic3A7IEEgVENQIGVuZHBvaW50IFNIT1VMRCBpbXBsZW1lbnQgRUNOIGFz IGRlc2NyaWJlZCBpbiBSRkMgMzE2OCAoU0hMRC08YnI+DQombmJzcDsmbmJzcDsgOCkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHA+SSB0aGluayB0aGUgc2Vuc2Ugb2Yg d2hhdCBwZW9wbGUgbWlnaHQgYWdyZWUgdGhhdCBpdCBzaG91bGQgc2F5IGlzIHNvbWV0aGluZyBs aWtlIHRoaXMgKHdpdGggY2hhbmdlcyBtYXJrZWQgaW4gcmVkKTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4zLjcu Mi4mbmJzcDsgVENQIENvbmdlc3Rpb24gQ29udHJvbDxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPiZuYnNwOyZuYnNwOyBSRkMgMjkxNCBleHBsYWlucyB0aGUgaW1wb3J0YW5jZSBv ZiBjb25nZXN0aW9uIGNvbnRyb2wgZm9yIHRoZSBJbnRlcm5ldC48L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkZDIDExMjIgcmVxdWlyZWQgaW1wbGVtZW50YXRpb24gb2Yg VmFuIEphY29ic29uJ3MgY29uZ2VzdGlvbiBjb250cm9sPGJyPg0KJm5ic3A7Jm5ic3A7IGFsZ29y aXRobSBjb21iaW5pbmcgc2xvdyBzdGFydCB3aXRoIGNvbmdlc3Rpb24gYXZvaWRhbmNlLiZuYnNw OyBSRkMgMjU4MTxicj4NCiZuYnNwOyZuYnNwOyBwcm92aWRlZCBJRVRGIFN0YW5kYXJkcyBUcmFj ayBkZXNjcmlwdGlvbiBvZiB0aGlzLCBhbG9uZyB3aXRoIGZhc3Q8YnI+DQombmJzcDsmbmJzcDsg cmV0cmFuc21pdCBhbmQgZmFzdCByZWNvdmVyeS4mbmJzcDsgUkZDIDU2ODEgaXMgdGhlIGN1cnJl bnQgZGVzY3JpcHRpb24gb2Y8YnI+DQombmJzcDsmbmJzcDsgdGhlc2UgYWxnb3JpdGhtcyBhbmQg aXMgdGhlIGN1cnJlbnQgc3RhbmRhcmQgZm9yIFRDUCBjb25nZXN0aW9uPGJyPg0KJm5ic3A7Jm5i c3A7IGNvbnRyb2wuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IDxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+QSBUQ1AgZW5kcG9pbnQgTVVTVCBpbXBsZW1lbnQgPC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpyZWQiPmF0IGxlYXN0IHNvbWUgYmFzaWMgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRo bSBzdWl0YWJsZSB0byBhdm9pZCBjcmVhdGluZyBjb25nZXN0aW9uIGNvbGxhcHNlIGNvbmRpdGlv bnMgKE1VU1QtMTkpLiBSRkMgNTY4MSBpcyBhbiBleGVtcGxhcnkgYWxnb3JpdGhtIG9uIHRoZSBJ RVRGIFN0YW5kYXJkcw0KIFRyYWNrIHRoYXQgaXMgYnJvYWRseSBhcHBsaWNhYmxlLiZuYnNwOyBN dWx0aXBsZSBvdGhlciBzdWl0YWJsZSBhbGdvcml0aG1zIGV4aXN0IGFuZCBoYXZlIGJlZW4gd2lk ZWx5IHVzZWQuJm5ic3A7IENVQklDIFtSRkM4MzEyXSBhbmQgQkJSIGFyZSBwcm9taW5lbnQgZXhh bXBsZXMgdGhhdCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGF0IGxlbmd0aCBpbiB0aGUgSUVURiBidXQg bm90IHlldCBzdGFuZGFyZGl6ZWQuJm5ic3A7IE1hbnkgVENQIGltcGxlbWVudGF0aW9ucyBzdXBw b3J0DQogYSBzZXQgb2YgYWx0ZXJuYXRpdmUgYWxnb3JpdGhtcyB0aGF0IGNhbiBiZSBjb25maWd1 cmVkIGZvciB1c2Ugb24gdGhlIGVuZHBvaW50LiZuYnNwOw0KPC9zcGFuPjxicj4NCjxicj4NCiZu YnNwOyZuYnNwOyBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlvbiAoRUNOKSB3YXMgZGVm aW5lZCBpbiBSRkMgMzE2OCBhbmQgaXM8YnI+DQombmJzcDsmbmJzcDsgYW4gSUVURiBTdGFuZGFy ZHMgVHJhY2sgZW5oYW5jZW1lbnQgdGhhdCBoYXMgbWFueSBiZW5lZml0cyBbNDddLjxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyBBIFRDUCBlbmRwb2ludCBTSE9VTEQgaW1wbGVtZW50IEVDTiBhcyBk ZXNjcmliZWQgaW4gUkZDIDMxNjggKFNITEQtPGJyPg0KJm5ic3A7Jm5ic3A7IDgpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPlRoaXMgaXMgYW4gYXR0ZW1wdCBhdCBz eW50aGVzaXppbmcgZnJvbSBjb21tZW50cyBkdXJpbmcgdGhlIG1lZXRpbmcgKGJvdGggYXVkaW8g YW5kIGphYmJlciBjaGF0KSBmcm9tIEphbmEgSXllbmdhciwgSm9uYXRoYW4gTW9ydG9uLCBNYXJ0 aW4gRHVrZSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4sIEdvcnJ5IEZhaXJodXJzdCwgQm9iIEJy aXNjb2UsIE1hdHQgTWF0aGlzLCBhbmQgTWljaGFlbCBTY2hhcmYuJm5ic3A7IEkgdGhpbmsgdGhl cmUgaXMgYnJvYWQNCiBhZ3JlZW1lbnQgdGhhdCB3ZSB3YW50ZWQgdG8gbW92ZSBhd2F5IGZyb20g cmVxdWlyaW5nIDU2ODEsIGJ1dCBkaWQgd2FudCB0byBjaXRlIGl0IGFzIGEgcGVyZmVjdGx5IGZp bmUgZXhhbXBsZSBvciBkZWZhdWx0LCBidXQgYWxzbyB3YW50ZWQgdG8gZXhwbGljaXRseSBwZXJt aXQgb3RoZXIgcmVhc29uYWJsZSBjaG9pY2VzIGF0IGFuIGltcGxlbWVudGVyJ3MgZGlzY3JldGlv bi48bzpwPjwvbzpwPjwvcD4NCjxwPlBsZWFzZSBkaXNjdXNzLCBlc3BlY2lhbGx5IGlmIHlvdSBk aXNhZ3JlZSBvciBoYXZlIGJldHRlciB3YXlzIHRvIHBocmFzZSB0aGlzLjxvOnA+PC9vOnA+PC9w Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR00MB01769C238354FEB63479E2B1B6CC9SN2PR00MB0176namp_-- From nobody Wed Dec 9 15:14:38 2020 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 0710C3A00D3 for ; Wed, 9 Dec 2020 15:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 LtDeQCF-RL0b for ; Wed, 9 Dec 2020 15:14:35 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 36ED33A0045 for ; Wed, 9 Dec 2020 15:14:35 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id d3so2996157wmb.4 for ; Wed, 09 Dec 2020 15:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Y2MGUnMoSYzHdy1CCzEP79YGDojmD2FL3yGjE7qxfZM=; b=o6a5G+7LONs5BdIJqF5gi3TtVb9OnapVpihRTfCjclxEDZpWmzA7L5AiWvs5iQ/LrZ N7ikwEvUvwV0G6dgxDN6ItjCCzSkZLiTz0LbU83I4o1krlJkmnYAwoe73QGLaX86ZJj8 qOcmJI4ZyJTRU3xeAb2xTuuKs/+wZnFBGueQTuu98tZNIn63ex/S6lJLv9hYG8cn6N67 DVXs43ikUlt4KV09nwk17WVPQBuyUXsM0pOS0WAC9ioHp46OtnpK5E1DtCWxAB25JKEo M8efO3zFm5XS1QvA7eu4aVL3C8Bn8F2Wq32PiV2Ydv3V7mHK2+dAtVy5tQSS/EKCzzVA qD3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Y2MGUnMoSYzHdy1CCzEP79YGDojmD2FL3yGjE7qxfZM=; b=XqsBktIuPvrEI9pxp1Wsfyt17YGlmvN7a8XKW1Ah8s8vV1aPyHRBF8tyNU7FkRzsuu 8+buh7kSGyYH9uX2/UQ6brfeiHVO8Wu3w6MOxj53tff1jpnpV9yUPruM54XCurfmpnQ6 yZxJjWhi+SLTcA9rsk3LeKFe96TGFftXPgk7utqIeBWJ8Q0My4wemSZsQLFS60yyVGzu bQQoyeN6Nl53HQvFXfV5axX0cp2On3fRswGfm3WY0gYRsAE4v5vh60hzKbNPtR0BLQJ9 rgjN/RFlTBqB657YhVjh07ok6trr/SpkzFOStKF3xmTBLNvToGuFs74ZJBwUDX393eRI /gdQ== X-Gm-Message-State: AOAM5329AYgRa2+6M6K+aEkFB3h3UKS70UxDP9PbgMno4ILWtTKVBbdo yOkc0nigY2OAKnNMx/Dy0WbC6Q1HWhNhDREXeazqQw== X-Google-Smtp-Source: ABdhPJybVx//eE1jU3yHpvOOyKEJ5dgFupWld996MlVz/1tOQ+0QGwRnf2uSIBLDNoMKzY519PKuJwE30L/RCoi+mT4= X-Received: by 2002:a1c:6856:: with SMTP id d83mr5278486wmc.119.1607555673282; Wed, 09 Dec 2020 15:14:33 -0800 (PST) MIME-Version: 1.0 References: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> In-Reply-To: From: Yuchung Cheng Date: Wed, 9 Dec 2020 15:13:56 -0800 Message-ID: To: Praveen Balasubramanian Cc: "wes@mti-systems.com" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 23:14:37 -0000 +1 to proposed change. It might be odd to say this as a co-author of BBR. I think mentioning BBR or Cubic as prominent examples may be a bit biased. There are many prominent great congestion control (for different scope/area/type of networks) that are not possible to list them all. I would not mind if we remove 'CUBIC [RFC8312] and BBR are prominent examples that have been discussed at length in the IETF but not yet standardized. ' On Wed, Dec 9, 2020 at 2:45 PM Praveen Balasubramanian wrote: > > This looks good to me except that the references to CUBIC and BBR can bec= ome dated over time and might also get standardized. So I=E2=80=99d omit th= is sentence =E2=80=9CCUBIC [RFC8312] and BBR are prominent examples that ha= ve been discussed at length in the IETF but not yet standardized.=E2=80=9D > > > > From: tcpm On Behalf Of Wesley Eddy > Sent: Wednesday, December 9, 2020 2:09 PM > To: tcpm IETF list > Subject: [EXTERNAL] [tcpm] 793bis wording on congestion control > > > > During the IETF 109 meeting, we discussed what the 793bis document should= say regarding the congestion control algorithm support expected for TCP im= plementations. > > For reference, the current draft says: > > 3.7.2. TCP Congestion Control > > RFC 1122 required implementation of Van Jacobson's congestion control > algorithm combining slow start with congestion avoidance. RFC 2581 > provided IETF Standards Track description of this, along with fast > retransmit and fast recovery. RFC 5681 is the current description of > these algorithms and is the current standard for TCP congestion > control. > > A TCP endpoint MUST implement RFC 5681 (MUST-19). > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > an IETF Standards Track enhancement that has many benefits [47]. > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). > > I think the sense of what people might agree that it should say is someth= ing like this (with changes marked in red): > > 3.7.2. TCP Congestion Control > > RFC 2914 explains the importance of congestion control for the Interne= t. > > RFC 1122 required implementation of Van Jacobson's congestion control > algorithm combining slow start with congestion avoidance. RFC 2581 > provided IETF Standards Track description of this, along with fast > retransmit and fast recovery. RFC 5681 is the current description of > these algorithms and is the current standard for TCP congestion > control. > > A TCP endpoint MUST implement at least some basic congestion control a= lgorithm suitable to avoid creating congestion collapse conditions (MUST-19= ). RFC 5681 is an exemplary algorithm on the IETF Standards Track that is b= roadly applicable. Multiple other suitable algorithms exist and have been = widely used. CUBIC [RFC8312] and BBR are prominent examples that have been= discussed at length in the IETF but not yet standardized. Many TCP implem= entations support a set of alternative algorithms that can be configured fo= r use on the endpoint. > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > an IETF Standards Track enhancement that has many benefits [47]. > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). > > This is an attempt at synthesizing from comments during the meeting (both= audio and jabber chat) from Jana Iyengar, Jonathan Morton, Martin Duke, Pr= aveen Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt Mathis, and Micha= el Scharf. I think there is broad agreement that we wanted to move away fr= om requiring 5681, but did want to cite it as a perfectly fine example or d= efault, but also wanted to explicitly permit other reasonable choices at an= implementer's discretion. > > Please discuss, especially if you disagree or have better ways to phrase = this. > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Dec 9 16:52:34 2020 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 C3D0A3A0983 for ; Wed, 9 Dec 2020 16:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 jYtw-E53Jwgz for ; Wed, 9 Dec 2020 16:52:27 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 DA73A3A098A for ; Wed, 9 Dec 2020 16:52:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lO4ofxvS1eCUiexfuRTBxSXf8zzDyphCBG2tRkEHoKA=; b=ooRHj5ELCWmKG2+bxZ69vMEpp KGJUQ5zAHLVY63FeI6he/g9oxdZVKIXceQuVERCAmE2+viF4dKE4deXyhizdjqV97JxEKRi7CjjN4 IQez0D2QZKLX7rty87g4ZWJyAKALhoc/VBBWklX6CqGJdajOHDUithi1HdzJ6lk5l37Pr7Qek7Erv OrROvjzbpqLdWOKpqVE16nRLK5wZA880yd6zWouSzZBKfaMR2qFrJedP+huyxgSuoLNm/G7V90aTL UPSucl/zYsbHM0miCiyZiWNyl/2SdkNS9XW9Jj9It3Gc/e3dohVZv6zf6X9Zl4Yhlq/dSatDl+R9/ zQI8L2qZw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59963 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knABx-002QGc-T9; Wed, 09 Dec 2020 19:52:27 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_369CA418-9C63-438A-942B-BEEDEC8CC829" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Wed, 9 Dec 2020 16:52:21 -0800 Cc: Wes Eddy , "tcpm@ietf.org" Message-Id: References: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> To: Praveen Balasubramanian X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 00:52:33 -0000 --Apple-Mail=_369CA418-9C63-438A-942B-BEEDEC8CC829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, I don=E2=80=99t agree with this change. The last I recall, the basic rule was =E2=80=9CCC as per RFC 5681=E2=80=9D= , which allows for other algorithms as long as they=E2=80=99re no more = aggressive (sec 3). I see no reason to drop that requirement, which is what the text below = does. The text below implies that =E2=80=9Cwell, any CC will play = nice=E2=80=9D, but we know that=E2=80=99s not the case. Joe > On Dec 9, 2020, at 2:44 PM, Praveen Balasubramanian = wrote: >=20 > This looks good to me except that the references to CUBIC and BBR can = become dated over time and might also get standardized. So I=E2=80=99d = omit this sentence =E2=80=9CCUBIC [RFC8312] and BBR are prominent = examples that have been discussed at length in the IETF but not yet = standardized.=E2=80=9D > =20 > From: tcpm > On = Behalf Of Wesley Eddy > Sent: Wednesday, December 9, 2020 2:09 PM > To: tcpm IETF list > > Subject: [EXTERNAL] [tcpm] 793bis wording on congestion control > =20 > During the IETF 109 meeting, we discussed what the 793bis document = should say regarding the congestion control algorithm support expected = for TCP implementations. >=20 > For reference, the current draft says: >=20 > 3.7.2. TCP Congestion Control >=20 > RFC 1122 required implementation of Van Jacobson's congestion = control > algorithm combining slow start with congestion avoidance. RFC 2581 > provided IETF Standards Track description of this, along with fast > retransmit and fast recovery. RFC 5681 is the current description = of > these algorithms and is the current standard for TCP congestion > control. >=20 > A TCP endpoint MUST implement RFC 5681 (MUST-19). >=20 > Explicit Congestion Notification (ECN) was defined in RFC 3168 and = is > an IETF Standards Track enhancement that has many benefits [47]. >=20 > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). > I think the sense of what people might agree that it should say is = something like this (with changes marked in red): >=20 > 3.7.2. TCP Congestion Control >=20 > RFC 2914 explains the importance of congestion control for the = Internet. >=20 > RFC 1122 required implementation of Van Jacobson's congestion = control > algorithm combining slow start with congestion avoidance. RFC 2581 > provided IETF Standards Track description of this, along with fast > retransmit and fast recovery. RFC 5681 is the current description = of > these algorithms and is the current standard for TCP congestion > control. >=20 > A TCP endpoint MUST implement at least some basic congestion = control algorithm suitable to avoid creating congestion collapse = conditions (MUST-19). RFC 5681 is an exemplary algorithm on the IETF = Standards Track that is broadly applicable. Multiple other suitable = algorithms exist and have been widely used. CUBIC [RFC8312] and BBR are = prominent examples that have been discussed at length in the IETF but = not yet standardized. Many TCP implementations support a set of = alternative algorithms that can be configured for use on the endpoint. =20= >=20 > Explicit Congestion Notification (ECN) was defined in RFC 3168 and = is > an IETF Standards Track enhancement that has many benefits [47]. >=20 > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > 8). >=20 > This is an attempt at synthesizing from comments during the meeting = (both audio and jabber chat) from Jana Iyengar, Jonathan Morton, Martin = Duke, Praveen Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt = Mathis, and Michael Scharf. I think there is broad agreement that we = wanted to move away from requiring 5681, but did want to cite it as a = perfectly fine example or default, but also wanted to explicitly permit = other reasonable choices at an implementer's discretion. >=20 > Please discuss, especially if you disagree or have better ways to = phrase this. >=20 > =20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_369CA418-9C63-438A-942B-BEEDEC8CC829 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all,

I don=E2=80=99t = agree with this change.

The last I recall, the basic rule was =E2=80=9CCC as per RFC = 5681=E2=80=9D, which allows for other algorithms as long as they=E2=80=99r= e no more aggressive (sec 3).

I see no reason to drop that = requirement, which is what the text below does. The text below implies = that =E2=80=9Cwell, any CC will play nice=E2=80=9D, but we know that=E2=80= =99s not the case.

Joe

On Dec 9, 2020, at 2:44 PM, Praveen = Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> = wrote:

This looks good to me except that the references = to CUBIC and BBR can become dated over time and might also get = standardized. So I=E2=80=99d omit this sentence =E2=80=9CCUBIC [RFC8312] = and BBR are prominent examples that have been discussed at length in the = IETF but not yet standardized.=E2=80=9D
 
From: tcpm <tcpm-bounces@ietf.org> On Behalf = Of Wesley Eddy
Sent: Wednesday, December 9, 2020 = 2:09 PM
To: tcpm IETF list <tcpm@ietf.org>
Subject: [EXTERNAL] [tcpm] 793bis = wording on congestion control
 

During the IETF 109 meeting, we discussed what the 793bis = document should say regarding the congestion control algorithm support = expected for TCP implementations.

For reference, the current draft says:

3.7.2.  = TCP Congestion Control

   RFC = 1122 required implementation of Van Jacobson's congestion control
   algorithm combining slow start with congestion = avoidance.  RFC 2581
   provided IETF = Standards Track description of this, along with fast
   retransmit and fast recovery.  RFC 5681 is = the current description of
   these algorithms = and is the current standard for TCP congestion
   = control.

   A TCP endpoint MUST = implement RFC 5681 (MUST-19).

   = Explicit Congestion Notification (ECN) was defined in RFC 3168 and is
   an IETF Standards Track enhancement that has = many benefits [47].

   A TCP = endpoint SHOULD implement ECN as described in RFC 3168 (SHLD-
   8).

I think the sense of = what people might agree that it should say is something like this (with = changes marked in red):

3.7.2.  TCP Congestion Control

   RFC 2914 = explains the importance of congestion control for the = Internet.

   = RFC 1122 required implementation of Van Jacobson's congestion control
   algorithm combining slow start with congestion = avoidance.  RFC 2581
   provided IETF = Standards Track description of this, along with fast
   retransmit and fast recovery.  RFC 5681 is = the current description of
   these algorithms = and is the current standard for TCP congestion
   = control.

   A= TCP endpoint MUST implement at least some basic congestion control algorithm = suitable to avoid creating congestion collapse conditions (MUST-19). RFC = 5681 is an exemplary algorithm on the IETF Standards Track that is = broadly applicable.  Multiple other suitable algorithms exist and = have been widely used.  CUBIC [RFC8312] and BBR are prominent = examples that have been discussed at length in the IETF but not yet = standardized.  Many TCP implementations support a set of = alternative algorithms that can be configured for use on the = endpoint.  

   Explicit Congestion Notification (ECN) was = defined in RFC 3168 and is
   an IETF Standards = Track enhancement that has many benefits [47].

   A TCP endpoint SHOULD implement ECN as described = in RFC 3168 (SHLD-
   8).

This is an attempt at = synthesizing from comments during the meeting (both audio and jabber = chat) from Jana Iyengar, Jonathan Morton, Martin Duke, Praveen = Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt Mathis, and Michael = Scharf.  I think there is broad agreement that we wanted to move = away from requiring 5681, but did want to cite it as a perfectly fine = example or default, but also wanted to explicitly permit other = reasonable choices at an implementer's discretion.

Please discuss, especially if you = disagree or have better ways to phrase this.

 

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

= --Apple-Mail=_369CA418-9C63-438A-942B-BEEDEC8CC829-- From nobody Wed Dec 9 19:39:05 2020 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 4AB0B3A0936 for ; Wed, 9 Dec 2020 19:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 RyHA4C-3NBSe for ; Wed, 9 Dec 2020 19:39:02 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 E6FF23A095F for ; Wed, 9 Dec 2020 19:39:01 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id j26so2629364qtq.8 for ; Wed, 09 Dec 2020 19:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=mLwLsWkgiMvkTOH2okOHyFXrrtzhJG33CfPLu4dBvc0=; b=x30AUT63fuIDPGxwsdLirlglvzqmEkGbiyOEppON/troHb6RYcL83nZGZwpHkC+3bP mzYSFRQLdFemdY1rsRvbJdSHH7kFQ8cUPLsZ0eWq1FIspEuDXGwZYGZ/1zLFlbK3eZpl u61wKgPhCc7N9caqgRLFXldtVpWNPiPraBhvRy0MuPtuDrtfBfr3TdZHfQjnqr2ASbg+ qGJnVLhRbYFmcUWz0+QEnyL/K4eAfpAqkktBaZrYnbhODd2y+tPkhVTKqvVTmGk04Mia HXaIJC64/CNAVD7iDGtAL4piOkZnin8RuLjbT455hK28mu/tSFFZrfQlkFzqCCmwF48b PdNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=mLwLsWkgiMvkTOH2okOHyFXrrtzhJG33CfPLu4dBvc0=; b=rqrEGJxjzc7MeUs6x3g0DpegKY81kcL8Dtx1st2tIF/k6JBe10BrCQRF1LBY8StsaC 3NCqVJr4EScKT7CAT33ESGUVfltJ5CTjwe4r1Nm6CEIh3BNYLBm16kLgNPSHuKDkLoo1 PPoPoFo81Afd736w6edAiGgK/6EzM+9GC886XRlqggJJ9rzVn548DAuKKQyJoJLEAdf2 5DN2WzJVnTD4YlobuwfBLRnwLFCHCMFUls4nXjE7JTeu88E9SJr6GwcSMWKOhPFXdg5u zyIFzdDvYBEds468DIQUNSChzETzvMaq/62tyZY3e/ntBIolO37wrMOTUQFQfb6THlX9 xshw== X-Gm-Message-State: AOAM532lEb2xcA2uqzjtHAU2xouE93a/+vcgWVe1WiSQOYo0dx6uk39+ m/+86DMTk8jExZkyyB7ffeWML3SBgX4UnWpz X-Google-Smtp-Source: ABdhPJxYCcdaMxCpmrjVAmXcEI4Vk5X+v0jR4Zbsh3I66pdQCjiZoMgpSIqhb+FpgiokqL9QTI682g== X-Received: by 2002:ac8:590f:: with SMTP id 15mr6691957qty.249.1607571540551; Wed, 09 Dec 2020 19:39:00 -0800 (PST) Received: from [192.168.1.12] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id o9sm2526780qte.35.2020.12.09.19.38.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 19:38:59 -0800 (PST) To: tcpm IETF list From: Wesley Eddy Message-ID: <44bb0cb6-ca70-ed7f-6c88-233afcc09500@mti-systems.com> Date: Wed, 9 Dec 2020 22:38:49 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------2CCB611CEF4F4BEA653C4961" Content-Language: en-US Archived-At: Subject: [tcpm] 793bis: default R2 value for SYNs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 03:39:03 -0000 This is a multi-part message in MIME format. --------------2CCB611CEF4F4BEA653C4961 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In review comments, it's been suggested that the requirement is too high, saying the number of retries on SYNs needs to allow retransmissions for at least 3 minutes. For reference, the text in question is: However, the values of R1 and R2 may be different for SYN and data segments. In particular, R2 for a SYN segment MUST be set large enough to provide retransmission of the segment for at least 3 minutes (MUST-23). The application can close the connection (i.e., give up on the open attempt) sooner, of course. I would prefer not to change this in 793bis, but to leave it as a topic for the WG to look at separately, since I imagine it could be something that takes more discussion, leverages measurements, application surveys, etc. So, my plan is to leave this alone unless there's a strong feeling that this should be changed now, and that the WG agrees on how to change it / what it should be changed to. Any thoughts on this are welcome. --------------2CCB611CEF4F4BEA653C4961 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

In review comments, it's been suggested that the requirement is too high, saying the number of retries on SYNs needs to allow retransmissions for at least 3 minutes.

For reference, the text in question is:

   However, the values of R1 and R2 may be different for SYN and data
   segments.  In particular, R2 for a SYN segment MUST be set large
   enough to provide retransmission of the segment for at least 3
   minutes (MUST-23).  The application can close the connection (i.e.,
   give up on the open attempt) sooner, of course.

I would prefer not to change this in 793bis, but to leave it as a topic for the WG to look at separately, since I imagine it could be something that takes more discussion, leverages measurements, application surveys, etc.

So, my plan is to leave this alone unless there's a strong feeling that this should be changed now, and that the WG agrees on how to change it / what it should be changed to.

Any thoughts on this are welcome.


--------------2CCB611CEF4F4BEA653C4961-- From nobody Wed Dec 9 19:44:54 2020 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 D89793A0982 for ; Wed, 9 Dec 2020 19:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 r040vfS9tncv for ; Wed, 9 Dec 2020 19:44:51 -0800 (PST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 35B6C3A095F for ; Wed, 9 Dec 2020 19:44:51 -0800 (PST) Received: by mail-qv1-xf29.google.com with SMTP id l7so1794682qvt.4 for ; Wed, 09 Dec 2020 19:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=rRav29q/SR9caDLCegbKL7ABeCd4qcKRd8OVAtvaf+o=; b=DWmEdnlXdH3+UZzk6BeWjr7+AACMD4mNm6oBellM4BV0GS6UtTIzH7xwuMzJWiaK07 N5DglnAANBLFXJid7oLIthfJSIwUWCVBueVQlWZxalsjZ6sfw6Tz26cHCtZr3TRuP4mX cgenCoKtgRetp3tN6eLyxy6N2vhOOenLhAd2nkIzGeN0tiOcDT+qBKUhQGP7Cq4wsJpW wxPhbgh8o8iaE224m/QG5j4HY+V58IzXGvOfwZsVwhSHY5kKgMhfq03Omv7OH+Tfm5nQ gKuq/vuXHhnyqSAHv2sO1flG/RT1RGLPoX8PU7GqyKU7KrNMHVWciQLqxmCvLgNs9wE0 UMzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=rRav29q/SR9caDLCegbKL7ABeCd4qcKRd8OVAtvaf+o=; b=gbBnZAK7QbYBvQb9LvRk5PnESKGMqUeGcZAVrO1jp3ECO1TS+/iTcrUXJsaAloGA8k QkfIYEItJ4iEByXYNJTnCJ3cRyf9aZ6juCZ2N8buN3Q2QvGOYvwXVCN9+kSV2XxUiRc+ O0GEMvt2/Hn0ugfqdLsCA5M350wMp6BbAwNPODiN568adXKWj4yaHzhHUSOZlcQ5VrZk A93qgC4aplkLhbdph/P5NemXc0NMpZT3IJW7RXyNTz5iH5TCKZDFFnhWFuX/5v2jxQyv EhIR7zro6BT5So8KNTwVwvWw6ka6KM5SjKQ+AIcu4Fmm1Cjta97EjFlKfhVozR4zBOCq GJvA== X-Gm-Message-State: AOAM531PLMmksIA4Lqo3YB72CTAznLay9xfoBzLPMcYnqOF5IFhPgjAN aotrwP2qPWhZyo5DZQTzOtsM/t/M/FbB3yM6 X-Google-Smtp-Source: ABdhPJx3Oo8LAVOXDJCv1/gLgZdQFa0D9ZT3uiAkAIQoLfbYJKuSD3tfqVFJ5s4kyjcCdFKvaNt3HA== X-Received: by 2002:a0c:ab08:: with SMTP id h8mr6798837qvb.38.1607571889744; Wed, 09 Dec 2020 19:44:49 -0800 (PST) Received: from [192.168.1.12] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id z8sm2628874qti.22.2020.12.09.19.44.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 19:44:48 -0800 (PST) To: tcpm IETF list From: Wesley Eddy Message-ID: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> Date: Wed, 9 Dec 2020 22:44:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EE1D58D2009382348CF9257F" Content-Language: en-US Archived-At: Subject: [tcpm] 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 03:44:53 -0000 This is a multi-part message in MIME format. --------------EE1D58D2009382348CF9257F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit There's been a suggestion that we make a stronger statement on support for the common (but not required) options like SACK, Timestamp, and Window Scaling. Current text just indicates that these are recommended: Other Common Options Additional RFCs define some other commonly used options that are recommended to implement. These are the TCP Selective Acknowledgement (SACK) option [18 ][21], TCP Timestamp (TS) option [43 ], and TCP Window Scaling (WS) option [43 ]. I don't have any issues with appending a stronger statement something like: TCP implementations SHOULD support these options. Would that suffice?  Are there objections or other suggestions on what exactly to say? --------------EE1D58D2009382348CF9257F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

There's been a suggestion that we make a stronger statement on support for the common (but not required) options like SACK, Timestamp, and Window Scaling.

Current text just indicates that these are recommended:

        Other Common Options

        Additional RFCs define some other commonly used options that are
        recommended to implement.  These are the TCP Selective
        Acknowledgement (SACK) option [18][21], TCP Timestamp (TS)
        option [43], and TCP Window Scaling (WS) option [43].

I don't have any issues with appending a stronger statement something like:

TCP implementations SHOULD support these options.

Would that suffice?  Are there objections or other suggestions on what exactly to say?


--------------EE1D58D2009382348CF9257F-- From nobody Wed Dec 9 20:12:34 2020 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 A65ED3A09E0 for ; Wed, 9 Dec 2020 20:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 Eh1q4yTCtY6l for ; Wed, 9 Dec 2020 20:12:31 -0800 (PST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 2FF103A09A5 for ; Wed, 9 Dec 2020 20:12:31 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id u67so910317vkb.5 for ; Wed, 09 Dec 2020 20:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W3bJ9NH06/LcwZzO/cLwYmGaB3DtWf24PFlj01sML2Y=; b=UoE0T+T1sAe1wGuS25C7cEBmlp7pr2vNH+Wst1KwXkdy5qDrmi71RpPAGj2fD10RZX zrQkBefKkqpotVRelBRverz30iOpqMQxxUf821P5BTE6ORpMgh7igWoKgKFCB+PEQK52 SSTyZkzN3yJNBssh65M1MWc2+Z8EPp1AToa2NguS8HvIMbNw7E6fuAohkGR0J6vMi1G5 p3LA9t3q0NZTwTC7BJtt97HPqXQO2bB7Ajo3qBcX48V005/YTI7O8zY0PieLAM9yNbGM 8T+/hxY4zBhUV4QfPLl0/DpRDUIPSJnabiAxWzFlBS5Dj1dWd/l8fv2WQJ3yDhAtB232 ae3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W3bJ9NH06/LcwZzO/cLwYmGaB3DtWf24PFlj01sML2Y=; b=YAmLVvxiDAyJCgwJJ/RnLQv+bJ7Qaq9+MKq084umX8ZQ08JiNH6YWifJMnmYE4AG1C U28tnyQO0hwDXBga6IeQJ4sNnh/N0EglMLMyOkDc5lPLmhzS07HVQI+Rvfm5RvAJ2gph BYKAW8HZElNEQ8T6947Zd1x6V1n6+1pcu0tjO0oaMQJpALjFmPgTv9jaZbE+7J+t70nw vitj1GEbQKVPlLrdt+Y1qdYZeiP6vgydUqDcgSDif3sS7YWpojs6zSI5+gq/MYTmfM1J pwnas55+ZZvYZWT06lI8f16cgl1OGvDbiW4Kg/UFuwTRrfBC5VGFCf+Dv6D406icWQtm mdgA== X-Gm-Message-State: AOAM531qS7neOrqJFGnRKRkgO1abchBmtU4ih/87qiEpIhTit4Yr2GBX Tt+UIpxHo8q69g+roa7HCCjHVwI0jiPqETXJpGGFQo5EBKz7lVyF X-Google-Smtp-Source: ABdhPJx7Ol2OjjU86fWd5FTWEMgCZTjjAyzLs/WpvQXRp+BPXCOcdg3FkoxEuha5Q+3nAPKb50vPYp8xcgDtKm3wZgg= X-Received: by 2002:a1f:8d92:: with SMTP id p140mr6368054vkd.19.1607573549790; Wed, 09 Dec 2020 20:12:29 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> In-Reply-To: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> From: Neal Cardwell Date: Wed, 9 Dec 2020 23:12:12 -0500 Message-ID: To: Wesley Eddy Cc: tcpm IETF list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 04:12:33 -0000 On Wed, Dec 9, 2020 at 10:45 PM Wesley Eddy wrote: > > There's been a suggestion that we make a stronger statement on support for the common (but not required) options like SACK, Timestamp, and Window Scaling. > > Current text just indicates that these are recommended: > > Other Common Options > > Additional RFCs define some other commonly used options that are > recommended to implement. These are the TCP Selective > Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) > option [43], and TCP Window Scaling (WS) option [43]. > > I don't have any issues with appending a stronger statement something like: > > TCP implementations SHOULD support these options. > > Would that suffice? Are there objections or other suggestions on what exactly to say? All of those options are hugely valuable, so I would strongly support listing these options with a "SHOULD" or "RECOMMENDED". My reading of https://tools.ietf.org/html/rfc2119 is that "SHOULD" and "RECOMMENDED" are synonyms, in which case the "recommended" in that paragraph could perhaps just be changed to be an all-caps "RECOMMENDED". best, neal From nobody Wed Dec 9 23:23:27 2020 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 B35C93A08D4 for ; Wed, 9 Dec 2020 23:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org 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 1hBWBcaXqaWz for ; Wed, 9 Dec 2020 23:23:24 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 6259B3A0644 for ; Wed, 9 Dec 2020 23:23:19 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:50e0:58f4:5cc8:3f33] (unknown [IPv6:2a00:ac00:4000:400:50e0:58f4:5cc8:3f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id EC5B96103F6; Thu, 10 Dec 2020 09:23:11 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1607584992; bh=mmZYoFD2VtGsPCEStsD4LolqTG3CHQQBHHHfV2C5Lm0=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QjL8X5UhcjitXznW6AOKFLEDdz6x5IENIvEgtDyjbQ61+ZWVD0drlW9v61EBs4qeo JIAnfLnUyJpAYZXWVS7U/B1QuVIJ/8VBCjiSEaHX9MASscv2zLeQYwuLTUwQIQ2hkF Ssb8cccmwfDw2FpngAG3AiJqmplNScUTwdET8Uew= From: Lars Eggert Message-Id: <3BC7018B-601A-4C3F-98E2-90C51D4D104F@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_E50F5A24-B7F0-4FAD-A3A6-4294C5C5E266"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 10 Dec 2020 09:23:08 +0200 In-Reply-To: Cc: "wes@mti-systems.com" , "tcpm@ietf.org" To: Praveen Balasubramanian References: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> X-MailScanner-ID: EC5B96103F6.A3EBC X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 07:23:26 -0000 --Apple-Mail=_E50F5A24-B7F0-4FAD-A3A6-4294C5C5E266 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2020-12-10, at 0:44, Praveen Balasubramanian = wrote: > This looks good to me except that the references to CUBIC and BBR can = become dated over time and might also get standardized. So I=E2=80=99d = omit this sentence =E2=80=9CCUBIC [RFC8312] and BBR are prominent = examples that have been discussed at length in the IETF but not yet = standardized.=E2=80=9D also, we're about to ask for adoption of 8312bis on the Standards Track = (https://github.com/NTAP/rfc8312bis) as soon as we have the individual = -01 ready, so the text would be incorrect at least for CUBIC. Lars --Apple-Mail=_E50F5A24-B7F0-4FAD-A3A6-4294C5C5E266 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl/RzNwACgkQVLXDCb9w wVdo1g//bG6PKVoe5QCZ9WXk6rqxAT4qMoqaJvHWLdA+UPwLRoiaxs73Z4M7/Gpt GvKS9txaHGBuPXZYyUdXPTbw7PqUg7o7QxbuiEoK78pr2iw+Ao//G7OruPFJfksV nF/YT3ozIeRqJPCMCQ2y90p557sQxs9pjRLuSbsbT4fZmk19UJ2BQndaT2uR6p+u 7PVaq8rX/T1s1zYQulgWtjqbkLPN9lOAEakG8lWRY+QUXfnWcd7OOCy+qBN+B/f4 bTLi8KS/9/VyJZhujdlCTukXHv+GBpW1mSCqWDRrrZhfZGkp9nmcu3Szg3RIYgMu oUqs22nYAmgTZdP4YvI5eNg5Ol/O+f3+Zp1XSwb/DWBlMxc/R8ZVLezR83lSF5OU QvtxkY/4jov4l8wKBU6KDnjWNfJiz8Z2GwPykoLNe1HKnALO6o4RLZXGHr7PA+Sk MjeDg8hEtG2uN2rL9NYR9oqTrPX8d7oc5uqOS7HGxh7sJhG3XmKla1Eftrg8j1UA ka4xqAyFpN5alaT2K9mv32vDwwGwBmibx8sKThnXhtOuVuN/BZz8qC6MvPdCQ7kc 8DAaeelpOKRCd3xH/NnvxXdg2pZpFRqrMcif8YLyk+X0FIsthc6iD+iMQd4CIiFD AZCc99R0ozY9s5pnWnBsBHQA2p3NVN3M1A/a9CjMEwAiBPmrRKA= =+L+w -----END PGP SIGNATURE----- --Apple-Mail=_E50F5A24-B7F0-4FAD-A3A6-4294C5C5E266-- From nobody Wed Dec 9 23:34:01 2020 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 DE60E3A046D for ; Wed, 9 Dec 2020 23:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 r4q1i-R5VAJp for ; Wed, 9 Dec 2020 23:33:58 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 341193A0475 for ; Wed, 9 Dec 2020 23:33:58 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0BA7SKfZ037105; Wed, 9 Dec 2020 23:33:51 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=meHXfl/1ZZGYZ/lz57NkGjKJiYtWONZD7lG/vT+QDa8=; b=qmnntT15daSZjikFDEuUv1Gi2y8/4MVpRbZNm2HxkFDPmihx56yhTK5BTp2gAJmnP15k 1/iJNFQ6cRReS/C1/m/af8DTNumOJ4QaiktT8qnGE+zFAyKhj1OwDklkkaBJzKAmTOUG yf3LND9eSlG3BMqD/oNn9DTiwjdtzrZMoOS/b5D6q0qAPE5a/qgI/j9X9XfYS3EacONv Xc1sPxHlkl9Hpe04SIxCBf39K9YLj2I3+ZQ6Omtm9kUiiQkSQN1ZGJTrDmdOySkUYkkm arODfAaajMsgQOCcRDKS4Y2uuyDW3Fyg82x01xLqGCattkxXGjbt8ZoqD3BSLYtYCTLv /g== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3589r87kc3-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Dec 2020 23:33:50 -0800 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QL400JYE50A5130@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 09 Dec 2020 23:33:46 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QL4004004XXEM00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 09 Dec 2020 23:33:46 -0800 (PST) X-Va-A: X-Va-T-CD: e52bc99798a6b8983ba7b5634300aea3 X-Va-E-CD: 714e1c29d1198f70e9ca4b37a7356574 X-Va-R-CD: c818a24409186dceec2cd95ba3e28721 X-Va-CD: 0 X-Va-ID: f21ca144-b06d-45a2-8b60-c10badb7a452 X-V-A: X-V-T-CD: e52bc99798a6b8983ba7b5634300aea3 X-V-E-CD: 714e1c29d1198f70e9ca4b37a7356574 X-V-R-CD: c818a24409186dceec2cd95ba3e28721 X-V-CD: 0 X-V-ID: e361431e-208a-41e4-88c2-957fb39215a2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-10_01:2020-12-09, 2020-12-10 signatures=0 Received: from [17.232.216.106] (unknown [17.232.216.106]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QL400Z6A509U700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 09 Dec 2020 23:33:46 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Vidhi Goel In-reply-to: <3BC7018B-601A-4C3F-98E2-90C51D4D104F@eggert.org> Date: Wed, 09 Dec 2020 23:33:45 -0800 Cc: Praveen Balasubramanian , "tcpm@ietf.org" Content-transfer-encoding: quoted-printable Message-id: References: <0cd5b58f-37f3-51a4-7e5c-99644f0c77d6@mti-systems.com> <3BC7018B-601A-4C3F-98E2-90C51D4D104F@eggert.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-10_01:2020-12-09, 2020-12-10 signatures=0 Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 07:34:00 -0000 +1 to removing CUBIC or BBR as references. > On Dec 9, 2020, at 11:23 PM, Lars Eggert wrote: >=20 > Hi, >=20 > On 2020-12-10, at 0:44, Praveen Balasubramanian = wrote: >> This looks good to me except that the references to CUBIC and BBR can = become dated over time and might also get standardized. So I=E2=80=99d = omit this sentence =E2=80=9CCUBIC [RFC8312] and BBR are prominent = examples that have been discussed at length in the IETF but not yet = standardized.=E2=80=9D >=20 > also, we're about to ask for adoption of 8312bis on the Standards = Track (https://github.com/NTAP/rfc8312bis) as soon as we have the = individual -01 ready, so the text would be incorrect at least for CUBIC. >=20 > Lars >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 04:50:05 2020 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 7ED2B3A0DCB for ; Thu, 10 Dec 2020 04:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 fblwyiiwLY7i for ; Thu, 10 Dec 2020 04:49:59 -0800 (PST) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (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 624693A0DC4 for ; Thu, 10 Dec 2020 04:49:59 -0800 (PST) Received: by mail-yb1-xb31.google.com with SMTP id u203so4609870ybb.2 for ; Thu, 10 Dec 2020 04:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+MpT67fNmdezvIJ7LuqglKcRR/LQIRgtcQasjHMwln0=; b=PYj4FUbInEDfAXGfjzbPsiG+OILV4Gi9rojLC76ZA085AnwSnwpE55Zb3GxvZXN79P 2mqciHDDmHt401vpuI/vkFX6fOqr8CzA/2nHluelSiwZA7fcH3YQH6OPAtyh3bw4Zyhr y8sG6b0m0+kT0358y7KXimWYsEtWJGeztCW3v8gojOpWjioyyrotQE8xLBtryrlxcRFZ 01Dsy5mLUsJl/+O9G5qu52vuyjwF/xmppBLgiW8vEmu7/DiDkKIsYiF/WHXRnnToUbFq bZzuqHpEy+BsVLDq3JdwkA3uC4sqwzcY4U8DGYLKJ6R+XK1IpJTzmL+ZDbrMv5YJ549U uK/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+MpT67fNmdezvIJ7LuqglKcRR/LQIRgtcQasjHMwln0=; b=PaphvMLjK5f6oRWbHVk9TH6P24aASS4RvZ9v2RQusD0RsJsD3dCcVUpK9lWVUVrqL9 21b0FQMxV4y1D46vMyyVffAhqJ+tiKRi9cqUTJGEPH/FTJmER+45yft2y8cLLls5zFeO 7Ph84ygT0xWY/NHPn/oOWqub0KQN8+t0mpML/xgPPhZ/sTtHluRxO5t22xHf27YqVssU T7Yn6aLNYC2y9J2P6uXp7R7HUCKvMXC4F9BM3vgYwVluoBhSEcJiYg+pSx/pCGw2JTs4 pBZLAAnbn25TCzf7Aaa8JlkEcVV7BOEKmDQOuiGgEBiev7ctb6i3xGHxrI4FF1QTZcA2 BKnw== X-Gm-Message-State: AOAM5329EQVyYMTEATGhx9gsy7zGnAQdfkLoPnVlsMVDzPtsMt6O/s1u EU4e6y9spsw8j1CWHerSTQ3ZINxDMgilnWKr65gW7Q== X-Google-Smtp-Source: ABdhPJyLicVWwuz9fVlTHb0ON8bUjjxiJMAAD0H8r6MtXBmsIJVWIvdYWdfalxm2LAFuVYenNN2oWqPPC31gwpTnFLQ= X-Received: by 2002:a25:aac7:: with SMTP id t65mr10227091ybi.278.1607604598074; Thu, 10 Dec 2020 04:49:58 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> In-Reply-To: From: Ian Swett Date: Thu, 10 Dec 2020 07:49:46 -0500 Message-ID: To: Neal Cardwell Cc: Wesley Eddy , tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000031d1c05b61b9daa" Archived-At: Subject: Re: [tcpm] 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 12:50:04 -0000 --000000000000031d1c05b61b9daa Content-Type: text/plain; charset="UTF-8" I agree with Neal that these should be RECOMMENDED. On Wed, Dec 9, 2020 at 11:12 PM Neal Cardwell wrote: > On Wed, Dec 9, 2020 at 10:45 PM Wesley Eddy wrote: > > > > There's been a suggestion that we make a stronger statement on support > for the common (but not required) options like SACK, Timestamp, and Window > Scaling. > > > > Current text just indicates that these are recommended: > > > > Other Common Options > > > > Additional RFCs define some other commonly used options that are > > recommended to implement. These are the TCP Selective > > Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) > > option [43], and TCP Window Scaling (WS) option [43]. > > > > I don't have any issues with appending a stronger statement something > like: > > > > TCP implementations SHOULD support these options. > > > > Would that suffice? Are there objections or other suggestions on what > exactly to say? > > All of those options are hugely valuable, so I would strongly support > listing these options with a "SHOULD" or "RECOMMENDED". My reading of > https://tools.ietf.org/html/rfc2119 is that "SHOULD" and > "RECOMMENDED" are synonyms, in which case the "recommended" in that > paragraph could perhaps just be changed to be an all-caps > "RECOMMENDED". > > best, > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000031d1c05b61b9daa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Neal that these should be RECOMMENDED.
<= br>
On Wed,= Dec 9, 2020 at 11:12 PM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
On Wed, Dec 9, 2020 a= t 10:45 PM Wesley Eddy <wes@mti-systems.com> wrote:
>
> There's been a suggestion that we make a stronger statement on sup= port for the common (but not required) options like SACK, Timestamp, and Wi= ndow Scaling.
>
> Current text just indicates that these are recommended:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Other Common Options
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Additional RFCs define some other com= monly used options that are
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recommended to implement.=C2=A0 These= are the TCP Selective
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Acknowledgement (SACK) option [18][21= ], TCP Timestamp (TS)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option [43], and TCP Window Scaling (= WS) option [43].
>
> I don't have any issues with appending a stronger statement someth= ing like:
>
> TCP implementations SHOULD support these options.
>
> Would that suffice?=C2=A0 Are there objections or other suggestions on= what exactly to say?

All of those options are hugely valuable, so I would strongly support
listing these options with a "SHOULD" or "RECOMMENDED".= My reading of
https://tools.ietf.org/html/rfc2119=C2=A0 is that "SHO= ULD" and
"RECOMMENDED" are synonyms, in which case the "recommended&q= uot; in that
paragraph could perhaps just be changed to be an all-caps
"RECOMMENDED".

best,
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000031d1c05b61b9daa-- From nobody Thu Dec 10 05:52:58 2020 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 84F543A0E26; Thu, 10 Dec 2020 05:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Cz0-d_MiOQ3C; Thu, 10 Dec 2020 05:52:54 -0800 (PST) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F393A0E2C; Thu, 10 Dec 2020 05:52:41 -0800 (PST) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 0BADqceL092446; Thu, 10 Dec 2020 05:52:39 -0800 (PST) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 0BADqcwv092445; Thu, 10 Dec 2020 05:52:38 -0800 (PST) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> In-Reply-To: To: Yuchung Cheng Date: Thu, 10 Dec 2020 05:52:38 -0800 (PST) CC: Praveen Balasubramanian , "tcpm@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 13:52:57 -0000 > +1 to proposed change. > > It might be odd to say this as a co-author of BBR. I think mentioning > BBR or Cubic as prominent examples may be a bit biased. There are many > prominent great congestion control (for different scope/area/type of > networks) that are not possible to list them all. I would not mind if > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have > been discussed at length in the IETF but not yet standardized. ' Yes please., or perhaps only reference what IS in an RFC, CUBIC. > > On Wed, Dec 9, 2020 at 2:45 PM Praveen Balasubramanian > wrote: > > > > This looks good to me except that the references to CUBIC and BBR can become dated over time and might also get standardized. So I?d omit this sentence ?CUBIC [RFC8312] and BBR are prominent examples that have been discussed at length in the IETF but not yet standardized.? > > > > > > > > From: tcpm On Behalf Of Wesley Eddy > > Sent: Wednesday, December 9, 2020 2:09 PM > > To: tcpm IETF list > > Subject: [EXTERNAL] [tcpm] 793bis wording on congestion control > > > > > > > > During the IETF 109 meeting, we discussed what the 793bis document should say regarding the congestion control algorithm support expected for TCP implementations. > > > > For reference, the current draft says: > > > > 3.7.2. TCP Congestion Control > > > > RFC 1122 required implementation of Van Jacobson's congestion control > > algorithm combining slow start with congestion avoidance. RFC 2581 > > provided IETF Standards Track description of this, along with fast > > retransmit and fast recovery. RFC 5681 is the current description of > > these algorithms and is the current standard for TCP congestion > > control. > > > > A TCP endpoint MUST implement RFC 5681 (MUST-19). > > > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > > an IETF Standards Track enhancement that has many benefits [47]. > > > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > > 8). > > > > I think the sense of what people might agree that it should say is something like this (with changes marked in red): > > > > 3.7.2. TCP Congestion Control > > > > RFC 2914 explains the importance of congestion control for the Internet. > > > > RFC 1122 required implementation of Van Jacobson's congestion control > > algorithm combining slow start with congestion avoidance. RFC 2581 > > provided IETF Standards Track description of this, along with fast > > retransmit and fast recovery. RFC 5681 is the current description of > > these algorithms and is the current standard for TCP congestion > > control. > > > > A TCP endpoint MUST implement at least some basic congestion control algorithm suitable to avoid creating congestion collapse conditions (MUST-19). RFC 5681 is an exemplary algorithm on the IETF Standards Track that is broadly applicable. Multiple other suitable algorithms exist and have been widely used. CUBIC [RFC8312] and BBR are prominent examples that have been discussed at length in the IETF but not yet standardized. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. > > > > Explicit Congestion Notification (ECN) was defined in RFC 3168 and is > > an IETF Standards Track enhancement that has many benefits [47]. > > > > A TCP endpoint SHOULD implement ECN as described in RFC 3168 (SHLD- > > 8). > > > > This is an attempt at synthesizing from comments during the meeting (both audio and jabber chat) from Jana Iyengar, Jonathan Morton, Martin Duke, Praveen Balasubramanian, Gorry Fairhurst, Bob Briscoe, Matt Mathis, and Michael Scharf. I think there is broad agreement that we wanted to move away from requiring 5681, but did want to cite it as a perfectly fine example or default, but also wanted to explicitly permit other reasonable choices at an implementer's discretion. > > > > Please discuss, especially if you disagree or have better ways to phrase this. > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > -- Rod Grimes rgrimes@freebsd.org From nobody Thu Dec 10 06:09:55 2020 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 D47CA3A0E67 for ; Thu, 10 Dec 2020 06:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zY_Khjli5W_q for ; Thu, 10 Dec 2020 06:09:52 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 0F5E23A0E66 for ; Thu, 10 Dec 2020 06:09:52 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id f16so1719988uav.12 for ; Thu, 10 Dec 2020 06:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FGgKVIOodQpxIjkPQe/JXMbCbDBFhHVvfakqJs09Zms=; b=Bl3318zxT4p/o3dpKwWcNo9uPHb/jEEqndeKLvJUDn/5PqspUz4ltyO6swMqilOQrE Md34IX6XNZ4IJpqZuKPJ8RMmKkZufiZp4iVeBsI89U4P1sU+9XxzOqv4SMHcqyr/Ll5G RnhDP0KKc3HTgnUhLGjObEeHfI//Q0wJziOkbsqWMelNdoQ25nPlJtJ4yY4KxSEbjVxw kN58Ya9eEA5l2Af2bmRDYD4/z4IbHIS/zTrkavLMNxpFwebCNEpsCNaiMySuDWZEkE0y s4r02EyrLVuuU6dm33IowBCTafdHxwdj6Jb/flS3jijRgh/VgVS8PksLF5vCbpJvkn0t kXxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FGgKVIOodQpxIjkPQe/JXMbCbDBFhHVvfakqJs09Zms=; b=acCUO+0xoFR+3BfCchTt2f9iDYIQffcTCFpP9GEv+odvbZbCc2xGIer2lptXzXP9P5 PJyo/t+/GO1c59//l/0giWU1Ma0PPHbl1VQiSonxSTOMrAgr90/tmMzA1a5Y0k6BsVcv nVn/z8+hz0mXZrFnPj1G3R3eyzgiuA3ptgqP286+0DuSAECbiw0ozxkSztw9KxEcJEnz VD9+iw1mQpaUiHsw64HrnM9hHrX2REAPrevLoN7cDFNKvzRU0o0FYIcUs+TlP9va/dXP L8nAJGKrd3OrwLI9IHDEtLVyjaOtmINDTbQZTSQmPQxSb8xa7gKL8nuj4Xq6b6DloW1P G0iw== X-Gm-Message-State: AOAM530LVHr9j+WKWBjO2sE5HJ7kOIJ/0QQbV4Hif5Bsa7Ar7unohf/s CCCOKY/M/AZAf6xxAMHVM7kNvJxdkqWKd2A3dWjrEA== X-Google-Smtp-Source: ABdhPJyKMht5TBJ5TdpuDQUnIfY5fU7sDw6KRUQwAad4FxNM6msC9XKxbLGl98UZRXOh/hjdM7eVnZadBcItzq0jkSo= X-Received: by 2002:ab0:558a:: with SMTP id v10mr8436040uaa.63.1607609390828; Thu, 10 Dec 2020 06:09:50 -0800 (PST) MIME-Version: 1.0 References: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> In-Reply-To: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> From: Neal Cardwell Date: Thu, 10 Dec 2020 09:09:32 -0500 Message-ID: To: "Rodney W. Grimes" Cc: Yuchung Cheng , Praveen Balasubramanian , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ae1d5405b61cbaf4" Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 14:09:54 -0000 --000000000000ae1d5405b61cbaf4 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes wrote: > > +1 to proposed change. > > > > It might be odd to say this as a co-author of BBR. I think mentioning > > BBR or Cubic as prominent examples may be a bit biased. There are many > > prominent great congestion control (for different scope/area/type of > > networks) that are not possible to list them all. I would not mind if > > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have > > been discussed at length in the IETF but not yet standardized. ' > +1 to removing CUBIC or BBR as references. I would suggest instead a recommendation that emphasizes a general phrase that is less susceptible to bit rot over the next 10-20 years, like a "congestion control algorithm from the IETF Standards Track". Perhaps something like: A TCP endpoint MUST implement at least some basic congestion control algorithm suitable for avoiding congestion collapse conditions (MUST-19). Multiple suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. It is RECOMMENDED that a TCP implementation include at least one congestion control algorithm from the IETF Standards Track. neal --000000000000ae1d5405b61cbaf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 10, 2020 at 8:53 AM Rodney W.= Grimes <ietf@gndrsh.dnsmgr.ne= t> wrote:
> +1 to proposed change.
>
> It might be odd to say this as a co-author of BBR. I think mentioning<= br> > BBR or Cubic as prominent examples may be a bit biased. There are many=
> prominent great congestion control (for different scope/area/type of > networks) that are not possible to list them all. I would not mind if<= br> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that hav= e
> been discussed at length in the IETF but not yet standardized.=C2=A0 &= #39;

+1 to removing CUBIC or BBR as referenc= es.

I = would suggest instead a recommendation that emphasizes a general phrase tha= t is less susceptible to bit rot over the next 10-20 years, like a "co= ngestion control algorithm from the IETF Standards Track".

Perhaps something like:

A TCP endpoint MUST implement=C2=A0at= least some basic congestion control algorithm suitable for avoiding conges= tion collapse conditions (MUST-19). Multiple suitable algorithms exist and have bee= n widely used.=C2=A0Many TCP implementations support a set of alte= rnative algorithms that can be configured for use on the endpoint.=C2=A0It is REC= OMMENDED that a TCP implementation include at least one congestion control = algorithm from the IETF Standards Track.
neal

--000000000000ae1d5405b61cbaf4-- From nobody Thu Dec 10 08:00:09 2020 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 7FD8C3A1069 for ; Thu, 10 Dec 2020 08:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 zrArNGeTBqGA for ; Thu, 10 Dec 2020 08:00:06 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 CAA973A1068 for ; Thu, 10 Dec 2020 08:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VpqsBFrKAyVPNj4YHwXxyHSIY7+OuQio21ADvH6Bx0c=; b=XzGAEKwa3vGe1wXmhd7lsIkDA jp3xLlIHCF80gEFU9xQ4KHSRDjHrOiJWa9VbyHuU22QbogSdW6gYx/NG7k+sHN9LwHgPOwxtnZEyc AkQLbcXnBgmLOT01cffIbNnVlTsss1I/gorHgXrA2DZj0IJi8uE1HSGHdkLUh3n8ELWemkrphYxL/ 6LpGb0TPiCX6uAgpljzE8cbZdvpeOZtVZP30h80JJAIWCRDvwd1h+GU42fCytxt30Wr3VLRu9aqpa UewNkz5jubCZBdtBZDah5rPrnocQ2DgHq/IbUIc5IbVFb1KKAoL2VFEpMFUJxcuDxqMXn0l6on4qw g1JlztrFQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60459 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knOML-001yAt-9h; Thu, 10 Dec 2020 11:00:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_823AA3C4-034C-4A0B-823D-17BCECE0A526" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> Date: Thu, 10 Dec 2020 08:00:00 -0800 Cc: tcpm IETF list Message-Id: References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> To: Wes Eddy X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 16:00:09 -0000 --Apple-Mail=_823AA3C4-034C-4A0B-823D-17BCECE0A526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s = see how we can change TCP today=E2=80=9D. That wasn=E2=80=99t the point of this update. Second, the doc (and all docs) should scrub all uses of SHOULD to ensure = that conditions for exceptions are indicated. I.e., SHOULD except = where=E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs MAY or = MUST) in a way that becomes merely an opening for the loudest advocates, = which doesn=E2=80=99t help anyone. Finally, on this one in particular, NO. Again, we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2=80= =99s design. If the case hasn=E2=80=99t already been made in a draft in = detail, we should NOT be considering the change at this point. Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if = you don=E2=80=99t implement them, you basically only hurt your own = connections. So there=E2=80=99s already incentive for capable endpoints = to implement them. Nevermind the fact that this would severely impact IOT and other such = uses, which I am surprised has not been considered. Joe > On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: >=20 > There's been a suggestion that we make a stronger statement on support = for the common (but not required) options like SACK, Timestamp, and = Window Scaling. >=20 > Current text just indicates that these are recommended: >=20 > Other Common Options >=20 > Additional RFCs define some other commonly used options that = are > recommended to implement. These are the TCP Selective > Acknowledgement (SACK) option [18 = ][21], TCP Timestamp (TS) > option [43 = ], and TCP Window Scaling (WS) option [43 = ]. > I don't have any issues with appending a stronger statement something = like: >=20 > TCP implementations SHOULD support these options. >=20 > Would that suffice? Are there objections or other suggestions on what = exactly to say? >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_823AA3C4-034C-4A0B-823D-17BCECE0A526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 First, can we please NOT open the floodgates to =E2=80=9Clet=E2= =80=99s see how we can change TCP today=E2=80=9D.

That wasn=E2=80=99t the point of this = update.

Second, = the doc (and all docs) should scrub all uses of SHOULD to ensure that = conditions for exceptions are indicated. I.e., SHOULD except where=E2=80=A6= . Otherwise, we=E2=80=99re tilting the odds (vs MAY or MUST) in a way = that becomes merely an opening for the loudest advocates, which = doesn=E2=80=99t help anyone.

Finally, on this one in particular, = NO.

Again, = we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2=80=99s = design. If the case hasn=E2=80=99t already been made in a draft in = detail, we should NOT be considering the change at this = point.

Further, these only =E2=80=9Csh= oot you in the foot=E2=80=9D, i.e., if you don=E2=80=99t implement them, = you basically only hurt your own connections. So there=E2=80=99s already = incentive for capable endpoints to implement them.

Nevermind the fact that this would severely impact = IOT and other such uses, which I am surprised has not been = considered.

Joe

On Dec = 9, 2020, at 7:44 PM, Wesley Eddy <wes@mti-systems.com>= wrote:

=20 =20

There's been a suggestion that we make a = stronger statement on support for the common (but not required) options like SACK, Timestamp, and Window Scaling.

Current text just = indicates that these are recommended:

    =
    Other Common Options

        Additional RFCs define some other commonly used options that are
        recommended to implement.  These are the TCP Selective
        Acknowledgement (SACK) option [18][21], TCP Timestamp (TS)
        option [43], and TCP Window Scaling (WS) option [43].

I don't have any issues with = appending a stronger statement something like:

TCP implementations SHOULD = support these options.

Would that suffice?  Are there = objections or other suggestions on what exactly to say?


_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_823AA3C4-034C-4A0B-823D-17BCECE0A526-- From nobody Thu Dec 10 08:02:46 2020 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 72F083A1067 for ; Thu, 10 Dec 2020 08:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 VjZL7vzYmktG for ; Thu, 10 Dec 2020 08:02:41 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 AE02A3A1066 for ; Thu, 10 Dec 2020 08:02:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=m8CR0IZMHtimQyigC39NfBtBOOaHgnqOYV1mXg020Bs=; b=4jr9v2n7GdosfJ6df1R1qbsi+ l4wzTjMUVOBdzUCBorjh5WD/VHqlb1iNpG2K0isxkJdDroKfKg2y0LuNtCs/NHwbrvvrxxWJamZiO eBSL/yS8Ov+fEOGhvOr2aSS2RvLFVFYBVoXFlVsVQteV36y2ZpGwEFo5cxza9WWws2sHTs+nvry6C kTEis1Fyb2jMKWB2QUvWxL79+kPNNEgAeASb8VQ+0QG4LoPMiu9yj9X8BijpTdTnoc4qilBnUYUSK f+w3+/UUVdZfub5EackS8kkMIUy8B6bMMF4ptNjxm+r1y+2QMT8GlbW/YgzC+UBloaarIeKl/Ttjg O5cKcaBKg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60467 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knOOr-0020cb-06; Thu, 10 Dec 2020 11:02:41 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_5527BA96-7D24-4EA0-8415-41F637288D3D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <44bb0cb6-ca70-ed7f-6c88-233afcc09500@mti-systems.com> Date: Thu, 10 Dec 2020 08:02:36 -0800 Cc: tcpm IETF list Message-Id: <3F75D92C-E2D7-4A80-8F27-9B496A854864@strayalpha.com> References: <44bb0cb6-ca70-ed7f-6c88-233afcc09500@mti-systems.com> To: Wes Eddy X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] 793bis: default R2 value for SYNs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 16:02:44 -0000 --Apple-Mail=_5527BA96-7D24-4EA0-8415-41F637288D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No. Please see my other message about these sort of changes.=20 I like the idea of =E2=80=9Cif anyone thinks this needs to be changed, = we can have the WG look at it separately=E2=80=9D. But unless we=E2=80=99re holding up this update for that work to = *conclude*, this update isn=E2=80=99t a vehicle to open new change = topics. Joe > On Dec 9, 2020, at 7:38 PM, Wesley Eddy wrote: >=20 > In review comments, it's been suggested that the requirement is too = high, saying the number of retries on SYNs needs to allow = retransmissions for at least 3 minutes. >=20 > For reference, the text in question is: >=20 > However, the values of R1 and R2 may be different for SYN and data > segments. In particular, R2 for a SYN segment MUST be set large > enough to provide retransmission of the segment for at least 3 > minutes (MUST-23). The application can close the connection (i.e., > give up on the open attempt) sooner, of course. > I would prefer not to change this in 793bis, but to leave it as a = topic for the WG to look at separately, since I imagine it could be = something that takes more discussion, leverages measurements, = application surveys, etc. >=20 > So, my plan is to leave this alone unless there's a strong feeling = that this should be changed now, and that the WG agrees on how to change = it / what it should be changed to. >=20 > Any thoughts on this are welcome. >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_5527BA96-7D24-4EA0-8415-41F637288D3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No.

Please see my other message about these sort of = changes. 

I= like the idea of =E2=80=9Cif anyone thinks this needs to be changed, we = can have the WG look at it separately=E2=80=9D.

But unless we=E2=80=99re holding up = this update for that work to *conclude*, this update isn=E2=80=99t a = vehicle to open new change topics.

Joe

On Dec 9, 2020, at 7:38 PM, Wesley Eddy <wes@mti-systems.com>= wrote:

=20 =20

In review comments, it's been suggested = that the requirement is too high, saying the number of retries on SYNs needs to allow retransmissions for at least 3 minutes.

For = reference, the text in question is:

   =
However, the values of R1 and R2 may be different for SYN and data
   segments.  In particular, R2 for a SYN segment MUST be set large
   enough to provide retransmission of the segment for at least 3
   minutes (MUST-23).  The application can close the connection (i.e.,
   give up on the open attempt) sooner, of course.

I would prefer not to change this in 793bis, but to = leave it as a topic for the WG to look at separately, since I imagine it could be something that takes more discussion, leverages measurements, application surveys, etc.

So, my plan is to leave = this alone unless there's a strong feeling that this should be changed now, and that the WG agrees on how to change it / what it should be changed to.

Any thoughts on this are welcome.


_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_5527BA96-7D24-4EA0-8415-41F637288D3D-- From nobody Thu Dec 10 08:23:50 2020 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 64B393A10D8 for ; Thu, 10 Dec 2020 08:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 zeSvZaKVtZpS for ; Thu, 10 Dec 2020 08:23:43 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 528C23A10DA for ; Thu, 10 Dec 2020 08:23:43 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id y17so6066435wrr.10 for ; Thu, 10 Dec 2020 08:23:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RAdOA1G+y0voHN5DGrBXyShIZPMA9yILKiElJ9nWY5k=; b=c1ZRUVLz58BiIux9ZrbsHpOpQlUqWQU9Kys+FVxo5e+3pvb72BlqtCTx1sTezAhoV8 aW7cVU+euLyU+oWdi542OHdK0EdS2/e4AAeTBM0IuU2cSXGzvytj3KDP0CGSXh2SQx7x kF3o2gVWN5t9HfJfTFhXnNyx+b75ybYyiJJ/xHZJ7dsnaAAKPgZKTqYJss8n65aZmdjD S4XhPc47K3ziFnJkA++V0vJiWQSh6ytvtylrNmvkt/xCierC2Pgv+9whpE3AMd0qiW5Q 9UcXCPI8TdfMMMfN66atIFZMFIAISXJIujWhtvHsSzLm1fYM0OXd9rW20Z3QsmpYIabG DXVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RAdOA1G+y0voHN5DGrBXyShIZPMA9yILKiElJ9nWY5k=; b=mITBLsVFedhLDYp6UTH+ow/buJBmOWlmGzCP+YWYjIlLPNtXnzpXrNAd/FVG+n62qk 7P2JPVCFLvvNJh384G1f1/1rQxG4y5leZJtCYv6zRwRZ9LVLOVIqM93wgTaHOGA6RGE8 exKEimfgV27AD3yH0/e8RjFP7eUQ2MTJgkqUC5BFwsmWdq0tvGZHRtXU08wx510fPl6F yiiQzZpzkkCKYebZI1+Yla8ZinSE0daLtuysV6Ggjlmw+y3oXtPNDyFhYpAy2UL1oJju 3WzfeC5wTjTgWZZiuxiNuk7vZDE2PmQFGnVPaaVngCl860iwgrb+xxPk5a4uFecw5qvz WE6g== X-Gm-Message-State: AOAM532A2zP9ZMbpdSrLRDmes7HkSwn8+SFPo7f+6QihUNAuP/+JMsAS E9kPjrkBK34GrYqLo6eSWQPb/3VRiikQt+cEYdoeow== X-Google-Smtp-Source: ABdhPJwuL7+JSwgVpF+H/Z5li6s0uOCLYnAt+f45mmPUrIQFJHtSq9vNQIffN5PUUT8BwlsCXKL4yySNkq8w+7VFguA= X-Received: by 2002:adf:a3ca:: with SMTP id m10mr9186996wrb.228.1607617421498; Thu, 10 Dec 2020 08:23:41 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> In-Reply-To: From: Yuchung Cheng Date: Thu, 10 Dec 2020 08:23:04 -0800 Message-ID: To: Joseph Touch Cc: Wes Eddy , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 16:23:49 -0000 I agree with Neal and Ian that these features are highly useful for TCP (performance). But I also agree adding new SHOULD/MUST/MAY after the extensive WG reviews in the last minute is not a good idea. If this new RFC is about the minimal requirement to implement TCP correctly (but not necessarily performant in various networks), then my vote is to keep as-is. On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch wrote: > > First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s se= e how we can change TCP today=E2=80=9D. > > That wasn=E2=80=99t the point of this update. > > Second, the doc (and all docs) should scrub all uses of SHOULD to ensure = that conditions for exceptions are indicated. I.e., SHOULD except where=E2= =80=A6. Otherwise, we=E2=80=99re tilting the odds (vs MAY or MUST) in a way= that becomes merely an opening for the loudest advocates, which doesn=E2= =80=99t help anyone. > > Finally, on this one in particular, NO. > > Again, we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2= =80=99s design. If the case hasn=E2=80=99t already been made in a draft in = detail, we should NOT be considering the change at this point. > > Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if you= don=E2=80=99t implement them, you basically only hurt your own connections= . So there=E2=80=99s already incentive for capable endpoints to implement t= hem. > > Nevermind the fact that this would severely impact IOT and other such use= s, which I am surprised has not been considered. > > Joe > > On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: > > There's been a suggestion that we make a stronger statement on support fo= r the common (but not required) options like SACK, Timestamp, and Window Sc= aling. > > Current text just indicates that these are recommended: > > Other Common Options > > Additional RFCs define some other commonly used options that are > recommended to implement. These are the TCP Selective > Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) > option [43], and TCP Window Scaling (WS) option [43]. > > I don't have any issues with appending a stronger statement something lik= e: > > TCP implementations SHOULD support these options. > > Would that suffice? Are there objections or other suggestions on what ex= actly to say? > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 09:50:12 2020 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 C137A3A1149 for ; Thu, 10 Dec 2020 09:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MBDs9XcPkQ6U for ; Thu, 10 Dec 2020 09:50:07 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650113.outbound.protection.outlook.com [40.107.65.113]) (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 10ADB3A1147 for ; Thu, 10 Dec 2020 09:50:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BgUfB+lAJMiGtClxlPjnCa3kb/ex/mu2gAPwHQunpzDYgV0DwoXC3NtydUlyzT3pd1/Rg+a0+H75itA+kSlr9lLpuWiFyDObXxPz8s13P7RBVj+0iukcXtTRlH7AwRJoS8G5nzV/2zDxysPZnf82tciAYhB8MPwpJPQ6DTDIZ/oQKc8oukSF/+5Lly1K1WHo4u5H4mX+H8VEvUQ9A4u5l15EHhn+eGw8Dx0Xv5EO2ZDcb/GP4YDWFdF4lUHZmDDBImL756MHZLtlLKmaIdh7WoyGA6Ug/+UiNXXbwsFDXqGDgG5S6LlbDR9RiIehMIn9lV65yif55oLUGBkGy3it7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p2P1cgkH/Y1ZLk2lIacpW8Ms1x7/f7rlNeOJTqOEk+M=; b=KIkwpyecCO5fOI2oaNwMqbW0kKBSXaxm6MC7Ejoh2R97qndNXgcSL3c+NShWNpysi45rrEpvI5if6XD/NVYyRvYq3raDcZrmJi9fg0ULDOFyK/YShqE+Wd7lscRHIPdeNM/SBkEQ5CYqo4LNKqw6AKr+6+QpThx17TNiBp0BEoRm6cFUqPPRF0/kKnVtGkOI7pRCZk04D6etONEZxwJktdHK04DAr7fDnxUP13ZGUhDLE26JfkquGBD8ubI+AxbB5QlWy0wMA7tT09yfb5bQ1qcxxia8tedm+OvBLBi8Gc5pLLctSEW4r8e19cdkynft4POiVbv8dKOveL8d2PfBTw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=p2P1cgkH/Y1ZLk2lIacpW8Ms1x7/f7rlNeOJTqOEk+M=; b=coUp2AiBQVNLxaQmUew4c+snQj/9kmmHVFTojWS1DV//XPn4ZDsbsmuC0WKavxQR/dH7OHG3XrB2+NROM+b0awnizamrEZISxoQeeXNbqFsUkkdHmXy8gstalXgDQTrU/bF5n2iluXddHucYqGC7eLPH1ZO6MSM9WUJY2rFReHY= Received: from (2603:10b6:102:15::21) by CO2PR00MB0166.namprd00.prod.outlook.com (2603:10b6:102:15::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3693.0; Thu, 10 Dec 2020 17:50:01 +0000 Received: from CO2PR00MB0168.namprd00.prod.outlook.com ([fe80::a129:642e:2be2:f536]) by CO2PR00MB0168.namprd00.prod.outlook.com ([fe80::a129:642e:2be2:f536%12]) with mapi id 15.20.3701.000; Thu, 10 Dec 2020 17:50:01 +0000 From: Praveen Balasubramanian To: "ycheng=40google.com@dmarc.ietf.org" , "touch@strayalpha.com" CC: "tcpm@ietf.org" Thread-Topic: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common options Thread-Index: AQHWzw235Ahdg3GHWk61UjPnWu301qnwg10AgAAXYGA= Date: Thu, 10 Dec 2020 17:50:01 +0000 Message-ID: References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=ae6cc2d2-ed5d-492c-a7e7-3bcd27dd0347; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-10T17:46:43Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8:95d0:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6cf8daa7-7c8c-4100-9657-08d89d3404cc x-ms-traffictypediagnostic: CO2PR00MB0166: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PMYeIStEqW11FEj9N1b7IzDWjLkAQuj3YmHFFCpWxzJZ05aKkO81WVY77Wc0YwO989wiLLPkdAU79MjvqEgkEseSh550RULQ9afYjDJBoIJIVA5BaGVBZ7jkMeeFAj4/4FrHYc9yM7APe1x0RmQsmVALkdlqLhky1WKPnggMCvKFW7gpC+omlPElerHX3lrXC55PhCMwzKRfJ8LW7PkMRYDR9hkcUBSDTgTvklE+vc0HiqLXRa3BfJST9N65Jy7aQunpYnSllpnG8OiGCTDnZZVKDuyl8zFHP3Pmt3uUYi0Ew97cwM24lVxhz33UzZ5zGtVp5sDvLBuArAEvs/HBvBVnmPlUMQ4oxpUpiKsv1dukfH8aDBw40jkJcaFuTIRnTxYbcvWdFlga99+z4+fxn/F8eUuNpMJrmxhuaXkqh5dK7blNevCjUvUA7AlRr9aMfkKsL2a5FeRwMiXurTxpJw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO2PR00MB0168.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(376002)(83380400001)(7696005)(33656002)(82960400001)(53546011)(8676002)(86362001)(6506007)(82950400001)(55016002)(110136005)(10290500003)(8936002)(76116006)(66476007)(8990500004)(71200400001)(52536014)(64756008)(186003)(4326008)(9686003)(66446008)(508600001)(66946007)(966005)(66556008)(2906002)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?UVhrZ1RsalQ4WGRsZW9Ka20vQ3dlaFZPcjJaT1NvQkhnS3NPSVZ6cUlZc2ps?= =?utf-8?B?M2t6bGFUUkdQTDhJdUlPTk5Lb0k0RGpXSEdZRmNjNXkwQ2FUcTBYUi9TdDFh?= =?utf-8?B?dDZLbFNBMXBqMm9Kb2NBRGpwMklHdDN3VEVHUTBYb3RqWkZ0ZGovRCtDWUMz?= =?utf-8?B?L0FFNTZvZzduMDMzWXUzb2laOVA4dEF5UVhidkp2c2ExVVlXVVB0YnhSZVVU?= =?utf-8?B?OXdsSVdMSXZPUTRnRzR6bDVNR24rOXp4bmZuZExEWDQwZVdPemgxN2tTckhk?= =?utf-8?B?MXEvMzUwRm5KM3FQZDR5RkozTnZXRGcxMjg1bkVvcVB6VVczMmZJYzV6V0ZM?= =?utf-8?B?RGpPNmlidis3eDNUUFJtTk1DekZxQzhMTkIvOXhBcU43NzhkQVkzV1A5NWRQ?= =?utf-8?B?VGVFbGVYNUFKYlp4M2dKOEsrcnZUR0RrUG92SFppTHhYVGdqQ2VjMm02cmNr?= =?utf-8?B?RU45MHl0cENIbmtyeFBmMXZLdHNNSm14ZGZINXZ2TWg4ZFBTSE5GdXFSUzlm?= =?utf-8?B?YXNlNWV3WFhDZmRpZ0V3SHdRUzNYSks4dXZDVDRoYXdhY21lSGhhaG90V0Rv?= =?utf-8?B?eXZFUHV2ZGxkQzk5VUE0OTRvSytndml2WmhYYWNHSzdRREREYjlBMHh0K0Jo?= =?utf-8?B?bzFBNk9OK1pZUWhwOGUvVjNldGRmMFlXQ0szNHhDVXYwbFhiVkk5SVpRZjNC?= =?utf-8?B?ZlBhL0J3WW5JU0tZOHR6S2NaWVJtQnVicGpZZlJ3Y1FKQ29wZXMrUWdnQTJm?= =?utf-8?B?QzFuRWdjYzZTcE9GWU1uRUU2eE5HQ2ZMNVZ1ZGhJM3ltc3F1dnpIVWlTZGRT?= =?utf-8?B?ZzVva2RRYUV4amFLTzQ3d3haUnpBSndTNzNlSGdwdDJlVTBpWjBDazcwRmQ4?= =?utf-8?B?SzFEZmZ6dU5PeFVJc1R4dno0Z2hoV0NENS9SaG1kSHB0SDlXRjZCRmoxQXNO?= =?utf-8?B?dU9qeGVDUzNrRmh5RDRVUmpHQ2NCbHFvbFk3bXRGTEFJR243bERSUkpCWnZn?= =?utf-8?B?d2duaDE5dmZIS2k0RHV0bmgzUWRWWWozdHZtVWVUMFRJTDJzMjhxUi9HMnA2?= =?utf-8?B?NjI0S2JpUUV5Q3dydHh5R09hYUV6b2JJOGpOa21wRTU5eE5nVnlJR0hUWUg1?= =?utf-8?B?YktjZ3Exd0o4UGhUM3hGbENMb2hLMWlyYVlLMWFSZ05paGJ2aTQ5Q1NKcjk2?= =?utf-8?B?OW1adysvOExtTk5ndGFOcmgydmRwcGQvQjNVQ3poNTM1VVl5dDhWak01RE9a?= =?utf-8?B?eWdqcWFQd0VEeFhkTGo1K2hNbDRrSFBUVThqVGV3TEwvb1NtUXp2NS9WQkVn?= =?utf-8?B?bVhJUXNKTENDRnhBSnVLc0ZndVUyWUxhV3VFRkpEQUFLUlg1UE5yMHI0eXB0?= =?utf-8?B?dnVQRmw1OER3cFVSYk9BQXZ4cFV4TU5FemRLekF1cThDQUpYUVVFM0o0VWZo?= =?utf-8?B?ZUZZVmdHQnlKRG1kcllFNVRZZHBoVm1LeThEME8wdXo3T2pBWmQ0L0NaSTZN?= =?utf-8?Q?FFRsLdYk+SY5Da3IRMf/WvkvPc3?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO2PR00MB0168.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cf8daa7-7c8c-4100-9657-08d89d3404cc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 17:50:01.5802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: E1L6LyviQwfuTOB+9PrazHauymJkXfGn/lAxgOGIrKnVDBqsZ2kMLIZyqeYS+7TOtxtsd2pT+PA2LnyIDvoOAjuopEq2oWewgqQvneNcifQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0166 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:50:10 -0000 SU9UIGlzIGEgZ29vZCBwb2ludC4gU2luY2UgdGhpcyB3YXMgcGFydCBvZiBteSByZXZpZXcgY29t bWVudHMgSSBhbSBjb252aW5jZWQgdGhhdCB3ZSBkbyBub3QgbmVlZCB0byBtYWtlIHRoZXNlIGEg U0hPVUxEIHJlcXVpcmVtZW50LiBNQVkgaW1wbGVtZW50IGZvciBwZXJmb3JtYW5jZSB3aWxsIHN1 ZmZpY2UuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdGNwbSA8dGNwbS1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWXVjaHVuZyBDaGVuZw0KU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDEwLCAyMDIwIDg6MjMgQU0NClRvOiBKb3NlcGggVG91Y2ggPHRvdWNoQHN0 cmF5YWxwaGEuY29tPg0KQ2M6IHRjcG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPg0KU3ViamVj dDogW0VYVEVSTkFMXSBSZTogW3RjcG1dIDc5M2JpczogYWRkIFNIT1VMRCBvbiBvdGhlciBjb21t b24gb3B0aW9ucw0KDQpJIGFncmVlIHdpdGggTmVhbCBhbmQgSWFuIHRoYXQgdGhlc2UgZmVhdHVy ZXMgYXJlIGhpZ2hseSB1c2VmdWwgZm9yIFRDUCAocGVyZm9ybWFuY2UpLiBCdXQgSSBhbHNvIGFn cmVlIGFkZGluZyBuZXcgU0hPVUxEL01VU1QvTUFZIGFmdGVyIHRoZSBleHRlbnNpdmUgV0cgcmV2 aWV3cyBpbiB0aGUgbGFzdCBtaW51dGUgaXMgbm90IGEgZ29vZCBpZGVhLiBJZiB0aGlzIG5ldyBS RkMgaXMgYWJvdXQgdGhlIG1pbmltYWwgcmVxdWlyZW1lbnQgdG8gaW1wbGVtZW50IFRDUCBjb3Jy ZWN0bHkgKGJ1dCBub3QgbmVjZXNzYXJpbHkgcGVyZm9ybWFudCBpbiB2YXJpb3VzIG5ldHdvcmtz KSwgdGhlbiBteSB2b3RlIGlzIHRvIGtlZXAgYXMtaXMuDQoNCg0KT24gVGh1LCBEZWMgMTAsIDIw MjAgYXQgODowMCBBTSBKb3NlcGggVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPiB3cm90ZToN Cj4NCj4gRmlyc3QsIGNhbiB3ZSBwbGVhc2UgTk9UIG9wZW4gdGhlIGZsb29kZ2F0ZXMgdG8g4oCc bGV04oCZcyBzZWUgaG93IHdlIGNhbiBjaGFuZ2UgVENQIHRvZGF54oCdLg0KPg0KPiBUaGF0IHdh c27igJl0IHRoZSBwb2ludCBvZiB0aGlzIHVwZGF0ZS4NCj4NCj4gU2Vjb25kLCB0aGUgZG9jIChh bmQgYWxsIGRvY3MpIHNob3VsZCBzY3J1YiBhbGwgdXNlcyBvZiBTSE9VTEQgdG8gZW5zdXJlIHRo YXQgY29uZGl0aW9ucyBmb3IgZXhjZXB0aW9ucyBhcmUgaW5kaWNhdGVkLiBJLmUuLCBTSE9VTEQg ZXhjZXB0IHdoZXJl4oCmLiBPdGhlcndpc2UsIHdl4oCZcmUgdGlsdGluZyB0aGUgb2RkcyAodnMg TUFZIG9yIE1VU1QpIGluIGEgd2F5IHRoYXQgYmVjb21lcyBtZXJlbHkgYW4gb3BlbmluZyBmb3Ig dGhlIGxvdWRlc3QgYWR2b2NhdGVzLCB3aGljaCBkb2VzbuKAmXQgaGVscCBhbnlvbmUuDQo+DQo+ IEZpbmFsbHksIG9uIHRoaXMgb25lIGluIHBhcnRpY3VsYXIsIE5PLg0KPg0KPiBBZ2Fpbiwgd2Ug YXJlbuKAmXQgb3BlbmluZyB0aGUgZmxvb2RnYXRlcyB0byByZWNvbnNpZGVyaW5nIFRDUOKAmXMg ZGVzaWduLiBJZiB0aGUgY2FzZSBoYXNu4oCZdCBhbHJlYWR5IGJlZW4gbWFkZSBpbiBhIGRyYWZ0 IGluIGRldGFpbCwgd2Ugc2hvdWxkIE5PVCBiZSBjb25zaWRlcmluZyB0aGUgY2hhbmdlIGF0IHRo aXMgcG9pbnQuDQo+DQo+IEZ1cnRoZXIsIHRoZXNlIG9ubHkg4oCcc2hvb3QgeW91IGluIHRoZSBm b2904oCdLCBpLmUuLCBpZiB5b3UgZG9u4oCZdCBpbXBsZW1lbnQgdGhlbSwgeW91IGJhc2ljYWxs eSBvbmx5IGh1cnQgeW91ciBvd24gY29ubmVjdGlvbnMuIFNvIHRoZXJl4oCZcyBhbHJlYWR5IGlu Y2VudGl2ZSBmb3IgY2FwYWJsZSBlbmRwb2ludHMgdG8gaW1wbGVtZW50IHRoZW0uDQo+DQo+IE5l dmVybWluZCB0aGUgZmFjdCB0aGF0IHRoaXMgd291bGQgc2V2ZXJlbHkgaW1wYWN0IElPVCBhbmQg b3RoZXIgc3VjaCB1c2VzLCB3aGljaCBJIGFtIHN1cnByaXNlZCBoYXMgbm90IGJlZW4gY29uc2lk ZXJlZC4NCj4NCj4gSm9lDQo+DQo+IE9uIERlYyA5LCAyMDIwLCBhdCA3OjQ0IFBNLCBXZXNsZXkg RWRkeSA8d2VzQG10aS1zeXN0ZW1zLmNvbT4gd3JvdGU6DQo+DQo+IFRoZXJlJ3MgYmVlbiBhIHN1 Z2dlc3Rpb24gdGhhdCB3ZSBtYWtlIGEgc3Ryb25nZXIgc3RhdGVtZW50IG9uIHN1cHBvcnQgZm9y IHRoZSBjb21tb24gKGJ1dCBub3QgcmVxdWlyZWQpIG9wdGlvbnMgbGlrZSBTQUNLLCBUaW1lc3Rh bXAsIGFuZCBXaW5kb3cgU2NhbGluZy4NCj4NCj4gQ3VycmVudCB0ZXh0IGp1c3QgaW5kaWNhdGVz IHRoYXQgdGhlc2UgYXJlIHJlY29tbWVuZGVkOg0KPg0KPiAgICAgICAgIE90aGVyIENvbW1vbiBP cHRpb25zDQo+DQo+ICAgICAgICAgQWRkaXRpb25hbCBSRkNzIGRlZmluZSBzb21lIG90aGVyIGNv bW1vbmx5IHVzZWQgb3B0aW9ucyB0aGF0IGFyZQ0KPiAgICAgICAgIHJlY29tbWVuZGVkIHRvIGlt cGxlbWVudC4gIFRoZXNlIGFyZSB0aGUgVENQIFNlbGVjdGl2ZQ0KPiAgICAgICAgIEFja25vd2xl ZGdlbWVudCAoU0FDSykgb3B0aW9uIFsxOF1bMjFdLCBUQ1AgVGltZXN0YW1wIChUUykNCj4gICAg ICAgICBvcHRpb24gWzQzXSwgYW5kIFRDUCBXaW5kb3cgU2NhbGluZyAoV1MpIG9wdGlvbiBbNDNd Lg0KPg0KPiBJIGRvbid0IGhhdmUgYW55IGlzc3VlcyB3aXRoIGFwcGVuZGluZyBhIHN0cm9uZ2Vy IHN0YXRlbWVudCBzb21ldGhpbmcgbGlrZToNCj4NCj4gVENQIGltcGxlbWVudGF0aW9ucyBTSE9V TEQgc3VwcG9ydCB0aGVzZSBvcHRpb25zLg0KPg0KPiBXb3VsZCB0aGF0IHN1ZmZpY2U/ICBBcmUg dGhlcmUgb2JqZWN0aW9ucyBvciBvdGhlciBzdWdnZXN0aW9ucyBvbiB3aGF0IGV4YWN0bHkgdG8g c2F5Pw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy4NCj4gaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTA0JTdD MDElN0NwcmF2YiU0MG1pY3Jvcw0KPiBvZnQuY29tJTdDOTBiZDcwOThjOGYxNDdmN2JjYWYwOGQ4 OWQyODAwMjglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkDQo+IDAxMWRiNDclN0MxJTdDMCU3 QzYzNzQzMjE0MjQyMzQ3NDE3MSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU0NCj4g QzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNE JTdDMzAwMCZhbXA7cw0KPiBkYXRhPWRueW5OS2N4MjdUMmFaTkYlMkZ2SnFKcTlXdU15TW1McGMl MkZuTG5vSTlhejJZJTNEJmFtcDtyZXNlcnZlZD0wDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRj cG1AaWV0Zi5vcmcNCj4gaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lg0KPiBpZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDQlN0MwMSU3Q3ByYXZiJTQwbWljcm9zDQo+IG9mdC5jb20l N0M5MGJkNzA5OGM4ZjE0N2Y3YmNhZjA4ZDg5ZDI4MDAyOCU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QNCj4gMDExZGI0NyU3QzElN0MwJTdDNjM3NDMyMTQyNDIzNDc0MTcxJTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTQ0KPiBDNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MzMDAwJmFtcDtzDQo+IGRhdGE9ZG55bk5LY3gy N1QyYVpORiUyRnZKcUpxOVd1TXlNbUxwYyUyRm5Mbm9JOWF6MlklM0QmYW1wO3Jlc2VydmVkPTAN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0g bWFpbGluZyBsaXN0DQp0Y3BtQGlldGYub3JnDQpodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWls bWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTA0JTdDMDElN0NwcmF2YiU0MG1pY3Jvc29m dC5jb20lN0M5MGJkNzA5OGM4ZjE0N2Y3YmNhZjA4ZDg5ZDI4MDAyOCU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2Mzc0MzIxNDI0MjM0NzQxNzElN0NVbmtub3du JTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRp STZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMzAwMCZhbXA7c2RhdGE9ZG55bk5LY3gyN1QyYVpO RiUyRnZKcUpxOVd1TXlNbUxwYyUyRm5Mbm9JOWF6MlklM0QmYW1wO3Jlc2VydmVkPTANCg== From nobody Thu Dec 10 10:42:46 2020 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 487283A11CB for ; Thu, 10 Dec 2020 10:42:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 4U7JxWpnb-tH for ; Thu, 10 Dec 2020 10:42:30 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 227413A11FB for ; Thu, 10 Dec 2020 10:42:30 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id o8so6634720ioh.0 for ; Thu, 10 Dec 2020 10:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FmWgwHMsb43dNj7HkOumRP9k4+G9snv/hntIdNwx7HQ=; b=EDhJ6vMYbCoJLpU0TcYW1K20iRQjLUNxOGRZI7Chqi8n9K5ytwwb7POpjwu6orpxdS RKndMiC7jIr1IfB+O9NkJq+o+w0XTppU6GQsi08Y98dBDbmVtxcWQXwL+BdURiPIH91y yuJW75t2cmzSKs3p/7EEAQTDmYI5PXq2unwjn/zH745cSTg1DhyYbv47gBBHMaYIKKOW /+4CY2Qofr55+C25otvQv6Ejdw8MBQtbChqrMG+XoYU0ELQvW7wUnb8BZmPTnd/9ezKD WxZeilyN/k5sEiHm7s/2Xcs44k3vbbHM/+gWWTBlHmF35oGxRnYlsolt9LeTLfi1c0nt 8zFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FmWgwHMsb43dNj7HkOumRP9k4+G9snv/hntIdNwx7HQ=; b=V+3Y230kMK1DFrsFv1RLXG66HpGR986dfs8WVf/94/G6FhYDgs53g86wK6H3S2PCC/ WJVw6BwYG40WnRO2UtP14pTSufF2XieVs6ohjBYUMXBQElRt3Z/ZqubMTJXiXRehar7P cyWU+PrhsfPJ4c/TSl5JwQAQ7Ws26Mp4OmQc6tPpiC++sYN0Nr8Y1wJHlMVzaCozeaia m/ndJop5w/Xavyq5O7QtzWnZ1t77LZMvlcNzi7g0cMMWj44JnOPpU4t+C05HlMr7mSok 5/9JkYUPm7LKDnthAVTqyPRS2YROEFQgLayqUFlFla1b2gt0jbiXyjzLaIVOttPVynnr q71w== X-Gm-Message-State: AOAM531/hET79uo5mcrlat147uAaYPT+SJAdto+9DVwXPmDDKpaL86Rk xx1d/Te3UDDBhs2XQY93kwRAiFfi66n1RnYvLMI= X-Google-Smtp-Source: ABdhPJy8rkmsaOUZ0DZF52ixtcQt12SYbi4FxYCQM1rIc5EfY5afMkFUO6RZioJqjUOX7Xf1M609E+UEa9ohTHCo8NA= X-Received: by 2002:a02:a88a:: with SMTP id l10mr10029551jam.95.1607625749299; Thu, 10 Dec 2020 10:42:29 -0800 (PST) MIME-Version: 1.0 References: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> In-Reply-To: From: Martin Duke Date: Thu, 10 Dec 2020 10:42:19 -0800 Message-ID: To: Neal Cardwell Cc: "Rodney W. Grimes" , Praveen Balasubramanian , Yuchung Cheng , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b806ef05b6208990" Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 18:42:40 -0000 --000000000000b806ef05b6208990 Content-Type: text/plain; charset="UTF-8" I like Neal's change, though it might help understanding to say that 5681 is the only standard at time of writing. On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell wrote: > On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes > wrote: > >> > +1 to proposed change. >> > >> > It might be odd to say this as a co-author of BBR. I think mentioning >> > BBR or Cubic as prominent examples may be a bit biased. There are many >> > prominent great congestion control (for different scope/area/type of >> > networks) that are not possible to list them all. I would not mind if >> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have >> > been discussed at length in the IETF but not yet standardized. ' >> > > +1 to removing CUBIC or BBR as references. > > I would suggest instead a recommendation that emphasizes a general phrase > that is less susceptible to bit rot over the next 10-20 years, like a > "congestion control algorithm from the IETF Standards Track". > > Perhaps something like: > > A TCP endpoint MUST implement at least some basic congestion control > algorithm suitable for avoiding congestion collapse conditions (MUST-19). Multiple > suitable algorithms exist and have been widely used. Many TCP > implementations support a set of alternative algorithms that can be > configured for use on the endpoint. It is RECOMMENDED that a TCP > implementation include at least one congestion control algorithm from the > IETF Standards Track. > > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000b806ef05b6208990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like Neal's change, though it might help understandi= ng to say that 5681 is the only standard at time of writing.

<= div class=3D"gmail_quote">
On Thu, Dec= 10, 2020 at 6:10 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
=
On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes <ietf@gndrsh.dnsmgr.net&g= t; wrote:
> +1 to proposed change.
>
> It might be odd to say this as a co-author of BBR. I think mentioning<= br> > BBR or Cubic as prominent examples may be a bit biased. There are many=
> prominent great congestion control (for different scope/area/type of > networks) that are not possible to list them all. I would not mind if<= br> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that hav= e
> been discussed at length in the IETF but not yet standardized.=C2=A0 &= #39;

+1 to removing CUBIC or BBR as referenc= es.

I = would suggest instead a recommendation that emphasizes a general phrase tha= t is less susceptible to bit rot over the next 10-20 years, like a "co= ngestion control algorithm from the IETF Standards Track".

Perhaps something like:

A TCP endpoint MUST implement=C2=A0at= least some basic congestion control algorithm suitable for avoiding conges= tion collapse conditions (MUST-19). Multiple suitable algorithms exist and have bee= n widely used.=C2=A0Many TCP implementations support a set of alte= rnative algorithms that can be configured for use on the endpoint.=C2=A0It is REC= OMMENDED that a TCP implementation include at least one congestion control = algorithm from the IETF Standards Track.
neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000b806ef05b6208990-- From nobody Thu Dec 10 11:11:28 2020 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 E866A3A11F0 for ; Thu, 10 Dec 2020 11:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 nm1kCsN8X5mF for ; Thu, 10 Dec 2020 11:11:25 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 2BEB23A11ED for ; Thu, 10 Dec 2020 11:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1HMMjQ6Ig8lcXjetejb4fyqThjObnBrGOyqHd/LxnPE=; b=PHlpZmTwnkT7w6uYrBFAcS73GH e3uJ4TvxR0SETgINAtbm9zvOmLL+3T/EwWpuNLTkW4U2H76gfwyROLtvPtykvk8wVsORPpE5vMiTh ZizMu4pim9MO8miFClSkbhQj9sd8O04ogEOzGsEWgSdogqV2mrPMZ1XLDLrLlTI4W7c9ZALlqVFKH QO4s6h42zKou6MQQTjjDleVNwWK95QdZ9ZSCIksBOQ9Chv3Y2iDauo0CerO+cPmVUydrRFcgrOXRz Iz2Dad/OnCIHhdA9YbFJrLIfWkmMnYMFeeh/JOQ0uBVacxnRTA3Jc7A/FVRYwBaSJvGXcIvAau+9b UQydWwpw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51496 helo=[192.168.1.17]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knRLT-001QoN-Ab; Thu, 10 Dec 2020 14:11:24 -0500 Content-Type: multipart/alternative; boundary=Apple-Mail-E9EDB440-E2BB-4282-95E3-7792D3AC41B3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: Date: Thu, 10 Dec 2020 11:11:18 -0800 Cc: Neal Cardwell , Praveen Balasubramanian , tcpm@ietf.org, Yuchung Cheng Message-Id: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> References: To: Martin Duke X-Mailer: iPhone Mail (18B121) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 19:11:27 -0000 --Apple-Mail-E9EDB440-E2BB-4282-95E3-7792D3AC41B3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Why not use that text in the MUST? Otherwise we=E2=80=99re making a drastic change in requirements.=20 > On Dec 10, 2020, at 10:44 AM, Martin Duke wrote:= >=20 > =EF=BB=BF > I like Neal's change, though it might help understanding to say that 5681 i= s the only standard at time of writing. >=20 >> On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell wrote: >>> On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes wrote: >>=20 >>> > +1 to proposed change. >>> >=20 >>> > It might be odd to say this as a co-author of BBR. I think mentioning >>> > BBR or Cubic as prominent examples may be a bit biased. There are many= >>> > prominent great congestion control (for different scope/area/type of >>> > networks) that are not possible to list them all. I would not mind if >>> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have >>> > been discussed at length in the IETF but not yet standardized. ' >>=20 >> +1 to removing CUBIC or BBR as references. >>=20 >> I would suggest instead a recommendation that emphasizes a general phrase= that is less susceptible to bit rot over the next 10-20 years, like a "cong= estion control algorithm from the IETF Standards Track". >>=20 >> Perhaps something like: >>=20 >> A TCP endpoint MUST implement at least some basic congestion control algo= rithm suitable for avoiding congestion collapse conditions (MUST-19). Multip= le suitable algorithms exist and have been widely used. Many TCP implementat= ions support a set of alternative algorithms that can be configured for use o= n the endpoint. It is RECOMMENDED that a TCP implementation include at least= one congestion control algorithm from the IETF Standards Track. >>=20 >> neal >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail-E9EDB440-E2BB-4282-95E3-7792D3AC41B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Why not use that text in t= he MUST?

Otherwise we=E2=80= =99re making a drastic change in requirements. 
<= br>
On Dec 10, 2020, at 10:44 AM, Martin Duke <m= artin.h.duke@gmail.com> wrote:

=EF=BB=BF
I like Neal's change, t= hough it might help understanding to say that 5681 is the only standard at t= ime of writing.

On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell <ncardwel= l=3D40google.com@dmarc.ietf.o= rg> wrote:
=
On Thu, Dec 10, 2020 at 8:53 AM Rodney W. G= rimes <ietf@g= ndrsh.dnsmgr.net> wrote:
> +1 to proposed change.
>
> It might be odd to say this as a co-author of BBR. I think mentioning > BBR or Cubic as prominent examples may be a bit biased. There are many<= br> > prominent great congestion control (for different scope/area/type of > networks) that are not possible to list them all. I would not mind if > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have
= > been discussed at length in the IETF but not yet standardized.  '<= br>

+1 to removing CUBIC or BBR as references.

I would s= uggest instead a recommendation that emphasizes a general phrase that is les= s susceptible to bit rot over the next 10-20 years, like a "congestion contr= ol algorithm from the IETF Standards Track".

Perhaps somet= hing like:
A TCP endpoint MUST implement at least some basic conges= tion control algorithm suitable for avoiding congestion collapse conditions (= MUST-19). = Multiple suitable algorithms exist and have been widely used. = Many TCP implementations support a set of alternative algorithms that can be= configured for use on the endpoint. It is RECOMMENDED that a TCP implementati= on include at least one congestion control algorithm from the IETF Standards= Track.

neal

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm m= ailing list
tcpm@ietf.org
https://www.ietf.o= rg/mailman/listinfo/tcpm
= --Apple-Mail-E9EDB440-E2BB-4282-95E3-7792D3AC41B3-- From nobody Thu Dec 10 11:48:16 2020 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 566913A124F for ; Thu, 10 Dec 2020 11:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 Fv15C3Spzi7G for ; Thu, 10 Dec 2020 11:48:12 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 80D553A1234 for ; Thu, 10 Dec 2020 11:48:12 -0800 (PST) Received: from xse102.mail2web.com ([66.113.196.102] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1knRB2-000Y0b-D0 for tcpm@ietf.org; Thu, 10 Dec 2020 20:00:43 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CsNWy6msWz9vS for ; Thu, 10 Dec 2020 10:59:58 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1knRAU-00044v-QK for tcpm@ietf.org; Thu, 10 Dec 2020 10:59:58 -0800 Received: (qmail 20792 invoked from network); 10 Dec 2020 18:59:58 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Dec 2020 18:59:57 -0000 To: Martin Duke , Neal Cardwell Cc: Praveen Balasubramanian , "tcpm@ietf.org" , Yuchung Cheng References: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> From: Christian Huitema Message-ID: <11ac2919-edb1-5997-c452-fc722074645d@huitema.net> Date: Thu, 10 Dec 2020 10:59:56 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0592036EC98BF989938F6A2C" Content-Language: en-US X-Originating-IP: 66.113.196.102 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.102/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.102/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCHjY g+9f9LHDeU+OLkSuxRjmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjXixzL8ehbIG9sA3S3I0sdME5LN1n8YXzQY0mQUNzTGA6mwRNpj5snmK3jmyZjmm2JH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuuZLq0mDbdxseg/Mf69yzUU0 7DHaQb7rNMFNxR7dmYQq2JUne37EdXOqrRyXv4wznqY2w9haDFQBu9ffCH3zScc11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs161dhC9/ypj8hBtwyrCvOxdPCC/cRgvQKtcrMMueERx3a9W+ ptmuTiNQxU6G87mzEtf/dsqmFImVCa21PJmeoROIaIzNoZzswxuMaWjBAlpw7M2QCRsY/cPShB9p PqWtC/Uf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 19:48:14 -0000 This is a multi-part message in MIME format. --------------0592036EC98BF989938F6A2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I am torn between two points. On one hand, I get Joe's argument that 793bis is not the place to re-litigate the standardization of congestion control algorithms. On the other hand, I resent that loss-based congestion control like Reno or Cubic pretty much caused the buffer bloat issue. If we want to deliver low latency across the Internet, implementations will have to move away from Reno and Cubic and adopt CC algorithms that avoid building large queues. Yes, 793bis is not the place to discuss such algorithms. But we should avoid a message that enshrines loss based congestion control forever. Which is why I like Neal's formulation. It is reasonably neutral, but it also does not mortgage the future. -- Christian Huitema On 12/10/2020 10:42 AM, Martin Duke wrote: > I like Neal's change, though it might help understanding to say that > 5681 is the only standard at time of writing. > > On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell > > wrote: > > On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes > > wrote: > > > +1 to proposed change. > > > > It might be odd to say this as a co-author of BBR. I think > mentioning > > BBR or Cubic as prominent examples may be a bit biased. > There are many > > prominent great congestion control (for different > scope/area/type of > > networks) that are not possible to list them all. I would > not mind if > > we remove 'CUBIC [RFC8312] and BBR are prominent examples > that have > > been discussed at length in the IETF but not yet > standardized.  ' > > > +1 to removing CUBIC or BBR as references. > > I would suggest instead a recommendation that emphasizes a general > phrase that is less susceptible to bit rot over the next 10-20 > years, like a "congestion control algorithm from the IETF > Standards Track". > > Perhaps something like: > > A TCP endpoint MUST implement at least some basic congestion > control algorithm suitable for avoiding congestion collapse > conditions (MUST-19). Multiple suitable algorithms exist and have > been widely used. Many TCP implementations support a set of > alternative algorithms that can be configured for use on the > endpoint. It is RECOMMENDED that a TCP implementation include at > least one congestion control algorithm from the IETF Standards Track. > > neal > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------0592036EC98BF989938F6A2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I am torn between two points. On one hand, I get Joe's argument that 793bis is not the place to re-litigate the standardization of congestion control algorithms. On the other hand, I resent that loss-based congestion control like Reno or Cubic pretty much caused the buffer bloat issue. If we want to deliver low latency across the Internet, implementations will have to move away from Reno and Cubic and adopt CC algorithms that avoid building large queues. Yes, 793bis is not the place to discuss such algorithms. But we should avoid a message that enshrines loss based congestion control forever. Which is why I like Neal's formulation. It is reasonably neutral, but it also does not mortgage the future.

-- Christian Huitema

On 12/10/2020 10:42 AM, Martin Duke wrote:
I like Neal's change, though it might help understanding to say that 5681 is the only standard at time of writing.

On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org> wrote:
On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> wrote:
> +1 to proposed change.
>
> It might be odd to say this as a co-author of BBR. I think mentioning
> BBR or Cubic as prominent examples may be a bit biased. There are many
> prominent great congestion control (for different scope/area/type of
> networks) that are not possible to list them all. I would not mind if
> we remove 'CUBIC [RFC8312] and BBR are prominent examples that have
> been discussed at length in the IETF but not yet standardized.  '

+1 to removing CUBIC or BBR as references.

I would suggest instead a recommendation that emphasizes a general phrase that is less susceptible to bit rot over the next 10-20 years, like a "congestion control algorithm from the IETF Standards Track".

Perhaps something like:

A TCP endpoint MUST implement at least some basic congestion control algorithm suitable for avoiding congestion collapse conditions (MUST-19). Multiple suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. It is RECOMMENDED that a TCP implementation include at least one congestion control algorithm from the IETF Standards Track.

neal

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--------------0592036EC98BF989938F6A2C-- From nobody Thu Dec 10 12:03:29 2020 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 42F403A0B0E for ; Thu, 10 Dec 2020 12:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 c1wKO3kn9rJE for ; Thu, 10 Dec 2020 12:03:26 -0800 (PST) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 DCF433A1270 for ; Thu, 10 Dec 2020 12:03:01 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id r7so6763890wrc.5 for ; Thu, 10 Dec 2020 12:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AVjBfirbCJWlX3Z/aqZxle9pplfd+z9A0hXrWHqfB+U=; b=La1yHKF5718cX0RIYSVl7263JcT17lLwvzZzVEqPcuXAArCc9BCBf+PS4xHExSpIU4 mUtwtGXD739TVQ5h921/nXqUv1TFZtEv7HCYxYLY93kKOReARlUP2ZgWah/hyeZAttuk cMXYQZOoaBuaBS5w1KgT3Wt/bwTi7iKGmS4y82QAHxwjIssZa18HnixWYb4iLxl6PBOb gd5DXmodNASGSDCLMfqoUDgL6oZQ5U5nd2EOQV9LGMEExdvtjI4VpchtDZDGZ/3I+vxx BIKrJ8RIWfs3BqhTHm28hAnqkji36XjSkB7VxG+Lp+W7kWKYP4IZE7GAxQ7qim8a0X+m giOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AVjBfirbCJWlX3Z/aqZxle9pplfd+z9A0hXrWHqfB+U=; b=gEljbaeHler2/f/3iushIxsEDw0Z99g/wjPRxanoSnV/Jucn8ar5XcN7QM1aqRq1yi WNJrlIKNf9SD4aEwEB/97mFW6k4xGy4eh9sWma5fV7llncwvZggbYarm/AVvqQhbtJxN eOJ16VL6vU7l9FjW+PcWkwVRSUhiBFpGMnJATIY7vosrywGg0E8ZBWAKQoxlUwKjmfuE MYgG97SUqQC6REb5SfDGZcg1Ehc+j6pgfqPDboSkG4+KNSuGDiFaNB0sOmx+596F7ptF JTJASOcWhunzVOgcE4Ei67qWZ+hQ/RimIHXEkhjAfu6iKxLzJ2GdhZp6vtvrZThWsn3D kASA== X-Gm-Message-State: AOAM532CaPA0Ry8uWM83oAk9+Mwhm3Pf5MA37VgUqpyS1SwtUiZpQ+xC SZ0uT6apReHgWQ9WkOxN0AU38boW+8AFjXKME/qV0Q== X-Google-Smtp-Source: ABdhPJxyZi/yZ2bTjbQeQ0vzWCj31W1kl8j8yazdwBDftWg/zR45T5g/yFNPyqVcwsDbwYQs8vvg+QM2SCJg2KQGVaM= X-Received: by 2002:a5d:6a88:: with SMTP id s8mr10310032wru.118.1607630580154; Thu, 10 Dec 2020 12:03:00 -0800 (PST) MIME-Version: 1.0 References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> In-Reply-To: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> From: Yuchung Cheng Date: Thu, 10 Dec 2020 12:02:23 -0800 Message-ID: To: Joe Touch Cc: Martin Duke , Neal Cardwell , Praveen Balasubramanian , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 20:03:28 -0000 Joe: could you clarify what's the change you're suggesting? I like s/RECOMMENDED/MUST in Neal's text. On Thu, Dec 10, 2020 at 11:11 AM Joe Touch wrote: > > Why not use that text in the MUST? > > Otherwise we=E2=80=99re making a drastic change in requirements. > > On Dec 10, 2020, at 10:44 AM, Martin Duke wrote= : > > =EF=BB=BF > I like Neal's change, though it might help understanding to say that 5681= is the only standard at time of writing. > > On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell wrote: >> >> On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes wrote: >>> >>> > +1 to proposed change. >>> > >>> > It might be odd to say this as a co-author of BBR. I think mentioning >>> > BBR or Cubic as prominent examples may be a bit biased. There are man= y >>> > prominent great congestion control (for different scope/area/type of >>> > networks) that are not possible to list them all. I would not mind if >>> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have >>> > been discussed at length in the IETF but not yet standardized. ' >> >> >> +1 to removing CUBIC or BBR as references. >> >> I would suggest instead a recommendation that emphasizes a general phras= e that is less susceptible to bit rot over the next 10-20 years, like a "co= ngestion control algorithm from the IETF Standards Track". >> >> Perhaps something like: >> >> A TCP endpoint MUST implement at least some basic congestion control alg= orithm suitable for avoiding congestion collapse conditions (MUST-19). Mult= iple suitable algorithms exist and have been widely used. Many TCP implemen= tations support a set of alternative algorithms that can be configured for = use on the endpoint. It is RECOMMENDED that a TCP implementation include at= least one congestion control algorithm from the IETF Standards Track. >> >> neal >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 12:41:08 2020 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 BC7983A0C84 for ; Thu, 10 Dec 2020 12:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 mCtIQDVNcD3f for ; Thu, 10 Dec 2020 12:41:01 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 E9F6C3A0C77 for ; Thu, 10 Dec 2020 12:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=536u6zosDcmBJfmtD9L/uaDIb0+cC2/5s60QUOmJcYg=; b=ZcQgojaSxQsKh+F4B2MYxzsYL 6ODzokp3AqRFgVDaa5hcWTTICWAV672oK8Zts4mKcQpO9juFN8fUgKnr4JoEF2tB8Rrsx9KKaoFkE Yc7pORI6X4eiCsP/+UPp/uxarnw/TTkRKwBikVO/5vlklQMAwrfoGtyOtxvB+clpZfAW3vzDNtcbp +yiwzRILRFZasn++T3gAadBJW/t7xnNea8vWq/F1HU66xreoL/UlqEu+nqb7kxBBnEGDUL3hqI9q9 bTzVbGqXqOwKUKqCt60bGWnxQMAejVrfqgh3OmtM3MUeTelCbnbvpOJG7LllAG6iL9p/fad/oAms9 lmv4WlvQQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60808 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knSkC-002so8-Rx; Thu, 10 Dec 2020 15:41:01 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 10 Dec 2020 12:40:56 -0800 Cc: Martin Duke , Neal Cardwell , Praveen Balasubramanian , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> To: Yuchung Cheng X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 20:41:07 -0000 I=E2=80=99d suggest the following. The goal is to REMOVE the idea that = =E2=80=9Cdo what ever you want as long as it=E2=80=99s congestion = control=E2=80=9D is OK. --- A TCP endpoint MUST implement at least one congestion control algorithm = from the IETF Standards Track (MUST-19). Multiple suitable algorithms = exist and have been widely used. Many TCP implementations support a set = of alternative algorithms that can be configured for use on the = endpoint, but all MUST be standards-track. From nobody Thu Dec 10 12:58:40 2020 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 411723A1272 for ; Thu, 10 Dec 2020 12:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 w8Bdc5aWt3NT for ; Thu, 10 Dec 2020 12:58:37 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 298823A1268 for ; Thu, 10 Dec 2020 12:58:37 -0800 (PST) Received: from xse1.mail2web.com ([66.113.196.1] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1knT1F-000Uml-3d for tcpm@ietf.org; Thu, 10 Dec 2020 21:58:34 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CsR8j6GVMz3M65 for ; Thu, 10 Dec 2020 12:58:29 -0800 (PST) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1knT1B-0003wO-PG for tcpm@ietf.org; Thu, 10 Dec 2020 12:58:29 -0800 Received: (qmail 20197 invoked from network); 10 Dec 2020 20:58:29 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Dec 2020 20:58:29 -0000 To: Joseph Touch , Yuchung Cheng Cc: "tcpm@ietf.org Extensions" References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> From: Christian Huitema Message-ID: <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> Date: Thu, 10 Dec 2020 12:58:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.1 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.1/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.1/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCKZg 8DujejTr3FHNGdeOwQnmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjXixzL8ehbIG9sA3S3I0sdME5LN1n8YXzQY0mQUNzTGA8teNG+NZ/BA4WKnDt42T7xH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NDxdyIeJZUl7T+dBx2dACj+ZLq0mDbdxseg/Mf69yzUUa uA9750lbA3YD9a3+k1XdDRojSVizNl0ce/s7u0P9b5PUgQu2Mxbd4dUAOMnALSoI3NNm+Y5BUKGz 7XyDEWSpOTgtjQWHblEKb/bSn512wzF/xT0vdQ/ZQjlOk234ZSDZcpPgEJKLbDyaC/LdLvvYpKWz VymD7xCfNneJLrVMtfpVB9v9zY0h8asEYmbGGsJkWjQ4xyeNtxxq2TXT/AfNIW7lKDzq/pjhEhtz lDoy+BX0XF3qP/dj48psOHFCwviQxKSBCGH0S84CnKX/NUAV3jR5NeVaJQBh0uawl0Cg8nrgSS6D 7FozWS6JHKREtqdEPzY64lXv2dr2sny4a4Sj0cqzvWDlDrFILmNCVZ/264kd2x35zAiBFPp64JaI ysAWfpirH8g1GOR1IFGt5BWm X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 20:58:38 -0000 On 12/10/2020 12:40 PM, Joseph Touch wrote: > I’d suggest the following. The goal is to REMOVE the idea that “do what ever you want as long as it’s congestion control” is OK. > > --- > > A TCP endpoint MUST implement at least one congestion control algorithm from the IETF Standards Track (MUST-19). Multiple suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint, but all MUST be standards-track. I am not sure what "MUST be standards-track" means. Obviously that cannot mean "approved as a standard track RFC", because that's what the first sentence already says. You may want to say "described in an Internet draft submitted for standardization", but that's a pretty low bar. Overall, I think it is better to just keep Neal's original formulation. -- Christian Huitema From nobody Thu Dec 10 13:17:51 2020 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 CAC053A12A8 for ; Thu, 10 Dec 2020 13:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 n2BNnySzIPPE for ; Thu, 10 Dec 2020 13:17:47 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 DE37E3A12A5 for ; Thu, 10 Dec 2020 13:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=75bO6u11WuG1lvtLk8Owc3UkeYLu/D1ba0uwe1QZiVY=; b=jR7yYMd9xbGtbDStM9nqh9hEg qqlzGczwgwzxn0jdFx8UVuMeA8ihKiIRpcLgiP4NY1/x67UApAxkrFLjsZsZLWmyixshTfou0uWS3 yGHACP1FZYSCroOKAawDQMdw7UsP/FYs+qNGyt7K6uO5NldyrNZUwwdWQSxfKkkgUMixPoHupw0rd 2i4Q3inbhrL2xPUvTzRMkSXQ8s447lso9jZOBHGhdYA1TLOeNHXRMj5A6nm3bygx0PRN23V2SczV/ KlaJnWoy6D+I6GtqhZ25X2x4dw8+qNUUXaxH/prCkHzKsooiPNpfqgtqUBxEfbyhO6W5BpFrxdzp1 kVBg8MgqA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60808 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knSkv-002so8-GU; Thu, 10 Dec 2020 15:41:46 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_58CBB8DE-38FB-4058-9A95-DA1FB2EC178C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <11ac2919-edb1-5997-c452-fc722074645d@huitema.net> Date: Thu, 10 Dec 2020 12:41:41 -0800 Cc: Martin Duke , Neal Cardwell , Praveen Balasubramanian , Yuchung Cheng , "tcpm@ietf.org" Message-Id: <9276A189-E3C2-412F-843D-8B7A48E0516F@strayalpha.com> References: <202012101352.0BADqcwv092445@gndrsh.dnsmgr.net> <11ac2919-edb1-5997-c452-fc722074645d@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 21:17:50 -0000 --Apple-Mail=_58CBB8DE-38FB-4058-9A95-DA1FB2EC178C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW - I=E2=80=99m OK with Neal=E2=80=99s suggestion but am concerned = that the first sentence is too open. See my other post for my suggested = alternate. > On Dec 10, 2020, at 10:59 AM, Christian Huitema = wrote: >=20 > I am torn between two points. On one hand, I get Joe's argument that = 793bis is not the place to re-litigate the standardization of congestion = control algorithms. On the other hand, I resent that loss-based = congestion control like Reno or Cubic pretty much caused the buffer = bloat issue. If we want to deliver low latency across the Internet, = implementations will have to move away from Reno and Cubic and adopt CC = algorithms that avoid building large queues. Yes, 793bis is not the = place to discuss such algorithms. But we should avoid a message that = enshrines loss based congestion control forever. Which is why I like = Neal's formulation. It is reasonably neutral, but it also does not = mortgage the future. >=20 > -- Christian Huitema >=20 > On 12/10/2020 10:42 AM, Martin Duke wrote: >> I like Neal's change, though it might help understanding to say that = 5681 is the only standard at time of writing. >>=20 >> On Thu, Dec 10, 2020 at 6:10 AM Neal Cardwell = > wrote: >> On Thu, Dec 10, 2020 at 8:53 AM Rodney W. Grimes = > wrote: >> > +1 to proposed change. >> >=20 >> > It might be odd to say this as a co-author of BBR. I think = mentioning >> > BBR or Cubic as prominent examples may be a bit biased. There are = many >> > prominent great congestion control (for different scope/area/type = of >> > networks) that are not possible to list them all. I would not mind = if >> > we remove 'CUBIC [RFC8312] and BBR are prominent examples that have >> > been discussed at length in the IETF but not yet standardized. ' >>=20 >> +1 to removing CUBIC or BBR as references. >>=20 >> I would suggest instead a recommendation that emphasizes a general = phrase that is less susceptible to bit rot over the next 10-20 years, = like a "congestion control algorithm from the IETF Standards Track". >>=20 >> Perhaps something like: >>=20 >> A TCP endpoint MUST implement at least some basic congestion control = algorithm suitable for avoiding congestion collapse conditions = (MUST-19). Multiple suitable algorithms exist and have been widely used. = Many TCP implementations support a set of alternative algorithms that = can be configured for use on the endpoint. It is RECOMMENDED that a TCP = implementation include at least one congestion control algorithm from = the IETF Standards Track. >>=20 >> neal >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_58CBB8DE-38FB-4058-9A95-DA1FB2EC178C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW = - I=E2=80=99m OK with Neal=E2=80=99s suggestion but am concerned that = the first sentence is too open. See my other post for my suggested = alternate.

On Dec 10, 2020, at 10:59 AM, Christian = Huitema <huitema@huitema.net> wrote:

=20 =20

I am torn between two points. On one = hand, I get Joe's argument that 793bis is not the place to re-litigate the standardization of congestion control algorithms. On the other hand, I resent that loss-based congestion control like Reno or Cubic pretty much caused the buffer bloat issue. If we want to deliver low latency across the Internet, implementations will have to move away from Reno and Cubic and adopt CC algorithms that avoid building large queues. Yes, 793bis is not the place to discuss such algorithms. But we should avoid a message that enshrines loss based congestion control forever. Which is why I like Neal's formulation. It is reasonably neutral, but it also does not mortgage the = future.

-- Christian Huitema

On 12/10/2020 10:42 AM, Martin Duke wrote:
I like Neal's change, though it might = help understanding to say that 5681 is the only standard at time of writing.

On Thu, Dec 10, 2020 at = 6:10 AM Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> wrote:
On Thu, Dec 10, 2020 at 8:53 AM = Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> wrote:
> +1 to proposed change.
>
> It might be odd to say this as a co-author of BBR. I think mentioning
> BBR or Cubic as prominent examples may be a bit biased. There are many
> prominent great congestion control (for different scope/area/type of
> networks) that are not possible to list them all. I would not mind if
> we remove 'CUBIC [RFC8312] and BBR are prominent examples that have
> been discussed at length in the IETF but not yet standardized.  '

+1 to removing CUBIC or BBR as references.

I would suggest instead a recommendation that emphasizes a general phrase that is less susceptible to bit rot over the next 10-20 years, like a "congestion control algorithm from the IETF Standards Track".

Perhaps something like:

A TCP endpoint MUST implement at least some basic congestion control algorithm suitable for avoiding congestion collapse conditions (MUST-19). Multiple suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint. It is RECOMMENDED that a TCP implementation include at least one congestion control algorithm from the IETF Standards Track.

neal

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/m=
ailman/listinfo/tcpm
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_58CBB8DE-38FB-4058-9A95-DA1FB2EC178C-- From nobody Thu Dec 10 13:21:12 2020 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 1B5533A12A7 for ; Thu, 10 Dec 2020 13:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 bKcXkc5vW8BQ for ; Thu, 10 Dec 2020 13:21:08 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 924D13A12A8 for ; Thu, 10 Dec 2020 13:21:08 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id w13so10317654lfd.5 for ; Thu, 10 Dec 2020 13:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xqIUEoulkCT5v9IwGA4V4Eg4N89aqIbDD4aQ3PVk72g=; b=Wo/fS6zF10SFK+xNOgrxufAuHjfwJ+Ftz6nvzJi+bcDHqUvD6Qq1gkB38DGoB/Ziqw tqNLQqFHBsHCH0ynYCqZxux4AJBmfI945TLZcegPVHm39tTpKtcUVDGw5uFN+YkfAn5D D8EjDMyalL3ReyX2V9UAMlTBJTxT5T4LpbgQ3qIN21cuF8s0HEEu2R/QxPKrReHfq5X+ CiSBSaT0ObbWaSGW4u2R8Y7YG6vyolSBI2XVdX0o7p7sl3HN7Th47++VXCeTdHxTgdKv VGXdo+Q886JVt3olzYmamoMmEz1opuF1eB7sjw6dksvRuD8uJy9biO9h/KUmQwIiTUJC w9lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xqIUEoulkCT5v9IwGA4V4Eg4N89aqIbDD4aQ3PVk72g=; b=B+BcxEX/p41AEdgh9iGTCmFDf2IXidktpxfKcHDqykjFd9GqIj9LpKPFv0Mu5M5FeF AcG8vGRdfb+u+efExR2cLwrhRb5o5oedSFeGWmCCsunQWw6v+yMvgofBIbj4ENHYGAVN nFO+py9UGE9uGlR2XECTlmQDAJ3Ky+HORloV9fDALeE1DugCJPjET0amiqGzy4qIfmpG G2uQTQ1C7YihLytJ/39MU9g5eLcHaqbCtlswfxNGW6YrpXtH+LIHFj88CDsbJVcBBrzZ ILLFeJdr3JMnXpoZO3ZUmirNARhiMFU6sPv2l79w7P5nNuQhHSN0/b+Uu3qzIXCBF337 XF2g== X-Gm-Message-State: AOAM531fm1sATAUmBhfbNVf7hLXadxziVwz7xAeOQrLp0mpEhk996zmd hNjpEk7oNhzGwKk7162um/E= X-Google-Smtp-Source: ABdhPJz1MeVy3BnGwvArb0sIcpQmQCyGeVLo/VyplVZ5H90KHryYtScmgvF7lcGL5/WTB8bO6Wb6pQ== X-Received: by 2002:ac2:59c9:: with SMTP id x9mr3504098lfn.481.1607635266533; Thu, 10 Dec 2020 13:21:06 -0800 (PST) Received: from jonathartonsmbp.lan (178-55-241-81.bb.dnainternet.fi. [178.55.241.81]) by smtp.gmail.com with ESMTPSA id f22sm732043ljn.113.2020.12.10.13.21.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2020 13:21:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Thu, 10 Dec 2020 23:21:04 +0200 Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <70F65AC4-EA0E-4E0C-9594-96997D9539DE@gmail.com> References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> To: Joseph Touch X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 21:21:10 -0000 > On 10 Dec, 2020, at 10:40 pm, Joseph Touch = wrote: >=20 > A TCP endpoint MUST implement at least one congestion control = algorithm from the IETF Standards Track (MUST-19). Multiple suitable = algorithms exist and have been widely used. Many TCP implementations = support a set of alternative algorithms that can be configured for use = on the endpoint, but all MUST be standards-track. The above phrasing is problematic because it would make a TCP = implementing CUBIC (which is currently experimental) non-compliant, even = if it defaulted to NewReno (which is standards track). Better would be: 1: MUST implement at least one standards-track algorithm. Presently = that means NewReno, but it looks like CUBIC will be added to the list in = the foreseeable future. Rationale: these algorithms have been proven = through long experience. 2: MAY implement other algorithms, which MUST all be "suitable for = avoiding congestion collapse conditions" as Neal put it. I think this results in two distinct MUST requirements, but more = granularly captures the actual needs - which include responsible = experimentation. - Jonathan Morton= From nobody Thu Dec 10 13:50:46 2020 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 2C7EB3A12DB for ; Thu, 10 Dec 2020 13:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 eK2Jl7oQlGBh for ; Thu, 10 Dec 2020 13:50:43 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 B9E323A12D9 for ; Thu, 10 Dec 2020 13:50:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=+KKM8bMXyI9/udlC0Zv4cB7p9FGvAqcNROl3RW0MgcU=; b=N4Bsei7z3Ady4Fb52LHciejKa zi6IjljHHBLQuwmt5NVAX/bXCtrYQ28thW2G2aGM85+HfvKFSS6NvaK0W7/eDAmqzfCbHv4Vxn7n9 9RmNY8JsZ3iEy3+T7t8jsABCAYBpEu8wvULYviR+b4nmGj2aFCfqcX6rmbS8zRkuzZyZpjkT0soTg Q41alg0EOT9XEAvZx/LJ/UthIQkGs6UlIkLMyJikD5Nb9U1l/iSYZuX0ApLsqaUnDMgfu7HpPyYK6 FmfTwmjXLj5sJ2xL91v+HPGSTQ3AAw9NTG+x6v8P/jwVWbGXnsLsA0Z2mBYEDyzMRvj1m6QlJ4fq1 Q6sfDSVkA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60907 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knTpe-0043um-L8; Thu, 10 Dec 2020 16:50:43 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <70F65AC4-EA0E-4E0C-9594-96997D9539DE@gmail.com> Date: Thu, 10 Dec 2020 13:50:37 -0800 Cc: "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <70F65AC4-EA0E-4E0C-9594-96997D9539DE@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 21:50:45 -0000 If you want an set of rules, IMO: - MUST implement at least one standards-track CC alg - MUST default to a standards-track CC all - MAY implement other CCs, as long as they are TCP-friendly as per = RFCxxx (can=E2=80=99t recall which one would be best) I don=E2=80=99t think. =E2=80=9CAvoids congestion collapse=E2=80=9D is = sufficient. We need to ensure they=E2=80=99re not aggressive vs. TCP = standards CC lags. Joe > On Dec 10, 2020, at 1:21 PM, Jonathan Morton = wrote: >=20 >> On 10 Dec, 2020, at 10:40 pm, Joseph Touch = wrote: >>=20 >> A TCP endpoint MUST implement at least one congestion control = algorithm from the IETF Standards Track (MUST-19). Multiple suitable = algorithms exist and have been widely used. Many TCP implementations = support a set of alternative algorithms that can be configured for use = on the endpoint, but all MUST be standards-track. >=20 > The above phrasing is problematic because it would make a TCP = implementing CUBIC (which is currently experimental) non-compliant, even = if it defaulted to NewReno (which is standards track). Better would be: >=20 > 1: MUST implement at least one standards-track algorithm. Presently = that means NewReno, but it looks like CUBIC will be added to the list in = the foreseeable future. Rationale: these algorithms have been proven = through long experience. >=20 > 2: MAY implement other algorithms, which MUST all be "suitable for = avoiding congestion collapse conditions" as Neal put it. >=20 > I think this results in two distinct MUST requirements, but more = granularly captures the actual needs - which include responsible = experimentation. >=20 > - Jonathan Morton > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 13:52:31 2020 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 1E2A53A12D9 for ; Thu, 10 Dec 2020 13:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 8v8CH8u6KAu1 for ; Thu, 10 Dec 2020 13:52:28 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 B5FB53A12D8 for ; Thu, 10 Dec 2020 13:52:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7zTnhBO5awYD56dEpxDwn++vkb6xtvnBr4szJFx7sD0=; b=qj6MIrOPylLGl+RJKJw+jRt9Z /eEQXpRQkZk4MnX3k4tj+c6HU1727C4Gl0qzO60RvSDpKJ2bBPC1+GMPF0VKMIQt3P8WPeEPDfAu1 keIA5kTJVuHL8I8lknBkI75sVZK3urRWJ8nHhodygPEPn++9Ng8V3wlDh8qrcKx5zccYrTvERhd83 j7rXS6TOl65k+PEjLs96tMVlxzwXaco2KdGiimu2bkkF4bQb+rdDxb080vIpBmYDKeDhFmGvTJk9o bWz4NCQuBff6epV8PAd6QEXIXJjOk56/4h9sjnNsPwNrStgIIhU+kmmK1H+oi44vPN1kpB2y34N2O 8JdTlvqUQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60919 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knTrL-004590-Qw; Thu, 10 Dec 2020 16:52:28 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> Date: Thu, 10 Dec 2020 13:52:23 -0800 Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 21:52:30 -0000 > On Dec 10, 2020, at 12:58 PM, Christian Huitema = wrote: >=20 >=20 > On 12/10/2020 12:40 PM, Joseph Touch wrote: >> I=E2=80=99d suggest the following. The goal is to REMOVE the idea = that =E2=80=9Cdo what ever you want as long as it=E2=80=99s congestion = control=E2=80=9D is OK. >>=20 >> --- >>=20 >> A TCP endpoint MUST implement at least one congestion control = algorithm from the IETF Standards Track (MUST-19). Multiple suitable = algorithms exist and have been widely used. Many TCP implementations = support a set of alternative algorithms that can be configured for use = on the endpoint, but all MUST be standards-track. >=20 > I am not sure what "MUST be standards-track" means. Obviously that = cannot mean "approved as a standard track RFC", because that's what the = first sentence already says. First says =E2=80=9CMUST do at least one=E2=80=9D Last says =E2=80=9Ccan do others, but they MUST be standards too=E2=80=9D = -=20 - agreed that=E2=80=99s too strong, but we do need = =E2=80=9CTCP-friendly" there, not just =E2=80=9Cavoids collapse=E2=80=9D. - so, IMO, =E2=80=9CMAY do others, but each one MUST be = TCP-friendly=E2=80=9D Joe > You may want to say "described in an Internet draft submitted for = standardization", but that's a pretty low bar. Overall, I think it is = better to just keep Neal's original formulation. >=20 > -- Christian Huitema >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 15:45:24 2020 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 8DFAB3A1377 for ; Thu, 10 Dec 2020 15:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 kfYAqTV8t_nX for ; Thu, 10 Dec 2020 15:45:15 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 409853A1350 for ; Thu, 10 Dec 2020 15:45:15 -0800 (PST) Received: from xse101.mail2web.com ([66.113.196.101] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1knVcI-000sm3-2i for tcpm@ietf.org; Fri, 11 Dec 2020 00:45:11 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4CsVrf04Kqz3T8p for ; Thu, 10 Dec 2020 15:44:50 -0800 (PST) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1knVc9-0005Oj-SQ for tcpm@ietf.org; Thu, 10 Dec 2020 15:44:49 -0800 Received: (qmail 7260 invoked from network); 10 Dec 2020 23:44:49 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Dec 2020 23:44:48 -0000 To: Joseph Touch Cc: "tcpm@ietf.org Extensions" References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> From: Christian Huitema Message-ID: <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> Date: Thu, 10 Dec 2020 15:44:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.101 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.101/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.101/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCOXc ZOcrN3DDvKtWrI3PXBbmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjXixzL8ehbIG9sA3S3I0sdME5LN1n8YXzQY0mQUNzTGA6mwRNpj5snmK3jmyZjmm2JH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuuZLq0mDbdxseg/Mf69yzUW9 TjUdPKhCLpZZYarVEnvz2JUne37EdXOqrRyXv4wznjA08FLvVADy8LB0Htmu5lw11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs12dbay1uBmcjbmCY3bWMBYRPCC/cRgvQKtcrMMueERx3m19X ghxKSxZ7p4i5kGLZjeCV26Sz/GqtElkHWp2Nis+IaIzNoZzswxuMaWjBAlpwQKAF9rx7E/FOOo0H C4C4+PUf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 23:45:23 -0000 On 12/10/2020 1:52 PM, Joseph Touch wrote: > First says “MUST do at least one” > Last says “can do others, but they MUST be standards too” - > - agreed that’s too strong, but we do need “TCP-friendly" there, not just “avoids collapse”. > - so, IMO, “MAY do others, but each one MUST be TCP-friendly” I would not be too happy with that. The usual meaning of TCP friendly is, "competes fairly with a TCP implementation using New Reno." One could argue that Cubic does not do that, at least not on large BDP paths: it will drive the packet error rate to a level at which Reno collapses. One could also argue that both Reno and Cubic have some very undesirable side effects, such as increasing the sizes of queues at the bottleneck. I want a future Internet that get rid of those side effects, not one in which we get long queues and large latency forever. "Avoid collapse" would suit me fine. If we want to say something more, we have to define what TCP Friendly actually means -- avoid starving implementations using Reno would be OK, enforce parity with Reno would not be. -- Christian Huitema From nobody Thu Dec 10 16:16:00 2020 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 B4A9C3A1370 for ; Thu, 10 Dec 2020 16:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Iv-NKa6xNGgQ for ; Thu, 10 Dec 2020 16:15:57 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 16A523A136D for ; Thu, 10 Dec 2020 16:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sdNWb/uLn6rWC/e64/1D/1UcsRWcOANK6K2mGdkQ3Fo=; b=vbmgM2Zb6A5xqHZ5jWk+Z9p7f KvRn0FEoKJsE/U+Dv7dPZobldMWSMdgwrzyOga9QpjulDOH9u20aXojD5+ClWEP4ERv3NiKz54rqm 8BiJwcjQXUEx8hNL/yOcSnXw/m1y092LlQ26n2xKiz1S/+m8Yqcu/Qvr4e5FmABQHOQDJEVKw6Du9 R6K5mVPxIZXQ81bRBuy6f1KDtnJjCV8VSL68QSgJLDjxyjg0t2h0FHyNaEkAGZs48DU0dvJxdphpb e3dtYCxQFAVKVqH5ygJtR8nUnqQA9LF50yoIP+X1yGaYgIiBAASTLcyiILzsISNvmh1EubgIVwxCp DilaMm2rA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61058 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knW6C-0022Gx-9V; Thu, 10 Dec 2020 19:15:56 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> Date: Thu, 10 Dec 2020 16:15:51 -0800 Cc: "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 00:15:59 -0000 Would you accept =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D? That opens it up beyond Reno, allows it to evolve, but still keeps a = leash on the solutions. "Avoids collapse=E2=80=9D is too open; it allows aggressive approaches = that themselves get capacity at the expense of others. That=E2=80=99s = the issue - not merely whether collapse occurs. Joe > On Dec 10, 2020, at 3:44 PM, Christian Huitema = wrote: >=20 > On 12/10/2020 1:52 PM, Joseph Touch wrote: >=20 >> First says =E2=80=9CMUST do at least one=E2=80=9D >> Last says =E2=80=9Ccan do others, but they MUST be standards too=E2=80=9D= - >> - agreed that=E2=80=99s too strong, but we do need = =E2=80=9CTCP-friendly" there, not just =E2=80=9Cavoids collapse=E2=80=9D. >> - so, IMO, =E2=80=9CMAY do others, but each one MUST be = TCP-friendly=E2=80=9D >=20 > I would not be too happy with that. The usual meaning of TCP friendly = is, "competes fairly with a TCP implementation using New Reno." One = could argue that Cubic does not do that, at least not on large BDP = paths: it will drive the packet error rate to a level at which Reno = collapses. One could also argue that both Reno and Cubic have some very = undesirable side effects, such as increasing the sizes of queues at the = bottleneck. I want a future Internet that get rid of those side effects, = not one in which we get long queues and large latency forever. "Avoid = collapse" would suit me fine. If we want to say something more, we have = to define what TCP Friendly actually means -- avoid starving = implementations using Reno would be OK, enforce parity with Reno would = not be. >=20 > -- Christian Huitema >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 16:52:54 2020 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 E458D3A13AF for ; Thu, 10 Dec 2020 16:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 pCqWz83ltHAo for ; Thu, 10 Dec 2020 16:52:44 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 0C6E03A139C for ; Thu, 10 Dec 2020 16:52:43 -0800 (PST) Received: from xse150.mail2web.com ([66.113.196.150] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1knWfm-000jIS-Cs for tcpm@ietf.org; Fri, 11 Dec 2020 01:52:41 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4CsXLs2fhlzDDx for ; Thu, 10 Dec 2020 16:52:37 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1knWfl-0005Hw-8r for tcpm@ietf.org; Thu, 10 Dec 2020 16:52:37 -0800 Received: (qmail 11796 invoked from network); 11 Dec 2020 00:52:36 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Dec 2020 00:52:35 -0000 To: Joseph Touch Cc: "tcpm@ietf.org Extensions" References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> From: Christian Huitema Message-ID: Date: Thu, 10 Dec 2020 16:52:34 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.150 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.150/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.150/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yjTC8Fov82/EJuxz8FihBPKj/EwzSHE5FGYwwjsNRPCD7s 6c+rmuZBXNEXZ0Rx92PmD6wdmZPcItWbGe10hXJtyz/MWLF6jnm7fdxjsJMmvxOMEZrAzcbOYTBU Hb9yjjXixzL8ehbIG9sA3S3I0sdME5LN1n8YXzQY0mQUNzTGA6mwRNpj5snmK3jmyZjmm2JH3v3Q 7PQeNoNQjwiv3IhNPpDsdaHHqGG7YXgprtn5XLToE7g5LY8o1a6sSJrLl3xdARnv/HGR54G9CHRY hyVqYO/Ae1h1hLGGi4ebv387hThA9A+LrmkGouiRB8qN/5RbHDa6yUUKFnWNneAcuva3BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuuZLq0mDbdxseg/Mf69yzUVo 5hetsIpFpXmrO4wFWKZ22JUne37EdXOqrRyXv4wznp6VEDH1GucU8+AOV8jFU6U11lqdy1V/0aEk MCdb3YpWUo4/+EUytKrR9Md9I2Rs1+bBqc7hOuCr3QvuR6/jMd9PCC/cRgvQKtcrMMueERx3Ymf8 pO3Z6Ops5yPSJjNafpTsjT+2FAcWBJmd4gieca+IaIzNoZzswxuMaWjBAlpw3yF0aUj4sEG2a3xH JTILm/Uf9oDBqtClgM5jH/om1Q5UomG0v+rwIiID/kwKc8V5Tj9+FRkaOS/DNjANmb8tO61SbYdY AwdpaVzHW7wHO7YhEWyJzIkwSFAW0Pw8uiKeubcolFl/rX+2ReQklqJDASQX2Id+W5hjJNcdGs0+ iHjXODmj5PX/tZQU3bYnWKpb X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 00:52:53 -0000 Something like “friendly to TCP standards-track CC”, or something like "following standard recommendations for TCP-Friendliness." But at this point I think I talked too much, will let others chime in. -- Christian Huitema On 12/10/2020 4:15 PM, Joseph Touch wrote: > Would you accept “friendly to TCP standards-track CC”? > > That opens it up beyond Reno, allows it to evolve, but still keeps a leash on the solutions. > > "Avoids collapse” is too open; it allows aggressive approaches that themselves get capacity at the expense of others. That’s the issue - not merely whether collapse occurs. > > Joe > >> On Dec 10, 2020, at 3:44 PM, Christian Huitema wrote: >> >> On 12/10/2020 1:52 PM, Joseph Touch wrote: >> >>> First says “MUST do at least one” >>> Last says “can do others, but they MUST be standards too” - >>> - agreed that’s too strong, but we do need “TCP-friendly" there, not just “avoids collapse”. >>> - so, IMO, “MAY do others, but each one MUST be TCP-friendly” >> I would not be too happy with that. The usual meaning of TCP friendly is, "competes fairly with a TCP implementation using New Reno." One could argue that Cubic does not do that, at least not on large BDP paths: it will drive the packet error rate to a level at which Reno collapses. One could also argue that both Reno and Cubic have some very undesirable side effects, such as increasing the sizes of queues at the bottleneck. I want a future Internet that get rid of those side effects, not one in which we get long queues and large latency forever. "Avoid collapse" would suit me fine. If we want to say something more, we have to define what TCP Friendly actually means -- avoid starving implementations using Reno would be OK, enforce parity with Reno would not be. >> >> -- Christian Huitema >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 18:02:19 2020 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 C3B7E3A15A9 for ; Thu, 10 Dec 2020 18:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AKVqJlKZf7Zv for ; Thu, 10 Dec 2020 18:02:10 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 351153A1415 for ; Thu, 10 Dec 2020 18:02:00 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id o17so8262128lfg.4 for ; Thu, 10 Dec 2020 18:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XBJpsHUi927resmhPgyQQoBRr0ROF1DqQuAoUgZ0XCE=; b=FrFjVNtLbp+S15w2C41rL4t4S/ouWquixs6qo6GgW84QLOOOYmr3Xtpp86/AzO7M8G ARsT6+quACwL7nrjSPB6eY06JEx5xHUYCiHm0PUZ1vuwFW8+3+pwOdeqqsbx7mqHbVsp oF+oJ09aJTeNOC/xqHD7WyaMRmHCWbs8AlPuChLS5n0vMMnigu/Negqkr9S/YWczBhEA Xx2bXPz4OCXdto7+JK7GQzz6f11f7evKul3hRrrUd1eeq5I5a0gCkq2npNZDNony4Xr9 2J1kMh/q3OlQQ9btwv3yuyS/NCk9HxEwt5At1FnWlhPBOJPSEVrWXnpBlkzZ92EpTHhG zuHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XBJpsHUi927resmhPgyQQoBRr0ROF1DqQuAoUgZ0XCE=; b=fuK54V6HmCfKVEcyQS2Amj8R8AIdCALocYrEtBASkJ9/vSoWqpFaqRXV1rZihuZWDM nNVHE+SaM4sTVzVqB3gRD97coQItzoojbIilFiljZtJ52n3DSHRa5qxkzzOK6IeZ5GXZ Wq4R0gNAyidjIjYtOXOFePX0z6updK/3ohF4KUzLI41xTcfQxF622OOQTXtTqF9SGBeK w+wzIpW/l3UGJFzaC+wWSHWty5GaX5FASwf0ukxVHvRnW8sJNli9gFrZOZWcP66JiLBE qHLDwRT124OHGNMuevSNr3Vk7vj5TdTzX74Lf3AVwx3IRby4DmT/0b7Kzs2aWKP1Ejfo AZtw== X-Gm-Message-State: AOAM530mazKzb1B6bTiLncLbSCcLFN14EW3/NPKQum0Tf9bdRQsFoSNY HDMHLYGw1rohp7zbEN8rywk= X-Google-Smtp-Source: ABdhPJz+ECPwadjX4La2QBGelr0sVFx+AbjJ+gLYKlkR8NTulsYN80cb6WKM5WtjX2ekCPkJ5ffOLg== X-Received: by 2002:a05:6512:3888:: with SMTP id n8mr1191996lft.458.1607652118445; Thu, 10 Dec 2020 18:01:58 -0800 (PST) Received: from jonathartonsmbp.lan (178-55-241-81.bb.dnainternet.fi. [178.55.241.81]) by smtp.gmail.com with ESMTPSA id h23sm625233lfc.246.2020.12.10.18.01.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2020 18:01:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Fri, 11 Dec 2020 04:01:56 +0200 Cc: Joseph Touch , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> To: Christian Huitema X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 02:02:18 -0000 > On 11 Dec, 2020, at 2:52 am, Christian Huitema = wrote: >=20 > Something like =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D, = or something like "following standard recommendations for = TCP-Friendliness." But at this point I think I talked too much, will let = others chime in. Isn't there an RFC somewhere which talks about what you should take into = account when designing a congestion control algorithm? It would surely = be appropriate to reference that. - Jonathan Morton= From nobody Thu Dec 10 20:32:24 2020 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 A57BE3A15AA for ; Thu, 10 Dec 2020 20:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 tXxAVQf9OYr2 for ; Thu, 10 Dec 2020 20:32:20 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 B7D153A15A7 for ; Thu, 10 Dec 2020 20:32:20 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id p7so4142058vsf.8 for ; Thu, 10 Dec 2020 20:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Uy87AipezqFzjLrrn6cIMdW2tdSurt7L5eNm2ysQ0/s=; b=HZUcVKC7yWW26AkQWy8kYTyH7/TpHjWVABXnjh7RfpnhkzON440fssKcVrCj7KGIMY iNxL5GB12CqxL7/bVIq7jbH+oqalawYGOoC5i0tHoIPZSBjtLJiPUkmyHD/JM8OFBSzL Ll7/qFGRjaVlCMAfdeHg5++EK3ZY0r0+3q18TMxEqGKXvBDqZCImqL+OiraFPAwOJvDg 44LhaytPS5rYL9hGgaz2xIaCnRjaVvkfBvtYz9vrDCJMqpzJRxGOixXwuPRY26GAve9B M3QL6nzDdkjs70Qx0FY1/RRE7fWuDvhZLeb+kBgbUNJIDN385bexS8IpBy6up9CzcdJI agFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Uy87AipezqFzjLrrn6cIMdW2tdSurt7L5eNm2ysQ0/s=; b=YRuNq/6ZzIU9o/2bgFb/wVpiI6YkxEfSv8rIpJSZKb3ZKmUqWR9xqzQZbZXU3uodBl ydbfpHz5yXsAsFikQXAa97f8BDk7IvOcucjnhjE+GnKZZp8wCOWja1057ciuAyhWJAub MA3MhpdyR1U/Iyvm1mQs3XbQBWluEF7cfdfgbOmbAkE9d6ASjIAgf1jD+Th4z3XtZCQC Xv0dWZSeLqE9E+VhHty39oTf8OBwI0CRRtThBtcKpIIukt9z/+fYEP9bKckwWdhDjqqq 6B3Xlt1nZPnDKexwBtgt4rekygTJYUBdpkvJWdLb+GkAsYGK1tA6j3vhVFesyxtom4+a 8Iuw== X-Gm-Message-State: AOAM531bCpPx9Rx26Q2q8vRfHfPc3PX8Wxdkz3vQyw/T9AKBdnDQkILw 13nkikENOm3DUK/ouO9Xgz8JFyEGjIcH4OZIPRPxmXwHF6etOEuR X-Google-Smtp-Source: ABdhPJzxuFEggpbCT9k9oKkXv5LDaMvEhz0NkF+ef33kwTu3ClxJ9WgYflEERVc89EZVZkX0m48bMiVnAHVi6DxbosY= X-Received: by 2002:a67:de97:: with SMTP id r23mr11859953vsk.44.1607661139519; Thu, 10 Dec 2020 20:32:19 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> In-Reply-To: From: Neal Cardwell Date: Thu, 10 Dec 2020 23:32:03 -0500 Message-ID: To: Praveen Balasubramanian Cc: "ycheng=40google.com@dmarc.ietf.org" , "touch@strayalpha.com" , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 04:32:23 -0000 To help address the IOT case, along the lines of Joe's "conditions for exceptions are indicated. I.e., SHOULD except where=E2=80=A6." remarks, one option would be to say that "These options are helpful for high performance and SHOULD be implemented except where resource constraints make this infeasible (e.g. constrained-node network devices with CPU or memory limits)." neal On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian wrote: > > IOT is a good point. Since this was part of my review comments I am convi= nced that we do not need to make these a SHOULD requirement. MAY implement = for performance will suffice. > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Thursday, December 10, 2020 8:23 AM > To: Joseph Touch > Cc: tcpm IETF list > Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common options > > I agree with Neal and Ian that these features are highly useful for TCP (= performance). But I also agree adding new SHOULD/MUST/MAY after the extensi= ve WG reviews in the last minute is not a good idea. If this new RFC is abo= ut the minimal requirement to implement TCP correctly (but not necessarily = performant in various networks), then my vote is to keep as-is. > > > On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch wrote= : > > > > First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s = see how we can change TCP today=E2=80=9D. > > > > That wasn=E2=80=99t the point of this update. > > > > Second, the doc (and all docs) should scrub all uses of SHOULD to ensur= e that conditions for exceptions are indicated. I.e., SHOULD except where= =E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs MAY or MUST) in a = way that becomes merely an opening for the loudest advocates, which doesn= =E2=80=99t help anyone. > > > > Finally, on this one in particular, NO. > > > > Again, we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2= =80=99s design. If the case hasn=E2=80=99t already been made in a draft in = detail, we should NOT be considering the change at this point. > > > > Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if y= ou don=E2=80=99t implement them, you basically only hurt your own connectio= ns. So there=E2=80=99s already incentive for capable endpoints to implement= them. > > > > Nevermind the fact that this would severely impact IOT and other such u= ses, which I am surprised has not been considered. > > > > Joe > > > > On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: > > > > There's been a suggestion that we make a stronger statement on support = for the common (but not required) options like SACK, Timestamp, and Window = Scaling. > > > > Current text just indicates that these are recommended: > > > > Other Common Options > > > > Additional RFCs define some other commonly used options that ar= e > > recommended to implement. These are the TCP Selective > > Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) > > option [43], and TCP Window Scaling (WS) option [43]. > > > > I don't have any issues with appending a stronger statement something l= ike: > > > > TCP implementations SHOULD support these options. > > > > Would that suffice? Are there objections or other suggestions on what = exactly to say? > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micro= s > > oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s > > data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved= =3D0 > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micro= s > > oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd > > 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s > > data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved= =3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.= com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DdnynNKcx27T2= aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 21:17:09 2020 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 531473A15CF for ; Thu, 10 Dec 2020 21:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 gXYPgO6q0W7r for ; Thu, 10 Dec 2020 21:17:06 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 0921D3A15CD for ; Thu, 10 Dec 2020 21:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pVO3W+s++El6zPbK7O5U7eyD3t1P0vX2U1VCOFXWhWs=; b=qwmf/05HdwBKsnDhvhr0c5bhf sxiVuyiIQRMzIomPqNxD2SyJW+0PMPiUn37ISEA3oDzUypcNgSQr8onts7fSCdkw1iI7osDrbc+L9 Jel7he3xFA29+SXotM3fZneXo4KlNorsAOXWpVqAZY+13Mldob5IvMyLJNDFcE+YF5sRO12PTj6Nn fzAa1y7iWOPHDkgIXweV6PQHxj6V0rUmUDu533PnvqaZMVHOBtKmyymicAWQGkbwoPZWaZ47GQs+g wK5inzccsOGRQtl46nEKcyn9Ys+yO3dDl3pm+apOUZOX0z1HkEDDhF41lpqaa76L0Y0pzwMMUtCwL gRL0Qkezw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63138 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knanc-002XCz-CZ; Fri, 11 Dec 2020 00:17:05 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_AB376763-AC7A-4F9B-BD28-D3142CEA56E8" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 10 Dec 2020 21:16:59 -0800 Cc: Praveen Balasubramanian , "tcpm@ietf.org" , "ycheng=40google.com@dmarc.ietf.org" Message-Id: <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> To: Neal Cardwell X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 05:17:08 -0000 --Apple-Mail=_AB376763-AC7A-4F9B-BD28-D3142CEA56E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree that it=E2=80=99s useful to suggest them for high performance, = but disagree with adding a new SHOULD. Again, we=E2=80=99re not here to open new issues - and more to the = point, these were updated in 2014 and no SHOULD was added at that time: Finally, we observe that most of the mechanisms defined in this document are important for LFNs and/or very high-speed networks. For low-speed networks, it might be a performance optimization to NOT use these mechanisms. A TCP vendor concerned about optimal performance over low-speed paths might consider turning these extensions off for low-speed paths, or allow a user or installation manager to disable them. Joe > On Dec 10, 2020, at 8:32 PM, Neal Cardwell = wrote: >=20 > To help address the IOT case, along the lines of Joe's "conditions for > exceptions are indicated. I.e., SHOULD except where=E2=80=A6." = remarks, one > option would be to say that "These options are helpful for high > performance and SHOULD be implemented except where resource > constraints make this infeasible (e.g. constrained-node network > devices with CPU or memory limits)." >=20 > neal >=20 > On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian > wrote: >>=20 >> IOT is a good point. Since this was part of my review comments I am = convinced that we do not need to make these a SHOULD requirement. MAY = implement for performance will suffice. >>=20 >> -----Original Message----- >> From: tcpm On Behalf Of Yuchung Cheng >> Sent: Thursday, December 10, 2020 8:23 AM >> To: Joseph Touch >> Cc: tcpm IETF list >> Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common = options >>=20 >> I agree with Neal and Ian that these features are highly useful for = TCP (performance). But I also agree adding new SHOULD/MUST/MAY after the = extensive WG reviews in the last minute is not a good idea. If this new = RFC is about the minimal requirement to implement TCP correctly (but not = necessarily performant in various networks), then my vote is to keep = as-is. >>=20 >>=20 >> On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch = wrote: >>>=20 >>> First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s= see how we can change TCP today=E2=80=9D. >>>=20 >>> That wasn=E2=80=99t the point of this update. >>>=20 >>> Second, the doc (and all docs) should scrub all uses of SHOULD to = ensure that conditions for exceptions are indicated. I.e., SHOULD except = where=E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs MAY or = MUST) in a way that becomes merely an opening for the loudest advocates, = which doesn=E2=80=99t help anyone. >>>=20 >>> Finally, on this one in particular, NO. >>>=20 >>> Again, we aren=E2=80=99t opening the floodgates to reconsidering = TCP=E2=80=99s design. If the case hasn=E2=80=99t already been made in a = draft in detail, we should NOT be considering the change at this point. >>>=20 >>> Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., = if you don=E2=80=99t implement them, you basically only hurt your own = connections. So there=E2=80=99s already incentive for capable endpoints = to implement them. >>>=20 >>> Nevermind the fact that this would severely impact IOT and other = such uses, which I am surprised has not been considered. >>>=20 >>> Joe >>>=20 >>> On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: >>>=20 >>> There's been a suggestion that we make a stronger statement on = support for the common (but not required) options like SACK, Timestamp, = and Window Scaling. >>>=20 >>> Current text just indicates that these are recommended: >>>=20 >>> Other Common Options >>>=20 >>> Additional RFCs define some other commonly used options that = are >>> recommended to implement. These are the TCP Selective >>> Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) >>> option [43], and TCP Window Scaling (WS) option [43]. >>>=20 >>> I don't have any issues with appending a stronger statement = something like: >>>=20 >>> TCP implementations SHOULD support these options. >>>=20 >>> Would that suffice? Are there objections or other suggestions on = what exactly to say? >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >>> = ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros >>> = oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd >>> = 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >>> = C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >>> = data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0= >>>=20 >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >>> = ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros >>> = oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd >>> = 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >>> = C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >>> = data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0= >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.= com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DdnynNKcx2= 7T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_AB376763-AC7A-4F9B-BD28-D3142CEA56E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = agree that it=E2=80=99s useful to suggest them for high performance, but = disagree with adding a new SHOULD.

Again, we=E2=80=99re not here to open = new issues - and more to the point, these were updated in 2014 and no = SHOULD was added at that time:

   Finally, we observe that most of the mechanisms =
defined in this
   document are important for LFNs and/or very high-speed networks.  For
   low-speed networks, it might be a performance optimization to NOT use
   these mechanisms.  A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low-speed paths, or allow a user or installation manager to disable
   them.

Joe

On Dec 10, 2020, at 8:32 PM, Neal Cardwell = <ncardwell=3D40google.com@dmarc.ietf.org> = wrote:

To help address the IOT case, along the lines of Joe's = "conditions for
exceptions are indicated. I.e., SHOULD = except where=E2=80=A6." remarks, one
option would be to = say that "These options are helpful for high
performance = and SHOULD be implemented except where resource
constraints = make this infeasible (e.g. constrained-node network
devices = with CPU or memory limits)."

neal

On Thu, Dec 10, 2020 at 12:50 PM Praveen = Balasubramanian
<pravb=3D40microsoft.com@dmarc.ietf.org> wrote:

IOT is a = good point. Since this was part of my review comments I am convinced = that we do not need to make these a SHOULD requirement. MAY implement = for performance will suffice.

-----Original = Message-----
From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
Sent: Thursday, December 10, 2020 8:23 AM
To: = Joseph Touch <touch@strayalpha.com>
Cc: tcpm IETF list = <tcpm@ietf.org>
Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other = common options

I agree with Neal and Ian = that these features are highly useful for TCP (performance). But I also = agree adding new SHOULD/MUST/MAY after the extensive WG reviews in the = last minute is not a good idea. If this new RFC is about the minimal = requirement to implement TCP correctly (but not necessarily performant = in various networks), then my vote is to keep as-is.


On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch = <touch@strayalpha.com> wrote:

First, can we please NOT open = the floodgates to =E2=80=9Clet=E2=80=99s see how we can change TCP = today=E2=80=9D.

That wasn=E2=80=99t the = point of this update.

Second, the doc (and = all docs) should scrub all uses of SHOULD to ensure that conditions for = exceptions are indicated. I.e., SHOULD except where=E2=80=A6. Otherwise, = we=E2=80=99re tilting the odds (vs MAY or MUST) in a way that becomes = merely an opening for the loudest advocates, which doesn=E2=80=99t help = anyone.

Finally, on this one in particular, = NO.

Again, we aren=E2=80=99t opening the = floodgates to reconsidering TCP=E2=80=99s design. If the case hasn=E2=80=99= t already been made in a draft in detail, we should NOT be considering = the change at this point.

Further, these = only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if you don=E2=80=99t = implement them, you basically only hurt your own connections. So = there=E2=80=99s already incentive for capable endpoints to implement = them.

Nevermind the fact that this would = severely impact IOT and other such uses, which I am surprised has not = been considered.

Joe

On Dec 9, 2020, at 7:44 PM, Wesley Eddy <wes@mti-systems.com>= wrote:

There's been a suggestion that we = make a stronger statement on support for the common (but not required) = options like SACK, Timestamp, and Window Scaling.

Current text just indicates that these are recommended:

=        Other Common Options

=        Additional RFCs define some = other commonly used options that are
=        recommended to implement. =  These are the TCP Selective
=        Acknowledgement (SACK) option = [18][21], TCP Timestamp (TS)
=        option [43], and TCP Window = Scaling (WS) option [43].

I don't have any = issues with appending a stronger statement something like:

TCP implementations SHOULD support these = options.

Would that suffice?  Are = there objections or other suggestions on what exactly to say?


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cp= ravb%40micros
oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91= ab2d7cd
011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&amp;s
data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&a= mp;reserved=3D0


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cp= ravb%40micros
oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91= ab2d7cd
011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&amp;s
data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&a= mp;reserved=3D0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpra= vb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91= ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reser= ved=3D0
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

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

= --Apple-Mail=_AB376763-AC7A-4F9B-BD28-D3142CEA56E8-- From nobody Thu Dec 10 21:24:15 2020 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 460363A15D6 for ; Thu, 10 Dec 2020 21:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 4f3hmYf1kWUy for ; Thu, 10 Dec 2020 21:24:13 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 003323A15D4 for ; Thu, 10 Dec 2020 21:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=93/tIXeR5JMg5sSoHspL2Q+AYSHlpel4CJU3OXR8tT8=; b=mnEzG4csXdejH+1smHB5kAnJ2 R24kk9oD84ya3ZOqZ5MlVnaPFf0jfHwM9uHtXV92Drq6/Dkr+QpogMVoXV8+7VMdh0ZUT7tLPMOQG O44ktFkDE1zGqxFHyhq/XSzq8kHNRzjHWGgeeo9SLu/44weYvB9N0Ay5g9Q923DC2sN7JLskPlbOZ 1yzRirLG+WSlVni15kbW+IqJauu0VPfAmSEkqtV6k6GvZauEgU8fje7y0Ef/vWn8O8kDoj+fPSPnt igKVoSiugLBVicMkDRvslx3MZrBc39R6or0oHLzCjrIlio1cgrnrT3qH6cdGKV8nbieSspdLU9Psf /ZHg83Prg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:63196 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knauV-002fd5-QB; Fri, 11 Dec 2020 00:24:12 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 10 Dec 2020 21:24:06 -0800 Cc: Christian Huitema , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 05:24:14 -0000 RFC 5681 defines TCP CC, but does not define what constitutes = =E2=80=9Cfriendly=E2=80=9D. The closest is RFC 5348, but that defines = rate control known to be TCP friendly, not the parameters that define = =E2=80=9CTCP friendly=E2=80=9D in general. The closest I could find was = RFC8312, which as an oddly reverse definition that =E2=80=9Cfriendly=E2=80= =9D means =E2=80=9Cgives its users at least as much BW as conventional = TCP=E2=80=9D - but that=E2=80=99s not friendly at all, frankly (I can = easily design something that does that by turning off CC) =E2=80=94 it = really should be more like =E2=80=9Cgives its users no more BW than = conventional TCP=E2=80=9D. Anyone else find anything? > On Dec 10, 2020, at 6:01 PM, Jonathan Morton = wrote: >=20 >> On 11 Dec, 2020, at 2:52 am, Christian Huitema = wrote: >>=20 >> Something like =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D, = or something like "following standard recommendations for = TCP-Friendliness." But at this point I think I talked too much, will let = others chime in. >=20 > Isn't there an RFC somewhere which talks about what you should take = into account when designing a congestion control algorithm? It would = surely be appropriate to reference that. >=20 > - Jonathan Morton > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Dec 10 22:00:28 2020 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 561473A15EA for ; Thu, 10 Dec 2020 22:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ismNAj9GyCL4 for ; Thu, 10 Dec 2020 22:00:24 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4968F3A0B26 for ; Thu, 10 Dec 2020 22:00:24 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id m12so11778261lfo.7 for ; Thu, 10 Dec 2020 22:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lEvePldLo3BXQ5GuXUYTNgGV4tB4hCDwLLp/dXQb60g=; b=lE9yxavDG8f1qLwcnFBVvksyqtYGfikY0XlvKM5o8AFzwCLxRkCgJN8j5aMQwFthao 8lusdAtsS2ZB1rmIDGJmZ0YtZqnfM9QJLWZdO1dchwVCov2913eTLNoNNIKCSf8IM4Sh Z81VIEo7TrM6R227L5qJGhU8Yo25hjA1UdGNNp5oD+LFLeC6nFzFZ7mTGtqZIkkrRCiy mMoPoQ0dBAyDD1VnjCa7l3y+TTzMBhWk5ZMBjezH/0a81fu2VhBuvPZFOmbVUCwLFtDm ITA7HngO3Ckr3azIO0cNr0Qiwdh0o1oJ5eYwsWVKYNo0drdMq9rKS2Xhp+obIB4Xbfwr BZbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lEvePldLo3BXQ5GuXUYTNgGV4tB4hCDwLLp/dXQb60g=; b=rEyBIuWvXkD3fflt2WiNefOYuag6vThU1RC5fCl0hB/eai1HPwAotBAitGUQpvy9/2 LpM2zbawGIg7N0xhRnc1QjtHRJIudW6RtgnJA1mTLsn0g4E6RfVAsN0g41CtTgrSIRwQ 3dMJ3/VrNT94fSdeGjQjeu6tBgfawpNSOugdQIrrndTG85DtxbUYQNc0YH4iRrLFLYZc k1kh92Vbo/NBg50D6bKu2gpYmWc0Diil7MOZU/A+ScWXABRW/qxvAmYuLqsxPurTYlQy UpjLQ5kKFwH8f9+nCMn3+zmulce4rQRCouLlSuH2silJTNeSKa+MS24fnNXnOLUIsjxm XtvA== X-Gm-Message-State: AOAM531EkNJb/jPPcLd143nSu9hPIIa8PbuKSofRXaBqgIBBtIOQKFlO vX+CmnRd8mgn+91mLAXhRiA= X-Google-Smtp-Source: ABdhPJzScelsYzcHJUFw6H8FlwkfrevQxQj3dHjNVY6QfurAILqjTPM31FcEoIwLsJnuwO717C5Ujw== X-Received: by 2002:a19:c6c1:: with SMTP id w184mr4085374lff.553.1607666422319; Thu, 10 Dec 2020 22:00:22 -0800 (PST) Received: from jonathartonsmbp.lan (178-55-241-81.bb.dnainternet.fi. [178.55.241.81]) by smtp.gmail.com with ESMTPSA id d12sm868655ljl.111.2020.12.10.22.00.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Dec 2020 22:00:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: Date: Fri, 11 Dec 2020 08:00:20 +0200 Cc: Christian Huitema , "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <00271035-1B91-4848-B9D7-FBA2F287782B@gmail.com> References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> To: Joseph Touch X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 06:00:26 -0000 > On 11 Dec, 2020, at 7:24 am, Joseph Touch = wrote: >=20 > RFC 5681 defines TCP CC, but does not define what constitutes = =E2=80=9Cfriendly=E2=80=9D. The closest is RFC 5348, but that defines = rate control known to be TCP friendly, not the parameters that define = =E2=80=9CTCP friendly=E2=80=9D in general. The closest I could find was = RFC8312, which as an oddly reverse definition that =E2=80=9Cfriendly=E2=80= =9D means =E2=80=9Cgives its users at least as much BW as conventional = TCP=E2=80=9D - but that=E2=80=99s not friendly at all, frankly (I can = easily design something that does that by turning off CC) =E2=80=94 it = really should be more like =E2=80=9Cgives its users no more BW than = conventional TCP=E2=80=9D. >=20 > Anyone else find anything? I was thinking of RFC-5033. - Jonathan Morton >> On Dec 10, 2020, at 6:01 PM, Jonathan Morton = wrote: >>=20 >>> On 11 Dec, 2020, at 2:52 am, Christian Huitema = wrote: >>>=20 >>> Something like =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D, = or something like "following standard recommendations for = TCP-Friendliness." But at this point I think I talked too much, will let = others chime in. >>=20 >> Isn't there an RFC somewhere which talks about what you should take = into account when designing a congestion control algorithm? It would = surely be appropriate to reference that. >>=20 >> - Jonathan Morton >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Thu Dec 10 22:05:50 2020 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 706CB3A15EA for ; Thu, 10 Dec 2020 22:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 BAaKE6_xCknI for ; Thu, 10 Dec 2020 22:05:46 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 E6EAD3A15E7 for ; Thu, 10 Dec 2020 22:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XQBexGpZUDQRIaP4yV6avodkmi3FfvkNdfJoayN4aoQ=; b=RSzzMv5n3Wers+MpdTB1jhqfs USjsUGL9otCvHbSPoPg72I/8J4SR8AJx5CZ/nFaxKgqStD4MNCqh/Q8lJg4QD0WWOz6kGcHh/dEZT hrRuL3ls3a33h6ggWKXIZ0BMVLzx1zbltkpyq2kCg1+hulkA0hNlJCriKQQWImS0eA583+76BQcG5 m54Op4UOVI/LEQhgdmVISYCSlVsBCUZ8S6J5HP7YmbvLX13Pevay1DI96/rEzkYlL1egBHUHrPl42 zIM5WIr8Tj0Q9/9UZJNENurZn/8HcusZ5P7Sa5CG3PZUZwuN68jXTvypNCO0F92VG0LFgflyKwazl uosMAnjzA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:64108 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knbYj-003Kyj-Ln; Fri, 11 Dec 2020 01:05:46 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <00271035-1B91-4848-B9D7-FBA2F287782B@gmail.com> Date: Thu, 10 Dec 2020 22:05:40 -0800 Cc: "tcpm@ietf.org Extensions" , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> <00271035-1B91-4848-B9D7-FBA2F287782B@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 06:05:48 -0000 That works. > On Dec 10, 2020, at 10:00 PM, Jonathan Morton = wrote: >=20 >> On 11 Dec, 2020, at 7:24 am, Joseph Touch = wrote: >>=20 >> RFC 5681 defines TCP CC, but does not define what constitutes = =E2=80=9Cfriendly=E2=80=9D. The closest is RFC 5348, but that defines = rate control known to be TCP friendly, not the parameters that define = =E2=80=9CTCP friendly=E2=80=9D in general. The closest I could find was = RFC8312, which as an oddly reverse definition that =E2=80=9Cfriendly=E2=80= =9D means =E2=80=9Cgives its users at least as much BW as conventional = TCP=E2=80=9D - but that=E2=80=99s not friendly at all, frankly (I can = easily design something that does that by turning off CC) =E2=80=94 it = really should be more like =E2=80=9Cgives its users no more BW than = conventional TCP=E2=80=9D. >>=20 >> Anyone else find anything? >=20 > I was thinking of RFC-5033. >=20 > - Jonathan Morton >=20 >=20 >>> On Dec 10, 2020, at 6:01 PM, Jonathan Morton = wrote: >>>=20 >>>> On 11 Dec, 2020, at 2:52 am, Christian Huitema = wrote: >>>>=20 >>>> Something like =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D, = or something like "following standard recommendations for = TCP-Friendliness." But at this point I think I talked too much, will let = others chime in. >>>=20 >>> Isn't there an RFC somewhere which talks about what you should take = into account when designing a congestion control algorithm? It would = surely be appropriate to reference that. >>>=20 >>> - Jonathan Morton >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Dec 11 01:58:54 2020 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 B3DA93A089A for ; Fri, 11 Dec 2020 01:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 Pm9Cugi-DQVO for ; Fri, 11 Dec 2020 01:58:42 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 524BC3A098D for ; Fri, 11 Dec 2020 01:58:42 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id 1so7868746qka.0 for ; Fri, 11 Dec 2020 01:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=diK2JYfARmPrjaDgTUdfqP7ZcANjCxXJ3/gk8g71kIs=; b=SkziWM0U+Xh4RblX3ScH/ElUn60tlKtGMA1Wu8pfUZEUlf7oAxEUW58YCg9EcAMlm3 p9OaWkja58vCG3gz+Xramy+35aJPed5cAalZavgrxSKNm1Q+e4/vZGVi2DFUUQH7EPvE zZ+gVeY0L/p5Y60/f0NKib2+AOMDPAmJYr7W5FlIqIo3ntFwd1vvZhiVgCvfjaSixRO+ gMYoblXeCUzrlOeYutxVA7xdUXwvqcsPO2uFAJRHG702b9rSj4Wd/tewJzc86JTlJUv/ WzMo/suts3CN8/n0hEFbPpFbbY+0KVwJ3S77iA2QFDZ7T8uqyqjWporWicDTOBmqs39A bdPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=diK2JYfARmPrjaDgTUdfqP7ZcANjCxXJ3/gk8g71kIs=; b=G1oJ4tSuAo/8RZjQ5kI5lkn+tMqig1lgEdQpWujB1e1mhZ5ongN8oZlhuZZ0oOn1bL +nTuRQbp3ki+pDyMDoWY8GDB6OMhPGfcgEUMZ9t+CoVES+q0EeLF3ljLKquhtMA2LviA TP5FSnFs/1wW6gogUzb+yTkweHB4lsv5QGOqSo9WBZFNSbjO7FDTaKSyLj3wrdvN1hdI F3qXNnjJkJ12Q5NT8gkVqI3NVH7LSsY0wQI+LD122yxtHBtCVHd2KZIeN2/c9Qyo/JjP /5TJvsFqvH9Ug48o7cSIvWvS81xJPY74FeagrMt7oQ+B8CNXlw/9s4M+4WeD6YMS65ID cQRw== X-Gm-Message-State: AOAM531B7fM6LwYG8dyGFx0MPCSze5sDrYZt2Yksa/CBcU6VZFnCYSJC iv9aEl2H+fgpxWsHwB1da7NdJWU1xusCYrBg2aVLLb/5 X-Google-Smtp-Source: ABdhPJzwWrGPug6lB3jRgYU6r2uF+3whG4t+J+imP6NZFrmlU5kN1jsW11PGF+7NCcYWN181Os36gklg8mfaPtQqhI4= X-Received: by 2002:a37:9f14:: with SMTP id i20mr14780777qke.321.1607680721025; Fri, 11 Dec 2020 01:58:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 11 Dec 2020 01:58:29 -0800 Message-ID: To: tcpm IETF list Content-Type: multipart/alternative; boundary="00000000000049fee905b62d567e" Archived-At: Subject: Re: [tcpm] Request for feedback on WG Adoption of RFC6937bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 09:58:52 -0000 --00000000000049fee905b62d567e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, This is just a reminder in case you forgot to express your opinion on this. We'll make a decision soon. Thanks, -- Yoshi on behalf of tcpm co-chairs On Mon, Nov 30, 2020 at 10:12 AM Yoshifumi Nishida wrote: > Hi folks, > > This mail starts a WG adoption call for RFC6937bis draft. > As we've already seen positive supports for this work, we are not asking > people who already expressed their opinions this time. (but, if you want = to > do it for some reason, please go ahead) > However, if you haven't done it yet, especially if you're against it, we > would like to encourage you to provide feedback. > > We are thinking that the intended status of the doc will be PS based on > the feedback we've seen so far. But, if you have opinions on it, please l= et > us know. > > Thank you so much, > -- > Yoshi on behalf of tcpm co-chairs > > > On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis 40google.com@dmarc.ietf.org> wrote: > >> The authors of PRR would like to update PRR to Proposed Standard status. >> This entails introducing a new document as an tcpm work item. >> >> *Please indicate (non) support and/or comment.* >> >> For more details see the tcpm meeting materials from IETF 109 >> minutes: >> https://datatracker.ietf.org/meeting/109/materials/minutes-109-tcpm-00 >> slides: https://tools.ietf.org/html/draft-mathis-tcpm-rfc6937bis-00 >> >> There were about four "I support this work" remarks at the mic (not >> recorded in the minutes), and about as many in the Meetecho chat. >> >> Abridged IETF/tcpm/PRRbis slides: >> -- >> PRR recap (RFC6937 experimental) >> PRR is a special congestion control effective only during fast recovery >> >> - When inflight >=3D ssthresh, send at loss_beta*rate_before_loss (e.= g. >> loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for Cubic) >> - When inflight < ssthresh, send at the same or twice the >> delivery_rate (more later) >> - Used by all congestion control modules in Linux during fast recover= y >> - Can be more dominant than the actual C.C. for lossy flows >> that=E2=80=99re in fast recovery constantly (e.g. video streaming = through policers) >> >> -- >> Current Status >> >> - >> >> PRR is widely deployed >> - >> >> At least three major OSs: Linux, Windows, (NetFlix) BSD >> - >> >> Vast majority of Web traffic for years >> - >> >> No changes to algorithms published in RFC 6937 >> - >> >> PRR-CRB - Conservative Reduction Bound - strict packet conversion >> during loss recovery >> - >> >> PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK >> during loss recovery >> - >> >> 2015 Heuristic to dynamically select which reduction bound >> - >> >> Only use PRR-SSRB when making good forward progress >> - >> >> ACKs that advanced snd.una and report no new losses >> - >> >> Resolves some pathological cases with token bucket policers >> - >> >> CC estimates ssthresh before it can possibly measure the token >> rate >> - >> >> The heuristic makes the best of a bad situation >> >> -- >> Tentative path forward >> >> - >> >> Adopt as a tcpm work item >> - >> >> Update the text >> - >> >> Normative RFC 2119 language >> - >> >> Add MAY use the heuristic... >> - >> >> Trim redundant and obsolete language >> - >> >> RFC 6937 repeats itself and is much longer than necessary >> - >> >> Focus on what an implementer needs to know >> - >> >> Use non-normative references to RFC 6937 for prior measurement >> work, etc >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> We must not tolerate intolerance; >> however our response must be carefully measured: >> too strong would be hypocritical and risks spiraling out of >> control; >> too weak risks being mistaken for tacit approval. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > --00000000000049fee905b62d567e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,
This is just a reminder in = case you forgot to express your opinion=C2=A0on this.
We'll m= ake a decision soon.

Thanks,
--
Yoshi on behalf of tcpm co-chairs

On Mon, Nov 30, 2020 at 10:12 AM Yos= hifumi Nishida <nsd.ietf@gmail.com= > wrote:
=
Hi folks,

This mail starts a= WG adoption call for RFC6937bis draft.
As we've already seen= positive supports for this work, we are not asking people who already expr= essed their opinions this time. (but, if you want to do it for some reason,= please go ahead)=C2=A0
However, if you haven't done it yet, = especially if you're against it, we would like to encourage you to prov= ide feedback.

We are thinking that the intended st= atus of the doc will be PS based on the feedback we've seen so far. But= , if you have opinions on it, please let us know.

= Thank you so much,
--
Yoshi on behalf of tcpm co-chairs=


On Wed, Nov 18, 2020 at 7:56 PM Matt Mathis <mattmathis= =3D40googl= e.com@dmarc.ietf.org> wrote:
The autho= rs of PRR would like to update PRR to Proposed Standard status.=C2=A0 This = entails introducing a new document as an tcpm work item.
<= font color=3D"#000000">
Ple= ase indicate (non) support and/or comment.

For more details= see the tcpm meeting materials from IETF 109

There were about four "I support = this work" remarks at the mic (not recorded in the minutes), and about= as many in the Meetecho chat.

Abridged IETF/tcpm/PRRbis slides:
--
PRR =C2=A0recap (RFC6937 e= xperimental)
PRR is a special = congestion control effective only during fast recovery
  • When inflight >=3D ssthresh, send at loss_beta*rat= e_before_loss (e.g. loss_beta =3D 0.5 for Reno (aka rate-halving), 0.7 for = Cubic)
  • When inflight < ssthresh, = send at the same or twice the delivery_rate (more later)
  • Used by all congestion control modules in Linux during= fast recovery
    • Can be more domin= ant than the actual C.C. for lossy flows that=E2=80=99re in fast recovery c= onstantly (e.g. video streaming through policers)
--
Current Sta= tus

  • PRR is widely deployed<= /p>

    • At least three major OSs: Linux, Windows, (NetFlix) BSD

    • Vast majority of Web traffic for years

      =

  • No changes to algorithms published in RFC = 6937

    • PRR-CRB - Conservative Reduction Bound - strict packet con= version during loss recovery=C2=A0

    • = PRR-SSRB - Slowstart Reduction Bound - one extra segment per ACK during los= s recovery

  • 2015 Heuristic to dyn= amically select which reduction bound

    • Only use PRR-SSRB when ma= king good forward progress

      • ACKs that advanced snd.una and repor= t no new losses

    • <= p style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Resolves som= e pathological cases with token bucket policers

      • CC estimates ss= thresh before it can possibly measure the token rate

      • The heuristic makes the best of a bad situation

--
Tentative path forward=C2=A0

  • Adopt as a tcpm work item

  • Update the text

  • Normative RFC 2119 language

  • Add MAY use the heuristic...

    <= /li>

  • Trim redundant and ob= solete language

    • RFC 6937 repeats itse= lf and is much longer than necessary

    • Focus on what an implementer needs to know

    • Use non-norm= ative references to RFC 6937 for prior measurement work, etc

=
Th= anks,
--MM--
The best way to predict= the future is to create it. =C2=A0- Alan Kay

We must not tolerate i= ntolerance;
=C2=A0 =C2= =A0 =C2=A0 =C2=A0however our response must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 too strong would be hypocritical and risks spiraling out of control;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 too weak risks being mistaken for tacit approval.
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000049fee905b62d567e-- From nobody Fri Dec 11 08:56:32 2020 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 A369D3A0D09 for ; Fri, 11 Dec 2020 08:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 CMsbOy12PPyL for ; Fri, 11 Dec 2020 08:56:28 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 CD1A53A0964 for ; Fri, 11 Dec 2020 08:56:27 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id l14so8637037ybq.3 for ; Fri, 11 Dec 2020 08:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SDKLK896tEe38fJymxrfY7Itlf3VOaf0dezVgRKoXIU=; b=XQsbLs+5VCO/+FuBJFcOBdxHFW5DBI+smEaGv+6A0zAYidnltYPdmdGNBCs+GfwXa2 1Gnt5PExTQ9L0QCpcs72Zf7JFGtH908qk898fxIUcPsW7GZSZwgeu8YEtAW7r4PrMLfW j6KOQF03TvFCQ+Q8W4wKVZmJ4/ilAag8H8keMY1sEhPrrEElS1cxl5e0n7UQSwVAWO/y xz68jBxWDtbLS8k0J2TC7gV/PsrsSq7FzaBcr8vH9OuTmdVBku4nJbtXEqfdCiaqPhL0 KfVSSgEY96sTsW78onOpynBSUbV0wl8LSax0XO4DBBuG5dLIvByKi+9m+wBHLQ5pwimt qTNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SDKLK896tEe38fJymxrfY7Itlf3VOaf0dezVgRKoXIU=; b=s+HcQGQBILvJG4MMEnNOOQsx77xQyD5vpwjg3qFYEpgFLT6L3f/OSYv8A4gKc0baKH jQ1Uv0g9z5cyprru+Vw7rLDV566MPf89zSskxdvWEGzoKV4LGf9YzJn20p7crB8ZlR8p GwRDSoxAo0RWJXGMI+XRIkPQfc86e2qZA9U5MJtZf0R0o5NmgeCjsckD/V0nJX2+6oNG no/4lnblUg6W1H9iLr8BafGDgrPt6CUpEC3JFMCWiwek3y4kZJBA0q+mbHctLx/Yzpa7 2m21Fc4zgQaxNM8NNrWMQdPWPPR0rGP2ez/AJY1CxQibxbSMPDuscbGt3jFqqYKioq04 6D7Q== X-Gm-Message-State: AOAM532cWhxB4vQVi5lVYCkyywpEmloo4BQPiU6bnc9meXzunTLmfd/d W/ruxm5SSDjBmTMXEqmNbMcmtdVFVXIwRbTZpUuBhW4g5o4= X-Google-Smtp-Source: ABdhPJxNg/OHwMbLgF2wKi7a0lo2sEIEfShKRaQjuagHWQHarceiGXsSnahO4sekhWk0VXSSq5EMQfum38vpbrJ+xvU= X-Received: by 2002:a25:c095:: with SMTP id c143mr12477636ybf.119.1607705786747; Fri, 11 Dec 2020 08:56:26 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> In-Reply-To: <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> From: Ian Swett Date: Fri, 11 Dec 2020 11:56:15 -0500 Message-ID: To: Joseph Touch Cc: Neal Cardwell , Praveen Balasubramanian , "ycheng=40google.com@dmarc.ietf.org" , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000530ca305b6332cdf" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 16:56:31 -0000 --000000000000530ca305b6332cdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In my opinion, we already have an issue, because a non-normative 'recommended' is used. A reasonable reading is this was intended as the normative RECOMMENDED, but no one ever bothered to capitalize it, but it seems there's some disagreement on whether that was the case. If you're not going to make it normative, I'd suggest you choose a different word than recommended or remove the last part of the sentence. As stated before, I'd suggest you capitalize it and make it normative. On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch wrote: > I agree that it=E2=80=99s useful to suggest them for high performance, bu= t > disagree with adding a new SHOULD. > > Again, we=E2=80=99re not here to open new issues - and more to the point,= these > were updated in 2014 and no SHOULD was added at that time: > > Finally, we observe that most of the mechanisms defined in this > document are important for LFNs and/or very high-speed networks. For > low-speed networks, it might be a performance optimization to NOT use > these mechanisms. A TCP vendor concerned about optimal performance > over low-speed paths might consider turning these extensions off for > low-speed paths, or allow a user or installation manager to disable > them. > > > Joe > > On Dec 10, 2020, at 8:32 PM, Neal Cardwell < > ncardwell=3D40google.com@dmarc.ietf.org> wrote: > > To help address the IOT case, along the lines of Joe's "conditions for > exceptions are indicated. I.e., SHOULD except where=E2=80=A6." remarks, o= ne > option would be to say that "These options are helpful for high > performance and SHOULD be implemented except where resource > constraints make this infeasible (e.g. constrained-node network > devices with CPU or memory limits)." > > neal > > On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian > wrote: > > > IOT is a good point. Since this was part of my review comments I am > convinced that we do not need to make these a SHOULD requirement. MAY > implement for performance will suffice. > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Thursday, December 10, 2020 8:23 AM > To: Joseph Touch > Cc: tcpm IETF list > Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common options > > I agree with Neal and Ian that these features are highly useful for TCP > (performance). But I also agree adding new SHOULD/MUST/MAY after the > extensive WG reviews in the last minute is not a good idea. If this new R= FC > is about the minimal requirement to implement TCP correctly (but not > necessarily performant in various networks), then my vote is to keep as-i= s. > > > On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch wrote= : > > > First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s se= e how we can > change TCP today=E2=80=9D. > > That wasn=E2=80=99t the point of this update. > > Second, the doc (and all docs) should scrub all uses of SHOULD to ensure > that conditions for exceptions are indicated. I.e., SHOULD except where= =E2=80=A6. > Otherwise, we=E2=80=99re tilting the odds (vs MAY or MUST) in a way that = becomes > merely an opening for the loudest advocates, which doesn=E2=80=99t help a= nyone. > > Finally, on this one in particular, NO. > > Again, we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2= =80=99s design. If > the case hasn=E2=80=99t already been made in a draft in detail, we should= NOT be > considering the change at this point. > > Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if you= don=E2=80=99t implement > them, you basically only hurt your own connections. So there=E2=80=99s al= ready > incentive for capable endpoints to implement them. > > Nevermind the fact that this would severely impact IOT and other such > uses, which I am surprised has not been considered. > > Joe > > On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: > > There's been a suggestion that we make a stronger statement on support fo= r > the common (but not required) options like SACK, Timestamp, and Window > Scaling. > > Current text just indicates that these are recommended: > > Other Common Options > > Additional RFCs define some other commonly used options that are > recommended to implement. These are the TCP Selective > Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) > option [43], and TCP Window Scaling (WS) option [43]. > > I don't have any issues with appending a stronger statement something lik= e: > > TCP implementations SHOULD support these options. > > Would that suffice? Are there objections or other suggestions on what > exactly to say? > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros > oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s > data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D= 0 > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros > oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd > 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s > data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D= 0 > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.= com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DdnynNKcx27T2= aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000530ca305b6332cdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In my opinion, we already have an issue, because a non-nor= mative 'recommended' is used.=C2=A0 A reasonable reading is this wa= s intended as the normative RECOMMENDED, but no one ever bothered to capita= lize it, but it seems there's some disagreement on whether that was the= case.

If you're not going to make it normative, I&#= 39;d suggest you choose a different=C2=A0word than recommended or remove th= e last part of the sentence.

As stated before, I&#= 39;d suggest you capitalize it and make it normative.

On Fri, Dec 11, = 2020 at 12:17 AM Joseph Touch <t= ouch@strayalpha.com> wrote:
I agree that i= t=E2=80=99s useful to suggest them for high performance, but disagree with = adding a new SHOULD.

Again, we=E2=80=99re not here to op= en new issues - and more to the point, these were updated in 2014 and no SH= OULD was added at that time:

   Finally, we observe that most of the mechanisms defined in this
   document are important for LFNs and/or very high-speed networks.  For
   low-speed networks, it might be a performance optimization to NOT use
   these mechanisms.  A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low-speed paths, or allow a user or installation manager to disable
   them.

Joe

On Dec 10, 2020, at 8:32 PM, Neal Cardwell <ncardwell=3D40= google.com@dmarc.ietf.org> wrote:

To help address= the IOT case, along the lines of Joe's "conditions for
excepti= ons are indicated. I.e., SHOULD except where=E2=80=A6." remarks, oneoption would be to say that "These options are helpful for high
p= erformance and SHOULD be implemented except where resource
constraints m= ake this infeasible (e.g. constrained-node network
devices with CPU or m= emory limits)."

neal

On Thu, Dec 10, 2020 at 12:50 PM Pr= aveen Balasubramanian
<pravb=3D40microsoft.com@dmarc.ietf.org>= ; wrote:

IOT is a good point. Since this w= as part of my review comments I am convinced that we do not need to make th= ese a SHOULD requirement. MAY implement for performance will suffice.
-----Original Message-----
From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Y= uchung Cheng
Sent: Thursday, December 10, 2020 8:23 AM
To: Joseph Tou= ch <touch@stra= yalpha.com>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: [EXTERNAL] Re: [tcpm= ] 793bis: add SHOULD on other common options

I agree with Neal and I= an that these features are highly useful for TCP (performance). But I also = agree adding new SHOULD/MUST/MAY after the extensive WG reviews in the last= minute is not a good idea. If this new RFC is about the minimal requiremen= t to implement TCP correctly (but not necessarily performant in various net= works), then my vote is to keep as-is.


On Thu, Dec 10, 2020 at 8= :00 AM Joseph Touch <touch@strayalpha.com> wrote:
First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s see= how we can change TCP today=E2=80=9D.

That wasn=E2=80=99t the point= of this update.

Second, the doc (and all docs) should scrub all use= s of SHOULD to ensure that conditions for exceptions are indicated. I.e., S= HOULD except where=E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs = MAY or MUST) in a way that becomes merely an opening for the loudest advoca= tes, which doesn=E2=80=99t help anyone.

Finally, on this one in part= icular, NO.

Again, we aren=E2=80=99t opening the floodgates to recon= sidering TCP=E2=80=99s design. If the case hasn=E2=80=99t already been made= in a draft in detail, we should NOT be considering the change at this poin= t.

Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e.= , if you don=E2=80=99t implement them, you basically only hurt your own con= nections. So there=E2=80=99s already incentive for capable endpoints to imp= lement them.

Nevermind the fact that this would severely impact IOT = and other such uses, which I am surprised has not been considered.

J= oe

On Dec 9, 2020, at 7:44 PM, Wesley Eddy <wes@mti-systems.com> wrote:
<= br>There's been a suggestion that we make a stronger statement on suppo= rt for the common (but not required) options like SACK, Timestamp, and Wind= ow Scaling.

Current text just indicates that these are recommended:<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Other Common Options
<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Additional RFCs define some o= ther commonly used options that are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0recommended to implement.=C2=A0 These are the TCP Selective
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Acknowledgement (SACK) option [18= ][21], TCP Timestamp (TS)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0opt= ion [43], and TCP Window Scaling (WS) option [43].

I don't have = any issues with appending a stronger statement something like:

TCP i= mplementations SHOULD support these options.

Would that suffice?=C2= =A0 Are there objections or other suggestions on what exactly to say?

_______________________________________________
tcpm mailing list<= br>tcpm@ietf.org
= https://nam06.safelinks.protection.outlook.com/?= url=3Dhttps%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpravb%= 40micros
oft.com%7C90bd= 7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
011db47%7C1%7C0= %7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
data=3DdnynNK= cx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=3D0

_______________________________________________
tcpm mailing list
<= a href=3D"mailto:tcpm@ietf.org" target=3D"_blank">tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.
= ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpravb%40m= icros
oft.com%7C90bd709= 8c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
011db47%7C1%7C0%7C= 637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJQIjoi= V2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
data=3DdnynNKcx2= 7T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=3D0

_______________________________________________
tcpm mailing lis= t
tcpm@ietf.orghttps://nam06.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04= %7C01%7Cpravb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf= 86f141af91ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb= 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&amp;sdata=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&am= p;reserved=3D0
_______________________________________________
tc= pm mailing list
tcpm@= ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list<= br>tcpm@ietf.org
= ht= tps://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000530ca305b6332cdf-- From nobody Fri Dec 11 09:52:10 2020 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 6532F3A0D81 for ; Fri, 11 Dec 2020 09:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Jv-Hjc4CBsWw for ; Fri, 11 Dec 2020 09:51:58 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 1CBB33A0D79 for ; Fri, 11 Dec 2020 09:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ebmcbzg5TjLaJO19jNX6y3GY2jpuJNmAWYxwKHgbLHM=; b=3tRujLSDp676Jv/lY5LWmy0N7 EwIx9ZlOx/dbpa/sWydGSi/GuINBNhdpkMjOsR+OOZn9O9zESbOWhZU/XwoysuumUoj48jJfVT37R 2S9Z6zgWz6wd30EQ8IJ8efWAKMFDiOKaoQM8GsmfTZT9IG6QkvTsHs3CuDn0+A9RkezDh3m9cZLMl afFD2NRzDLGwOFMlBUOYrKvIO2PMY0GjZ57ZJIzZNTglUPT2FmUHmWFRLehBXi5aiXTGo+o5tD7kc v0usdwOVCF4c89nTcjUOor1J4VEQ5qI8TtNK69zExspIePH+n1q1qC5hwK6unk0ciQtkof7aWzBlI RY5a8cR1g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:65035 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1knma7-0021Vw-Rm; Fri, 11 Dec 2020 12:51:57 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_8BE5EB23-7C3E-4D48-9FD6-903A039E8153" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Fri, 11 Dec 2020 09:51:50 -0800 Cc: Praveen Balasubramanian , Neal Cardwell , "ycheng=40google.com@dmarc.ietf.org" , "tcpm@ietf.org" Message-Id: <68B1C03F-71F6-4854-B0F8-AE9D4121E9E2@strayalpha.com> References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> To: Ian Swett X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:52:09 -0000 --Apple-Mail=_8BE5EB23-7C3E-4D48-9FD6-903A039E8153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 11, 2020, at 8:56 AM, Ian Swett = wrote: >=20 > In my opinion, we already have an issue, because a non-normative = 'recommended' is used. A reasonable reading is this was intended as the = normative RECOMMENDED, but no one ever bothered to capitalize it, but it = seems there's some disagreement on whether that was the case. Except that this RFC actually already includes the following *explicit* = language: In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119 = ] significance. > If you're not going to make it normative, I'd suggest you choose a = different word than recommended or remove the last part of the sentence. Absolutely. > As stated before, I'd suggest you capitalize it and make it normative. Again, no, as per above. Joe >=20 > On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch > wrote: > I agree that it=E2=80=99s useful to suggest them for high performance, = but disagree with adding a new SHOULD. >=20 > Again, we=E2=80=99re not here to open new issues - and more to the = point, these were updated in 2014 and no SHOULD was added at that time: >=20 > Finally, we observe that most of the mechanisms defined in this > document are important for LFNs and/or very high-speed networks. = For > low-speed networks, it might be a performance optimization to NOT = use > these mechanisms. A TCP vendor concerned about optimal performance > over low-speed paths might consider turning these extensions off = for > low-speed paths, or allow a user or installation manager to disable > them. >=20 > Joe >=20 >> On Dec 10, 2020, at 8:32 PM, Neal Cardwell = > wrote: >>=20 >> To help address the IOT case, along the lines of Joe's "conditions = for >> exceptions are indicated. I.e., SHOULD except where=E2=80=A6." = remarks, one >> option would be to say that "These options are helpful for high >> performance and SHOULD be implemented except where resource >> constraints make this infeasible (e.g. constrained-node network >> devices with CPU or memory limits)." >>=20 >> neal >>=20 >> On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian >> > wrote: >>>=20 >>> IOT is a good point. Since this was part of my review comments I am = convinced that we do not need to make these a SHOULD requirement. MAY = implement for performance will suffice. >>>=20 >>> -----Original Message----- >>> From: tcpm > On = Behalf Of Yuchung Cheng >>> Sent: Thursday, December 10, 2020 8:23 AM >>> To: Joseph Touch > >>> Cc: tcpm IETF list > >>> Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common = options >>>=20 >>> I agree with Neal and Ian that these features are highly useful for = TCP (performance). But I also agree adding new SHOULD/MUST/MAY after the = extensive WG reviews in the last minute is not a good idea. If this new = RFC is about the minimal requirement to implement TCP correctly (but not = necessarily performant in various networks), then my vote is to keep = as-is. >>>=20 >>>=20 >>> On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch > wrote: >>>>=20 >>>> First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99= s see how we can change TCP today=E2=80=9D. >>>>=20 >>>> That wasn=E2=80=99t the point of this update. >>>>=20 >>>> Second, the doc (and all docs) should scrub all uses of SHOULD to = ensure that conditions for exceptions are indicated. I.e., SHOULD except = where=E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs MAY or = MUST) in a way that becomes merely an opening for the loudest advocates, = which doesn=E2=80=99t help anyone. >>>>=20 >>>> Finally, on this one in particular, NO. >>>>=20 >>>> Again, we aren=E2=80=99t opening the floodgates to reconsidering = TCP=E2=80=99s design. If the case hasn=E2=80=99t already been made in a = draft in detail, we should NOT be considering the change at this point. >>>>=20 >>>> Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., = if you don=E2=80=99t implement them, you basically only hurt your own = connections. So there=E2=80=99s already incentive for capable endpoints = to implement them. >>>>=20 >>>> Nevermind the fact that this would severely impact IOT and other = such uses, which I am surprised has not been considered. >>>>=20 >>>> Joe >>>>=20 >>>> On Dec 9, 2020, at 7:44 PM, Wesley Eddy > wrote: >>>>=20 >>>> There's been a suggestion that we make a stronger statement on = support for the common (but not required) options like SACK, Timestamp, = and Window Scaling. >>>>=20 >>>> Current text just indicates that these are recommended: >>>>=20 >>>> Other Common Options >>>>=20 >>>> Additional RFCs define some other commonly used options that = are >>>> recommended to implement. These are the TCP Selective >>>> Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) >>>> option [43], and TCP Window Scaling (WS) option [43]. >>>>=20 >>>> I don't have any issues with appending a stronger statement = something like: >>>>=20 >>>> TCP implementations SHOULD support these options. >>>>=20 >>>> Would that suffice? Are there objections or other suggestions on = what exactly to say? >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww = .= >>>> ietf.org = %2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%= 40micros >>>> oft.com = %7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91a= b2d7cd >>>> = 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >>>> = C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >>>> = data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0= >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww = .= >>>> ietf.org = %2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%= 40micros >>>> oft.com = %7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91a= b2d7cd >>>> = 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >>>> = C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >>>> = data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0= >>>=20 >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> = https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft.= com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL= CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DdnynNKcx2= 7T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0 = >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm = >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_8BE5EB23-7C3E-4D48-9FD6-903A039E8153 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 11, 2020, at 8:56 AM, Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> = wrote:

In my opinion, we already have an issue, because = a non-normative 'recommended' is used.  A reasonable reading is = this was intended as the normative RECOMMENDED, but no one ever bothered = to capitalize it, but it seems there's some disagreement on whether that = was the case.

Except that this RFC actually already includes the = following *explicit* language:

   In this document, these =
words will appear with that interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

If you're not = going to make it normative, I'd suggest you choose a different word = than recommended or remove the last part of the = sentence.

Absolutely.

As stated before, I'd suggest you capitalize it and make it = normative.

Again, = no, as per above.

Joe


On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch = <touch@strayalpha.com> wrote:
I agree that it=E2=80=99s useful to suggest them = for high performance, but disagree with adding a new SHOULD.

Again, we=E2=80=99re not = here to open new issues - and more to the point, these were updated in = 2014 and no SHOULD was added at that time:

   =
Finally, we observe that most of the mechanisms defined in this
   document are important for LFNs and/or very high-speed networks.  For
   low-speed networks, it might be a performance optimization to NOT use
   these mechanisms.  A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low-speed paths, or allow a user or installation manager to disable
   them.

Joe

On Dec 10, 2020, at 8:32 PM, = Neal Cardwell <ncardwell=3D40google.com@dmarc.ietf.org> = wrote:

To help = address the IOT case, along the lines of Joe's "conditions for
exceptions are indicated. I.e., SHOULD except where=E2=80=A6." = remarks, one
option would be to say that "These options = are helpful for high
performance and SHOULD be implemented = except where resource
constraints make this infeasible = (e.g. constrained-node network
devices with CPU or memory = limits)."

neal

On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian
<pravb=3D40microsoft.com@dmarc.ietf.org>= ; wrote:

IOT is a good point. Since this was part of my review = comments I am convinced that we do not need to make these a SHOULD = requirement. MAY implement for performance will suffice.
-----Original Message-----
From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
Sent: Thursday, December 10, 2020 8:23 AM
To: = Joseph Touch <touch@strayalpha.com>
Cc: tcpm IETF = list <tcpm@ietf.org>
Subject: [EXTERNAL] Re: = [tcpm] 793bis: add SHOULD on other common options

I agree with Neal and Ian that these features are highly = useful for TCP (performance). But I also agree adding new = SHOULD/MUST/MAY after the extensive WG reviews in the last minute is not = a good idea. If this new RFC is about the minimal requirement to = implement TCP correctly (but not necessarily performant in various = networks), then my vote is to keep as-is.

On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch <touch@strayalpha.com> wrote:

First, can we please NOT open = the floodgates to =E2=80=9Clet=E2=80=99s see how we can change TCP = today=E2=80=9D.

That wasn=E2=80=99t the = point of this update.

Second, the doc (and = all docs) should scrub all uses of SHOULD to ensure that conditions for = exceptions are indicated. I.e., SHOULD except where=E2=80=A6. Otherwise, = we=E2=80=99re tilting the odds (vs MAY or MUST) in a way that becomes = merely an opening for the loudest advocates, which doesn=E2=80=99t help = anyone.

Finally, on this one in particular, = NO.

Again, we aren=E2=80=99t opening the = floodgates to reconsidering TCP=E2=80=99s design. If the case hasn=E2=80=99= t already been made in a draft in detail, we should NOT be considering = the change at this point.

Further, these = only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if you don=E2=80=99t = implement them, you basically only hurt your own connections. So = there=E2=80=99s already incentive for capable endpoints to implement = them.

Nevermind the fact that this would = severely impact IOT and other such uses, which I am surprised has not = been considered.

Joe

On Dec 9, 2020, at 7:44 PM, Wesley Eddy <wes@mti-systems.com> wrote:

There's been a suggestion that we make a stronger statement = on support for the common (but not required) options like SACK, = Timestamp, and Window Scaling.

Current text = just indicates that these are recommended:

=        Other Common Options

=        Additional RFCs define some = other commonly used options that are
=        recommended to = implement.  These are the TCP Selective
=        Acknowledgement (SACK) option = [18][21], TCP Timestamp (TS)
=        option [43], and TCP Window = Scaling (WS) option [43].

I don't have any = issues with appending a stronger statement something like:

TCP implementations SHOULD support these = options.

Would that suffice?  Are = there objections or other suggestions on what exactly to say?


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01= %7Cpravb%40micros
oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141= af91ab2d7cd
011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&amp;s
data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&a= mp;reserved=3D0


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01= %7Cpravb%40micros
oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141= af91ab2d7cd
011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8ey= JWIjoiM
C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300= 0&amp;s
data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&a= mp;reserved=3D0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpra= vb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91= ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIj= oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&am= p;sdata=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reser= ved=3D0
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm = mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_8BE5EB23-7C3E-4D48-9FD6-903A039E8153-- From nobody Fri Dec 11 11:25:25 2020 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 88CCD3A0E76 for ; Fri, 11 Dec 2020 11:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 dyNBHmtN7hLG for ; Fri, 11 Dec 2020 11:25:21 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 5DF6E3A0E71 for ; Fri, 11 Dec 2020 11:25:21 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id 82so2106219yby.6 for ; Fri, 11 Dec 2020 11:25:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j5Uiu6qsMjYCTYDzgon1O3EmPQNkbVuzyKSeHtKgp2c=; b=OuRHSs6FDj7k41ieaqwMiQyRFDwZJKBmHP1qGTLzKuA0dRaGnHUfUm4Qo06bfctHxw D8Lg/WDKTncpwk+0w8x0DztpIWwXvZIkRqa2cZGBX7JPc8LB8xHpi93LdaUO4RaXfIx+ QRmESNvefLo9D1hjOjBBkhIg429Zy4zPlRzEm5iKDF6LFB/fvBCCT0qFHrDiIKGLytT9 13mWq4R8BRTqMMJWXpkGV3VIrs2+FJsNqW3wv11bj0cODmLHoESP4hLsFzhHhOoOwBbV ZIdfGMugiSoPdIIt4oQh2hYLZ1EQ0E71E4Tj3azD9CmNN21YA+twQTlkuIcpjcEG62Tx 6hFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j5Uiu6qsMjYCTYDzgon1O3EmPQNkbVuzyKSeHtKgp2c=; b=MY/B0dGtHNdH2lVnIelSEhNv9+WdoBIkHwe7W5/bgU1q06MKQT5a5+0vaGPHS1ND2+ t2Qwf3GTfoki2aXAqlW67cGH83ohGu4ggNzCPx3xj+Ed9kjBykAsDKA/7Z76zwLY7nb4 bycqSPqs5d8YCMeK9Rvapw24p6NAhlB1ry84tHw/kE4IL3FNr9/PeCDMpbPf3j0yZJl0 gJonZ4VIqo3ZFoR8u779IdhJc6vLyiuGPQFcb6Hg9YihffbePTJB6wi2NIyrBnMwZhAi Ihr0Dw3KATnk9UrKxMxBg0xKJf2hoASEC1J2woBN+iWToGsVMoX0x15EosJR3hMvIT+s Hglg== X-Gm-Message-State: AOAM532Hu9MhE6cYepfrBO/FfiFgPM3oxCflQu6iQ49DKTx7G5QzkzPW B1yS9gluWXA2INqTm1arK+NgspY/rGuPBRQyhLHIEA== X-Google-Smtp-Source: ABdhPJyxHnIxAEJE8R7Xzb/Yvu2IMXQzdWxK8LWSDExsgLULcD6H6obwBkkOV8Vxp3FXtCEEqUhV2zZS11r/MVZzOUQ= X-Received: by 2002:a25:4f83:: with SMTP id d125mr22856675ybb.388.1607714720252; Fri, 11 Dec 2020 11:25:20 -0800 (PST) MIME-Version: 1.0 References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> <68B1C03F-71F6-4854-B0F8-AE9D4121E9E2@strayalpha.com> In-Reply-To: <68B1C03F-71F6-4854-B0F8-AE9D4121E9E2@strayalpha.com> From: Ian Swett Date: Fri, 11 Dec 2020 14:25:09 -0500 Message-ID: To: Joseph Touch Cc: Praveen Balasubramanian , Neal Cardwell , "ycheng=40google.com@dmarc.ietf.org" , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cd8a9505b6354086" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 19:25:25 -0000 --000000000000cd8a9505b6354086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch wrote: > > > On Dec 11, 2020, at 8:56 AM, Ian Swett < > ianswett=3D40google.com@dmarc.ietf.org> wrote: > > In my opinion, we already have an issue, because a non-normative > 'recommended' is used. A reasonable reading is this was intended as the > normative RECOMMENDED, but no one ever bothered to capitalize it, but it > seems there's some disagreement on whether that was the case. > > > Except that this RFC actually already includes the following *explicit* > language: > > In this document, these words will appear with that interpretation > only when in UPPER CASE. Lower case uses of these words are not to > be interpreted as carrying [RFC2119 ] significance. > > Ok, well that's unusual. > > If you're not going to make it normative, I'd suggest you choose a > different word than recommended or remove the last part of the sentence. > > > Absolutely. > > As stated before, I'd suggest you capitalize it and make it normative. > > > Again, no, as per above. > Fair > > Joe > > > On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch > wrote: > >> I agree that it=E2=80=99s useful to suggest them for high performance, b= ut >> disagree with adding a new SHOULD. >> >> Again, we=E2=80=99re not here to open new issues - and more to the point= , these >> were updated in 2014 and no SHOULD was added at that time: >> >> Finally, we observe that most of the mechanisms defined in this >> document are important for LFNs and/or very high-speed networks. For >> low-speed networks, it might be a performance optimization to NOT use >> these mechanisms. A TCP vendor concerned about optimal performance >> over low-speed paths might consider turning these extensions off for >> low-speed paths, or allow a user or installation manager to disable >> them. >> >> >> Joe >> >> On Dec 10, 2020, at 8:32 PM, Neal Cardwell < >> ncardwell=3D40google.com@dmarc.ietf.org> wrote: >> >> To help address the IOT case, along the lines of Joe's "conditions for >> exceptions are indicated. I.e., SHOULD except where=E2=80=A6." remarks, = one >> option would be to say that "These options are helpful for high >> performance and SHOULD be implemented except where resource >> constraints make this infeasible (e.g. constrained-node network >> devices with CPU or memory limits)." >> >> neal >> >> On Thu, Dec 10, 2020 at 12:50 PM Praveen Balasubramanian >> wrote: >> >> >> IOT is a good point. Since this was part of my review comments I am >> convinced that we do not need to make these a SHOULD requirement. MAY >> implement for performance will suffice. >> >> -----Original Message----- >> From: tcpm On Behalf Of Yuchung Cheng >> Sent: Thursday, December 10, 2020 8:23 AM >> To: Joseph Touch >> Cc: tcpm IETF list >> Subject: [EXTERNAL] Re: [tcpm] 793bis: add SHOULD on other common option= s >> >> I agree with Neal and Ian that these features are highly useful for TCP >> (performance). But I also agree adding new SHOULD/MUST/MAY after the >> extensive WG reviews in the last minute is not a good idea. If this new = RFC >> is about the minimal requirement to implement TCP correctly (but not >> necessarily performant in various networks), then my vote is to keep as-= is. >> >> >> On Thu, Dec 10, 2020 at 8:00 AM Joseph Touch >> wrote: >> >> >> First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s s= ee how we can >> change TCP today=E2=80=9D. >> >> That wasn=E2=80=99t the point of this update. >> >> Second, the doc (and all docs) should scrub all uses of SHOULD to ensure >> that conditions for exceptions are indicated. I.e., SHOULD except where= =E2=80=A6. >> Otherwise, we=E2=80=99re tilting the odds (vs MAY or MUST) in a way that= becomes >> merely an opening for the loudest advocates, which doesn=E2=80=99t help = anyone. >> >> Finally, on this one in particular, NO. >> >> Again, we aren=E2=80=99t opening the floodgates to reconsidering TCP=E2= =80=99s design. If >> the case hasn=E2=80=99t already been made in a draft in detail, we shoul= d NOT be >> considering the change at this point. >> >> Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e., if yo= u don=E2=80=99t implement >> them, you basically only hurt your own connections. So there=E2=80=99s a= lready >> incentive for capable endpoints to implement them. >> >> Nevermind the fact that this would severely impact IOT and other such >> uses, which I am surprised has not been considered. >> >> Joe >> >> On Dec 9, 2020, at 7:44 PM, Wesley Eddy wrote: >> >> There's been a suggestion that we make a stronger statement on support >> for the common (but not required) options like SACK, Timestamp, and Wind= ow >> Scaling. >> >> Current text just indicates that these are recommended: >> >> Other Common Options >> >> Additional RFCs define some other commonly used options that are >> recommended to implement. These are the TCP Selective >> Acknowledgement (SACK) option [18][21], TCP Timestamp (TS) >> option [43], and TCP Window Scaling (WS) option [43]. >> >> I don't have any issues with appending a stronger statement something >> like: >> >> TCP implementations SHOULD support these options. >> >> Would that suffice? Are there objections or other suggestions on what >> exactly to say? >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros >> oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd >> 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >> data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved= =3D0 >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40micros >> oft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd >> 011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s >> data=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved= =3D0 >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> >> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D04%7C01%7Cpravb%40microsoft= .com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd011db47%= 7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC= JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3DdnynNKcx27T= 2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&reserved=3D0 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > > --000000000000cd8a9505b6354086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Dec 11, 2020 at 12:52 PM Jose= ph Touch <touch@strayalpha.com> wrote:



In my opinio= n, we already have an issue, because a non-normative 'recommended' = is used.=C2=A0 A reasonable reading is this was intended as the normative R= ECOMMENDED, but no one ever bothered to capitalize it, but it seems there&#= 39;s some disagreement on whether that was the case.

Except that this RFC actually already includes the fo= llowing *explicit* language:

   In this=
 document, these words will appear with that interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

Ok, well that's unusual.
= =C2=A0

If you're not going to make it no= rmative, I'd suggest you choose a different=C2=A0word than recommended = or remove the last part of the sentence.

Absolutely.

As stated before, I'd suggest you capitalize it and make= it normative.

Again, no, as p= er above.

Fair=C2=A0

Joe


= On Fri, Dec 11, 2020 at 12:17 AM Joseph Touch <touch@strayalpha.com> wrote:
I agree that it= =E2=80=99s useful to suggest them for high performance, but disagree with a= dding a new SHOULD.

Again, we=E2=80=99re not here to ope= n new issues - and more to the point, these were updated in 2014 and no SHO= ULD was added at that time:

   Finally,=
 we observe that most of the mechanisms defined in this
   document are important for LFNs and/or very high-speed networks.  For
   low-speed networks, it might be a performance optimization to NOT use
   these mechanisms.  A TCP vendor concerned about optimal performance
   over low-speed paths might consider turning these extensions off for
   low-speed paths, or allow a user or installation manager to disable
   them.

Joe

On Dec 10, 2020, at 8:32 PM, Neal Cardwell <ncardwell=3D40= google.com@dmarc.ietf.org> wrote:

To help address= the IOT case, along the lines of Joe's "conditions for
excepti= ons are indicated. I.e., SHOULD except where=E2=80=A6." remarks, oneoption would be to say that "These options are helpful for high
p= erformance and SHOULD be implemented except where resource
constraints m= ake this infeasible (e.g. constrained-node network
devices with CPU or m= emory limits)."

neal

On Thu, Dec 10, 2020 at 12:50 PM Pr= aveen Balasubramanian
<pravb=3D40microsoft.com@dmarc.ietf.org>= ; wrote:

IOT is a good point. Since this w= as part of my review comments I am convinced that we do not need to make th= ese a SHOULD requirement. MAY implement for performance will suffice.
-----Original Message-----
From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Y= uchung Cheng
Sent: Thursday, December 10, 2020 8:23 AM
To: Joseph Tou= ch <touch@stra= yalpha.com>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: [EXTERNAL] Re: [tcpm= ] 793bis: add SHOULD on other common options

I agree with Neal and I= an that these features are highly useful for TCP (performance). But I also = agree adding new SHOULD/MUST/MAY after the extensive WG reviews in the last= minute is not a good idea. If this new RFC is about the minimal requiremen= t to implement TCP correctly (but not necessarily performant in various net= works), then my vote is to keep as-is.


On Thu, Dec 10, 2020 at 8= :00 AM Joseph Touch <touch@strayalpha.com> wrote:
First, can we please NOT open the floodgates to =E2=80=9Clet=E2=80=99s see= how we can change TCP today=E2=80=9D.

That wasn=E2=80=99t the point= of this update.

Second, the doc (and all docs) should scrub all use= s of SHOULD to ensure that conditions for exceptions are indicated. I.e., S= HOULD except where=E2=80=A6. Otherwise, we=E2=80=99re tilting the odds (vs = MAY or MUST) in a way that becomes merely an opening for the loudest advoca= tes, which doesn=E2=80=99t help anyone.

Finally, on this one in part= icular, NO.

Again, we aren=E2=80=99t opening the floodgates to recon= sidering TCP=E2=80=99s design. If the case hasn=E2=80=99t already been made= in a draft in detail, we should NOT be considering the change at this poin= t.

Further, these only =E2=80=9Cshoot you in the foot=E2=80=9D, i.e.= , if you don=E2=80=99t implement them, you basically only hurt your own con= nections. So there=E2=80=99s already incentive for capable endpoints to imp= lement them.

Nevermind the fact that this would severely impact IOT = and other such uses, which I am surprised has not been considered.

J= oe

On Dec 9, 2020, at 7:44 PM, Wesley Eddy <wes@mti-systems.com> wrote:
<= br>There's been a suggestion that we make a stronger statement on suppo= rt for the common (but not required) options like SACK, Timestamp, and Wind= ow Scaling.

Current text just indicates that these are recommended:<= br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Other Common Options
<= br> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Additional RFCs define some o= ther commonly used options that are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0recommended to implement.=C2=A0 These are the TCP Selective
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Acknowledgement (SACK) option [18= ][21], TCP Timestamp (TS)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0opt= ion [43], and TCP Window Scaling (WS) option [43].

I don't have = any issues with appending a stronger statement something like:

TCP i= mplementations SHOULD support these options.

Would that suffice?=C2= =A0 Are there objections or other suggestions on what exactly to say?

_______________________________________________
tcpm mailing list<= br>tcpm@ietf.org
= https://nam06.safelinks.protection.outlook.com/?= url=3Dhttps%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpravb= %40micros
oft.com%7C90= bd7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
011db47%7C1%7= C0%7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJ= QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
data=3Ddnyn= NKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=3D0

=
_______________________________________________
tcpm mailing listtcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?ur= l=3Dhttps%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D04%7C01%7Cpravb%4= 0micros
oft.com%7C90bd= 7098c8f147f7bcaf08d89d280028%7C72f988bf86f141af91ab2d7cd
011db47%7C1%7C0= %7C637432142423474171%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
C4wLjAwMDAiLCJQI= joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
data=3DdnynNK= cx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&amp;reserved=3D0

_______________________________________________
tcpm mailing = list
tcpm@ietf.org
https://nam06.safelinks.protection.outlook.com/?u= rl=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D= 04%7C01%7Cpravb%40microsoft.com%7C90bd7098c8f147f7bcaf08d89d280028%7C72f988= bf86f141af91ab2d7cd011db47%7C1%7C0%7C637432142423474171%7CUnknown%7CTWFpbGZ= sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3= 000&amp;sdata=3DdnynNKcx27T2aZNF%2FvJqJq9WuMyMmLpc%2FnLnoI9az2Y%3D&= amp;reserved=3D0
_______________________________________________
= tcpm mailing list
tcp= m@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing lis= t
tcpm@ietf.org= https://www.ietf.org/mailman/listinfo/tcpm
=

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://= www.ietf.org/mailman/listinfo/tcpm

--000000000000cd8a9505b6354086-- From nobody Fri Dec 11 14:08:45 2020 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 0319D3A102E for ; Fri, 11 Dec 2020 14:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 CnwgBsCuYm4h for ; Fri, 11 Dec 2020 14:08:31 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 8240F3A101A for ; Fri, 11 Dec 2020 14:08:31 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id x16so14403017ejj.7 for ; Fri, 11 Dec 2020 14:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T8Qz6UYHdmp1N/q4o/fbNv51HIeDhQSxlcBkq7tSLxc=; b=Hy2xmGcnoPufS3AINLCNp5tdnuvvHTPEkeUJnV62fgaxWm4btp72KrS6STSmYPc7U3 ne+S8zIkFx3fL+/qZBIqRRsxhnwntYfXoQVm/Zvsm3kR/pOWFqUTK2/Aa+dHWpR7p2hK FD3ZB1CEjwmwCE42207r3hKv0WcTwf2NzNs0BWKuD+ZYUUWY0SW+WIkZR0qrgdmY25aW lEFB5xq2OQFCGCDGu7ZqPw9NviIKgvPQnWRMZwiBsSwwwqjd49rKxBqVbfui9CZoLIhS WhA+aN8KmqY7Zi7iKyFsHLhVmL8XlV0eMf2xNncKtZhXorWGeZy0iDM6Yd+EsEh2A2E6 oXuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T8Qz6UYHdmp1N/q4o/fbNv51HIeDhQSxlcBkq7tSLxc=; b=rhJEJYazc/VanGrRil1aSIIjkGOQ97izJFePqJ1Z+Mv0SIR7VvD654xOv5tvloVy57 eLm7cqhn/WcMzMAhQaG3oefbL5d88XYOD807t7JHpsyQVm+Rao9YRiRBFTMwHQ2kQ8yY 6SDs4ZDgJ2CNisqt+t4nyzn3VD4zEEQERgfKQID0pqgwQpPDKP2EpFBJN/wxoh4vEpVJ fZcH8XbjopKmRITbwpxzoDBQu8t22tkPQaRvW1u1saf089sPrFGkPjhbnN+0CL3alTt6 m1MUNhG8nwNm4k4Wqzue49Y+MXl70QMqunFhMjMmYAnbTEIBP765MssK1+KDAOFarqWG wU9g== X-Gm-Message-State: AOAM532ZtWAQpN9DL9kFc90CKrKJPekDGkw9Xr1FjMSDVm4m5JEZGu+C DMmuc7J3wr57uJjQug4OCJbSzxciv3sR9lpEkW2Z6w== X-Google-Smtp-Source: ABdhPJzWDHBnxdPIO/DkOhgtkfLD8h7EvroHinTEf0oAFf0Exl2rZzCLaFX3jwXH+vxBFNtOACfEqEs702MeNpst4OM= X-Received: by 2002:a17:906:fa12:: with SMTP id lo18mr13163395ejb.354.1607724509414; Fri, 11 Dec 2020 14:08:29 -0800 (PST) MIME-Version: 1.0 References: <160435977209.20839.4083263519198538783@ietfa.amsl.com> <8b5b8012-0914-c833-6390-0e98a97074ad@gmx.at> In-Reply-To: <8b5b8012-0914-c833-6390-0e98a97074ad@gmx.at> From: Kevin Yang Date: Fri, 11 Dec 2020 17:08:18 -0500 Message-ID: To: "Scheffenegger, Richard" Cc: Yuchung Cheng , "tcpm@ietf.org Extensions" , Eric Dumazet , iccrg IRTF list , Neal Cardwell Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-yang-tcpm-ets-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 22:08:40 -0000 Thank you Richard, To make less confusion, the new proposed ETSopt is targeting a different option kind, i.e. not reusing RFC7323 TSopt, so please allow me to use ETSval and ETSecr to refer to the timestamps in ETS option. For saving more space in and by reusing the ETSecr, I generally like this idea about XOR ETSecr with other fields. But considered the complexity it adds to the protocol and implementation, I'm on the fence and waiting for more inputs from others. To help others understand the problem, I summarize it in the following: The idea is to XOR ETSecr with EcrDel and MaxACKDel fields in and to save the 32 bits space used by EcrDel. The ETSecr is all-zero in , so we can XOR them to save 32 bits without problem. But to XOR ETSecr with the other fields in , we need to prevent mis-paired with retransmitted s. One way to solve the problem is to: 1. In , make S (e.g. S=3) bits of either in EcrDel or MaxACKDel to be 0, sacrifice a little accuracy, e.g. roundup to neaest multiple of 8. 2. Need to rearrange the position of EcrDel or MaxACKDel so that those S bits coincide with the least significant of ETSecr. So the S bits of ETSecr remain the same in . 3. In and retransmitted , the sender makes each retransmitted have ETSval's last S bits that are different from before. 4. When the sender receives the , it knows which to pair using the last S bit of ETSecr. About the 2^10 nanosecond unit, I'm thinking that might not make it easier for computation EcrDel = LatestACKDel + TSecrAge (page 7), since both component are not directly compute from nanosecond: TSecrAge is the difference of two TS clock (in microsecond), LatestACKDel can be computed from tp->tcp_mstamp in Linux which is also in microsecond. So if EcrDel can be represented in microsecond, there should be no div operation needed. Also, it is more natural to keep EcrDel with the same microsecond(10^3 nanosecond) format as ETSval and ETSecr. Best, Kevin On Tue, Nov 24, 2020 at 8:22 AM Scheffenegger, Richard wrote: > > > > Am 23.11.2020 um 02:47 schrieb Kevin Yang: > >> The high level approach there was to use the unused TSecr field (should > >> be 0 for 7323/1323), and overlay (xor) in the SYN/ACK's TSopt ecr field > >> the client's TSopt val with the servers 32-bit negotiation field... As > >> the client can retain knowledge of the initial TSopt value (there should > >> be a randomized initial value), the client can extract the server side > >> options by xor'ing it's known initial value when the SYN/ACK is > >> received. Or fall back to default 7323 operation, if the result of the > >> XOR is zero... > >> > > > > I agree that the TSecr in might be used for other purposes. But I'm > > not sure if we can alter the TSecr in by XOR other info. > > One specific example I came up with is that a sender may send out many > > SYNs because of timeout, > > then when it receives a , it does not know which TSval should > > be used for xor op. > > (E)TS opt is not necessarily the old differentiation between subsequent > SYN packets; extending some reserved bits (during the SYN handshake) may > be another easy way to have sufficient differentiation available. > > E.g. The EcrDel value may be restricted to no less than 4 or 8 usec (any > lower value rounded up), yielding sufficient bits which would expected > to be zero in the SYN,ACK; The TSval offset can then be selected by the > sender in such a way, to change at these locations for each > retransmission of the SYN, allowing the sender to disambiguate which SYN > a particular SYN,ACK pairs up with... > > > > >> It could be used almost as a drop-in use of timestamp-negotiation, as > >> long as it can be guaranteed, that at least one bit is set in the 32bit > >> field (e.g. setting the reserved bit to 1). > > > > In this way we need to add another "ETSval'' in usec if we use the > > RFC7323/1323 TSopt, > > the reason is explained above. > > As long as some more coarse time resolution is acceptable during the > (special case handling) 3WHS, all you need is a few bits to disambiguate > retransmitted SYN packets. We did spent some thought on the > retransmitted SYN problem during the TS-nego design phase. A single > reserved bit is not sufficient, though; > > > > >> EcrDelUnit: I think the codepoint assignment could be improved (but this > >> is really nit-picking; just that a broken implementation may send out > >> TSopt with len=12, but initialized-to-zero superflous bytes... > >> 0: invalid > >> 1: milliseconds [2^20 nanoseconds?] > >> 2: microseconds [2^10 nanoseconds?] > >> 3: reserved (nanoseconds) > > > > Thanks for the nice suggestion. I agree we probably should have > > all-zero codepoint to be > > "no information". For 2^k nanosec unit, I guess that is for bit-op > > convenience and performance? > > Yes, simple binary shift operations instead of multiply/divide, and > internally representing timestamp values in nanoseconds > (timespec/tv_nsec). The error when using timeval/tv_usec may even be > small enough to not matter in many environments (eg. simply use a > "microsecond 2^10" value directly, without adjusting for the 2.4% error, > as you are interested in deltas on short timescales, not across long > timespans? From nobody Fri Dec 11 14:26:05 2020 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 2F36C3A1026 for ; Fri, 11 Dec 2020 14:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 4qk3OZFSBtRj for ; Fri, 11 Dec 2020 14:25:51 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EBD3A0FD3 for ; Fri, 11 Dec 2020 14:25:50 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sat, 12 Dec 2020 00:25:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=qUbjaF wBZwZrQdhznwjxlmfqZlbtrXgFbCe62TnuLZU=; b=NAm8iC70zAkIVLc7KuyOvn R0VB1OYb+UnvmQtjRdMSs4DgB1l5lHQe5gxGbTO5B5twc+dMB82V6PrTj/OkwRyV D6ow5UKlBb3PyLUcJN9VCxFLEQNWAoavrsg7HPXHbAgR1tKv9eVpydULcIKPSUZQ UgeCGWMdeZnxZ1Q2Gaesg= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Sat, 12 Dec 2020 00:25:37 +0200 id 00000000005A01BC.000000005FD3F1E1.00005851 Date: Sat, 12 Dec 2020 00:25:37 +0200 (EET) From: Markku Kojo To: Joseph Touch cc: Jonathan Morton , "tcpm@ietf.org Extensions" , Christian Huitema In-Reply-To: Message-ID: References: <633700D0-20DF-43C8-9450-2E360FEA2933@strayalpha.com> <829add9b-3894-fdec-ecd4-38e374a4b2be@huitema.net> <0F5CB40A-39F8-499F-BADF-90FBAE2D1988@strayalpha.com> <02d957de-00cb-f8d3-10ce-77ba180fc939@huitema.net> <730CCF47-4800-4F60-9D2A-98ADE7E0FB85@strayalpha.com> <00271035-1B91-4848-B9D7-FBA2F287782B@gmail.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-22636-1607725537-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] [EXTERNAL] 793bis wording on congestion control X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 22:26:04 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-22636-1607725537-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi, I believe all necessary wording on what is required from alternative=20 TCP congestion control algorithms and "TCP friendliness" is in the=20 existing BCPs: RFC 2914, RFC 5033, and RFC 4774. RFC 2914 and 4774 use=20 terms such as "conformant congestion control", "conformant TCP", and=20 "TCP-compatible". RFC 5033 uses term "TCP-friendly". I'd suggest using minimal text on "TCP friendlyness" and citing RFC 2914,=20 RFC 5033 (and possibly RFC 4774) for this matter. What the current text and all proposed texts misses is exponential=20 back-off of RTO. MUST in RFC 1122. If it is not included in RFC973bis=20 it is easy to miss by an implementer who is not that familier with CC. RFC 5681 does not mention exponential back-off of RTO, even though=20 it is indispensable congestion control algorithm to avoid congestion=20 collapse as stated in RFC 5033 and RFC 2914; algorithms in RFC 5681 alone=20 are not enough. RFC 6298 describes it as MUST but does not identify it as=20 a congestion control algorithm. RFC 6298 also makes it clear that the=20 backed-off RTO must be kept until a successful transmission of=20 non-retransmitted data, i.e., for the next segment, but it is not a=20 normative MUST. Original Karn's algorithm emphasises this, too. Exponential back-off of RTO is also important for IoT since a constrained=20 device might not have enough memory to have a larger window than 1 MSS.=20 In such a TCP implementation exponential back-off of RTO is the only CC=20 algorithm that is useful and needed. Furthermore, only RFC 1122 talks about "an algorithm" and clarifies:=20 combining "slow start" with "congestion avoidance". However, the original=20 congavoid paper, RFC 5681 and many other RFCs describe slow start,=20 congestion avoidance, etc. as separate algorithms. Alternative CC=20 algorithms usually modify one or a few of these algorithms. Current text=20 reads like it would be ok to implement just one of the algorithms, fast=20 retransmit, for example. In the RFC series slow start, congestion avoidance and exponential=20 back-off of RTO are MUST. Fast rexmit and fast recovery are SHOULD, i.e.,=20 they are more or less performance enhancements, very useful though. So how about something along the following lines: 3.7.2.=C2=A0 TCP Congestion Control RFC 2914 explains the importance of congestion control for the Internet= . RFC 1122 required implementation of Van Jacobson's congestion control algorithms slow start and congestion avoidance together with exponential back-off for successive RTO values for the same segment. RFC 2581 provided IETF Standards Track description of slow start and congestion avoidance, along with fast retransmit and fast recovery. RFC 5681 is the current description of these algorithms and is the current Standard Track specification providing guidelines for TCP congestion control. RFC 6298 describes exponential back-off of RTO values, including keeping the backed-off value until a subsequent=20 segment with new data has been sent and acknowledged. =C2=A0A TCP endpoint MUST implement=C2=A0the basic congestion control alg= orithms slow start, congestion avoidance, and exponential back-off of RTO to avoid creating congestion collapse conditions (MUST-19). RFC 5681 and RFC 6298 describe the basic algorithms on the IETF Standards Track that are broadly applicable. Multiple other suitable algorithms exist and have been widely used. Many TCP implementations support a set of alternative algorithms that can be configured for use on the endpoint.=C2=A0An endpoint may implement such alternative algorithm= s provided that the algorithms are conformant with the TCP specifications from the IETF Standards Track as described in RFC 2914, RFC 5033, and RFC 8961. ... /Markku On Thu, 10 Dec 2020, Joseph Touch wrote: > That works. > >> On Dec 10, 2020, at 10:00 PM, Jonathan Morton = wrote: >>=20 >>> On 11 Dec, 2020, at 7:24 am, Joseph Touch wrot= e: >>>=20 >>> RFC 5681 defines TCP CC, but does not define what constitutes =E2=80=9C= friendly=E2=80=9D. The closest is RFC 5348, but that defines rate control = known to be TCP friendly, not the parameters that define =E2=80=9CTCP fri= endly=E2=80=9D in general. The closest I could find was RFC8312, which as = an oddly reverse definition that =E2=80=9Cfriendly=E2=80=9D means =E2=80=9C= gives its users at least as much BW as conventional TCP=E2=80=9D - but th= at=E2=80=99s not friendly at all, frankly (I can easily design something = that does that by turning off CC) =E2=80=94 it really should be more like = =E2=80=9Cgives its users no more BW than conventional TCP=E2=80=9D. >>>=20 >>> Anyone else find anything? >>=20 >> I was thinking of RFC-5033. >>=20 >> - Jonathan Morton >>=20 >>=20 >>>> On Dec 10, 2020, at 6:01 PM, Jonathan Morton = wrote: >>>>=20 >>>>> On 11 Dec, 2020, at 2:52 am, Christian Huitema wrote: >>>>>=20 >>>>> Something like =E2=80=9Cfriendly to TCP standards-track CC=E2=80=9D= , or something like "following standard recommendations for TCP-Friendlin= ess." But at this point I think I talked too much, will let others chime = in. >>>>=20 >>>> Isn't there an RFC somewhere which talks about what you should take = into account when designing a congestion control algorithm? It would sur= ely be appropriate to reference that. >>>>=20 >>>> - Jonathan Morton >>>> _______________________________________________ >>>> tcpm mailing list >>>> tcpm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tcpm >>>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --=_script-22636-1607725537-0001-2-- From nobody Sat Dec 12 10:04:48 2020 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 4DAEE3A125F for ; Sat, 12 Dec 2020 10:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.6 X-Spam-Level: X-Spam-Status: No, score=-16.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, FUZZY_IMPORTANT=1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 YDqUpj2AiV0e for ; Sat, 12 Dec 2020 10:04:43 -0800 (PST) Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) (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 621373A1260 for ; Sat, 12 Dec 2020 10:04:43 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id v185so2898218vkf.8 for ; Sat, 12 Dec 2020 10:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bfnex/d40d4ttAR62h3SmaEomaoQgh9O15geOc9YCOg=; b=Sst9u7kthIlR79VrqUg25fl26PVDpdO8qQKVRkTl1DR3JZlRg3mP0MMChs3b6Q7ujD XKvyT114eAfYnqsr+eXMmW5KAR7DlpA2wWlLp5i5jxO6mgQUZDXHPG5bq7fUaQDp6zFH P4Xr7p04dwunYLgNJGFsBMhkUYYz0eg/SaEZ0eQ5cEtBzcOLtMkVmBD2wX+LOTIC6aPm u+5+pHG7oGmdU6dQK3Za7O+f5G+YoTdfQg3x/DH3ylXmAZzsmKWJ2Rf7eVeEnj20EjXD mOf0GlruZrnL3fD+NI/WLCdA3Ko6oUU5PUsJtLGYbAVtGUPMOGCbswrW5CNnyU7soh4l iiqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bfnex/d40d4ttAR62h3SmaEomaoQgh9O15geOc9YCOg=; b=bRbtHAfLffCvmyyunTV0Pz0+1Fb1FjAa7TL6kMi5HPnxW6rI+D8Sb32Rs9bpDV6fHr RIUJb8z5HQLhcRaCD1NtrwlvN6a9tGmVGG/KCMQ/dPPZzRjVSIRnNG6AfysR/gems8pJ QL/nHMLgGTOn70rv5+Izc3XjliL+K6+SplLtQ99wdAlm4EDu02vff6SUjX/et5smEbrl 8CuKw6K7TOE0jUin2hqtfv1G053Y0cHcp9LJO0o7MDQG3w/0rAhR46xh+bAP6AYGMATy aMUcViRx1uZ/XPcQiXcZnMv7qWEoyOE3RlPpMQG/rbJF1JeYjMn9dBZF25sY6YzzGJ23 6+bg== X-Gm-Message-State: AOAM533YnH3mwBo4xL907qx/hkE5M9MuP6U0+p982LaG+DVcfHpqx3tN dSKu/D+J8mwmo490LEs/Enwkr0TdWw8Xlm/X72hQMA== X-Google-Smtp-Source: ABdhPJyRpfSXA3mSAsYRiyy4uqjc0E8yKXMOsl8RwBYZ77wQwAc2mz7KITqDQQtLl6aZCsnqVjzcr4pNKkYryk/mL7I= X-Received: by 2002:a05:6122:12bb:: with SMTP id j27mr18513312vkp.18.1607796280997; Sat, 12 Dec 2020 10:04:40 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Neal Cardwell Date: Sat, 12 Dec 2020 13:04:24 -0500 Message-ID: To: Markku Kojo Cc: Yuchung Cheng , last-call@ietf.org, "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetection algorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 12 Dec 2020 18:04:47 -0000 Hi Markku, Thanks for your many detailed and thoughtful comments. Please see below in-line for our comments based on discussions among RACK-TLP draft authors. On Tue, Dec 8, 2020 at 11:21 AM Markku Kojo wrote: > > Hi, > > please see inline. > > On Mon, 7 Dec 2020, Yuchung Cheng wrote: > > > On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo wrote: > >> > >> Hi Yuchung, > >> > >> thanks for your reply. My major point is that IMHO this RACK-TLP > >> specification should give the necessary advice w.r.t congestion control > >> in cases when such advice is not available in the RFC series or is not > >> that easy to interpreted correctly from the existing RFCs. > >> > >> Even though the CC principles were available in RFC series I believe you > >> agree with me that getting detailed CC actions correct is sometimes quite > >> hard, especially if one needs to interpret and apply them from another > >> spec than what one is implementing. Please see more details inline below. > >> > >> In addition, we need to remember that this document is not meant only for > >> TCP experts following the tcpm list and having deep understanding of > >> congestion control but also those implementing TCP, for the very first > >> time, for various appliances, for example. They do not have first hand > >> experience in implementing TCP congestion control and deserve clear > >> advice what to do. > >> > >> On Fri, 4 Dec 2020, Yuchung Cheng wrote: > >> > >>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: > >>>> > >>>> Hi all, > >>>> > >>>> I know this is a bit late but I didn't have time earlier to take look at > >>>> this draft. > >>>> > >>>> Given that this RFC to be is standards track and RECOMMENDED to replace > >>>> current DupAck-based loss detection, it is important that the spec is > >>>> clear on its advice to those implementing it. Current text seems to > >>>> lack important advice w.r.t congestion control, and even though > >>>> the spec tries to decouple loss detection from congestion control > >>>> and does not intend to modify existing standard congestion control > >>>> some of the examples advice incorrect congestion control actions. > >>>> Therefore, I think it is worth to correct the mistakes and take > >>>> yet another look at a few implications of this specification. > >>> As you noted, the intention is to decouple the two as much as possible > >>> > >>> Unlike the 20 years ago where TCP loss detection and congestion > >>> control are essentially glued in one piece, the decoupling of the two > >>> (including modularizing congestion controls in implementations) has > >>> helped fueled many great inventions of new congestion controls. > >>> Codifying so-called-default C.C. reactions in the loss detection is a > >>> step backward that the authors try their best to avoid. > >> > >> While I fully agree with the general principle of decoupling loss > >> detection from congestion control when it is possible without leaving > >> open questions, I find it hard to get congestion control right with this > >> spec in certain cases I raised just by following the current standards > >> track CC specifications. The reason for this is that RACK-TLP introduces > >> new ways to detect loss (i.e., not present in any earlier standard track > >> RFC) and the current CC specifications do not provide correct CC actions > >> for such cases as I try to point out below. > >> > >>> To keep the > >>> document less "abstract / unclear" as many WGLC reviewers commented, > >>> we use examples to illustrate that includes CC actions. But the > >>> details of these CC actions are likely to become obsolete as CC > >>> continues to advance hopefully. > >> > >> Agreed. But I would appreciate if the CC actions in the examples would > >> correctly follow what is specified in the the current CC RFCs. And, I > >> would suggest explicitly citing the RFC(s) that each of the examples is > >> illustriating so that there is no doubt which CC variant the example > >> is valid with. Then there is no problem with the correctness of the > >> example either even if the cited RFC becomes later obsoleted. > >> > >>>> > >>>> Sec. 3.4 (and elsewhere when discussing recovering a dropped > >>>> retransmission): > >>>> > >>>> It is very useful that RACK-TLP allows for recovering dropped rexmits. > >>>> However, it seems that the spec ignores the fact that loss of a > >>>> retransmission is a loss in a successive window that requires reacting > >>>> to congestion twice as per RFC 5681. This advice must be included in > >>>> the specification because with RACK-TLP recovery of dropped rexmit > >>>> takes place during the fast recovery which is very different > >>>> from the other standard algorithms and therefore easy to miss > >>>> when implementing this spec. > >>> > >>> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 > >>> "Loss in two successive windows of data, or the loss of a > >>> retransmission, should be taken as two indications of congestion and, > >>> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > >>> > >>> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on > >>> this so I am not sure what clause you suggest to add to RACK-TLP. > >> > >> Right, this is the CC *principle* in RFC 5681 I am refering to but I am > >> afraid it is not enough to help one to correctly implement such lowering > >> of cwnd (and ssthresh) twice when a loss of a retransmission is detected > >> during Fast Recovery. Nor do RFCs clearly advice *when* this reduction > >> must take place. > >> > >> Congestion control principles tell us that congestion must be reacted > >> immediately when detected. But at the same time, standards track CC > >> specifications react to congestion only once during Fast Recovery > >> because the losses in the current window, which Fast Recovery repairs, > >> occured during the same RTT. That is, the current CC specifications do > >> not handle lost rexmits during Fast Recovery but, instead, the correct CC > >> reaction to a loss of a rexmit is automatically achieved by those > >> specifications via RTO when cwnd is explicitly reset upon RTO. > >> > >> Furthermore, the problem I am trying to point out is that there is no > >> correct rule/formula available in the standards track RFCs that would > >> give the correct way to reduce cwnd when the loss of rexmit is detected > >> with RACK-TLP. > >> > >> I suggest everyone reading this message stops reading at this point > >> for a while before continuing reading and figures out themselves what > >> they think would be the correct equation to use in the standards RFC > >> series to find the new halved value for cwnd when RACK-TLP detects a loss > >> of a rexmit during Fast Recovery. I would appreciate a comment on the > >> tcpm list from those who think they found the correct answer immediately > >> and easily, and what was the formula to use. > >> > >> ... > >> > >> I think the best advice one may find by looking at RFC 6675 (and RFC > >> 5681) is to set > >> > >> ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.2) > >> > >> Now, let's modify the example in Sec 3.4 of the draft: > >> > >> 1. Send P0, P1, P2, ..., P20 > >> [Assume P1, ..., P20 dropped by network] > >> > >> 2. Receive P0, ACK P0 > >> 3a. 2RTTs after (2), TLP timer fires > >> 3b. TLP: retransmits P20 > >> ... > >> 5a. Receive SACK for P20 > >> 5b. RACK: marks P1, ..., P20 lost > >> set cwnd=ssthresh=FlightSize/2=10 > >> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > >> [P1 retransmission dropped by network] > >> > >> Receive SACK P2 & P3 > >> 7a. RACK: marks P1 retransmission lost > >> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > >> 7b. Retransmit P1 > >> ... > >> > >> So, is the new value of the cwnd (10MSS) correct and halved twice? If not, > >> where is the correct formula to do it? > >> > >> Before RFC 5681 was published we had a discussion on FlighSize and that > >> during Fast Recovery it does not reflect the amount of segments in > >> flight correctly but may also have a too large value. It was decided not > >> to try to correct it because it only has an impact when RTO fires during > >> Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too large > >> ssthresh for RTO recovery in some cases was not considered that bad > >> because a TCP sender anyway takes to most conservative CC action with the > >> cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP enables > >> detecting loss of a rexmit during Fast Recovery we have an unresolved > >> problem. > > > > > 1. Send P0, P1, P2, ..., P20 > >> [Assume P1, ..., P20 dropped by network] > >> > >> 2. Receive P0, ACK P0 > >> 3a. 2RTTs after (2), TLP timer fires > >> 3b. TLP: retransmits P20 > >> ... > >> 5a. Receive SACK for P20 > >> 5b. RACK: marks P1, ..., P20 lost > >> set cwnd=ssthresh=FlightSize/2=10 > >> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > >> [P1 retransmission dropped by network] > >> > >> Receive SACK P2 & P3 > >> 7a. RACK: marks P1 retransmission lost > >> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > >> 7b. Retransmit P1 > > > > To account for your points, IMO clearly stating the existing CC RFC > > interactions w/o mandating any C.C. actions are the best way to move > > forward. Here are the text diff I proposed: > > > > "Figure 1, above, illustrates ... > > Notice a subtle interaction with existing congestion control actions > > on event 7a. It essentially starts another new episode of congestion > > due to the detection of lost retransmission. Per RFC5681 (section 4.3) > > that loss in two successive windows of data, or the loss of a > > retransmission, should be taken as two indications of congestion as a > > principle. But RFC6675 that introduces the pipe concept does not > > specify such a second window reduction. This document reminds RACK-TLP > > This is not quite correct characterization of RFC 6675. > RFC 6675 does not repeat all guidelines of RFC 5681. RFC 6675 DOES specify > the two indications of congestion implicitly by clearly stating in the > intro that it follows the guidelines set in RFC 5681. > And RFC 5681 articulates a set of MUSTs which ALL alternative loss > recovery algorithms MUST follow in order to become RFCs. > > (*) RFC 5681, Sec 4.3 (pp. 12-13): > > "While this document does not standardize any of the > specific algorithms that may improve fast retransmit/fast recovery, > ... > That is, ... > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion and, > therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > > > > implementation to carefully consider the new multiple congestion > > episode cases in the corresponding congestion control." > > I am sorry to say that this is very fuzzy and leaves an implementer > all alone what to do. > > More inportantly, AFAIK we have no discussion nor consensus in the IETF > on what is the correct CC action when lost rexmit is detected. > Should one reset cwnd like current CCs do, or would "halving again" be > fine, or something else? IMHO this requires experimentation to decide. > > I assumed there is an implementation of RACK-TLP with corresponding CC > actions and experimental results to devise what are the implications of > the selected CC action(s) with various levels of congestion. But it seems > we do not have such implementation nor experimental evidence? Am I wrong? [RACK-TLP-team:] We do have such implementations of RACK-TLP with corresponding CC actions, and experimental results were reported in RACK-TLP presentations and earlier revisions of the RACK-TLP draft. With respect to implementations, there is the Linux TCP stack, which has been using RACK-TLP as the default loss recovery algorithm since Linux v4.18 in August 2018. The exact commit is: b38a51fec1c1 tcp: disable RFC6675 loss detection With Linux, the default sender behavior since that commit has been governed by CUBIC, PRR, and RACK-TLP. RACK-TLP is used by all Google TCP traffic, including internal RPC traffic and external YouTube and google.com traffic over the public Internet. At Google we have years of high-traffic-volume experience with RACK-TLP with three different CC schemes: CUBIC+PRR, BBRv1, and BBRv2. My understanding is that Netflix FreeBSD TCP traffic uses RACK-TLP, and Microsoft Windows TCP traffic has also been using RACK-TLP. > I sincerely apologize that this got raised this late in the prosess and > I know how irritating it may be. I like the idea of RACK-TLP and by no > means my intention is not to hold up the process but the lack of evidence > makes me quite concerned. In particular, when this document says that > the current loss detection SHOULD be replaced in all implementations with > RACK-TLP. > > > and to emphasize in section 9.3 Interaction with congestion control > > > > "9.3. Interaction with congestion control > > > > RACK-TLP intentionally decouples loss detection ... this appropriate. > > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > > Loss in two successive windows of data, or the loss of a > > retransmission, should be taken as two indications of congestion, and > > therefore reacted separately. However implementation of RFC6675 pipe > > algorithm may not directly account for this newly detected congestion > > events properly. Therefore the documents reminds RACK-TLP > > implementation to carefully consider these implications in its > > corresponding congestion control. > > > > ..." > > > > > > > >> > >> > >>>> Sec 9.3: > >>>> > >>>> In Section 9.3 it is stated that the only modification to the existing > >>>> congestion control algorithms is that one outstanding loss probe > >>>> can be sent even if the congestion window is fully used. This is > >>>> fine, but the spec lacks the advice that if a new data segment is sent > >>>> this extra segment MUST NOT be included when calculating the new value > >>>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an > >>>> extra segment not allowed by cwnd, so it must be excluded from > >>>> FlightSize, if the TLP probe detects loss or if there is no ack > >>>> and RTO is needed to trigger loss recovery. > >>> > >>> Why exclude TLP (or any data) from FlightSize? The congestion control > >>> needs precise accounting of the flight size to react to congestion > >>> properly. > >> > >> Because FlightSize does not always reflect the correct amount of data > >> allowed by cwnd. When a TCP sender is not already in loss recovery and > >> it detects loss, this loss indicates the congestion point for the TCP > >> sender, i.e., how much data it can have outstanding. It is this amount of > >> data that it must use in calculating the new value of cwnd (and > >> ssthresh), so it must not include any data sent beyond the congestion > >> point. When TLP sends a new data segment, it is beyond the congestion > >> point and must not be included. Same holds for the segments sent via > >> Limited Transmit: they are allowed to be send out by the packet > >> conservation rule (DupAck indicates a pkt has left the network, but does > >> not allow increasing cwnd), i.e., the actual amount of data in flight > >> remains the same. > >> > >>>> In these cases the temporary over-commit is not accounted for as DupAck > >>>> does not decrease FlightSize and in case of an RTO the next ACK comes too > >>>> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits > >>>> including the segments transmitted via Limitid Transmit in the > >>>> calculation of ssthresh. > >>>> > >>>> In Section 9.3 a few example scenarios are used to illustriate the > >>>> intended operation of RACK-TLP. > >>>> > >>>> In the first example a sender has a congestion window (cwnd) of 20 > >>>> segments on a SACK-enabled connection. It sends 10 data segments > >>>> and all of them are lost. > >>>> > >>>> The text claims that without RACK-TLP the ending cwnd would be 4 segments > >>>> due to congestion window validation. This is incorrect. > >>>> As per RFC 7661 the sender MUST exit the non-validated phase upon an > >>>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if > >>>> the TCP sender uses the equation (4) of RFC 5681). > >>>> > >>>> The operation with RACK-TLP would inevitably result in congestion > >>>> collapse if RACK-TLP behaves as described in the example because > >>>> it restores the previous cwnd of 10 segments after the fast recovery > >>>> and would not react to congestion at all! I think this is not the > >>>> intended behavior by this spec but a mistake in the example. > >>>> The ssthresh calculated in the beginning of loss recovery should > >>>> be 5 segments as per RFC 6675 (and RFC 5681). > >>> To clarify, would this text look more clear? > >>> > >>> 'an ending cwnd set to the slow start threshold of 5 segments (half of > >>> the original congestion window of 10 segments)' > >> > >> This is correct, but please replace: > >> > >> (half of the original congestion window of 10 segments) > >> --> > >> (half of> the original FlightSize of 10 segments) > > > > sure will do > > > >> > >> cwnd in the example was 20 segments. > >> > >> Please also correct the ending cwnd for "without RACK" scenario. > >> I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, > >> my apologies. It MAENT equation (3) AND that results in ending cwnd of 5 > >> and 2/5 MSS (not 5 and 1/2 MSS). > >> NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then > >> ending cwnd would be 6 and 1/6 MSS). > >> > >>>> > >>>> Furthermore, it seems that this example with RACK-TLP refers to using > >>>> PRR_SSRB which effectively implements regular slow start in this > >>>> case(?). From congestion control point of view this is correct because > >>>> the entire flight of data as well as ack clock was lost. > >>>> > >>>> However, as correctly discussed in Sec 2, congestion window must be reset > >>>> to 1 MSS when an entire flight of data is and Ack clock is lost. But how > >>>> can an implementor know what to do if she/he is not implementing the > >>>> experimental PRR algrorithm? This spec articulates specifying an > >>>> alternative for DupAck counting, indicating that TLP is used to trigger > >>>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. > >>>> This means that without an additional advise an implementation of this > >>>> spec would just halve the cwnd and ssthresh and send a potentially very > >>>> large burst of segments in the beginning of the Fast Recovery because > >>>> there is no ack clock. So, this spec begs for an advise (MUST) when to > >>>> slow start and reset cwnd and when not, or at least a discussion of > >>>> this problem and some sort of advise what to do and what to avoid. > >>>> And, maybe a recommendation to implement it with PRR? > >>> > >>> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst > >>> control (when to slow-start). The use of PRR is just an example to > >>> illustrate and not meant for a recommendation. > >> > >> I understand the use of PRR was just an example, but my point is that if > >> one wants to implement RACK-TLP but does not intend to implement PRR but > >> RFC 6675 then we do not have a rule in RFC 6675 to correctly implement > >> CC for the case when an entire flight is lost and loss is detected with > >> TLP. Congestion control principle for this is clear and also stated in > >> this draft but IMHO it is not enough to ensure correct implementation. > >> > >> To my understanding we only have implementation experience for RACK-TLP > >> only togerher with PRR, which has the necessary rule to handle this kind > >> of scenario correctly. > >> > >> So, my question is how can one implement CC correctly without PRR such > >> a scenario where entire inflight is lost? > >> Which rule and where in the RFC series gives the necessary guidance to > >> reset cwnd and slow start when TCP detets loss of an entire flight? > > > > I think we're going in loops. To move forward it'd help if you suggest > > some text you like to change. > > Unfortunately I do not have an immediate solution. I assumed there is an > implementation and you could enlighten what was the solution there and > experimental results showing how it seems to work. If I have understood > it correctly there is a solution/implementation and experience of RACK-TLP > that works together with PRR but no solution/implementation nor experience > how it works without PRR. Am I correct? [RACK-TLP-team:] The implementation solutions and experiments were mentioned above. Our team's experience is with RACK-TLP in combination with either CUBIC+PRR, BBRv1, and BBRv2. We are not sure if there are other TCP implementations that implement RACK-TLP without PRR. > Given my understanding of PRR, the problem of an entire flight being > dropped is quite nicely solved with it. However, implementing RACK-TLP > without PRR begs for a solution. Here is my current understanding: > > (1) RACK part is what can be called to "replace" DupAck counting > (2) TLP part is effectively a new retransmission timeout to detect > a loss of an entire flight of data (i.e., it is only invoked > when a tail of the current flight becomes lost which equals to > the case of losing an entire flight since all segments before > the tail loss will get cumulatively Acked and hence these segments > are not anymore a part of the current flight at the time the loss > is detected. And we an assume application limited TCP sender. > (3) Current CC principles require resetting cwnd in such a case > and entering slow start (and so effectively does PRR though it is > not explicitly stated in RFC 6937). Slow start avoids a big burst > if the lost flight is big. > (4) RACK-TLP would possibly like to allow that cwnd is set to a half > of the lost flight and not to slow start. This means that the bigger > the lost flight is, the bigger is the burst that gets transmitted at > the beginning of the recovery which is bad. So, this approach would > need at least a rule/advice for burst avoidance (slow start, pacing, > ...). > (5) When the lost flight is small (<= 4 segments) there is no difference > in recovery efficiency between (3) and (4). If the lost flight is > > 5 segments, then (4) takes less RTTs to complete the recovery > but generates a burst. Note, even if pacing over one SRTT would be > used, it is still a burst. > > Now, it would be useful to have experimental data to know how the size of > the lost flight is distributed. Is it typically just a few segments as > illustriated in the examples of the draft or is it often larger? > > My advice would be to add a rule that cwnd MUST be reset to 1 MSS > and the sender MUST enter slow start if TLP detects loss of an entire > flight. This would be safe. Otherwise, without experimental evidence from > a wide range of different network conditions and workloads it feels > unsafe to allow more aggressive approach. [RACK-TLP-team:] Our team's position is that the RACK-TLP draft documents a loss detection algorithm, and normative declarations about congestion control behavior (like your "cwnd MUST be reset to 1 MSS", above) should be in a separate document focused on congestion control. > >>> Section 3 has a lengthy section to elaborate the key point of RACK-TLP > >>> is to maximize the chance of fast recovery. How C.C. governs the > >>> transmission dynamics after losses are detected are out of scope of > >>> this document in our authors' opinions. > >>> > >>> > >>>> > >>>> Another question relates to the use of TLP and adjusting timer(s) upon > >>>> timeout. In the same example discussed above, it is clear that PTO > >>>> that fires TLP is just a more aggressive retransmit timer with > >>>> an alternative data segment to (re)transmit. > >>>> > >>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in > >>>> effect a retransmission timout and the timer(s) must be backed-off. > >>>> This is not adviced in this specification. Whether it is the TCP RTO > >>>> or PTO that should be backed-off is an open question. Otherwise, > >>>> if the congestion is persistent and further transmission are also lost, > >>>> RACK-TLP would not react to congestion properly but would keep > >>>> retransmitting with "constant" timer value because new RTT estimate > >>>> cannot be obtained. > >>>> On a buffer bloated and heavily congested bottleneck this would easily > >>>> result in sending at least one unnecessary retransmission per one > >>>> delivered segment which is not advisable (e.g., when there are a huge > >>>> number of applications sharing a constrained bottleneck and these > >>>> applications are sending only one (or a few) segments and then > >>>> waiting for an reply from the peer before sending another request). > >>> > >>> Thanks for pointing to the RFC. After TLP, RTO timers will > >>> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 > >>> (didn't find 9.1 relevant). > >> > >> My apologies for refering to the wrong section of RFC 2914, Yes, I meant > >> Sec 9.3. > >> > >>> In your scenario, you presuppose the > >>> retransmission is unnecessary so obviously TLP is not good. Consider > >>> what happens without TLP where all the senders fire RTO spuriously and > >>> blow up the network. It is equally unfortunate behavior. "bdp > >>> insufficient of many flows" is a congestion control problem > >> > >> If (without TLP) RTO is spurious, it may result in unnecessary > >> retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to > >> detect and resolve it without TLP, so I don't find it as a problem. > >> > >> To clarify more, what I am concerned about. Think about a scenario where a > >> (narrow) bottleneck becomes heavily congested by a huge number of > >> competing senders such that the available capacity per sender is less > >> than 1 segment (or << 1 MSS). > >> This is a situation that network first enters before congestion collapse > >> gets realized. So, it is extremely important that all CC and timer > >> mechanisms handle it properly. Regular TCP handles it via RFC 6298 by > >> backing off RTO expotentially and keeping this backed-off RTO until an > >> new ACK is received for new data. This saves RACK-TLP from full congestion > >> collapse. But consider what happens: even though RTO is backed off, each > >> time a TCP sender manages to get one segment through (with cwnd = 1 MSS) > >> it always first arms PTO with more or less constant value of 2*SRTT. If > >> the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and > >> TLP becomes spurious. After a spurious TLP, RTO expires (maybe more than > >> once before exponential back-off of RTO results in large enough value) > >> and a new RTT sample is not received. So, SRTT remains unchanged and even > >> if sometimes a new sample is received, SRTT gets very slowly adjusted. As > >> a result, each TCP sender would keep on sending a spurious TLP for each > >> new segment resulting in at least 50% of the packets being unnecessary > >> rexmitted and the utilization of the bottleneck is < 50%. This would not > >> be a full congestion collapse but has unwanted symptoms towards > >> congestion collapse (Note: there is no clear line for the level of > >> reduction in delivery of useful data is considered as congestion > >> collapse). > > > > AFAIK you are saying: under extreme congestion shared by many short > > flows, RACK-TLP can cause more packet losses because of the more > > aggressive PTO timer. I agree and can add this to the "section 9.3". > > No, that was not what I meant. This happens simply when enough flows are > competing on the same bottleneck. It may be long flows or maybe > applications with more or less continuous request-reply exhanges. > E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is 500msecs and PMTU > is 1500B, then a bit over 40 simultaneous flows would mean that the > bottleneck becomes fully utilized with the equal share of roughly 1 MSS > per flow. With a quite typical bottleneck buffer size roughly equaling to > BDP, about 80+ flows would fill up the buffer as well and increase > RTT >= 1 secs. A buffer bloated bottleneck buffer would mean even larger > RTT and allow more flows sharing the bottleneck without loss. > > If the number of TCP flows is > 90 (or >> 90) RACK-TLP would ends up > (almost) always unnecessarily retransmitting each new segment once (PTO > being 1 sec or around 1 sec). RTO back-off after a few rounds saves each > TCP sender from additional unnecessary rexmits but still ~ 50% of the > deivered packets are not making any useful progress. > > If the bottleneck buffer is small, it would result in more losses as you > suggest but would not be that much of problem because majority of the > unnecessary rexmits would not get delivered over the bottleneck link. > Instead, they wuold get dropped at the bottleneck. Unnecessary rexmits > would just create extra load on the poth before the bottleneck (which of > course is not a non-problem either). [RACK-TLP-team:] If we are correctly understanding the scenario you are outlining, the PTO would likely not be 1 sec in this case. In this scenario, the RTT is around 1sec, so the PTO would be around 2*srtt, which would be around 2 secs. With a 1sec RTT, and even considering delayed ACKs, it seems very unlikely that a 2 sec PTO would cause a significant number of unnecessary TLP probes. Perhaps your postulated PTO of 1 sec is coming from the pseudocode path in TLP_calc_PTO() where, if SRTT is not available, the PTO is 1 second? However, this case where there is no SRTT only happens if (a) the connection is *not* using TCP timestamps (enabled for most connections on the public Internet, due to default-enabled support in Linux/Android and iOS/MacOS), and (b) the connection has *never* had a single RTT sample from a non-retransmitted packet. To meet both of those conditions is quite rare in practice. Is this the path that is causing your concerns about a PTO of 1 sec? Furthermore, in cases like this where the number of flows is roughly equal to or greater than the BDP of the path, Reno/[RFC5681] and CUBIC will spend the majority of their time in loss recovery (the minimum ssthresh from [RFC5681] being 2*SMSS). And the RACK-TLP ID specifies that TLP probes are not sent while in loss recovery. > > What authors disagree is that RTO must be back-off on the first > > instance if TLP is not acked. While your suggestion helps the > > congestion case, it may also hurt the recovery in other cases when the > > TLP is dropped due to light/burst/transient congestion. Arguing which > > scenarios matter more subjectively is not productive. > > When RACK-TLP is required to be implemented by all TCP stacks, it > is extremely important that it always works in a safe way and congestion > is always the primary concern to get properly handled. Without arguing > more, I just want to point out that TCP must work reasonably for all > Internet users. That means it must not generate a situation where even a > small minority of the Internet users often or almost always encounter > severe problems with their connectivity. > > For example, also users in developing countries where possibly an entire > village shares just one mobile (cellular, maybe 3G possibly only GPRS) > connection for their Internet access and pays per amount of data should > get reasonable TCP behavior. In such a case, I cannot agree with > engineering that results in almost always getting only half of the > already scarce bandwidth whle paying double price fot the useful data. > > But thinking about a way forward. Karn's algorithm would require backing > off PTO even if you get Ack of PTO. Relaxing this does not sound me that > bad at all, because there is often a pause before TLP and a TCP sender > gets feedback, so apparently conditions are not that bad and loss > recovery gets triggered (hopefully in slow start). > If TLP is not acked, RTO is needed and recovery is completed in using RTO > recovery in slow start. Now, if the RTO recovery is successful (no > losses during RTO recovery), it should be quite likely that the TCP > sender is able to successfully send also one new segment, because it > enters CA when it is sending at the half of the previous rate. So, once > you get Ack for the new segment, the TLP back off can be removed and it > is unlikely that the TLP back off slowed down next loss detection. > On the other hand, if the RTO recovery after an unsuccessful TLP is not > successful (more losses are detected), it is quite likely that congestion > has not been resolved. So, it is important to be conservative and have a > backed-off PTO (or even turn it off) to avoid (further) unnecessary > rexmits. If PTO is not backed of, I'd envision PTO mainly failing to get > an Ack in such a case and thereby it not being that useful. > > This certainly would require experimental data in a heavily congested > setting to really figure out the actual impact of different alternatives. > > > So the question we need to look at is if RACK-TLP 2RTT-PTO + regular > > RTO-backoff is going to cause major stability issues in extreme > > congestion. My understanding based on my officemate Van Jacobson's > > explanation is, as long as there's eventual exponential backoff, we'll > > avoid the repeated shelling the network. > > Right. But the problem is that with TLP as specified we do not have full > exponential back off. It lacks Karn's clamped retransmit backoff (as it > is called in Van Jacobson's seminal paper) which requires keeping > backed-off timer of a retransmitted segment for the next (new) segment and > ensures that there is eventual exponential backoff. > Backing off just RTO is not enough, because "fixed" PTO for each new > segment breaks this "back-off chain", that is, the exponential backoff > is not continueed until there is evidence that congestion has been > resolved (a cumulative Ack arrives for new data). But as I said, backing > off RTO saves RACK-TLP from a full congestion collapse. Still, wasting > 50% of the available network capacity in certain usage scenarios does not > sound acceptable for me. [RACK-TLP-team:] To address concerns related to Karn's algorithm, perhaps it would be sufficient to specify that after a RACK-TLP sender sends a TLP probe that is a retransmitted segment, it temporarily disables further TLP retransmissions until the sender obtains a valid RTT sample (i.e. from a non-retransmitted segment, or a segment with [RFC7323] TCP timestamps)? > > As a matter of fact some > > major TCP (!= Linux) implementation has implemented linear backoff of > > first N RTOs before exp-backoff. > > But that's quite ok as long as there is eventual exponential backoff, > including Karn's clamped retransmit backoff. Linear back-off in the > beginning just makes resolving (heavy) congestion a bit slower. > > >> > >>>> > >>>> Additional notes: > >>>> > >>>> Sec 2.2: > >>>> > >>>> Example 2: > >>>> "Lost retransmissions cause a resort to RTO recovery, since > >>>> DUPACK-counting does not detect the loss of the retransmissions. > >>>> Then the slow start after RTO recovery could cause burst losses > >>>> again that severely degrades performance [POLICER16]." > >>>> > >>>> RTO reovery is done in slow start. The last sentence is confusing as > >>>> there is no (new) slow-start after RTO recovery (or more precisely > >>>> slow start continues until cwnd > ssthresh). Do you mean: if/when slow > >>>> start still continues after RTO Recovery has repaired lost segments, > >>>> it may cause burst losses again? > >>> I mean the slow start after (the start of) RTO recovery. HTH > >> > >> Tnx. I'd appreciate if the text could be clarified to reflect this more > >> accurately. Maybe something along the lines(?): > >> > >> "Then the RTO recovery in slow start could cause burst > >> losses again that severely degrades performance [POLICER16]." > >> > >>>> > >>>> Example 3: > >>>> "If the reordering degree is beyond DupThresh, the DUPACK- > >>>> counting can cause a spurious fast recovery and unnecessary > >>>> congestion window reduction. To mitigate the issue, [RFC4653] > >>>> adjusts DupThresh to half of the inflight size to tolerate the > >>>> higher degree of reordering. However if more than half of the > >>>> inflight is lost, then the sender has to resort to RTO recovery." > >>>> > >>>> This seems to be somewhat incorrect description of TCP-NCR specified in > >>>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending > >>>> new data segments on DupAcks that makes it likely to avoid an RTO in > >>>> the given example scenario, if not too many of the the new data > >>>> segments triggered by Extended Limited Transmit are lost. > >>> sorry I don't see how the text is wrong describing RFC4653, > >>> specifically the algorithm in adjusting ssthresh > >> > >> To my understanding RFC4653 initializes DupThresh to half of the inflight > >> size in the beginning of the Extended Limited Transmit. Then on each > >> DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd > >> worth of DupAcks are received before packet loss is declared (or > >> reordering detected). So, if I am not incorrect, loss of a half of the > >> inflight does not necessarily result in RTO recovery with TCP-NCR. > > Could you suggest the text you'd like on NCR description. > > I'm not an expert nor closely acquainted with NCR. There might be many > different packet loss patterns that may affect the behavior. So, my > advice is to simply drop the last sentence starting with "However ...", > because it seems incorrect and replace the second but last sentence: > > To mitigate the issue, [RFC4653] > adjusts DupThresh to half of the inflight size to tolerate the > higher degree of reordering. > > --> > > To mitigate the issue, TCP-NCR [RFC4653] > increases the DupThresh from the current fixed value of three duplicate > ACKs [RFC5681] to approximately a congestion window of data having left > the network. [RACK-TLP-team:] Sure, we will revise accordingly. > >>>> > >>>> Sec. 3.5: > >>>> > >>>> "For example, consider a simple case where one > >>>> segment was sent with an RTO of 1 second, and then the application > >>>> writes more data, causing a second and third segment to be sent right > >>>> before the RTO of the first segment expires. Suppose only the first > >>>> segment is lost. Without RACK, upon RTO expiration the sender marks > >>>> all three segments as lost and retransmits the first segment. When > >>>> the sender receives the ACK that selectively acknowledges the second > >>>> segment, the sender spuriously retransmits the third segment." > >>>> > >>>> This seems incorrect. When the sender receives the ACK that selectively > >>>> acknowledges the second segment, it is a DupAck as per RFC 6675 and does > >>>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the > >>>> rexmit of the third segment is not allowad until the cumulative ACK of > >>>> the first segment arrives. > >>> I don't see where RFC6675 forbids growing cwnd. Even if it does, I > >>> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly > >>> indicates a delivery has been made. > >> > >> SACKed sequences with DUpAcks indicate that those sequences were > >> delivered but it does not tell when they were sent. The basic principle > >> of slow start is to reliably determine the available network capacity > >> during slow start. Therefore, slow start must ensure it uses only > >> segments sent during the slow start to increase cwnd. Otherwise, a TCP > >> sender may encounter exactly the problem of unnecessary retransmission > >> envisioned in this example of RACK-TCP draft (and increase cwnd on not > >> valid Acks). > >> > >> RFC 6675 does re-specify DupAck with SACK option but it does not include > >> the rule for slow start. Slow start is specified in RFC 5681. It is > >> crystal clear in allowing increase in cwnd only on cumulative > >> Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, > >> page 6: > >> > >> During slow start, a TCP increments cwnd by at most SMSS bytes for > >> each ACK received that cumulatively acknowledges new data. > >> > >> Maybe this example in the RACK-TLP draft was inspired by a incorrect > >> implementation of SACK-based loss recovery? > >> > >> FYI: when we were finalizing RFC 6675 I suggested including also an > >> algorithm for RTO recovery with SACK in RFC 6675. The reason was exactly > >> that it might be not easy to gather info from multiple documents and > >> hence help the implementor to have all necessary advice in a single > >> document. This unfortunately did not get realized though. > > > > I am honestly lost quibbling these RFC6675 implementations and feeling > > pedantic to these standards largely serve as guiding principles > > instead of line-by-line code. Is cwnd one packet bigger or smaller in > > this example making any different in advancing the Internet's > > capability to do better loss detection. I do not think so. > > Sorry, I don't understand what was quibbling here. I believe I did not > argue anything about cwnd size with this example at hand in Sec. 3.5. > My point is that it describes incorrect slow start behavior. Correctly > implemented slow start does not have the problem illustriated in the > example. > > > At this point please suggest a text you like to change. > > That is simple. Please remove the description of the behavior without > RACK. Or correct it: the behavior would be exactly the same as with RACK, > but the reason for not unnecessarily retransmitting third segment can be > described to be different. > And, please correct also the description with RACK. With RACK, third > segment does not get unnecessarly rexmitted for the reason already > indicated and also because cwnd=1 MSS. And, no new segments are allowed > either by cwnd=1. > [RACK-TLP-team:] Thanks. Perhaps it makes sense to consider a slightly different RTO scenario to illustrate the point about how RACK RTO behavior can avoid spurious retransmissions. Here is the proposed new text: "3.5. An Example of RACK-TLP in Action: RTO In addition to enhancing fast recovery, RACK improves the accuracy of RTO recovery by reducing spurious retransmissions. Without RACK, upon RTO timer expiration the sender marks all the unacknowledged segments lost. This approach can lead to spurious retransmissions. For example, consider a simple case where one segment was sent with an RTO of 1 second, and then the application writes more data, causing a second and third segment to be sent right before the RTO of the first segment expires. Suppose none of the segments were lost. Without RACK, if there is a spurious RTO then the sender marks all three segments as lost and retransmits the first segment. If the ACK for the original copy of the first segment arrives right after the spurious RTO retransmission, then the sender continues slow start and spuriously retransmits the second and third segments, since it (erroneously) presumed they are lost. With RACK, upon RTO timer expiration the only segment automatically marked lost is the first segment (since it was sent an RTO ago); for all the other segments RACK only marks the segment lost if at least one round trip has elapsed since the segment was transmitted. Consider the previous example scenario, this time with RACK. With RACK, when the RTO expires the sender only marks the first segment as lost, and retransmits that segment. The other two very recently sent segments are not marked lost, because they were sent less than one round trip ago and there were no ACKs providing evidence that they were lost. Upon receiving the ACK for the RTO retransmission the RACK sender would not yet retransmit the second or third segment. but rather would rearm the RTO timer and wait for a new RTO interval to elapse before marking the second or third segments as lost. " best regards, neal > Please remove also the last paragraph of the Sec. 3.5, it being also > incorrect description of behavior. > > BR, > > /Markku > > >> > >> BR, > >> > >> /Markku > >> > >>>> > >>>> Best regards, > >>>> > >>>> /Markku > >>>> > >>>> > >>>> > >>>> On Mon, 16 Nov 2020, The IESG wrote: > >>>> > >>>>> > >>>>> The IESG has received a request from the TCP Maintenance and Minor Extensions > >>>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection > >>>>> algorithm for TCP' > >>>>> as Proposed Standard > >>>>> > >>>>> The IESG plans to make a decision in the next few weeks, and solicits final > >>>>> comments on this action. Please send substantive comments to the > >>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may > >>>>> be sent to iesg@ietf.org instead. In either case, please retain the beginning > >>>>> of the Subject line to allow automated sorting. > >>>>> > >>>>> Abstract > >>>>> > >>>>> > >>>>> This document presents the RACK-TLP loss detection algorithm for TCP. > >>>>> RACK-TLP uses per-segment transmit timestamps and selective > >>>>> acknowledgements (SACK) and has two parts: RACK ("Recent > >>>>> ACKnowledgment") starts fast recovery quickly using time-based > >>>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") > >>>>> leverages RACK and sends a probe packet to trigger ACK feedback to > >>>>> avoid retransmission timeout (RTO) events. Compared to the widely > >>>>> used DUPACK threshold approach, RACK-TLP detects losses more > >>>>> efficiently when there are application-limited flights of data, lost > >>>>> retransmissions, or data packet reordering events. It is intended to > >>>>> be an alternative to the DUPACK threshold approach. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> The file can be obtained via > >>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > >>>>> > >>>>> > >>>>> > >>>>> No IPR declarations have been submitted directly on this I-D. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> tcpm mailing list > >>>>> tcpm@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>>> > >>> > > From nobody Sun Dec 13 03:38:20 2020 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 8BBFD3A16A5 for ; Sun, 13 Dec 2020 03:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Yz4mxkipyVJn for ; Sun, 13 Dec 2020 03:38:17 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 A30083A16A3 for ; Sun, 13 Dec 2020 03:38:17 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id 22so2848341qkf.9 for ; Sun, 13 Dec 2020 03:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8iwCDKxBEM7kuJXO7yCJAIsWlBfDm+n0NO/GO29a3WE=; b=CbWEEwSfmVWwT44TDmWm+6Bcw9YL0m2i70mBTkA5kZh+3KXf74gcU6vklf4EIHenBg QDVWV9wU5RVoipJtAusx+yGdwkYxPtyDf33xTUJrraJ93ohghVRW8zdYQvGoL/0eRufC 9M2ItQ+a646QAl6XUVFlMtbDndvrCo1MCDSyghv3zxFrSvkfK7ZFD+ErGO7KJvr4FnoR NJL9p9quFDHKheYL8zm24e3c68kWLqktWjuMtlp56rYQV7qhnDOXRCZnRbGp9fZL00zX ZYekaWYpv6IQy1zAnyb7aRlmRPKsUPaWDUd7KOTwH9+O5yVh8TVJKRMZBbtMp+tp0Xtk oDSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8iwCDKxBEM7kuJXO7yCJAIsWlBfDm+n0NO/GO29a3WE=; b=BJ/KvmfNmKOb4jzs8MGfKGui4GP3PK+WQpUctcYjO2QiBQsNcL4dhdANuHj5mDCMDM usIDhOhjACpUG0MAiSnhUKsP9Hg9Oid1VkH7XN7//nX5YaduZq4VvV5G9V++99dORFHM InKDIN6okDW6PNlnCrbI1x1UMp9qBLxsLp3n0oFy7LCqIB9Sk0gkqh/5+Cta5yKdqPCK txKZDikWziFWbs4JRvdeOpI0H/3/Oi6TbeNHf9CtvPpn0oGVjxr9CvsusM/PBwT4N1af /HyBeqt2WoX+RAcUpo0H9BF12bYAuiVSlnz6QFe2x44fq+ArIXJqvaL54Bp/FLhncaQ2 jz8g== X-Gm-Message-State: AOAM533G2xb9sBJZ+bH8Tjk4CTQ3vgMKjK9kPEhKY4fb1FoP73NO44QK JdRbVvxA5I/2yeJKquRg1zjsxaH8q1JkR/AUdRA= X-Google-Smtp-Source: ABdhPJz8U9iDvRLG4zx3nOTiCW3JOWxYj9nVeynfHM0JRJluTbx5ezy8Vy45VuWrl+BkA6WGr3p80uYq6fRY8TSTK0Q= X-Received: by 2002:a37:6f07:: with SMTP id k7mr27567440qkc.476.1607859495711; Sun, 13 Dec 2020 03:38:15 -0800 (PST) MIME-Version: 1.0 References: <160634544894.28725.8891473900084027588@ietfa.amsl.com> <7F478CFF-A60E-4513-AFCB-1DEE985F9880@ifi.uio.no> <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> In-Reply-To: <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> From: Yoshifumi Nishida Date: Sun, 13 Dec 2020 03:38:04 -0800 Message-ID: To: "Scharf, Michael" Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="0000000000001737a505b656f6dd" Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 11:38:20 -0000 --0000000000001737a505b656f6dd Content-Type: text/plain; charset="UTF-8" (chair hat off) Hi, I've read the updated version of the draft. But, I personally think the appendix.C still looks a bit too long. This appendix describes a proposal that can adjust initial cwnd over long timescales, but I'm not very sure if it's worth using 7 pages because It seems to me it doesn't look a very crucial part of the draft. Also, I am not sure how many readers want to implement this or there are some implementations that have already adopted it. Thanks, -- Yoshi On Thu, Nov 26, 2020 at 6:13 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > The appendix was the only remaining open issue I am aware of. If I there > are no objections to -06, I will close the WGLC and prepare my shepherd > write-up. > > Thanks! > > Michael > > > > -----Original Message----- > > From: tcpm On Behalf Of Michael Welzl > > Sent: Thursday, November 26, 2020 1:48 PM > > To: tcpm IETF list > > Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt > > > > Dear all, > > > > This is our update to address the WGLC comments, where concrete > > suggestions were made regarding the appendix. > > > > Cheers, > > Michael > > > > > > > On 26 Nov 2020, at 00:04, internet-drafts@ietf.org wrote: > > > > > > > > > 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 > WG > > of the IETF. > > > > > > Title : TCP Control Block Interdependence > > > Authors : Joe Touch > > > Michael Welzl > > > Safiqul Islam > > > Filename : draft-ietf-tcpm-2140bis-06.txt > > > Pages : 34 > > > Date : 2020-11-25 > > > > > > Abstract: > > > This memo provides guidance to TCP implementers that are intended to > > > help improve convergence to steady-state operation without affecting > > > interoperability. It updates and replaces RFC 2140's description of > > > interdependent TCP control blocks and the ways that part of TCP > > > state can be shared among similar concurrent or consecutive > > > connections. TCP state includes a combination of parameters, such as > > > connection state, current round-trip time estimates, congestion > > > control information, and process information. Most of this state is > > > maintained on a per-connection basis in the TCP Control Block (TCB), > > > but implementations can (and do) share certain TCB information > > > across connections to the same host. Such sharing is intended to > > > improve overall transient transport performance, while maintaining > > > backward-compatibility with existing implementations. The sharing > > > described herein is limited to only the TCB initialization and so > > > has no effect on the long-term behavior of TCP after a connection > > > has been established. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-06 > > > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-06 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-06 > > > > > > > > > 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/ > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000001737a505b656f6dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(chair hat off)
Hi,

I've read the updated version of the draft. But, I personally think t= he appendix.C still looks a bit too long.
This appendix describes= a proposal that can adjust initial cwnd over long timescales, but I'm = not very sure if it's worth using=C2=A07 pages because It seems to me i= t doesn't look a very crucial part of the draft.=C2=A0
Also, = I am not sure how many readers want to implement this or there are some imp= lementations=C2=A0that have already adopted it.

Th= anks,
--
Yoshi

On Thu, Nov 26, 2020 at 6:13 AM Scharf, M= ichael <Michael.Scharf= @hs-esslingen.de> wrote:
The appendix was the only remaining open issue I am aware o= f. If I there are no objections to -06, I will close the WGLC and prepare m= y shepherd write-up.

Thanks!

Michael


> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Michael Welzl
> Sent: Thursday, November 26, 2020 1:48 PM
> To: tcpm IETF list <tcpm@ietf.org>
> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt
>
> Dear all,
>
> This is our update to address the WGLC comments, where concrete
> suggestions were made regarding the appendix.
>
> Cheers,
> Michael
>
>
> > On 26 Nov 2020, at 00:04, internet-drafts@ietf.org wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> directories.
> > This draft is a work item of the TCP Maintenance and Minor Extens= ions WG
> of the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: TCP Control Block Interdependence
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Joe Touch
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Michael Welzl
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Safiqul Islam
> >=C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-tcpm-2140bis-06.txt
> >=C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 34
> >=C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 2020-11-25
> >
> > Abstract:
> >=C2=A0 =C2=A0This memo provides guidance to TCP implementers that = are intended to
> >=C2=A0 =C2=A0help improve convergence to steady-state operation wi= thout affecting
> >=C2=A0 =C2=A0interoperability. It updates and replaces RFC 2140= 9;s description of
> >=C2=A0 =C2=A0interdependent TCP control blocks and the ways that p= art of TCP
> >=C2=A0 =C2=A0state can be shared among similar concurrent or conse= cutive
> >=C2=A0 =C2=A0connections. TCP state includes a combination of para= meters, such as
> >=C2=A0 =C2=A0connection state, current round-trip time estimates, = congestion
> >=C2=A0 =C2=A0control information, and process information. Most of= this state is
> >=C2=A0 =C2=A0maintained on a per-connection basis in the TCP Contr= ol Block (TCB),
> >=C2=A0 =C2=A0but implementations can (and do) share certain TCB in= formation
> >=C2=A0 =C2=A0across connections to the same host. Such sharing is = intended to
> >=C2=A0 =C2=A0improve overall transient transport performance, whil= e maintaining
> >=C2=A0 =C2=A0backward-compatibility with existing implementations.= The sharing
> >=C2=A0 =C2=A0described herein is limited to only the TCB initializ= ation and so
> >=C2=A0 =C2=A0has no effect on the long-term behavior of TCP after = a connection
> >=C2=A0 =C2=A0has been established.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/= draft-ietf-tcpm-2140bis/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ie= tf-tcpm-2140bis-06
> > https://datatracker.ietf.o= rg/doc/html/draft-ietf-tcpm-2140bis-06
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-tcpm-2140bis-06
> >
> >
> > 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/
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/tcpm >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000001737a505b656f6dd-- From nobody Mon Dec 14 02:56:26 2020 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 811EC3A0FB9 for ; Mon, 14 Dec 2020 02:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 7hj6rMqvmkWi for ; Mon, 14 Dec 2020 02:56:22 -0800 (PST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2057.outbound.protection.outlook.com [40.107.21.57]) (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 498A73A0FB6 for ; Mon, 14 Dec 2020 02:56:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SMe2jrp7d9NBkTLfZufUVvabG4mQIE76blAgezEuNuyD/2+dfKaVlVUJtsSRKuc13uLKfJaKqFKetSp0X2NbqgFKbI4BBP2asifaNeXFMYW0YoaWAijowHGKCHCi2rAtS/ja+Ade4nJ2aRkyiXmTfSgZju9aYnjtPe7KIbwPYJVgRzz5TG8k3d2lVFTXtNdWWM9nrWtGsQA6cuszvG9kdwcxmedkJ9ISQbAeypEGLBOTAatbrBgGs5tYu0i9YMqUIRhuEvMydaEececR2cnWsi7I0yj0BC3kSBvW95LwcoyuW55QUr71ERlnEsyyuU5BVYcuRNwwvGPn1HHKU9yOSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z9h6xAPlXV2pJ6vWS4Rnu9zdjGvOicZnfn9yq27Kiyc=; b=kXyQ3svoCDz9E+56jSZHvncJ1YXpS8OXU+qQg/kpLdSNPLeRinxncGs9+gJ+jD6dja0ZPDz4xUdmdX/mTmgBhhSnBDNg+fCL4AsUg//q3f75N0HDYlCnxvYCcpfy9KfjVlTufLNVGZ7Jz6k5teUSFlaSLVTVpliWRtN2cliUo2VNq9ONhJSikNE8xX3+R3/yyvA+BEeSFd1dqD+E96DJbYQoURIu7kzAT9Oe9F4I7eO7IkfZK4RnAL4rnFHMgF9DcGcUanZE1gtZMNk18pV6WnInZpIlUrLqGPg6yGJ2e0Wxd01tmUWkf9QpAmlicdlmVlvOdqyBBqReozvQPNxOPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z9h6xAPlXV2pJ6vWS4Rnu9zdjGvOicZnfn9yq27Kiyc=; b=kqd561yThHAjyItQbM8ZBO+vgva8u+/5u0TvTfzmFo9qpZ2L1rc6yklDsI+nk8j3HEchxHDkvNtpFyAZr5ALNf8lYgaln15B1cHge5r2fFAtjnDqZcqLH2v0zSmxtwSRU+yIelBWtyNbeRP9JTmx7TF/oweQnvq5PJiClnlrBNk= Received: from AM0PR07MB3939.eurprd07.prod.outlook.com (2603:10a6:208:40::14) by AM0PR07MB3939.eurprd07.prod.outlook.com (2603:10a6:208:40::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.12; Mon, 14 Dec 2020 10:56:19 +0000 Received: from AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::d1a5:d2f1:5d62:ee4b]) by AM0PR07MB3939.eurprd07.prod.outlook.com ([fe80::d1a5:d2f1:5d62:ee4b%2]) with mapi id 15.20.3676.013; Mon, 14 Dec 2020 10:56:19 +0000 From: Mirja Kuehlewind To: Yoshifumi Nishida , "Scharf, Michael" CC: tcpm IETF list Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt Thread-Index: AQHWw39v0FHIeYsNaky1sbWGb+rnjKnaXZyAgAAXyoCAGoxxAIABl26A Date: Mon, 14 Dec 2020 10:56:19 +0000 Message-ID: <6338D8C5-6485-47A3-ACB3-73DC7F641488@ericsson.com> References: <160634544894.28725.8891473900084027588@ietfa.amsl.com> <7F478CFF-A60E-4513-AFCB-1DEE985F9880@ifi.uio.no> <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e74a:3800:b438:fbb8:b98e:f3dd] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24d0402a-b23c-49a2-d93a-08d8a01ee369 x-ms-traffictypediagnostic: AM0PR07MB3939: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2Q94y/+uyFViDLzCk0cOCI3QNILkvU/brRNOzinBzseiHpKUorP1CBSBxAnkT7DCNZoLdYRdfFpfM+iFlvbZ5cUfms6XabafDBFFgxfXF7BNntN8MAnGRWRm0vAE3xCfCTujUFH3LVtT5godghK75i0qIfQx+RfEB7XYRUmGxy4eWjl/hwxvTanluJ5wPJUIUqd80CGKR+Y2m+ITUrvXEHDRglF72m7uDRlzM9fGzgTVIL8NOIQUBmX+MKhhjO3z2/6+erZf+WcSj/MsCGyC55oAobEtNJPgYGsTPE7d25XjdPKpZHCXiE20Tdt6roqV+S+GB7kKIdI9wpPZg7YTXhYlaF7eNt5GpWPTkq0T82GwX/f2vwRnODj/aanfV7AR/i+K32EM7ZmXzWRGS+oG49jEvdPMubanqLNPoU0kE0g1xDMpfs2jU0gckXtNs5f2xWOI4mj/MITwFNV1YWuZ0PrzjK6gfGZA6SFzbsmcWcGkvXVXzKNmavSzQRyqkiVl x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3939.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(366004)(136003)(39860400002)(376002)(83380400001)(6512007)(71200400001)(166002)(6506007)(44832011)(66574015)(4326008)(2616005)(316002)(5660300002)(33656002)(2906002)(8936002)(6486002)(76116006)(36756003)(186003)(86362001)(66446008)(66556008)(66476007)(64756008)(66946007)(478600001)(110136005)(53546011)(8676002)(966005)(4001150100001)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Rlg0SU9DL1NBa1ZRMXU4WWdKNU56aGZ4NVVHaW9mSWN3UytxdTU2WUI2Umx4?= =?utf-8?B?cnhYdkFmaDRrU0FJWXRKWVdKTzZ4cDVXbjdwT3ZHNmpJeXpseUlkNVY4aHIy?= =?utf-8?B?NUY0dS9YTm5BNjBjMzg0a1lMNmJmN05YQlJiMk9VQzZPTmRQc0dtUjY5SHRw?= =?utf-8?B?Q1dmcEZLWUVab29BREZnbmVPcDNHMkZMMStFaVBMVEVma05GZ1Q0WlF1UDQ3?= =?utf-8?B?U09KdkZQNWphQ2FjNVk0WFZmeGI1bzltVmIzVk12NmovTGkrV2xSZFBpTG9G?= =?utf-8?B?Rys0OVllSVh3UmpnaVB3NkcweGxsdzFrMlRKcUZ0d2NsN1Z3Zm1sOEpMM0NQ?= =?utf-8?B?NFhtcm5LSlloeXBNQzFpS1Nncno2SURXbjA4Z3lkNktUQmpWb0RIVmRtSFkx?= =?utf-8?B?M0g2aERHK01jZWRZdUc1enZES2s3cTQzaTV1T0dORWVLeHVrUWZMM2JYZEVB?= =?utf-8?B?VDdTQzYzMTJ3OEttYWt4b1ZNeEJwN0NPeHpZeGVKbWxQTHdYVi9nY3ZnSHVh?= =?utf-8?B?ZHRnVnRFNkUxQjNIUjYyTnl2V1lZR0tMdjJTOXNIdzNKTjkrdXBvQmx0RVgy?= =?utf-8?B?U3dDZTN3UHFEMjMyb2cyWVVGdzQrelhTOW9VdDdTTXFVZXZVM01oeHRweFJn?= =?utf-8?B?cTBIbEY0STV3WTVaVDVNRktyMjJ5MFVRdzlLcno3UXhOUVVjeUI1M29LRXRs?= =?utf-8?B?YVFwU0praDIrUm9rRnNsbXdhZzV3Mk53MDRHNzdTay9VNkYxdHlxTDNYUklP?= =?utf-8?B?Rmd0aU1lcC9SY1NHVjFReWFKaHpXUk9FRGQ3OUpxejFRWXN0Q21NeTNMOVNQ?= =?utf-8?B?a3RQOVBZenBVTW0yRHZYM2JYSnQyc3I0TXcvZnBDRDVmMWpsbGQzSFE2a3VL?= =?utf-8?B?Z2Q2aFBkUDRxVzdXNmxXTG9ZdTZtRW83dGJma2tZKyszNWZ0WE5PNFVLTStP?= =?utf-8?B?M2FuOG9ORlJJc3BQRTM3ZllIdGNCQS9ycWxxRWZ3Y0QyV2lUOThtZ01jNjlR?= =?utf-8?B?UlRXNm9pQ3NsMzJxcTBjK1l4ZmxvVEM3TXNFZ3pBTXNYNFVZTUlsblBFYlhn?= =?utf-8?B?MzkvaWxPQVdVWVAxM0xLb3Fna3BKMm9wQUVJdTdxV2FRTDhFWjk5d09qSWUr?= =?utf-8?B?VldpRkJHaGVCM0IzancxYkc3RkF4cWRLS00yNkRIM2o1SkJZS055am1FT3B3?= =?utf-8?B?Vjk4cU9UL0tUc0ZtVDRodTVzeE14cjJzajdsNHV5eE1YL05BR2R0V29aVm1Q?= =?utf-8?B?eHBFQXFnSk95cmx3TjF1ZnpRNm9idjBxWDRMYlFveEZDTFU3U081TmVHdUJO?= =?utf-8?B?Y01RdUJhNWowQ3ZGYzRVR09UZDI0TFlKY3VIRTRGMmp6YTRLZ21jTk9SRXM0?= =?utf-8?B?TWlkRDBiREM4a01Qby8xTEc1Mk5rNFM3TnlXM3Z0Y2Q4Y0gwMDc3dkdUU0g4?= =?utf-8?Q?ExmEK3lT?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6338D8C5648547A3ACB373DC7F641488ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3939.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24d0402a-b23c-49a2-d93a-08d8a01ee369 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2020 10:56:19.7183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9rqPkBjOxzY2CTrG1apskpAnuuBGWrgbwonQMWDgxc+h+quW8RQKerv+7j5osl8liE6ie8UkvDH9piRupshtwZox6hnrb8tolHwObTX+ptE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3939 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 14 Dec 2020 10:56:24 -0000 --_000_6338D8C5648547A3ACB373DC7F641488ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWxzbyBzdGlsbCBjb25jZXJuZWQgYWJvdXQgdGhlIGFwcGVuZGl4LiBJIHRoaW5rIGEg bGluayB0byB0aGUgZXhwaXJlZCBkcmFmdCBhbmQgc29tZSBzdW1tYXJ5IGRpc2N1c3Npb24gd291 bGQgYmUgc3VmZmljaWVudCByYXRoZXIgdGhhbiBjb3B5aW5nIHRoZSB3aG9sZSBleHBpcmVkIGRy YWZ0IGluIHRoZSBhcHBlbmRpeCB0aGF0IG5ldmVyIHJlYWNoZWQgYW55IGNvbnNlbnN1cyBpbiB0 aGUgZ3JvdXAuDQoNCg0KDQpGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBZb3NoaWZ1bWkgTmlzaGlkYSA8bnNkLmlldGZAZ21haWwuY29tPg0KRGF0ZTogU3Vu ZGF5LCAxMy4gRGVjZW1iZXIgMjAyMCBhdCAxMjozOA0KVG86ICJTY2hhcmYsIE1pY2hhZWwiIDxN aWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+DQpDYzogdGNwbSBJRVRGIGxpc3QgPHRjcG1A aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNw bS0yMTQwYmlzLTA2LnR4dA0KDQooY2hhaXIgaGF0IG9mZikNCkhpLA0KDQpJJ3ZlIHJlYWQgdGhl IHVwZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQuIEJ1dCwgSSBwZXJzb25hbGx5IHRoaW5rIHRo ZSBhcHBlbmRpeC5DIHN0aWxsIGxvb2tzIGEgYml0IHRvbyBsb25nLg0KVGhpcyBhcHBlbmRpeCBk ZXNjcmliZXMgYSBwcm9wb3NhbCB0aGF0IGNhbiBhZGp1c3QgaW5pdGlhbCBjd25kIG92ZXIgbG9u ZyB0aW1lc2NhbGVzLCBidXQgSSdtIG5vdCB2ZXJ5IHN1cmUgaWYgaXQncyB3b3J0aCB1c2luZyA3 IHBhZ2VzIGJlY2F1c2UgSXQgc2VlbXMgdG8gbWUgaXQgZG9lc24ndCBsb29rIGEgdmVyeSBjcnVj aWFsIHBhcnQgb2YgdGhlIGRyYWZ0Lg0KQWxzbywgSSBhbSBub3Qgc3VyZSBob3cgbWFueSByZWFk ZXJzIHdhbnQgdG8gaW1wbGVtZW50IHRoaXMgb3IgdGhlcmUgYXJlIHNvbWUgaW1wbGVtZW50YXRp b25zIHRoYXQgaGF2ZSBhbHJlYWR5IGFkb3B0ZWQgaXQuDQoNClRoYW5rcywNCi0tDQpZb3NoaQ0K DQpPbiBUaHUsIE5vdiAyNiwgMjAyMCBhdCA2OjEzIEFNIFNjaGFyZiwgTWljaGFlbCA8TWljaGFl bC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5n ZW4uZGU+PiB3cm90ZToNClRoZSBhcHBlbmRpeCB3YXMgdGhlIG9ubHkgcmVtYWluaW5nIG9wZW4g aXNzdWUgSSBhbSBhd2FyZSBvZi4gSWYgSSB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyB0byAtMDYs IEkgd2lsbCBjbG9zZSB0aGUgV0dMQyBhbmQgcHJlcGFyZSBteSBzaGVwaGVyZCB3cml0ZS11cC4N Cg0KVGhhbmtzIQ0KDQpNaWNoYWVsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiB0Y3BtIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRjcG0tYm91bmNlc0Bp ZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFdlbHpsDQo+IFNlbnQ6IFRodXJzZGF5LCBO b3ZlbWJlciAyNiwgMjAyMCAxOjQ4IFBNDQo+IFRvOiB0Y3BtIElFVEYgbGlzdCA8dGNwbUBpZXRm Lm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4+DQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMtMDYudHh0DQo+DQo+IERlYXIgYWxsLA0KPg0K PiBUaGlzIGlzIG91ciB1cGRhdGUgdG8gYWRkcmVzcyB0aGUgV0dMQyBjb21tZW50cywgd2hlcmUg Y29uY3JldGUNCj4gc3VnZ2VzdGlvbnMgd2VyZSBtYWRlIHJlZ2FyZGluZyB0aGUgYXBwZW5kaXgu DQo+DQo+IENoZWVycywNCj4gTWljaGFlbA0KPg0KPg0KPiA+IE9uIDI2IE5vdiAyMDIwLCBhdCAw MDowNCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+ ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVENQIE1haW50ZW5hbmNlIGFuZCBN aW5vciBFeHRlbnNpb25zIFdHDQo+IG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gICAgICAgIFRpdGxl ICAgICAgICAgICA6IFRDUCBDb250cm9sIEJsb2NrIEludGVyZGVwZW5kZW5jZQ0KPiA+ICAgICAg ICBBdXRob3JzICAgICAgICAgOiBKb2UgVG91Y2gNCj4gPiAgICAgICAgICAgICAgICAgICAgICAg ICAgTWljaGFlbCBXZWx6bA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBTYWZpcXVsIElz bGFtDQo+ID4gICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2 LnR4dA0KPiA+ICAgICBQYWdlcyAgICAgICAgICAgOiAzNA0KPiA+ICAgICBEYXRlICAgICAgICAg ICAgOiAyMDIwLTExLTI1DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgIFRoaXMgbWVtbyBwcm92 aWRlcyBndWlkYW5jZSB0byBUQ1AgaW1wbGVtZW50ZXJzIHRoYXQgYXJlIGludGVuZGVkIHRvDQo+ ID4gICBoZWxwIGltcHJvdmUgY29udmVyZ2VuY2UgdG8gc3RlYWR5LXN0YXRlIG9wZXJhdGlvbiB3 aXRob3V0IGFmZmVjdGluZw0KPiA+ICAgaW50ZXJvcGVyYWJpbGl0eS4gSXQgdXBkYXRlcyBhbmQg cmVwbGFjZXMgUkZDIDIxNDAncyBkZXNjcmlwdGlvbiBvZg0KPiA+ICAgaW50ZXJkZXBlbmRlbnQg VENQIGNvbnRyb2wgYmxvY2tzIGFuZCB0aGUgd2F5cyB0aGF0IHBhcnQgb2YgVENQDQo+ID4gICBz dGF0ZSBjYW4gYmUgc2hhcmVkIGFtb25nIHNpbWlsYXIgY29uY3VycmVudCBvciBjb25zZWN1dGl2 ZQ0KPiA+ICAgY29ubmVjdGlvbnMuIFRDUCBzdGF0ZSBpbmNsdWRlcyBhIGNvbWJpbmF0aW9uIG9m IHBhcmFtZXRlcnMsIHN1Y2ggYXMNCj4gPiAgIGNvbm5lY3Rpb24gc3RhdGUsIGN1cnJlbnQgcm91 bmQtdHJpcCB0aW1lIGVzdGltYXRlcywgY29uZ2VzdGlvbg0KPiA+ICAgY29udHJvbCBpbmZvcm1h dGlvbiwgYW5kIHByb2Nlc3MgaW5mb3JtYXRpb24uIE1vc3Qgb2YgdGhpcyBzdGF0ZSBpcw0KPiA+ ICAgbWFpbnRhaW5lZCBvbiBhIHBlci1jb25uZWN0aW9uIGJhc2lzIGluIHRoZSBUQ1AgQ29udHJv bCBCbG9jayAoVENCKSwNCj4gPiAgIGJ1dCBpbXBsZW1lbnRhdGlvbnMgY2FuIChhbmQgZG8pIHNo YXJlIGNlcnRhaW4gVENCIGluZm9ybWF0aW9uDQo+ID4gICBhY3Jvc3MgY29ubmVjdGlvbnMgdG8g dGhlIHNhbWUgaG9zdC4gU3VjaCBzaGFyaW5nIGlzIGludGVuZGVkIHRvDQo+ID4gICBpbXByb3Zl IG92ZXJhbGwgdHJhbnNpZW50IHRyYW5zcG9ydCBwZXJmb3JtYW5jZSwgd2hpbGUgbWFpbnRhaW5p bmcNCj4gPiAgIGJhY2t3YXJkLWNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRh dGlvbnMuIFRoZSBzaGFyaW5nDQo+ID4gICBkZXNjcmliZWQgaGVyZWluIGlzIGxpbWl0ZWQgdG8g b25seSB0aGUgVENCIGluaXRpYWxpemF0aW9uIGFuZCBzbw0KPiA+ICAgaGFzIG5vIGVmZmVjdCBv biB0aGUgbG9uZy10ZXJtIGJlaGF2aW9yIG9mIFRDUCBhZnRlciBhIGNvbm5lY3Rpb24NCj4gPiAg IGhhcyBiZWVuIGVzdGFibGlzaGVkLg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tl ciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRjcG0tMjE0MGJpcy8NCj4gPg0KPiA+IFRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMtMDYNCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2DQo+ ID4NCj4gPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGNwbS0y MTQwYmlzLTA2DQo+ID4NCj4gPg0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gPiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiA+ IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IHRjcG0gbWFpbGluZyBsaXN0DQo+IHRjcG1AaWV0 Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGNwbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1A aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg== --_000_6338D8C5648547A3ACB373DC7F641488ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1ERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZbSBhbHNvIHN0aWxsIGNvbmNlcm5lZCBhYm91dCB0 aGUgYXBwZW5kaXguIEkgdGhpbmsgYSBsaW5rIHRvIHRoZSBleHBpcmVkIGRyYWZ0IGFuZCBzb21l IHN1bW1hcnkgZGlzY3Vzc2lvbiB3b3VsZCBiZSBzdWZmaWNpZW50IHJhdGhlciB0aGFuIGNvcHlp bmcgdGhlIHdob2xlIGV4cGlyZWQgZHJhZnQgaW4gdGhlIGFwcGVuZGl4DQogdGhhdCBuZXZlciBy ZWFjaGVkIGFueSBjb25zZW5zdXMgaW4gdGhlIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj50Y3BtICZsdDt0Y3BtLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7bnNkLmlldGZAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIDEzLiBEZWNlbWJlciAyMDIwIGF0IDEy OjM4PGJyPg0KPGI+VG86IDwvYj4mcXVvdDtTY2hhcmYsIE1pY2hhZWwmcXVvdDsgJmx0O01pY2hh ZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSZndDs8YnI+DQo8Yj5DYzogPC9iPnRjcG0gSUVURiBs aXN0ICZsdDt0Y3BtQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW3RjcG1d IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2LnR4dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPihjaGFp ciBoYXQgb2ZmKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGksPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkkndmUgcmVhZCB0aGUgdXBkYXRlZCB2ZXJz aW9uIG9mIHRoZSBkcmFmdC4gQnV0LCBJIHBlcnNvbmFsbHkgdGhpbmsgdGhlIGFwcGVuZGl4LkMg c3RpbGwgbG9va3MgYSBiaXQgdG9vIGxvbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGlzIGFw cGVuZGl4IGRlc2NyaWJlcyBhIHByb3Bvc2FsIHRoYXQgY2FuIGFkanVzdCBpbml0aWFsIGN3bmQg b3ZlciBsb25nIHRpbWVzY2FsZXMsIGJ1dCBJJ20gbm90IHZlcnkgc3VyZSBpZiBpdCdzIHdvcnRo IHVzaW5nJm5ic3A7NyBwYWdlcyBiZWNhdXNlIEl0IHNlZW1zIHRvIG1lIGl0IGRvZXNuJ3QgbG9v ayBhIHZlcnkgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBkcmFmdC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPkFsc28sIEkgYW0gbm90IHN1cmUgaG93IG1hbnkgcmVhZGVycyB3YW50IHRvIGltcGxl bWVudCB0aGlzIG9yIHRoZXJlIGFyZSBzb21lIGltcGxlbWVudGF0aW9ucyZuYnNwO3RoYXQgaGF2 ZSBhbHJlYWR5IGFkb3B0ZWQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5Zb3NoaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+T24gVGh1LCBOb3YgMjYsIDIwMjAgYXQgNjoxMyBBTSBTY2hhcmYsIE1pY2hhZWwgJmx0 OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGUiPk1pY2hhZWwu U2NoYXJmQGhzLWVzc2xpbmdlbi5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+VGhlIGFwcGVuZGl4IHdhcyB0aGUgb25seSByZW1haW5pbmcgb3BlbiBpc3N1ZSBJ IGFtIGF3YXJlIG9mLiBJZiBJIHRoZXJlIGFyZSBubyBvYmplY3Rpb25zIHRvIC0wNiwgSSB3aWxs IGNsb3NlIHRoZSBXR0xDIGFuZCBwcmVwYXJlIG15IHNoZXBoZXJkIHdyaXRlLXVwLjxicj4NCjxi cj4NClRoYW5rcyE8YnI+DQo8YnI+DQpNaWNoYWVsPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogdGNwbSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRjcG0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG0tYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBNaWNoYWVsIFdlbHpsPGJyPg0KJmd0OyBT ZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjYsIDIwMjAgMTo0OCBQTTxicj4NCiZndDsgVG86IHRj cG0gSUVURiBsaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDogUmU6IFt0Y3Bt XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRjcG0tMjE0MGJpcy0wNi50eHQ8YnI+DQomZ3Q7IDxi cj4NCiZndDsgRGVhciBhbGwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgb3VyIHVwZGF0 ZSB0byBhZGRyZXNzIHRoZSBXR0xDIGNvbW1lbnRzLCB3aGVyZSBjb25jcmV0ZTxicj4NCiZndDsg c3VnZ2VzdGlvbnMgd2VyZSBtYWRlIHJlZ2FyZGluZyB0aGUgYXBwZW5kaXguPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IENoZWVycyw8YnI+DQomZ3Q7IE1pY2hhZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IE9uIDI2IE5vdiAyMDIwLCBhdCAwMDowNCwgPGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9u LWxpbmUgSW50ZXJuZXQtRHJhZnRzPGJyPg0KJmd0OyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7ICZn dDsgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVENQIE1haW50ZW5hbmNlIGFuZCBN aW5vciBFeHRlbnNpb25zIFdHPGJyPg0KJmd0OyBvZiB0aGUgSUVURi48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGl0bGUmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogVENQIENvbnRyb2wgQmxvY2sgSW50ZXJk ZXBlbmRlbmNlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhv cnMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBKb2UgVG91Y2g8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTWljaGFlbCBXZWx6bDxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTYWZpcXVsIElzbGFt PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtGaWxlbmFtZSZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2LnR4dDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7UGFnZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzogMzQ8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0RhdGUm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMjAtMTEtMjU8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwO1RoaXMgbWVtbyBwcm92aWRlcyBndWlkYW5jZSB0byBUQ1AgaW1wbGVtZW50ZXJzIHRo YXQgYXJlIGludGVuZGVkIHRvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2hlbHAgaW1wcm92 ZSBjb252ZXJnZW5jZSB0byBzdGVhZHktc3RhdGUgb3BlcmF0aW9uIHdpdGhvdXQgYWZmZWN0aW5n PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2ludGVyb3BlcmFiaWxpdHkuIEl0IHVwZGF0ZXMg YW5kIHJlcGxhY2VzIFJGQyAyMTQwJ3MgZGVzY3JpcHRpb24gb2Y8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7aW50ZXJkZXBlbmRlbnQgVENQIGNvbnRyb2wgYmxvY2tzIGFuZCB0aGUgd2F5cyB0 aGF0IHBhcnQgb2YgVENQPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO3N0YXRlIGNhbiBiZSBz aGFyZWQgYW1vbmcgc2ltaWxhciBjb25jdXJyZW50IG9yIGNvbnNlY3V0aXZlPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwO2Nvbm5lY3Rpb25zLiBUQ1Agc3RhdGUgaW5jbHVkZXMgYSBjb21iaW5h dGlvbiBvZiBwYXJhbWV0ZXJzLCBzdWNoIGFzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2Nv bm5lY3Rpb24gc3RhdGUsIGN1cnJlbnQgcm91bmQtdHJpcCB0aW1lIGVzdGltYXRlcywgY29uZ2Vz dGlvbjxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtjb250cm9sIGluZm9ybWF0aW9uLCBhbmQg cHJvY2VzcyBpbmZvcm1hdGlvbi4gTW9zdCBvZiB0aGlzIHN0YXRlIGlzPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwO21haW50YWluZWQgb24gYSBwZXItY29ubmVjdGlvbiBiYXNpcyBpbiB0aGUg VENQIENvbnRyb2wgQmxvY2sgKFRDQiksPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2J1dCBp bXBsZW1lbnRhdGlvbnMgY2FuIChhbmQgZG8pIHNoYXJlIGNlcnRhaW4gVENCIGluZm9ybWF0aW9u PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2Fjcm9zcyBjb25uZWN0aW9ucyB0byB0aGUgc2Ft ZSBob3N0LiBTdWNoIHNoYXJpbmcgaXMgaW50ZW5kZWQgdG88YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7aW1wcm92ZSBvdmVyYWxsIHRyYW5zaWVudCB0cmFuc3BvcnQgcGVyZm9ybWFuY2UsIHdo aWxlIG1haW50YWluaW5nPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2JhY2t3YXJkLWNvbXBh dGliaWxpdHkgd2l0aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMuIFRoZSBzaGFyaW5nPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2Rlc2NyaWJlZCBoZXJlaW4gaXMgbGltaXRlZCB0byBvbmx5 IHRoZSBUQ0IgaW5pdGlhbGl6YXRpb24gYW5kIHNvPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw O2hhcyBubyBlZmZlY3Qgb24gdGhlIGxvbmctdGVybSBiZWhhdmlvciBvZiBUQ1AgYWZ0ZXIgYSBj b25uZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO2hhcyBiZWVuIGVzdGFibGlzaGVk Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQomZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3Bt LTIxNDBiaXMvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXRjcG0tMjE0MGJpcy88L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+ DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdGNwbS0yMTQwYmlzLTA2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMtMDY8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10 Y3BtLTIxNDBiaXMtMDYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLTIxNDBiaXMtMDY8L2E+PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2 YWlsYWJsZSBhdDo8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2IiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10Y3BtLTIxNDBi aXMtMDY8L2E+PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mPGJyPg0KJmd0OyBzdWJtaXNzaW9uPGJyPg0KJmd0OyAmZ3Q7IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRmLm9yZzwvYT4uPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgdGNwbSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEg aHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3Jn PC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RjcG0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG08L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0Y3BtIG1haWxpbmcg bGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdGNwbSBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRj cG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6338D8C5648547A3ACB373DC7F641488ericssoncom_-- From nobody Mon Dec 14 19:43:22 2020 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 9DA933A0332 for ; Mon, 14 Dec 2020 19:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 wLMz8P0LYM8z for ; Mon, 14 Dec 2020 19:43:19 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 7E61D3A02BD for ; Mon, 14 Dec 2020 19:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=USx18rLhO5w6GXINTdhEcXUzUva8iFoR6BwnetcdGUc=; b=BgFm27vhcgkr21y8I55nXg5tG ZPHQW/bszZUt53G4bJ7X2nBRFJG7S+KCk1aatvB3cxjhFZ7TmqKBexBiGr+FPiuCOiw+zd5mY94mt Z7zIdhKnIHZUwTZF47Ci6y7U823WsPaDNMI6yu7wkgD37QY/tXZa+BFHqpcAJyRLEb64KvigLDlC5 Wn0h9xrhvNbM3G3nweq87XjSbjY1gEJf18c5QPC2xT1nCbQvdJilmiNuwQPO5kjUsDSSQ1RxttC5V JIc+IcavZRKnePT8T8m2iet43PeZRs0PlX08kefvT+ocZqvmgkAiwiexSOvD2WetktzCO5COupXv6 ituVi8udg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61429 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kp1F3-002xlp-O0; Mon, 14 Dec 2020 22:43:18 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Mon, 14 Dec 2020 19:43:12 -0800 Cc: "Scharf, Michael" , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <160634544894.28725.8891473900084027588@ietfa.amsl.com> <7F478CFF-A60E-4513-AFCB-1DEE985F9880@ifi.uio.no> <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 03:43:21 -0000 On Dec 13, 2020, at 3:38 AM, Yoshifumi Nishida = wrote: >=20 > (chair hat off) > Hi, >=20 > I've read the updated version of the draft. But, I personally think = the appendix.C still looks a bit too long. > This appendix describes a proposal that can adjust initial cwnd over = long timescales, but I'm not very sure if it's worth using 7 pages = because It seems to me it doesn't look a very crucial part of the draft.=20= It=E2=80=99s tracked for informational. I agree with your assessment, = but only because there are no =E2=80=9Ccrucial=E2=80=9D portions to ANY = informational document. > Also, I am not sure how many readers want to implement this or there = are some implementations that have already adopted it. That argument held when 2140 was originally published 23 years ago, but = aspects of it were implemented many years later. This update anticipates = the same possibility and timeline. The appendix takes *only* 7 pages to explain the details of how to adapt = the methods in the rest of the paper to long timescales, which could = replace the need to repeatedly update the IW, which took 12 pages the = first time, 15 pages the second time, and 18 pages the third time. I.e., = that=E2=80=99s 7 pages in this doc vs. 45 pages to date in other docs. = That should be considered a bargain. If you look at those 7 pages, it provides pseudocode, mechanisms that = have since become BCP for ECN, and recommendations on configurations of = defaults. It would be useful if you could point to a specific section of = that appendix that you think could be compressed or removed. Joe From nobody Mon Dec 14 19:51:55 2020 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 5C90A3A03EF for ; Mon, 14 Dec 2020 19:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.455 X-Spam-Level: X-Spam-Status: No, score=0.455 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.652, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 8Le7m-AMmXFk for ; Mon, 14 Dec 2020 19:51:51 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 E30033A03EE for ; Mon, 14 Dec 2020 19:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QTk8kAVvlgQpTG1/yavgiq81ZRMIp/VX25rjhrFLOTY=; b=U/+svgvtpvUpbf4UVbPN9tcXz 42b5VHtzWHqyBzcKATEVzjt7dz/0JorgIfC1shtoKc+FrDzU1wjpA2p6yGRzEMaRnUoMdoDhHTlH+ AY2R4zGePsrlUIJ6PCiiRLJjssFM3Ynhv3LWhgWQQ9n3qyp1arjFeaz8VnuROKysmt8BCQCq5jOiP LDZZAljBFCCGkk6gfhZeA1XW4go35Coou060iqNJi9EQBLr2pAMh/770LGb4l7AdpV7/00t6dy9BC KTKScAKALIWSQsZ8aVgaWimd+RvI3YSKYGUNIIMcpcZtLbCLr3D5dhp0OxLp1ov0GGF2OxD1eWjko Ch6mUgzRg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61491 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kp1NK-00374q-TW; Mon, 14 Dec 2020 22:51:51 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_D40A3DE1-9390-4CD4-8994-C4434A864A0D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: <6338D8C5-6485-47A3-ACB3-73DC7F641488@ericsson.com> Date: Mon, 14 Dec 2020 19:51:46 -0800 Cc: Yoshifumi Nishida , "Scharf, Michael" , tcpm IETF list Message-Id: <67892C2A-2D3F-4C25-B071-ADAE95A6AC52@strayalpha.com> References: <160634544894.28725.8891473900084027588@ietfa.amsl.com> <7F478CFF-A60E-4513-AFCB-1DEE985F9880@ifi.uio.no> <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> <6338D8C5-6485-47A3-ACB3-73DC7F641488@ericsson.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 03:51:53 -0000 --Apple-Mail=_D40A3DE1-9390-4CD4-8994-C4434A864A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To the WG: > On Dec 14, 2020, at 2:56 AM, Mirja Kuehlewind = wrote: >=20 > I=E2=80=99m also still concerned about the appendix. I think a link to = the expired draft and some summary discussion would be sufficient rather = than copying the whole expired draft in the appendix that never reached = any consensus in the group. We have addressed these comments before and disagree with them. The material was available to the WG for several months and has received = no objections except Mirja's during WGLC and Youshifumi=E2=80=99s now = many months after WGLC. The content of expired I-Ds can be removed from public view at any time, = per: https://ietf.org/about/groups/iesg/statements/internet-draft-removal/ = Finally, see the *explicit* instructions in the required boilerplate of = every I-D: ...It is inappropriate to use Internet-Drafts as reference material ... I will let my co-authors address how to proceed. Joe= --Apple-Mail=_D40A3DE1-9390-4CD4-8994-C4434A864A0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = the WG:

On Dec 14, 2020, at 2:56 AM, Mirja Kuehlewind = <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> = wrote:

I=E2=80=99m also = still concerned about the appendix. I think a link to the expired draft = and some summary discussion would be sufficient rather than copying the = whole expired draft in the appendix that never reached any consensus in = the group.

We have addressed these comments before and = disagree with them.

The material was = available to the WG for several months and has received no objections = except Mirja's during WGLC and Youshifumi=E2=80=99s now many months = after WGLC.

The content of expired = I-Ds can be removed from public view at any time, per:

Finally, see the = *explicit* instructions in the required boilerplate of every = I-D:

	...It is =
inappropriate to use Internet-Drafts as
   reference material ...

I will let my co-authors address how to proceed.

Joe
= --Apple-Mail=_D40A3DE1-9390-4CD4-8994-C4434A864A0D-- From nobody Tue Dec 15 00:15:26 2020 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 BD3373A0E31; Tue, 15 Dec 2020 00:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 D-BV2hK0HjlH; Tue, 15 Dec 2020 00:15:22 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 458733A0E2F; Tue, 15 Dec 2020 00:15:21 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kp5UN-0005R9-4E; Tue, 15 Dec 2020 09:15:19 +0100 Received: from ti0182q160-1994.bb.online.no ([212.251.170.224] helo=[192.168.1.11]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kp5UL-00095F-Tl; Tue, 15 Dec 2020 09:15:19 +0100 From: Michael Welzl Message-Id: <1752C5EA-6500-4C1E-B8DB-65F5E5F049CB@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_DEECF238-E35B-40A5-BAB0-89A20510DC9F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 15 Dec 2020 09:15:16 +0100 In-Reply-To: <67892C2A-2D3F-4C25-B071-ADAE95A6AC52@strayalpha.com> Cc: Mirja Kuehlewind , tcpm IETF list To: Joseph Touch References: <160634544894.28725.8891473900084027588@ietfa.amsl.com> <7F478CFF-A60E-4513-AFCB-1DEE985F9880@ifi.uio.no> <94c8342fcda84ede98e0591867cd8933@hs-esslingen.de> <6338D8C5-6485-47A3-ACB3-73DC7F641488@ericsson.com> <67892C2A-2D3F-4C25-B071-ADAE95A6AC52@strayalpha.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 212.251.170.224 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.224; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.11]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 101EA869AC443BDC27741BD1F176E55AAA2998BF Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-06.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 08:15:25 -0000 --Apple-Mail=_DEECF238-E35B-40A5-BAB0-89A20510DC9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Dec 15, 2020, at 4:51 AM, Joseph Touch = wrote: >=20 > To the WG: >=20 >> On Dec 14, 2020, at 2:56 AM, Mirja Kuehlewind = > wrote: >>=20 >> I=E2=80=99m also still concerned about the appendix. I think a link = to the expired draft and some summary discussion would be sufficient = rather than copying the whole expired draft in the appendix that never = reached any consensus in the group. >=20 > We have addressed these comments before Indeed: this comment appears to refer to an earlier version of the = draft. > and disagree with them. >=20 > The material was available to the WG for several months and has = received no objections except Mirja's during WGLC and Youshifumi=E2=80=99s= now many months after WGLC. >=20 > The content of expired I-Ds can be removed from public view at any = time, per: > https://ietf.org/about/groups/iesg/statements/internet-draft-removal/ = >=20 > Finally, see the *explicit* instructions in the required boilerplate = of every I-D: >=20 > ...It is inappropriate to use Internet-Drafts as > reference material ... >=20 > I will let my co-authors address how to proceed. You made our position clear; the next steps are at the discretion of the = chairs at this point. Cheers, Michael --Apple-Mail=_DEECF238-E35B-40A5-BAB0-89A20510DC9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,


On Dec 15, 2020, at 4:51 AM, Joseph Touch <touch@strayalpha.com> wrote:

To the WG:

On Dec 14, 2020, at 2:56 AM, Mirja Kuehlewind = <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> = wrote:

I=E2=80=99m also = still concerned about the appendix. I think a link to the expired draft = and some summary discussion would be sufficient rather than copying the = whole expired draft in the appendix that never reached any consensus in = the group.

We have addressed these comments = before

Indeed: this comment appears to refer to an = earlier version of the draft.


and disagree with = them.

The = material was available to the WG for several months and has received no = objections except Mirja's during WGLC and Youshifumi=E2=80=99s now many = months after WGLC.

The content of expired I-Ds can be removed from public view = at any time, per:
https://ietf.org/about/groups/iesg/statements/internet-draft-re= moval/

Finally, see the *explicit* instructions in the required = boilerplate of every I-D:

	...It is =
inappropriate to use Internet-Drafts as
   reference material ...

I will let my co-authors address how to = proceed.

You= made our position clear; the next steps are at the discretion of the = chairs at this point.

Cheers,
Michael

= --Apple-Mail=_DEECF238-E35B-40A5-BAB0-89A20510DC9F-- From nobody Tue Dec 15 10:57:18 2020 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 5A3253A16C2; Tue, 15 Dec 2020 10:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_IMPORTANT=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 N-RScrSqbHYz; Tue, 15 Dec 2020 10:57:06 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F30C3A16BE; Tue, 15 Dec 2020 10:57:04 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Tue, 15 Dec 2020 20:56:51 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=LnxEuUZqghc89b9MG 3M14HyKZGK3KkkGOlDWBiTwmnI=; b=G2iKHf+QXRjMP9nXFc/QG4GTWGBq4TaS6 pQBsbuAo5ERb7XwqYUZKVt/kt46fC4FQ+ZJOJkMzG9p5M5rDOK8iwUPFua35jJ7Y f4rFdnsRiAcXMh84fWpy0zcRk7RTr838PzfILbuOQSkj5FvgkZlYn/GdAKdh5kGA NZvvsftMfA= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Tue, 15 Dec 2020 20:56:50 +0200 id 00000000005A01BC.000000005FD906F2.00004B8D Date: Tue, 15 Dec 2020 20:56:50 +0200 (EET) From: Markku Kojo To: Neal Cardwell cc: Yuchung Cheng , last-call@ietf.org, "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="US-ASCII" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 18:57:12 -0000 Hi Neal, all, (my apologies for this message getting so long but I didn't want to drop any parts of it in case someone wants to get the entire discussion in one piece. Also, apologies for repeating some of my concerns inline below; Those who are clear with the problems may well opt skipping those parts.) Thanks Neal for the reply. I believe we are slowly converging with many of my comments but two of the important issues still remain open. That is, where can an implementer find advice for correct congestion control actions with RACK-TLP, when: (1) a loss of rexmitted segment is detected (2) an entire flight of data gets dropped (and detected), that is, when there is no feedback available and a timeout is needed to detect the loss I fully understand the intent of the RACK-TLP draft not to include congestion control actions in this document (or the intent to minimise such advise). However, when new ways to detect loss are introduced and published (as this document would do), IMHO it is imperative to have such congestion control actions readily available for an implementer. AFAIK we do not have in the RFC series correct actions available for these two cases. I do not have a strong opinion whether the necessary actions should be in this document or in another document, as long as we have them. This is more or less a process decision, I think. Please see more details inline. I also investigated a bit more on RACK-TLP as specified in the draft and it seems that there is a problem with the pseudocode as currently presented (some sequence numbers seem to be off by one, resulting in wrong outcome in some/many? cases). Please see inline in the end of my reply. On Sat, 12 Dec 2020, Neal Cardwell wrote: > Hi Markku, > > Thanks for your many detailed and thoughtful comments. Please see > below in-line for our comments based on discussions among RACK-TLP > draft authors. > > On Tue, Dec 8, 2020 at 11:21 AM Markku Kojo wrote: >> >> Hi, >> >> please see inline. >> >> On Mon, 7 Dec 2020, Yuchung Cheng wrote: >> >>> On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo wrote: >>>> >>>> Hi Yuchung, >>>> >>>> thanks for your reply. My major point is that IMHO this RACK-TLP >>>> specification should give the necessary advice w.r.t congestion control >>>> in cases when such advice is not available in the RFC series or is not >>>> that easy to interpreted correctly from the existing RFCs. >>>> >>>> Even though the CC principles were available in RFC series I believe you >>>> agree with me that getting detailed CC actions correct is sometimes quite >>>> hard, especially if one needs to interpret and apply them from another >>>> spec than what one is implementing. Please see more details inline below. >>>> >>>> In addition, we need to remember that this document is not meant only for >>>> TCP experts following the tcpm list and having deep understanding of >>>> congestion control but also those implementing TCP, for the very first >>>> time, for various appliances, for example. They do not have first hand >>>> experience in implementing TCP congestion control and deserve clear >>>> advice what to do. >>>> >>>> On Fri, 4 Dec 2020, Yuchung Cheng wrote: >>>> >>>>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I know this is a bit late but I didn't have time earlier to take look at >>>>>> this draft. >>>>>> >>>>>> Given that this RFC to be is standards track and RECOMMENDED to replace >>>>>> current DupAck-based loss detection, it is important that the spec is >>>>>> clear on its advice to those implementing it. Current text seems to >>>>>> lack important advice w.r.t congestion control, and even though >>>>>> the spec tries to decouple loss detection from congestion control >>>>>> and does not intend to modify existing standard congestion control >>>>>> some of the examples advice incorrect congestion control actions. >>>>>> Therefore, I think it is worth to correct the mistakes and take >>>>>> yet another look at a few implications of this specification. >>>>> As you noted, the intention is to decouple the two as much as possible >>>>> >>>>> Unlike the 20 years ago where TCP loss detection and congestion >>>>> control are essentially glued in one piece, the decoupling of the two >>>>> (including modularizing congestion controls in implementations) has >>>>> helped fueled many great inventions of new congestion controls. >>>>> Codifying so-called-default C.C. reactions in the loss detection is a >>>>> step backward that the authors try their best to avoid. >>>> >>>> While I fully agree with the general principle of decoupling loss >>>> detection from congestion control when it is possible without leaving >>>> open questions, I find it hard to get congestion control right with this >>>> spec in certain cases I raised just by following the current standards >>>> track CC specifications. The reason for this is that RACK-TLP introduces >>>> new ways to detect loss (i.e., not present in any earlier standard track >>>> RFC) and the current CC specifications do not provide correct CC actions >>>> for such cases as I try to point out below. >>>> >>>>> To keep the >>>>> document less "abstract / unclear" as many WGLC reviewers commented, >>>>> we use examples to illustrate that includes CC actions. But the >>>>> details of these CC actions are likely to become obsolete as CC >>>>> continues to advance hopefully. >>>> >>>> Agreed. But I would appreciate if the CC actions in the examples would >>>> correctly follow what is specified in the the current CC RFCs. And, I >>>> would suggest explicitly citing the RFC(s) that each of the examples is >>>> illustriating so that there is no doubt which CC variant the example >>>> is valid with. Then there is no problem with the correctness of the >>>> example either even if the cited RFC becomes later obsoleted. >>>> >>>>>> >>>>>> Sec. 3.4 (and elsewhere when discussing recovering a dropped >>>>>> retransmission): >>>>>> >>>>>> It is very useful that RACK-TLP allows for recovering dropped rexmits. >>>>>> However, it seems that the spec ignores the fact that loss of a >>>>>> retransmission is a loss in a successive window that requires reacting >>>>>> to congestion twice as per RFC 5681. This advice must be included in >>>>>> the specification because with RACK-TLP recovery of dropped rexmit >>>>>> takes place during the fast recovery which is very different >>>>>> from the other standard algorithms and therefore easy to miss >>>>>> when implementing this spec. >>>>> >>>>> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 >>>>> "Loss in two successive windows of data, or the loss of a >>>>> retransmission, should be taken as two indications of congestion and, >>>>> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." >>>>> >>>>> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on >>>>> this so I am not sure what clause you suggest to add to RACK-TLP. >>>> >>>> Right, this is the CC *principle* in RFC 5681 I am refering to but I am >>>> afraid it is not enough to help one to correctly implement such lowering >>>> of cwnd (and ssthresh) twice when a loss of a retransmission is detected >>>> during Fast Recovery. Nor do RFCs clearly advice *when* this reduction >>>> must take place. >>>> >>>> Congestion control principles tell us that congestion must be reacted >>>> immediately when detected. But at the same time, standards track CC >>>> specifications react to congestion only once during Fast Recovery >>>> because the losses in the current window, which Fast Recovery repairs, >>>> occured during the same RTT. That is, the current CC specifications do >>>> not handle lost rexmits during Fast Recovery but, instead, the correct CC >>>> reaction to a loss of a rexmit is automatically achieved by those >>>> specifications via RTO when cwnd is explicitly reset upon RTO. >>>> >>>> Furthermore, the problem I am trying to point out is that there is no >>>> correct rule/formula available in the standards track RFCs that would >>>> give the correct way to reduce cwnd when the loss of rexmit is detected >>>> with RACK-TLP. >>>> >>>> I suggest everyone reading this message stops reading at this point >>>> for a while before continuing reading and figures out themselves what >>>> they think would be the correct equation to use in the standards RFC >>>> series to find the new halved value for cwnd when RACK-TLP detects a loss >>>> of a rexmit during Fast Recovery. I would appreciate a comment on the >>>> tcpm list from those who think they found the correct answer immediately >>>> and easily, and what was the formula to use. >>>> >>>> ... >>>> >>>> I think the best advice one may find by looking at RFC 6675 (and RFC >>>> 5681) is to set >>>> >>>> ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step 4.2) >>>> >>>> Now, let's modify the example in Sec 3.4 of the draft: >>>> >>>> 1. Send P0, P1, P2, ..., P20 >>>> [Assume P1, ..., P20 dropped by network] >>>> >>>> 2. Receive P0, ACK P0 >>>> 3a. 2RTTs after (2), TLP timer fires >>>> 3b. TLP: retransmits P20 >>>> ... >>>> 5a. Receive SACK for P20 >>>> 5b. RACK: marks P1, ..., P20 lost >>>> set cwnd=ssthresh=FlightSize/2=10 >>>> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) >>>> [P1 retransmission dropped by network] >>>> >>>> Receive SACK P2 & P3 >>>> 7a. RACK: marks P1 retransmission lost >>>> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 >>>> 7b. Retransmit P1 >>>> ... >>>> >>>> So, is the new value of the cwnd (10MSS) correct and halved twice? If not, >>>> where is the correct formula to do it? >>>> >>>> Before RFC 5681 was published we had a discussion on FlighSize and that >>>> during Fast Recovery it does not reflect the amount of segments in >>>> flight correctly but may also have a too large value. It was decided not >>>> to try to correct it because it only has an impact when RTO fires during >>>> Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too large >>>> ssthresh for RTO recovery in some cases was not considered that bad >>>> because a TCP sender anyway takes to most conservative CC action with the >>>> cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP enables >>>> detecting loss of a rexmit during Fast Recovery we have an unresolved >>>> problem. >>> >>>> 1. Send P0, P1, P2, ..., P20 >>>> [Assume P1, ..., P20 dropped by network] >>>> >>>> 2. Receive P0, ACK P0 >>>> 3a. 2RTTs after (2), TLP timer fires >>>> 3b. TLP: retransmits P20 >>>> ... >>>> 5a. Receive SACK for P20 >>>> 5b. RACK: marks P1, ..., P20 lost >>>> set cwnd=ssthresh=FlightSize/2=10 >>>> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) >>>> [P1 retransmission dropped by network] >>>> >>>> Receive SACK P2 & P3 >>>> 7a. RACK: marks P1 retransmission lost >>>> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 >>>> 7b. Retransmit P1 >>> >>> To account for your points, IMO clearly stating the existing CC RFC >>> interactions w/o mandating any C.C. actions are the best way to move >>> forward. Here are the text diff I proposed: >>> >>> "Figure 1, above, illustrates ... >>> Notice a subtle interaction with existing congestion control actions >>> on event 7a. It essentially starts another new episode of congestion >>> due to the detection of lost retransmission. Per RFC5681 (section 4.3) >>> that loss in two successive windows of data, or the loss of a >>> retransmission, should be taken as two indications of congestion as a >>> principle. But RFC6675 that introduces the pipe concept does not >>> specify such a second window reduction. This document reminds RACK-TLP >> >> This is not quite correct characterization of RFC 6675. >> RFC 6675 does not repeat all guidelines of RFC 5681. RFC 6675 DOES specify >> the two indications of congestion implicitly by clearly stating in the >> intro that it follows the guidelines set in RFC 5681. >> And RFC 5681 articulates a set of MUSTs which ALL alternative loss >> recovery algorithms MUST follow in order to become RFCs. >> >> (*) RFC 5681, Sec 4.3 (pp. 12-13): >> >> "While this document does not standardize any of the >> specific algorithms that may improve fast retransmit/fast recovery, >> ... >> That is, ... >> Loss in two successive windows of data, or the loss of a >> retransmission, should be taken as two indications of congestion and, >> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." >> >> >>> implementation to carefully consider the new multiple congestion >>> episode cases in the corresponding congestion control." >> >> I am sorry to say that this is very fuzzy and leaves an implementer >> all alone what to do. >> >> More inportantly, AFAIK we have no discussion nor consensus in the IETF >> on what is the correct CC action when lost rexmit is detected. >> Should one reset cwnd like current CCs do, or would "halving again" be >> fine, or something else? IMHO this requires experimentation to decide. >> >> I assumed there is an implementation of RACK-TLP with corresponding CC >> actions and experimental results to devise what are the implications of >> the selected CC action(s) with various levels of congestion. But it seems >> we do not have such implementation nor experimental evidence? Am I wrong? > > [RACK-TLP-team:] > > We do have such implementations of RACK-TLP with corresponding CC > actions, and experimental results were reported in RACK-TLP > presentations and earlier revisions of the RACK-TLP draft. With Yes, that was my understanding what is implemented. Given there is this implementation that reacts appropriately to congestion when RACK-TLP detects loss of a retransmitted segment, could you please illuminate the congestion control actions taken in the implementation with which there is experimental experience. If I understood it correctly, the RACK-TLP in question is implemented with PRR. Let's assume another implementer wants to add RACK-TLP with PRR in the stack she/he is working on. I believe that the implementer would think that detecting a loss of a rexmit during fast recovery would start a new congestion episode in PRR (and that's what Yuchung also indicated in the new proposed text in his previeous reply shown above). With that advice and reading RFC 6937, an implementer would reinitialize PRR state for the new congestion episode. So how should the implementer calculate new values for ssthresh and RecoverFS? Should she/he use what is currently described in RFC 6937, Sec 3 (to keep discussion simple assume the implementer wants to have an IETF Standards Track comformant implementation, so use CongCtrlAlg() = FlightSize/2): ssthresh = CongCtrlAlg() // Target cwnd after recovery prr_delivered = 0 // Total bytes delivered during recovery prr_out = 0 // Total bytes sent during recovery RecoverFS = snd.nxt-snd.una // FlightSize at the start of recovery Or should one use something else? AFAIK depending on the loss pattern neither FlightSize nor "snd.nxt-snd.una" would give correct values for the intended behavior. Depending on the loss pattern, at the time of detecting a loss of rexmit FlighSize may be ~ 50% larger than in the beginning of fast recovery. This would result in increasing ssthresh (send rate), instead of decreasing it. It seems that something else in PRR algo would also need to be modified to get sndcnt correct but I cannot figure it out right now. If one wants to implement RACK-TLP without PRR, that is, with RFC 6675, we have the same probelm with FlightSize in determining a new value for cwnd and ssthresh. My point is that using what we currently have out there in the RFC series gives incorrect CC advice. And, having correct CC actions in this case is far from trivial so IMHO high quality standards specifications should not leave an implementer of RACK-TLP alone to figure it out. In addition, if a new episode of fast recovery is started for CC purposes how would that play together with RACK-TLP loss detection? In Sec 7.1 the text says initialize (reset) TLP.end_seq and TLP.is_retrans when initiating fast recovery. But detecting a lost rexmit seemingly should not reinitialize TLP because PTO is disabled during fast recovery as per Sec 7.2. If CC actions are in another document and loss detection in this document, it would be of high importance to clarify when each of the fast recovery episodies (CC vs. loss detection) are supposed to end: is the end condition the same or different? > respect to implementations, there is the Linux TCP stack, which has > been using RACK-TLP as the default loss recovery algorithm since Linux > v4.18 in August 2018. The exact commit is: > > b38a51fec1c1 tcp: disable RFC6675 loss detection > > With Linux, the default sender behavior since that commit has been > governed by CUBIC, PRR, and RACK-TLP. > > RACK-TLP is used by all Google TCP traffic, including internal RPC > traffic and external YouTube and google.com traffic over the public > Internet. At Google we have years of high-traffic-volume experience > with RACK-TLP with three different CC schemes: CUBIC+PRR, BBRv1, and > BBRv2. > > My understanding is that Netflix FreeBSD TCP traffic uses RACK-TLP, > and Microsoft Windows TCP traffic has also been using RACK-TLP. And I wonder what would be the CC actions taken in each of these implementations when a loss of rexmited segment is detected? >> I sincerely apologize that this got raised this late in the prosess and >> I know how irritating it may be. I like the idea of RACK-TLP and by no >> means my intention is not to hold up the process but the lack of evidence >> makes me quite concerned. In particular, when this document says that >> the current loss detection SHOULD be replaced in all implementations with >> RACK-TLP. >> >>> and to emphasize in section 9.3 Interaction with congestion control >>> >>> "9.3. Interaction with congestion control >>> >>> RACK-TLP intentionally decouples loss detection ... this appropriate. >>> As mentioned in Figure 1 caption, RFC5681 mandates a principle that >>> Loss in two successive windows of data, or the loss of a >>> retransmission, should be taken as two indications of congestion, and >>> therefore reacted separately. However implementation of RFC6675 pipe >>> algorithm may not directly account for this newly detected congestion >>> events properly. Therefore the documents reminds RACK-TLP >>> implementation to carefully consider these implications in its >>> corresponding congestion control. >>> >>> ..." >>> >>> >>> >>>> >>>> >>>>>> Sec 9.3: >>>>>> >>>>>> In Section 9.3 it is stated that the only modification to the existing >>>>>> congestion control algorithms is that one outstanding loss probe >>>>>> can be sent even if the congestion window is fully used. This is >>>>>> fine, but the spec lacks the advice that if a new data segment is sent >>>>>> this extra segment MUST NOT be included when calculating the new value >>>>>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an >>>>>> extra segment not allowed by cwnd, so it must be excluded from >>>>>> FlightSize, if the TLP probe detects loss or if there is no ack >>>>>> and RTO is needed to trigger loss recovery. >>>>> >>>>> Why exclude TLP (or any data) from FlightSize? The congestion control >>>>> needs precise accounting of the flight size to react to congestion >>>>> properly. >>>> >>>> Because FlightSize does not always reflect the correct amount of data >>>> allowed by cwnd. When a TCP sender is not already in loss recovery and >>>> it detects loss, this loss indicates the congestion point for the TCP >>>> sender, i.e., how much data it can have outstanding. It is this amount of >>>> data that it must use in calculating the new value of cwnd (and >>>> ssthresh), so it must not include any data sent beyond the congestion >>>> point. When TLP sends a new data segment, it is beyond the congestion >>>> point and must not be included. Same holds for the segments sent via >>>> Limited Transmit: they are allowed to be send out by the packet >>>> conservation rule (DupAck indicates a pkt has left the network, but does >>>> not allow increasing cwnd), i.e., the actual amount of data in flight >>>> remains the same. >>>> >>>>>> In these cases the temporary over-commit is not accounted for as DupAck >>>>>> does not decrease FlightSize and in case of an RTO the next ACK comes too >>>>>> late. This is similar to the rule in RFC 5681 and RFC 6675 that prohibits >>>>>> including the segments transmitted via Limitid Transmit in the >>>>>> calculation of ssthresh. >>>>>> >>>>>> In Section 9.3 a few example scenarios are used to illustriate the >>>>>> intended operation of RACK-TLP. >>>>>> >>>>>> In the first example a sender has a congestion window (cwnd) of 20 >>>>>> segments on a SACK-enabled connection. It sends 10 data segments >>>>>> and all of them are lost. >>>>>> >>>>>> The text claims that without RACK-TLP the ending cwnd would be 4 segments >>>>>> due to congestion window validation. This is incorrect. >>>>>> As per RFC 7661 the sender MUST exit the non-validated phase upon an >>>>>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 segments if >>>>>> the TCP sender uses the equation (4) of RFC 5681). >>>>>> >>>>>> The operation with RACK-TLP would inevitably result in congestion >>>>>> collapse if RACK-TLP behaves as described in the example because >>>>>> it restores the previous cwnd of 10 segments after the fast recovery >>>>>> and would not react to congestion at all! I think this is not the >>>>>> intended behavior by this spec but a mistake in the example. >>>>>> The ssthresh calculated in the beginning of loss recovery should >>>>>> be 5 segments as per RFC 6675 (and RFC 5681). >>>>> To clarify, would this text look more clear? >>>>> >>>>> 'an ending cwnd set to the slow start threshold of 5 segments (half of >>>>> the original congestion window of 10 segments)' >>>> >>>> This is correct, but please replace: >>>> >>>> (half of the original congestion window of 10 segments) >>>> --> >>>> (half of> the original FlightSize of 10 segments) >>> >>> sure will do >>> >>>> >>>> cwnd in the example was 20 segments. >>>> >>>> Please also correct the ending cwnd for "without RACK" scenario. >>>> I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd value, >>>> my apologies. It MAENT equation (3) AND that results in ending cwnd of 5 >>>> and 2/5 MSS (not 5 and 1/2 MSS). >>>> NB: and if a TCP sender implements entering CA when cwnd > ssthresh, then >>>> ending cwnd would be 6 and 1/6 MSS). >>>> >>>>>> >>>>>> Furthermore, it seems that this example with RACK-TLP refers to using >>>>>> PRR_SSRB which effectively implements regular slow start in this >>>>>> case(?). From congestion control point of view this is correct because >>>>>> the entire flight of data as well as ack clock was lost. >>>>>> >>>>>> However, as correctly discussed in Sec 2, congestion window must be reset >>>>>> to 1 MSS when an entire flight of data is and Ack clock is lost. But how >>>>>> can an implementor know what to do if she/he is not implementing the >>>>>> experimental PRR algrorithm? This spec articulates specifying an >>>>>> alternative for DupAck counting, indicating that TLP is used to trigger >>>>>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow start. >>>>>> This means that without an additional advise an implementation of this >>>>>> spec would just halve the cwnd and ssthresh and send a potentially very >>>>>> large burst of segments in the beginning of the Fast Recovery because >>>>>> there is no ack clock. So, this spec begs for an advise (MUST) when to >>>>>> slow start and reset cwnd and when not, or at least a discussion of >>>>>> this problem and some sort of advise what to do and what to avoid. >>>>>> And, maybe a recommendation to implement it with PRR? >>>>> >>>>> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst >>>>> control (when to slow-start). The use of PRR is just an example to >>>>> illustrate and not meant for a recommendation. >>>> >>>> I understand the use of PRR was just an example, but my point is that if >>>> one wants to implement RACK-TLP but does not intend to implement PRR but >>>> RFC 6675 then we do not have a rule in RFC 6675 to correctly implement >>>> CC for the case when an entire flight is lost and loss is detected with >>>> TLP. Congestion control principle for this is clear and also stated in >>>> this draft but IMHO it is not enough to ensure correct implementation. >>>> >>>> To my understanding we only have implementation experience for RACK-TLP >>>> only togerher with PRR, which has the necessary rule to handle this kind >>>> of scenario correctly. >>>> >>>> So, my question is how can one implement CC correctly without PRR such >>>> a scenario where entire inflight is lost? >>>> Which rule and where in the RFC series gives the necessary guidance to >>>> reset cwnd and slow start when TCP detets loss of an entire flight? >>> >>> I think we're going in loops. To move forward it'd help if you suggest >>> some text you like to change. >> >> Unfortunately I do not have an immediate solution. I assumed there is an >> implementation and you could enlighten what was the solution there and >> experimental results showing how it seems to work. If I have understood >> it correctly there is a solution/implementation and experience of RACK-TLP >> that works together with PRR but no solution/implementation nor experience >> how it works without PRR. Am I correct? > > [RACK-TLP-team:] > > The implementation solutions and experiments were mentioned above. Our > team's experience is with RACK-TLP in combination with either > CUBIC+PRR, BBRv1, and BBRv2. We are not sure if there are other TCP > implementations that implement RACK-TLP without PRR. So, in addition to the lack of experimental evidence using RACK-TLP without PRR we have a specification problem for which we have no answer: The RACK-TLP text suggests that if PTO fires and TLP detects a loss, the TCP sender enters fast recovery. But PTO = timeout that expires if there is no feedback (ACKs) from the network, i.e., entire flight of data is lost. TLP = a single segment that is sent when timer expires. What is different compared to RTO is that PTO may expire faster and a different segment is (re)transmitted, allowing to detect more than one lost segment with a single Ack w/ SACK triggered by TLP (with regular RTO recovery only the next unacknowledged segment can reliably be considered lost) >From congestion control point of view this means that PTO is no different from RTO. The congestion control principle as stated in Sec 2.2 of this document tells us that a loss of entire flight deserves a cautious response, i.e., reset cwnd and slow start. When RACK-TLP is implemented with PRR we have appropriate CC actions specified in RFC 6937 that effectively reset cwnd and force the TCP sender to slow start, even though it tecnically enters fast recovery. This is safe. However, if an implementer wants to implement RACK-TLP without PRR, she/he has to consult RFC 6675 which gives an incorrect CC response for this case, resulting in an unsafe implementation. The problem is not in the fast recovery algorithm in RFC 6675 because it was not intended to be initiated with TLP-kind of loss detection. So the question is how to ensure an implementer has the necessary advice to implement correct congestion control actions for RACK-TLP once this document is published. The lack of correct advice becomes even more prominent as this document requires (all SACK capable) TCPs to implement RACK-TLP. >> Given my understanding of PRR, the problem of an entire flight being >> dropped is quite nicely solved with it. However, implementing RACK-TLP >> without PRR begs for a solution. Here is my current understanding: >> >> (1) RACK part is what can be called to "replace" DupAck counting >> (2) TLP part is effectively a new retransmission timeout to detect >> a loss of an entire flight of data (i.e., it is only invoked >> when a tail of the current flight becomes lost which equals to >> the case of losing an entire flight since all segments before >> the tail loss will get cumulatively Acked and hence these segments >> are not anymore a part of the current flight at the time the loss >> is detected. And we an assume application limited TCP sender. >> (3) Current CC principles require resetting cwnd in such a case >> and entering slow start (and so effectively does PRR though it is >> not explicitly stated in RFC 6937). Slow start avoids a big burst >> if the lost flight is big. >> (4) RACK-TLP would possibly like to allow that cwnd is set to a half >> of the lost flight and not to slow start. This means that the bigger >> the lost flight is, the bigger is the burst that gets transmitted at >> the beginning of the recovery which is bad. So, this approach would >> need at least a rule/advice for burst avoidance (slow start, pacing, >> ...). >> (5) When the lost flight is small (<= 4 segments) there is no difference >> in recovery efficiency between (3) and (4). If the lost flight is >> > 5 segments, then (4) takes less RTTs to complete the recovery >> but generates a burst. Note, even if pacing over one SRTT would be >> used, it is still a burst. >> >> Now, it would be useful to have experimental data to know how the size of >> the lost flight is distributed. Is it typically just a few segments as >> illustriated in the examples of the draft or is it often larger? >> >> My advice would be to add a rule that cwnd MUST be reset to 1 MSS >> and the sender MUST enter slow start if TLP detects loss of an entire >> flight. This would be safe. Otherwise, without experimental evidence from >> a wide range of different network conditions and workloads it feels >> unsafe to allow more aggressive approach. > > [RACK-TLP-team:] > > Our team's position is that the RACK-TLP draft documents a loss > detection algorithm, and normative declarations about congestion > control behavior (like your "cwnd MUST be reset to 1 MSS", above) > should be in a separate document focused on congestion control. I do not disagree with you what becomes to the role of congestion control in the RACK-TLP draft. It may well be in another document but IMHO such document must be available at the time this docment gets published. How can we otherwise ensure correct implementations? So this is more of a process question than critique towards the draft. >>>>> Section 3 has a lengthy section to elaborate the key point of RACK-TLP >>>>> is to maximize the chance of fast recovery. How C.C. governs the >>>>> transmission dynamics after losses are detected are out of scope of >>>>> this document in our authors' opinions. >>>>> >>>>> >>>>>> >>>>>> Another question relates to the use of TLP and adjusting timer(s) upon >>>>>> timeout. In the same example discussed above, it is clear that PTO >>>>>> that fires TLP is just a more aggressive retransmit timer with >>>>>> an alternative data segment to (re)transmit. >>>>>> >>>>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it is in >>>>>> effect a retransmission timout and the timer(s) must be backed-off. >>>>>> This is not adviced in this specification. Whether it is the TCP RTO >>>>>> or PTO that should be backed-off is an open question. Otherwise, >>>>>> if the congestion is persistent and further transmission are also lost, >>>>>> RACK-TLP would not react to congestion properly but would keep >>>>>> retransmitting with "constant" timer value because new RTT estimate >>>>>> cannot be obtained. >>>>>> On a buffer bloated and heavily congested bottleneck this would easily >>>>>> result in sending at least one unnecessary retransmission per one >>>>>> delivered segment which is not advisable (e.g., when there are a huge >>>>>> number of applications sharing a constrained bottleneck and these >>>>>> applications are sending only one (or a few) segments and then >>>>>> waiting for an reply from the peer before sending another request). >>>>> >>>>> Thanks for pointing to the RFC. After TLP, RTO timers will >>>>> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 >>>>> (didn't find 9.1 relevant). >>>> >>>> My apologies for refering to the wrong section of RFC 2914, Yes, I meant >>>> Sec 9.3. >>>> >>>>> In your scenario, you presuppose the >>>>> retransmission is unnecessary so obviously TLP is not good. Consider >>>>> what happens without TLP where all the senders fire RTO spuriously and >>>>> blow up the network. It is equally unfortunate behavior. "bdp >>>>> insufficient of many flows" is a congestion control problem >>>> >>>> If (without TLP) RTO is spurious, it may result in unnecessary >>>> retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to >>>> detect and resolve it without TLP, so I don't find it as a problem. >>>> >>>> To clarify more, what I am concerned about. Think about a scenario where a >>>> (narrow) bottleneck becomes heavily congested by a huge number of >>>> competing senders such that the available capacity per sender is less >>>> than 1 segment (or << 1 MSS). >>>> This is a situation that network first enters before congestion collapse >>>> gets realized. So, it is extremely important that all CC and timer >>>> mechanisms handle it properly. Regular TCP handles it via RFC 6298 by >>>> backing off RTO expotentially and keeping this backed-off RTO until an >>>> new ACK is received for new data. This saves RACK-TLP from full congestion >>>> collapse. But consider what happens: even though RTO is backed off, each >>>> time a TCP sender manages to get one segment through (with cwnd = 1 MSS) >>>> it always first arms PTO with more or less constant value of 2*SRTT. If >>>> the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT and >>>> TLP becomes spurious. After a spurious TLP, RTO expires (maybe more than >>>> once before exponential back-off of RTO results in large enough value) >>>> and a new RTT sample is not received. So, SRTT remains unchanged and even >>>> if sometimes a new sample is received, SRTT gets very slowly adjusted. As >>>> a result, each TCP sender would keep on sending a spurious TLP for each >>>> new segment resulting in at least 50% of the packets being unnecessary >>>> rexmitted and the utilization of the bottleneck is < 50%. This would not >>>> be a full congestion collapse but has unwanted symptoms towards >>>> congestion collapse (Note: there is no clear line for the level of >>>> reduction in delivery of useful data is considered as congestion >>>> collapse). >>> >>> AFAIK you are saying: under extreme congestion shared by many short >>> flows, RACK-TLP can cause more packet losses because of the more >>> aggressive PTO timer. I agree and can add this to the "section 9.3". >> >> No, that was not what I meant. This happens simply when enough flows are >> competing on the same bottleneck. It may be long flows or maybe >> applications with more or less continuous request-reply exhanges. >> E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is 500msecs and PMTU >> is 1500B, then a bit over 40 simultaneous flows would mean that the >> bottleneck becomes fully utilized with the equal share of roughly 1 MSS >> per flow. With a quite typical bottleneck buffer size roughly equaling to >> BDP, about 80+ flows would fill up the buffer as well and increase >> RTT >= 1 secs. A buffer bloated bottleneck buffer would mean even larger >> RTT and allow more flows sharing the bottleneck without loss. >> >> If the number of TCP flows is > 90 (or >> 90) RACK-TLP would ends up >> (almost) always unnecessarily retransmitting each new segment once (PTO >> being 1 sec or around 1 sec). RTO back-off after a few rounds saves each >> TCP sender from additional unnecessary rexmits but still ~ 50% of the >> deivered packets are not making any useful progress. >> >> If the bottleneck buffer is small, it would result in more losses as you >> suggest but would not be that much of problem because majority of the >> unnecessary rexmits would not get delivered over the bottleneck link. >> Instead, they wuold get dropped at the bottleneck. Unnecessary rexmits >> would just create extra load on the poth before the bottleneck (which of >> course is not a non-problem either). > > [RACK-TLP-team:] > > If we are correctly understanding the scenario you are outlining, the > PTO would likely not be 1 sec in this case. In this scenario, the RTT > is around 1sec, so the PTO would be around 2*srtt, which would be > around 2 secs. With a 1sec RTT, and even considering delayed ACKs, it > seems very unlikely that a 2 sec PTO would cause a significant number > of unnecessary TLP probes. Well. Roughly the first initiated 40 flows will have SRTT ~ 0.5 sec. If next ~ 40 flows arrive within an RTT or so they will get RTT samples roughly between 0.5 - 1.x secs. The rest 80 - N hundreds flows will not get an RTT sample and will use initial/default PTO = 1 sec (unless using timestamps). The larger the buffer bloat the worse things get. Once ~200 flows are competing over the bottleneck, RTT will be well beyond 2 secs and grows when more flows join, guaranteeing spurious TLP for each new segment (unless timestamps are in use). > Perhaps your postulated PTO of 1 sec is coming from the pseudocode > path in TLP_calc_PTO() where, if SRTT is not available, the PTO is 1 > second? However, this case where there is no SRTT only happens if (a) > the connection is *not* using TCP timestamps (enabled for most > connections on the public Internet, due to default-enabled support in > Linux/Android and iOS/MacOS), and (b) the connection has *never* had a > single RTT sample from a non-retransmitted packet. To meet both of > those conditions is quite rare in practice. Is this the path that is > causing your concerns about a PTO of 1 sec? Sure. Having timestamps helps a lot in case the bottleneck buffer is buffer bloated (though RTT sample will not include delayed Ack effect for rexmits that are immediately acked). But RACK-TLP does not require timestamps and there are a lot of TCP stacks out there in addition to Linux/Android and iOS/MacOS. And more are coming with IoT expansion, for example. In addition, it is quite suprising how old (mobile) devices many people are using, some of which are old enough and have not been eligible for an OS upgrade for many years. But my quick example scenario was just to illustriate the problem, maybe typical in some areas where the only Internet access is over a geostationary satellite connection and people quite likely not using mobile/cellular devices. And, I selected a buffer-bloated scenario because that generates unnecessary rexmits which are a prerequisite for classical congestion collapse. It may well be in some environments that these hundreds of competing flows are application limited (request-reply continuously) and get started over a longer period of time, each getting RTT sample(s) over a lightly loaded bottleneck and then becoming idle or sending data only sporadically. Then later they all become active more or less at the same time (maybe by a common trigger). Base RTT may then be much lower than 500 ms as long as there is enough buffer bloat. Furthermore, timestamps are not that helpful in case of a heavily congested small buffer bottleneck. Having approximately accurate SRTT does not alone help in reducing the sending rate below 1 segment/RTT in heavily congested scenarios. Exponential backoff of timer is a must. I believe that either of us know what's really out there employing Internet for communication purposes. It does not matter whether it is a notable percentage or not as long there is a group of users who are encountering the envisioned problem. It may very well be a small minority, but if this kind of a problem escalates for this group very often (maybe almost always), it means we are disabling use of Internet technology for them. > Furthermore, in cases like this where the number of flows is roughly > equal to or greater than the BDP of the path, Reno/[RFC5681] and CUBIC > will spend the majority of their time in loss recovery (the minimum > ssthresh from [RFC5681] being 2*SMSS). Sure there is surprisingly lot to improve with TCP when the window needs to be kept lower than 2 MSS or when the available share would be even less than 1 MSS/RTT. RFC 5681 would exponentially back-off on every RTO, leaving opportunity for other flows to make progress during the backed-off interval. Once the sender is lucky and gets an Ack for a new segment, min ssthresh of 2*MSS unfortunately allows it to accelerate to 2*MSS/RTT and maybe more until RTO expires again. We cannot avoid some drops or unnecessary rexmits. Actually, in such a heavily congested scenario the combination of Karn's exponential back-off and slow start results in Multiplicative Increase Multiplicative Decrease (MIMD) behaviorwhich does not converge that well to fairness. But it avoids congestion collapse. It is kind a tradeoff between safe and stable behavior during heavy congestion and being able to ramp up fast when the congestion fades away. Even though the current behavior is not ideal for fairness, we should not make it even worse. Currently only way to avoid spending most of the time in loss recovery seems to be ECN that would make a TCP sender to become rate controlled once cwnd hits the minimum cwnd of 1 MSS(*). But there is a lot to optimise also with ECN in this kind of scenario ... (*) to avoid anyone repeating the misconception that minimum cwnd is 2 MSS per equation (4) in RFC 5681: equation (4) sets ssthresh, not cwnd. RFC 3168 clearly states that cwnd must be halved on an arrival of ECE; this holds until cwnd = 1 MSS. After this, the sending rate of new segments is (RTO) timer controlled and the timer avlue exponentially backed-off if more ECEs arrive. At least two major OSs implement this incorrectly unless now already fixed. > And the RACK-TLP ID specifies > that TLP probes are not sent while in loss recovery. Maybe I missed it but I couldn't find an end condition of RTO recovery for RACK-TLP purposes in the document. Regular RTO does not have such end condition because it is not needed. Congestion control and loss recovery are quite decoupled during RTO recovery; slow start follows its own rules and ends when cwnd > ssthresh and loss recovery has its own rules to select segments to rexmit and just moves on sending new data once all lost segments have been retransmitted. Some implementations may have such variable/condition but it didn't help me. Without timestamps, if TLP is not backed-off, a TLP is likely to be sent for each new segment (assuming certain conditions). Each not backed-off rexmit is potentially stealing an opportunity from another flow to get its segment being delivered, thereby contributing to unfair use of bottleneck resources. >>> What authors disagree is that RTO must be back-off on the first >>> instance if TLP is not acked. While your suggestion helps the >>> congestion case, it may also hurt the recovery in other cases when the >>> TLP is dropped due to light/burst/transient congestion. Arguing which >>> scenarios matter more subjectively is not productive. >> >> When RACK-TLP is required to be implemented by all TCP stacks, it >> is extremely important that it always works in a safe way and congestion >> is always the primary concern to get properly handled. Without arguing >> more, I just want to point out that TCP must work reasonably for all >> Internet users. That means it must not generate a situation where even a >> small minority of the Internet users often or almost always encounter >> severe problems with their connectivity. >> >> For example, also users in developing countries where possibly an entire >> village shares just one mobile (cellular, maybe 3G possibly only GPRS) >> connection for their Internet access and pays per amount of data should >> get reasonable TCP behavior. In such a case, I cannot agree with >> engineering that results in almost always getting only half of the >> already scarce bandwidth whle paying double price fot the useful data. >> >> But thinking about a way forward. Karn's algorithm would require backing >> off PTO even if you get Ack of PTO. Relaxing this does not sound me that >> bad at all, because there is often a pause before TLP and a TCP sender >> gets feedback, so apparently conditions are not that bad and loss >> recovery gets triggered (hopefully in slow start). >> If TLP is not acked, RTO is needed and recovery is completed in using RTO >> recovery in slow start. Now, if the RTO recovery is successful (no >> losses during RTO recovery), it should be quite likely that the TCP >> sender is able to successfully send also one new segment, because it >> enters CA when it is sending at the half of the previous rate. So, once >> you get Ack for the new segment, the TLP back off can be removed and it >> is unlikely that the TLP back off slowed down next loss detection. >> On the other hand, if the RTO recovery after an unsuccessful TLP is not >> successful (more losses are detected), it is quite likely that congestion >> has not been resolved. So, it is important to be conservative and have a >> backed-off PTO (or even turn it off) to avoid (further) unnecessary >> rexmits. If PTO is not backed of, I'd envision PTO mainly failing to get >> an Ack in such a case and thereby it not being that useful. >> >> This certainly would require experimental data in a heavily congested >> setting to really figure out the actual impact of different alternatives. >> >>> So the question we need to look at is if RACK-TLP 2RTT-PTO + regular >>> RTO-backoff is going to cause major stability issues in extreme >>> congestion. My understanding based on my officemate Van Jacobson's >>> explanation is, as long as there's eventual exponential backoff, we'll >>> avoid the repeated shelling the network. >> >> Right. But the problem is that with TLP as specified we do not have full >> exponential back off. It lacks Karn's clamped retransmit backoff (as it >> is called in Van Jacobson's seminal paper) which requires keeping >> backed-off timer of a retransmitted segment for the next (new) segment and >> ensures that there is eventual exponential backoff. >> Backing off just RTO is not enough, because "fixed" PTO for each new >> segment breaks this "back-off chain", that is, the exponential backoff >> is not continueed until there is evidence that congestion has been >> resolved (a cumulative Ack arrives for new data). But as I said, backing >> off RTO saves RACK-TLP from a full congestion collapse. Still, wasting >> 50% of the available network capacity in certain usage scenarios does not >> sound acceptable for me. > > [RACK-TLP-team:] > > To address concerns related to Karn's algorithm, perhaps it would be > sufficient to specify that after a RACK-TLP sender sends a TLP probe > that is a retransmitted segment, it temporarily disables further TLP > retransmissions until the sender obtains a valid RTT sample (i.e. from > a non-retransmitted segment, or a segment with [RFC7323] TCP > timestamps)? As a basic rule: disabling TLP probes for the period of loss recovery as currently specified sounds like a correct approach provided that the end condition "until the sender obtains a valid RTT sample" is added (this would be without timestamps, see some considerations with timestamps later below). Then some justification and maybe some exeptions can also be specified (all these without timestamps): If fast recovery is not entered via detecting loss using TLP, the sender does not need to wait for a valid RTT sample. It should be enough that RecoveryPoint is reached, i.e., use normal exit condition for fast recovery. However, I am not sure whether detecting a loss of a rexmit during fast recovery might change this? I think it does not matter whether a TLP probe is a retransmitted segment or not: (a) if there is no ack after TLP probe and RTO expires it should be clear that TLP must be disabled until an ack for a new previously not rexmitted segment is received, regardless of the probe segment sent by TLP. This is Karn's algorithm. (b) if TLP triggers an Ack that is used to detect a loss of an entire flight of data, this may later during loss recovery result in an RTO which definitely requires disabling TLP as per the basic rule. There might be some exeptions when the basic rule is not necessary but it is hard for me to figure one right now, except (c) if TLP rexmit detects and repairs a single loss, then CC is anyway invoked and Ack is received. If the arriving Ack is triggered by the TLP probe segment, it indicates that the conditions are likely not that bad (RTO not needed). So it might be ok, to rearm PTO for the next time without any backoff (without disbling it). However, (d) if TLP was spurious rexmit, then PTO value obviously was too low (effective RTT may have increased suddenly and Acks got just delayed). This is possibly detected only one RTT later when the DupAck of the TLP rexmit arrives. TLP may have got rearmed by that time again with too low value, so it should be rearmed with doubled value to avoid another spurious TLP PTO (or disabled). Then with timestamps. I think the simple rule for disabling TLP "until the sender obtains a valid RTT sample" is not necessarily giving the desired outcome in all cases. For example, if a TLP probe is send and then a late ack arrives for a segment sent before the TLP probe and gives a valid RTT sample with help of timestamps. This would allow a new TLP even though the sender has not got an Ack for a new segment sent after the TLP probe? So, also with timestamps the requirement must be that the sender obtains a valid RTT sample for a segment sent after the TLP probe. And, at least, if RTO recovery is entered, then the Ack must be for a new segment. Cannot figure out now all potential exceptions when a valid RTT sample with timestamps would allow re-enabling TLP earlier. Too complex algorithm with too many possible scenarios to investigate right now ;) A single, simple rule would be advisable here. Otherwise, this may end up being too complex to get it right. >>> As a matter of fact some >>> major TCP (!= Linux) implementation has implemented linear backoff of >>> first N RTOs before exp-backoff. >> >> But that's quite ok as long as there is eventual exponential backoff, >> including Karn's clamped retransmit backoff. Linear back-off in the >> beginning just makes resolving (heavy) congestion a bit slower. >> >>>> >>>>>> >>>>>> Additional notes: >>>>>> >>>>>> Sec 2.2: >>>>>> >>>>>> Example 2: >>>>>> "Lost retransmissions cause a resort to RTO recovery, since >>>>>> DUPACK-counting does not detect the loss of the retransmissions. >>>>>> Then the slow start after RTO recovery could cause burst losses >>>>>> again that severely degrades performance [POLICER16]." >>>>>> >>>>>> RTO reovery is done in slow start. The last sentence is confusing as >>>>>> there is no (new) slow-start after RTO recovery (or more precisely >>>>>> slow start continues until cwnd > ssthresh). Do you mean: if/when slow >>>>>> start still continues after RTO Recovery has repaired lost segments, >>>>>> it may cause burst losses again? >>>>> I mean the slow start after (the start of) RTO recovery. HTH >>>> >>>> Tnx. I'd appreciate if the text could be clarified to reflect this more >>>> accurately. Maybe something along the lines(?): >>>> >>>> "Then the RTO recovery in slow start could cause burst >>>> losses again that severely degrades performance [POLICER16]." >>>> >>>>>> >>>>>> Example 3: >>>>>> "If the reordering degree is beyond DupThresh, the DUPACK- >>>>>> counting can cause a spurious fast recovery and unnecessary >>>>>> congestion window reduction. To mitigate the issue, [RFC4653] >>>>>> adjusts DupThresh to half of the inflight size to tolerate the >>>>>> higher degree of reordering. However if more than half of the >>>>>> inflight is lost, then the sender has to resort to RTO recovery." >>>>>> >>>>>> This seems to be somewhat incorrect description of TCP-NCR specified in >>>>>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on sending >>>>>> new data segments on DupAcks that makes it likely to avoid an RTO in >>>>>> the given example scenario, if not too many of the the new data >>>>>> segments triggered by Extended Limited Transmit are lost. >>>>> sorry I don't see how the text is wrong describing RFC4653, >>>>> specifically the algorithm in adjusting ssthresh >>>> >>>> To my understanding RFC4653 initializes DupThresh to half of the inflight >>>> size in the beginning of the Extended Limited Transmit. Then on each >>>> DupAck it adjusts (recalculates) DupThresh again such that ideally a cwnd >>>> worth of DupAcks are received before packet loss is declared (or >>>> reordering detected). So, if I am not incorrect, loss of a half of the >>>> inflight does not necessarily result in RTO recovery with TCP-NCR. >>> Could you suggest the text you'd like on NCR description. >> >> I'm not an expert nor closely acquainted with NCR. There might be many >> different packet loss patterns that may affect the behavior. So, my >> advice is to simply drop the last sentence starting with "However ...", >> because it seems incorrect and replace the second but last sentence: >> >> To mitigate the issue, [RFC4653] >> adjusts DupThresh to half of the inflight size to tolerate the >> higher degree of reordering. >> >> --> >> >> To mitigate the issue, TCP-NCR [RFC4653] >> increases the DupThresh from the current fixed value of three duplicate >> ACKs [RFC5681] to approximately a congestion window of data having left >> the network. > > [RACK-TLP-team:] > > Sure, we will revise accordingly. Tnx. > >>>>>> >>>>>> Sec. 3.5: >>>>>> >>>>>> "For example, consider a simple case where one >>>>>> segment was sent with an RTO of 1 second, and then the application >>>>>> writes more data, causing a second and third segment to be sent right >>>>>> before the RTO of the first segment expires. Suppose only the first >>>>>> segment is lost. Without RACK, upon RTO expiration the sender marks >>>>>> all three segments as lost and retransmits the first segment. When >>>>>> the sender receives the ACK that selectively acknowledges the second >>>>>> segment, the sender spuriously retransmits the third segment." >>>>>> >>>>>> This seems incorrect. When the sender receives the ACK that selectively >>>>>> acknowledges the second segment, it is a DupAck as per RFC 6675 and does >>>>>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, the >>>>>> rexmit of the third segment is not allowad until the cumulative ACK of >>>>>> the first segment arrives. >>>>> I don't see where RFC6675 forbids growing cwnd. Even if it does, I >>>>> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly >>>>> indicates a delivery has been made. >>>> >>>> SACKed sequences with DUpAcks indicate that those sequences were >>>> delivered but it does not tell when they were sent. The basic principle >>>> of slow start is to reliably determine the available network capacity >>>> during slow start. Therefore, slow start must ensure it uses only >>>> segments sent during the slow start to increase cwnd. Otherwise, a TCP >>>> sender may encounter exactly the problem of unnecessary retransmission >>>> envisioned in this example of RACK-TCP draft (and increase cwnd on not >>>> valid Acks). >>>> >>>> RFC 6675 does re-specify DupAck with SACK option but it does not include >>>> the rule for slow start. Slow start is specified in RFC 5681. It is >>>> crystal clear in allowing increase in cwnd only on cumulative >>>> Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, >>>> page 6: >>>> >>>> During slow start, a TCP increments cwnd by at most SMSS bytes for >>>> each ACK received that cumulatively acknowledges new data. >>>> >>>> Maybe this example in the RACK-TLP draft was inspired by a incorrect >>>> implementation of SACK-based loss recovery? >>>> >>>> FYI: when we were finalizing RFC 6675 I suggested including also an >>>> algorithm for RTO recovery with SACK in RFC 6675. The reason was exactly >>>> that it might be not easy to gather info from multiple documents and >>>> hence help the implementor to have all necessary advice in a single >>>> document. This unfortunately did not get realized though. >>> >>> I am honestly lost quibbling these RFC6675 implementations and feeling >>> pedantic to these standards largely serve as guiding principles >>> instead of line-by-line code. Is cwnd one packet bigger or smaller in >>> this example making any different in advancing the Internet's >>> capability to do better loss detection. I do not think so. >> >> Sorry, I don't understand what was quibbling here. I believe I did not >> argue anything about cwnd size with this example at hand in Sec. 3.5. >> My point is that it describes incorrect slow start behavior. Correctly >> implemented slow start does not have the problem illustriated in the >> example. >> >>> At this point please suggest a text you like to change. >> >> That is simple. Please remove the description of the behavior without >> RACK. Or correct it: the behavior would be exactly the same as with RACK, >> but the reason for not unnecessarily retransmitting third segment can be >> described to be different. >> And, please correct also the description with RACK. With RACK, third >> segment does not get unnecessarly rexmitted for the reason already >> indicated and also because cwnd=1 MSS. And, no new segments are allowed >> either by cwnd=1. >> > > [RACK-TLP-team:] > > Thanks. Perhaps it makes sense to consider a slightly different RTO > scenario to illustrate the point about how RACK RTO behavior can avoid > spurious retransmissions. > > Here is the proposed new text: > > "3.5. An Example of RACK-TLP in Action: RTO > > In addition to enhancing fast recovery, RACK improves the accuracy of > RTO recovery by reducing spurious retransmissions. > > Without RACK, upon RTO timer expiration the sender marks all the > unacknowledged segments lost. This approach can lead to spurious > retransmissions. For example, consider a simple case where one > segment was sent with an RTO of 1 second, and then the application > writes more data, causing a second and third segment to be sent right > before the RTO of the first segment expires. Suppose none of the > segments were lost. Without RACK, if there is a spurious RTO then > the sender marks all three segments as lost and retransmits the > first segment. If the ACK for the original copy of the first segment > arrives right after the spurious RTO retransmission, then the > sender continues slow start and spuriously retransmits the second > and third segments, since it (erroneously) presumed they are lost. That seems fine. Would it be useful to add an additional note saying that if F-RTO is in use, then further unnecessary retransmissions can be avoided? > With RACK, upon RTO timer expiration the only segment automatically > marked lost is the first segment (since it was sent an RTO ago); for > all the other segments RACK only marks the segment lost if at least > one round trip has elapsed since the segment was transmitted. > Consider the previous example scenario, this time with RACK. With > RACK, when the RTO expires the sender only marks the first segment as > lost, and retransmits that segment. The other two very recently sent > segments are not marked lost, because they were sent less than one > round trip ago and there were no ACKs providing evidence that they > were lost. Upon receiving the ACK for the RTO retransmission the > RACK sender would not yet retransmit the second or third segment. but > rather would rearm the RTO timer and wait for a new RTO interval to elapse > before marking the second or third segments as lost. > " This behavior with RACK-TLP does not quite match with my reading of the draft in all parts, so I have some questions. First, wouldn't the PTO timer be first running for the first segment and when the sender sends the 2nd and 3rd segment it would rearm PTO for the 3rd segment? My understanding based on Sec 8 is that RTO cannot be armed until PTO fires? And when the PTO fires, the sender would retransmit the 3rd segment? Maybe I am missing something? Anyways, an RTO timer may expire in this scenario (e.g., if there is no Ack for TLP). Let's assume the RTO timer expires as described. When the first Ack after the rexmit of the 1st segment arrives, isn't that the late ACK for the original copy of the first segment, not the ACK for the RTO retransmission? Anyways, when this first Ack arrives after the RTO, the second and third segment are not marked as lost as described, which nicely prevents unnecessary retransmissions of those segments. However, if the 2nd and 3rd segments were lost, wouldn't rearming RTO with exponentially backed-off timer value (2*RTO) make the recovery of the 2nd and 3rd segment very slow? After 2*RTO the timer expires and the 2nd segment is rexmitted and only after one additional RTT when the ack for the 2nd segment arrives, the sender rexmits the 3rd segment? Wouldn't it be much more efficient to disable RACK loss detection during an RTO recovery and employ F-RTO? Maybe I am missing something again? Then to the problem with the pseudocode I mentioned in the beginning of this message. If I am not incorrect it seems to me that setting a value to TLP.end_seq in TLP_send_probe() is off by one byte? Maybe something similar is wrong somewhere else too, didn't check. Please apologise me if I missed something. Let's use an example with RACK-TLP recovery: Send P1, ..., P9, P10 [P1,.., P9 delayed, P10 dropped] /* I believe P1-9 delayed is not important here */ After 2*SRTT PTO expires P10 rexmitted by TLP [ TLP_send_probe(): set TLP.end_seq = SND.NXT (= SEG.P11) ] [after TLP, the application possibly provides more data to send] Ack for original P1 arrives (P11 sent, if more data by application) Ack for original P2 arrives (P12 sent, if more data by application) ... Ack for original P9 arrives (P19 sent, if more data by application) Ack for P10 triggered by TLP rexmit of P10 arrives [TLP_process_ack(ACK): ... If ACK's ack. number > TLP.end_seq returns False since ACK's ack. number = SEQ.ACK = TLP.end_seq = SEG.P11] Loss of P10 is undetected and no reaction to congestion] My understanding of draft text is that a loss of P10 is not concealed. Please advise. Best regards, /Markku > best regards, > > neal > >> Please remove also the last paragraph of the Sec. 3.5, it being also >> incorrect description of behavior. >> >> BR, >> >> /Markku >> >>>> >>>> BR, >>>> >>>> /Markku >>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> /Markku >>>>>> >>>>>> >>>>>> >>>>>> On Mon, 16 Nov 2020, The IESG wrote: >>>>>> >>>>>>> >>>>>>> The IESG has received a request from the TCP Maintenance and Minor Extensions >>>>>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss detection >>>>>>> algorithm for TCP' >>>>>>> as Proposed Standard >>>>>>> >>>>>>> The IESG plans to make a decision in the next few weeks, and solicits final >>>>>>> comments on this action. Please send substantive comments to the >>>>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, comments may >>>>>>> be sent to iesg@ietf.org instead. In either case, please retain the beginning >>>>>>> of the Subject line to allow automated sorting. >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> >>>>>>> This document presents the RACK-TLP loss detection algorithm for TCP. >>>>>>> RACK-TLP uses per-segment transmit timestamps and selective >>>>>>> acknowledgements (SACK) and has two parts: RACK ("Recent >>>>>>> ACKnowledgment") starts fast recovery quickly using time-based >>>>>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") >>>>>>> leverages RACK and sends a probe packet to trigger ACK feedback to >>>>>>> avoid retransmission timeout (RTO) events. Compared to the widely >>>>>>> used DUPACK threshold approach, RACK-TLP detects losses more >>>>>>> efficiently when there are application-limited flights of data, lost >>>>>>> retransmissions, or data packet reordering events. It is intended to >>>>>>> be an alternative to the DUPACK threshold approach. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> The file can be obtained via >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> No IPR declarations have been submitted directly on this I-D. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> tcpm mailing list >>>>>>> tcpm@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tcpm >>>>>>> >>>>> >>> > From nobody Wed Dec 16 08:18:42 2020 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 666A13A0905; Tue, 15 Dec 2020 15:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FUZZY_IMPORTANT=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 QhYYJiN6nNeK; Tue, 15 Dec 2020 15:54:11 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 AAB473A0902; Tue, 15 Dec 2020 15:54:10 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id t8so22257525iov.8; Tue, 15 Dec 2020 15:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z6owWIOlaaC7oSAAer3jj/FJmo/Ym43lg9zffaq/gjE=; b=aoyw8lgJYKjsMdpUhRx1wduF5nZXnUmZQCzBnfxVmboh4Nmhf+F4oCu8GdgAKCqptU c+9Gw1CnQVSp+HBk9l0YWpRzKLU/OY/Um7pArmhF2hsfyGo84d+oV93M8zXYx6YGPhVo diKGzzoN4vVCIhNLQSri1GAFj05UQHpZFwhccEsOq001+5PjELZhWpvO3e5xuGutaa2B oU16Xt0SUXBbkz5KkF/MpbXjLmp73UH4jymEZpqjHWjvtG4FSfr7LPZMTucEfL0GhN97 fAU6/e0lVb79ip+Ep9ZwCEQZo+0A7W5iuXTEpmhDPxXWI7JoLSYBCCELmmP8eju+43FK Aogg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z6owWIOlaaC7oSAAer3jj/FJmo/Ym43lg9zffaq/gjE=; b=bSSTNxWPtrMnZGNx9RMp7c9MU0DeMd1E34Hbxy73SD101ROwrNR+8WGGdQetTR8poh aGMm76bz6Zny5LORSVDuMyiT21sb1RGwuMjaN281xhcPQYZjzec2lxac8cjPpkQzxvAB SxrUw9FyYDJLc1SsAPZ1KVzfrP+v0VYMCX0HahoJ8uC5nC+LLHxToETW0Q8U61FkKoVF YQrB4YgcNVIr8oaAr6xm2Ms4DQcPrVBaZxVbD3NgA5WcHxJMmXto1UTCCd/hWWh/wGFH 2HFkl9PXHrJF8sb+kis58+dizd6exN43qFoKjewaQyEMb0srqvA8xfe2ZzHGCy+lXZfL 5W7A== X-Gm-Message-State: AOAM532ExQv7YNBykiG6j88fHUfuDavIjqlpfcs8OelQCWWB9c8f/ApH VVBmJjZnIdK9Pa7kSpxVtnsaMXkovKljqXeKewo= X-Google-Smtp-Source: ABdhPJx9ymp39lOQ/zR3I0sqJC7jG1WppTBby7MXgk3kGds5sRjdEs3qN/RXI6yIOOEZCsdUcVzxKh8Ax85m7ykdKTk= X-Received: by 2002:a02:cf30:: with SMTP id s16mr12869294jar.144.1608076449493; Tue, 15 Dec 2020 15:54:09 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Tue, 15 Dec 2020 15:53:58 -0800 Message-ID: To: Markku Kojo Cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="0000000000008b36fd05b68979f9" Archived-At: X-Mailman-Approved-At: Wed, 16 Dec 2020 08:18:40 -0800 Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 23:54:20 -0000 --0000000000008b36fd05b68979f9 Content-Type: text/plain; charset="UTF-8" Hi Markku, Thanks for the comments. The authors will incorporate many of your suggestions after the IESG review. There's one thing I don't understand in your comments: " That is, where can an implementer find advice for correct congestion control actions with RACK-TLP, when: (1) a loss of rexmitted segment is detected (2) an entire flight of data gets dropped (and detected), that is, when there is no feedback available and a timeout is needed to detect the loss " Section 9.3 is the discussion about CC, and is clear that the implementer should use either 5681 or 6937. You went through the 6937 case in detail. If 5681, it's pretty clear to me that in (1) this is a new loss detection after acknowledgment of new data, and therefore requires a second halving of cwnd. For (2), the RTO timer is still operative so the RTO recovery rules would still follow. In other words, I am not seeing a case that requires new congestion control concepts except as discussed in 9.3. What am I missing? On Tue, Dec 15, 2020 at 10:57 AM Markku Kojo wrote: > Hi Neal, all, > > (my apologies for this message getting so long but I didn't want to drop > any parts of it in case someone wants to get the entire discussion in one > piece. Also, apologies for repeating some of my concerns inline below; > Those who are clear with the problems may well opt skipping those parts.) > > Thanks Neal for the reply. I believe we are slowly converging with many > of my comments but two of the important issues still remain open. That is, > where can an implementer find advice for correct congestion control > actions with RACK-TLP, when: > (1) a loss of rexmitted segment is detected > (2) an entire flight of data gets dropped (and detected), > that is, when there is no feedback available and a timeout > is needed to detect the loss > > I fully understand the intent of the RACK-TLP draft not to include > congestion control actions in this document (or the intent to minimise > such advise). However, when new ways to detect loss are introduced and > published (as this document would do), IMHO it is imperative to have such > congestion control actions readily available for an implementer. AFAIK > we do not have in the RFC series correct actions available for these two > cases. > > I do not have a strong opinion whether the necessary actions should be in > this document or in another document, as long as we have them. This is > more or less a process decision, I think. > > Please see more details inline. > > I also investigated a bit more on RACK-TLP as specified in the draft and > it seems that there is a problem with the pseudocode as currently > presented (some sequence numbers seem to be off by one, resulting in > wrong outcome in some/many? cases). Please see inline in the end of my > reply. > > > On Sat, 12 Dec 2020, Neal Cardwell wrote: > > > Hi Markku, > > > > Thanks for your many detailed and thoughtful comments. Please see > > below in-line for our comments based on discussions among RACK-TLP > > draft authors. > > > > On Tue, Dec 8, 2020 at 11:21 AM Markku Kojo wrote: > >> > >> Hi, > >> > >> please see inline. > >> > >> On Mon, 7 Dec 2020, Yuchung Cheng wrote: > >> > >>> On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo > wrote: > >>>> > >>>> Hi Yuchung, > >>>> > >>>> thanks for your reply. My major point is that IMHO this RACK-TLP > >>>> specification should give the necessary advice w.r.t congestion > control > >>>> in cases when such advice is not available in the RFC series or is not > >>>> that easy to interpreted correctly from the existing RFCs. > >>>> > >>>> Even though the CC principles were available in RFC series I believe > you > >>>> agree with me that getting detailed CC actions correct is sometimes > quite > >>>> hard, especially if one needs to interpret and apply them from another > >>>> spec than what one is implementing. Please see more details inline > below. > >>>> > >>>> In addition, we need to remember that this document is not meant only > for > >>>> TCP experts following the tcpm list and having deep understanding of > >>>> congestion control but also those implementing TCP, for the very first > >>>> time, for various appliances, for example. They do not have first hand > >>>> experience in implementing TCP congestion control and deserve clear > >>>> advice what to do. > >>>> > >>>> On Fri, 4 Dec 2020, Yuchung Cheng wrote: > >>>> > >>>>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo > wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I know this is a bit late but I didn't have time earlier to take > look at > >>>>>> this draft. > >>>>>> > >>>>>> Given that this RFC to be is standards track and RECOMMENDED to > replace > >>>>>> current DupAck-based loss detection, it is important that the spec > is > >>>>>> clear on its advice to those implementing it. Current text seems to > >>>>>> lack important advice w.r.t congestion control, and even though > >>>>>> the spec tries to decouple loss detection from congestion control > >>>>>> and does not intend to modify existing standard congestion control > >>>>>> some of the examples advice incorrect congestion control actions. > >>>>>> Therefore, I think it is worth to correct the mistakes and take > >>>>>> yet another look at a few implications of this specification. > >>>>> As you noted, the intention is to decouple the two as much as > possible > >>>>> > >>>>> Unlike the 20 years ago where TCP loss detection and congestion > >>>>> control are essentially glued in one piece, the decoupling of the two > >>>>> (including modularizing congestion controls in implementations) has > >>>>> helped fueled many great inventions of new congestion controls. > >>>>> Codifying so-called-default C.C. reactions in the loss detection is a > >>>>> step backward that the authors try their best to avoid. > >>>> > >>>> While I fully agree with the general principle of decoupling loss > >>>> detection from congestion control when it is possible without leaving > >>>> open questions, I find it hard to get congestion control right with > this > >>>> spec in certain cases I raised just by following the current standards > >>>> track CC specifications. The reason for this is that RACK-TLP > introduces > >>>> new ways to detect loss (i.e., not present in any earlier standard > track > >>>> RFC) and the current CC specifications do not provide correct CC > actions > >>>> for such cases as I try to point out below. > >>>> > >>>>> To keep the > >>>>> document less "abstract / unclear" as many WGLC reviewers commented, > >>>>> we use examples to illustrate that includes CC actions. But the > >>>>> details of these CC actions are likely to become obsolete as CC > >>>>> continues to advance hopefully. > >>>> > >>>> Agreed. But I would appreciate if the CC actions in the examples would > >>>> correctly follow what is specified in the the current CC RFCs. And, I > >>>> would suggest explicitly citing the RFC(s) that each of the examples > is > >>>> illustriating so that there is no doubt which CC variant the example > >>>> is valid with. Then there is no problem with the correctness of the > >>>> example either even if the cited RFC becomes later obsoleted. > >>>> > >>>>>> > >>>>>> Sec. 3.4 (and elsewhere when discussing recovering a dropped > >>>>>> retransmission): > >>>>>> > >>>>>> It is very useful that RACK-TLP allows for recovering dropped > rexmits. > >>>>>> However, it seems that the spec ignores the fact that loss of a > >>>>>> retransmission is a loss in a successive window that requires > reacting > >>>>>> to congestion twice as per RFC 5681. This advice must be included in > >>>>>> the specification because with RACK-TLP recovery of dropped rexmit > >>>>>> takes place during the fast recovery which is very different > >>>>>> from the other standard algorithms and therefore easy to miss > >>>>>> when implementing this spec. > >>>>> > >>>>> per RFC5681 sec 4.3 https://tools.ietf.org/html/rfc5681#section-4.3 > >>>>> "Loss in two successive windows of data, or the loss of a > >>>>> retransmission, should be taken as two indications of congestion > and, > >>>>> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > >>>>> > >>>>> RACK-TLP is a loss detection algorithm. RFC5681 is crystal clear on > >>>>> this so I am not sure what clause you suggest to add to RACK-TLP. > >>>> > >>>> Right, this is the CC *principle* in RFC 5681 I am refering to but I > am > >>>> afraid it is not enough to help one to correctly implement such > lowering > >>>> of cwnd (and ssthresh) twice when a loss of a retransmission is > detected > >>>> during Fast Recovery. Nor do RFCs clearly advice *when* this reduction > >>>> must take place. > >>>> > >>>> Congestion control principles tell us that congestion must be reacted > >>>> immediately when detected. But at the same time, standards track CC > >>>> specifications react to congestion only once during Fast Recovery > >>>> because the losses in the current window, which Fast Recovery repairs, > >>>> occured during the same RTT. That is, the current CC specifications do > >>>> not handle lost rexmits during Fast Recovery but, instead, the > correct CC > >>>> reaction to a loss of a rexmit is automatically achieved by those > >>>> specifications via RTO when cwnd is explicitly reset upon RTO. > >>>> > >>>> Furthermore, the problem I am trying to point out is that there is no > >>>> correct rule/formula available in the standards track RFCs that would > >>>> give the correct way to reduce cwnd when the loss of rexmit is > detected > >>>> with RACK-TLP. > >>>> > >>>> I suggest everyone reading this message stops reading at this point > >>>> for a while before continuing reading and figures out themselves what > >>>> they think would be the correct equation to use in the standards RFC > >>>> series to find the new halved value for cwnd when RACK-TLP detects a > loss > >>>> of a rexmit during Fast Recovery. I would appreciate a comment on the > >>>> tcpm list from those who think they found the correct answer > immediately > >>>> and easily, and what was the formula to use. > >>>> > >>>> ... > >>>> > >>>> I think the best advice one may find by looking at RFC 6675 (and RFC > >>>> 5681) is to set > >>>> > >>>> ssthresh = cwnd = (FlightSize / 2) (RFC 6675, Sec 5, algorithm step > 4.2) > >>>> > >>>> Now, let's modify the example in Sec 3.4 of the draft: > >>>> > >>>> 1. Send P0, P1, P2, ..., P20 > >>>> [Assume P1, ..., P20 dropped by network] > >>>> > >>>> 2. Receive P0, ACK P0 > >>>> 3a. 2RTTs after (2), TLP timer fires > >>>> 3b. TLP: retransmits P20 > >>>> ... > >>>> 5a. Receive SACK for P20 > >>>> 5b. RACK: marks P1, ..., P20 lost > >>>> set cwnd=ssthresh=FlightSize/2=10 > >>>> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > >>>> [P1 retransmission dropped by network] > >>>> > >>>> Receive SACK P2 & P3 > >>>> 7a. RACK: marks P1 retransmission lost > >>>> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > >>>> 7b. Retransmit P1 > >>>> ... > >>>> > >>>> So, is the new value of the cwnd (10MSS) correct and halved twice? If > not, > >>>> where is the correct formula to do it? > >>>> > >>>> Before RFC 5681 was published we had a discussion on FlighSize and > that > >>>> during Fast Recovery it does not reflect the amount of segments in > >>>> flight correctly but may also have a too large value. It was decided > not > >>>> to try to correct it because it only has an impact when RTO fires > during > >>>> Fast Recovery and in such a case cwnd is reset to 1 MSS. Having too > large > >>>> ssthresh for RTO recovery in some cases was not considered that bad > >>>> because a TCP sender anyway takes to most conservative CC action with > the > >>>> cwnd and would slow start from cwnd = 1 MSS. But now when RACK-TLP > enables > >>>> detecting loss of a rexmit during Fast Recovery we have an unresolved > >>>> problem. > >>> > >>>> 1. Send P0, P1, P2, ..., P20 > >>>> [Assume P1, ..., P20 dropped by network] > >>>> > >>>> 2. Receive P0, ACK P0 > >>>> 3a. 2RTTs after (2), TLP timer fires > >>>> 3b. TLP: retransmits P20 > >>>> ... > >>>> 5a. Receive SACK for P20 > >>>> 5b. RACK: marks P1, ..., P20 lost > >>>> set cwnd=ssthresh=FlightSize/2=10 > >>>> 5c. Retransmit P1, P2 (and some more depending on how CC implemented) > >>>> [P1 retransmission dropped by network] > >>>> > >>>> Receive SACK P2 & P3 > >>>> 7a. RACK: marks P1 retransmission lost > >>>> As per RFC 6675: set cwnd=ssthresh=FlightSize/2=20/2=10 > >>>> 7b. Retransmit P1 > >>> > >>> To account for your points, IMO clearly stating the existing CC RFC > >>> interactions w/o mandating any C.C. actions are the best way to move > >>> forward. Here are the text diff I proposed: > >>> > >>> "Figure 1, above, illustrates ... > >>> Notice a subtle interaction with existing congestion control actions > >>> on event 7a. It essentially starts another new episode of congestion > >>> due to the detection of lost retransmission. Per RFC5681 (section 4.3) > >>> that loss in two successive windows of data, or the loss of a > >>> retransmission, should be taken as two indications of congestion as a > >>> principle. But RFC6675 that introduces the pipe concept does not > >>> specify such a second window reduction. This document reminds RACK-TLP > >> > >> This is not quite correct characterization of RFC 6675. > >> RFC 6675 does not repeat all guidelines of RFC 5681. RFC 6675 DOES > specify > >> the two indications of congestion implicitly by clearly stating in the > >> intro that it follows the guidelines set in RFC 5681. > >> And RFC 5681 articulates a set of MUSTs which ALL alternative loss > >> recovery algorithms MUST follow in order to become RFCs. > >> > >> (*) RFC 5681, Sec 4.3 (pp. 12-13): > >> > >> "While this document does not standardize any of the > >> specific algorithms that may improve fast retransmit/fast recovery, > >> ... > >> That is, ... > >> Loss in two successive windows of data, or the loss of a > >> retransmission, should be taken as two indications of congestion and, > >> therefore, cwnd (and ssthresh) MUST be lowered twice in this case." > >> > >> > >>> implementation to carefully consider the new multiple congestion > >>> episode cases in the corresponding congestion control." > >> > >> I am sorry to say that this is very fuzzy and leaves an implementer > >> all alone what to do. > >> > >> More inportantly, AFAIK we have no discussion nor consensus in the IETF > >> on what is the correct CC action when lost rexmit is detected. > >> Should one reset cwnd like current CCs do, or would "halving again" be > >> fine, or something else? IMHO this requires experimentation to decide. > >> > >> I assumed there is an implementation of RACK-TLP with corresponding CC > >> actions and experimental results to devise what are the implications of > >> the selected CC action(s) with various levels of congestion. But it > seems > >> we do not have such implementation nor experimental evidence? Am I > wrong? > > > > [RACK-TLP-team:] > > > > We do have such implementations of RACK-TLP with corresponding CC > > actions, and experimental results were reported in RACK-TLP > > presentations and earlier revisions of the RACK-TLP draft. With > > Yes, that was my understanding what is implemented. Given there is this > implementation that reacts appropriately to congestion when RACK-TLP > detects loss of a retransmitted segment, could you please illuminate the > congestion control actions taken in the implementation with which there > is experimental experience. > > If I understood it correctly, the RACK-TLP in question is implemented > with PRR. Let's assume another implementer wants to add RACK-TLP with PRR > in the stack she/he is working on. I believe that the implementer would > think that detecting a loss of a rexmit during fast recovery would start > a new congestion episode in PRR (and that's what Yuchung also indicated > in the new proposed text in his previeous reply shown above). With > that advice and reading RFC 6937, an implementer would reinitialize PRR > state for the new congestion episode. So how should the implementer > calculate new values for ssthresh and RecoverFS? Should she/he use what > is currently described in RFC 6937, Sec 3 (to keep discussion simple > assume the implementer wants to have an IETF Standards Track comformant > implementation, so use CongCtrlAlg() = FlightSize/2): > > ssthresh = CongCtrlAlg() // Target cwnd after recovery > prr_delivered = 0 // Total bytes delivered during recovery > prr_out = 0 // Total bytes sent during recovery > RecoverFS = snd.nxt-snd.una // FlightSize at the start of recovery > > Or should one use something else? AFAIK depending on the loss pattern > neither FlightSize nor "snd.nxt-snd.una" would give correct values for > the intended behavior. Depending on the loss pattern, at the time > of detecting a loss of rexmit FlighSize may be ~ 50% larger than in the > beginning of fast recovery. This would result in increasing ssthresh > (send rate), instead of decreasing it. It seems that something else in > PRR algo would also need to be modified to get sndcnt correct but I > cannot figure it out right now. > > If one wants to implement RACK-TLP without PRR, that is, with RFC 6675, > we have the same probelm with FlightSize in determining a new value for > cwnd and ssthresh. > > My point is that using what we currently have out there in the RFC > series gives incorrect CC advice. And, having correct CC actions in this > case is far from trivial so IMHO high quality standards specifications > should not leave an implementer of RACK-TLP alone to figure it out. > > In addition, if a new episode of fast recovery is started for CC purposes > how would that play together with RACK-TLP loss detection? In Sec 7.1 the > text says initialize (reset) TLP.end_seq and TLP.is_retrans when > initiating fast recovery. But detecting a lost rexmit seemingly should > not reinitialize TLP because PTO is disabled during fast recovery as per > Sec 7.2. If CC actions are in another document and loss detection in this > document, it would be of high importance to clarify when each of the > fast recovery episodies (CC vs. loss detection) are supposed to end: is > the end condition the same or different? > > > respect to implementations, there is the Linux TCP stack, which has > > been using RACK-TLP as the default loss recovery algorithm since Linux > > v4.18 in August 2018. The exact commit is: > > > > b38a51fec1c1 tcp: disable RFC6675 loss detection > > > > With Linux, the default sender behavior since that commit has been > > governed by CUBIC, PRR, and RACK-TLP. > > > > RACK-TLP is used by all Google TCP traffic, including internal RPC > > traffic and external YouTube and google.com traffic over the public > > Internet. At Google we have years of high-traffic-volume experience > > with RACK-TLP with three different CC schemes: CUBIC+PRR, BBRv1, and > > BBRv2. > > > > My understanding is that Netflix FreeBSD TCP traffic uses RACK-TLP, > > and Microsoft Windows TCP traffic has also been using RACK-TLP. > > And I wonder what would be the CC actions taken in each of these > implementations when a loss of rexmited segment is detected? > > >> I sincerely apologize that this got raised this late in the prosess and > >> I know how irritating it may be. I like the idea of RACK-TLP and by no > >> means my intention is not to hold up the process but the lack of > evidence > >> makes me quite concerned. In particular, when this document says that > >> the current loss detection SHOULD be replaced in all implementations > with > >> RACK-TLP. > >> > >>> and to emphasize in section 9.3 Interaction with congestion control > >>> > >>> "9.3. Interaction with congestion control > >>> > >>> RACK-TLP intentionally decouples loss detection ... this appropriate. > >>> As mentioned in Figure 1 caption, RFC5681 mandates a principle that > >>> Loss in two successive windows of data, or the loss of a > >>> retransmission, should be taken as two indications of congestion, and > >>> therefore reacted separately. However implementation of RFC6675 pipe > >>> algorithm may not directly account for this newly detected congestion > >>> events properly. Therefore the documents reminds RACK-TLP > >>> implementation to carefully consider these implications in its > >>> corresponding congestion control. > >>> > >>> ..." > >>> > >>> > >>> > >>>> > >>>> > >>>>>> Sec 9.3: > >>>>>> > >>>>>> In Section 9.3 it is stated that the only modification to the > existing > >>>>>> congestion control algorithms is that one outstanding loss probe > >>>>>> can be sent even if the congestion window is fully used. This is > >>>>>> fine, but the spec lacks the advice that if a new data segment is > sent > >>>>>> this extra segment MUST NOT be included when calculating the new > value > >>>>>> of ssthresh as per the equation (4) of RFC 5681. Such segment is an > >>>>>> extra segment not allowed by cwnd, so it must be excluded from > >>>>>> FlightSize, if the TLP probe detects loss or if there is no ack > >>>>>> and RTO is needed to trigger loss recovery. > >>>>> > >>>>> Why exclude TLP (or any data) from FlightSize? The congestion control > >>>>> needs precise accounting of the flight size to react to congestion > >>>>> properly. > >>>> > >>>> Because FlightSize does not always reflect the correct amount of data > >>>> allowed by cwnd. When a TCP sender is not already in loss recovery and > >>>> it detects loss, this loss indicates the congestion point for the TCP > >>>> sender, i.e., how much data it can have outstanding. It is this > amount of > >>>> data that it must use in calculating the new value of cwnd (and > >>>> ssthresh), so it must not include any data sent beyond the congestion > >>>> point. When TLP sends a new data segment, it is beyond the congestion > >>>> point and must not be included. Same holds for the segments sent via > >>>> Limited Transmit: they are allowed to be send out by the packet > >>>> conservation rule (DupAck indicates a pkt has left the network, but > does > >>>> not allow increasing cwnd), i.e., the actual amount of data in flight > >>>> remains the same. > >>>> > >>>>>> In these cases the temporary over-commit is not accounted for as > DupAck > >>>>>> does not decrease FlightSize and in case of an RTO the next ACK > comes too > >>>>>> late. This is similar to the rule in RFC 5681 and RFC 6675 that > prohibits > >>>>>> including the segments transmitted via Limitid Transmit in the > >>>>>> calculation of ssthresh. > >>>>>> > >>>>>> In Section 9.3 a few example scenarios are used to illustriate the > >>>>>> intended operation of RACK-TLP. > >>>>>> > >>>>>> In the first example a sender has a congestion window (cwnd) of 20 > >>>>>> segments on a SACK-enabled connection. It sends 10 data segments > >>>>>> and all of them are lost. > >>>>>> > >>>>>> The text claims that without RACK-TLP the ending cwnd would be 4 > segments > >>>>>> due to congestion window validation. This is incorrect. > >>>>>> As per RFC 7661 the sender MUST exit the non-validated phase upon an > >>>>>> RTO. Therefore the ending cwnd would be 5 segments (or 5 1/2 > segments if > >>>>>> the TCP sender uses the equation (4) of RFC 5681). > >>>>>> > >>>>>> The operation with RACK-TLP would inevitably result in congestion > >>>>>> collapse if RACK-TLP behaves as described in the example because > >>>>>> it restores the previous cwnd of 10 segments after the fast recovery > >>>>>> and would not react to congestion at all! I think this is not the > >>>>>> intended behavior by this spec but a mistake in the example. > >>>>>> The ssthresh calculated in the beginning of loss recovery should > >>>>>> be 5 segments as per RFC 6675 (and RFC 5681). > >>>>> To clarify, would this text look more clear? > >>>>> > >>>>> 'an ending cwnd set to the slow start threshold of 5 segments (half > of > >>>>> the original congestion window of 10 segments)' > >>>> > >>>> This is correct, but please replace: > >>>> > >>>> (half of the original congestion window of 10 segments) > >>>> --> > >>>> (half of> the original FlightSize of 10 segments) > >>> > >>> sure will do > >>> > >>>> > >>>> cwnd in the example was 20 segments. > >>>> > >>>> Please also correct the ending cwnd for "without RACK" scenario. > >>>> I poined out wrong equation number IN RFC 5681 and INCORRECT cwnd > value, > >>>> my apologies. It MAENT equation (3) AND that results in ending cwnd > of 5 > >>>> and 2/5 MSS (not 5 and 1/2 MSS). > >>>> NB: and if a TCP sender implements entering CA when cwnd > ssthresh, > then > >>>> ending cwnd would be 6 and 1/6 MSS). > >>>> > >>>>>> > >>>>>> Furthermore, it seems that this example with RACK-TLP refers to > using > >>>>>> PRR_SSRB which effectively implements regular slow start in this > >>>>>> case(?). From congestion control point of view this is correct > because > >>>>>> the entire flight of data as well as ack clock was lost. > >>>>>> > >>>>>> However, as correctly discussed in Sec 2, congestion window must be > reset > >>>>>> to 1 MSS when an entire flight of data is and Ack clock is lost. > But how > >>>>>> can an implementor know what to do if she/he is not implementing the > >>>>>> experimental PRR algrorithm? This spec articulates specifying an > >>>>>> alternative for DupAck counting, indicating that TLP is used to > trigger > >>>>>> Fast Retransmit & Fast Recovery only, not a loss recovery in slow > start. > >>>>>> This means that without an additional advise an implementation of > this > >>>>>> spec would just halve the cwnd and ssthresh and send a potentially > very > >>>>>> large burst of segments in the beginning of the Fast Recovery > because > >>>>>> there is no ack clock. So, this spec begs for an advise (MUST) when > to > >>>>>> slow start and reset cwnd and when not, or at least a discussion of > >>>>>> this problem and some sort of advise what to do and what to avoid. > >>>>>> And, maybe a recommendation to implement it with PRR? > >>>>> > >>>>> It's wise to decouple loss detection (RACK-TLP) vs congestion/burst > >>>>> control (when to slow-start). The use of PRR is just an example to > >>>>> illustrate and not meant for a recommendation. > >>>> > >>>> I understand the use of PRR was just an example, but my point is that > if > >>>> one wants to implement RACK-TLP but does not intend to implement PRR > but > >>>> RFC 6675 then we do not have a rule in RFC 6675 to correctly implement > >>>> CC for the case when an entire flight is lost and loss is detected > with > >>>> TLP. Congestion control principle for this is clear and also stated in > >>>> this draft but IMHO it is not enough to ensure correct implementation. > >>>> > >>>> To my understanding we only have implementation experience for > RACK-TLP > >>>> only togerher with PRR, which has the necessary rule to handle this > kind > >>>> of scenario correctly. > >>>> > >>>> So, my question is how can one implement CC correctly without PRR such > >>>> a scenario where entire inflight is lost? > >>>> Which rule and where in the RFC series gives the necessary guidance to > >>>> reset cwnd and slow start when TCP detets loss of an entire flight? > >>> > >>> I think we're going in loops. To move forward it'd help if you suggest > >>> some text you like to change. > >> > >> Unfortunately I do not have an immediate solution. I assumed there is an > >> implementation and you could enlighten what was the solution there and > >> experimental results showing how it seems to work. If I have understood > >> it correctly there is a solution/implementation and experience of > RACK-TLP > >> that works together with PRR but no solution/implementation nor > experience > >> how it works without PRR. Am I correct? > > > > [RACK-TLP-team:] > > > > The implementation solutions and experiments were mentioned above. Our > > team's experience is with RACK-TLP in combination with either > > CUBIC+PRR, BBRv1, and BBRv2. We are not sure if there are other TCP > > implementations that implement RACK-TLP without PRR. > > So, in addition to the lack of experimental evidence using RACK-TLP > without PRR we have a specification problem for which we have no answer: > > The RACK-TLP text suggests that if PTO fires and TLP detects a loss, the > TCP sender enters fast recovery. But > > PTO = timeout that expires if there is no feedback (ACKs) from > the network, i.e., entire flight of data is lost. > > TLP = a single segment that is sent when timer expires. What is > different compared to RTO is that PTO may expire faster > and a different segment is (re)transmitted, allowing to > detect more than one lost segment with a single Ack w/ SACK > triggered by TLP (with regular RTO recovery only the next > unacknowledged segment can reliably be considered lost) > > >From congestion control point of view this means that PTO is no different > from RTO. The congestion control principle as stated in Sec 2.2 of this > document tells us that a loss of entire flight deserves a cautious > response, i.e., reset cwnd and slow start. > > When RACK-TLP is implemented with PRR we have appropriate CC actions > specified in RFC 6937 that effectively reset cwnd and force the TCP sender > to slow start, even though it tecnically enters fast recovery. This is > safe. > > However, if an implementer wants to implement RACK-TLP without PRR, > she/he has to consult RFC 6675 which gives an incorrect CC response for > this case, resulting in an unsafe implementation. The problem is not in > the fast recovery algorithm in RFC 6675 because it was not intended to be > initiated with TLP-kind of loss detection. > > So the question is how to ensure an implementer has the necessary advice > to implement correct congestion control actions for RACK-TLP once this > document is published. The lack of correct advice becomes even more > prominent as this document requires (all SACK capable) TCPs to implement > RACK-TLP. > > >> Given my understanding of PRR, the problem of an entire flight being > >> dropped is quite nicely solved with it. However, implementing RACK-TLP > >> without PRR begs for a solution. Here is my current understanding: > >> > >> (1) RACK part is what can be called to "replace" DupAck counting > >> (2) TLP part is effectively a new retransmission timeout to detect > >> a loss of an entire flight of data (i.e., it is only invoked > >> when a tail of the current flight becomes lost which equals to > >> the case of losing an entire flight since all segments before > >> the tail loss will get cumulatively Acked and hence these segments > >> are not anymore a part of the current flight at the time the loss > >> is detected. And we an assume application limited TCP sender. > >> (3) Current CC principles require resetting cwnd in such a case > >> and entering slow start (and so effectively does PRR though it is > >> not explicitly stated in RFC 6937). Slow start avoids a big burst > >> if the lost flight is big. > >> (4) RACK-TLP would possibly like to allow that cwnd is set to a half > >> of the lost flight and not to slow start. This means that the > bigger > >> the lost flight is, the bigger is the burst that gets transmitted > at > >> the beginning of the recovery which is bad. So, this approach would > >> need at least a rule/advice for burst avoidance (slow start, > pacing, > >> ...). > >> (5) When the lost flight is small (<= 4 segments) there is no difference > >> in recovery efficiency between (3) and (4). If the lost flight is > >> > 5 segments, then (4) takes less RTTs to complete the recovery > >> but generates a burst. Note, even if pacing over one SRTT would be > >> used, it is still a burst. > >> > >> Now, it would be useful to have experimental data to know how the size > of > >> the lost flight is distributed. Is it typically just a few segments as > >> illustriated in the examples of the draft or is it often larger? > >> > >> My advice would be to add a rule that cwnd MUST be reset to 1 MSS > >> and the sender MUST enter slow start if TLP detects loss of an entire > >> flight. This would be safe. Otherwise, without experimental evidence > from > >> a wide range of different network conditions and workloads it feels > >> unsafe to allow more aggressive approach. > > > > [RACK-TLP-team:] > > > > Our team's position is that the RACK-TLP draft documents a loss > > detection algorithm, and normative declarations about congestion > > control behavior (like your "cwnd MUST be reset to 1 MSS", above) > > should be in a separate document focused on congestion control. > > I do not disagree with you what becomes to the role of congestion control > in the RACK-TLP draft. It may well be in another document but IMHO such > document must be available at the time this docment gets published. > How can we otherwise ensure correct implementations? > > So this is more of a process question than critique towards the draft. > > > >>>>> Section 3 has a lengthy section to elaborate the key point of > RACK-TLP > >>>>> is to maximize the chance of fast recovery. How C.C. governs the > >>>>> transmission dynamics after losses are detected are out of scope of > >>>>> this document in our authors' opinions. > >>>>> > >>>>> > >>>>>> > >>>>>> Another question relates to the use of TLP and adjusting timer(s) > upon > >>>>>> timeout. In the same example discussed above, it is clear that PTO > >>>>>> that fires TLP is just a more aggressive retransmit timer with > >>>>>> an alternative data segment to (re)transmit. > >>>>>> > >>>>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when PTO expires, it > is in > >>>>>> effect a retransmission timout and the timer(s) must be backed-off. > >>>>>> This is not adviced in this specification. Whether it is the TCP RTO > >>>>>> or PTO that should be backed-off is an open question. Otherwise, > >>>>>> if the congestion is persistent and further transmission are also > lost, > >>>>>> RACK-TLP would not react to congestion properly but would keep > >>>>>> retransmitting with "constant" timer value because new RTT estimate > >>>>>> cannot be obtained. > >>>>>> On a buffer bloated and heavily congested bottleneck this would > easily > >>>>>> result in sending at least one unnecessary retransmission per one > >>>>>> delivered segment which is not advisable (e.g., when there are a > huge > >>>>>> number of applications sharing a constrained bottleneck and these > >>>>>> applications are sending only one (or a few) segments and then > >>>>>> waiting for an reply from the peer before sending another request). > >>>>> > >>>>> Thanks for pointing to the RFC. After TLP, RTO timers will > >>>>> exp-backoff (as usual) for stability reasons mentioned in sec 9.3 > >>>>> (didn't find 9.1 relevant). > >>>> > >>>> My apologies for refering to the wrong section of RFC 2914, Yes, I > meant > >>>> Sec 9.3. > >>>> > >>>>> In your scenario, you presuppose the > >>>>> retransmission is unnecessary so obviously TLP is not good. Consider > >>>>> what happens without TLP where all the senders fire RTO spuriously > and > >>>>> blow up the network. It is equally unfortunate behavior. "bdp > >>>>> insufficient of many flows" is a congestion control problem > >>>> > >>>> If (without TLP) RTO is spurious, it may result in unnecessary > >>>> retransmissions. But we have F-RTO (RFC 5682) and Eifel (RFC 3522) to > >>>> detect and resolve it without TLP, so I don't find it as a problem. > >>>> > >>>> To clarify more, what I am concerned about. Think about a scenario > where a > >>>> (narrow) bottleneck becomes heavily congested by a huge number of > >>>> competing senders such that the available capacity per sender is less > >>>> than 1 segment (or << 1 MSS). > >>>> This is a situation that network first enters before congestion > collapse > >>>> gets realized. So, it is extremely important that all CC and timer > >>>> mechanisms handle it properly. Regular TCP handles it via RFC 6298 by > >>>> backing off RTO expotentially and keeping this backed-off RTO until an > >>>> new ACK is received for new data. This saves RACK-TLP from full > congestion > >>>> collapse. But consider what happens: even though RTO is backed off, > each > >>>> time a TCP sender manages to get one segment through (with cwnd = 1 > MSS) > >>>> it always first arms PTO with more or less constant value of 2*SRTT. > If > >>>> the bottleneck is buffer bloated the actual RTT easily exceeds 2*SRTT > and > >>>> TLP becomes spurious. After a spurious TLP, RTO expires (maybe more > than > >>>> once before exponential back-off of RTO results in large enough value) > >>>> and a new RTT sample is not received. So, SRTT remains unchanged and > even > >>>> if sometimes a new sample is received, SRTT gets very slowly > adjusted. As > >>>> a result, each TCP sender would keep on sending a spurious TLP for > each > >>>> new segment resulting in at least 50% of the packets being unnecessary > >>>> rexmitted and the utilization of the bottleneck is < 50%. This would > not > >>>> be a full congestion collapse but has unwanted symptoms towards > >>>> congestion collapse (Note: there is no clear line for the level of > >>>> reduction in delivery of useful data is considered as congestion > >>>> collapse). > >>> > >>> AFAIK you are saying: under extreme congestion shared by many short > >>> flows, RACK-TLP can cause more packet losses because of the more > >>> aggressive PTO timer. I agree and can add this to the "section 9.3". > >> > >> No, that was not what I meant. This happens simply when enough flows are > >> competing on the same bottleneck. It may be long flows or maybe > >> applications with more or less continuous request-reply exhanges. > >> E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is 500msecs and PMTU > >> is 1500B, then a bit over 40 simultaneous flows would mean that the > >> bottleneck becomes fully utilized with the equal share of roughly 1 MSS > >> per flow. With a quite typical bottleneck buffer size roughly equaling > to > >> BDP, about 80+ flows would fill up the buffer as well and increase > >> RTT >= 1 secs. A buffer bloated bottleneck buffer would mean even > larger > >> RTT and allow more flows sharing the bottleneck without loss. > >> > >> If the number of TCP flows is > 90 (or >> 90) RACK-TLP would ends up > >> (almost) always unnecessarily retransmitting each new segment once (PTO > >> being 1 sec or around 1 sec). RTO back-off after a few rounds saves each > >> TCP sender from additional unnecessary rexmits but still ~ 50% of the > >> deivered packets are not making any useful progress. > >> > >> If the bottleneck buffer is small, it would result in more losses as you > >> suggest but would not be that much of problem because majority of the > >> unnecessary rexmits would not get delivered over the bottleneck link. > >> Instead, they wuold get dropped at the bottleneck. Unnecessary rexmits > >> would just create extra load on the poth before the bottleneck (which of > >> course is not a non-problem either). > > > > [RACK-TLP-team:] > > > > If we are correctly understanding the scenario you are outlining, the > > PTO would likely not be 1 sec in this case. In this scenario, the RTT > > is around 1sec, so the PTO would be around 2*srtt, which would be > > around 2 secs. With a 1sec RTT, and even considering delayed ACKs, it > > seems very unlikely that a 2 sec PTO would cause a significant number > > of unnecessary TLP probes. > > Well. Roughly the first initiated 40 flows will have SRTT ~ 0.5 sec. If > next ~ 40 flows arrive within an RTT or so they will get RTT samples > roughly between 0.5 - 1.x secs. The rest 80 - N hundreds flows will not > get an RTT sample and will use initial/default PTO = 1 sec (unless using > timestamps). The larger the buffer bloat the worse things get. > Once ~200 flows are competing over the bottleneck, RTT will be well > beyond 2 secs and grows when more flows join, guaranteeing spurious TLP > for each new segment (unless timestamps are in use). > > > Perhaps your postulated PTO of 1 sec is coming from the pseudocode > > path in TLP_calc_PTO() where, if SRTT is not available, the PTO is 1 > > second? However, this case where there is no SRTT only happens if (a) > > the connection is *not* using TCP timestamps (enabled for most > > connections on the public Internet, due to default-enabled support in > > Linux/Android and iOS/MacOS), and (b) the connection has *never* had a > > single RTT sample from a non-retransmitted packet. To meet both of > > those conditions is quite rare in practice. Is this the path that is > > causing your concerns about a PTO of 1 sec? > > Sure. Having timestamps helps a lot in case the bottleneck buffer is > buffer bloated (though RTT sample will not include delayed Ack effect for > rexmits that are immediately acked). But RACK-TLP does not require > timestamps and there are a lot of TCP stacks out there in addition to > Linux/Android and iOS/MacOS. And more are coming with IoT expansion, > for example. In addition, it is quite suprising how old (mobile) devices > many people are using, some of which are old enough and have not been > eligible for an OS upgrade for many years. > > But my quick example scenario was just to illustriate the problem, maybe > typical in some areas where the only Internet access is over a > geostationary satellite connection and people quite likely not using > mobile/cellular devices. And, I selected a buffer-bloated scenario > because that generates unnecessary rexmits which are a prerequisite for > classical congestion collapse. > > It may well be in some environments that these hundreds of competing > flows are application limited (request-reply continuously) and get > started over a longer period of time, each getting RTT sample(s) over a > lightly loaded bottleneck and then becoming idle or sending data only > sporadically. Then later they all become active more or less at the same > time (maybe by a common trigger). Base RTT may then be much lower than > 500 ms as long as there is enough buffer bloat. > > Furthermore, timestamps are not that helpful in case of a heavily > congested small buffer bottleneck. Having approximately accurate SRTT > does not alone help in reducing the sending rate below 1 segment/RTT in > heavily congested scenarios. Exponential backoff of timer is a must. > > I believe that either of us know what's really out there employing > Internet for communication purposes. It does not matter whether it is a > notable percentage or not as long there is a group of users who are > encountering the envisioned problem. > It may very well be a small minority, but if this kind of a problem > escalates for this group very often (maybe almost always), it means we > are disabling use of Internet technology for them. > > > Furthermore, in cases like this where the number of flows is roughly > > equal to or greater than the BDP of the path, Reno/[RFC5681] and CUBIC > > will spend the majority of their time in loss recovery (the minimum > > ssthresh from [RFC5681] being 2*SMSS). > > Sure there is surprisingly lot to improve with TCP when the window needs > to be kept lower than 2 MSS or when the available share would be even > less than 1 MSS/RTT. RFC 5681 would exponentially back-off on every RTO, > leaving opportunity for other flows to make progress during the > backed-off interval. Once the sender is lucky and gets an Ack for a new > segment, min ssthresh of 2*MSS unfortunately allows it to accelerate to > 2*MSS/RTT and maybe more until RTO expires again. We cannot avoid some > drops or unnecessary rexmits. Actually, in such a heavily congested > scenario the combination of Karn's exponential back-off and slow start > results in Multiplicative Increase Multiplicative Decrease (MIMD) > behaviorwhich does not converge that well to fairness. But it avoids > congestion collapse. It is kind a tradeoff between safe and stable > behavior during heavy congestion and being able to ramp up fast when the > congestion fades away. Even though the current behavior is not ideal > for fairness, we should not make it even worse. > > Currently only way to avoid spending most of the time in loss > recovery seems to be ECN that would make a TCP sender to become rate > controlled once cwnd hits the minimum cwnd of 1 MSS(*). But there is a > lot to optimise also with ECN in this kind of scenario ... > > (*) to avoid anyone repeating the misconception that minimum cwnd is > 2 MSS per equation (4) in RFC 5681: equation (4) sets ssthresh, > not cwnd. RFC 3168 clearly states that cwnd must be halved on > an arrival of ECE; this holds until cwnd = 1 MSS. After this, > the sending rate of new segments is (RTO) timer controlled and > the timer avlue exponentially backed-off if more ECEs arrive. > At least two major OSs implement this incorrectly unless now > already fixed. > > > And the RACK-TLP ID specifies > > that TLP probes are not sent while in loss recovery. > > Maybe I missed it but I couldn't find an end condition of RTO recovery > for RACK-TLP purposes in the document. Regular RTO does not have such end > condition because it is not needed. Congestion control and loss recovery > are quite decoupled during RTO recovery; slow start follows its own > rules and ends when cwnd > ssthresh and loss recovery has its own > rules to select segments to rexmit and just moves on sending new data > once all lost segments have been retransmitted. Some implementations may > have such variable/condition but it didn't help me. > > Without timestamps, if TLP is not backed-off, a TLP is likely to be sent > for each new segment (assuming certain conditions). Each not backed-off > rexmit is potentially stealing an opportunity from another flow to get > its segment being delivered, thereby contributing to unfair use of > bottleneck resources. > > >>> What authors disagree is that RTO must be back-off on the first > >>> instance if TLP is not acked. While your suggestion helps the > >>> congestion case, it may also hurt the recovery in other cases when the > >>> TLP is dropped due to light/burst/transient congestion. Arguing which > >>> scenarios matter more subjectively is not productive. > >> > >> When RACK-TLP is required to be implemented by all TCP stacks, it > >> is extremely important that it always works in a safe way and congestion > >> is always the primary concern to get properly handled. Without arguing > >> more, I just want to point out that TCP must work reasonably for all > >> Internet users. That means it must not generate a situation where even a > >> small minority of the Internet users often or almost always encounter > >> severe problems with their connectivity. > >> > >> For example, also users in developing countries where possibly an entire > >> village shares just one mobile (cellular, maybe 3G possibly only GPRS) > >> connection for their Internet access and pays per amount of data should > >> get reasonable TCP behavior. In such a case, I cannot agree with > >> engineering that results in almost always getting only half of the > >> already scarce bandwidth whle paying double price fot the useful data. > >> > >> But thinking about a way forward. Karn's algorithm would require backing > >> off PTO even if you get Ack of PTO. Relaxing this does not sound me that > >> bad at all, because there is often a pause before TLP and a TCP sender > >> gets feedback, so apparently conditions are not that bad and loss > >> recovery gets triggered (hopefully in slow start). > >> If TLP is not acked, RTO is needed and recovery is completed in using > RTO > >> recovery in slow start. Now, if the RTO recovery is successful (no > >> losses during RTO recovery), it should be quite likely that the TCP > >> sender is able to successfully send also one new segment, because it > >> enters CA when it is sending at the half of the previous rate. So, once > >> you get Ack for the new segment, the TLP back off can be removed and it > >> is unlikely that the TLP back off slowed down next loss detection. > >> On the other hand, if the RTO recovery after an unsuccessful TLP is not > >> successful (more losses are detected), it is quite likely that > congestion > >> has not been resolved. So, it is important to be conservative and have a > >> backed-off PTO (or even turn it off) to avoid (further) unnecessary > >> rexmits. If PTO is not backed of, I'd envision PTO mainly failing to get > >> an Ack in such a case and thereby it not being that useful. > >> > >> This certainly would require experimental data in a heavily congested > >> setting to really figure out the actual impact of different > alternatives. > >> > >>> So the question we need to look at is if RACK-TLP 2RTT-PTO + regular > >>> RTO-backoff is going to cause major stability issues in extreme > >>> congestion. My understanding based on my officemate Van Jacobson's > >>> explanation is, as long as there's eventual exponential backoff, we'll > >>> avoid the repeated shelling the network. > >> > >> Right. But the problem is that with TLP as specified we do not have full > >> exponential back off. It lacks Karn's clamped retransmit backoff (as it > >> is called in Van Jacobson's seminal paper) which requires keeping > >> backed-off timer of a retransmitted segment for the next (new) segment > and > >> ensures that there is eventual exponential backoff. > >> Backing off just RTO is not enough, because "fixed" PTO for each new > >> segment breaks this "back-off chain", that is, the exponential backoff > >> is not continueed until there is evidence that congestion has been > >> resolved (a cumulative Ack arrives for new data). But as I said, backing > >> off RTO saves RACK-TLP from a full congestion collapse. Still, wasting > >> 50% of the available network capacity in certain usage scenarios does > not > >> sound acceptable for me. > > > > [RACK-TLP-team:] > > > > To address concerns related to Karn's algorithm, perhaps it would be > > sufficient to specify that after a RACK-TLP sender sends a TLP probe > > that is a retransmitted segment, it temporarily disables further TLP > > retransmissions until the sender obtains a valid RTT sample (i.e. from > > a non-retransmitted segment, or a segment with [RFC7323] TCP > > timestamps)? > > As a basic rule: disabling TLP probes for the period of loss recovery as > currently specified sounds like a correct approach provided that the end > condition > > "until the sender obtains a valid RTT sample" > > is added (this would be without timestamps, see some considerations with > timestamps later below). > > Then some justification and maybe some exeptions can also be specified > (all these without timestamps): > > If fast recovery is not entered via detecting loss using TLP, the > sender does not need to wait for a valid RTT sample. It should be enough > that RecoveryPoint is reached, i.e., use normal exit condition for fast > recovery. However, I am not sure whether detecting a loss of a rexmit > during fast recovery might change this? > > I think it does not matter whether a TLP probe is a retransmitted segment > or not: > > (a) if there is no ack after TLP probe and RTO expires it should be clear > that TLP must be disabled until an ack for a new previously not rexmitted > segment is received, regardless of the probe segment sent by TLP. > This is Karn's algorithm. > > (b) if TLP triggers an Ack that is used to detect a loss of an entire > flight of data, this may later during loss recovery result in an RTO > which definitely requires disabling TLP as per the basic rule. There > might be some exeptions when the basic rule is not necessary but it is > hard for me to figure one right now, except > > (c) if TLP rexmit detects and repairs a single loss, then CC is anyway > invoked and Ack is received. If the arriving Ack is triggered by the TLP > probe segment, it indicates that the conditions are likely not that bad > (RTO not needed). So it might be ok, to rearm PTO for the next time > without any backoff (without disbling it). However, > > (d) if TLP was spurious rexmit, then PTO value obviously was too low > (effective RTT may have increased suddenly and Acks got just delayed). > This is possibly detected only one RTT later when the DupAck of the TLP > rexmit arrives. TLP may have got rearmed by that time again with too > low value, so it should be rearmed with doubled value to avoid another > spurious TLP PTO (or disabled). > > Then with timestamps. I think the simple rule for disabling TLP "until > the sender obtains a valid RTT sample" is not necessarily giving the > desired outcome in all cases. For example, if a TLP probe is send and > then a late ack arrives for a segment sent before the TLP probe and gives > a valid RTT sample with help of timestamps. This would allow a new TLP > even though the sender has not got an Ack for a new segment sent after > the TLP probe? > > So, also with timestamps the requirement must be that the sender obtains > a valid RTT sample for a segment sent after the TLP probe. And, at least, > if RTO recovery is entered, then the Ack must be for a new segment. > Cannot figure out now all potential exceptions when a valid RTT sample > with timestamps would allow re-enabling TLP earlier. Too complex > algorithm with too many possible scenarios to investigate right now ;) > > A single, simple rule would be advisable here. Otherwise, this may end up > being too complex to get it right. > > > >>> As a matter of fact some > >>> major TCP (!= Linux) implementation has implemented linear backoff of > >>> first N RTOs before exp-backoff. > >> > >> But that's quite ok as long as there is eventual exponential backoff, > >> including Karn's clamped retransmit backoff. Linear back-off in the > >> beginning just makes resolving (heavy) congestion a bit slower. > >> > >>>> > >>>>>> > >>>>>> Additional notes: > >>>>>> > >>>>>> Sec 2.2: > >>>>>> > >>>>>> Example 2: > >>>>>> "Lost retransmissions cause a resort to RTO recovery, since > >>>>>> DUPACK-counting does not detect the loss of the retransmissions. > >>>>>> Then the slow start after RTO recovery could cause burst losses > >>>>>> again that severely degrades performance [POLICER16]." > >>>>>> > >>>>>> RTO reovery is done in slow start. The last sentence is confusing as > >>>>>> there is no (new) slow-start after RTO recovery (or more precisely > >>>>>> slow start continues until cwnd > ssthresh). Do you mean: if/when > slow > >>>>>> start still continues after RTO Recovery has repaired lost segments, > >>>>>> it may cause burst losses again? > >>>>> I mean the slow start after (the start of) RTO recovery. HTH > >>>> > >>>> Tnx. I'd appreciate if the text could be clarified to reflect this > more > >>>> accurately. Maybe something along the lines(?): > >>>> > >>>> "Then the RTO recovery in slow start could cause burst > >>>> losses again that severely degrades performance [POLICER16]." > >>>> > >>>>>> > >>>>>> Example 3: > >>>>>> "If the reordering degree is beyond DupThresh, the DUPACK- > >>>>>> counting can cause a spurious fast recovery and unnecessary > >>>>>> congestion window reduction. To mitigate the issue, [RFC4653] > >>>>>> adjusts DupThresh to half of the inflight size to tolerate the > >>>>>> higher degree of reordering. However if more than half of the > >>>>>> inflight is lost, then the sender has to resort to RTO recovery." > >>>>>> > >>>>>> This seems to be somewhat incorrect description of TCP-NCR > specified in > >>>>>> RFC 4653. TCP-NCR uses Extended Limited Transmit that keeps on > sending > >>>>>> new data segments on DupAcks that makes it likely to avoid an RTO in > >>>>>> the given example scenario, if not too many of the the new data > >>>>>> segments triggered by Extended Limited Transmit are lost. > >>>>> sorry I don't see how the text is wrong describing RFC4653, > >>>>> specifically the algorithm in adjusting ssthresh > >>>> > >>>> To my understanding RFC4653 initializes DupThresh to half of the > inflight > >>>> size in the beginning of the Extended Limited Transmit. Then on each > >>>> DupAck it adjusts (recalculates) DupThresh again such that ideally a > cwnd > >>>> worth of DupAcks are received before packet loss is declared (or > >>>> reordering detected). So, if I am not incorrect, loss of a half of the > >>>> inflight does not necessarily result in RTO recovery with TCP-NCR. > >>> Could you suggest the text you'd like on NCR description. > >> > >> I'm not an expert nor closely acquainted with NCR. There might be many > >> different packet loss patterns that may affect the behavior. So, my > >> advice is to simply drop the last sentence starting with "However ...", > >> because it seems incorrect and replace the second but last sentence: > >> > >> To mitigate the issue, [RFC4653] > >> adjusts DupThresh to half of the inflight size to tolerate the > >> higher degree of reordering. > >> > >> --> > >> > >> To mitigate the issue, TCP-NCR [RFC4653] > >> increases the DupThresh from the current fixed value of three > duplicate > >> ACKs [RFC5681] to approximately a congestion window of data having > left > >> the network. > > > > [RACK-TLP-team:] > > > > Sure, we will revise accordingly. > > Tnx. > > > > >>>>>> > >>>>>> Sec. 3.5: > >>>>>> > >>>>>> "For example, consider a simple case where one > >>>>>> segment was sent with an RTO of 1 second, and then the application > >>>>>> writes more data, causing a second and third segment to be sent > right > >>>>>> before the RTO of the first segment expires. Suppose only the > first > >>>>>> segment is lost. Without RACK, upon RTO expiration the sender > marks > >>>>>> all three segments as lost and retransmits the first segment. > When > >>>>>> the sender receives the ACK that selectively acknowledges the > second > >>>>>> segment, the sender spuriously retransmits the third segment." > >>>>>> > >>>>>> This seems incorrect. When the sender receives the ACK that > selectively > >>>>>> acknowledges the second segment, it is a DupAck as per RFC 6675 and > does > >>>>>> not increase cwnd and cwnd remains as 1 MSS and pipe is 1 MSS. So, > the > >>>>>> rexmit of the third segment is not allowad until the cumulative ACK > of > >>>>>> the first segment arrives. > >>>>> I don't see where RFC6675 forbids growing cwnd. Even if it does, I > >>>>> don't think it's a good thing (in RTO-slow-start) as DUPACK clearly > >>>>> indicates a delivery has been made. > >>>> > >>>> SACKed sequences with DUpAcks indicate that those sequences were > >>>> delivered but it does not tell when they were sent. The basic > principle > >>>> of slow start is to reliably determine the available network capacity > >>>> during slow start. Therefore, slow start must ensure it uses only > >>>> segments sent during the slow start to increase cwnd. Otherwise, a TCP > >>>> sender may encounter exactly the problem of unnecessary retransmission > >>>> envisioned in this example of RACK-TCP draft (and increase cwnd on not > >>>> valid Acks). > >>>> > >>>> RFC 6675 does re-specify DupAck with SACK option but it does not > include > >>>> the rule for slow start. Slow start is specified in RFC 5681. It is > >>>> crystal clear in allowing increase in cwnd only on cumulative > >>>> Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 5681, Sec 3, > >>>> page 6: > >>>> > >>>> During slow start, a TCP increments cwnd by at most SMSS bytes for > >>>> each ACK received that cumulatively acknowledges new data. > >>>> > >>>> Maybe this example in the RACK-TLP draft was inspired by a incorrect > >>>> implementation of SACK-based loss recovery? > >>>> > >>>> FYI: when we were finalizing RFC 6675 I suggested including also an > >>>> algorithm for RTO recovery with SACK in RFC 6675. The reason was > exactly > >>>> that it might be not easy to gather info from multiple documents and > >>>> hence help the implementor to have all necessary advice in a single > >>>> document. This unfortunately did not get realized though. > >>> > >>> I am honestly lost quibbling these RFC6675 implementations and feeling > >>> pedantic to these standards largely serve as guiding principles > >>> instead of line-by-line code. Is cwnd one packet bigger or smaller in > >>> this example making any different in advancing the Internet's > >>> capability to do better loss detection. I do not think so. > >> > >> Sorry, I don't understand what was quibbling here. I believe I did not > >> argue anything about cwnd size with this example at hand in Sec. 3.5. > >> My point is that it describes incorrect slow start behavior. Correctly > >> implemented slow start does not have the problem illustriated in the > >> example. > >> > >>> At this point please suggest a text you like to change. > >> > >> That is simple. Please remove the description of the behavior without > >> RACK. Or correct it: the behavior would be exactly the same as with > RACK, > >> but the reason for not unnecessarily retransmitting third segment can be > >> described to be different. > >> And, please correct also the description with RACK. With RACK, third > >> segment does not get unnecessarly rexmitted for the reason already > >> indicated and also because cwnd=1 MSS. And, no new segments are allowed > >> either by cwnd=1. > >> > > > > [RACK-TLP-team:] > > > > Thanks. Perhaps it makes sense to consider a slightly different RTO > > scenario to illustrate the point about how RACK RTO behavior can avoid > > spurious retransmissions. > > > > Here is the proposed new text: > > > > "3.5. An Example of RACK-TLP in Action: RTO > > > > In addition to enhancing fast recovery, RACK improves the accuracy of > > RTO recovery by reducing spurious retransmissions. > > > > Without RACK, upon RTO timer expiration the sender marks all the > > unacknowledged segments lost. This approach can lead to spurious > > retransmissions. For example, consider a simple case where one > > segment was sent with an RTO of 1 second, and then the application > > writes more data, causing a second and third segment to be sent right > > before the RTO of the first segment expires. Suppose none of the > > segments were lost. Without RACK, if there is a spurious RTO then > > the sender marks all three segments as lost and retransmits the > > first segment. If the ACK for the original copy of the first segment > > arrives right after the spurious RTO retransmission, then the > > sender continues slow start and spuriously retransmits the second > > and third segments, since it (erroneously) presumed they are lost. > > That seems fine. Would it be useful to add an additional note saying that > if F-RTO is in use, then further unnecessary retransmissions can be > avoided? > > > With RACK, upon RTO timer expiration the only segment automatically > > marked lost is the first segment (since it was sent an RTO ago); for > > all the other segments RACK only marks the segment lost if at least > > one round trip has elapsed since the segment was transmitted. > > Consider the previous example scenario, this time with RACK. With > > RACK, when the RTO expires the sender only marks the first segment as > > lost, and retransmits that segment. The other two very recently sent > > segments are not marked lost, because they were sent less than one > > round trip ago and there were no ACKs providing evidence that they > > were lost. Upon receiving the ACK for the RTO retransmission the > > RACK sender would not yet retransmit the second or third segment. but > > rather would rearm the RTO timer and wait for a new RTO interval to > elapse > > before marking the second or third segments as lost. > > " > > This behavior with RACK-TLP does not quite match with my reading of > the draft in all parts, so I have some questions. > > First, wouldn't the PTO timer be first running for the first segment > and when the sender sends the 2nd and 3rd segment it would rearm PTO for > the 3rd segment? My understanding based on Sec 8 is that RTO cannot be > armed until PTO fires? And when the PTO fires, the sender would > retransmit the 3rd segment? Maybe I am missing something? > > Anyways, an RTO timer may expire in this scenario (e.g., if there is no > Ack for TLP). > Let's assume the RTO timer expires as described. When the first Ack after > the rexmit of the 1st segment arrives, isn't that the late ACK for the > original copy of the first segment, not the ACK for the RTO > retransmission? Anyways, when this first Ack arrives after the RTO, the > second and third segment are not marked as lost as described, which > nicely prevents unnecessary retransmissions of those segments. > However, if the 2nd and 3rd segments were lost, wouldn't rearming RTO > with exponentially backed-off timer value (2*RTO) make the recovery of > the 2nd and 3rd segment very slow? After 2*RTO the timer expires and > the 2nd segment is rexmitted and only after one additional RTT when the > ack for the 2nd segment arrives, the sender rexmits the 3rd segment? > Wouldn't it be much more efficient to disable RACK loss detection during > an RTO recovery and employ F-RTO? Maybe I am missing something again? > > > Then to the problem with the pseudocode I mentioned in the beginning of > this message. If I am not incorrect it seems to me that setting a value > to TLP.end_seq in TLP_send_probe() is off by one byte? Maybe something > similar is wrong somewhere else too, didn't check. Please apologise me if > I missed something. > > Let's use an example with RACK-TLP recovery: > > Send P1, ..., P9, P10 > [P1,.., P9 delayed, P10 dropped] > /* I believe P1-9 delayed is not important here */ > > After 2*SRTT PTO expires > P10 rexmitted by TLP > [ TLP_send_probe(): set TLP.end_seq = SND.NXT (= SEG.P11) ] > > [after TLP, the application possibly provides more data to send] > > Ack for original P1 arrives > (P11 sent, if more data by application) > Ack for original P2 arrives > (P12 sent, if more data by application) > ... > Ack for original P9 arrives > (P19 sent, if more data by application) > > Ack for P10 triggered by TLP rexmit of P10 arrives > [TLP_process_ack(ACK): > ... > If ACK's ack. number > TLP.end_seq > returns False > since ACK's ack. number = SEQ.ACK = TLP.end_seq = SEG.P11] > > Loss of P10 is undetected and no reaction to congestion] > > > My understanding of draft text is that a loss of P10 is not concealed. > Please advise. > > Best regards, > > /Markku > > > best regards, > > > > neal > > > >> Please remove also the last paragraph of the Sec. 3.5, it being also > >> incorrect description of behavior. > >> > >> BR, > >> > >> /Markku > >> > >>>> > >>>> BR, > >>>> > >>>> /Markku > >>>> > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> /Markku > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, 16 Nov 2020, The IESG wrote: > >>>>>> > >>>>>>> > >>>>>>> The IESG has received a request from the TCP Maintenance and Minor > Extensions > >>>>>>> WG (tcpm) to consider the following document: - 'The RACK-TLP loss > detection > >>>>>>> algorithm for TCP' > >>>>>>> as Proposed Standard > >>>>>>> > >>>>>>> The IESG plans to make a decision in the next few weeks, and > solicits final > >>>>>>> comments on this action. Please send substantive comments to the > >>>>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptionally, > comments may > >>>>>>> be sent to iesg@ietf.org instead. In either case, please retain > the beginning > >>>>>>> of the Subject line to allow automated sorting. > >>>>>>> > >>>>>>> Abstract > >>>>>>> > >>>>>>> > >>>>>>> This document presents the RACK-TLP loss detection algorithm for > TCP. > >>>>>>> RACK-TLP uses per-segment transmit timestamps and selective > >>>>>>> acknowledgements (SACK) and has two parts: RACK ("Recent > >>>>>>> ACKnowledgment") starts fast recovery quickly using time-based > >>>>>>> inferences derived from ACK feedback. TLP ("Tail Loss Probe") > >>>>>>> leverages RACK and sends a probe packet to trigger ACK feedback > to > >>>>>>> avoid retransmission timeout (RTO) events. Compared to the > widely > >>>>>>> used DUPACK threshold approach, RACK-TLP detects losses more > >>>>>>> efficiently when there are application-limited flights of data, > lost > >>>>>>> retransmissions, or data packet reordering events. It is > intended to > >>>>>>> be an alternative to the DUPACK threshold approach. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The file can be obtained via > >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> No IPR declarations have been submitted directly on this I-D. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> tcpm mailing list > >>>>>>> tcpm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>>>>> > >>>>> > >>> > > > --0000000000008b36fd05b68979f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Markku,

Thanks for the co= mments. The authors will incorporate many of your suggestions after the IES= G review.

There's one thing I don't unders= tand in your comments:

" That is,
where can an implementer find advice for correct congestion control
actions with RACK-TLP, when:

(1) a loss of rexmitted segment is detected
(2) an entire flight of data gets dropped (and detected),
=C2=A0 =C2=A0 =C2=A0that is, when there is no feedback available and a time= out
=C2=A0 =C2=A0 =C2=A0is needed to detect the loss "

=
Section 9.3 is the discussion about CC, and is clear that the im= plementer should use either 5681 or 6937.

You went= through the 6937 case in detail.

If 5681, it&= #39;s pretty clear to me that in (1) this is a new loss detection after ack= nowledgment of new data, and therefore requires a second halving of cwnd. F= or (2), the RTO timer is still operative so the RTO recovery rules would st= ill follow.

In other words, I am not seeing a case= that requires new congestion control concepts except as discussed in 9.3.<= br>

What am I missing?

On Tue, Dec 15, 2020 at 10:57 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:
Hi Neal, all,

(my apologies for this message getting so long but I didn't want to dro= p
any parts of it in case someone wants to get the entire discussion in one <= br> piece. Also, apologies for repeating some of my concerns inline below;
Those who are clear with the problems may well opt skipping those parts.)
Thanks Neal for the reply. I believe we are slowly converging with many of my comments but two of the important issues still remain open. That is, =
where can an implementer find advice for correct congestion control
actions with RACK-TLP, when:
(1) a loss of rexmitted segment is detected
(2) an entire flight of data gets dropped (and detected),
=C2=A0 =C2=A0 =C2=A0that is, when there is no feedback available and a time= out
=C2=A0 =C2=A0 =C2=A0is needed to detect the loss

I fully understand the intent of the RACK-TLP draft not to include
congestion control actions in this document (or the intent to minimise
such advise). However, when new ways to detect loss are introduced and
published (as this document would do), IMHO it is imperative to have such <= br> congestion control actions readily available for an implementer. AFAIK
we do not have in the RFC series correct actions available for these two cases.

I do not have a strong opinion whether the necessary actions should be in <= br> this document or in another document, as long as we have them. This is
more or less a process decision, I think.

Please see more details inline.

I also investigated a bit more on RACK-TLP as specified in the draft and it seems that there is a problem with the pseudocode as currently
presented (some sequence numbers seem to be off by one, resulting in
wrong outcome in some/many? cases). Please see inline in the end of my
reply.


=C2=A0 On Sat, 12 Dec 2020, Neal Cardwell wrote:

> Hi Markku,
>
> Thanks for your many detailed and thoughtful comments. Please see
> below in-line for our comments based on discussions among RACK-TLP
> draft authors.
>
> On Tue, Dec 8, 2020 at 11:21 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:
>>
>> Hi,
>>
>> please see inline.
>>
>> On Mon, 7 Dec 2020, Yuchung Cheng wrote:
>>
>>> On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo <kojo@cs.helsinki.fi> wrote= :
>>>>
>>>> Hi Yuchung,
>>>>
>>>> thanks for your reply. My major point is that IMHO this RA= CK-TLP
>>>> specification should give the necessary advice w.r.t conge= stion control
>>>> in cases when such advice is not available in the RFC seri= es or is not
>>>> that easy to interpreted correctly from the existing RFCs.=
>>>>
>>>> Even though the CC principles were available in RFC series= I believe you
>>>> agree with me that getting detailed CC actions correct is = sometimes quite
>>>> hard, especially if one needs to interpret and apply them = from another
>>>> spec than what one is implementing. Please see more detail= s inline below.
>>>>
>>>> In addition, we need to remember that this document is not= meant only for
>>>> TCP experts following the tcpm list and having deep unders= tanding of
>>>> congestion control but also those implementing TCP, for th= e very first
>>>> time, for various appliances, for example. They do not hav= e first hand
>>>> experience in implementing TCP congestion control and dese= rve clear
>>>> advice what to do.
>>>>
>>>> On Fri, 4 Dec 2020, Yuchung Cheng wrote:
>>>>
>>>>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo <kojo@cs.helsinki.fi&g= t; wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I know this is a bit late but I didn't have ti= me earlier to take look at
>>>>>> this draft.
>>>>>>
>>>>>> Given that this RFC to be is standards track and R= ECOMMENDED to replace
>>>>>> current DupAck-based loss detection, it is importa= nt that the spec is
>>>>>> clear on its advice to those implementing it. Curr= ent text seems to
>>>>>> lack important advice w.r.t congestion control, an= d even though
>>>>>> the spec tries to decouple loss detection from con= gestion control
>>>>>> and does not intend to modify existing standard co= ngestion control
>>>>>> some of the examples advice incorrect congestion c= ontrol actions.
>>>>>> Therefore, I think it is worth to correct the mist= akes and take
>>>>>> yet another look at a few implications of this spe= cification.
>>>>> As you noted, the intention is to decouple the two as = much as possible
>>>>>
>>>>> Unlike the 20 years ago where TCP loss detection and c= ongestion
>>>>> control are essentially glued in one piece, the decoup= ling of the two
>>>>> (including modularizing congestion controls in impleme= ntations) has
>>>>> helped fueled many great inventions of new congestion = controls.
>>>>> Codifying so-called-default C.C. reactions in the loss= detection is a
>>>>> step backward that the authors try their best to avoid= .
>>>>
>>>> While I fully agree with the general principle of decoupli= ng loss
>>>> detection from congestion control when it is possible with= out leaving
>>>> open questions, I find it hard to get congestion control r= ight with this
>>>> spec in certain cases I raised just by following the curre= nt standards
>>>> track CC specifications. The reason for this is that RACK-= TLP introduces
>>>> new ways to detect loss (i.e., not present in any earlier = standard track
>>>> RFC) and the current CC specifications do not provide corr= ect CC actions
>>>> for such cases as I try to point out below.
>>>>
>>>>> To keep the
>>>>> document less "abstract / unclear" as many W= GLC reviewers commented,
>>>>> we use examples to illustrate that includes CC actions= . But the
>>>>> details of these CC actions are likely to become obsol= ete as CC
>>>>> continues to advance hopefully.
>>>>
>>>> Agreed. But I would appreciate if the CC actions in the ex= amples would
>>>> correctly follow what is specified in the the current CC R= FCs. And, I
>>>> would suggest explicitly citing the RFC(s) that each of th= e examples is
>>>> illustriating so that there is no doubt which CC variant t= he example
>>>> is valid with. Then there is no problem with the correctne= ss of the
>>>> example either even if the cited RFC becomes later obsolet= ed.
>>>>
>>>>>>
>>>>>> Sec. 3.4 (and elsewhere when discussing recovering= a dropped
>>>>>> retransmission):
>>>>>>
>>>>>> It is very useful that RACK-TLP allows for recover= ing dropped rexmits.
>>>>>> However, it seems that the spec ignores the fact t= hat loss of a
>>>>>> retransmission is a loss in a successive window th= at requires reacting
>>>>>> to congestion twice as per RFC 5681. This advice m= ust be included in
>>>>>> the specification because with RACK-TLP recovery o= f dropped rexmit
>>>>>> takes place during the fast recovery which is very= different
>>>>>> from the other standard algorithms and therefore e= asy to miss
>>>>>> when implementing this spec.
>>>>>
>>>>> per RFC5681 sec 4.3 https://tool= s.ietf.org/html/rfc5681#section-4.3
>>>>> "Loss in two successive windows of data, or the l= oss of a
>>>>>=C2=A0 retransmission, should be taken as two indicatio= ns of congestion and,
>>>>>=C2=A0 =C2=A0therefore, cwnd (and ssthresh) MUST be low= ered twice in this case."
>>>>>
>>>>> RACK-TLP is a loss detection algorithm. RFC5681 is cry= stal clear on
>>>>> this so I am not sure what clause you suggest to add t= o RACK-TLP.
>>>>
>>>> Right, this is the CC *principle* in RFC 5681 I am referin= g to but I am
>>>> afraid it is not enough to help one to correctly implement= such lowering
>>>> of cwnd (and ssthresh) twice when a loss of a retransmissi= on is detected
>>>> during Fast Recovery. Nor do RFCs clearly advice *when* th= is reduction
>>>> must take place.
>>>>
>>>> Congestion control principles tell us that congestion must= be reacted
>>>> immediately when detected. But at the same time, standards= track CC
>>>> specifications react to congestion only once during Fast R= ecovery
>>>> because the losses in the current window, which Fast Recov= ery repairs,
>>>> occured during the same RTT. That is, the current CC speci= fications do
>>>> not handle lost rexmits during Fast Recovery but, instead,= the correct CC
>>>> reaction to a loss of a rexmit is automatically achieved b= y those
>>>> specifications via RTO when cwnd is explicitly reset upon = RTO.
>>>>
>>>> Furthermore, the problem I am trying to point out is that = there is no
>>>> correct rule/formula available in the standards track RFCs= that would
>>>> give the correct way to reduce cwnd when the loss of rexmi= t is detected
>>>> with RACK-TLP.
>>>>
>>>> I suggest everyone reading this message stops reading at t= his point
>>>> for a while before continuing reading and figures out them= selves what
>>>> they think would be the correct equation to use in the sta= ndards RFC
>>>> series to find the new halved value for cwnd when RACK-TLP= detects a loss
>>>> of a rexmit during Fast Recovery. I would appreciate a com= ment on the
>>>> tcpm list from those who think they found the correct answ= er immediately
>>>> and easily, and what was the formula to use.
>>>>
>>>> ...
>>>>
>>>> I think the best advice one may find by looking at RFC 667= 5 (and RFC
>>>> 5681) is to set
>>>>
>>>>=C2=A0 =C2=A0ssthresh =3D cwnd =3D (FlightSize / 2) (RFC 66= 75, Sec 5, algorithm step 4.2)
>>>>
>>>> Now, let's modify the example in Sec 3.4 of the draft:=
>>>>
>>>> 1. Send P0, P1, P2, ..., P20
>>>>=C2=A0 =C2=A0 [Assume P1, ..., P20 dropped by network]
>>>>
>>>> 2.=C2=A0 =C2=A0Receive P0, ACK P0
>>>> 3a.=C2=A0 2RTTs after (2), TLP timer fires
>>>> 3b.=C2=A0 TLP: retransmits P20
>>>> ...
>>>> 5a.=C2=A0 Receive SACK for P20
>>>> 5b.=C2=A0 RACK: marks P1, ..., P20 lost
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0set cwnd=3Dssthresh=3DFlightSize= /2=3D10
>>>> 5c.=C2=A0 Retransmit P1, P2 (and some more depending on ho= w CC implemented)
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 retransmission dropped by ne= twork]
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Receive SACK P2 & P3
>>>> 7a.=C2=A0 RACK: marks P1 retransmission lost
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0As per RFC 6675: set cwnd=3Dssth= resh=3DFlightSize/2=3D20/2=3D10
>>>> 7b.=C2=A0 Retransmit P1
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>
>>>> So, is the new value of the cwnd (10MSS) correct and halve= d twice? If not,
>>>> where is the correct formula to do it?
>>>>
>>>> Before RFC 5681 was published we had a discussion on Fligh= Size and that
>>>> during Fast Recovery it does not reflect the amount of seg= ments in
>>>> flight correctly but may also have a too large value. It w= as decided not
>>>> to try to correct it because it only has an impact when RT= O fires during
>>>> Fast Recovery and in such a case cwnd is reset to 1 MSS. H= aving too large
>>>> ssthresh for RTO recovery in some cases was not considered= that bad
>>>> because a TCP sender anyway takes to most conservative CC = action with the
>>>> cwnd and would slow start from cwnd =3D 1 MSS. But now whe= n RACK-TLP enables
>>>> detecting loss of a rexmit during Fast Recovery we have an= unresolved
>>>> problem.
>>>
>>>> 1. Send P0, P1, P2, ..., P20
>>>>=C2=A0 =C2=A0 [Assume P1, ..., P20 dropped by network]
>>>>
>>>> 2.=C2=A0 =C2=A0Receive P0, ACK P0
>>>> 3a.=C2=A0 2RTTs after (2), TLP timer fires
>>>> 3b.=C2=A0 TLP: retransmits P20
>>>> ...
>>>> 5a.=C2=A0 Receive SACK for P20
>>>> 5b.=C2=A0 RACK: marks P1, ..., P20 lost
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0set cwnd=3Dssthresh=3DFlightSize= /2=3D10
>>>> 5c.=C2=A0 Retransmit P1, P2 (and some more depending on ho= w CC implemented)
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 retransmission dropped by ne= twork]
>>>>
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Receive SACK P2 & P3
>>>> 7a.=C2=A0 RACK: marks P1 retransmission lost
>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0As per RFC 6675: set cwnd=3Dssth= resh=3DFlightSize/2=3D20/2=3D10
>>>> 7b.=C2=A0 Retransmit P1
>>>
>>> To account for your points, IMO clearly stating the existing C= C RFC
>>> interactions w/o mandating any C.C. actions are the best way t= o move
>>> forward. Here are the text diff I proposed:
>>>
>>> "Figure 1, above, illustrates=C2=A0 ...
>>> Notice a subtle interaction with existing congestion control a= ctions
>>> on event 7a. It essentially starts another new episode of cong= estion
>>> due to the detection of lost retransmission. Per RFC5681 (sect= ion 4.3)
>>> that loss in two successive windows of data, or the loss of a<= br> >>> retransmission, should be taken as two indications of congesti= on as a
>>> principle. But RFC6675 that introduces the pipe concept does n= ot
>>> specify such a second window reduction. This document reminds = RACK-TLP
>>
>> This is not quite correct characterization of RFC 6675.
>> RFC 6675 does not repeat all guidelines of RFC 5681. RFC 6675 DOES= specify
>> the two indications of congestion implicitly by clearly stating in= the
>> intro that it follows the guidelines set in RFC=C2=A0 5681.
>> And RFC 5681 articulates a set of MUSTs which ALL alternative loss=
>> recovery algorithms MUST follow in order to become RFCs.
>>
>> (*) RFC 5681, Sec 4.3 (pp. 12-13):
>>
>>=C2=A0 =C2=A0"While this document does not standardize any of = the
>>=C2=A0 =C2=A0 specific algorithms that may improve fast retransmit/= fast recovery,
>>=C2=A0 =C2=A0 ...
>>=C2=A0 =C2=A0 That is, ...
>>=C2=A0 =C2=A0 Loss in two successive windows of data, or the loss o= f a
>>=C2=A0 =C2=A0 retransmission, should be taken as two indications of= congestion and,
>>=C2=A0 =C2=A0 therefore, cwnd (and ssthresh) MUST be lowered twice = in this case."
>>
>>
>>> implementation to carefully consider the new multiple congesti= on
>>> episode cases in the corresponding congestion control." >>
>> I am sorry to say that this is very fuzzy and leaves an implemente= r
>> all alone what to do.
>>
>> More inportantly, AFAIK we have no discussion nor consensus in the= IETF
>> on what is the correct CC action when lost rexmit is detected.
>> Should one reset cwnd like current CCs do, or would "halving = again" be
>> fine, or something else? IMHO this requires experimentation to dec= ide.
>>
>> I assumed there is an implementation of RACK-TLP with correspondin= g CC
>> actions and experimental results to devise what are the implicatio= ns of
>> the selected CC action(s) with various levels of congestion. But i= t seems
>> we do not have such implementation nor experimental evidence? Am I= wrong?
>
> [RACK-TLP-team:]
>
> We do have such implementations of RACK-TLP with corresponding CC
> actions, and experimental results were reported in RACK-TLP
> presentations and earlier revisions of the RACK-TLP draft. With

Yes, that was my understanding what is implemented. Given there is this implementation that reacts appropriately to congestion when RACK-TLP
detects loss of a retransmitted segment, could you please illuminate the congestion control actions taken in the implementation with which there is experimental experience.

If I understood it correctly, the RACK-TLP in question is implemented
with PRR. Let's assume another implementer wants to add RACK-TLP with P= RR
in the stack she/he is working on. I believe that the implementer would think that detecting a loss of a rexmit during fast recovery would start a new congestion episode in PRR (and that's what Yuchung also indicated=
in the new proposed text in his previeous reply shown above). With
that advice and reading RFC 6937, an implementer would reinitialize PRR state for the new congestion episode. So how should the implementer
calculate new values for ssthresh and RecoverFS? Should she/he use what is currently described in RFC 6937, Sec 3 (to keep discussion simple
assume the implementer wants to have an IETF Standards Track comformant implementation, so use CongCtrlAlg() =3D FlightSize/2):

=C2=A0 ssthresh =3D CongCtrlAlg()=C2=A0 // Target cwnd after recovery
=C2=A0 prr_delivered =3D 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Total bytes = delivered during recovery
=C2=A0 prr_out =3D 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= // Total bytes sent during recovery
=C2=A0 RecoverFS =3D snd.nxt-snd.una // FlightSize at the start of recovery=

Or should one use something else? AFAIK depending on the loss pattern
neither FlightSize nor "snd.nxt-snd.una" would give correct value= s for
the intended behavior. Depending on the loss pattern, at the time
of detecting a loss of rexmit FlighSize may be ~ 50% larger than in the beginning of fast recovery. This would result in increasing ssthresh
(send rate), instead of decreasing it. It seems that something else in
PRR algo would also need to be modified to get sndcnt correct but I
cannot figure it out right now.

If one wants to implement RACK-TLP without PRR, that is, with RFC 6675, we have the same probelm with FlightSize in determining a new value for cwnd and ssthresh.

My point is that using what we currently have out there in the RFC
series gives incorrect CC advice. And, having correct CC actions in this case is far from trivial so IMHO high quality standards specifications
should not leave an implementer of RACK-TLP alone to figure it out.

In addition, if a new episode of fast recovery is started for CC purposes <= br> how would that play together with RACK-TLP loss detection? In Sec 7.1 the <= br> text says initialize (reset) TLP.end_seq and TLP.is_retrans when
initiating fast recovery. But detecting a lost rexmit seemingly should
not reinitialize TLP because PTO is disabled during fast recovery as per Sec 7.2. If CC actions are in another document and loss detection in this <= br> document, it would be of high importance to clarify when each of the
fast recovery episodies (CC vs. loss detection) are supposed to end: is the end condition the same or different?

> respect to implementations, there is the Linux TCP stack, which has > been using RACK-TLP as the default loss recovery algorithm since Linux=
> v4.18 in August 2018. The exact commit is:
>
>=C2=A0 b38a51fec1c1 tcp: disable RFC6675 loss detection
>
> With Linux, the default sender behavior since that commit has been
> governed by CUBIC, PRR, and RACK-TLP.
>
> RACK-TLP is used by all Google TCP traffic, including internal RPC
> traffic and external YouTube and google.com traffic over the public
> Internet. At Google we have years of high-traffic-volume experience > with RACK-TLP with three different CC schemes: CUBIC+PRR, BBRv1, and > BBRv2.
>
> My understanding is that Netflix FreeBSD TCP traffic uses RACK-TLP, > and Microsoft Windows TCP traffic has also been using RACK-TLP.

And I wonder what would be the CC actions taken in each of these
implementations when a loss of rexmited segment is detected?

>> I sincerely apologize that this got raised this late in the proses= s and
>> I know how irritating it may be. I like the idea of RACK-TLP and b= y no
>> means my intention is not to hold up the process but the lack of e= vidence
>> makes me quite concerned. In particular, when this document says t= hat
>> the current loss detection SHOULD be replaced in all implementatio= ns with
>> RACK-TLP.
>>
>>> and to emphasize in section 9.3 Interaction with congestion co= ntrol
>>>
>>> "9.3.=C2=A0 Interaction with congestion control
>>>
>>> RACK-TLP intentionally decouples loss detection ... this appro= priate.
>>> As mentioned in Figure 1 caption, RFC5681 mandates a principle= that
>>> Loss in two successive windows of data, or the loss of a
>>> retransmission, should be taken as two indications of congesti= on, and
>>> therefore reacted separately. However implementation of RFC667= 5 pipe
>>> algorithm may not directly account for this newly detected con= gestion
>>> events properly. Therefore the documents reminds RACK-TLP
>>> implementation to carefully consider these implications in its=
>>> corresponding congestion control.
>>>
>>> ..."
>>>
>>>
>>>
>>>>
>>>>
>>>>>> Sec 9.3:
>>>>>>
>>>>>> In Section 9.3 it is stated that the only modifica= tion to the existing
>>>>>> congestion control algorithms is that one outstand= ing loss probe
>>>>>> can be sent even if the congestion window is fully= used. This is
>>>>>> fine, but the spec lacks the advice that if a new = data segment is sent
>>>>>> this extra segment MUST NOT be included when calcu= lating the new value
>>>>>> of ssthresh as per the equation (4) of RFC 5681. S= uch segment is an
>>>>>> extra segment not allowed by cwnd, so it must be e= xcluded from
>>>>>> FlightSize, if the TLP probe detects loss or if th= ere is no ack
>>>>>> and RTO is needed to trigger loss recovery.
>>>>>
>>>>> Why exclude TLP (or any data) from FlightSize? The con= gestion control
>>>>> needs precise accounting of the flight size to react t= o congestion
>>>>> properly.
>>>>
>>>> Because FlightSize does not always reflect the correct amo= unt of data
>>>> allowed by cwnd. When a TCP sender is not already in loss = recovery and
>>>> it detects loss, this loss indicates the congestion point = for the TCP
>>>> sender, i.e., how much data it can have outstanding. It is= this amount of
>>>> data that it must use in calculating the new value of cwnd= (and
>>>> ssthresh), so it must not include any data sent beyond the= congestion
>>>> point. When TLP sends a new data segment, it is beyond the= congestion
>>>> point and must not be included. Same holds for the segment= s sent via
>>>> Limited Transmit: they are allowed to be send out by the p= acket
>>>> conservation rule (DupAck indicates a pkt has left the net= work, but does
>>>> not allow increasing cwnd), i.e., the actual amount of dat= a in flight
>>>> remains the same.
>>>>
>>>>>> In these cases the temporary over-commit is not ac= counted for as DupAck
>>>>>> does not decrease FlightSize and in case of an RTO= the next ACK comes too
>>>>>> late. This is similar to the rule in RFC 5681 and = RFC 6675 that prohibits
>>>>>> including the segments transmitted via Limitid Tra= nsmit in the
>>>>>> calculation of ssthresh.
>>>>>>
>>>>>> In Section 9.3 a few example scenarios are used to= illustriate the
>>>>>> intended operation of RACK-TLP.
>>>>>>
>>>>>>=C2=A0 =C2=A0In the first example a sender has a co= ngestion window (cwnd) of 20
>>>>>>=C2=A0 =C2=A0segments on a SACK-enabled connection.= =C2=A0 It sends 10 data segments
>>>>>>=C2=A0 =C2=A0and all of them are lost.
>>>>>>
>>>>>> The text claims that without RACK-TLP the ending c= wnd would be 4 segments
>>>>>> due to congestion window validation. This is incor= rect.
>>>>>> As per RFC 7661 the sender MUST exit the non-valid= ated phase upon an
>>>>>> RTO. Therefore the ending cwnd would be 5 segments= (or 5 1/2 segments if
>>>>>> the TCP sender uses the equation (4) of RFC 5681).=
>>>>>>
>>>>>> The operation with RACK-TLP would inevitably resul= t in congestion
>>>>>> collapse if RACK-TLP behaves as described in the e= xample because
>>>>>> it restores the previous cwnd of 10 segments after= the fast recovery
>>>>>> and would not react to congestion at all! I think = this is not the
>>>>>> intended behavior by this spec but a mistake in th= e example.
>>>>>> The ssthresh calculated in the beginning of loss r= ecovery should
>>>>>> be 5 segments as per RFC 6675 (and RFC 5681).
>>>>> To clarify, would this text look more clear?
>>>>>
>>>>> 'an ending cwnd set to the slow start threshold of= 5 segments (half of
>>>>> the original congestion window of 10 segments)' >>>>
>>>> This is correct, but please replace:
>>>>
>>>>=C2=A0 =C2=A0(half of the original congestion window of 10 = segments)
>>>> -->
>>>>=C2=A0 =C2=A0(half of> the original FlightSize of 10 seg= ments)
>>>
>>> sure will do
>>>
>>>>
>>>> cwnd in the example was 20 segments.
>>>>
>>>> Please also correct the ending cwnd for "without RACK= " scenario.
>>>> I poined out wrong equation number IN RFC 5681 and INCORRE= CT cwnd value,
>>>> my apologies. It MAENT equation (3) AND that results in en= ding cwnd of 5
>>>> and 2/5 MSS (not 5 and 1/2 MSS).
>>>> NB: and if a TCP sender implements entering CA when cwnd &= gt; ssthresh, then
>>>> ending cwnd would be 6 and 1/6 MSS).
>>>>
>>>>>>
>>>>>> Furthermore, it seems that this example with RACK-= TLP refers to using
>>>>>> PRR_SSRB which effectively implements regular slow= start in this
>>>>>> case(?). From congestion control point of view thi= s is correct because
>>>>>> the entire flight of data as well as ack clock was= lost.
>>>>>>
>>>>>> However, as correctly discussed in Sec 2, congesti= on window must be reset
>>>>>> to 1 MSS when an entire flight of data is and Ack = clock is lost. But how
>>>>>> can an implementor know what to do if she/he is no= t implementing the
>>>>>> experimental PRR algrorithm? This spec articulates= specifying an
>>>>>> alternative for DupAck counting, indicating that T= LP is used to trigger
>>>>>> Fast Retransmit & Fast Recovery only, not a lo= ss recovery in slow start.
>>>>>> This means that without an additional advise an im= plementation of this
>>>>>> spec would just halve the cwnd and ssthresh and se= nd a potentially very
>>>>>> large burst of segments in the beginning of the Fa= st Recovery because
>>>>>> there is no ack clock. So, this spec begs for an a= dvise (MUST) when to
>>>>>> slow start and reset cwnd and when not, or at leas= t a discussion of
>>>>>> this problem and some sort of advise what to do an= d what to avoid.
>>>>>> And, maybe a recommendation to implement it with P= RR?
>>>>>
>>>>> It's wise to decouple loss detection (RACK-TLP) vs= congestion/burst
>>>>> control (when to slow-start). The use of PRR is just a= n example to
>>>>> illustrate and not meant for a recommendation.
>>>>
>>>> I understand the use of PRR was just an example, but my po= int is that if
>>>> one wants to implement RACK-TLP but does not intend to imp= lement PRR but
>>>> RFC 6675 then we do not have a rule in RFC 6675 to correct= ly implement
>>>> CC for the case when an entire flight is lost and loss is = detected with
>>>> TLP. Congestion control principle for this is clear and al= so stated in
>>>> this draft but IMHO it is not enough to ensure correct imp= lementation.
>>>>
>>>> To my understanding we only have implementation experience= for RACK-TLP
>>>> only togerher with PRR, which has the necessary rule to ha= ndle this kind
>>>> of scenario correctly.
>>>>
>>>> So, my question is how can one implement CC correctly with= out PRR such
>>>> a scenario where entire inflight is lost?
>>>> Which rule and where in the RFC series gives the necessary= guidance to
>>>> reset cwnd and slow start when TCP detets loss of an entir= e flight?
>>>
>>> I think we're going in loops. To move forward it'd hel= p if you suggest
>>> some text you like to change.
>>
>> Unfortunately I do not have an immediate solution. I assumed there= is an
>> implementation and you could enlighten what was the solution there= and
>> experimental results showing how it seems to work. If I have under= stood
>> it correctly there is a solution/implementation and experience of = RACK-TLP
>> that works together with PRR but no solution/implementation nor ex= perience
>> how it works without PRR. Am I correct?
>
> [RACK-TLP-team:]
>
> The implementation solutions and experiments were mentioned above. Our=
> team's experience is with RACK-TLP in combination with either
> CUBIC+PRR, BBRv1, and BBRv2. We are not sure if there are other TCP > implementations that implement RACK-TLP without PRR.

So, in addition to the lack of experimental evidence using RACK-TLP
without PRR we have a specification problem for which we have no answer:
The RACK-TLP text suggests that if PTO fires and TLP detects a loss, the TCP sender enters fast recovery. But

PTO =3D timeout that expires if there is no feedback (ACKs) from
=C2=A0 =C2=A0 =C2=A0 =C2=A0the network, i.e., entire flight of data is lost= .

TLP =3D a single segment that is sent when timer expires. What is
=C2=A0 =C2=A0 =C2=A0 =C2=A0different compared to RTO is that PTO may expire= faster
=C2=A0 =C2=A0 =C2=A0 =C2=A0and a different segment is (re)transmitted, allo= wing to
=C2=A0 =C2=A0 =C2=A0 =C2=A0detect more than one lost segment with a single = Ack w/ SACK
=C2=A0 =C2=A0 =C2=A0 =C2=A0triggered by TLP (with regular RTO recovery only= the next
=C2=A0 =C2=A0 =C2=A0 =C2=A0unacknowledged segment can reliably be considere= d lost)

>From congestion control point of view this means that PTO is no differe= nt
from RTO. The congestion control principle as stated in Sec 2.2 of this document tells us that a loss of entire flight deserves a cautious
response, i.e., reset cwnd and slow start.

When RACK-TLP is implemented with PRR we have appropriate CC actions
specified in RFC 6937 that effectively reset cwnd and force the TCP sender =
to slow start, even though it tecnically enters fast recovery. This is
safe.

However, if an implementer wants to implement RACK-TLP without PRR,
she/he has to consult RFC 6675 which gives an incorrect CC response for this case, resulting in an unsafe implementation. The problem is not in the fast recovery algorithm in RFC 6675 because it was not intended to be <= br> initiated with TLP-kind of loss detection.

So the question is how to ensure an implementer has the necessary advice to implement correct congestion control actions for RACK-TLP once this
document is published. The lack of correct advice becomes even more
prominent as this document requires (all SACK capable) TCPs to implement RACK-TLP.

>> Given my understanding of PRR, the problem of an entire flight bei= ng
>> dropped is quite nicely solved with it. However, implementing RACK= -TLP
>> without PRR begs for a solution. Here is my current understanding:=
>>
>> (1) RACK part is what can be called to "replace" DupAck = counting
>> (2) TLP part is effectively a new retransmission timeout to detect=
>>=C2=A0 =C2=A0 =C2=A0 a loss of an entire flight of data (i.e., it i= s only invoked
>>=C2=A0 =C2=A0 =C2=A0 when a tail of the current flight becomes lost= which equals to
>>=C2=A0 =C2=A0 =C2=A0 the case of losing an entire flight since all = segments before
>>=C2=A0 =C2=A0 =C2=A0 the tail loss will get cumulatively Acked and = hence these segments
>>=C2=A0 =C2=A0 =C2=A0 are not anymore a part of the current flight a= t the time the loss
>>=C2=A0 =C2=A0 =C2=A0 is detected. And we an assume application limi= ted TCP sender.
>> (3) Current CC principles require resetting cwnd in such a case >>=C2=A0 =C2=A0 =C2=A0 and entering slow start (and so effectively do= es PRR though it is
>>=C2=A0 =C2=A0 =C2=A0 not explicitly stated in RFC 6937). Slow start= avoids a big burst
>>=C2=A0 =C2=A0 =C2=A0 if the lost flight is big.
>> (4) RACK-TLP would possibly like to allow that cwnd is set to a ha= lf
>>=C2=A0 =C2=A0 =C2=A0 of the lost flight and not to slow start. This= means that the bigger
>>=C2=A0 =C2=A0 =C2=A0 the lost flight is, the bigger is the burst th= at gets transmitted at
>>=C2=A0 =C2=A0 =C2=A0 the beginning of the recovery which is bad. So= , this approach would
>>=C2=A0 =C2=A0 =C2=A0 need at least a rule/advice for burst avoidanc= e (slow start, pacing,
>>=C2=A0 =C2=A0 =C2=A0 ...).
>> (5) When the lost flight is small (<=3D 4 segments) there is no= difference
>>=C2=A0 =C2=A0 =C2=A0 in recovery efficiency between (3) and (4). If= the lost flight is
>>=C2=A0 =C2=A0 =C2=A0> 5 segments, then (4) takes less RTTs to co= mplete the recovery
>>=C2=A0 =C2=A0 =C2=A0 but generates a burst. Note, even if pacing ov= er one SRTT would be
>>=C2=A0 =C2=A0 =C2=A0 used, it is still a burst.
>>
>> Now, it would be useful to have experimental data to know how the = size of
>> the lost flight is distributed. Is it typically just a few segment= s as
>> illustriated in the examples of the draft or is it often larger? >>
>> My advice would be to add a rule that cwnd MUST be reset to 1 MSS<= br> >> and the sender MUST enter slow start if TLP detects loss of an ent= ire
>> flight. This would be safe. Otherwise, without experimental eviden= ce from
>> a wide range of different network conditions and workloads it feel= s
>> unsafe to allow more aggressive approach.
>
> [RACK-TLP-team:]
>
> Our team's position is that the RACK-TLP draft documents a loss > detection algorithm, and normative declarations about congestion
> control behavior (like your "cwnd MUST be reset to 1 MSS", a= bove)
> should be in a separate document focused on congestion control.

I do not disagree with you what becomes to the role of congestion control <= br> in the RACK-TLP draft. It may well be in another document but IMHO such document must be available at the time this docment gets published.
How can we otherwise ensure correct implementations?

So this is more of a process question than critique towards the draft.


>>>>> Section 3 has a lengthy section to elaborate the key p= oint of RACK-TLP
>>>>> is to maximize the chance of fast recovery. How C.C. g= overns the
>>>>> transmission dynamics after losses are detected are ou= t of scope of
>>>>> this document in our authors' opinions.
>>>>>
>>>>>
>>>>>>
>>>>>> Another question relates to the use of TLP and adj= usting timer(s) upon
>>>>>> timeout. In the same example discussed above, it i= s clear that PTO
>>>>>> that fires TLP is just a more aggressive retransmi= t timer with
>>>>>> an alternative data segment to (re)transmit.
>>>>>>
>>>>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when= PTO expires, it is in
>>>>>> effect a retransmission timout and the timer(s) mu= st be backed-off.
>>>>>> This is not adviced in this specification. Whether= it is the TCP RTO
>>>>>> or PTO that should be backed-off is an open questi= on.=C2=A0 Otherwise,
>>>>>> if the congestion is persistent and further transm= ission are also lost,
>>>>>> RACK-TLP would not react to congestion properly bu= t would keep
>>>>>> retransmitting with "constant" timer val= ue because new RTT estimate
>>>>>> cannot be obtained.
>>>>>> On a buffer bloated and heavily congested bottlene= ck this would easily
>>>>>> result in sending at least one unnecessary retrans= mission per one
>>>>>> delivered segment which is not advisable (e.g., wh= en there are a huge
>>>>>> number of applications sharing a constrained bottl= eneck and these
>>>>>> applications are sending only one (or a few) segme= nts and then
>>>>>> waiting for an reply from the peer before sending = another request).
>>>>>
>>>>> Thanks for pointing to the RFC.=C2=A0 After TLP, RTO t= imers will
>>>>> exp-backoff (as usual) for stability reasons mentioned= in sec 9.3
>>>>> (didn't find 9.1 relevant).
>>>>
>>>> My apologies for refering to the wrong section of RFC 2914= , Yes, I meant
>>>> Sec 9.3.
>>>>
>>>>> In your scenario, you presuppose the
>>>>> retransmission is unnecessary so obviously TLP is not = good. Consider
>>>>> what happens without TLP where all the senders fire RT= O spuriously and
>>>>> blow up the network. It is equally unfortunate behavio= r. "bdp
>>>>> insufficient of many flows" is a congestion contr= ol problem
>>>>
>>>> If (without TLP) RTO is spurious, it may result in unneces= sary
>>>> retransmissions. But we have F-RTO (RFC 5682) and Eifel (R= FC 3522) to
>>>> detect and resolve it without TLP, so I don't find it = as a problem.
>>>>
>>>> To clarify more, what I am concerned about. Think about a = scenario where a
>>>> (narrow) bottleneck becomes heavily congested by a huge nu= mber of
>>>> competing senders such that the available capacity per sen= der is less
>>>> than 1 segment (or << 1 MSS).
>>>> This is a situation that network first enters before conge= stion collapse
>>>> gets realized. So, it is extremely important that all CC a= nd timer
>>>> mechanisms handle it properly. Regular TCP handles it via = RFC 6298 by
>>>> backing off RTO expotentially and keeping this backed-off = RTO until an
>>>> new ACK is received for new data. This saves RACK-TLP from= full congestion
>>>> collapse. But consider what happens: even though RTO is ba= cked off, each
>>>> time a TCP sender manages to get one segment through (with= cwnd =3D 1 MSS)
>>>> it always first arms PTO with more or less constant value = of 2*SRTT. If
>>>> the bottleneck is buffer bloated the actual RTT easily exc= eeds 2*SRTT and
>>>> TLP becomes spurious. After a spurious TLP, RTO expires (m= aybe more than
>>>> once before exponential back-off of RTO results in large e= nough value)
>>>> and a new RTT sample is not received. So, SRTT remains unc= hanged and even
>>>> if sometimes a new sample is received, SRTT gets very slow= ly adjusted. As
>>>> a result, each TCP sender would keep on sending a spurious= TLP for each
>>>> new segment resulting in at least 50% of the packets being= unnecessary
>>>> rexmitted and the utilization of the bottleneck is < 50= %. This would not
>>>> be a full congestion collapse but has unwanted symptoms to= wards
>>>> congestion collapse (Note: there is no clear line for the = level of
>>>> reduction in delivery of useful data is considered as cong= estion
>>>> collapse).
>>>
>>> AFAIK you are saying: under extreme congestion shared by many = short
>>> flows, RACK-TLP can cause more packet losses because of the mo= re
>>> aggressive PTO timer. I agree and can add this to the "se= ction 9.3".
>>
>> No, that was not what I meant. This happens simply when enough flo= ws are
>> competing on the same bottleneck. It may be long flows or maybe >> applications with more or less continuous request-reply exhanges.<= br> >> E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is 500msecs and= PMTU
>> is 1500B, then a bit over 40 simultaneous flows would mean that th= e
>> bottleneck becomes fully utilized with the equal share of roughly = 1 MSS
>> per flow. With a quite typical bottleneck buffer size roughly equa= ling to
>> BDP, about 80+ flows would fill up the buffer as well and increase=
>> RTT >=3D 1 secs.=C2=A0 A buffer bloated bottleneck buffer would= mean even larger
>> RTT and allow more flows sharing the bottleneck without loss.
>>
>> If the number of TCP flows is > 90 (or >> 90) RACK-TLP wo= uld ends up
>> (almost) always unnecessarily retransmitting each new segment once= (PTO
>> being 1 sec or around 1 sec). RTO back-off after a few rounds save= s each
>> TCP sender from additional unnecessary rexmits but still ~ 50% of = the
>> deivered packets are not making any useful progress.
>>
>> If the bottleneck buffer is small, it would result in more losses = as you
>> suggest but would not be that much of problem because majority of = the
>> unnecessary rexmits would not get delivered over the bottleneck li= nk.
>> Instead, they wuold get dropped at the bottleneck. Unnecessary rex= mits
>> would just create extra load on the poth before the bottleneck (wh= ich of
>> course is not a non-problem either).
>
> [RACK-TLP-team:]
>
> If we are correctly understanding the scenario you are outlining, the<= br> > PTO would likely not be 1 sec in this case. In this scenario, the RTT<= br> > is around 1sec, so the PTO would be around 2*srtt, which would be
> around 2 secs. With a 1sec RTT, and even considering delayed ACKs, it<= br> > seems very unlikely that a 2 sec PTO would cause a significant number<= br> > of unnecessary TLP probes.

Well. Roughly the first initiated 40 flows will have SRTT ~ 0.5 sec. If next ~ 40 flows arrive within an RTT or so they will get RTT samples
roughly between 0.5 - 1.x secs. The rest 80 - N hundreds flows will not get an RTT sample and will use initial/default PTO =3D 1 sec (unless using =
timestamps). The larger the buffer bloat the worse things get.
Once ~200 flows are competing over the bottleneck, RTT will be well
beyond 2 secs and grows when more flows join, guaranteeing spurious TLP for each new segment (unless timestamps are in use).

> Perhaps your postulated PTO of 1 sec is coming from the pseudocode
> path in TLP_calc_PTO() where, if SRTT is not available, the PTO is 1 > second? However, this case where there is no SRTT only happens if (a)<= br> > the connection is *not* using TCP timestamps (enabled for most
> connections on the public Internet, due to default-enabled support in<= br> > Linux/Android and iOS/MacOS), and (b) the connection has *never* had a=
> single RTT sample from a non-retransmitted packet. To meet both of
> those conditions is quite rare in practice. Is this the path that is > causing your concerns about a PTO of 1 sec?

Sure. Having timestamps helps a lot in case the bottleneck buffer is
buffer bloated (though RTT sample will not include delayed Ack effect for <= br> rexmits that are immediately acked). But RACK-TLP does not require
timestamps and there are a lot of TCP stacks out there in addition to
Linux/Android and iOS/MacOS. And more are coming with IoT expansion,
for example. In addition, it is quite suprising how old (mobile) devices many people are using, some of which are old enough and have not been
eligible for an OS upgrade for many years.

But my quick example scenario was just to illustriate the problem, maybe typical in some areas where the only Internet access is over a
geostationary satellite connection and people quite likely not using
mobile/cellular devices. And, I selected a buffer-bloated scenario
because that generates unnecessary rexmits which are a prerequisite for classical congestion collapse.

It may well be in some environments that these hundreds of competing
flows are application limited (request-reply continuously) and get
started over a longer period of time, each getting RTT sample(s) over a lightly loaded bottleneck and then becoming idle or sending data only
sporadically. Then later they all become active more or less at the same time (maybe by a common trigger). Base RTT may then be much lower than
500 ms as long as there is enough buffer bloat.

Furthermore, timestamps are not that helpful in case of a heavily
congested small buffer bottleneck. Having approximately accurate SRTT
does not alone help in reducing the sending rate below 1 segment/RTT in heavily congested scenarios. Exponential backoff of timer is a must.

I believe that either of us know what's really out there employing
Internet for communication purposes. It does not matter whether it is a notable percentage or not as long there is a group of users who are
encountering the envisioned problem.
It may very well be a small minority, but if this kind of a problem
escalates for this group very often (maybe almost always), it means we
are disabling use of Internet technology for them.

> Furthermore, in cases like this where the number of flows is roughly > equal to or greater than the BDP of the path, Reno/[RFC5681] and CUBIC=
> will spend the majority of their time in loss recovery (the minimum > ssthresh from [RFC5681] being 2*SMSS).

Sure there is surprisingly lot to improve with TCP when the window needs to be kept lower than 2 MSS or when the available share would be even
less than 1 MSS/RTT. RFC 5681 would exponentially back-off on every RTO, leaving opportunity for other flows to make progress during the
backed-off interval. Once the sender is lucky and gets an Ack for a new segment, min ssthresh of 2*MSS unfortunately allows it to accelerate to 2*MSS/RTT and maybe more until RTO expires again. We cannot avoid some
drops or unnecessary rexmits. Actually, in such a heavily congested
scenario the combination of Karn's exponential back-off and slow start =
results in Multiplicative Increase Multiplicative Decrease (MIMD)
behaviorwhich does not converge that well to fairness. But it avoids
congestion collapse. It is kind a tradeoff between safe and stable
behavior during heavy congestion and being able to ramp up fast when the congestion fades away. Even though the current behavior is not ideal
for fairness, we should not make it even worse.

Currently only way to avoid spending most of the time in loss
recovery seems to be ECN that would make a TCP sender to become rate
controlled once cwnd hits the minimum cwnd of 1 MSS(*). But there is a
lot to optimise also with ECN in this kind of scenario ...

(*) to avoid anyone repeating the misconception that minimum cwnd is
=C2=A0 =C2=A0 =C2=A02 MSS per equation (4) in RFC 5681: equation (4) sets s= sthresh,
=C2=A0 =C2=A0 =C2=A0not cwnd. RFC 3168 clearly states that cwnd must be hal= ved on
=C2=A0 =C2=A0 =C2=A0an arrival of ECE; this holds until cwnd =3D 1 MSS. Aft= er this,
=C2=A0 =C2=A0 =C2=A0the sending rate of new segments is (RTO) timer control= led and
=C2=A0 =C2=A0 =C2=A0the timer avlue exponentially backed-off if more ECEs a= rrive.
=C2=A0 =C2=A0 =C2=A0At least two major OSs implement this incorrectly unles= s now
=C2=A0 =C2=A0 =C2=A0already fixed.

> And the RACK-TLP ID specifies
> that TLP probes are not sent while in loss recovery.

Maybe I missed it but I couldn't find an end condition of RTO recovery =
for RACK-TLP purposes in the document. Regular RTO does not have such end <= br> condition because it is not needed. Congestion control and loss recovery are quite decoupled during=C2=A0 RTO recovery; slow start follows its own <= br> rules and ends when cwnd > ssthresh and loss recovery has its own
rules to select segments to rexmit and just moves on sending new data
once all lost segments have been retransmitted. Some implementations may have such variable/condition but it didn't help me.

Without timestamps, if TLP is not backed-off, a TLP is likely to be sent for each new segment (assuming certain conditions). Each not backed-off rexmit is potentially stealing an opportunity from another flow to get
its segment being delivered, thereby contributing to unfair use of
bottleneck resources.

>>> What authors disagree is that RTO must be back-off on the firs= t
>>> instance if TLP is not acked. While your suggestion helps the<= br> >>> congestion case, it may also hurt the recovery in other cases = when the
>>> TLP is dropped due to light/burst/transient congestion. Arguin= g which
>>> scenarios matter more subjectively is not productive.
>>
>> When RACK-TLP is required to be implemented by all TCP stacks, it<= br> >> is extremely important that it always works in a safe way and cong= estion
>> is always the primary concern to get properly handled. Without arg= uing
>> more, I just want to point out that TCP must work reasonably for a= ll
>> Internet users. That means it must not generate a situation where = even a
>> small minority of the Internet users often or almost always encoun= ter
>> severe problems with their connectivity.
>>
>> For example, also users in developing countries where possibly an = entire
>> village shares just one mobile (cellular, maybe 3G possibly only G= PRS)
>> connection for their Internet access and pays per amount of data s= hould
>> get reasonable TCP behavior. In such a case, I cannot agree with >> engineering that results in almost always getting only half of the=
>> already scarce bandwidth whle paying double price fot the useful d= ata.
>>
>> But thinking about a way forward. Karn's algorithm would requi= re backing
>> off PTO even if you get Ack of PTO. Relaxing this does not sound m= e that
>> bad at all, because there is often a pause before TLP and a TCP se= nder
>> gets feedback, so apparently conditions are not that bad and loss<= br> >> recovery gets triggered (hopefully in slow start).
>> If TLP is not acked, RTO is needed and recovery is completed in us= ing RTO
>> recovery in slow start. Now, if the RTO recovery is successful (no=
>> losses during RTO recovery), it should be quite likely that the TC= P
>> sender is able to successfully send also one new segment, because = it
>> enters CA when it is sending at the half of the previous rate. So,= once
>> you get Ack for the new segment, the TLP back off can be removed a= nd it
>> is unlikely that the TLP back off slowed down next loss detection.=
>> On the other hand, if the RTO recovery after an unsuccessful TLP i= s not
>> successful (more losses are detected), it is quite likely that con= gestion
>> has not been resolved. So, it is important to be conservative and = have a
>> backed-off PTO (or even turn it off) to avoid (further) unnecessar= y
>> rexmits. If PTO is not backed of, I'd envision PTO mainly fail= ing to get
>> an Ack in such a case and thereby it not being that useful.
>>
>> This certainly would require experimental data in a heavily conges= ted
>> setting to really figure out the actual impact of different altern= atives.
>>
>>> So the question we need to look at is if RACK-TLP 2RTT-PTO + r= egular
>>> RTO-backoff is going to cause major stability issues in extrem= e
>>> congestion. My understanding based on my officemate Van Jacobs= on's
>>> explanation is, as long as there's eventual exponential ba= ckoff, we'll
>>> avoid the repeated shelling the network.
>>
>> Right. But the problem is that with TLP as specified we do not hav= e full
>> exponential back off. It lacks Karn's clamped retransmit backo= ff (as it
>> is called in Van Jacobson's seminal paper) which requires keep= ing
>> backed-off timer of a retransmitted segment for the next (new) seg= ment and
>> ensures that there is eventual exponential backoff.
>> Backing off just RTO is not enough, because "fixed" PTO = for each new
>> segment breaks this "back-off chain", that is, the expon= ential backoff
>> is not continueed until there is evidence that congestion has been=
>> resolved (a cumulative Ack arrives for new data). But as I said, b= acking
>> off RTO saves RACK-TLP from a full congestion collapse. Still, was= ting
>> 50% of the available network capacity in certain usage scenarios d= oes not
>> sound acceptable for me.
>
> [RACK-TLP-team:]
>
> To address concerns related to Karn's algorithm, perhaps it would = be
> sufficient to specify that after a RACK-TLP sender sends a TLP probe > that is a retransmitted segment, it temporarily disables further TLP > retransmissions until the sender obtains a valid RTT sample (i.e. from=
> a non-retransmitted segment, or a segment with [RFC7323] TCP
> timestamps)?

As a basic rule: disabling TLP probes for the period of loss recovery as currently specified sounds like a correct approach provided that the end condition

=C2=A0 "until the sender obtains a valid RTT sample"

is added (this would be without timestamps, see some considerations with timestamps later below).

Then some justification and maybe some exeptions can also be specified
(all these without timestamps):

If fast recovery is not entered via detecting loss using TLP, the
sender does not need to wait for a valid RTT sample. It should be enough that RecoveryPoint is reached, i.e., use normal exit condition for fast recovery. However, I am not sure whether detecting a loss of a rexmit
during fast recovery might change this?

I think it does not matter whether a TLP probe is a retransmitted segment or not:

(a) if there is no ack after TLP probe and RTO expires it should be clear <= br> that TLP must be disabled until an ack for a new previously not rexmitted <= br> segment is received, regardless of the probe segment sent by TLP.
This is Karn's algorithm.

(b) if TLP triggers an Ack that is used to detect a loss of an entire
flight of data, this may later during loss recovery result in an RTO
which definitely requires disabling TLP as per the basic rule. There
might be some exeptions when the basic rule is not necessary but it is
hard for me to figure one right now, except

(c) if TLP rexmit detects and repairs a single loss, then CC is anyway
invoked and Ack is received. If the arriving Ack is triggered by the TLP probe segment, it indicates that the conditions are likely not that bad (RTO not needed). So it might be ok, to rearm PTO for the next time
without any backoff (without disbling it). However,

(d) if TLP was spurious rexmit, then PTO value obviously was too low
(effective RTT may have increased suddenly and Acks got just delayed).
This is possibly detected only one RTT later when the DupAck of the TLP rexmit arrives. TLP may have got rearmed by that time again with too
low value, so it should be rearmed with doubled value to avoid another
spurious TLP PTO (or disabled).

Then with timestamps. I think the simple rule for disabling TLP "until=
the sender obtains a valid RTT sample" is not necessarily giving the <= br> desired outcome in all cases. For example, if a TLP probe is send and
then a late ack arrives for a segment sent before the TLP probe and gives <= br> a valid RTT sample with help of timestamps. This would allow a new TLP
even though the sender has not got an Ack for a new segment sent after
the TLP probe?

So, also with timestamps the requirement must be that the sender obtains a valid RTT sample for a segment sent after the TLP probe. And, at least, <= br> if RTO recovery is entered, then the Ack must be for a new segment.
Cannot figure out now all potential exceptions when a valid RTT sample
with timestamps would allow re-enabling TLP earlier. Too complex
algorithm with too many possible scenarios to investigate right now ;)

A single, simple rule would be advisable here. Otherwise, this may end up <= br> being too complex to get it right.


>>> As a matter of fact some
>>> major TCP (!=3D Linux) implementation has implemented linear b= ackoff of
>>> first N RTOs before exp-backoff.
>>
>> But that's quite ok as long as there is eventual exponential b= ackoff,
>> including Karn's clamped retransmit backoff. Linear back-off i= n the
>> beginning just makes resolving (heavy) congestion a bit slower. >>
>>>>
>>>>>>
>>>>>> Additional notes:
>>>>>>
>>>>>> Sec 2.2:
>>>>>>
>>>>>> Example 2:
>>>>>> "Lost retransmissions cause a=C2=A0 resort to= RTO recovery, since
>>>>>>=C2=A0 =C2=A0DUPACK-counting does not detect the lo= ss of the retransmissions.
>>>>>>=C2=A0 =C2=A0Then the slow start after RTO recovery= could cause burst losses
>>>>>>=C2=A0 =C2=A0again that severely degrades performan= ce [POLICER16]."
>>>>>>
>>>>>> RTO reovery is done in slow start. The last senten= ce is confusing as
>>>>>> there is no (new) slow-start after RTO recovery (o= r more precisely
>>>>>> slow start continues until cwnd > ssthresh). Do= you mean: if/when slow
>>>>>> start still continues after RTO Recovery has repai= red lost segments,
>>>>>> it may cause burst losses again?
>>>>> I mean the slow start after (the start of) RTO recover= y. HTH
>>>>
>>>> Tnx. I'd appreciate if the text could be clarified to = reflect this more
>>>> accurately. Maybe something along the lines(?):
>>>>
>>>>=C2=A0 =C2=A0"Then the RTO recovery in slow start coul= d cause burst
>>>>=C2=A0 =C2=A0losses again that severely degrades performanc= e [POLICER16]."
>>>>
>>>>>>
>>>>>> Example 3:
>>>>>>=C2=A0 =C2=A0"If the reordering degree is beyo= nd DupThresh, the DUPACK-
>>>>>>=C2=A0 =C2=A0 counting can cause a spurious fast re= covery and unnecessary
>>>>>>=C2=A0 =C2=A0 congestion window reduction.=C2=A0 To= mitigate the issue, [RFC4653]
>>>>>>=C2=A0 =C2=A0 adjusts DupThresh to half of the infl= ight size to tolerate the
>>>>>>=C2=A0 =C2=A0 higher degree of reordering.=C2=A0 Ho= wever if more than half of the
>>>>>>=C2=A0 =C2=A0 inflight is lost, then the sender has= to resort to RTO recovery."
>>>>>>
>>>>>> This seems to be somewhat incorrect description of= TCP-NCR specified in
>>>>>> RFC 4653. TCP-NCR uses Extended Limited Transmit t= hat keeps on sending
>>>>>> new data segments on DupAcks that makes it likely = to avoid an RTO in
>>>>>> the given example scenario, if not too many of the= the new data
>>>>>> segments triggered by Extended Limited Transmit ar= e lost.
>>>>> sorry I don't see how the text is wrong describing= RFC4653,
>>>>> specifically the algorithm in adjusting ssthresh
>>>>
>>>> To my understanding RFC4653 initializes DupThresh to half = of the inflight
>>>> size in the beginning of the Extended Limited Transmit. Th= en on each
>>>> DupAck it adjusts (recalculates) DupThresh again such that= ideally a cwnd
>>>> worth of DupAcks are received before packet loss is declar= ed (or
>>>> reordering detected). So, if I am not incorrect, loss of a= half of the
>>>> inflight does not necessarily result in RTO recovery with = TCP-NCR.
>>> Could you suggest the text you'd like on NCR description.<= br> >>
>> I'm not an expert nor closely acquainted with NCR. There might= be many
>> different packet loss patterns that may affect the behavior. So, m= y
>> advice is to simply drop the last sentence starting with "How= ever ...",
>> because it seems incorrect and replace the second but last sentenc= e:
>>
>>=C2=A0 =C2=A0 To mitigate the issue, [RFC4653]
>>=C2=A0 =C2=A0 adjusts DupThresh to half of the inflight size to tol= erate the
>>=C2=A0 =C2=A0 higher degree of reordering.
>>
>> -->
>>
>>=C2=A0 =C2=A0 To mitigate the issue, TCP-NCR [RFC4653]
>>=C2=A0 =C2=A0 increases the DupThresh from the current fixed value = of three duplicate
>>=C2=A0 =C2=A0 ACKs [RFC5681] to approximately a congestion window o= f data having left
>>=C2=A0 =C2=A0 the network.
>
> [RACK-TLP-team:]
>
> Sure, we will revise accordingly.

Tnx.

>
>>>>>>
>>>>>> Sec. 3.5:
>>>>>>
>>>>>>=C2=A0 =C2=A0"For example, consider a simple c= ase where one
>>>>>>=C2=A0 =C2=A0segment was sent with an RTO of 1 seco= nd, and then the application
>>>>>>=C2=A0 =C2=A0writes more data, causing a second and= third segment to be sent right
>>>>>>=C2=A0 =C2=A0before the RTO of the first segment ex= pires.=C2=A0 Suppose only the first
>>>>>>=C2=A0 =C2=A0segment is lost.=C2=A0 Without RACK, u= pon RTO expiration the sender marks
>>>>>>=C2=A0 =C2=A0all three segments as lost and retrans= mits the first segment.=C2=A0 When
>>>>>>=C2=A0 =C2=A0the sender receives the ACK that selec= tively acknowledges the second
>>>>>>=C2=A0 =C2=A0segment, the sender spuriously retrans= mits the third segment."
>>>>>>
>>>>>> This seems incorrect. When the sender receives the= ACK that selectively
>>>>>> acknowledges the second segment, it is a DupAck as= per RFC 6675 and does
>>>>>> not increase cwnd and cwnd remains as 1 MSS and pi= pe is 1 MSS. So, the
>>>>>> rexmit of the third segment is not allowad until t= he cumulative ACK of
>>>>>> the first segment arrives.
>>>>> I don't see where RFC6675 forbids growing cwnd. Ev= en if it does, I
>>>>> don't think it's a good thing (in RTO-slow-sta= rt) as DUPACK clearly
>>>>> indicates a delivery has been made.
>>>>
>>>> SACKed sequences with DUpAcks indicate that those sequence= s were
>>>> delivered but it does not tell when they were sent. The ba= sic principle
>>>> of slow start is to reliably determine the available netwo= rk capacity
>>>> during slow start. Therefore, slow start must ensure it us= es only
>>>> segments sent during the slow start to increase cwnd. Othe= rwise, a TCP
>>>> sender may encounter exactly the problem of unnecessary re= transmission
>>>> envisioned in this example of RACK-TCP draft (and increase= cwnd on not
>>>> valid Acks).
>>>>
>>>> RFC 6675 does re-specify DupAck with SACK option but it do= es not include
>>>> the rule for slow start. Slow start is specified in RFC 56= 81. It is
>>>> crystal clear in allowing increase in cwnd only on cumulat= ive
>>>> Acks, i.e., forbidding to increase cwnd on DupAcks (RFC 56= 81, Sec 3,
>>>> page 6:
>>>>
>>>>=C2=A0 =C2=A0 During slow start, a TCP increments cwnd by a= t most SMSS bytes for
>>>>=C2=A0 =C2=A0 each ACK received that cumulatively acknowled= ges new data.
>>>>
>>>> Maybe this example in the RACK-TLP draft was inspired by a= incorrect
>>>> implementation of SACK-based loss recovery?
>>>>
>>>> FYI: when we were finalizing RFC 6675 I suggested includin= g also an
>>>> algorithm for RTO recovery with SACK in RFC 6675. The reas= on was exactly
>>>> that it might be not easy to gather info from multiple doc= uments and
>>>> hence help the implementor to have all necessary advice in= a single
>>>> document. This unfortunately did not get realized though.<= br> >>>
>>> I am honestly lost quibbling these RFC6675 implementations and= feeling
>>> pedantic to these standards largely serve as guiding principle= s
>>> instead of line-by-line code. Is cwnd one packet bigger or sma= ller in
>>> this example making any different in advancing the Internet= 9;s
>>> capability to do better loss detection. I do not think so.
>>
>> Sorry, I don't understand what was quibbling here. I believe I= did not
>> argue anything about cwnd size with this example at hand in Sec. 3= .5.
>> My point is that it describes incorrect slow start behavior. Corre= ctly
>> implemented slow start does not have the problem illustriated in t= he
>> example.
>>
>>> At this point please suggest a text you like to change.
>>
>> That is simple. Please remove the description of the behavior with= out
>> RACK. Or correct it: the behavior would be exactly the same as wit= h RACK,
>> but the reason for not unnecessarily retransmitting third segment = can be
>> described to be different.
>> And, please correct also the description with RACK. With RACK, thi= rd
>> segment does not get unnecessarly rexmitted for the reason already=
>> indicated and also because cwnd=3D1 MSS. And, no new segments are = allowed
>> either by cwnd=3D1.
>>
>
> [RACK-TLP-team:]
>
> Thanks. Perhaps it makes sense to consider a slightly different RTO > scenario to illustrate the point about how RACK RTO behavior can avoid=
> spurious retransmissions.
>
> Here is the proposed new text:
>
> "3.5.=C2=A0 An Example of RACK-TLP in Action: RTO
>
>=C2=A0 =C2=A0In addition to enhancing fast recovery, RACK improves the = accuracy of
>=C2=A0 =C2=A0RTO recovery by reducing spurious retransmissions.
>
>=C2=A0 =C2=A0Without RACK, upon RTO timer expiration the sender marks a= ll the
>=C2=A0 =C2=A0unacknowledged segments lost.=C2=A0 This approach can lead= to spurious
>=C2=A0 =C2=A0retransmissions.=C2=A0 For example, consider a simple case= where one
>=C2=A0 =C2=A0segment was sent with an RTO of 1 second, and then the app= lication
>=C2=A0 =C2=A0writes more data, causing a second and third segment to be= sent right
>=C2=A0 =C2=A0before the RTO of the first segment expires.=C2=A0 Suppose= none of the
>=C2=A0 =C2=A0segments were lost.=C2=A0 Without RACK, if there is a spur= ious RTO then
>=C2=A0 =C2=A0the sender marks all three segments as lost and retransmit= s the
>=C2=A0 =C2=A0first segment. If the ACK for the original copy of the fir= st segment
>=C2=A0 =C2=A0arrives right after the spurious RTO retransmission, then = the
>=C2=A0 =C2=A0sender continues slow start and spuriously retransmits the= second
>=C2=A0 =C2=A0and third segments, since it (erroneously) presumed they a= re lost.

That seems fine. Would it be useful to add an additional note saying that <= br> if F-RTO is in use, then further unnecessary retransmissions can be
avoided?

>=C2=A0 =C2=A0With RACK, upon RTO timer expiration the only segment auto= matically
>=C2=A0 =C2=A0marked lost is the first segment (since it was sent an RTO= ago); for
>=C2=A0 =C2=A0all the other segments RACK only marks the segment lost if= at least
>=C2=A0 =C2=A0one round trip has elapsed since the segment was transmitt= ed.
>=C2=A0 =C2=A0Consider the previous example scenario, this time with RAC= K.=C2=A0 With
>=C2=A0 =C2=A0RACK, when the RTO expires the sender only marks the first= segment as
>=C2=A0 =C2=A0lost, and retransmits that segment.=C2=A0 The other two ve= ry recently sent
>=C2=A0 =C2=A0segments are not marked lost, because they were sent less = than one
>=C2=A0 =C2=A0round trip ago and there were no ACKs providing evidence t= hat they
>=C2=A0 =C2=A0were lost. Upon receiving the ACK for the RTO retransmissi= on the
>=C2=A0 =C2=A0RACK sender would not yet retransmit the second or third s= egment. but
>=C2=A0 =C2=A0rather would rearm the RTO timer and wait for a new RTO in= terval to elapse
>=C2=A0 =C2=A0before marking the second or third segments as lost.
> "

This behavior with RACK-TLP does not quite match with my reading of
the draft in all parts, so I have some questions.

First, wouldn't the PTO timer be first running for the first segment and when the sender sends the 2nd and 3rd segment it would rearm PTO for the 3rd segment? My understanding based on Sec 8 is that RTO cannot be
armed until PTO fires? And when the PTO fires, the sender would
retransmit the 3rd segment? Maybe I am missing something?

Anyways, an RTO timer may expire in this scenario (e.g., if there is no Ack for TLP).
Let's assume the RTO timer expires as described. When the first Ack aft= er
the rexmit of the 1st segment arrives, isn't that the late ACK for the =
original copy of the first segment, not the ACK for the RTO
retransmission? Anyways, when this first Ack arrives after the RTO, the second and third segment are not marked as lost as described, which
nicely prevents unnecessary retransmissions of those segments.
However, if the 2nd and 3rd segments were lost, wouldn't rearming RTO <= br> with exponentially backed-off timer value (2*RTO) make the recovery of
the 2nd and 3rd segment very slow? After 2*RTO the timer expires and
the 2nd segment is rexmitted and only after one additional RTT when the ack for the 2nd segment arrives, the sender rexmits the 3rd segment?
Wouldn't it be much more efficient to disable RACK loss detection durin= g
an RTO recovery and employ F-RTO? Maybe I am missing something again?


Then to the problem with the pseudocode I mentioned in the beginning of this message. If I am not incorrect it seems to me that setting a value to TLP.end_seq in TLP_send_probe() is off by one byte? Maybe something
similar is wrong somewhere else too, didn't check. Please apologise me = if
I missed something.

Let's use an example with RACK-TLP recovery:

Send P1, ..., P9, P10
[P1,.., P9 delayed, P10 dropped]
/* I believe P1-9 delayed is not important here */

After 2*SRTT PTO expires
P10 rexmitted by TLP
=C2=A0 [ TLP_send_probe(): set TLP.end_seq =3D SND.NXT (=3D SEG.P11) ]

=C2=A0 [after TLP, the=C2=A0 application possibly provides more data to sen= d]

Ack for original P1 arrives
(P11 sent, if more data by application)
Ack for original P2 arrives
(P12 sent, if more data by application)
...
Ack for original P9 arrives
(P19 sent, if more data by application)

Ack for P10 triggered by TLP rexmit of P10 arrives
=C2=A0 [TLP_process_ack(ACK):
=C2=A0 =C2=A0...
=C2=A0 =C2=A0If ACK's ack. number > TLP.end_seq
=C2=A0 =C2=A0 returns False
=C2=A0 =C2=A0 since ACK's ack. number =3D SEQ.ACK =3D TLP.end_seq =3D S= EG.P11]

=C2=A0 =C2=A0Loss of P10 is undetected and no reaction to congestion]


My understanding of draft text is that a loss of P10 is not concealed.
Please advise.

Best regards,

/Markku

> best regards,
>
> neal
>
>> Please remove also the last paragraph of the Sec. 3.5, it being al= so
>> incorrect description of behavior.
>>
>> BR,
>>
>> /Markku
>>
>>>>
>>>> BR,
>>>>
>>>> /Markku
>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> /Markku
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, 16 Nov 2020, The IESG wrote:
>>>>>>
>>>>>>>
>>>>>>> The IESG has received a request from the TCP M= aintenance and Minor Extensions
>>>>>>> WG (tcpm) to consider the following document: = - 'The RACK-TLP loss detection
>>>>>>> algorithm for TCP'
>>>>>>>=C2=A0 <draft-ietf-tcpm-rack-13.txt> as P= roposed Standard
>>>>>>>
>>>>>>> The IESG plans to make a decision in the next = few weeks, and solicits final
>>>>>>> comments on this action. Please send substanti= ve comments to the
>>>>>>> last-call@ietf.org mailing lists by 2020-11-30. Exceptional= ly, comments may
>>>>>>> be sent to iesg@ietf.org instead. In either case, please retain th= e beginning
>>>>>>> of the Subject line to allow automated sorting= .
>>>>>>>
>>>>>>> Abstract
>>>>>>>
>>>>>>>
>>>>>>>=C2=A0 =C2=A0This document presents the RACK-TL= P loss detection algorithm for TCP.
>>>>>>>=C2=A0 =C2=A0RACK-TLP uses per-segment transmit= timestamps and selective
>>>>>>>=C2=A0 =C2=A0acknowledgements (SACK) and has tw= o parts: RACK ("Recent
>>>>>>>=C2=A0 =C2=A0ACKnowledgment") starts fast = recovery quickly using time-based
>>>>>>>=C2=A0 =C2=A0inferences derived from ACK feedba= ck.=C2=A0 TLP ("Tail Loss Probe")
>>>>>>>=C2=A0 =C2=A0leverages RACK and sends a probe p= acket to trigger ACK feedback to
>>>>>>>=C2=A0 =C2=A0avoid retransmission timeout (RTO)= events.=C2=A0 Compared to the widely
>>>>>>>=C2=A0 =C2=A0used DUPACK threshold approach, RA= CK-TLP detects losses more
>>>>>>>=C2=A0 =C2=A0efficiently when there are applica= tion-limited flights of data, lost
>>>>>>>=C2=A0 =C2=A0retransmissions, or data packet re= ordering events.=C2=A0 It is intended to
>>>>>>>=C2=A0 =C2=A0be an alternative to the DUPACK th= reshold approach.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The file can be obtained via
>>>>>>> https://datatrack= er.ietf.org/doc/draft-ietf-tcpm-rack/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No IPR declarations have been submitted direct= ly on this I-D.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ______________________________________________= _
>>>>>>> tcpm mailing list
>>>>>>> tcpm@ietf.org
>>>>>>> https://www.ietf.org/mailman/= listinfo/tcpm
>>>>>>>
>>>>>
>>>
>
--0000000000008b36fd05b68979f9-- From nobody Wed Dec 16 11:39:59 2020 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 EA4E93A0E5B; Wed, 16 Dec 2020 11:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FUZZY_IMPORTANT=1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 fI1u8ncv2nkV; Wed, 16 Dec 2020 11:39:47 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7473A0E63; Wed, 16 Dec 2020 11:39:44 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 16 Dec 2020 21:39:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=JHdxpi n5BdcNzN4wpUn1awNoXLLansdPbzqhnru5cTM=; b=ZdT0KmSweOaqXfBqPPUGnq C32Pys+1jCiIJID61vgWch4fFzm93Tx3QwoJv0fDcl2dpCFRbRnas5Dh0QVYpakE +h5jkmPkW44dBOk8L81mGtNGT17zcT2GXZrqFQDGDjFmgRt248DPr3FntM7GqUC5 OZt51h09YiirI6+2y8bF4= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 16 Dec 2020 21:39:32 +0200 id 00000000005A0170.000000005FDA6274.00003116 Date: Wed, 16 Dec 2020 21:39:30 +0200 (EET) From: Markku Kojo To: Martin Duke cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-12593-1608147572-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 19:39:53 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-12593-1608147572-0001-2 Content-Type: text/plain; charset="iso-8859-15"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi Martin, On Tue, 15 Dec 2020, Martin Duke wrote: > Hi Markku, >=20 > Thanks for the comments. The authors will incorporate many of your > suggestions after the IESG review. >=20 > There's one thing I don't understand in your comments: >=20 > " That is, > where can an implementer find advice for correct congestion control > actions with RACK-TLP, when: >=20 > (1) a loss of rexmitted segment is detected > (2) an entire flight of data gets dropped (and detected), > =A0 =A0 =A0that is, when there is no feedback available and a timeout > =A0 =A0 =A0is needed to detect the loss " >=20 > Section 9.3 is the discussion about CC, and is clear that the > implementer should use either 5681 or 6937. Just a cite nit: RFC 5681 provides basic CC concepts and some useful CC=20 guidelines but given that RACK-TLP MUST implement SACK the algorithm in=20 RFC 5681 is not that useful and an implementer quite likely follows=20 mainly the algorithm in RFC 6675 (and not RFC 6937 at all if not=20 implementing PRR). And RFC 6675 is not mentioned in Sec 9.3, though it is listed in the=20 Sec. 4 (Requirements). > You went through the 6937 case in detail. Yes, but without correct CC actions. > If 5681, it's pretty clear to me that in (1) this is a new loss > detection after acknowledgment of new data, and therefore requires a > second halving of cwnd. Hmm, not sure what you mean by "this is a new loss detection after=20 acknowledgment of new data"? But anyway, RFC 5681 gives the general principle to reduce cwnd and=20 ssthresh twice if a retransmission is lost but IMHO (and I believe many=20 who have designed new loss recovery and CC algorithms or implemented them=20 agree) that it is hard to get things right if only congestion control=20 principles are available and no algorithm. That's why ALL mechanisms that we have include a quite detailed algorithm=20 with all necessary variables and actions for loss recovery and/or CC=20 purposes (and often also pseudocode). Like this document does for loss=20 detection. So the problem is that we do not have a detailed enough algorithm or=20 rule that tells exactly what to do when a loss of rexmit is detected. Even worse, the algorithms in RFC 5681 and RFC 6675 refer to=20 equation (4) of RFC 5681 to reduce ssthresh and cwnd when a loss=20 requiring a congestion control action is detected: (cwnd =3D) ssthresh =3D FlightSize / 2) And RFC 5681 gives a warning not to halve cwnd in the equation but=20 FlightSize. That is, this equation is what an implementer intuitively would use=20 when reading the relevant RFCs but it gives a wrong result for=20 outstanding data when in fast recovery (when the sender is in=20 congestion avoidance and the equation (4) is used to halve cwnd, it=20 gives a correct result). More precisely, during fast recovery FlightSize is inflated when new=20 data is sent and reduced when segments are cumulatively Acked.=20 What the outcome is depends on the loss pattern. In the worst case,=20 FlightSize is signficantly larger than in the beginning of the fast=20 recovery when FlightSize was (correctly) used to determine the halved=20 value for cwnd and ssthresh, i.e., equation (4) may result in=20 *increasing* cwnd upon detecting a loss of a rexmitted segment, instead=20 of further halving it. A clever implementer might have no problem to have it right with some=20 thinking but I am afraid that there will be incorrect implementations=20 with what is currently specified. Not all implementers have spent=20 signicicant fraction of their career in solving TCP peculiarities. > For (2), the RTO timer is still operative so > the RTO recovery rules would still follow. In short: When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1 MSS= ,=20 and slow start is entered. When with a RACK_TLP implementation timer (PTO) expires,=20 normal fast recovery is entered (unless implementing=20 also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1. This means that this document explicitly modifies standard TCP congestion=20 control when there are no acks coming and the retransmission timer=20 expires from: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer) 1. RTO timer expires 2. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit one segment 3. Ack of rexmit sent in step 2 arrives 4. cwnd =3D cwnd+1 MSS; send two segments ... to: PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the timer) 1. PTO times expires 2. (cwnd=3D1 MSS); (re)xmit one segment 3. Ack of (re)xmit sent in srep 2 arrives 4. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcwnd segments For example, if FlightSize is 100 segments when timer expires, congestion control is the same in steps 1-3, but in step 4 the=20 current standard congestion control allows transmitting 2 segments,=20 while RACK-TLP would allow blasting 50 segments. Question is: what is the justification to modify standard TCP=20 congestion control to use fast recovery instead of slow start for a=20 case where timeout is needed to detect loss because there is no=20 feedback and ack clock is lost? The draft does not give any=20 justification. This clearly is in conflict with items (0) and (1)=20 in BCP 133 (RFC 5033). Furthermore, there is no implementation nor experimental experience=20 evaluating this change. The implementation with experimental experience=20 uses PRR (RFC 6937) which is an Experimental specification including a=20 novel "trick" that directs PRR fast recovery to effectively use slow=20 start in this case at hand. > In other words, I am not seeing a case that requires new congestion > control concepts except as discussed in 9.3. See above. The change in standard congestion control for (2). The draft intends not to change congestion control but effectively it=20 does without any operational evidence. What's also is missing and would be very useful: - For (1), a hint for an implementer saying that because RACK-TLP is able to detect a loss of a rexmit unlike any other loss detection algorithm, the sender MUST react twice to congestion (and cite RFC 5681). And cite a document where necessary correct actions are described. - For (1), advise that an implementer needs to keep track when it detects a loss of a retransmitted segment. Current algorithms in the draft detect a loss of retransmitted segment exactly in the same way as loss of any other segment. There seems to be nothing to track when a retransmission of a retransmitted segment takes place. Therefore, the algorithms should have additional actions to correctly track when such a loss is detected. - For (1), discussion on how many times a loss of a retransmission of the same segment may occur and be detected. Seems that it may be possible to drop a rexmitted segment more than once and detect it also several times? What are the implications? - If previous is possible, then the algorithm possibly also may detect a loss of a new segment that was sent during fast recovery? This is also loss in two successive windows of data, and cwnd MUST be lowered twice. This discussion and necessary actions to track it are missing, if such scenario is possible. > What am I missing? Hope the above helps. /Markku > On Tue, Dec 15, 2020 at 10:57 AM Markku Kojo > wrote: > Hi Neal, all, > > (my apologies for this message getting so long but I didn't > want to drop > any parts of it in case someone wants to get the entire > discussion in one > piece. Also, apologies for repeating some of my concerns > inline below; > Those who are clear with the problems may well opt skipping > those parts.) > > Thanks Neal for the reply. I believe we are slowly > converging with many > of my comments but two of the important issues still remain > open. That is, > where can an implementer find advice for correct congestion > control > actions with RACK-TLP, when: > (1) a loss of rexmitted segment is detected > (2) an entire flight of data gets dropped (and detected), > =A0 =A0 =A0that is, when there is no feedback available and a > timeout > =A0 =A0 =A0is needed to detect the loss > > I fully understand the intent of the RACK-TLP draft not to > include > congestion control actions in this document (or the intent > to minimise > such advise). However, when new ways to detect loss are > introduced and > published (as this document would do), IMHO it is > imperative to have such > congestion control actions readily available for an > implementer. AFAIK > we do not have in the RFC series correct actions available > for these two > cases. > > I do not have a strong opinion whether the necessary > actions should be in > this document or in another document, as long as we have > them. This is > more or less a process decision, I think. > > Please see more details inline. > > I also investigated a bit more on RACK-TLP as specified in > the draft and > it seems that there is a problem with the pseudocode as > currently > presented (some sequence numbers seem to be off by one, > resulting in > wrong outcome in some/many? cases). Please see inline in > the end of my > reply. >=20 > > =A0 On Sat, 12 Dec 2020, Neal Cardwell wrote: > > > Hi Markku, > > > > Thanks for your many detailed and thoughtful comments. > Please see > > below in-line for our comments based on discussions among > RACK-TLP > > draft authors. > > > > On Tue, Dec 8, 2020 at 11:21 AM Markku Kojo > wrote: > >> > >> Hi, > >> > >> please see inline. > >> > >> On Mon, 7 Dec 2020, Yuchung Cheng wrote: > >> > >>> On Mon, Dec 7, 2020 at 8:06 AM Markku Kojo > wrote: > >>>> > >>>> Hi Yuchung, > >>>> > >>>> thanks for your reply. My major point is that IMHO > this RACK-TLP > >>>> specification should give the necessary advice w.r.t > congestion control > >>>> in cases when such advice is not available in the RFC > series or is not > >>>> that easy to interpreted correctly from the existing > RFCs. > >>>> > >>>> Even though the CC principles were available in RFC > series I believe you > >>>> agree with me that getting detailed CC actions correct > is sometimes quite > >>>> hard, especially if one needs to interpret and apply > them from another > >>>> spec than what one is implementing. Please see more > details inline below. > >>>> > >>>> In addition, we need to remember that this document is > not meant only for > >>>> TCP experts following the tcpm list and having deep > understanding of > >>>> congestion control but also those implementing TCP, > for the very first > >>>> time, for various appliances, for example. They do not > have first hand > >>>> experience in implementing TCP congestion control and > deserve clear > >>>> advice what to do. > >>>> > >>>> On Fri, 4 Dec 2020, Yuchung Cheng wrote: > >>>> > >>>>> On Fri, Dec 4, 2020 at 5:02 AM Markku Kojo > wrote: > >>>>>> > >>>>>> Hi all, > >>>>>> > >>>>>> I know this is a bit late but I didn't have time > earlier to take look at > >>>>>> this draft. > >>>>>> > >>>>>> Given that this RFC to be is standards track and > RECOMMENDED to replace > >>>>>> current DupAck-based loss detection, it is important > that the spec is > >>>>>> clear on its advice to those implementing it. > Current text seems to > >>>>>> lack important advice w.r.t congestion control, and > even though > >>>>>> the spec tries to decouple loss detection from > congestion control > >>>>>> and does not intend to modify existing standard > congestion control > >>>>>> some of the examples advice incorrect congestion > control actions. > >>>>>> Therefore, I think it is worth to correct the > mistakes and take > >>>>>> yet another look at a few implications of this > specification. > >>>>> As you noted, the intention is to decouple the two as > much as possible > >>>>> > >>>>> Unlike the 20 years ago where TCP loss detection and > congestion > >>>>> control are essentially glued in one piece, the > decoupling of the two > >>>>> (including modularizing congestion controls in > implementations) has > >>>>> helped fueled many great inventions of new congestion > controls. > >>>>> Codifying so-called-default C.C. reactions in the > loss detection is a > >>>>> step backward that the authors try their best to > avoid. > >>>> > >>>> While I fully agree with the general principle of > decoupling loss > >>>> detection from congestion control when it is possible > without leaving > >>>> open questions, I find it hard to get congestion > control right with this > >>>> spec in certain cases I raised just by following the > current standards > >>>> track CC specifications. The reason for this is that > RACK-TLP introduces > >>>> new ways to detect loss (i.e., not present in any > earlier standard track > >>>> RFC) and the current CC specifications do not provide > correct CC actions > >>>> for such cases as I try to point out below. > >>>> > >>>>> To keep the > >>>>> document less "abstract / unclear" as many WGLC > reviewers commented, > >>>>> we use examples to illustrate that includes CC > actions. But the > >>>>> details of these CC actions are likely to become > obsolete as CC > >>>>> continues to advance hopefully. > >>>> > >>>> Agreed. But I would appreciate if the CC actions in > the examples would > >>>> correctly follow what is specified in the the current > CC RFCs. And, I > >>>> would suggest explicitly citing the RFC(s) that each > of the examples is > >>>> illustriating so that there is no doubt which CC > variant the example > >>>> is valid with. Then there is no problem with the > correctness of the > >>>> example either even if the cited RFC becomes later > obsoleted. > >>>> > >>>>>> > >>>>>> Sec. 3.4 (and elsewhere when discussing recovering a > dropped > >>>>>> retransmission): > >>>>>> > >>>>>> It is very useful that RACK-TLP allows for > recovering dropped rexmits. > >>>>>> However, it seems that the spec ignores the fact > that loss of a > >>>>>> retransmission is a loss in a successive window that > requires reacting > >>>>>> to congestion twice as per RFC 5681. This advice > must be included in > >>>>>> the specification because with RACK-TLP recovery of > dropped rexmit > >>>>>> takes place during the fast recovery which is very > different > >>>>>> from the other standard algorithms and therefore > easy to miss > >>>>>> when implementing this spec. > >>>>> > >>>>> per RFC5681 sec 4.3 > https://tools.ietf.org/html/rfc5681#section-4.3 > >>>>> "Loss in two successive windows of data, or the loss > of a > >>>>>=A0 retransmission, should be taken as two indications > of congestion and, > >>>>>=A0 =A0therefore, cwnd (and ssthresh) MUST be lowered > twice in this case." > >>>>> > >>>>> RACK-TLP is a loss detection algorithm. RFC5681 is > crystal clear on > >>>>> this so I am not sure what clause you suggest to add > to RACK-TLP. > >>>> > >>>> Right, this is the CC *principle* in RFC 5681 I am > refering to but I am > >>>> afraid it is not enough to help one to correctly > implement such lowering > >>>> of cwnd (and ssthresh) twice when a loss of a > retransmission is detected > >>>> during Fast Recovery. Nor do RFCs clearly advice > *when* this reduction > >>>> must take place. > >>>> > >>>> Congestion control principles tell us that congestion > must be reacted > >>>> immediately when detected. But at the same time, > standards track CC > >>>> specifications react to congestion only once during > Fast Recovery > >>>> because the losses in the current window, which Fast > Recovery repairs, > >>>> occured during the same RTT. That is, the current CC > specifications do > >>>> not handle lost rexmits during Fast Recovery but, > instead, the correct CC > >>>> reaction to a loss of a rexmit is automatically > achieved by those > >>>> specifications via RTO when cwnd is explicitly reset > upon RTO. > >>>> > >>>> Furthermore, the problem I am trying to point out is > that there is no > >>>> correct rule/formula available in the standards track > RFCs that would > >>>> give the correct way to reduce cwnd when the loss of > rexmit is detected > >>>> with RACK-TLP. > >>>> > >>>> I suggest everyone reading this message stops reading > at this point > >>>> for a while before continuing reading and figures out > themselves what > >>>> they think would be the correct equation to use in the > standards RFC > >>>> series to find the new halved value for cwnd when > RACK-TLP detects a loss > >>>> of a rexmit during Fast Recovery. I would appreciate a > comment on the > >>>> tcpm list from those who think they found the correct > answer immediately > >>>> and easily, and what was the formula to use. > >>>> > >>>> ... > >>>> > >>>> I think the best advice one may find by looking at RFC > 6675 (and RFC > >>>> 5681) is to set > >>>> > >>>>=A0 =A0ssthresh =3D cwnd =3D (FlightSize / 2) (RFC 6675, Sec = 5, > algorithm step 4.2) > >>>> > >>>> Now, let's modify the example in Sec 3.4 of the draft: > >>>> > >>>> 1. Send P0, P1, P2, ..., P20 > >>>>=A0 =A0 [Assume P1, ..., P20 dropped by network] > >>>> > >>>> 2.=A0 =A0Receive P0, ACK P0 > >>>> 3a.=A0 2RTTs after (2), TLP timer fires > >>>> 3b.=A0 TLP: retransmits P20 > >>>> ... > >>>> 5a.=A0 Receive SACK for P20 > >>>> 5b.=A0 RACK: marks P1, ..., P20 lost > >>>>=A0 =A0 =A0 =A0set cwnd=3Dssthresh=3DFlightSize/2=3D10 > >>>> 5c.=A0 Retransmit P1, P2 (and some more depending on how > CC implemented) > >>>>=A0 =A0 =A0 =A0[P1 retransmission dropped by network] > >>>> > >>>>=A0 =A0 =A0 =A0Receive SACK P2 & P3 > >>>> 7a.=A0 RACK: marks P1 retransmission lost > >>>>=A0 =A0 =A0 =A0As per RFC 6675: set > cwnd=3Dssthresh=3DFlightSize/2=3D20/2=3D10 > >>>> 7b.=A0 Retransmit P1 > >>>>=A0 =A0 =A0 =A0... > >>>> > >>>> So, is the new value of the cwnd (10MSS) correct and > halved twice? If not, > >>>> where is the correct formula to do it? > >>>> > >>>> Before RFC 5681 was published we had a discussion on > FlighSize and that > >>>> during Fast Recovery it does not reflect the amount of > segments in > >>>> flight correctly but may also have a too large value. > It was decided not > >>>> to try to correct it because it only has an impact > when RTO fires during > >>>> Fast Recovery and in such a case cwnd is reset to 1 > MSS. Having too large > >>>> ssthresh for RTO recovery in some cases was not > considered that bad > >>>> because a TCP sender anyway takes to most conservative > CC action with the > >>>> cwnd and would slow start from cwnd =3D 1 MSS. But now > when RACK-TLP enables > >>>> detecting loss of a rexmit during Fast Recovery we > have an unresolved > >>>> problem. > >>> > >>>> 1. Send P0, P1, P2, ..., P20 > >>>>=A0 =A0 [Assume P1, ..., P20 dropped by network] > >>>> > >>>> 2.=A0 =A0Receive P0, ACK P0 > >>>> 3a.=A0 2RTTs after (2), TLP timer fires > >>>> 3b.=A0 TLP: retransmits P20 > >>>> ... > >>>> 5a.=A0 Receive SACK for P20 > >>>> 5b.=A0 RACK: marks P1, ..., P20 lost > >>>>=A0 =A0 =A0 =A0set cwnd=3Dssthresh=3DFlightSize/2=3D10 > >>>> 5c.=A0 Retransmit P1, P2 (and some more depending on how > CC implemented) > >>>>=A0 =A0 =A0 =A0[P1 retransmission dropped by network] > >>>> > >>>>=A0 =A0 =A0 =A0Receive SACK P2 & P3 > >>>> 7a.=A0 RACK: marks P1 retransmission lost > >>>>=A0 =A0 =A0 =A0As per RFC 6675: set > cwnd=3Dssthresh=3DFlightSize/2=3D20/2=3D10 > >>>> 7b.=A0 Retransmit P1 > >>> > >>> To account for your points, IMO clearly stating the > existing CC RFC > >>> interactions w/o mandating any C.C. actions are the > best way to move > >>> forward. Here are the text diff I proposed: > >>> > >>> "Figure 1, above, illustrates=A0 ... > >>> Notice a subtle interaction with existing congestion > control actions > >>> on event 7a. It essentially starts another new episode > of congestion > >>> due to the detection of lost retransmission. Per > RFC5681 (section 4.3) > >>> that loss in two successive windows of data, or the > loss of a > >>> retransmission, should be taken as two indications of > congestion as a > >>> principle. But RFC6675 that introduces the pipe concept > does not > >>> specify such a second window reduction. This document > reminds RACK-TLP > >> > >> This is not quite correct characterization of RFC 6675. > >> RFC 6675 does not repeat all guidelines of RFC 5681. RFC > 6675 DOES specify > >> the two indications of congestion implicitly by clearly > stating in the > >> intro that it follows the guidelines set in RFC=A0 5681. > >> And RFC 5681 articulates a set of MUSTs which ALL > alternative loss > >> recovery algorithms MUST follow in order to become RFCs. > >> > >> (*) RFC 5681, Sec 4.3 (pp. 12-13): > >> > >>=A0 =A0"While this document does not standardize any of the > >>=A0 =A0 specific algorithms that may improve fast > retransmit/fast recovery, > >>=A0 =A0 ... > >>=A0 =A0 That is, ... > >>=A0 =A0 Loss in two successive windows of data, or the loss > of a > >>=A0 =A0 retransmission, should be taken as two indications of > congestion and, > >>=A0 =A0 therefore, cwnd (and ssthresh) MUST be lowered twice > in this case." > >> > >> > >>> implementation to carefully consider the new multiple > congestion > >>> episode cases in the corresponding congestion control." > >> > >> I am sorry to say that this is very fuzzy and leaves an > implementer > >> all alone what to do. > >> > >> More inportantly, AFAIK we have no discussion nor > consensus in the IETF > >> on what is the correct CC action when lost rexmit is > detected. > >> Should one reset cwnd like current CCs do, or would > "halving again" be > >> fine, or something else? IMHO this requires > experimentation to decide. > >> > >> I assumed there is an implementation of RACK-TLP with > corresponding CC > >> actions and experimental results to devise what are the > implications of > >> the selected CC action(s) with various levels of > congestion. But it seems > >> we do not have such implementation nor experimental > evidence? Am I wrong? > > > > [RACK-TLP-team:] > > > > We do have such implementations of RACK-TLP with > corresponding CC > > actions, and experimental results were reported in > RACK-TLP > > presentations and earlier revisions of the RACK-TLP > draft. With > > Yes, that was my understanding what is implemented. Given > there is this > implementation that reacts appropriately to congestion when > RACK-TLP > detects loss of a retransmitted segment, could you please > illuminate the > congestion control actions taken in the implementation with > which there > is experimental experience. > > If I understood it correctly, the RACK-TLP in question is > implemented > with PRR. Let's assume another implementer wants to add > RACK-TLP with PRR > in the stack she/he is working on. I believe that the > implementer would > think that detecting a loss of a rexmit during fast > recovery would start > a new congestion episode in PRR (and that's what Yuchung > also indicated > in the new proposed text in his previeous reply shown > above). With > that advice and reading RFC 6937, an implementer would > reinitialize PRR > state for the new congestion episode. So how should the > implementer > calculate new values for ssthresh and RecoverFS? Should > she/he use what > is currently described in RFC 6937, Sec 3 (to keep > discussion simple > assume the implementer wants to have an IETF Standards > Track comformant > implementation, so use CongCtrlAlg() =3D FlightSize/2): > > =A0 ssthresh =3D CongCtrlAlg()=A0 // Target cwnd after recovery > =A0 prr_delivered =3D 0=A0 =A0 =A0 =A0 =A0// Total bytes delivere= d during > recovery > =A0 prr_out =3D 0=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// Total bytes se= nt during > recovery > =A0 RecoverFS =3D snd.nxt-snd.una // FlightSize at the start of > recovery > > Or should one use something else? AFAIK depending on the > loss pattern > neither FlightSize nor "snd.nxt-snd.una" would give correct > values for > the intended behavior. Depending on the loss pattern, at > the time > of detecting a loss of rexmit FlighSize may be ~ 50% larger > than in the > beginning of fast recovery. This would result in increasing > ssthresh > (send rate), instead of decreasing it. It seems that > something else in > PRR algo would also need to be modified to get sndcnt > correct but I > cannot figure it out right now. > > If one wants to implement RACK-TLP without PRR, that is, > with RFC 6675, > we have the same probelm with FlightSize in determining a > new value for > cwnd and ssthresh. > > My point is that using what we currently have out there in > the RFC > series gives incorrect CC advice. And, having correct CC > actions in this > case is far from trivial so IMHO high quality standards > specifications > should not leave an implementer of RACK-TLP alone to figure > it out. > > In addition, if a new episode of fast recovery is started > for CC purposes > how would that play together with RACK-TLP loss detection? > In Sec 7.1 the > text says initialize (reset) TLP.end_seq and TLP.is_retrans > when > initiating fast recovery. But detecting a lost rexmit > seemingly should > not reinitialize TLP because PTO is disabled during fast > recovery as per > Sec 7.2. If CC actions are in another document and loss > detection in this > document, it would be of high importance to clarify when > each of the > fast recovery episodies (CC vs. loss detection) are > supposed to end: is > the end condition the same or different? > > > respect to implementations, there is the Linux TCP stack, > which has > > been using RACK-TLP as the default loss recovery > algorithm since Linux > > v4.18 in August 2018. The exact commit is: > > > >=A0 b38a51fec1c1 tcp: disable RFC6675 loss detection > > > > With Linux, the default sender behavior since that commit > has been > > governed by CUBIC, PRR, and RACK-TLP. > > > > RACK-TLP is used by all Google TCP traffic, including > internal RPC > > traffic and external YouTube and google.com traffic over > the public > > Internet. At Google we have years of high-traffic-volume > experience > > with RACK-TLP with three different CC schemes: CUBIC+PRR, > BBRv1, and > > BBRv2. > > > > My understanding is that Netflix FreeBSD TCP traffic uses > RACK-TLP, > > and Microsoft Windows TCP traffic has also been using > RACK-TLP. > > And I wonder what would be the CC actions taken in each of > these > implementations when a loss of rexmited segment is > detected? > > >> I sincerely apologize that this got raised this late in > the prosess and > >> I know how irritating it may be. I like the idea of > RACK-TLP and by no > >> means my intention is not to hold up the process but the > lack of evidence > >> makes me quite concerned. In particular, when this > document says that > >> the current loss detection SHOULD be replaced in all > implementations with > >> RACK-TLP. > >> > >>> and to emphasize in section 9.3 Interaction with > congestion control > >>> > >>> "9.3.=A0 Interaction with congestion control > >>> > >>> RACK-TLP intentionally decouples loss detection ... > this appropriate. > >>> As mentioned in Figure 1 caption, RFC5681 mandates a > principle that > >>> Loss in two successive windows of data, or the loss of > a > >>> retransmission, should be taken as two indications of > congestion, and > >>> therefore reacted separately. However implementation of > RFC6675 pipe > >>> algorithm may not directly account for this newly > detected congestion > >>> events properly. Therefore the documents reminds > RACK-TLP > >>> implementation to carefully consider these implications > in its > >>> corresponding congestion control. > >>> > >>> ..." > >>> > >>> > >>> > >>>> > >>>> > >>>>>> Sec 9.3: > >>>>>> > >>>>>> In Section 9.3 it is stated that the only > modification to the existing > >>>>>> congestion control algorithms is that one > outstanding loss probe > >>>>>> can be sent even if the congestion window is fully > used. This is > >>>>>> fine, but the spec lacks the advice that if a new > data segment is sent > >>>>>> this extra segment MUST NOT be included when > calculating the new value > >>>>>> of ssthresh as per the equation (4) of RFC 5681. > Such segment is an > >>>>>> extra segment not allowed by cwnd, so it must be > excluded from > >>>>>> FlightSize, if the TLP probe detects loss or if > there is no ack > >>>>>> and RTO is needed to trigger loss recovery. > >>>>> > >>>>> Why exclude TLP (or any data) from FlightSize? The > congestion control > >>>>> needs precise accounting of the flight size to react > to congestion > >>>>> properly. > >>>> > >>>> Because FlightSize does not always reflect the correct > amount of data > >>>> allowed by cwnd. When a TCP sender is not already in > loss recovery and > >>>> it detects loss, this loss indicates the congestion > point for the TCP > >>>> sender, i.e., how much data it can have outstanding. > It is this amount of > >>>> data that it must use in calculating the new value of > cwnd (and > >>>> ssthresh), so it must not include any data sent beyond > the congestion > >>>> point. When TLP sends a new data segment, it is beyond > the congestion > >>>> point and must not be included. Same holds for the > segments sent via > >>>> Limited Transmit: they are allowed to be send out by > the packet > >>>> conservation rule (DupAck indicates a pkt has left the > network, but does > >>>> not allow increasing cwnd), i.e., the actual amount of > data in flight > >>>> remains the same. > >>>> > >>>>>> In these cases the temporary over-commit is not > accounted for as DupAck > >>>>>> does not decrease FlightSize and in case of an RTO > the next ACK comes too > >>>>>> late. This is similar to the rule in RFC 5681 and > RFC 6675 that prohibits > >>>>>> including the segments transmitted via Limitid > Transmit in the > >>>>>> calculation of ssthresh. > >>>>>> > >>>>>> In Section 9.3 a few example scenarios are used to > illustriate the > >>>>>> intended operation of RACK-TLP. > >>>>>> > >>>>>>=A0 =A0In the first example a sender has a congestion > window (cwnd) of 20 > >>>>>>=A0 =A0segments on a SACK-enabled connection.=A0 It sends > 10 data segments > >>>>>>=A0 =A0and all of them are lost. > >>>>>> > >>>>>> The text claims that without RACK-TLP the ending > cwnd would be 4 segments > >>>>>> due to congestion window validation. This is > incorrect. > >>>>>> As per RFC 7661 the sender MUST exit the > non-validated phase upon an > >>>>>> RTO. Therefore the ending cwnd would be 5 segments > (or 5 1/2 segments if > >>>>>> the TCP sender uses the equation (4) of RFC 5681). > >>>>>> > >>>>>> The operation with RACK-TLP would inevitably result > in congestion > >>>>>> collapse if RACK-TLP behaves as described in the > example because > >>>>>> it restores the previous cwnd of 10 segments after > the fast recovery > >>>>>> and would not react to congestion at all! I think > this is not the > >>>>>> intended behavior by this spec but a mistake in the > example. > >>>>>> The ssthresh calculated in the beginning of loss > recovery should > >>>>>> be 5 segments as per RFC 6675 (and RFC 5681). > >>>>> To clarify, would this text look more clear? > >>>>> > >>>>> 'an ending cwnd set to the slow start threshold of 5 > segments (half of > >>>>> the original congestion window of 10 segments)' > >>>> > >>>> This is correct, but please replace: > >>>> > >>>>=A0 =A0(half of the original congestion window of 10 > segments) > >>>> --> > >>>>=A0 =A0(half of> the original FlightSize of 10 segments) > >>> > >>> sure will do > >>> > >>>> > >>>> cwnd in the example was 20 segments. > >>>> > >>>> Please also correct the ending cwnd for "without RACK" > scenario. > >>>> I poined out wrong equation number IN RFC 5681 and > INCORRECT cwnd value, > >>>> my apologies. It MAENT equation (3) AND that results > in ending cwnd of 5 > >>>> and 2/5 MSS (not 5 and 1/2 MSS). > >>>> NB: and if a TCP sender implements entering CA when > cwnd > ssthresh, then > >>>> ending cwnd would be 6 and 1/6 MSS). > >>>> > >>>>>> > >>>>>> Furthermore, it seems that this example with > RACK-TLP refers to using > >>>>>> PRR_SSRB which effectively implements regular slow > start in this > >>>>>> case(?). From congestion control point of view this > is correct because > >>>>>> the entire flight of data as well as ack clock was > lost. > >>>>>> > >>>>>> However, as correctly discussed in Sec 2, congestion > window must be reset > >>>>>> to 1 MSS when an entire flight of data is and Ack > clock is lost. But how > >>>>>> can an implementor know what to do if she/he is not > implementing the > >>>>>> experimental PRR algrorithm? This spec articulates > specifying an > >>>>>> alternative for DupAck counting, indicating that TLP > is used to trigger > >>>>>> Fast Retransmit & Fast Recovery only, not a loss > recovery in slow start. > >>>>>> This means that without an additional advise an > implementation of this > >>>>>> spec would just halve the cwnd and ssthresh and send > a potentially very > >>>>>> large burst of segments in the beginning of the Fast > Recovery because > >>>>>> there is no ack clock. So, this spec begs for an > advise (MUST) when to > >>>>>> slow start and reset cwnd and when not, or at least > a discussion of > >>>>>> this problem and some sort of advise what to do and > what to avoid. > >>>>>> And, maybe a recommendation to implement it with > PRR? > >>>>> > >>>>> It's wise to decouple loss detection (RACK-TLP) vs > congestion/burst > >>>>> control (when to slow-start). The use of PRR is just > an example to > >>>>> illustrate and not meant for a recommendation. > >>>> > >>>> I understand the use of PRR was just an example, but > my point is that if > >>>> one wants to implement RACK-TLP but does not intend to > implement PRR but > >>>> RFC 6675 then we do not have a rule in RFC 6675 to > correctly implement > >>>> CC for the case when an entire flight is lost and loss > is detected with > >>>> TLP. Congestion control principle for this is clear > and also stated in > >>>> this draft but IMHO it is not enough to ensure correct > implementation. > >>>> > >>>> To my understanding we only have implementation > experience for RACK-TLP > >>>> only togerher with PRR, which has the necessary rule > to handle this kind > >>>> of scenario correctly. > >>>> > >>>> So, my question is how can one implement CC correctly > without PRR such > >>>> a scenario where entire inflight is lost? > >>>> Which rule and where in the RFC series gives the > necessary guidance to > >>>> reset cwnd and slow start when TCP detets loss of an > entire flight? > >>> > >>> I think we're going in loops. To move forward it'd help > if you suggest > >>> some text you like to change. > >> > >> Unfortunately I do not have an immediate solution. I > assumed there is an > >> implementation and you could enlighten what was the > solution there and > >> experimental results showing how it seems to work. If I > have understood > >> it correctly there is a solution/implementation and > experience of RACK-TLP > >> that works together with PRR but no > solution/implementation nor experience > >> how it works without PRR. Am I correct? > > > > [RACK-TLP-team:] > > > > The implementation solutions and experiments were > mentioned above. Our > > team's experience is with RACK-TLP in combination with > either > > CUBIC+PRR, BBRv1, and BBRv2. We are not sure if there are > other TCP > > implementations that implement RACK-TLP without PRR. > > So, in addition to the lack of experimental evidence using > RACK-TLP > without PRR we have a specification problem for which we > have no answer: > > The RACK-TLP text suggests that if PTO fires and TLP > detects a loss, the > TCP sender enters fast recovery. But > > PTO =3D timeout that expires if there is no feedback (ACKs) > from > =A0 =A0 =A0 =A0the network, i.e., entire flight of data is lost. > > TLP =3D a single segment that is sent when timer expires. > What is > =A0 =A0 =A0 =A0different compared to RTO is that PTO may expire > faster > =A0 =A0 =A0 =A0and a different segment is (re)transmitted, allowi= ng > to > =A0 =A0 =A0 =A0detect more than one lost segment with a single Ac= k > w/ SACK > =A0 =A0 =A0 =A0triggered by TLP (with regular RTO recovery only t= he > next > =A0 =A0 =A0 =A0unacknowledged segment can reliably be considered > lost) > > >From congestion control point of view this means that PTO > is no different > from RTO. The congestion control principle as stated in Sec > 2.2 of this > document tells us that a loss of entire flight deserves a > cautious > response, i.e., reset cwnd and slow start. > > When RACK-TLP is implemented with PRR we have appropriate > CC actions > specified in RFC 6937 that effectively reset cwnd and force > the TCP sender > to slow start, even though it tecnically enters fast > recovery. This is > safe. > > However, if an implementer wants to implement RACK-TLP > without PRR, > she/he has to consult RFC 6675 which gives an incorrect CC > response for > this case, resulting in an unsafe implementation. The > problem is not in > the fast recovery algorithm in RFC 6675 because it was not > intended to be > initiated with TLP-kind of loss detection. > > So the question is how to ensure an implementer has the > necessary advice > to implement correct congestion control actions for > RACK-TLP once this > document is published. The lack of correct advice becomes > even more > prominent as this document requires (all SACK capable) TCPs > to implement > RACK-TLP. > > >> Given my understanding of PRR, the problem of an entire > flight being > >> dropped is quite nicely solved with it. However, > implementing RACK-TLP > >> without PRR begs for a solution. Here is my current > understanding: > >> > >> (1) RACK part is what can be called to "replace" DupAck > counting > >> (2) TLP part is effectively a new retransmission timeout > to detect > >>=A0 =A0 =A0 a loss of an entire flight of data (i.e., it is > only invoked > >>=A0 =A0 =A0 when a tail of the current flight becomes lost > which equals to > >>=A0 =A0 =A0 the case of losing an entire flight since all > segments before > >>=A0 =A0 =A0 the tail loss will get cumulatively Acked and hence > these segments > >>=A0 =A0 =A0 are not anymore a part of the current flight at the > time the loss > >>=A0 =A0 =A0 is detected. And we an assume application limited > TCP sender. > >> (3) Current CC principles require resetting cwnd in such > a case > >>=A0 =A0 =A0 and entering slow start (and so effectively does > PRR though it is > >>=A0 =A0 =A0 not explicitly stated in RFC 6937). Slow start > avoids a big burst > >>=A0 =A0 =A0 if the lost flight is big. > >> (4) RACK-TLP would possibly like to allow that cwnd is > set to a half > >>=A0 =A0 =A0 of the lost flight and not to slow start. This > means that the bigger > >>=A0 =A0 =A0 the lost flight is, the bigger is the burst that > gets transmitted at > >>=A0 =A0 =A0 the beginning of the recovery which is bad. So, > this approach would > >>=A0 =A0 =A0 need at least a rule/advice for burst avoidance > (slow start, pacing, > >>=A0 =A0 =A0 ...). > >> (5) When the lost flight is small (<=3D 4 segments) there > is no difference > >>=A0 =A0 =A0 in recovery efficiency between (3) and (4). If the > lost flight is > >>=A0 =A0 =A0> 5 segments, then (4) takes less RTTs to complete > the recovery > >>=A0 =A0 =A0 but generates a burst. Note, even if pacing over > one SRTT would be > >>=A0 =A0 =A0 used, it is still a burst. > >> > >> Now, it would be useful to have experimental data to > know how the size of > >> the lost flight is distributed. Is it typically just a > few segments as > >> illustriated in the examples of the draft or is it often > larger? > >> > >> My advice would be to add a rule that cwnd MUST be reset > to 1 MSS > >> and the sender MUST enter slow start if TLP detects loss > of an entire > >> flight. This would be safe. Otherwise, without > experimental evidence from > >> a wide range of different network conditions and > workloads it feels > >> unsafe to allow more aggressive approach. > > > > [RACK-TLP-team:] > > > > Our team's position is that the RACK-TLP draft documents > a loss > > detection algorithm, and normative declarations about > congestion > > control behavior (like your "cwnd MUST be reset to 1 > MSS", above) > > should be in a separate document focused on congestion > control. > > I do not disagree with you what becomes to the role of > congestion control > in the RACK-TLP draft. It may well be in another document > but IMHO such > document must be available at the time this docment gets > published. > How can we otherwise ensure correct implementations? > > So this is more of a process question than critique towards > the draft. >=20 > > >>>>> Section 3 has a lengthy section to elaborate the key > point of RACK-TLP > >>>>> is to maximize the chance of fast recovery. How C.C. > governs the > >>>>> transmission dynamics after losses are detected are > out of scope of > >>>>> this document in our authors' opinions. > >>>>> > >>>>> > >>>>>> > >>>>>> Another question relates to the use of TLP and > adjusting timer(s) upon > >>>>>> timeout. In the same example discussed above, it is > clear that PTO > >>>>>> that fires TLP is just a more aggressive retransmit > timer with > >>>>>> an alternative data segment to (re)transmit. > >>>>>> > >>>>>> Therefore, as per RFC 2914 (BCP 41), Sec 9.1, when > PTO expires, it is in > >>>>>> effect a retransmission timout and the timer(s) must > be backed-off. > >>>>>> This is not adviced in this specification. Whether > it is the TCP RTO > >>>>>> or PTO that should be backed-off is an open > question.=A0 Otherwise, > >>>>>> if the congestion is persistent and further > transmission are also lost, > >>>>>> RACK-TLP would not react to congestion properly but > would keep > >>>>>> retransmitting with "constant" timer value because > new RTT estimate > >>>>>> cannot be obtained. > >>>>>> On a buffer bloated and heavily congested bottleneck > this would easily > >>>>>> result in sending at least one unnecessary > retransmission per one > >>>>>> delivered segment which is not advisable (e.g., when > there are a huge > >>>>>> number of applications sharing a constrained > bottleneck and these > >>>>>> applications are sending only one (or a few) > segments and then > >>>>>> waiting for an reply from the peer before sending > another request). > >>>>> > >>>>> Thanks for pointing to the RFC.=A0 After TLP, RTO > timers will > >>>>> exp-backoff (as usual) for stability reasons > mentioned in sec 9.3 > >>>>> (didn't find 9.1 relevant). > >>>> > >>>> My apologies for refering to the wrong section of RFC > 2914, Yes, I meant > >>>> Sec 9.3. > >>>> > >>>>> In your scenario, you presuppose the > >>>>> retransmission is unnecessary so obviously TLP is not > good. Consider > >>>>> what happens without TLP where all the senders fire > RTO spuriously and > >>>>> blow up the network. It is equally unfortunate > behavior. "bdp > >>>>> insufficient of many flows" is a congestion control > problem > >>>> > >>>> If (without TLP) RTO is spurious, it may result in > unnecessary > >>>> retransmissions. But we have F-RTO (RFC 5682) and > Eifel (RFC 3522) to > >>>> detect and resolve it without TLP, so I don't find it > as a problem. > >>>> > >>>> To clarify more, what I am concerned about. Think > about a scenario where a > >>>> (narrow) bottleneck becomes heavily congested by a > huge number of > >>>> competing senders such that the available capacity per > sender is less > >>>> than 1 segment (or << 1 MSS). > >>>> This is a situation that network first enters before > congestion collapse > >>>> gets realized. So, it is extremely important that all > CC and timer > >>>> mechanisms handle it properly. Regular TCP handles it > via RFC 6298 by > >>>> backing off RTO expotentially and keeping this > backed-off RTO until an > >>>> new ACK is received for new data. This saves RACK-TLP > from full congestion > >>>> collapse. But consider what happens: even though RTO > is backed off, each > >>>> time a TCP sender manages to get one segment through > (with cwnd =3D 1 MSS) > >>>> it always first arms PTO with more or less constant > value of 2*SRTT. If > >>>> the bottleneck is buffer bloated the actual RTT easily > exceeds 2*SRTT and > >>>> TLP becomes spurious. After a spurious TLP, RTO > expires (maybe more than > >>>> once before exponential back-off of RTO results in > large enough value) > >>>> and a new RTT sample is not received. So, SRTT remains > unchanged and even > >>>> if sometimes a new sample is received, SRTT gets very > slowly adjusted. As > >>>> a result, each TCP sender would keep on sending a > spurious TLP for each > >>>> new segment resulting in at least 50% of the packets > being unnecessary > >>>> rexmitted and the utilization of the bottleneck is < > 50%. This would not > >>>> be a full congestion collapse but has unwanted > symptoms towards > >>>> congestion collapse (Note: there is no clear line for > the level of > >>>> reduction in delivery of useful data is considered as > congestion > >>>> collapse). > >>> > >>> AFAIK you are saying: under extreme congestion shared > by many short > >>> flows, RACK-TLP can cause more packet losses because of > the more > >>> aggressive PTO timer. I agree and can add this to the > "section 9.3". > >> > >> No, that was not what I meant. This happens simply when > enough flows are > >> competing on the same bottleneck. It may be long flows > or maybe > >> applications with more or less continuous request-reply > exhanges. > >> E.g., if the bottleneck bit rate is 1 Mbits/s, RTT is > 500msecs and PMTU > >> is 1500B, then a bit over 40 simultaneous flows would > mean that the > >> bottleneck becomes fully utilized with the equal share > of roughly 1 MSS > >> per flow. With a quite typical bottleneck buffer size > roughly equaling to > >> BDP, about 80+ flows would fill up the buffer as well > and increase > >> RTT >=3D 1 secs.=A0 A buffer bloated bottleneck buffer would > mean even larger > >> RTT and allow more flows sharing the bottleneck without > loss. > >> > >> If the number of TCP flows is > 90 (or >> 90) RACK-TLP > would ends up > >> (almost) always unnecessarily retransmitting each new > segment once (PTO > >> being 1 sec or around 1 sec). RTO back-off after a few > rounds saves each > >> TCP sender from additional unnecessary rexmits but still > ~ 50% of the > >> deivered packets are not making any useful progress. > >> > >> If the bottleneck buffer is small, it would result in > more losses as you > >> suggest but would not be that much of problem because > majority of the > >> unnecessary rexmits would not get delivered over the > bottleneck link. > >> Instead, they wuold get dropped at the bottleneck. > Unnecessary rexmits > >> would just create extra load on the poth before the > bottleneck (which of > >> course is not a non-problem either). > > > > [RACK-TLP-team:] > > > > If we are correctly understanding the scenario you are > outlining, the > > PTO would likely not be 1 sec in this case. In this > scenario, the RTT > > is around 1sec, so the PTO would be around 2*srtt, which > would be > > around 2 secs. With a 1sec RTT, and even considering > delayed ACKs, it > > seems very unlikely that a 2 sec PTO would cause a > significant number > > of unnecessary TLP probes. > > Well. Roughly the first initiated 40 flows will have SRTT ~ > 0.5 sec. If > next ~ 40 flows arrive within an RTT or so they will get > RTT samples > roughly between 0.5 - 1.x secs. The rest 80 - N hundreds > flows will not > get an RTT sample and will use initial/default PTO =3D 1 sec > (unless using > timestamps). The larger the buffer bloat the worse things > get. > Once ~200 flows are competing over the bottleneck, RTT will > be well > beyond 2 secs and grows when more flows join, guaranteeing > spurious TLP > for each new segment (unless timestamps are in use). > > > Perhaps your postulated PTO of 1 sec is coming from the > pseudocode > > path in TLP_calc_PTO() where, if SRTT is not available, > the PTO is 1 > > second? However, this case where there is no SRTT only > happens if (a) > > the connection is *not* using TCP timestamps (enabled for > most > > connections on the public Internet, due to > default-enabled support in > > Linux/Android and iOS/MacOS), and (b) the connection has > *never* had a > > single RTT sample from a non-retransmitted packet. To > meet both of > > those conditions is quite rare in practice. Is this the > path that is > > causing your concerns about a PTO of 1 sec? > > Sure. Having timestamps helps a lot in case the bottleneck > buffer is > buffer bloated (though RTT sample will not include delayed > Ack effect for > rexmits that are immediately acked). But RACK-TLP does not > require > timestamps and there are a lot of TCP stacks out there in > addition to > Linux/Android and iOS/MacOS. And more are coming with IoT > expansion, > for example. In addition, it is quite suprising how old > (mobile) devices > many people are using, some of which are old enough and > have not been > eligible for an OS upgrade for many years. > > But my quick example scenario was just to illustriate the > problem, maybe > typical in some areas where the only Internet access is > over a > geostationary satellite connection and people quite likely > not using > mobile/cellular devices. And, I selected a buffer-bloated > scenario > because that generates unnecessary rexmits which are a > prerequisite for > classical congestion collapse. > > It may well be in some environments that these hundreds of > competing > flows are application limited (request-reply continuously) > and get > started over a longer period of time, each getting RTT > sample(s) over a > lightly loaded bottleneck and then becoming idle or sending > data only > sporadically. Then later they all become active more or > less at the same > time (maybe by a common trigger). Base RTT may then be much > lower than > 500 ms as long as there is enough buffer bloat. > > Furthermore, timestamps are not that helpful in case of a > heavily > congested small buffer bottleneck. Having approximately > accurate SRTT > does not alone help in reducing the sending rate below 1 > segment/RTT in > heavily congested scenarios. Exponential backoff of timer > is a must. > > I believe that either of us know what's really out there > employing > Internet for communication purposes. It does not matter > whether it is a > notable percentage or not as long there is a group of users > who are > encountering the envisioned problem. > It may very well be a small minority, but if this kind of a > problem > escalates for this group very often (maybe almost always), > it means we > are disabling use of Internet technology for them. > > > Furthermore, in cases like this where the number of flows > is roughly > > equal to or greater than the BDP of the path, > Reno/[RFC5681] and CUBIC > > will spend the majority of their time in loss recovery > (the minimum > > ssthresh from [RFC5681] being 2*SMSS). > > Sure there is surprisingly lot to improve with TCP when the > window needs > to be kept lower than 2 MSS or when the available share > would be even > less than 1 MSS/RTT. RFC 5681 would exponentially back-off > on every RTO, > leaving opportunity for other flows to make progress during > the > backed-off interval. Once the sender is lucky and gets an > Ack for a new > segment, min ssthresh of 2*MSS unfortunately allows it to > accelerate to > 2*MSS/RTT and maybe more until RTO expires again. We cannot > avoid some > drops or unnecessary rexmits. Actually, in such a heavily > congested > scenario the combination of Karn's exponential back-off and > slow start > results in Multiplicative Increase Multiplicative Decrease > (MIMD) > behaviorwhich does not converge that well to fairness. But > it avoids > congestion collapse. It is kind a tradeoff between safe and > stable > behavior during heavy congestion and being able to ramp up > fast when the > congestion fades away. Even though the current behavior is > not ideal > for fairness, we should not make it even worse. > > Currently only way to avoid spending most of the time in > loss > recovery seems to be ECN that would make a TCP sender to > become rate > controlled once cwnd hits the minimum cwnd of 1 MSS(*). But > there is a > lot to optimise also with ECN in this kind of scenario ... > > (*) to avoid anyone repeating the misconception that > minimum cwnd is > =A0 =A0 =A02 MSS per equation (4) in RFC 5681: equation (4) sets > ssthresh, > =A0 =A0 =A0not cwnd. RFC 3168 clearly states that cwnd must be > halved on > =A0 =A0 =A0an arrival of ECE; this holds until cwnd =3D 1 MSS. > After this, > =A0 =A0 =A0the sending rate of new segments is (RTO) timer > controlled and > =A0 =A0 =A0the timer avlue exponentially backed-off if more ECEs > arrive. > =A0 =A0 =A0At least two major OSs implement this incorrectly > unless now > =A0 =A0 =A0already fixed. > > > And the RACK-TLP ID specifies > > that TLP probes are not sent while in loss recovery. > > Maybe I missed it but I couldn't find an end condition of > RTO recovery > for RACK-TLP purposes in the document. Regular RTO does not > have such end > condition because it is not needed. Congestion control and > loss recovery > are quite decoupled during=A0 RTO recovery; slow start > follows its own > rules and ends when cwnd > ssthresh and loss recovery has > its own > rules to select segments to rexmit and just moves on > sending new data > once all lost segments have been retransmitted. Some > implementations may > have such variable/condition but it didn't help me. > > Without timestamps, if TLP is not backed-off, a TLP is > likely to be sent > for each new segment (assuming certain conditions). Each > not backed-off > rexmit is potentially stealing an opportunity from another > flow to get > its segment being delivered, thereby contributing to unfair > use of > bottleneck resources. > > >>> What authors disagree is that RTO must be back-off on > the first > >>> instance if TLP is not acked. While your suggestion > helps the > >>> congestion case, it may also hurt the recovery in other > cases when the > >>> TLP is dropped due to light/burst/transient congestion. > Arguing which > >>> scenarios matter more subjectively is not productive. > >> > >> When RACK-TLP is required to be implemented by all TCP > stacks, it > >> is extremely important that it always works in a safe > way and congestion > >> is always the primary concern to get properly handled. > Without arguing > >> more, I just want to point out that TCP must work > reasonably for all > >> Internet users. That means it must not generate a > situation where even a > >> small minority of the Internet users often or almost > always encounter > >> severe problems with their connectivity. > >> > >> For example, also users in developing countries where > possibly an entire > >> village shares just one mobile (cellular, maybe 3G > possibly only GPRS) > >> connection for their Internet access and pays per amount > of data should > >> get reasonable TCP behavior. In such a case, I cannot > agree with > >> engineering that results in almost always getting only > half of the > >> already scarce bandwidth whle paying double price fot > the useful data. > >> > >> But thinking about a way forward. Karn's algorithm would > require backing > >> off PTO even if you get Ack of PTO. Relaxing this does > not sound me that > >> bad at all, because there is often a pause before TLP > and a TCP sender > >> gets feedback, so apparently conditions are not that bad > and loss > >> recovery gets triggered (hopefully in slow start). > >> If TLP is not acked, RTO is needed and recovery is > completed in using RTO > >> recovery in slow start. Now, if the RTO recovery is > successful (no > >> losses during RTO recovery), it should be quite likely > that the TCP > >> sender is able to successfully send also one new > segment, because it > >> enters CA when it is sending at the half of the previous > rate. So, once > >> you get Ack for the new segment, the TLP back off can be > removed and it > >> is unlikely that the TLP back off slowed down next loss > detection. > >> On the other hand, if the RTO recovery after an > unsuccessful TLP is not > >> successful (more losses are detected), it is quite > likely that congestion > >> has not been resolved. So, it is important to be > conservative and have a > >> backed-off PTO (or even turn it off) to avoid (further) > unnecessary > >> rexmits. If PTO is not backed of, I'd envision PTO > mainly failing to get > >> an Ack in such a case and thereby it not being that > useful. > >> > >> This certainly would require experimental data in a > heavily congested > >> setting to really figure out the actual impact of > different alternatives. > >> > >>> So the question we need to look at is if RACK-TLP > 2RTT-PTO + regular > >>> RTO-backoff is going to cause major stability issues in > extreme > >>> congestion. My understanding based on my officemate Van > Jacobson's > >>> explanation is, as long as there's eventual exponential > backoff, we'll > >>> avoid the repeated shelling the network. > >> > >> Right. But the problem is that with TLP as specified we > do not have full > >> exponential back off. It lacks Karn's clamped retransmit > backoff (as it > >> is called in Van Jacobson's seminal paper) which > requires keeping > >> backed-off timer of a retransmitted segment for the next > (new) segment and > >> ensures that there is eventual exponential backoff. > >> Backing off just RTO is not enough, because "fixed" PTO > for each new > >> segment breaks this "back-off chain", that is, the > exponential backoff > >> is not continueed until there is evidence that > congestion has been > >> resolved (a cumulative Ack arrives for new data). But as > I said, backing > >> off RTO saves RACK-TLP from a full congestion collapse. > Still, wasting > >> 50% of the available network capacity in certain usage > scenarios does not > >> sound acceptable for me. > > > > [RACK-TLP-team:] > > > > To address concerns related to Karn's algorithm, perhaps > it would be > > sufficient to specify that after a RACK-TLP sender sends > a TLP probe > > that is a retransmitted segment, it temporarily disables > further TLP > > retransmissions until the sender obtains a valid RTT > sample (i.e. from > > a non-retransmitted segment, or a segment with [RFC7323] > TCP > > timestamps)? > > As a basic rule: disabling TLP probes for the period of > loss recovery as > currently specified sounds like a correct approach provided > that the end > condition > > =A0 "until the sender obtains a valid RTT sample" > > is added (this would be without timestamps, see some > considerations with > timestamps later below). > > Then some justification and maybe some exeptions can also > be specified > (all these without timestamps): > > If fast recovery is not entered via detecting loss using > TLP, the > sender does not need to wait for a valid RTT sample. It > should be enough > that RecoveryPoint is reached, i.e., use normal exit > condition for fast > recovery. However, I am not sure whether detecting a loss > of a rexmit > during fast recovery might change this? > > I think it does not matter whether a TLP probe is a > retransmitted segment > or not: > > (a) if there is no ack after TLP probe and RTO expires it > should be clear > that TLP must be disabled until an ack for a new previously > not rexmitted > segment is received, regardless of the probe segment sent > by TLP. > This is Karn's algorithm. > > (b) if TLP triggers an Ack that is used to detect a loss of > an entire > flight of data, this may later during loss recovery result > in an RTO > which definitely requires disabling TLP as per the basic > rule. There > might be some exeptions when the basic rule is not > necessary but it is > hard for me to figure one right now, except > > (c) if TLP rexmit detects and repairs a single loss, then > CC is anyway > invoked and Ack is received. If the arriving Ack is > triggered by the TLP > probe segment, it indicates that the conditions are likely > not that bad > (RTO not needed). So it might be ok, to rearm PTO for the > next time > without any backoff (without disbling it). However, > > (d) if TLP was spurious rexmit, then PTO value obviously > was too low > (effective RTT may have increased suddenly and Acks got > just delayed). > This is possibly detected only one RTT later when the > DupAck of the TLP > rexmit arrives. TLP may have got rearmed by that time again > with too > low value, so it should be rearmed with doubled value to > avoid another > spurious TLP PTO (or disabled). > > Then with timestamps. I think the simple rule for disabling > TLP "until > the sender obtains a valid RTT sample" is not necessarily > giving the > desired outcome in all cases. For example, if a TLP probe > is send and > then a late ack arrives for a segment sent before the TLP > probe and gives > a valid RTT sample with help of timestamps. This would > allow a new TLP > even though the sender has not got an Ack for a new segment > sent after > the TLP probe? > > So, also with timestamps the requirement must be that the > sender obtains > a valid RTT sample for a segment sent after the TLP probe. > And, at least, > if RTO recovery is entered, then the Ack must be for a new > segment. > Cannot figure out now all potential exceptions when a valid > RTT sample > with timestamps would allow re-enabling TLP earlier. Too > complex > algorithm with too many possible scenarios to investigate > right now ;) > > A single, simple rule would be advisable here. Otherwise, > this may end up > being too complex to get it right. >=20 > > >>> As a matter of fact some > >>> major TCP (!=3D Linux) implementation has implemented > linear backoff of > >>> first N RTOs before exp-backoff. > >> > >> But that's quite ok as long as there is eventual > exponential backoff, > >> including Karn's clamped retransmit backoff. Linear > back-off in the > >> beginning just makes resolving (heavy) congestion a bit > slower. > >> > >>>> > >>>>>> > >>>>>> Additional notes: > >>>>>> > >>>>>> Sec 2.2: > >>>>>> > >>>>>> Example 2: > >>>>>> "Lost retransmissions cause a=A0 resort to RTO > recovery, since > >>>>>>=A0 =A0DUPACK-counting does not detect the loss of the > retransmissions. > >>>>>>=A0 =A0Then the slow start after RTO recovery could cause > burst losses > >>>>>>=A0 =A0again that severely degrades performance > [POLICER16]." > >>>>>> > >>>>>> RTO reovery is done in slow start. The last sentence > is confusing as > >>>>>> there is no (new) slow-start after RTO recovery (or > more precisely > >>>>>> slow start continues until cwnd > ssthresh). Do you > mean: if/when slow > >>>>>> start still continues after RTO Recovery has > repaired lost segments, > >>>>>> it may cause burst losses again? > >>>>> I mean the slow start after (the start of) RTO > recovery. HTH > >>>> > >>>> Tnx. I'd appreciate if the text could be clarified to > reflect this more > >>>> accurately. Maybe something along the lines(?): > >>>> > >>>>=A0 =A0"Then the RTO recovery in slow start could cause > burst > >>>>=A0 =A0losses again that severely degrades performance > [POLICER16]." > >>>> > >>>>>> > >>>>>> Example 3: > >>>>>>=A0 =A0"If the reordering degree is beyond DupThresh, the > DUPACK- > >>>>>>=A0 =A0 counting can cause a spurious fast recovery and > unnecessary > >>>>>>=A0 =A0 congestion window reduction.=A0 To mitigate the > issue, [RFC4653] > >>>>>>=A0 =A0 adjusts DupThresh to half of the inflight size to > tolerate the > >>>>>>=A0 =A0 higher degree of reordering.=A0 However if more > than half of the > >>>>>>=A0 =A0 inflight is lost, then the sender has to resort > to RTO recovery." > >>>>>> > >>>>>> This seems to be somewhat incorrect description of > TCP-NCR specified in > >>>>>> RFC 4653. TCP-NCR uses Extended Limited Transmit > that keeps on sending > >>>>>> new data segments on DupAcks that makes it likely to > avoid an RTO in > >>>>>> the given example scenario, if not too many of the > the new data > >>>>>> segments triggered by Extended Limited Transmit are > lost. > >>>>> sorry I don't see how the text is wrong describing > RFC4653, > >>>>> specifically the algorithm in adjusting ssthresh > >>>> > >>>> To my understanding RFC4653 initializes DupThresh to > half of the inflight > >>>> size in the beginning of the Extended Limited > Transmit. Then on each > >>>> DupAck it adjusts (recalculates) DupThresh again such > that ideally a cwnd > >>>> worth of DupAcks are received before packet loss is > declared (or > >>>> reordering detected). So, if I am not incorrect, loss > of a half of the > >>>> inflight does not necessarily result in RTO recovery > with TCP-NCR. > >>> Could you suggest the text you'd like on NCR > description. > >> > >> I'm not an expert nor closely acquainted with NCR. There > might be many > >> different packet loss patterns that may affect the > behavior. So, my > >> advice is to simply drop the last sentence starting with > "However ...", > >> because it seems incorrect and replace the second but > last sentence: > >> > >>=A0 =A0 To mitigate the issue, [RFC4653] > >>=A0 =A0 adjusts DupThresh to half of the inflight size to > tolerate the > >>=A0 =A0 higher degree of reordering. > >> > >> --> > >> > >>=A0 =A0 To mitigate the issue, TCP-NCR [RFC4653] > >>=A0 =A0 increases the DupThresh from the current fixed value > of three duplicate > >>=A0 =A0 ACKs [RFC5681] to approximately a congestion window > of data having left > >>=A0 =A0 the network. > > > > [RACK-TLP-team:] > > > > Sure, we will revise accordingly. > > Tnx. > > > > >>>>>> > >>>>>> Sec. 3.5: > >>>>>> > >>>>>>=A0 =A0"For example, consider a simple case where one > >>>>>>=A0 =A0segment was sent with an RTO of 1 second, and then > the application > >>>>>>=A0 =A0writes more data, causing a second and third > segment to be sent right > >>>>>>=A0 =A0before the RTO of the first segment expires.=A0 > Suppose only the first > >>>>>>=A0 =A0segment is lost.=A0 Without RACK, upon RTO > expiration the sender marks > >>>>>>=A0 =A0all three segments as lost and retransmits the > first segment.=A0 When > >>>>>>=A0 =A0the sender receives the ACK that selectively > acknowledges the second > >>>>>>=A0 =A0segment, the sender spuriously retransmits the > third segment." > >>>>>> > >>>>>> This seems incorrect. When the sender receives the > ACK that selectively > >>>>>> acknowledges the second segment, it is a DupAck as > per RFC 6675 and does > >>>>>> not increase cwnd and cwnd remains as 1 MSS and pipe > is 1 MSS. So, the > >>>>>> rexmit of the third segment is not allowad until the > cumulative ACK of > >>>>>> the first segment arrives. > >>>>> I don't see where RFC6675 forbids growing cwnd. Even > if it does, I > >>>>> don't think it's a good thing (in RTO-slow-start) as > DUPACK clearly > >>>>> indicates a delivery has been made. > >>>> > >>>> SACKed sequences with DUpAcks indicate that those > sequences were > >>>> delivered but it does not tell when they were sent. > The basic principle > >>>> of slow start is to reliably determine the available > network capacity > >>>> during slow start. Therefore, slow start must ensure > it uses only > >>>> segments sent during the slow start to increase cwnd. > Otherwise, a TCP > >>>> sender may encounter exactly the problem of > unnecessary retransmission > >>>> envisioned in this example of RACK-TCP draft (and > increase cwnd on not > >>>> valid Acks). > >>>> > >>>> RFC 6675 does re-specify DupAck with SACK option but > it does not include > >>>> the rule for slow start. Slow start is specified in > RFC 5681. It is > >>>> crystal clear in allowing increase in cwnd only on > cumulative > >>>> Acks, i.e., forbidding to increase cwnd on DupAcks > (RFC 5681, Sec 3, > >>>> page 6: > >>>> > >>>>=A0 =A0 During slow start, a TCP increments cwnd by at most > SMSS bytes for > >>>>=A0 =A0 each ACK received that cumulatively acknowledges > new data. > >>>> > >>>> Maybe this example in the RACK-TLP draft was inspired > by a incorrect > >>>> implementation of SACK-based loss recovery? > >>>> > >>>> FYI: when we were finalizing RFC 6675 I suggested > including also an > >>>> algorithm for RTO recovery with SACK in RFC 6675. The > reason was exactly > >>>> that it might be not easy to gather info from multiple > documents and > >>>> hence help the implementor to have all necessary > advice in a single > >>>> document. This unfortunately did not get realized > though. > >>> > >>> I am honestly lost quibbling these RFC6675 > implementations and feeling > >>> pedantic to these standards largely serve as guiding > principles > >>> instead of line-by-line code. Is cwnd one packet bigger > or smaller in > >>> this example making any different in advancing the > Internet's > >>> capability to do better loss detection. I do not think > so. > >> > >> Sorry, I don't understand what was quibbling here. I > believe I did not > >> argue anything about cwnd size with this example at hand > in Sec. 3.5. > >> My point is that it describes incorrect slow start > behavior. Correctly > >> implemented slow start does not have the problem > illustriated in the > >> example. > >> > >>> At this point please suggest a text you like to change. > >> > >> That is simple. Please remove the description of the > behavior without > >> RACK. Or correct it: the behavior would be exactly the > same as with RACK, > >> but the reason for not unnecessarily retransmitting > third segment can be > >> described to be different. > >> And, please correct also the description with RACK. With > RACK, third > >> segment does not get unnecessarly rexmitted for the > reason already > >> indicated and also because cwnd=3D1 MSS. And, no new > segments are allowed > >> either by cwnd=3D1. > >> > > > > [RACK-TLP-team:] > > > > Thanks. Perhaps it makes sense to consider a slightly > different RTO > > scenario to illustrate the point about how RACK RTO > behavior can avoid > > spurious retransmissions. > > > > Here is the proposed new text: > > > > "3.5.=A0 An Example of RACK-TLP in Action: RTO > > > >=A0 =A0In addition to enhancing fast recovery, RACK improves > the accuracy of > >=A0 =A0RTO recovery by reducing spurious retransmissions. > > > >=A0 =A0Without RACK, upon RTO timer expiration the sender > marks all the > >=A0 =A0unacknowledged segments lost.=A0 This approach can lead > to spurious > >=A0 =A0retransmissions.=A0 For example, consider a simple case > where one > >=A0 =A0segment was sent with an RTO of 1 second, and then the > application > >=A0 =A0writes more data, causing a second and third segment to > be sent right > >=A0 =A0before the RTO of the first segment expires.=A0 Suppose > none of the > >=A0 =A0segments were lost.=A0 Without RACK, if there is a > spurious RTO then > >=A0 =A0the sender marks all three segments as lost and > retransmits the > >=A0 =A0first segment. If the ACK for the original copy of the > first segment > >=A0 =A0arrives right after the spurious RTO retransmission, > then the > >=A0 =A0sender continues slow start and spuriously retransmits > the second > >=A0 =A0and third segments, since it (erroneously) presumed > they are lost. > > That seems fine. Would it be useful to add an additional > note saying that > if F-RTO is in use, then further unnecessary > retransmissions can be > avoided? > > >=A0 =A0With RACK, upon RTO timer expiration the only segment > automatically > >=A0 =A0marked lost is the first segment (since it was sent an > RTO ago); for > >=A0 =A0all the other segments RACK only marks the segment lost > if at least > >=A0 =A0one round trip has elapsed since the segment was > transmitted. > >=A0 =A0Consider the previous example scenario, this time with > RACK.=A0 With > >=A0 =A0RACK, when the RTO expires the sender only marks the > first segment as > >=A0 =A0lost, and retransmits that segment.=A0 The other two very > recently sent > >=A0 =A0segments are not marked lost, because they were sent > less than one > >=A0 =A0round trip ago and there were no ACKs providing > evidence that they > >=A0 =A0were lost. Upon receiving the ACK for the RTO > retransmission the > >=A0 =A0RACK sender would not yet retransmit the second or > third segment. but > >=A0 =A0rather would rearm the RTO timer and wait for a new RTO > interval to elapse > >=A0 =A0before marking the second or third segments as lost. > > " > > This behavior with RACK-TLP does not quite match with my > reading of > the draft in all parts, so I have some questions. > > First, wouldn't the PTO timer be first running for the > first segment > and when the sender sends the 2nd and 3rd segment it would > rearm PTO for > the 3rd segment? My understanding based on Sec 8 is that > RTO cannot be > armed until PTO fires? And when the PTO fires, the sender > would > retransmit the 3rd segment? Maybe I am missing something? > > Anyways, an RTO timer may expire in this scenario (e.g., if > there is no > Ack for TLP). > Let's assume the RTO timer expires as described. When the > first Ack after > the rexmit of the 1st segment arrives, isn't that the late > ACK for the > original copy of the first segment, not the ACK for the RTO > retransmission? Anyways, when this first Ack arrives after > the RTO, the > second and third segment are not marked as lost as > described, which > nicely prevents unnecessary retransmissions of those > segments. > However, if the 2nd and 3rd segments were lost, wouldn't > rearming RTO > with exponentially backed-off timer value (2*RTO) make the > recovery of > the 2nd and 3rd segment very slow? After 2*RTO the timer > expires and > the 2nd segment is rexmitted and only after one additional > RTT when the > ack for the 2nd segment arrives, the sender rexmits the 3rd > segment? > Wouldn't it be much more efficient to disable RACK loss > detection during > an RTO recovery and employ F-RTO? Maybe I am missing > something again? >=20 > > Then to the problem with the pseudocode I mentioned in the > beginning of > this message. If I am not incorrect it seems to me that > setting a value > to TLP.end_seq in TLP_send_probe() is off by one byte? > Maybe something > similar is wrong somewhere else too, didn't check. Please > apologise me if > I missed something. > > Let's use an example with RACK-TLP recovery: > > Send P1, ..., P9, P10 > [P1,.., P9 delayed, P10 dropped] > /* I believe P1-9 delayed is not important here */ > > After 2*SRTT PTO expires > P10 rexmitted by TLP > =A0 [ TLP_send_probe(): set TLP.end_seq =3D SND.NXT (=3D SEG.P11) > ] > > =A0 [after TLP, the=A0 application possibly provides more data > to send] > > Ack for original P1 arrives > (P11 sent, if more data by application) > Ack for original P2 arrives > (P12 sent, if more data by application) > ... > Ack for original P9 arrives > (P19 sent, if more data by application) > > Ack for P10 triggered by TLP rexmit of P10 arrives > =A0 [TLP_process_ack(ACK): > =A0 =A0... > =A0 =A0If ACK's ack. number > TLP.end_seq > =A0 =A0 returns False > =A0 =A0 since ACK's ack. number =3D SEQ.ACK =3D TLP.end_seq =3D > SEG.P11] > > =A0 =A0Loss of P10 is undetected and no reaction to congestion] >=20 > > My understanding of draft text is that a loss of P10 is not > concealed. > Please advise. > > Best regards, > > /Markku > > > best regards, > > > > neal > > > >> Please remove also the last paragraph of the Sec. 3.5, > it being also > >> incorrect description of behavior. > >> > >> BR, > >> > >> /Markku > >> > >>>> > >>>> BR, > >>>> > >>>> /Markku > >>>> > >>>>>> > >>>>>> Best regards, > >>>>>> > >>>>>> /Markku > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mon, 16 Nov 2020, The IESG wrote: > >>>>>> > >>>>>>> > >>>>>>> The IESG has received a request from the TCP > Maintenance and Minor Extensions > >>>>>>> WG (tcpm) to consider the following document: - > 'The RACK-TLP loss detection > >>>>>>> algorithm for TCP' > >>>>>>>=A0 as Proposed Standard > >>>>>>> > >>>>>>> The IESG plans to make a decision in the next few > weeks, and solicits final > >>>>>>> comments on this action. Please send substantive > comments to the > >>>>>>> last-call@ietf.org mailing lists by 2020-11-30. > Exceptionally, comments may > >>>>>>> be sent to iesg@ietf.org instead. In either case, > please retain the beginning > >>>>>>> of the Subject line to allow automated sorting. > >>>>>>> > >>>>>>> Abstract > >>>>>>> > >>>>>>> > >>>>>>>=A0 =A0This document presents the RACK-TLP loss > detection algorithm for TCP. > >>>>>>>=A0 =A0RACK-TLP uses per-segment transmit timestamps and > selective > >>>>>>>=A0 =A0acknowledgements (SACK) and has two parts: RACK > ("Recent > >>>>>>>=A0 =A0ACKnowledgment") starts fast recovery quickly > using time-based > >>>>>>>=A0 =A0inferences derived from ACK feedback.=A0 TLP ("Tail > Loss Probe") > >>>>>>>=A0 =A0leverages RACK and sends a probe packet to > trigger ACK feedback to > >>>>>>>=A0 =A0avoid retransmission timeout (RTO) events.=A0 > Compared to the widely > >>>>>>>=A0 =A0used DUPACK threshold approach, RACK-TLP detects > losses more > >>>>>>>=A0 =A0efficiently when there are application-limited > flights of data, lost > >>>>>>>=A0 =A0retransmissions, or data packet reordering > events.=A0 It is intended to > >>>>>>>=A0 =A0be an alternative to the DUPACK threshold > approach. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> The file can be obtained via > >>>>>>> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> No IPR declarations have been submitted directly on > this I-D. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> tcpm mailing list > >>>>>>> tcpm@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/tcpm > >>>>>>> > >>>>> > >>> > > >=20 >=20 > --=_script-12593-1608147572-0001-2-- From nobody Wed Dec 16 12:46:28 2020 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 B880F3A1051; Wed, 16 Dec 2020 12:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mAN6rcaB7IzR; Wed, 16 Dec 2020 12:46:24 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 384823A104E; Wed, 16 Dec 2020 12:46:24 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id 75so11804219ilv.13; Wed, 16 Dec 2020 12:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NQs3jRnuolPVIb9gjFT1OWLHyjaEwg3CH2lug1ehHzo=; b=P7fPpuSpgoDg4reZOPOgByvALZnW/nPkNU1Vk5O/I5OJsfZ3kdcEceX4J1fivOcPZ2 VPqjT+dBexCRD55DXcwB6Xi54qHgVRZaEXSO9xGSWg4wBhZrQwse0S6PTgPp6gzmNMPS /nShXPyYvWsAXTo1MDCWuJSUXLSQ08u1/Yexm44PjvawQrdL9fjB5598UNe2sxAQ0Ia2 7iwYcpF/k6tpB4B1pKugGnSKVwfklDDYuUWM5DLP7ap6gNAfVyxH08e3HZAsJ2aSWmsO ssPJ6ZXE9F+dX2lffnjLbh+k1s2jFC+N8phOVCXNs4ULqXWg7eX2ezdyofxIFn3lNWq4 LtZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NQs3jRnuolPVIb9gjFT1OWLHyjaEwg3CH2lug1ehHzo=; b=JeJg11CheWE0xCD/awreTtBkKykh9+mg220qt8waeIhsFBq5M46Df/XJTQ6DOCSuNv DrlnDzD7ZSks3rkmiaHqd2CIcWfEQhQDba71KNf0ooLkI6Vpjw4GoVu0ESWSAC6QX9MF KRf0mggmaNhmfwnueyMZ1UOJohOsUYshsZuSP4AAu2rAlpZJd+xuYgoPFXChTOoTii2y mj9nqltCZC7Q6cPQrgHbvmzagqkoZeD+bAq1L+R7J5w0+lm8SrBOr9f4vy1Hn9zlsUxU goBl27T0sgk97sTTmVykyLo+u1TD5tCum1p+rhsWb64vCAGphpfAUA0KMp8PjHcCfUmj hDMg== X-Gm-Message-State: AOAM5336XsoFhGdqEzptFS9jHDu8Ce9z0Fb+bRD7xB/rBynu5TV2iUyK tryCDzn/oa4tt8ZxzAWuAHv4+U8Rml9ffMPYVlA= X-Google-Smtp-Source: ABdhPJxJfCYJMPI7xK8SvBgsjDhn9+1nwouSZ3OjwtN/+zFjdjC6wUivcIomsqpVgNxkjVExmLmt+hNgUQ1zLjWuGbc= X-Received: by 2002:a92:ba08:: with SMTP id o8mr47140036ili.249.1608151583416; Wed, 16 Dec 2020 12:46:23 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Wed, 16 Dec 2020 12:46:12 -0800 Message-ID: To: Markku Kojo Cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000dfe5bb05b69af79a" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 20:46:27 -0000 --000000000000dfe5bb05b69af79a Content-Type: text/plain; charset="UTF-8" Hi Markku, There is a ton here, but I'll try to address the top points. Hopefully they obviate the rest. 1. [Markku] "Hmm, not sure what you mean by "this is a new loss detection after acknowledgment of new data"? But anyway, RFC 5681 gives the general principle to reduce cwnd and ssthresh twice if a retransmission is lost but IMHO (and I believe many who have designed new loss recovery and CC algorithms or implemented them agree) that it is hard to get things right if only congestion control principles are available and no algorithm." [Martin] So 6675 Sec 5 is quite explicit that there is only one cwnd reduction per fast recovery episode, which ends once new data has been acknowledged. By definition, if a retransmission is lost it is because newer data has been acknowledged, so it's a new recovery episode. Meanwhile, during the Fast Recovery period the incoming acks implicitly remove data from the network and therefore keep flightsize low. We can continue to go around on our interpretation of these documents, but fundamentally if there is ambiguity in 5681/6675 we should bis those RFCs rather than expand the scope of RACK. 2. [Markku] " In short: When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=1 MSS, and slow start is entered. When with a RACK_TLP implementation timer (PTO) expires, normal fast recovery is entered (unless implementing also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1." [Martin] There may be a misunderstanding here. PTO is not the same as RTO, and both mechanisms exist! The loss response to a PTO is to send a probe; the RTO response is as with conventional TCP. In Section 7.3: " After attempting to send a loss probe, regardless of whether a loss probe was sent, the sender MUST re-arm the RTO timer, not the PTO timer, if FlightSize is not zero. This ensures RTO recovery remains the last resort if TLP fails. " So a pure RTO response exists in the case of persistent congestion that causes losses of probes or their ACKs. Martin On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo wrote: > Hi Martin, > > On Tue, 15 Dec 2020, Martin Duke wrote: > > > Hi Markku, > > > > Thanks for the comments. The authors will incorporate many of your > > suggestions after the IESG review. > > > > There's one thing I don't understand in your comments: > > > > " That is, > > where can an implementer find advice for correct congestion control > > actions with RACK-TLP, when: > > > > (1) a loss of rexmitted segment is detected > > (2) an entire flight of data gets dropped (and detected), > > that is, when there is no feedback available and a timeout > > is needed to detect the loss " > > > > Section 9.3 is the discussion about CC, and is clear that the > > implementer should use either 5681 or 6937. > > Just a cite nit: RFC 5681 provides basic CC concepts and some useful CC > guidelines but given that RACK-TLP MUST implement SACK the algorithm in > RFC 5681 is not that useful and an implementer quite likely follows > mainly the algorithm in RFC 6675 (and not RFC 6937 at all if not > implementing PRR). > And RFC 6675 is not mentioned in Sec 9.3, though it is listed in the > Sec. 4 (Requirements). > > > You went through the 6937 case in detail. > > Yes, but without correct CC actions. > > > If 5681, it's pretty clear to me that in (1) this is a new loss > > detection after acknowledgment of new data, and therefore requires a > > second halving of cwnd. > > Hmm, not sure what you mean by "this is a new loss detection after > acknowledgment of new data"? > But anyway, RFC 5681 gives the general principle to reduce cwnd and > ssthresh twice if a retransmission is lost but IMHO (and I believe many > who have designed new loss recovery and CC algorithms or implemented them > agree) that it is hard to get things right if only congestion control > principles are available and no algorithm. > That's why ALL mechanisms that we have include a quite detailed algorithm > with all necessary variables and actions for loss recovery and/or CC > purposes (and often also pseudocode). Like this document does for loss > detection. > > So the problem is that we do not have a detailed enough algorithm or > rule that tells exactly what to do when a loss of rexmit is detected. > Even worse, the algorithms in RFC 5681 and RFC 6675 refer to > equation (4) of RFC 5681 to reduce ssthresh and cwnd when a loss > requiring a congestion control action is detected: > > (cwnd =) ssthresh = FlightSize / 2) > > And RFC 5681 gives a warning not to halve cwnd in the equation but > FlightSize. > > That is, this equation is what an implementer intuitively would use > when reading the relevant RFCs but it gives a wrong result for > outstanding data when in fast recovery (when the sender is in > congestion avoidance and the equation (4) is used to halve cwnd, it > gives a correct result). > More precisely, during fast recovery FlightSize is inflated when new > data is sent and reduced when segments are cumulatively Acked. > What the outcome is depends on the loss pattern. In the worst case, > FlightSize is signficantly larger than in the beginning of the fast > recovery when FlightSize was (correctly) used to determine the halved > value for cwnd and ssthresh, i.e., equation (4) may result in > *increasing* cwnd upon detecting a loss of a rexmitted segment, instead > of further halving it. > > A clever implementer might have no problem to have it right with some > thinking but I am afraid that there will be incorrect implementations > with what is currently specified. Not all implementers have spent > signicicant fraction of their career in solving TCP peculiarities. > > > For (2), the RTO timer is still operative so > > the RTO recovery rules would still follow. > > In short: > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=1 MSS, > and slow start is entered. > When with a RACK_TLP implementation timer (PTO) expires, > normal fast recovery is entered (unless implementing > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1. > > This means that this document explicitly modifies standard TCP congestion > control when there are no acks coming and the retransmission timer > expires > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > 1. RTO timer expires > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment > 3. Ack of rexmit sent in step 2 arrives > 4. cwnd = cwnd+1 MSS; send two segments > ... > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the timer) > 1. PTO times expires > 2. (cwnd=1 MSS); (re)xmit one segment > 3. Ack of (re)xmit sent in srep 2 arrives > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments > > For example, if FlightSize is 100 segments when timer expires, > congestion control is the same in steps 1-3, but in step 4 the > current standard congestion control allows transmitting 2 segments, > while RACK-TLP would allow blasting 50 segments. > > Question is: what is the justification to modify standard TCP > congestion control to use fast recovery instead of slow start for a > case where timeout is needed to detect loss because there is no > feedback and ack clock is lost? The draft does not give any > justification. This clearly is in conflict with items (0) and (1) > in BCP 133 (RFC 5033). > > Furthermore, there is no implementation nor experimental experience > evaluating this change. The implementation with experimental experience > uses PRR (RFC 6937) which is an Experimental specification including a > novel "trick" that directs PRR fast recovery to effectively use slow > start in this case at hand. > > > > In other words, I am not seeing a case that requires new congestion > > control concepts except as discussed in 9.3. > > See above. The change in standard congestion control for (2). > The draft intends not to change congestion control but effectively it > does without any operational evidence. > > What's also is missing and would be very useful: > > - For (1), a hint for an implementer saying that because RACK-TLP is > able to detect a loss of a rexmit unlike any other loss detection > algorithm, the sender MUST react twice to congestion (and cite > RFC 5681). And cite a document where necessary correct actions > are described. > > - For (1), advise that an implementer needs to keep track when it > detects a loss of a retransmitted segment. Current algorithms > in the draft detect a loss of retransmitted segment exactly in > the same way as loss of any other segment. There seems to be > nothing to track when a retransmission of a retransmitted segment > takes place. Therefore, the algorithms should have additional > actions to correctly track when such a loss is detected. > > - For (1), discussion on how many times a loss of a retransmission > of the same segment may occur and be detected. Seems that it > may be possible to drop a rexmitted segment more than once and > detect it also several times? What are the implications? > > - If previous is possible, then the algorithm possibly also > may detect a loss of a new segment that was sent during fast > recovery? This is also loss in two successive windows of data, > and cwnd MUST be lowered twice. This discussion and necessary > actions to track it are missing, if such scenario is possible. > > > What am I missing? > > Hope the above helps. > > /Markku > > > --000000000000dfe5bb05b69af79a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Markku,

There is a ton here, but I'll try to address the top points. Hop= efully they obviate the rest.

1.
[Markku= ]
"Hmm, not sure what you mean by "this is a new loss detection aft= er
acknowledgment of new data"?
But anyway, RFC 5681 gives the general principle to reduce cwnd and
ssthresh twice if a retransmission is lost but IMHO (and I believe many who have designed new loss recovery and CC algorithms or implemented them <= br> agree) that it is hard to get things right if only congestion control
principles are available and no algorithm."

[= Martin]
So 6675 Sec 5 is quite explicit that there is only on= e cwnd reduction per fast recovery episode, which ends once new data has be= en acknowledged. By definition, if a retransmission is lost it is because n= ewer data has been acknowledged, so it's a new recovery episode. Meanwh= ile, during the Fast Recovery period the incoming acks implicitly remove da= ta from the network and therefore keep flightsize low.

=
We can continue to go around on our interpretation of these documents,= but fundamentally if there is ambiguity in 5681/6675 we should bis those R= FCs rather than expand the scope of RACK.

2.
=
[Markku]
" In short:
When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1 MSS, =
and slow start is entered.
When with a RACK_TLP implementation timer (PTO) expires,
normal fast recovery is entered (unless implementing
also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1."

[Martin]
There may be a misunderstandin= g here. PTO is not the same as RTO, and both mechanisms exist! The loss res= ponse to a PTO is to send a probe; the RTO response is as with conventional= TCP. In Section 7.3:

" 
After attempting to send a loss probe, regardless of whether =
a loss
   probe was sent, the sender MUST re-arm the RTO timer, not the PTO
   timer, if FlightSize is not zero.  This ensures RTO recovery remains
   the last resort if TLP fails.
"

So a pure RTO response exists in the case of persistent congestion t= hat causes losses of probes or their ACKs.

Martin<= br>


On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo = <kojo@cs.helsinki.fi> wrot= e:
Hi Martin,
On Tue, 15 Dec 2020, Martin Duke wrote:

> Hi Markku,
>
> Thanks for the comments. The authors will incorporate many of your
> suggestions after the IESG review.
>
> There's one thing I don't understand in your comments:
>
> " That is,
> where can an implementer find advice for correct congestion control > actions with RACK-TLP, when:
>
> (1) a loss of rexmitted segment is detected
> (2) an entire flight of data gets dropped (and detected),
> =C2=A0 =C2=A0 =C2=A0that is, when there is no feedback available and a= timeout
> =C2=A0 =C2=A0 =C2=A0is needed to detect the loss "
>
> Section 9.3 is the discussion about CC, and is clear that the
> implementer should use either 5681 or 6937.

Just a cite nit: RFC 5681 provides basic CC concepts and some useful CC guidelines but given that RACK-TLP MUST implement SACK the algorithm in RFC 5681 is not that useful and an implementer quite likely follows
mainly the algorithm in RFC 6675 (and not RFC 6937 at all if not
implementing PRR).
And RFC 6675 is not mentioned in Sec 9.3, though it is listed in the
Sec. 4 (Requirements).

> You went through the 6937 case in detail.

Yes, but without correct CC actions.

> If 5681, it's pretty clear to me that in (1) this is a new loss > detection after acknowledgment of new data, and therefore requires a > second halving of cwnd.

Hmm, not sure what you mean by "this is a new loss detection after acknowledgment of new data"?
But anyway, RFC 5681 gives the general principle to reduce cwnd and
ssthresh twice if a retransmission is lost but IMHO (and I believe many who have designed new loss recovery and CC algorithms or implemented them <= br> agree) that it is hard to get things right if only congestion control
principles are available and no algorithm.
That's why ALL mechanisms that we have include a quite detailed algorit= hm
with all necessary variables and actions for loss recovery and/or CC
purposes (and often also pseudocode). Like this document does for loss
detection.

So the problem is that we do not have a detailed enough algorithm or
rule that tells exactly what to do when a loss of rexmit is detected.
Even worse, the algorithms in RFC 5681 and RFC 6675 refer to
equation (4) of RFC 5681 to reduce ssthresh and cwnd when a loss
requiring a congestion control action is detected:

=C2=A0 (cwnd =3D) ssthresh =3D FlightSize / 2)

And RFC 5681 gives a warning not to halve cwnd in the equation but
FlightSize.

That is, this equation is what an implementer intuitively would use
when reading the relevant RFCs but it gives a wrong result for
outstanding data when in fast recovery (when the sender is in
congestion avoidance and the equation (4) is used to halve cwnd, it
gives a correct result).
More precisely, during fast recovery FlightSize is inflated when new
data is sent and reduced when segments are cumulatively Acked.
What the outcome is depends on the loss pattern. In the worst case,
FlightSize is signficantly larger than in the beginning of the fast
recovery when FlightSize was (correctly) used to determine the halved
value for cwnd and ssthresh, i.e., equation (4) may result in
*increasing* cwnd upon detecting a loss of a rexmitted segment, instead of further halving it.

A clever implementer might have no problem to have it right with some
thinking but I am afraid that there will be incorrect implementations
with what is currently specified. Not all implementers have spent
signicicant fraction of their career in solving TCP peculiarities.

> For (2), the RTO timer is still operative so
> the RTO recovery rules would still follow.

In short:
When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1 MSS, =
and slow start is entered.
When with a RACK_TLP implementation timer (PTO) expires,
normal fast recovery is entered (unless implementing
also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1.

This means that this document explicitly modifies standard TCP congestion <= br> control when there are no acks coming and the retransmission timer
expires

from: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit= one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
=C2=A0 =C2=A0 =C2=A0 =C2=A0...

to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the timer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3D= cwnd segments

For example, if FlightSize is 100 segments when timer expires,
congestion control is the same in steps 1-3, but in step 4 the
current standard congestion control allows transmitting 2 segments,
while RACK-TLP would allow blasting 50 segments.

Question is: what is the justification to modify standard TCP
congestion control to use fast recovery instead of slow start for a
case where timeout is needed to detect loss because there is no
feedback and ack clock is lost? The draft does not give any
justification. This clearly is in conflict with items (0) and (1)
in BCP 133 (RFC 5033).

Furthermore, there is no implementation nor experimental experience
evaluating this change. The implementation with experimental experience uses PRR (RFC 6937) which is an Experimental specification including a
novel "trick" that directs PRR fast recovery to effectively use s= low
start in this case at hand.


> In other words, I am not seeing a case that requires new congestion > control concepts except as discussed in 9.3.

See above. The change in standard congestion control for (2).
The draft intends not to change congestion control but effectively it
does without any operational evidence.

What's also is missing and would be very useful:

- For (1), a hint for an implementer saying that because RACK-TLP is
=C2=A0 =C2=A0able to detect a loss of a rexmit unlike any other loss detect= ion
=C2=A0 =C2=A0algorithm, the sender MUST react twice to congestion (and cite=
=C2=A0 =C2=A0RFC 5681). And cite a document where necessary correct actions=
=C2=A0 =C2=A0are described.

- For (1), advise that an implementer needs to keep track when it
=C2=A0 =C2=A0detects a loss of a retransmitted segment. Current algorithms<= br> =C2=A0 =C2=A0in the draft detect a loss of retransmitted segment exactly in=
=C2=A0 =C2=A0the same way as loss of any other segment. There seems to be =C2=A0 =C2=A0nothing to track when a retransmission of a retransmitted segm= ent
=C2=A0 =C2=A0takes place. Therefore, the algorithms should have additional<= br> =C2=A0 =C2=A0actions to correctly track when such a loss is detected.

- For (1), discussion on how many times a loss of a retransmission
=C2=A0 =C2=A0of the same segment may occur and be detected. Seems that it =C2=A0 =C2=A0may be possible to drop a rexmitted segment more than once and=
=C2=A0 =C2=A0detect it also several times?=C2=A0 What are the implications?=

- If previous is possible, then the algorithm possibly also
=C2=A0 =C2=A0may detect a loss of a new segment that was sent during fast =C2=A0 =C2=A0recovery? This is also loss in two successive windows of data,=
=C2=A0 =C2=A0and cwnd MUST be lowered twice. This discussion and necessary<= br> =C2=A0 =C2=A0actions to track it are missing, if such scenario is possible.=

> What am I missing?

Hope the above helps.

/Markku


<snipping the rest>
--000000000000dfe5bb05b69af79a-- From nobody Wed Dec 16 16:11:23 2020 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 EE5CD3A12FF; Wed, 16 Dec 2020 16:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 g43FE-vE4WSt; Wed, 16 Dec 2020 16:11:13 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C683A12FB; Wed, 16 Dec 2020 16:11:11 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 17 Dec 2020 02:11:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=fiXUbXTcavK55peKy bYMKDRzs3d3XTWQRyURYhb2R5k=; b=VMHEaeK1DFe0IRNP1xsbVkczCyvuTnbAs xDkiGoqVRwNFQ5mhI9+Q+SMjVEvad8Dk0hESWnzz9vbWWhTr/PjukZN2daHx5mGS 9P0cED96VAp9Mylx5OED7d8c6WBFDHrQ7BnhqnKiTEZ0vE/KvhO39FrHTWmYA5x9 W+v4OVD3tc= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 17 Dec 2020 02:11:07 +0200 id 00000000005A281E.000000005FDAA21B.00003DC7 Date: Thu, 17 Dec 2020 02:11:06 +0200 (EET) From: Markku Kojo To: Martin Duke cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-15839-1608163868-0001-2" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmfor TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 00:11:16 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-15839-1608163868-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Martin, See inline. On Wed, 16 Dec 2020, Martin Duke wrote: > Hi Markku, >=20 > There is a ton here, but I'll try to address the top points. Hopefully > they obviate the rest. Sorry for being verbose. I tried to be clear but you actually removed my=20 key issues/questions ;) > 1. > [Markku] > "Hmm, not sure what you mean by "this is a new loss detection after > acknowledgment of new data"? > But anyway, RFC 5681 gives the general principle to reduce cwnd and > ssthresh twice if a retransmission is lost but IMHO (and I believe many > who have designed new loss recovery and CC algorithms or implemented > them > agree) that it is hard to get things right if only congestion control > principles are available and no algorithm." >=20 > [Martin] > So 6675 Sec 5 is quite explicit that there is only one cwnd reduction > per fast recovery episode, which ends once new data has been > acknowledged. To be more precise: fast recovery ends when the current window becomes=20 cumulatively acknowledged, that is, (4.1) RecoveryPoint (=3D HighData at the beginning) becomes acknowledged I believe we agree and you meant this although new data below=20 RecoveryPoint may become cumulatively acknowledged already earlier=20 during the fast recovery. Reno loss recovery in RFC 5681 ends, when=20 (any) new data has been acknowledged. > By definition, if a retransmission is lost it is because > newer data has been acknowledged, so it's a new recovery episode. Not sure where you have this definition? Newer than what are you=20 referring to? But, yes, if a retransmission is lost with RFC 6675 algorithm,=20 it requires RTO to be detected and definitely starts a new recovery=20 episode. That is, a new recovery episode is enforced by step (1.a) of=20 NextSeg () which prevents retransmission if a segment that has already=20 been retransmitted. If RACK-TLP is used for detecting loss with RFC 6675=20 things get different in many ways, because it may detect loss of a=20 retransmission. It would pretty much require an entire redesign=20 of the algorith. For example, calculation of pipe does not consider=20 segments that have been retransmitted more than once. > Meanwhile, during the Fast Recovery period the incoming acks implicitly > remove data from the network and therefore keep flightsize low. Incorrect. FlightSize !=3D pipe. Only cumulative acks remove data from=20 FlightSize and new data transmitted during fast recovery inflate=20 FlightSize. How FlightSize evolves depends on loss pattern as I said.=20 It is also possible that FlightSize is low, it may err in both=20 directions. A simple example can be used as a proof for the case where=20 cwnd increases if a loss of retransmission is detected and repaired: RFC 6675 recovery with RACK-TLP loss detection: (contains some inaccuracies because it has not been defined how lost rexmits are calculated into pipe) cwnd=3D20; packets P1,...,P20 in flight =3D current window of data [P1 dropped and rexmit of P1 will also be dropped] DupAck w/SACK for P2 arrives [loss of P1 detected after one RTT from original xmit of P1] [cwnd=3Dssthresh=3D10] P1 is rexmitted (and it logically starts next window of data) DupAcks w/ SACK for original P3..11 arrive DupAck w/ SACK for original P12 arrives [cwnd-pipe =3D 10-9 >=3D1] send P21 DupAck w/SACK for P13 arrives send P22 ... DupAck w/SACK for P20 arrives send P29 [FlightSize=3D29] (Ack for rexmit of P1 would arrive here unless it got dropped) DupAck w/SACK for P21 arrives [loss of rexmit P1 detected after one RTT from rexmit of P1] SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5 CWND INCREASES when it should be at most 5 after halving it twice!!! > We can continue to go around on our interpretation of these documents, > but fundamentally if there is ambiguity in 5681/6675 we should bis > those RFCs rather than expand the scope of RACK. As I said earlier, I am not opposing bis, though 5681bis wuold not=20 be needed, I think. But let me repeat: if we publish RACK-TLP now without necessary warnings=20 or with a correct congesion control algorithm someone will try to=20 implement RACK-TLP with RFC 6675 and it will be a total mesh. The=20 behavior will be unpredictable and quite likely unsafe congestion=20 control behavior. > 2. > [Markku] > " In short: > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1 > MSS, > and slow start is entered. > When with a RACK_TLP implementation timer (PTO) expires, > normal fast recovery is entered (unless implementing > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1." >=20 > [Martin] > There may be a misunderstanding here. PTO is not the same as RTO, and > both mechanisms exist! The loss response to a PTO is to send a probe; > the RTO response is as with conventional TCP. In Section 7.3: No, I don't think I misunderstood. If you call timeout with=20 another name, it is still timeout. And congestion control does not=20 consider which segments to send (SND.UNA vs. probe w/ higher sequence=20 number), only how much is sent. You ignored my major point where I decoupled congestion control from loss=20 detection and loss recovery and compared RFC 5681 behavior to RACK-TLP=20 behavior in exactly the same scenario where an entire flight is lost and=20 timer expires. Please comment why congestion control behavior is allowed to be radically=20 different in these two implementations? RFC 5681 & RFC 6298 timeout: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer) =C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires =C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexm= it one segment =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments =C2=A0 =C2=A0 =C2=A0 =C2=A0... RACK-TLP timeout: =C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PTO used for arming the timer) =C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires =C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3D= cwnd segments If FlightSize is 100 segments when timer expires, congestion control is=20 the same in steps 1-3, but in step 4 the standard congestion control=20 allows transmitting 2 segments, while RACK-TLP would allow=20 blasting 50 segments. > After attempting to send a loss probe, regardless of whether a loss > probe was sent, the sender MUST re-arm the RTO timer, not the PTO > timer, if FlightSize is not zero. This ensures RTO recovery remains > the last resort if TLP fails. > " This does not prevent the above RACK-TLP behavior from getting realized. > So a pure RTO response exists in the case of persistent congestion that > causes losses of probes or their ACKs. Yes, RTO response exists BUT only after RACK-TLP at least once blasts the=20 network. It may well be that with smaller windows RACK-TLP is successful=20 during its TLP initiated overly aggressive "fast recovery" and never=20 enters RTO recovery because it may detect and repair also loss of=20 rexmits. That is, it continues at too high rate even if lost rexmits=20 indicate that congestion persists in successive windows of data. And=20 worse, it is successful because it pushes away other compatible TCP=20 flows by being too aggressive and unfair. Even a single shot burst every time there is significant loss=20 event is not acceptable, not to mention continuous aggressiveness, and=20 this is exactly what RFC 2914 and RFC 5033 explicitly address and warn=20 about. Are we ignoring these BCPs that have IETF consensus? And the other important question I'd like to have an answer: What is the justification to modify standard TCP congestion control to=20 use fast recovery instead of slow start for a case where timeout is=20 needed to detect the packet losses because there is no feedback and ack=20 clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4.1. As I noted: based on what is written in the draft it does not intend to=20 change congestion control but effectively it does. /Markku > Martin >=20 >=20 > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > wrote: > Hi Martin, > > On Tue, 15 Dec 2020, Martin Duke wrote: > > > Hi Markku, > > > > Thanks for the comments. The authors will incorporate > many of your > > suggestions after the IESG review. > > > > There's one thing I don't understand in your comments: > > > > " That is, > > where can an implementer find advice for correct > congestion control > > actions with RACK-TLP, when: > > > > (1) a loss of rexmitted segment is detected > > (2) an entire flight of data gets dropped (and detected), > > =C2=A0 =C2=A0 =C2=A0that is, when there is no feedback availabl= e and a > timeout > > =C2=A0 =C2=A0 =C2=A0is needed to detect the loss " > > > > Section 9.3 is the discussion about CC, and is clear that > the > > implementer should use either 5681 or 6937. > > Just a cite nit: RFC 5681 provides basic CC concepts and > some useful CC > guidelines but given that RACK-TLP MUST implement SACK the > algorithm in > RFC 5681 is not that useful and an implementer quite likely > follows > mainly the algorithm in RFC 6675 (and not RFC 6937 at all > if not > implementing PRR). > And RFC 6675 is not mentioned in Sec 9.3, though it is > listed in the > Sec. 4 (Requirements). > > > You went through the 6937 case in detail. > > Yes, but without correct CC actions. > > > If 5681, it's pretty clear to me that in (1) this is a > new loss > > detection after acknowledgment of new data, and therefore > requires a > > second halving of cwnd. > > Hmm, not sure what you mean by "this is a new loss > detection after > acknowledgment of new data"? > But anyway, RFC 5681 gives the general principle to reduce > cwnd and > ssthresh twice if a retransmission is lost but IMHO (and I > believe many > who have designed new loss recovery and CC algorithms or > implemented them > agree) that it is hard to get things right if only > congestion control > principles are available and no algorithm. > That's why ALL mechanisms that we have include a quite > detailed algorithm > with all necessary variables and actions for loss recovery > and/or CC > purposes (and often also pseudocode). Like this document > does for loss > detection. > > So the problem is that we do not have a detailed enough > algorithm or > rule that tells exactly what to do when a loss of rexmit is > detected. > Even worse, the algorithms in RFC 5681 and RFC 6675 refer > to > equation (4) of RFC 5681 to reduce ssthresh and cwnd when a > loss > requiring a congestion control action is detected: > > =C2=A0 (cwnd =3D) ssthresh =3D FlightSize / 2) > > And RFC 5681 gives a warning not to halve cwnd in the > equation but > FlightSize. > > That is, this equation is what an implementer intuitively > would use > when reading the relevant RFCs but it gives a wrong result > for > outstanding data when in fast recovery (when the sender is > in > congestion avoidance and the equation (4) is used to halve > cwnd, it > gives a correct result). > More precisely, during fast recovery FlightSize is inflated > when new > data is sent and reduced when segments are cumulatively > Acked. > What the outcome is depends on the loss pattern. In the > worst case, > FlightSize is signficantly larger than in the beginning of > the fast > recovery when FlightSize was (correctly) used to determine > the halved > value for cwnd and ssthresh, i.e., equation (4) may result > in > *increasing* cwnd upon detecting a loss of a rexmitted > segment, instead > of further halving it. > > A clever implementer might have no problem to have it right > with some > thinking but I am afraid that there will be incorrect > implementations > with what is currently specified. Not all implementers have > spent > signicicant fraction of their career in solving TCP > peculiarities. > > > For (2), the RTO timer is still operative so > > the RTO recovery rules would still follow. > > In short: > When with a non-RACK-TLP implementation timer (RTO) > expires: cwnd=3D1 MSS, > and slow start is entered. > When with a RACK_TLP implementation timer (PTO) expires, > normal fast recovery is entered (unless implementing > also PRR). So no RTO recovery as explicitly stated in Sec. > 7.4.1. > > This means that this document explicitly modifies standard > TCP congestion > control when there are no acks coming and the > retransmission timer > expires > > from: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer) > =C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires > =C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize= /2; rexmit one > segment > =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrive= s > =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segme= nts > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the ti= mer) > =C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires > =C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segmen= t > =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arri= ves > =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; = send N=3Dcwnd > segments > > For example, if FlightSize is 100 segments when timer > expires, > congestion control is the same in steps 1-3, but in step 4 > the > current standard congestion control allows transmitting 2 > segments, > while RACK-TLP would allow blasting 50 segments. > > Question is: what is the justification to modify standard > TCP > congestion control to use fast recovery instead of slow > start for a > case where timeout is needed to detect loss because there > is no > feedback and ack clock is lost? The draft does not give any > justification. This clearly is in conflict with items (0) > and (1) > in BCP 133 (RFC 5033). > > Furthermore, there is no implementation nor experimental > experience > evaluating this change. The implementation with > experimental experience > uses PRR (RFC 6937) which is an Experimental specification > including a > novel "trick" that directs PRR fast recovery to effectively > use slow > start in this case at hand. >=20 > > > In other words, I am not seeing a case that requires new > congestion > > control concepts except as discussed in 9.3. > > See above. The change in standard congestion control for > (2). > The draft intends not to change congestion control but > effectively it > does without any operational evidence. > > What's also is missing and would be very useful: > > - For (1), a hint for an implementer saying that because > RACK-TLP is > =C2=A0 =C2=A0able to detect a loss of a rexmit unlike any other l= oss > detection > =C2=A0 =C2=A0algorithm, the sender MUST react twice to congestion > (and cite > =C2=A0 =C2=A0RFC 5681). And cite a document where necessary corre= ct > actions > =C2=A0 =C2=A0are described. > > - For (1), advise that an implementer needs to keep track > when it > =C2=A0 =C2=A0detects a loss of a retransmitted segment. Current > algorithms > =C2=A0 =C2=A0in the draft detect a loss of retransmitted segment > exactly in > =C2=A0 =C2=A0the same way as loss of any other segment. There see= ms > to be > =C2=A0 =C2=A0nothing to track when a retransmission of a > retransmitted segment > =C2=A0 =C2=A0takes place. Therefore, the algorithms should have > additional > =C2=A0 =C2=A0actions to correctly track when such a loss is detec= ted. > > - For (1), discussion on how many times a loss of a > retransmission > =C2=A0 =C2=A0of the same segment may occur and be detected. Seems > that it > =C2=A0 =C2=A0may be possible to drop a rexmitted segment more tha= n > once and > =C2=A0 =C2=A0detect it also several times?=C2=A0 What are the > implications? > > - If previous is possible, then the algorithm possibly also > =C2=A0 =C2=A0may detect a loss of a new segment that was sent dur= ing > fast > =C2=A0 =C2=A0recovery? This is also loss in two successive window= s of > data, > =C2=A0 =C2=A0and cwnd MUST be lowered twice. This discussion and > necessary > =C2=A0 =C2=A0actions to track it are missing, if such scenario is > possible. > > > What am I missing? > > Hope the above helps. > > /Markku >=20 >=20 > >=20 > --=_script-15839-1608163868-0001-2-- From nobody Wed Dec 16 18:34:06 2020 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 F2D203A139B; Wed, 16 Dec 2020 18:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=qfyiPWrN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AUZK+Qav 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 AK8BCvUUaI4l; Wed, 16 Dec 2020 18:33:58 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3431D3A1396; Wed, 16 Dec 2020 18:33:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6B7A05C0150; Wed, 16 Dec 2020 21:33:57 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 16 Dec 2020 21:33:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=d G8N25qHAIiYyy9kjaofD6b/5DbjeuTQVlztkc2pNK0=; b=qfyiPWrNnNG5g+5D0 p83p14dHN5ZX1IpfPW2+2B7u9NV/AnNSztZvK5WPvvFXX9vM3hnqoNz6xDss4JZW cg/FziM0BdM4CiIIxQ6tW3ZoP5c2cEjoa8DBc+GQheIMe6KRqv4WuAdMHruhlcah 9+GH+4kQGM5/G1JWpujqa8WPv3qwNQYSjHohC45oXhP81fEPZS3gpBDzU0jErO8b 4iKOrfC3B7FvqGTtNlyuNRThTxH2q9wzGx5cBC+mcn2vVQBCTGkLknjLGxsBlXOJ pOw1n386PL4FLSORb3vWzBT7h8DxZiZU4y2EiUJn1ZuJhFdgqzLfyLMBaCkq/SGI KTD7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=dG8N25qHAIiYyy9kjaofD6b/5DbjeuTQVlztkc2pN K0=; b=AUZK+Qavcv2JUQ+13wo9KJ9dyFFbabuiZD3YxYACO+4x0Xk1ET+fCmDKR RwgDxW3pp8QDIhGAd2Me5Vc00N2K04/hVKPZ7IiHctvUEhUIfADvdUCn2R92oaeM V074i14IwuISy5AutuJSWtoUt1QowmhOZ1zVZKbSSMxSElCSfptKKLlrnAUPWS9A 9modOPMvYE9XWEt5wkfIdO9HbGBzp0UirvbFFlebyghr4HciargaB3ubZmOedHkf DYIZ+dobzzqW6XDP5oAfQ3aHOIEfqCICz1NQqMuZAX+0njieVNvbwt7InRFy/uS1 BTQ4HmAAxaWEguZEri8pTmbDRodUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelfedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrg htthgvrhhnpeefudfhgfetgfetvddvffeiuddtkeffgedvjeejtdeiheefgfelfeeutdel vdfggfenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedrudduje drledunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-vpn4-1171.cisco.com (unknown [173.38.117.91]) by mail.messagingengine.com (Postfix) with ESMTPA id B6D08240057; Wed, 16 Dec 2020 21:33:56 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: Date: Wed, 16 Dec 2020 21:33:56 -0500 Cc: Last Call , General Area Review Team , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <160729596677.24036.14420451480687784125@ietfa.amsl.com> To: Yuchung Cheng , Peter Yee X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [tcpm] [Gen-art] Genart last call review of draft-ietf-tcpm-rack-14 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 02:34:00 -0000 Peter, thanks for your review. Yuchung, thanks for your response. I = entered a No Objection ballot. Alissa > On Dec 7, 2020, at 4:28 PM, Yuchung Cheng = wrote: >=20 > On Sun, Dec 6, 2020 at 3:06 PM Peter Yee via Datatracker > wrote: >>=20 >> Reviewer: Peter Yee >> Review result: Ready with Nits >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-tcpm-rack-14 >> Reviewer: Peter Yee >> Review Date: 2020-12-06 >> IETF LC End Date: 2020-11-30 >> IESG Telechat date: 2020-12-17 >>=20 >> Summary: This is a well-written draft specifying an efficient scheme = for >> detecting and recovering from TCP segment loss. There are a few minor = nits that >> should be corrected prior to publication, but to the extent that I = understand >> this specification, I don't see any major or minor flaws. [Ready with = nits] > Thanks for the review. We will make all the changes suggested in the > next revision. >=20 >>=20 >> Major issues: None >>=20 >> Minor issues: None >>=20 >> Nits/editorial comments: >>=20 >> General: >>=20 >> For all occurrences of "i.e." and "e.g.", make sure that they are = consistently >> followed by a comma. (Like I said, nits.) >>=20 >> Specific: >>=20 >> Page 7, 1st paragraph, 3rd sentence: change: "DUPTHRESH" to = "DupThresh". This >> appears to be only use of all caps for the term and it does not = appear as such >> in RFC 6675. >>=20 >> Page 9, Figure 1: while I understand what is being shown, I'm not a = fan of >> having the "<--" followed by things like "Receive P0" as this is not = a >> transmission by the TCP data receiver in the figure. The ACKs and = SACKs are >> fine on those lines, but I think the receives should be shown on the = same line >> as the sends. >>=20 >> Page 9, Figure 1, step 7a: why is there no "receive SACK" as show in = step 5a? > good idea. we'll include that to make it more complete. >=20 >>=20 >> Page 9, 1st paragraph under Figure 1: change "(P1, P2, P3, P4)" to = "(P0, P1, >> P2, P3)" to match both the figure and the following text. >>=20 >> Page 14, 1st paragraph after list item #2: change "round trip" to = "round-trip". >>=20 >> Page 16, 2nd paragraph: append a comma after "observed". >>=20 >> Page 17, 1st paragraph, 1st sentence: append a comma after = "temporary". >>=20 >> Page 18, 1st paragraph after "now >=3D" formula, 1 sentence: change = "round trip" >> to "round-trip". >>=20 >> Page 18, 2nd to last paragraph, 1st sentence: change "left hand" to = "left-hand". >>=20 >> Page 20, 2nd to last paragraph, 2nd sentence: change = "implementation-specific" >> to "implementation specific". >>=20 >> Page 21, last paragraph, 1st sentence: the pointer to the earlier = section is >> oddly constructed, using doubled single quotes and capitalization = that doesn't >> even match the referenced section (6.1). It would be better, in my = opinion, >> just to give a pointer to the section number. > sorry will replace w/ section pointer directly >>=20 >> Page 25, item #3, 1st sentence: change "are" to "is" as flight is = singular. >>=20 >> Page 26, 1st partial paragraph, 1st full sentence: change = "data-centers" to >> "data centers". >>=20 >> Page 27, section 9.4, 1st sentence: delete "time" or alternatively = insert "a" >> before "longer". >>=20 >>=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Dec 16 18:55:24 2020 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 5C9873A13A6; Wed, 16 Dec 2020 18:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 NEqsuTtOEQ7o; Wed, 16 Dec 2020 18:55:15 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 48A8F3A13A5; Wed, 16 Dec 2020 18:55:15 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id d9so26092565iob.6; Wed, 16 Dec 2020 18:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3GTBTImZEv8jg7pXyPHtGIkOKSlJslnERqHjl1yX+wc=; b=NqOZzuF4PEvwm6y2JrGZsxlqPmRJ4tzD5n+tw7IWU3A0dfZbX29t+hCbQASqkcUgag YJFL+nyyPj3p5aGxTK0gtJyfpvjsR/4SZSSoghWCIl2B7XaUc7N9n4yZ9bZhQOquk8rv ref5jseDFqPUDxidj11Pid/7fg7hynmzYtvrFxqfLSy0/EZ/9XX/kqktj34vOT0sIn2K 8iGch7wKcBes/eXzr+IZ1d2wTJJO/HqXOImBwmnK+TlPCsb1LLMq3yKKAt895rZBAUe5 4lngTT6b8qisdzLRgBllofuRNY/GoPsEezndAgiMjBrJaNQJihKohsL5h6aEnc+den3J Q37g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3GTBTImZEv8jg7pXyPHtGIkOKSlJslnERqHjl1yX+wc=; b=OzvHI6BNxs+G9k59N9z26YXLX8uw/SCHvq+ah96FRDnM8LD2xXA+LA8P0IzwBudpy7 hVBNq3qbMV0KZrb8XKBfyu4myR8rSLPi8+KT9tGa420D4h7UetpXQ/1aDsH8O7q2I0rx 4d/xEUWkODDWNF2Atl8NBD0kbkUXTJTsMe/jaB7mBbz3mpENHP27Ucxd5NzeOoBnevVP HsL/n+xPJw7Fg0iiVN7yh0GHxgWrWjdlhk0M275ZRmKpFF1mjml7K6aqOa4Zd5UniqZA xeHTw15/SyBSTJ/mTnn9r/Jtxapgom22yIWytFty6oRU2fgbodNZrokZ3ttkryMASfhL x/tw== X-Gm-Message-State: AOAM533C9VVzwmJmE/0cv7uplD3B8atEiw0aXy1DpvlWRN17QAXlc3+S WnCjqkgVaY7kTgHNKmGNH6C4SJRGYPES9jN9ml5RJJHGVWZDZNjr X-Google-Smtp-Source: ABdhPJyaJL7PchMCarygf4VRYWHX/fwN3O1OOBbUbSBxnDia851z1anWy/Q6Dvq8+DVMbo5oAFHCxJ8ptXU9j9ird5s= X-Received: by 2002:a6b:f810:: with SMTP id o16mr3281868ioh.20.1608173714381; Wed, 16 Dec 2020 18:55:14 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Wed, 16 Dec 2020 18:55:03 -0800 Message-ID: To: Markku Kojo Cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000fb9fc505b6a01e72" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmfor TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 02:55:20 -0000 --000000000000fb9fc505b6a01e72 Content-Type: text/plain; charset="UTF-8" (1) Flightsize: in RFC 6675 . Section 5, Step 4.2: (4.2) ssthresh = cwnd = (FlightSize / 2) The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC5681 ]. Additionally, note that [RFC5681 ] requires that any *segments sent as part of the Limited Transmit mechanism not be counted in FlightSize *for the purpose of the above equation. IIUC the segments P21..P29 in your example were sent because of Limited Transmit, and so don't count. The flightsize for the purposes of (4.2) is therefore 20 after both losses, and the cwnd does not go up on the second loss. (2) " Even a single shot burst every time there is significant loss event is not acceptable, not to mention continuous aggressiveness, and this is exactly what RFC 2914 and RFC 5033 explicitly address and warn about." "Significant loss event" is the key phrase here. The intent of TLP/PTO is to equalize the treatment of a small packet loss whether it happened in the middle of a burst or the end. Why should an isolated loss be treated differently based on its position in the burst? This is just a logical extension of fast retransmit, which also modified the RTO paradigm. The working group consensus is that this is a feature, not a bug; you're welcome to feel otherwise but I suspect you're in the rough here. Regards Martin On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote: > Hi Martin, > > See inline. > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > Hi Markku, > > > > There is a ton here, but I'll try to address the top points. Hopefully > > they obviate the rest. > > Sorry for being verbose. I tried to be clear but you actually removed my > key issues/questions ;) > > > 1. > > [Markku] > > "Hmm, not sure what you mean by "this is a new loss detection after > > acknowledgment of new data"? > > But anyway, RFC 5681 gives the general principle to reduce cwnd and > > ssthresh twice if a retransmission is lost but IMHO (and I believe many > > who have designed new loss recovery and CC algorithms or implemented > > them > > agree) that it is hard to get things right if only congestion control > > principles are available and no algorithm." > > > > [Martin] > > So 6675 Sec 5 is quite explicit that there is only one cwnd reduction > > per fast recovery episode, which ends once new data has been > > acknowledged. > > To be more precise: fast recovery ends when the current window becomes > cumulatively acknowledged, that is, > > (4.1) RecoveryPoint (= HighData at the beginning) becomes acknowledged > > I believe we agree and you meant this although new data below > RecoveryPoint may become cumulatively acknowledged already earlier > during the fast recovery. Reno loss recovery in RFC 5681 ends, when > (any) new data has been acknowledged. > > > By definition, if a retransmission is lost it is because > > newer data has been acknowledged, so it's a new recovery episode. > > Not sure where you have this definition? Newer than what are you > referring to? > > But, yes, if a retransmission is lost with RFC 6675 algorithm, > it requires RTO to be detected and definitely starts a new recovery > episode. That is, a new recovery episode is enforced by step (1.a) of > NextSeg () which prevents retransmission if a segment that has already > been retransmitted. If RACK-TLP is used for detecting loss with RFC 6675 > things get different in many ways, because it may detect loss of a > retransmission. It would pretty much require an entire redesign > of the algorith. For example, calculation of pipe does not consider > segments that have been retransmitted more than once. > > > Meanwhile, during the Fast Recovery period the incoming acks implicitly > > remove data from the network and therefore keep flightsize low. > > Incorrect. FlightSize != pipe. Only cumulative acks remove data from > FlightSize and new data transmitted during fast recovery inflate > FlightSize. How FlightSize evolves depends on loss pattern as I said. > It is also possible that FlightSize is low, it may err in both > directions. A simple example can be used as a proof for the case where > cwnd increases if a loss of retransmission is detected and repaired: > > RFC 6675 recovery with RACK-TLP loss detection: > (contains some inaccuracies because it has not been defined how > lost rexmits are calculated into pipe) > > cwnd=20; packets P1,...,P20 in flight = current window of data > [P1 dropped and rexmit of P1 will also be dropped] > > DupAck w/SACK for P2 arrives > [loss of P1 detected after one RTT from original xmit of P1] > [cwnd=ssthresh=10] > P1 is rexmitted (and it logically starts next window of data) > > DupAcks w/ SACK for original P3..11 arrive > DupAck w/ SACK for original P12 arrives > [cwnd-pipe = 10-9 >=1] > send P21 > DupAck w/SACK for P13 arrives > send P22 > ... > DupAck w/SACK for P20 arrives > send P29 > [FlightSize=29] > > (Ack for rexmit of P1 would arrive here unless it got dropped) > > DupAck w/SACK for P21 arrives > [loss of rexmit P1 detected after one RTT from rexmit of P1] > > SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 > > CWND INCREASES when it should be at most 5 after halving it twice!!! > > > We can continue to go around on our interpretation of these documents, > > but fundamentally if there is ambiguity in 5681/6675 we should bis > > those RFCs rather than expand the scope of RACK. > > As I said earlier, I am not opposing bis, though 5681bis wuold not > be needed, I think. > > But let me repeat: if we publish RACK-TLP now without necessary warnings > or with a correct congesion control algorithm someone will try to > implement RACK-TLP with RFC 6675 and it will be a total mesh. The > behavior will be unpredictable and quite likely unsafe congestion > control behavior. > > > 2. > > [Markku] > > " In short: > > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=1 > > MSS, > > and slow start is entered. > > When with a RACK_TLP implementation timer (PTO) expires, > > normal fast recovery is entered (unless implementing > > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1." > > > > [Martin] > > There may be a misunderstanding here. PTO is not the same as RTO, and > > both mechanisms exist! The loss response to a PTO is to send a probe; > > the RTO response is as with conventional TCP. In Section 7.3: > > No, I don't think I misunderstood. If you call timeout with > another name, it is still timeout. And congestion control does not > consider which segments to send (SND.UNA vs. probe w/ higher sequence > number), only how much is sent. > > You ignored my major point where I decoupled congestion control from loss > detection and loss recovery and compared RFC 5681 behavior to RACK-TLP > behavior in exactly the same scenario where an entire flight is lost and > timer expires. > > Please comment why congestion control behavior is allowed to be radically > different in these two implementations? > > RFC 5681 & RFC 6298 timeout: > > RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > 1. RTO timer expires > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment > 3. Ack of rexmit sent in step 2 arrives > 4. cwnd = cwnd+1 MSS; send two segments > ... > > RACK-TLP timeout: > > PTO=min(2*SRTT,RTO) (PTO used for arming the timer) > 1. PTO times expires > 2. (cwnd=1 MSS); (re)xmit one segment > 3. Ack of (re)xmit sent in srep 2 arrives > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments > > If FlightSize is 100 segments when timer expires, congestion control is > the same in steps 1-3, but in step 4 the standard congestion control > allows transmitting 2 segments, while RACK-TLP would allow > blasting 50 segments. > > > After attempting to send a loss probe, regardless of whether a loss > > probe was sent, the sender MUST re-arm the RTO timer, not the PTO > > timer, if FlightSize is not zero. This ensures RTO recovery remains > > the last resort if TLP fails. > > " > > This does not prevent the above RACK-TLP behavior from getting realized. > > > So a pure RTO response exists in the case of persistent congestion that > > causes losses of probes or their ACKs. > > Yes, RTO response exists BUT only after RACK-TLP at least once blasts the > network. It may well be that with smaller windows RACK-TLP is successful > during its TLP initiated overly aggressive "fast recovery" and never > enters RTO recovery because it may detect and repair also loss of > rexmits. That is, it continues at too high rate even if lost rexmits > indicate that congestion persists in successive windows of data. And > worse, it is successful because it pushes away other compatible TCP > flows by being too aggressive and unfair. > > Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > about. > > Are we ignoring these BCPs that have IETF consensus? > > And the other important question I'd like to have an answer: > > What is the justification to modify standard TCP congestion control to > use fast recovery instead of slow start for a case where timeout is > needed to detect the packet losses because there is no feedback and ack > clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4.1. > > As I noted: based on what is written in the draft it does not intend to > change congestion control but effectively it does. > > /Markku > > > Martin > > > > > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > > wrote: > > Hi Martin, > > > > On Tue, 15 Dec 2020, Martin Duke wrote: > > > > > Hi Markku, > > > > > > Thanks for the comments. The authors will incorporate > > many of your > > > suggestions after the IESG review. > > > > > > There's one thing I don't understand in your comments: > > > > > > " That is, > > > where can an implementer find advice for correct > > congestion control > > > actions with RACK-TLP, when: > > > > > > (1) a loss of rexmitted segment is detected > > > (2) an entire flight of data gets dropped (and detected), > > > that is, when there is no feedback available and a > > timeout > > > is needed to detect the loss " > > > > > > Section 9.3 is the discussion about CC, and is clear that > > the > > > implementer should use either 5681 or 6937. > > > > Just a cite nit: RFC 5681 provides basic CC concepts and > > some useful CC > > guidelines but given that RACK-TLP MUST implement SACK the > > algorithm in > > RFC 5681 is not that useful and an implementer quite likely > > follows > > mainly the algorithm in RFC 6675 (and not RFC 6937 at all > > if not > > implementing PRR). > > And RFC 6675 is not mentioned in Sec 9.3, though it is > > listed in the > > Sec. 4 (Requirements). > > > > > You went through the 6937 case in detail. > > > > Yes, but without correct CC actions. > > > > > If 5681, it's pretty clear to me that in (1) this is a > > new loss > > > detection after acknowledgment of new data, and therefore > > requires a > > > second halving of cwnd. > > > > Hmm, not sure what you mean by "this is a new loss > > detection after > > acknowledgment of new data"? > > But anyway, RFC 5681 gives the general principle to reduce > > cwnd and > > ssthresh twice if a retransmission is lost but IMHO (and I > > believe many > > who have designed new loss recovery and CC algorithms or > > implemented them > > agree) that it is hard to get things right if only > > congestion control > > principles are available and no algorithm. > > That's why ALL mechanisms that we have include a quite > > detailed algorithm > > with all necessary variables and actions for loss recovery > > and/or CC > > purposes (and often also pseudocode). Like this document > > does for loss > > detection. > > > > So the problem is that we do not have a detailed enough > > algorithm or > > rule that tells exactly what to do when a loss of rexmit is > > detected. > > Even worse, the algorithms in RFC 5681 and RFC 6675 refer > > to > > equation (4) of RFC 5681 to reduce ssthresh and cwnd when a > > loss > > requiring a congestion control action is detected: > > > > (cwnd =) ssthresh = FlightSize / 2) > > > > And RFC 5681 gives a warning not to halve cwnd in the > > equation but > > FlightSize. > > > > That is, this equation is what an implementer intuitively > > would use > > when reading the relevant RFCs but it gives a wrong result > > for > > outstanding data when in fast recovery (when the sender is > > in > > congestion avoidance and the equation (4) is used to halve > > cwnd, it > > gives a correct result). > > More precisely, during fast recovery FlightSize is inflated > > when new > > data is sent and reduced when segments are cumulatively > > Acked. > > What the outcome is depends on the loss pattern. In the > > worst case, > > FlightSize is signficantly larger than in the beginning of > > the fast > > recovery when FlightSize was (correctly) used to determine > > the halved > > value for cwnd and ssthresh, i.e., equation (4) may result > > in > > *increasing* cwnd upon detecting a loss of a rexmitted > > segment, instead > > of further halving it. > > > > A clever implementer might have no problem to have it right > > with some > > thinking but I am afraid that there will be incorrect > > implementations > > with what is currently specified. Not all implementers have > > spent > > signicicant fraction of their career in solving TCP > > peculiarities. > > > > > For (2), the RTO timer is still operative so > > > the RTO recovery rules would still follow. > > > > In short: > > When with a non-RACK-TLP implementation timer (RTO) > > expires: cwnd=1 MSS, > > and slow start is entered. > > When with a RACK_TLP implementation timer (PTO) expires, > > normal fast recovery is entered (unless implementing > > also PRR). So no RTO recovery as explicitly stated in Sec. > > 7.4.1. > > > > This means that this document explicitly modifies standard > > TCP congestion > > control when there are no acks coming and the > > retransmission timer > > expires > > > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > > 1. RTO timer expires > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one > > segment > > 3. Ack of rexmit sent in step 2 arrives > > 4. cwnd = cwnd+1 MSS; send two segments > > ... > > > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the timer) > > 1. PTO times expires > > 2. (cwnd=1 MSS); (re)xmit one segment > > 3. Ack of (re)xmit sent in srep 2 arrives > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd > > segments > > > > For example, if FlightSize is 100 segments when timer > > expires, > > congestion control is the same in steps 1-3, but in step 4 > > the > > current standard congestion control allows transmitting 2 > > segments, > > while RACK-TLP would allow blasting 50 segments. > > > > Question is: what is the justification to modify standard > > TCP > > congestion control to use fast recovery instead of slow > > start for a > > case where timeout is needed to detect loss because there > > is no > > feedback and ack clock is lost? The draft does not give any > > justification. This clearly is in conflict with items (0) > > and (1) > > in BCP 133 (RFC 5033). > > > > Furthermore, there is no implementation nor experimental > > experience > > evaluating this change. The implementation with > > experimental experience > > uses PRR (RFC 6937) which is an Experimental specification > > including a > > novel "trick" that directs PRR fast recovery to effectively > > use slow > > start in this case at hand. > > > > > > > In other words, I am not seeing a case that requires new > > congestion > > > control concepts except as discussed in 9.3. > > > > See above. The change in standard congestion control for > > (2). > > The draft intends not to change congestion control but > > effectively it > > does without any operational evidence. > > > > What's also is missing and would be very useful: > > > > - For (1), a hint for an implementer saying that because > > RACK-TLP is > > able to detect a loss of a rexmit unlike any other loss > > detection > > algorithm, the sender MUST react twice to congestion > > (and cite > > RFC 5681). And cite a document where necessary correct > > actions > > are described. > > > > - For (1), advise that an implementer needs to keep track > > when it > > detects a loss of a retransmitted segment. Current > > algorithms > > in the draft detect a loss of retransmitted segment > > exactly in > > the same way as loss of any other segment. There seems > > to be > > nothing to track when a retransmission of a > > retransmitted segment > > takes place. Therefore, the algorithms should have > > additional > > actions to correctly track when such a loss is detected. > > > > - For (1), discussion on how many times a loss of a > > retransmission > > of the same segment may occur and be detected. Seems > > that it > > may be possible to drop a rexmitted segment more than > > once and > > detect it also several times? What are the > > implications? > > > > - If previous is possible, then the algorithm possibly also > > may detect a loss of a new segment that was sent during > > fast > > recovery? This is also loss in two successive windows of > > data, > > and cwnd MUST be lowered twice. This discussion and > > necessary > > actions to track it are missing, if such scenario is > > possible. > > > > > What am I missing? > > > > Hope the above helps. > > > > /Markku > > > > > > > > > > --000000000000fb9fc505b6a01e72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(1) Flightsize: in RFC 6675. Section 5, Step 4.2:

<= /div>
       =
(4.2) ssthresh =3D cwnd =3D (FlightSize / 2)

             The congestion window (cwnd) and slow start threshold
             (ssthresh) are reduced to half of FlightSize per [RFC5681].
             Additionally, note that [RFC5681] requir=
es that any
             segments sent as part of the Limited Transmit mechanism not
             be counted in FlightSize for the purpose of the above
             equation.

IIUC the segments P21..P29 in your example were s= ent because of Limited Transmit, and so don't count. The flightsize for= the purposes of (4.2) is therefore 20 after both losses, and the cwnd does= not go up on the second loss.

(2)
<= /div>
" Even a single shot burst every time there is significant loss
event is not acceptable, not to mention continuous aggressiveness, and
this is exactly what RFC 2914 and RFC 5033 explicitly address and warn
about."

"Significant loss event" is= the key phrase here. The intent of TLP/PTO is to equalize the treatment of= a small packet loss whether it happened in the middle of a burst or the en= d. Why should an isolated loss be treated differently based on its position= in the burst? This is just a logical extension of fast retransmit, which a= lso modified the RTO paradigm. The working group consensus is that this is = a feature, not a bug; you're welcome to feel otherwise but I suspect yo= u're in the rough here.

Regards
= Martin


On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> = wrote:
Hi Martin= ,

See inline.

On Wed, 16 Dec 2020, Martin Duke wrote:

> Hi Markku,
>
> There is a ton here, but I'll try to address the top points. Hopef= ully
> they obviate the rest.

Sorry for being verbose. I tried to be clear but you actually removed my key issues/questions ;)

> 1.
> [Markku]
> "Hmm, not sure what you mean by "this is a new loss detectio= n after
> acknowledgment of new data"?
> But anyway, RFC 5681 gives the general principle to reduce cwnd and > ssthresh twice if a retransmission is lost but IMHO (and I believe man= y
> who have designed new loss recovery and CC algorithms or implemented > them
> agree) that it is hard to get things right if only congestion control<= br> > principles are available and no algorithm."
>
> [Martin]
> So 6675 Sec 5 is quite explicit that there is only one cwnd reduction<= br> > per fast recovery episode, which ends once new data has been
> acknowledged.

To be more precise: fast recovery ends when the current window becomes
cumulatively acknowledged, that is,

(4.1) RecoveryPoint (=3D HighData at the beginning) becomes acknowledged
I believe we agree and you meant this although new data below
RecoveryPoint may become cumulatively acknowledged already earlier
during the fast recovery. Reno loss recovery in RFC 5681 ends, when
(any) new data has been acknowledged.

> By definition, if a retransmission is lost it is because
> newer data has been acknowledged, so it's a new recovery episode.<= br>
Not sure where you have this definition? Newer than what are you
referring to?

But, yes, if a retransmission is lost with RFC 6675 algorithm,
it requires RTO to be detected and definitely starts a new recovery
episode. That is, a new recovery episode is enforced by step (1.a) of
NextSeg () which prevents retransmission if a segment that has already
been retransmitted. If RACK-TLP is used for detecting loss with RFC 6675 things get different in many ways, because it may detect loss of a
retransmission. It would pretty much require an entire redesign
of the algorith. For example, calculation of pipe does not consider
segments that have been retransmitted more than once.

> Meanwhile, during the Fast Recovery period the incoming acks implicitl= y
> remove data from the network and therefore keep flightsize low.

Incorrect. FlightSize !=3D pipe. Only cumulative acks remove data from
FlightSize and new data transmitted during fast recovery inflate
FlightSize. How FlightSize evolves depends on loss pattern as I said.
It is also possible that FlightSize is low, it may err in both
directions. A simple example can be used as a proof for the case where
cwnd increases if a loss of retransmission is detected and repaired:

RFC 6675 recovery with RACK-TLP loss detection:
(contains some inaccuracies because it has not been defined how
lost rexmits are calculated into pipe)

cwnd=3D20; packets P1,...,P20 in flight =3D current window of data
[P1 dropped and rexmit of P1 will also be dropped]

DupAck w/SACK for P2 arrives
[loss of P1 detected after one RTT from original xmit of P1]
[cwnd=3Dssthresh=3D10]
P1 is rexmitted (and it logically starts next window of data)

DupAcks w/ SACK for original P3..11 arrive
DupAck w/ SACK for original P12 arrives
[cwnd-pipe =3D 10-9 >=3D1]
send P21
DupAck w/SACK for P13 arrives
send P22
...
DupAck w/SACK for P20 arrives
send P29
[FlightSize=3D29]

(Ack for rexmit of P1 would arrive here unless it got dropped)

DupAck w/SACK for P21 arrives
[loss of rexmit P1 detected after one RTT from rexmit of P1]

SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5

CWND INCREASES when it should be at most 5 after halving it twice!!!

> We can continue to go around on our interpretation of these documents,=
> but fundamentally if there is ambiguity in 5681/6675 we should bis
> those RFCs rather than expand the scope of RACK.

As I said earlier, I am not opposing bis, though 5681bis wuold not
be needed, I think.

But let me repeat: if we publish RACK-TLP now without necessary warnings or with a correct congesion control algorithm someone will try to
implement RACK-TLP with RFC 6675 and it will be a total mesh. The
behavior will be unpredictable and quite likely unsafe congestion
control behavior.

> 2.
> [Markku]
> " In short:
> When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1<= br> > MSS,
> and slow start is entered.
> When with a RACK_TLP implementation timer (PTO) expires,
> normal fast recovery is entered (unless implementing
> also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1."= ;
>
> [Martin]
> There may be a misunderstanding here. PTO is not the same as RTO, and<= br> > both mechanisms exist! The loss response to a PTO is to send a probe;<= br> > the RTO response is as with conventional TCP. In Section 7.3:

No, I don't think I misunderstood. If you call timeout with
another name, it is still timeout. And congestion control does not
consider which segments to send (SND.UNA vs. probe w/ higher sequence
number), only how much is sent.

You ignored my major point where I decoupled congestion control from loss <= br> detection and loss recovery and compared RFC 5681 behavior to RACK-TLP
behavior in exactly the same scenario where an entire flight is lost and timer expires.

Please comment why congestion control behavior is allowed to be radically <= br> different in these two implementations?

RFC 5681 & RFC 6298 timeout:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTTVAR (RTO used for arming the ti= mer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit= one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
=C2=A0 =C2=A0 =C2=A0 =C2=A0...

RACK-TLP timeout:

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PTO used for arming= the timer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3D= cwnd segments

If FlightSize is 100 segments when timer expires, congestion control is the same in steps 1-3, but in step 4 the standard congestion control
allows transmitting 2 segments, while RACK-TLP would allow
blasting 50 segments.

> After attempting to send a loss probe, regardless of whether a loss >=C2=A0 =C2=A0 probe was sent, the sender MUST re-arm the RTO timer, not= the PTO
>=C2=A0 =C2=A0 timer, if FlightSize is not zero.=C2=A0 This ensures RTO = recovery remains
>=C2=A0 =C2=A0 the last resort if TLP fails.
> "

This does not prevent the above RACK-TLP behavior from getting realized.
> So a pure RTO response exists in the case of persistent congestion tha= t
> causes losses of probes or their ACKs.

Yes, RTO response exists BUT only after RACK-TLP at least once blasts the <= br> network. It may well be that with smaller windows RACK-TLP is successful during its TLP initiated overly aggressive "fast recovery" and ne= ver
enters RTO recovery because it may detect and repair also loss of
rexmits. That is, it continues at too high rate even if lost rexmits
indicate that congestion persists in successive windows of data. And
worse, it is successful because it pushes away other compatible TCP
flows by being too aggressive and unfair.

Even a single shot burst every time there is significant loss
event is not acceptable, not to mention continuous aggressiveness, and
this is exactly what RFC 2914 and RFC 5033 explicitly address and warn
about.

Are we ignoring these BCPs that have IETF consensus?

And the other important question I'd like to have an answer:

What is the justification to modify standard TCP congestion control to
use fast recovery instead of slow start for a case where timeout is
needed to detect the packet losses because there is no feedback and ack clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4.1.

As I noted: based on what is written in the draft it does not intend to change congestion control but effectively it does.

/Markku

> Martin
>
>
> On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo <kojo@cs.helsinki.fi>
> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks for the comments. The authors wi= ll incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggestions after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There's one thing I don't under= stand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " That is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where can an implementer find advice fo= r correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a loss of rexmitted segment is dete= cted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an entire flight of data gets dropp= ed (and detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0that is, when there= is no feedback available and a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0is needed to detect= the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section 9.3 is the discussion about CC,= and is clear that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implementer should use either 5681 or 6= 937.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite nit: RFC 5681 provides basic CC = concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines but given that RACK-TLP MUST impl= ement SACK the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is not that useful and an implement= er quite likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the algorithm in RFC 6675 (and not RF= C 6937 at all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 is not mentioned in Sec 9.3, th= ough it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requirements).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went through the 6937 case in detai= l.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but without correct CC actions.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681, it's pretty clear to me th= at in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detection after acknowledgment of new d= ata, and therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second halving of cwnd.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure what you mean by "this is= a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, RFC 5681 gives the general princ= iple to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twice if a retransmission is lost b= ut IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have designed new loss recovery and CC a= lgorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that it is hard to get things right i= f only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles are available and no algorithm. >=C2=A0 =C2=A0 =C2=A0 =C2=A0That's why ALL mechanisms that we have i= nclude a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algorithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all necessary variables and actions for= loss recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and often also pseudocode). Like t= his document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the problem is that we do not have a deta= iled enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tells exactly what to do when a lo= ss of rexmit is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, the algorithms in RFC 5681 and R= FC 6675 refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) of RFC 5681 to reduce ssthresh = and cwnd when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a congestion control action is det= ected:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd =3D) ssthresh =3D FlightSize / = 2)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 gives a warning not to halve cw= nd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this equation is what an implemente= r intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading the relevant RFCs but it gives = a wrong result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding data when in fast recovery (when= the sender is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion avoidance and the equation (4) is= used to halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a correct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisely, during fast recovery FlightS= ize is inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent and reduced when segments are c= umulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outcome is depends on the loss patt= ern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is signficantly larger than in th= e beginning of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when FlightSize was (correctly) use= d to determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwnd and ssthresh, i.e., equation = (4) may result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* cwnd upon detecting a loss of a= rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, instead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further halving it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever implementer might have no problem t= o have it right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but I am afraid that there will be = incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is currently specified. Not all im= plementers have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant fraction of their career in solv= ing TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2), the RTO timer is still operati= ve so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO recovery rules would still foll= ow.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a non-RACK-TLP implementation time= r (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd=3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a RACK_TLP implementation timer (P= TO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast recovery is entered (unless impl= ementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So no RTO recovery as explicitly = stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means that this document explicitly mod= ifies standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when there are no acks coming and th= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DSRTT+4*RTTVAR (RTO used for armi= ng the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO u= sed for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, if FlightSize is 100 segments w= hen timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control is the same in steps 1-3,= but in step 4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0current standard congestion control allows t= ransmitting 2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TLP would allow blasting 50 segme= nts.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: what is the justification to mo= dify standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control to use fast recovery inst= ead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where timeout is needed to detect loss = because there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and ack clock is lost? The draft do= es not give any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification. This clearly is in conflict w= ith items (0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (RFC 5033).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, there is no implementation nor = experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating this change. The implementation w= ith
>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC 6937) which is an Experimental= specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "trick" that directs PRR fas= t recovery to effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this case at hand.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other words, I am not seeing a case = that requires new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control concepts except as discussed in= 9.3.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. The change in standard congestion= control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft intends not to change congestion c= ontrol but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without any operational evidence.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's also is missing and would be very= useful:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a hint for an implementer saying = that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0able to detect a loss of a rexm= it unlike any other loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0algorithm, the sender MUST reac= t twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0RFC 5681). And cite a document = where necessary correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0are described.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), advise that an implementer needs = to keep track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detects a loss of a retransmitt= ed segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0in the draft detect a loss of r= etransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the same way as loss of any oth= er segment. There seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0nothing to track when a retrans= mission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0takes place. Therefore, the alg= orithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to correctly track when= such a loss is detected.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), discussion on how many times a lo= ss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of the same segment may occur a= nd be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may be possible to drop a rexmi= tted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detect it also several times?= =C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous is possible, then the algorith= m possibly also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may detect a loss of a new segm= ent that was sent during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0recovery? This is also loss in = two successive windows of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and cwnd MUST be lowered twice.= This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to track it are missing= , if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am I missing?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the above helps.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>
> <snipping the rest>
>
>
--000000000000fb9fc505b6a01e72-- From nobody Wed Dec 16 20:49:24 2020 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 E69443A1349; Wed, 16 Dec 2020 20:49:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, tuexen@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160818055846.21007.18172807717470668998@ietfa.amsl.com> Date: Wed, 16 Dec 2020 20:49:18 -0800 Archived-At: Subject: [tcpm] Barry Leiba's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 04:49:19 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tcpm-rack-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a very small comment: — Section 1 — In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. I don’t particularly object to that quoted text, but it’s redundant: the (correct) BCP 14 boilerplate before it already says that. What’s the purpose of adding this text? (I’m guessing it’s a remnant: it was there with the old BCP 14 boilerplate frim 2119, and when you switched to 8174 you didn’t remove this.) From nobody Wed Dec 16 21:56:17 2020 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 123D73A1490; Wed, 16 Dec 2020 21:56:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, tuexen@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160818456961.27293.9184699786015901072@ietfa.amsl.com> Date: Wed, 16 Dec 2020 21:56:10 -0800 Archived-At: Subject: [tcpm] Erik Kline's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 05:56:10 -0000 Erik Kline has entered the following ballot position for draft-ietf-tcpm-rack-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ nits ]] [ section 3.1 ] * "Conceptually, RACK puts a virtual timer for" Instead of "puts" perhaps "uses", "keeps", "imagines", or something? [ section 4 ] * "a timestamp whose granularity that is finer" -> "a timestamp with a granularity that is finer", or "a timestamp whose granularity is finer", perhaps [ section 9.4 ] * "sender takes longer time" -> "sender takes a longer time"? From nobody Wed Dec 16 23:27:18 2020 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 37C023A151B; Wed, 16 Dec 2020 23:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kn_lG-KXe3tT; Wed, 16 Dec 2020 23:27:13 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 697453A1010; Wed, 16 Dec 2020 23:27:12 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id w12so709374ilm.12; Wed, 16 Dec 2020 23:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BNk3KpAM19XnZfw4Dwxt4uNevH2ORuedSrkslWXI940=; b=LgWuofU5iLID2tAYq7EfEr9k+Et48gCjyKU7iGLNiIZcisFN86B56x+chCxZZJ9XgX w+4h9G0ebrJ0yC+eMM6YjDWjaw6i+pN0ADOATkE6FLyyyvk1kKh1gvyTHQ2UbLL/2Pg9 Cw/PuBTgxk0BCBi+FOHtKCjUpIJAdbx73f03grIxBqizL6I2g8LE/xevSAagbZykXnm0 2C/dEa5mCAJdlnMWieZ1UP+VHD/UJV93bbliOzwmEP4Q2ijzC4C+4KU2ZTGlAC8Yyg0U qUIc6h6nYEP1sW015NwRa2nFi3DYUYYyxIKqR04tqbdai93F4t5vDKO3eXtiqJfaqQSs FL9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BNk3KpAM19XnZfw4Dwxt4uNevH2ORuedSrkslWXI940=; b=bavs1eMBrMXnxPBsDW/kLQLrKRdbO6gIVU7znNggYy5xF14eddPUMOodyMb0DzqcN3 XXMhxblH6MR0AkeNT55Aehyjo5uDVu2v83NrCQHWndzLgnLPqD69vWA6063K5RSQ4h3O OZwc/GVo0WtkOu6Yn+n/aMlU+zfdXrzEjMmZiine32yDTVEXvY6wl7zs0eoKc5ImReeH qwHOrCHRBru6mTB0Qm3c8a65S5GwSisH3fA5d25gLPQeW+0NSnQA0TzrDAoLwr+4J5J8 AsQae1Pz3oQzjH8yAewcAMLT/TdbAK2cUbBz6URVxOquzHm5oQwfGhoRJsdO3kugAWAd xhlw== X-Gm-Message-State: AOAM533wl/66myCNBqgJCzmX3fLcbmxAb06rghqeASI83hx5sfqDz1kM UKoPdGu8/DRtn8DIIWx5CSwY9iwRvNys+t+6XBU= X-Google-Smtp-Source: ABdhPJwIqDtD8CMzvBuZ+hyzlOTLh5TV1M+af6977gFOc+I8hVJYpf55zTtMOyyw0Rd2zwIgL37+l0UIZvuIY8HA7eM= X-Received: by 2002:a92:155b:: with SMTP id v88mr48360349ilk.303.1608190031472; Wed, 16 Dec 2020 23:27:11 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Wed, 16 Dec 2020 23:26:59 -0800 Message-ID: To: Markku Kojo Cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="0000000000008ead4f05b6a3eb70" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmfor TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 07:27:17 -0000 --0000000000008ead4f05b6a3eb70 Content-Type: text/plain; charset="UTF-8" I spent a little longer looking at the specs more carefully, and I explained (1) incorrectly in my last two messages. P21..29 are not Limited Transmit packets. However, unless I'm missing something else, 6675 is clear that the recovery period does not end until the cumulative ack advances, meaning that detecting the lost retransmission of P1 does not trigger another MD directly. Thanks for this exercise! It's refreshed my memory of these details after working on slightly different QUIC algorithms a long time. On Wed, Dec 16, 2020, 18:55 Martin Duke wrote: > (1) Flightsize: in RFC 6675 . > Section 5, Step 4.2: > > (4.2) ssthresh = cwnd = (FlightSize / 2) > > The congestion window (cwnd) and slow start threshold > (ssthresh) are reduced to half of FlightSize per [RFC5681 ]. > Additionally, note that [RFC5681 ] requires that any > *segments sent as part of the Limited Transmit mechanism not > be counted in FlightSize *for the purpose of the above > equation. > > > IIUC the segments P21..P29 in your example were sent because of Limited > Transmit, and so don't count. The flightsize for the purposes of (4.2) is > therefore 20 after both losses, and the cwnd does not go up on the second > loss. > > (2) > " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > about." > > "Significant loss event" is the key phrase here. The intent of TLP/PTO is > to equalize the treatment of a small packet loss whether it happened in the > middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical > extension of fast retransmit, which also modified the RTO paradigm. The > working group consensus is that this is a feature, not a bug; you're > welcome to feel otherwise but I suspect you're in the rough here. > > Regards > Martin > > > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote: > >> Hi Martin, >> >> See inline. >> >> On Wed, 16 Dec 2020, Martin Duke wrote: >> >> > Hi Markku, >> > >> > There is a ton here, but I'll try to address the top points. Hopefully >> > they obviate the rest. >> >> Sorry for being verbose. I tried to be clear but you actually removed my >> key issues/questions ;) >> >> > 1. >> > [Markku] >> > "Hmm, not sure what you mean by "this is a new loss detection after >> > acknowledgment of new data"? >> > But anyway, RFC 5681 gives the general principle to reduce cwnd and >> > ssthresh twice if a retransmission is lost but IMHO (and I believe many >> > who have designed new loss recovery and CC algorithms or implemented >> > them >> > agree) that it is hard to get things right if only congestion control >> > principles are available and no algorithm." >> > >> > [Martin] >> > So 6675 Sec 5 is quite explicit that there is only one cwnd reduction >> > per fast recovery episode, which ends once new data has been >> > acknowledged. >> >> To be more precise: fast recovery ends when the current window becomes >> cumulatively acknowledged, that is, >> >> (4.1) RecoveryPoint (= HighData at the beginning) becomes acknowledged >> >> I believe we agree and you meant this although new data below >> RecoveryPoint may become cumulatively acknowledged already earlier >> during the fast recovery. Reno loss recovery in RFC 5681 ends, when >> (any) new data has been acknowledged. >> >> > By definition, if a retransmission is lost it is because >> > newer data has been acknowledged, so it's a new recovery episode. >> >> Not sure where you have this definition? Newer than what are you >> referring to? >> >> But, yes, if a retransmission is lost with RFC 6675 algorithm, >> it requires RTO to be detected and definitely starts a new recovery >> episode. That is, a new recovery episode is enforced by step (1.a) of >> NextSeg () which prevents retransmission if a segment that has already >> been retransmitted. If RACK-TLP is used for detecting loss with RFC 6675 >> things get different in many ways, because it may detect loss of a >> retransmission. It would pretty much require an entire redesign >> of the algorith. For example, calculation of pipe does not consider >> segments that have been retransmitted more than once. >> >> > Meanwhile, during the Fast Recovery period the incoming acks implicitly >> > remove data from the network and therefore keep flightsize low. >> >> Incorrect. FlightSize != pipe. Only cumulative acks remove data from >> FlightSize and new data transmitted during fast recovery inflate >> FlightSize. How FlightSize evolves depends on loss pattern as I said. >> It is also possible that FlightSize is low, it may err in both >> directions. A simple example can be used as a proof for the case where >> cwnd increases if a loss of retransmission is detected and repaired: >> >> RFC 6675 recovery with RACK-TLP loss detection: >> (contains some inaccuracies because it has not been defined how >> lost rexmits are calculated into pipe) >> >> cwnd=20; packets P1,...,P20 in flight = current window of data >> [P1 dropped and rexmit of P1 will also be dropped] >> >> DupAck w/SACK for P2 arrives >> [loss of P1 detected after one RTT from original xmit of P1] >> [cwnd=ssthresh=10] >> P1 is rexmitted (and it logically starts next window of data) >> >> DupAcks w/ SACK for original P3..11 arrive >> DupAck w/ SACK for original P12 arrives >> [cwnd-pipe = 10-9 >=1] >> send P21 >> DupAck w/SACK for P13 arrives >> send P22 >> ... >> DupAck w/SACK for P20 arrives >> send P29 >> [FlightSize=29] >> >> (Ack for rexmit of P1 would arrive here unless it got dropped) >> >> DupAck w/SACK for P21 arrives >> [loss of rexmit P1 detected after one RTT from rexmit of P1] >> >> SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 >> >> CWND INCREASES when it should be at most 5 after halving it twice!!! >> >> > We can continue to go around on our interpretation of these documents, >> > but fundamentally if there is ambiguity in 5681/6675 we should bis >> > those RFCs rather than expand the scope of RACK. >> >> As I said earlier, I am not opposing bis, though 5681bis wuold not >> be needed, I think. >> >> But let me repeat: if we publish RACK-TLP now without necessary warnings >> or with a correct congesion control algorithm someone will try to >> implement RACK-TLP with RFC 6675 and it will be a total mesh. The >> behavior will be unpredictable and quite likely unsafe congestion >> control behavior. >> >> > 2. >> > [Markku] >> > " In short: >> > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=1 >> > MSS, >> > and slow start is entered. >> > When with a RACK_TLP implementation timer (PTO) expires, >> > normal fast recovery is entered (unless implementing >> > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1." >> > >> > [Martin] >> > There may be a misunderstanding here. PTO is not the same as RTO, and >> > both mechanisms exist! The loss response to a PTO is to send a probe; >> > the RTO response is as with conventional TCP. In Section 7.3: >> >> No, I don't think I misunderstood. If you call timeout with >> another name, it is still timeout. And congestion control does not >> consider which segments to send (SND.UNA vs. probe w/ higher sequence >> number), only how much is sent. >> >> You ignored my major point where I decoupled congestion control from loss >> detection and loss recovery and compared RFC 5681 behavior to RACK-TLP >> behavior in exactly the same scenario where an entire flight is lost and >> timer expires. >> >> Please comment why congestion control behavior is allowed to be radically >> different in these two implementations? >> >> RFC 5681 & RFC 6298 timeout: >> >> RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >> 1. RTO timer expires >> 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment >> 3. Ack of rexmit sent in step 2 arrives >> 4. cwnd = cwnd+1 MSS; send two segments >> ... >> >> RACK-TLP timeout: >> >> PTO=min(2*SRTT,RTO) (PTO used for arming the timer) >> 1. PTO times expires >> 2. (cwnd=1 MSS); (re)xmit one segment >> 3. Ack of (re)xmit sent in srep 2 arrives >> 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments >> >> If FlightSize is 100 segments when timer expires, congestion control is >> the same in steps 1-3, but in step 4 the standard congestion control >> allows transmitting 2 segments, while RACK-TLP would allow >> blasting 50 segments. >> >> > After attempting to send a loss probe, regardless of whether a loss >> > probe was sent, the sender MUST re-arm the RTO timer, not the PTO >> > timer, if FlightSize is not zero. This ensures RTO recovery remains >> > the last resort if TLP fails. >> > " >> >> This does not prevent the above RACK-TLP behavior from getting realized. >> >> > So a pure RTO response exists in the case of persistent congestion that >> > causes losses of probes or their ACKs. >> >> Yes, RTO response exists BUT only after RACK-TLP at least once blasts the >> network. It may well be that with smaller windows RACK-TLP is successful >> during its TLP initiated overly aggressive "fast recovery" and never >> enters RTO recovery because it may detect and repair also loss of >> rexmits. That is, it continues at too high rate even if lost rexmits >> indicate that congestion persists in successive windows of data. And >> worse, it is successful because it pushes away other compatible TCP >> flows by being too aggressive and unfair. >> >> Even a single shot burst every time there is significant loss >> event is not acceptable, not to mention continuous aggressiveness, and >> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn >> about. >> >> Are we ignoring these BCPs that have IETF consensus? >> >> And the other important question I'd like to have an answer: >> >> What is the justification to modify standard TCP congestion control to >> use fast recovery instead of slow start for a case where timeout is >> needed to detect the packet losses because there is no feedback and ack >> clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4.1. >> >> As I noted: based on what is written in the draft it does not intend to >> change congestion control but effectively it does. >> >> /Markku >> >> > Martin >> > >> > >> > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo >> > wrote: >> > Hi Martin, >> > >> > On Tue, 15 Dec 2020, Martin Duke wrote: >> > >> > > Hi Markku, >> > > >> > > Thanks for the comments. The authors will incorporate >> > many of your >> > > suggestions after the IESG review. >> > > >> > > There's one thing I don't understand in your comments: >> > > >> > > " That is, >> > > where can an implementer find advice for correct >> > congestion control >> > > actions with RACK-TLP, when: >> > > >> > > (1) a loss of rexmitted segment is detected >> > > (2) an entire flight of data gets dropped (and detected), >> > > that is, when there is no feedback available and a >> > timeout >> > > is needed to detect the loss " >> > > >> > > Section 9.3 is the discussion about CC, and is clear that >> > the >> > > implementer should use either 5681 or 6937. >> > >> > Just a cite nit: RFC 5681 provides basic CC concepts and >> > some useful CC >> > guidelines but given that RACK-TLP MUST implement SACK the >> > algorithm in >> > RFC 5681 is not that useful and an implementer quite likely >> > follows >> > mainly the algorithm in RFC 6675 (and not RFC 6937 at all >> > if not >> > implementing PRR). >> > And RFC 6675 is not mentioned in Sec 9.3, though it is >> > listed in the >> > Sec. 4 (Requirements). >> > >> > > You went through the 6937 case in detail. >> > >> > Yes, but without correct CC actions. >> > >> > > If 5681, it's pretty clear to me that in (1) this is a >> > new loss >> > > detection after acknowledgment of new data, and therefore >> > requires a >> > > second halving of cwnd. >> > >> > Hmm, not sure what you mean by "this is a new loss >> > detection after >> > acknowledgment of new data"? >> > But anyway, RFC 5681 gives the general principle to reduce >> > cwnd and >> > ssthresh twice if a retransmission is lost but IMHO (and I >> > believe many >> > who have designed new loss recovery and CC algorithms or >> > implemented them >> > agree) that it is hard to get things right if only >> > congestion control >> > principles are available and no algorithm. >> > That's why ALL mechanisms that we have include a quite >> > detailed algorithm >> > with all necessary variables and actions for loss recovery >> > and/or CC >> > purposes (and often also pseudocode). Like this document >> > does for loss >> > detection. >> > >> > So the problem is that we do not have a detailed enough >> > algorithm or >> > rule that tells exactly what to do when a loss of rexmit is >> > detected. >> > Even worse, the algorithms in RFC 5681 and RFC 6675 refer >> > to >> > equation (4) of RFC 5681 to reduce ssthresh and cwnd when a >> > loss >> > requiring a congestion control action is detected: >> > >> > (cwnd =) ssthresh = FlightSize / 2) >> > >> > And RFC 5681 gives a warning not to halve cwnd in the >> > equation but >> > FlightSize. >> > >> > That is, this equation is what an implementer intuitively >> > would use >> > when reading the relevant RFCs but it gives a wrong result >> > for >> > outstanding data when in fast recovery (when the sender is >> > in >> > congestion avoidance and the equation (4) is used to halve >> > cwnd, it >> > gives a correct result). >> > More precisely, during fast recovery FlightSize is inflated >> > when new >> > data is sent and reduced when segments are cumulatively >> > Acked. >> > What the outcome is depends on the loss pattern. In the >> > worst case, >> > FlightSize is signficantly larger than in the beginning of >> > the fast >> > recovery when FlightSize was (correctly) used to determine >> > the halved >> > value for cwnd and ssthresh, i.e., equation (4) may result >> > in >> > *increasing* cwnd upon detecting a loss of a rexmitted >> > segment, instead >> > of further halving it. >> > >> > A clever implementer might have no problem to have it right >> > with some >> > thinking but I am afraid that there will be incorrect >> > implementations >> > with what is currently specified. Not all implementers have >> > spent >> > signicicant fraction of their career in solving TCP >> > peculiarities. >> > >> > > For (2), the RTO timer is still operative so >> > > the RTO recovery rules would still follow. >> > >> > In short: >> > When with a non-RACK-TLP implementation timer (RTO) >> > expires: cwnd=1 MSS, >> > and slow start is entered. >> > When with a RACK_TLP implementation timer (PTO) expires, >> > normal fast recovery is entered (unless implementing >> > also PRR). So no RTO recovery as explicitly stated in Sec. >> > 7.4.1. >> > >> > This means that this document explicitly modifies standard >> > TCP congestion >> > control when there are no acks coming and the >> > retransmission timer >> > expires >> > >> > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >> > 1. RTO timer expires >> > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one >> > segment >> > 3. Ack of rexmit sent in step 2 arrives >> > 4. cwnd = cwnd+1 MSS; send two segments >> > ... >> > >> > to: PTO=min(2*SRTT,RTO) (PRO used for arming the timer) >> > 1. PTO times expires >> > 2. (cwnd=1 MSS); (re)xmit one segment >> > 3. Ack of (re)xmit sent in srep 2 arrives >> > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd >> > segments >> > >> > For example, if FlightSize is 100 segments when timer >> > expires, >> > congestion control is the same in steps 1-3, but in step 4 >> > the >> > current standard congestion control allows transmitting 2 >> > segments, >> > while RACK-TLP would allow blasting 50 segments. >> > >> > Question is: what is the justification to modify standard >> > TCP >> > congestion control to use fast recovery instead of slow >> > start for a >> > case where timeout is needed to detect loss because there >> > is no >> > feedback and ack clock is lost? The draft does not give any >> > justification. This clearly is in conflict with items (0) >> > and (1) >> > in BCP 133 (RFC 5033). >> > >> > Furthermore, there is no implementation nor experimental >> > experience >> > evaluating this change. The implementation with >> > experimental experience >> > uses PRR (RFC 6937) which is an Experimental specification >> > including a >> > novel "trick" that directs PRR fast recovery to effectively >> > use slow >> > start in this case at hand. >> > >> > >> > > In other words, I am not seeing a case that requires new >> > congestion >> > > control concepts except as discussed in 9.3. >> > >> > See above. The change in standard congestion control for >> > (2). >> > The draft intends not to change congestion control but >> > effectively it >> > does without any operational evidence. >> > >> > What's also is missing and would be very useful: >> > >> > - For (1), a hint for an implementer saying that because >> > RACK-TLP is >> > able to detect a loss of a rexmit unlike any other loss >> > detection >> > algorithm, the sender MUST react twice to congestion >> > (and cite >> > RFC 5681). And cite a document where necessary correct >> > actions >> > are described. >> > >> > - For (1), advise that an implementer needs to keep track >> > when it >> > detects a loss of a retransmitted segment. Current >> > algorithms >> > in the draft detect a loss of retransmitted segment >> > exactly in >> > the same way as loss of any other segment. There seems >> > to be >> > nothing to track when a retransmission of a >> > retransmitted segment >> > takes place. Therefore, the algorithms should have >> > additional >> > actions to correctly track when such a loss is detected. >> > >> > - For (1), discussion on how many times a loss of a >> > retransmission >> > of the same segment may occur and be detected. Seems >> > that it >> > may be possible to drop a rexmitted segment more than >> > once and >> > detect it also several times? What are the >> > implications? >> > >> > - If previous is possible, then the algorithm possibly also >> > may detect a loss of a new segment that was sent during >> > fast >> > recovery? This is also loss in two successive windows of >> > data, >> > and cwnd MUST be lowered twice. This discussion and >> > necessary >> > actions to track it are missing, if such scenario is >> > possible. >> > >> > > What am I missing? >> > >> > Hope the above helps. >> > >> > /Markku >> > >> > >> > >> > >> > > > --0000000000008ead4f05b6a3eb70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I spent a little longer looking at the specs more careful= ly, and I explained (1) incorrectly in my last two messages. P21..29 are no= t Limited Transmit packets.=C2=A0

However, unless I'm missing something else, 6675 is clear that the = recovery period does not end until the cumulative ack advances, meaning tha= t detecting the lost retransmission of P1 does not trigger another MD direc= tly.

T= hanks for this exercise! It's refreshed my memory of these details afte= r working on slightly different QUIC algorithms a long time.

On = Wed, Dec 16, 2020, 18:55 Martin Duke <martin.h.duke@gmail.com> wrote:
(1) Flightsize: in RFC 6675. = Section 5, Step 4.2:

       (4.2) ssthresh =3D cwnd =
=3D (FlightSize / 2)

             The congestion window (cwnd) and slow start threshold
             (ssthresh) are reduced to half of FlightSize per [RFC5681].
             Additionally, note that [RF=
C5681] requires that any
             segments sent as part of the Limited Transmit mechanism not
             be counted in FlightSize for the purpose of the above
             equation.

IIUC the segments P21..P29 in your example were s= ent because of Limited Transmit, and so don't count. The flightsize for= the purposes of (4.2) is therefore 20 after both losses, and the cwnd does= not go up on the second loss.

(2)
<= /div>
" Even a single shot burst every time there is significant loss
event is not acceptable, not to mention continuous aggressiveness, and
this is exactly what RFC 2914 and RFC 5033 explicitly address and warn
about."

"Significant loss event" is= the key phrase here. The intent of TLP/PTO is to equalize the treatment of= a small packet loss whether it happened in the middle of a burst or the en= d. Why should an isolated loss be treated differently based on its position= in the burst? This is just a logical extension of fast retransmit, which a= lso modified the RTO paradigm. The working group consensus is that this is = a feature, not a bug; you're welcome to feel otherwise but I suspect yo= u're in the rough here.

Regards
= Martin


On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> w= rote:
Hi Martin,=

See inline.

On Wed, 16 Dec 2020, Martin Duke wrote:

> Hi Markku,
>
> There is a ton here, but I'll try to address the top points. Hopef= ully
> they obviate the rest.

Sorry for being verbose. I tried to be clear but you actually removed my key issues/questions ;)

> 1.
> [Markku]
> "Hmm, not sure what you mean by "this is a new loss detectio= n after
> acknowledgment of new data"?
> But anyway, RFC 5681 gives the general principle to reduce cwnd and > ssthresh twice if a retransmission is lost but IMHO (and I believe man= y
> who have designed new loss recovery and CC algorithms or implemented > them
> agree) that it is hard to get things right if only congestion control<= br> > principles are available and no algorithm."
>
> [Martin]
> So 6675 Sec 5 is quite explicit that there is only one cwnd reduction<= br> > per fast recovery episode, which ends once new data has been
> acknowledged.

To be more precise: fast recovery ends when the current window becomes
cumulatively acknowledged, that is,

(4.1) RecoveryPoint (=3D HighData at the beginning) becomes acknowledged
I believe we agree and you meant this although new data below
RecoveryPoint may become cumulatively acknowledged already earlier
during the fast recovery. Reno loss recovery in RFC 5681 ends, when
(any) new data has been acknowledged.

> By definition, if a retransmission is lost it is because
> newer data has been acknowledged, so it's a new recovery episode.<= br>
Not sure where you have this definition? Newer than what are you
referring to?

But, yes, if a retransmission is lost with RFC 6675 algorithm,
it requires RTO to be detected and definitely starts a new recovery
episode. That is, a new recovery episode is enforced by step (1.a) of
NextSeg () which prevents retransmission if a segment that has already
been retransmitted. If RACK-TLP is used for detecting loss with RFC 6675 things get different in many ways, because it may detect loss of a
retransmission. It would pretty much require an entire redesign
of the algorith. For example, calculation of pipe does not consider
segments that have been retransmitted more than once.

> Meanwhile, during the Fast Recovery period the incoming acks implicitl= y
> remove data from the network and therefore keep flightsize low.

Incorrect. FlightSize !=3D pipe. Only cumulative acks remove data from
FlightSize and new data transmitted during fast recovery inflate
FlightSize. How FlightSize evolves depends on loss pattern as I said.
It is also possible that FlightSize is low, it may err in both
directions. A simple example can be used as a proof for the case where
cwnd increases if a loss of retransmission is detected and repaired:

RFC 6675 recovery with RACK-TLP loss detection:
(contains some inaccuracies because it has not been defined how
lost rexmits are calculated into pipe)

cwnd=3D20; packets P1,...,P20 in flight =3D current window of data
[P1 dropped and rexmit of P1 will also be dropped]

DupAck w/SACK for P2 arrives
[loss of P1 detected after one RTT from original xmit of P1]
[cwnd=3Dssthresh=3D10]
P1 is rexmitted (and it logically starts next window of data)

DupAcks w/ SACK for original P3..11 arrive
DupAck w/ SACK for original P12 arrives
[cwnd-pipe =3D 10-9 >=3D1]
send P21
DupAck w/SACK for P13 arrives
send P22
...
DupAck w/SACK for P20 arrives
send P29
[FlightSize=3D29]

(Ack for rexmit of P1 would arrive here unless it got dropped)

DupAck w/SACK for P21 arrives
[loss of rexmit P1 detected after one RTT from rexmit of P1]

SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5

CWND INCREASES when it should be at most 5 after halving it twice!!!

> We can continue to go around on our interpretation of these documents,=
> but fundamentally if there is ambiguity in 5681/6675 we should bis
> those RFCs rather than expand the scope of RACK.

As I said earlier, I am not opposing bis, though 5681bis wuold not
be needed, I think.

But let me repeat: if we publish RACK-TLP now without necessary warnings or with a correct congesion control algorithm someone will try to
implement RACK-TLP with RFC 6675 and it will be a total mesh. The
behavior will be unpredictable and quite likely unsafe congestion
control behavior.

> 2.
> [Markku]
> " In short:
> When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1<= br> > MSS,
> and slow start is entered.
> When with a RACK_TLP implementation timer (PTO) expires,
> normal fast recovery is entered (unless implementing
> also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1."= ;
>
> [Martin]
> There may be a misunderstanding here. PTO is not the same as RTO, and<= br> > both mechanisms exist! The loss response to a PTO is to send a probe;<= br> > the RTO response is as with conventional TCP. In Section 7.3:

No, I don't think I misunderstood. If you call timeout with
another name, it is still timeout. And congestion control does not
consider which segments to send (SND.UNA vs. probe w/ higher sequence
number), only how much is sent.

You ignored my major point where I decoupled congestion control from loss <= br> detection and loss recovery and compared RFC 5681 behavior to RACK-TLP
behavior in exactly the same scenario where an entire flight is lost and timer expires.

Please comment why congestion control behavior is allowed to be radically <= br> different in these two implementations?

RFC 5681 & RFC 6298 timeout:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTTVAR (RTO used for arming the ti= mer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit= one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
=C2=A0 =C2=A0 =C2=A0 =C2=A0...

RACK-TLP timeout:

=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PTO used for arming= the timer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3D= cwnd segments

If FlightSize is 100 segments when timer expires, congestion control is the same in steps 1-3, but in step 4 the standard congestion control
allows transmitting 2 segments, while RACK-TLP would allow
blasting 50 segments.

> After attempting to send a loss probe, regardless of whether a loss >=C2=A0 =C2=A0 probe was sent, the sender MUST re-arm the RTO timer, not= the PTO
>=C2=A0 =C2=A0 timer, if FlightSize is not zero.=C2=A0 This ensures RTO = recovery remains
>=C2=A0 =C2=A0 the last resort if TLP fails.
> "

This does not prevent the above RACK-TLP behavior from getting realized.
> So a pure RTO response exists in the case of persistent congestion tha= t
> causes losses of probes or their ACKs.

Yes, RTO response exists BUT only after RACK-TLP at least once blasts the <= br> network. It may well be that with smaller windows RACK-TLP is successful during its TLP initiated overly aggressive "fast recovery" and ne= ver
enters RTO recovery because it may detect and repair also loss of
rexmits. That is, it continues at too high rate even if lost rexmits
indicate that congestion persists in successive windows of data. And
worse, it is successful because it pushes away other compatible TCP
flows by being too aggressive and unfair.

Even a single shot burst every time there is significant loss
event is not acceptable, not to mention continuous aggressiveness, and
this is exactly what RFC 2914 and RFC 5033 explicitly address and warn
about.

Are we ignoring these BCPs that have IETF consensus?

And the other important question I'd like to have an answer:

What is the justification to modify standard TCP congestion control to
use fast recovery instead of slow start for a case where timeout is
needed to detect the packet losses because there is no feedback and ack clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4.1.

As I noted: based on what is written in the draft it does not intend to change congestion control but effectively it does.

/Markku

> Martin
>
>
> On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo <kojo@cs.helsinki.fi>
> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks for the comments. The authors wi= ll incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggestions after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There's one thing I don't under= stand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " That is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where can an implementer find advice fo= r correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a loss of rexmitted segment is dete= cted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an entire flight of data gets dropp= ed (and detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0that is, when there= is no feedback available and a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0is needed to detect= the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section 9.3 is the discussion about CC,= and is clear that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implementer should use either 5681 or 6= 937.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite nit: RFC 5681 provides basic CC = concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines but given that RACK-TLP MUST impl= ement SACK the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is not that useful and an implement= er quite likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the algorithm in RFC 6675 (and not RF= C 6937 at all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 is not mentioned in Sec 9.3, th= ough it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requirements).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went through the 6937 case in detai= l.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but without correct CC actions.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681, it's pretty clear to me th= at in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detection after acknowledgment of new d= ata, and therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second halving of cwnd.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure what you mean by "this is= a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, RFC 5681 gives the general princ= iple to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twice if a retransmission is lost b= ut IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have designed new loss recovery and CC a= lgorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that it is hard to get things right i= f only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles are available and no algorithm. >=C2=A0 =C2=A0 =C2=A0 =C2=A0That's why ALL mechanisms that we have i= nclude a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algorithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all necessary variables and actions for= loss recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and often also pseudocode). Like t= his document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the problem is that we do not have a deta= iled enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tells exactly what to do when a lo= ss of rexmit is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, the algorithms in RFC 5681 and R= FC 6675 refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) of RFC 5681 to reduce ssthresh = and cwnd when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a congestion control action is det= ected:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd =3D) ssthresh =3D FlightSize / = 2)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 gives a warning not to halve cw= nd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this equation is what an implemente= r intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading the relevant RFCs but it gives = a wrong result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding data when in fast recovery (when= the sender is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion avoidance and the equation (4) is= used to halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a correct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisely, during fast recovery FlightS= ize is inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent and reduced when segments are c= umulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outcome is depends on the loss patt= ern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is signficantly larger than in th= e beginning of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when FlightSize was (correctly) use= d to determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved
>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwnd and ssthresh, i.e., equation = (4) may result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* cwnd upon detecting a loss of a= rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, instead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further halving it.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever implementer might have no problem t= o have it right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but I am afraid that there will be = incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementations
>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is currently specified. Not all im= plementers have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant fraction of their career in solv= ing TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2), the RTO timer is still operati= ve so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO recovery rules would still foll= ow.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a non-RACK-TLP implementation time= r (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd=3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a RACK_TLP implementation timer (P= TO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast recovery is entered (unless impl= ementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So no RTO recovery as explicitly = stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means that this document explicitly mod= ifies standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when there are no acks coming and th= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DSRTT+4*RTTVAR (RTO used for armi= ng the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO u= sed for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, if FlightSize is 100 segments w= hen timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control is the same in steps 1-3,= but in step 4
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0current standard congestion control allows t= ransmitting 2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TLP would allow blasting 50 segme= nts.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: what is the justification to mo= dify standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control to use fast recovery inst= ead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where timeout is needed to detect loss = because there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and ack clock is lost? The draft do= es not give any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification. This clearly is in conflict w= ith items (0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (RFC 5033).
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, there is no implementation nor = experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating this change. The implementation w= ith
>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC 6937) which is an Experimental= specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "trick" that directs PRR fas= t recovery to effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this case at hand.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other words, I am not seeing a case = that requires new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control concepts except as discussed in= 9.3.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. The change in standard congestion= control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft intends not to change congestion c= ontrol but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without any operational evidence.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's also is missing and would be very= useful:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a hint for an implementer saying = that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0able to detect a loss of a rexm= it unlike any other loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0algorithm, the sender MUST reac= t twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0RFC 5681). And cite a document = where necessary correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0are described.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), advise that an implementer needs = to keep track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detects a loss of a retransmitt= ed segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0in the draft detect a loss of r= etransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the same way as loss of any oth= er segment. There seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0nothing to track when a retrans= mission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0takes place. Therefore, the alg= orithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to correctly track when= such a loss is detected.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), discussion on how many times a lo= ss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of the same segment may occur a= nd be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may be possible to drop a rexmi= tted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detect it also several times?= =C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous is possible, then the algorith= m possibly also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may detect a loss of a new segm= ent that was sent during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0recovery? This is also loss in = two successive windows of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and cwnd MUST be lowered twice.= This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to track it are missing= , if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am I missing?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the above helps.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>
> <snipping the rest>
>
>
--0000000000008ead4f05b6a3eb70-- From nobody Wed Dec 16 23:53:58 2020 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 76C2F3A152C; Wed, 16 Dec 2020 23:53:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160819163601.18444.15133884751875574217@ietfa.amsl.com> Date: Wed, 16 Dec 2020 23:53:56 -0800 Archived-At: Subject: [tcpm] Murray Kucherawy's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 07:53:57 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-tcpm-rack-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this work. It's interesting stuff! Please expand DUPACK on first use. Section 2 is curious. As I read it, it establishes a normative recommendation to use it, but doesn't update either of its antecedents (RFC 5681 or RFC 6675) such that someone reading those might be referred to this. From nobody Thu Dec 17 00:18:10 2020 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 6A9FF3A160B; Thu, 17 Dec 2020 00:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 wg77modX0pee; Thu, 17 Dec 2020 00:17:56 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9403A15A6; Thu, 17 Dec 2020 00:17:48 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 17 Dec 2020 10:17:44 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=x5zX37XAgwZsLmjuB 69IXZnhm8pOUszdNJp6T440JpE=; b=ILETRXXWDu/hgaZOCNHJC1nyEVNpjw2A7 gXzpsbB/fbDMj/dYw5qI61vww89GWRDPD1oLByUqJBECFYkZQz2VuBGP8068Qmkg d8BqUpDOSezaWOY5pgls/6hSfVHk/Z2wfoPvnvhhiDGlsqx486vLy8Wug1jJIG3B Y4iDon3qCE= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 17 Dec 2020 10:17:44 +0200 id 00000000005A0932.000000005FDB1428.0000246F Date: Thu, 17 Dec 2020 10:17:43 +0200 (EET) From: Markku Kojo To: Martin Duke cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-9353-1608193064-0001-2" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 08:18:05 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-9353-1608193064-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Martin, On Wed, 16 Dec 2020, Martin Duke wrote: > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > (4.2) ssthresh =3D cwnd =3D (FlightSize / 2) > > The congestion window (cwnd) and slow start threshold > (ssthresh) are reduced to half of FlightSize per [RFC5681]= . > Additionally, note that [RFC5681] requires that any > segments sent as part of the Limited Transmit mechanism no= t > be counted in FlightSize for the purpose of the above > equation. >=20 > IIUC the segments P21..P29 in your example were sent because of Limited = Transmit, > and so don't count. The flightsize for the purposes of (4.2) is therefo= re 20 after > both losses, and the cwnd does not go up on the second loss. Incorrect. (And you corrected this in your later reply) > (2) > " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > about." >=20 > "Significant loss event" is the key phrase here. The intent of TLP/PTO = is to > equalize the treatment of a small packet loss whether it happened in th= e middle of > a burst or the end. Why should an isolated loss be treated differently = based on > its position in the burst? This is just a logical extension of fast ret= ransmit, > which also modified the RTO paradigm. The working group consensus is th= at this is > a feature, not a bug; you're welcome to feel otherwise but I suspect yo= u're in the > rough here. An isolated loss in the end of flight and repairing it is handled=20 as a separate case in the draft. It is easy to have a less conservative=20 congestion control response for it, and I would be fine with that. The problem we are discussing is the "significant loss event" where=20 even a huge number of packets are lost, potentially indicating severe=20 congestion. The draft accidentally handles it the same as a small packet=20 loss. And that is wrong. Why draft handles it accidentally wrong: because RACK-TLP has never=20 been implemented with the standard congestion control (RFC 6675) but=20 with PRR and the experimental evidence presented to the working group was=20 based on the implementation with PRR. One may say that the WG was=20 *accidentally* misguided. And as I have stated many times: PRR modifies RFC 6675 congestion control=20 and includes necessary actions to handle a significant loss event=20 properly. But current standards track congestion control does not. And=20 this draft explicitly modifies standards track congestion control but=20 conceals this significant modification in Sec. 9.3 when discussing the=20 interaction with congestion control. Best regards, /Markku > Regards > Martin >=20 >=20 > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote= : > Hi Martin, > > See inline. > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > Hi Markku, > > > > There is a ton here, but I'll try to address the top points. > Hopefully > > they obviate the rest. > > Sorry for being verbose. I tried to be clear but you actually rem= oved > my > key issues/questions ;) > > > 1. > > [Markku] > > "Hmm, not sure what you mean by "this is a new loss detection a= fter > > acknowledgment of new data"? > > But anyway, RFC 5681 gives the general principle to reduce cwnd = and > > ssthresh twice if a retransmission is lost but IMHO (and I beli= eve > many > > who have designed new loss recovery and CC algorithms or implem= ented > > them > > agree) that it is hard to get things right if only congestion > control > > principles are available and no algorithm." > > > > [Martin] > > So 6675 Sec 5 is quite explicit that there is only one cwnd > reduction > > per fast recovery episode, which ends once new data has been > > acknowledged. > > To be more precise: fast recovery ends when the current window be= comes > cumulatively acknowledged, that is, > > (4.1) RecoveryPoint (=3D HighData at the beginning) becomes ackno= wledged > > I believe we agree and you meant this although new data below > RecoveryPoint may become cumulatively acknowledged already earlie= r > during the fast recovery. Reno loss recovery in RFC 5681 ends, wh= en > (any) new data has been acknowledged. > > > By definition, if a retransmission is lost it is because > > newer data has been acknowledged, so it's a new recovery episod= e. > > Not sure where you have this definition? Newer than what are you > referring to? > > But, yes, if a retransmission is lost with RFC 6675 algorithm, > it requires RTO to be detected and definitely starts a new recove= ry > episode. That is, a new recovery episode is enforced by step (1.a= ) of > NextSeg () which prevents retransmission if a segment that has al= ready > been retransmitted. If RACK-TLP is used for detecting loss with R= FC > 6675 > things get different in many ways, because it may detect loss of = a > retransmission. It would pretty much require an entire redesign > of the algorith. For example, calculation of pipe does not consid= er > segments that have been retransmitted more than once. > > > Meanwhile, during the Fast Recovery period the incoming acks > implicitly > > remove data from the network and therefore keep flightsize low. > > Incorrect. FlightSize !=3D pipe. Only cumulative acks remove data = from > FlightSize and new data transmitted during fast recovery inflate > FlightSize. How FlightSize evolves depends on loss pattern as I s= aid. > It is also possible that FlightSize is low, it may err in both > directions. A simple example can be used as a proof for the case = where > cwnd increases if a loss of retransmission is detected and repair= ed: > > RFC 6675 recovery with RACK-TLP loss detection: > (contains some inaccuracies because it has not been defined how > lost rexmits are calculated into pipe) > > cwnd=3D20; packets P1,...,P20 in flight =3D current window of dat= a > [P1 dropped and rexmit of P1 will also be dropped] > > DupAck w/SACK for P2 arrives > [loss of P1 detected after one RTT from original xmit of P1] > [cwnd=3Dssthresh=3D10] > P1 is rexmitted (and it logically starts next window of data) > > DupAcks w/ SACK for original P3..11 arrive > DupAck w/ SACK for original P12 arrives > [cwnd-pipe =3D 10-9 >=3D1] > send P21 > DupAck w/SACK for P13 arrives > send P22 > ... > DupAck w/SACK for P20 arrives > send P29 > [FlightSize=3D29] > > (Ack for rexmit of P1 would arrive here unless it got dropped) > > DupAck w/SACK for P21 arrives > [loss of rexmit P1 detected after one RTT from rexmit of P1] > > SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5 > > CWND INCREASES when it should be at most 5 after halving it twice= !!! > > > We can continue to go around on our interpretation of these > documents, > > but fundamentally if there is ambiguity in 5681/6675 we should = bis > > those RFCs rather than expand the scope of RACK. > > As I said earlier, I am not opposing bis, though 5681bis wuold no= t > be needed, I think. > > But let me repeat: if we publish RACK-TLP now without necessary > warnings > or with a correct congesion control algorithm someone will try to > implement RACK-TLP with RFC 6675 and it will be a total mesh. The > behavior will be unpredictable and quite likely unsafe congestion > control behavior. > > > 2. > > [Markku] > > " In short: > > When with a non-RACK-TLP implementation timer (RTO) expires: cw= nd=3D1 > > MSS, > > and slow start is entered. > > When with a RACK_TLP implementation timer (PTO) expires, > > normal fast recovery is entered (unless implementing > > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.= 1." > > > > [Martin] > > There may be a misunderstanding here. PTO is not the same as RT= O, > and > > both mechanisms exist! The loss response to a PTO is to send a > probe; > > the RTO response is as with conventional TCP. In Section 7.3: > > No, I don't think I misunderstood. If you call timeout with > another name, it is still timeout. And congestion control does no= t > consider which segments to send (SND.UNA vs. probe w/ higher sequ= ence > number), only how much is sent. > > You ignored my major point where I decoupled congestion control f= rom > loss > detection and loss recovery and compared RFC 5681 behavior to RAC= K-TLP > behavior in exactly the same scenario where an entire flight is l= ost > and > timer expires. > > Please comment why congestion control behavior is allowed to be > radically > different in these two implementations? > > RFC 5681 & RFC 6298 timeout: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTTVAR (RTO used for arm= ing the timer) > =C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires > =C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize= /2; rexmit one segment > =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrive= s > =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segme= nts > =C2=A0 =C2=A0 =C2=A0 =C2=A0... > > RACK-TLP timeout: > > =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PTO used = for arming the timer) > =C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires > =C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segmen= t > =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arri= ves > =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; = send N=3Dcwnd segments > > If FlightSize is 100 segments when timer expires, congestion cont= rol > is > the same in steps 1-3, but in step 4 the standard congestion cont= rol > allows transmitting 2 segments, while RACK-TLP would allow > blasting 50 segments. > > > After attempting to send a loss probe, regardless of whether a = loss > >=C2=A0 =C2=A0 probe was sent, the sender MUST re-arm the RTO tim= er, not the PTO > >=C2=A0 =C2=A0 timer, if FlightSize is not zero.=C2=A0 This ensur= es RTO recovery > remains > >=C2=A0 =C2=A0 the last resort if TLP fails. > > " > > This does not prevent the above RACK-TLP behavior from getting > realized. > > > So a pure RTO response exists in the case of persistent congest= ion > that > > causes losses of probes or their ACKs. > > Yes, RTO response exists BUT only after RACK-TLP at least once bl= asts > the > network. It may well be that with smaller windows RACK-TLP is > successful > during its TLP initiated overly aggressive "fast recovery" and ne= ver > enters RTO recovery because it may detect and repair also loss of > rexmits. That is, it continues at too high rate even if lost rexm= its > indicate that congestion persists in successive windows of data. = And > worse, it is successful because it pushes away other compatible T= CP > flows by being too aggressive and unfair. > > Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness= , and > this is exactly what RFC 2914 and RFC 5033 explicitly address and = warn > about. > > Are we ignoring these BCPs that have IETF consensus? > > And the other important question I'd like to have an answer: > > What is the justification to modify standard TCP congestion contr= ol to > use fast recovery instead of slow start for a case where timeout = is > needed to detect the packet losses because there is no feedback a= nd > ack > clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.4= .1. > > As I noted: based on what is written in the draft it does not int= end > to > change congestion control but effectively it does. > > /Markku > > > Martin > > > > > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > > wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 Dec 2020, Martin Duke wrot= e: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks for the comments. The author= s will incorporate > >=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggestions after the IESG review. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> There's one thing I don't understan= d in your comments: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> " That is, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> where can an implementer find advic= e for correct > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions with RACK-TLP, when: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a loss of rexmitted segment is = detected > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an entire flight of data gets d= ropped (and detected), > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0that is, when t= here is no feedback available and a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0is needed to de= tect the loss " > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section 9.3 is the discussion about = CC, and is clear that > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> implementer should use either 5681 = or 6937. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite nit: RFC 5681 provides ba= sic CC concepts and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful CC > >=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines but given that RACK-TLP MU= ST implement SACK the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is not that useful and an im= plementer quite likely > >=C2=A0 =C2=A0 =C2=A0 =C2=A0follows > >=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the algorithm in RFC 6675 (and = not RFC 6937 at all > >=C2=A0 =C2=A0 =C2=A0 =C2=A0if not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing PRR). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 is not mentioned in Sec = 9.3, though it is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requirements). > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went through the 6937 case in d= etail. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but without correct CC actions. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681, it's pretty clear to me th= at in (1) this is a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> detection after acknowledgment of n= ew data, and therefore > >=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> second halving of cwnd. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure what you mean by "this = is a new loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection after > >=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgment of new data"? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, RFC 5681 gives the genera= l principle to reduce > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twice if a retransmission is = lost but IMHO (and I > >=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many > >=C2=A0 =C2=A0 =C2=A0 =C2=A0who have designed new loss recovery a= nd CC algorithms or > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented them > >=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that it is hard to get things = right if only > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0principles are available and no algor= ithm. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0That's why ALL mechanisms that we hav= e include a quite > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algorithm > >=C2=A0 =C2=A0 =C2=A0 =C2=A0with all necessary variables and acti= ons for loss recovery > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC > >=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and often also pseudocode). = Like this document > >=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0So the problem is that we do not have = a detailed enough > >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tells exactly what to do wh= en a loss of rexmit is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detected. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, the algorithms in RFC 568= 1 and RFC 6675 refer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) of RFC 5681 to reduce ss= thresh and cwnd when a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a congestion control action = is detected: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd =3D) ssthresh =3D Flight= Size / 2) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 gives a warning not to h= alve cwnd in the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but > >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this equation is what an imp= lementer intuitively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0would use > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading the relevant RFCs but it = gives a wrong result > >=C2=A0 =C2=A0 =C2=A0 =C2=A0for > >=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding data when in fast recover= y (when the sender is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion avoidance and the equation = (4) is used to halve > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a correct result). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisely, during fast recovery = FlightSize is inflated > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when new > >=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent and reduced when segment= s are cumulatively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outcome is depends on the lo= ss pattern. In the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is signficantly larger tha= n in the beginning of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast > >=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when FlightSize was (correct= ly) used to determine > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved > >=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwnd and ssthresh, i.e., eq= uation (4) may result > >=C2=A0 =C2=A0 =C2=A0 =C2=A0in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* cwnd upon detecting a lo= ss of a rexmitted > >=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, instead > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of further halving it. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever implementer might have no pr= oblem to have it right > >=C2=A0 =C2=A0 =C2=A0 =C2=A0with some > >=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but I am afraid that there w= ill be incorrect > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implementations > >=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is currently specified. Not = all implementers have > >=C2=A0 =C2=A0 =C2=A0 =C2=A0spent > >=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant fraction of their career = in solving TCP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2), the RTO timer is still ope= rative so > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO recovery rules would still = follow. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0In short: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a non-RACK-TLP implementati= on timer (RTO) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd=3D1 MSS, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow start is entered. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a RACK_TLP implementation t= imer (PTO) expires, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast recovery is entered (unle= ss implementing > >=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So no RTO recovery as expl= icitly stated in Sec. > >=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0This means that this document explici= tly modifies standard > >=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control when there are no acks coming = and the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission timer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DSRTT+4*RTTVAR (RTO used f= or arming the timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO tim= er expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D= 1 MSS; ssthresh=3DFlightSize/2; rexmit one > >=C2=A0 =C2=A0 =C2=A0 =C2=A0segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = rexmit sent in step 2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = cwnd+1 MSS; send two segments > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0... > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) = (PRO used for arming the timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO tim= es expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D= 1 MSS); (re)xmit one segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = (re)xmit sent in srep 2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = ssthresh =3D FlightSize/2; send N=3Dcwnd > >=C2=A0 =C2=A0 =C2=A0 =C2=A0segments > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, if FlightSize is 100 seg= ments when timer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control is the same in ste= ps 1-3, but in step 4 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0current standard congestion control a= llows transmitting 2 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0segments, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TLP would allow blasting 5= 0 segments. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: what is the justificatio= n to modify standard > >=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control to use fast recove= ry instead of slow > >=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0case where timeout is needed to detec= t loss because there > >=C2=A0 =C2=A0 =C2=A0 =C2=A0is no > >=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and ack clock is lost? The d= raft does not give any > >=C2=A0 =C2=A0 =C2=A0 =C2=A0justification. This clearly is in con= flict with items (0) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (RFC 5033). > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, there is no implementati= on nor experimental > >=C2=A0 =C2=A0 =C2=A0 =C2=A0experience > >=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating this change. The implement= ation with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental experience > >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC 6937) which is an Exper= imental specification > >=C2=A0 =C2=A0 =C2=A0 =C2=A0including a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "trick" that directs PRR fast r= ecovery to effectively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow > >=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this case at hand. > > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other words, I am not seeing a c= ase that requires new > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> control concepts except as discusse= d in 9.3. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. The change in standard con= gestion control for > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(2). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft intends not to change conge= stion control but > >=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0does without any operational evidence= . > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0What's also is missing and would be v= ery useful: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a hint for an implementer = saying that because > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0able to detect a loss of = a rexmit unlike any other loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0algorithm, the sender MU= ST react twice to congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0RFC 5681). And cite a do= cument where necessary correct > >=C2=A0 =C2=A0 =C2=A0 =C2=A0actions > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0are described. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), advise that an implementer = needs to keep track > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detects a loss of a retr= ansmitted segment. Current > >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0in the draft detect a lo= ss of retransmitted segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the same way as loss of = any other segment. There seems > >=C2=A0 =C2=A0 =C2=A0 =C2=A0to be > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0nothing to track when a = retransmission of a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0takes place. Therefore, = the algorithms should have > >=C2=A0 =C2=A0 =C2=A0 =C2=A0additional > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to correctly tra= ck when such a loss is detected. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), discussion on how many tim= es a loss of a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of the same segment may = occur and be detected. Seems > >=C2=A0 =C2=A0 =C2=A0 =C2=A0that it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may be possible to drop = a rexmitted segment more than > >=C2=A0 =C2=A0 =C2=A0 =C2=A0once and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detect it also several t= imes?=C2=A0 What are the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implications? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous is possible, then the a= lgorithm possibly also > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may detect a loss of a n= ew segment that was sent during > >=C2=A0 =C2=A0 =C2=A0 =C2=A0fast > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0recovery? This is also l= oss in two successive windows of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0data, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and cwnd MUST be lowered = twice. This discussion and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to track it are = missing, if such scenario is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0possible. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am I missing? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the above helps. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku > > > > > > > > > > >=20 >=20 > --=_script-9353-1608193064-0001-2-- From nobody Thu Dec 17 00:47:06 2020 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 18B343A1560; Thu, 17 Dec 2020 00:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 6cc6P7rTLI_d; Thu, 17 Dec 2020 00:46:59 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E940E3A1553; Thu, 17 Dec 2020 00:46:57 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 17 Dec 2020 10:46:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=ngc1Ya HG9iehNnjUzH54LVTPg1wsg3BCJAxYkrqFDw8=; b=fzGD1WAcG9+TCqfvydk04/ qytT+7fCpckHwFILWXqa4N28QZPgMCV5yhgedIbSN+bPQNnomjs95qs8k155QIoW eFcnrPDFhl4APTpOQ/BlPUjzym1EjVCzTeNVr1mrRRGGb2I8y4v2iRCGYTCuVOQ0 /6l2mJUfsRaq1ywy5hxfk= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 17 Dec 2020 10:46:53 +0200 id 00000000005A0932.000000005FDB1AFD.00006ADE Date: Thu, 17 Dec 2020 10:46:53 +0200 (EET) From: Markku Kojo To: Martin Duke cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-27384-1608194813-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 08:47:02 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-27384-1608194813-0001-2 Content-Type: text/plain; charset="iso-8859-15"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi, On Wed, 16 Dec 2020, Martin Duke wrote: > I spent a little longer looking at the specs more carefully, and I expl= ained (1) > incorrectly in my last two messages. P21..29 are not Limited Transmit p= ackets.=A0 Correct. Just normal the rule that allows sending new data during fast=20 recovery. > However, unless I'm missing something else, 6675 is clear that the reco= very period > does not end until the cumulative ack advances, meaning that detecting = the lost > retransmission of P1 does not trigger another MD directly. As I have said earlier, RFC 6675 does not repeat all congestion control=20 principles from RFC 5681. It definitely honors the CC principle that requires to treat a loss of a retransmission as a new congestion=20 indication and another MD. I believe I am obligated to know this as a=20 co-author of RFC 6675. ;) RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the=20 abstract: " ... conforms to the spirit of the current congestion control specification (RFC 5681 ..." And in the intro: "The algorithm specified in this document is a straightforward SACK-based loss recovery strategy that follows the guidelines set in [RFC5681] ..." I don't think there is anything unclear in this. RFC 6675 and all other standard congestion controls (RFC 5581 and RFC=20 6582) handle a loss of a retransmission by "enforcing" RTO to detect it.=20 And RTO guarantees MD. RACK-TLP changes the loss detection in this case=20 and therefore the standard congestion control algorithms do not have=20 actions to handle it corrrectly. That is the point. BR, /Markku > Thanks for this exercise! It's refreshed my memory of these details aft= er working > on slightly different QUIC algorithms a long time. >=20 > On Wed, Dec 16, 2020, 18:55 Martin Duke wrote= : > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > (4.2) ssthresh =3D cwnd =3D (FlightSize / 2) > > The congestion window (cwnd) and slow start threshold > (ssthresh) are reduced to half of FlightSize per [RFC5681]= . > Additionally, note that [RFC5681] requires that any > segments sent as part of the Limited Transmit mechanism no= t > be counted in FlightSize for the purpose of the above > equation. >=20 > IIUC the segments P21..P29 in your example were sent because of Limited > Transmit, and so don't count. The flightsize for the purposes of (4.2) = is > therefore 20 after both losses, and the cwnd does not go up on the seco= nd > loss. >=20 > (2) > " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > about." >=20 > "Significant loss event" is the key phrase here. The intent of TLP/PTO = is to > equalize the treatment of a small packet loss whether it happened in th= e > middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical > extension of fast retransmit, which also modified the RTO paradigm. The > working group consensus is that this is a feature, not a bug; you're we= lcome > to feel otherwise but I suspect you're in the rough here. >=20 > Regards > Martin >=20 >=20 > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote= : > Hi Martin, > > See inline. > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > Hi Markku, > > > > There is a ton here, but I'll try to address the top points. > Hopefully > > they obviate the rest. > > Sorry for being verbose. I tried to be clear but you actually > removed my > key issues/questions ;) > > > 1. > > [Markku] > > "Hmm, not sure what you mean by "this is a new loss detection > after > > acknowledgment of new data"? > > But anyway, RFC 5681 gives the general principle to reduce > cwnd and > > ssthresh twice if a retransmission is lost but IMHO (and I > believe many > > who have designed new loss recovery and CC algorithms or > implemented > > them > > agree) that it is hard to get things right if only congestion > control > > principles are available and no algorithm." > > > > [Martin] > > So 6675 Sec 5 is quite explicit that there is only one cwnd > reduction > > per fast recovery episode, which ends once new data has been > > acknowledged. > > To be more precise: fast recovery ends when the current window > becomes > cumulatively acknowledged, that is, > > (4.1) RecoveryPoint (=3D HighData at the beginning) becomes > acknowledged > > I believe we agree and you meant this although new data below > RecoveryPoint may become cumulatively acknowledged already > earlier > during the fast recovery. Reno loss recovery in RFC 5681 ends, > when > (any) new data has been acknowledged. > > > By definition, if a retransmission is lost it is because > > newer data has been acknowledged, so it's a new recovery > episode. > > Not sure where you have this definition? Newer than what are you > referring to? > > But, yes, if a retransmission is lost with RFC 6675 algorithm, > it requires RTO to be detected and definitely starts a new > recovery > episode. That is, a new recovery episode is enforced by step > (1.a) of > NextSeg () which prevents retransmission if a segment that has > already > been retransmitted. If RACK-TLP is used for detecting loss with > RFC 6675 > things get different in many ways, because it may detect loss of > a > retransmission. It would pretty much require an entire redesign > of the algorith. For example, calculation of pipe does not > consider > segments that have been retransmitted more than once. > > > Meanwhile, during the Fast Recovery period the incoming acks > implicitly > > remove data from the network and therefore keep flightsize > low. > > Incorrect. FlightSize !=3D pipe. Only cumulative acks remove data > from > FlightSize and new data transmitted during fast recovery inflate > FlightSize. How FlightSize evolves depends on loss pattern as I > said. > It is also possible that FlightSize is low, it may err in both > directions. A simple example can be used as a proof for the case > where > cwnd increases if a loss of retransmission is detected and > repaired: > > RFC 6675 recovery with RACK-TLP loss detection: > (contains some inaccuracies because it has not been defined how > lost rexmits are calculated into pipe) > > cwnd=3D20; packets P1,...,P20 in flight =3D current window of dat= a > [P1 dropped and rexmit of P1 will also be dropped] > > DupAck w/SACK for P2 arrives > [loss of P1 detected after one RTT from original xmit of P1] > [cwnd=3Dssthresh=3D10] > P1 is rexmitted (and it logically starts next window of data) > > DupAcks w/ SACK for original P3..11 arrive > DupAck w/ SACK for original P12 arrives > [cwnd-pipe =3D 10-9 >=3D1] > send P21 > DupAck w/SACK for P13 arrives > send P22 > ... > DupAck w/SACK for P20 arrives > send P29 > [FlightSize=3D29] > > (Ack for rexmit of P1 would arrive here unless it got dropped) > > DupAck w/SACK for P21 arrives > [loss of rexmit P1 detected after one RTT from rexmit of P1] > > SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5 > > CWND INCREASES when it should be at most 5 after halving it > twice!!! > > > We can continue to go around on our interpretation of these > documents, > > but fundamentally if there is ambiguity in 5681/6675 we should > bis > > those RFCs rather than expand the scope of RACK. > > As I said earlier, I am not opposing bis, though 5681bis wuold > not > be needed, I think. > > But let me repeat: if we publish RACK-TLP now without necessary > warnings > or with a correct congesion control algorithm someone will try > to > implement RACK-TLP with RFC 6675 and it will be a total mesh. > The > behavior will be unpredictable and quite likely unsafe > congestion > control behavior. > > > 2. > > [Markku] > > " In short: > > When with a non-RACK-TLP implementation timer (RTO) expires: > cwnd=3D1 > > MSS, > > and slow start is entered. > > When with a RACK_TLP implementation timer (PTO) expires, > > normal fast recovery is entered (unless implementing > > also PRR). So no RTO recovery as explicitly stated in Sec. > 7.4.1." > > > > [Martin] > > There may be a misunderstanding here. PTO is not the same as > RTO, and > > both mechanisms exist! The loss response to a PTO is to send a > probe; > > the RTO response is as with conventional TCP. In Section 7.3: > > No, I don't think I misunderstood. If you call timeout with > another name, it is still timeout. And congestion control does > not > consider which segments to send (SND.UNA vs. probe w/ higher > sequence > number), only how much is sent. > > You ignored my major point where I decoupled congestion control > from loss > detection and loss recovery and compared RFC 5681 behavior to > RACK-TLP > behavior in exactly the same scenario where an entire flight is > lost and > timer expires. > > Please comment why congestion control behavior is allowed to be > radically > different in these two implementations? > > RFC 5681 & RFC 6298 timeout: > > =A0 =A0 =A0 =A0 RTO=3DSRTT+4*RTTVAR (RTO used for arming the time= r) > =A0 =A0 =A0 =A01. RTO timer expires > =A0 =A0 =A0 =A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit o= ne segment > =A0 =A0 =A0 =A03. Ack of rexmit sent in step 2 arrives > =A0 =A0 =A0 =A04. cwnd =3D cwnd+1 MSS; send two segments > =A0 =A0 =A0 =A0... > > RACK-TLP timeout: > > =A0 =A0 =A0=A0 =A0PTO=3Dmin(2*SRTT,RTO) (PTO used for arming the = timer) > =A0 =A0 =A0 =A01. PTO times expires > =A0 =A0 =A0 =A02. (cwnd=3D1 MSS); (re)xmit one segment > =A0 =A0 =A0 =A03. Ack of (re)xmit sent in srep 2 arrives > =A0 =A0 =A0 =A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcw= nd segments > > If FlightSize is 100 segments when timer expires, congestion > control is > the same in steps 1-3, but in step 4 the standard congestion > control > allows transmitting 2 segments, while RACK-TLP would allow > blasting 50 segments. > > > After attempting to send a loss probe, regardless of whether a > loss > >=A0 =A0 probe was sent, the sender MUST re-arm the RTO timer, no= t > the PTO > >=A0 =A0 timer, if FlightSize is not zero.=A0 This ensures RTO > recovery remains > >=A0 =A0 the last resort if TLP fails. > > " > > This does not prevent the above RACK-TLP behavior from getting > realized. > > > So a pure RTO response exists in the case of persistent > congestion that > > causes losses of probes or their ACKs. > > Yes, RTO response exists BUT only after RACK-TLP at least once > blasts the > network. It may well be that with smaller windows RACK-TLP is > successful > during its TLP initiated overly aggressive "fast recovery" and > never > enters RTO recovery because it may detect and repair also loss > of > rexmits. That is, it continues at too high rate even if lost > rexmits > indicate that congestion persists in successive windows of data. > And > worse, it is successful because it pushes away other compatible > TCP > flows by being too aggressive and unfair. > > Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous > aggressiveness, and > this is exactly what RFC 2914 and RFC 5033 explicitly address > and warn > about. > > Are we ignoring these BCPs that have IETF consensus? > > And the other important question I'd like to have an answer: > > What is the justification to modify standard TCP congestion > control to > use fast recovery instead of slow start for a case where timeout > is > needed to detect the packet losses because there is no feedback > and ack > clock is lost? RACK-TLP explicitly instructs to do so in Sec. > 7.4.1. > > As I noted: based on what is written in the draft it does not > intend to > change congestion control but effectively it does. > > /Markku > > > Martin > > > > > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > > > wrote: > >=A0 =A0 =A0 =A0Hi Martin, > > > >=A0 =A0 =A0 =A0On Tue, 15 Dec 2020, Martin Duke wrote: > > > >=A0 =A0 =A0 =A0> Hi Markku, > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> Thanks for the comments. The authors will incor= porate > >=A0 =A0 =A0 =A0many of your > >=A0 =A0 =A0 =A0> suggestions after the IESG review. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> There's one thing I don't understand in your co= mments: > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> " That is, > >=A0 =A0 =A0 =A0> where can an implementer find advice for correc= t > >=A0 =A0 =A0 =A0congestion control > >=A0 =A0 =A0 =A0> actions with RACK-TLP, when: > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> (1) a loss of rexmitted segment is detected > >=A0 =A0 =A0 =A0> (2) an entire flight of data gets dropped (and > detected), > >=A0 =A0 =A0 =A0> =A0 =A0 =A0that is, when there is no feedback a= vailable and > a > >=A0 =A0 =A0 =A0timeout > >=A0 =A0 =A0 =A0> =A0 =A0 =A0is needed to detect the loss " > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> Section 9.3 is the discussion about CC, and is = clear > that > >=A0 =A0 =A0 =A0the > >=A0 =A0 =A0 =A0> implementer should use either 5681 or 6937. > > > >=A0 =A0 =A0 =A0Just a cite nit: RFC 5681 provides basic CC conce= pts and > >=A0 =A0 =A0 =A0some useful CC > >=A0 =A0 =A0 =A0guidelines but given that RACK-TLP MUST implement = SACK > the > >=A0 =A0 =A0 =A0algorithm in > >=A0 =A0 =A0 =A0RFC 5681 is not that useful and an implementer qu= ite > likely > >=A0 =A0 =A0 =A0follows > >=A0 =A0 =A0 =A0mainly the algorithm in RFC 6675 (and not RFC 693= 7 at > all > >=A0 =A0 =A0 =A0if not > >=A0 =A0 =A0 =A0implementing PRR). > >=A0 =A0 =A0 =A0And RFC 6675 is not mentioned in Sec 9.3, though = it is > >=A0 =A0 =A0 =A0listed in the > >=A0 =A0 =A0 =A0Sec. 4 (Requirements). > > > >=A0 =A0 =A0 =A0> You went through the 6937 case in detail. > > > >=A0 =A0 =A0 =A0Yes, but without correct CC actions. > > > >=A0 =A0 =A0 =A0> If 5681, it's pretty clear to me that in (1) th= is is a > >=A0 =A0 =A0 =A0new loss > >=A0 =A0 =A0 =A0> detection after acknowledgment of new data, and > therefore > >=A0 =A0 =A0 =A0requires a > >=A0 =A0 =A0 =A0> second halving of cwnd. > > > >=A0 =A0 =A0 =A0Hmm, not sure what you mean by "this is a new los= s > >=A0 =A0 =A0 =A0detection after > >=A0 =A0 =A0 =A0acknowledgment of new data"? > >=A0 =A0 =A0 =A0But anyway, RFC 5681 gives the general principle = to > reduce > >=A0 =A0 =A0 =A0cwnd and > >=A0 =A0 =A0 =A0ssthresh twice if a retransmission is lost but IM= HO (and > I > >=A0 =A0 =A0 =A0believe many > >=A0 =A0 =A0 =A0who have designed new loss recovery and CC algori= thms or > >=A0 =A0 =A0 =A0implemented them > >=A0 =A0 =A0 =A0agree) that it is hard to get things right if onl= y > >=A0 =A0 =A0 =A0congestion control > >=A0 =A0 =A0 =A0principles are available and no algorithm. > >=A0 =A0 =A0 =A0That's why ALL mechanisms that we have include a = quite > >=A0 =A0 =A0 =A0detailed algorithm > >=A0 =A0 =A0 =A0with all necessary variables and actions for loss > recovery > >=A0 =A0 =A0 =A0and/or CC > >=A0 =A0 =A0 =A0purposes (and often also pseudocode). Like this d= ocument > >=A0 =A0 =A0 =A0does for loss > >=A0 =A0 =A0 =A0detection. > > > >=A0 =A0 =A0 =A0So the problem is that we do not have a detailed = enough > >=A0 =A0 =A0 =A0algorithm or > >=A0 =A0 =A0 =A0rule that tells exactly what to do when a loss of = rexmit > is > >=A0 =A0 =A0 =A0detected. > >=A0 =A0 =A0 =A0Even worse, the algorithms in RFC 5681 and RFC 66= 75 > refer > >=A0 =A0 =A0 =A0to > >=A0 =A0 =A0 =A0equation (4) of RFC 5681 to reduce ssthresh and c= wnd > when a > >=A0 =A0 =A0 =A0loss > >=A0 =A0 =A0 =A0requiring a congestion control action is detected= : > > > >=A0 =A0 =A0 =A0=A0 (cwnd =3D) ssthresh =3D FlightSize / 2) > > > >=A0 =A0 =A0 =A0And RFC 5681 gives a warning not to halve cwnd in = the > >=A0 =A0 =A0 =A0equation but > >=A0 =A0 =A0 =A0FlightSize. > > > >=A0 =A0 =A0 =A0That is, this equation is what an implementer > intuitively > >=A0 =A0 =A0 =A0would use > >=A0 =A0 =A0 =A0when reading the relevant RFCs but it gives a wro= ng > result > >=A0 =A0 =A0 =A0for > >=A0 =A0 =A0 =A0outstanding data when in fast recovery (when the = sender > is > >=A0 =A0 =A0 =A0in > >=A0 =A0 =A0 =A0congestion avoidance and the equation (4) is used = to > halve > >=A0 =A0 =A0 =A0cwnd, it > >=A0 =A0 =A0 =A0gives a correct result). > >=A0 =A0 =A0 =A0More precisely, during fast recovery FlightSize i= s > inflated > >=A0 =A0 =A0 =A0when new > >=A0 =A0 =A0 =A0data is sent and reduced when segments are cumula= tively > >=A0 =A0 =A0 =A0Acked. > >=A0 =A0 =A0 =A0What the outcome is depends on the loss pattern. = In the > >=A0 =A0 =A0 =A0worst case, > >=A0 =A0 =A0 =A0FlightSize is signficantly larger than in the beg= inning > of > >=A0 =A0 =A0 =A0the fast > >=A0 =A0 =A0 =A0recovery when FlightSize was (correctly) used to > determine > >=A0 =A0 =A0 =A0the halved > >=A0 =A0 =A0 =A0value for cwnd and ssthresh, i.e., equation (4) m= ay > result > >=A0 =A0 =A0 =A0in > >=A0 =A0 =A0 =A0*increasing* cwnd upon detecting a loss of a rexm= itted > >=A0 =A0 =A0 =A0segment, instead > >=A0 =A0 =A0 =A0of further halving it. > > > >=A0 =A0 =A0 =A0A clever implementer might have no problem to hav= e it > right > >=A0 =A0 =A0 =A0with some > >=A0 =A0 =A0 =A0thinking but I am afraid that there will be incor= rect > >=A0 =A0 =A0 =A0implementations > >=A0 =A0 =A0 =A0with what is currently specified. Not all impleme= nters > have > >=A0 =A0 =A0 =A0spent > >=A0 =A0 =A0 =A0signicicant fraction of their career in solving T= CP > >=A0 =A0 =A0 =A0peculiarities. > > > >=A0 =A0 =A0 =A0> For (2), the RTO timer is still operative so > >=A0 =A0 =A0 =A0> the RTO recovery rules would still follow. > > > >=A0 =A0 =A0 =A0In short: > >=A0 =A0 =A0 =A0When with a non-RACK-TLP implementation timer (RT= O) > >=A0 =A0 =A0 =A0expires: cwnd=3D1 MSS, > >=A0 =A0 =A0 =A0and slow start is entered. > >=A0 =A0 =A0 =A0When with a RACK_TLP implementation timer (PTO) e= xpires, > >=A0 =A0 =A0 =A0normal fast recovery is entered (unless implement= ing > >=A0 =A0 =A0 =A0also PRR). So no RTO recovery as explicitly state= d in > Sec. > >=A0 =A0 =A0 =A07.4.1. > > > >=A0 =A0 =A0 =A0This means that this document explicitly modifies > standard > >=A0 =A0 =A0 =A0TCP congestion > >=A0 =A0 =A0 =A0control when there are no acks coming and the > >=A0 =A0 =A0 =A0retransmission timer > >=A0 =A0 =A0 =A0expires > > > >=A0 =A0 =A0 =A0from: RTO=3DSRTT+4*RTTVAR (RTO used for arming th= e timer) > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. RTO timer expires > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. cwnd=3D1 MSS; ssthresh=3DFlight= Size/2; rexmit one > >=A0 =A0 =A0 =A0segment > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of rexmit sent in step 2 ar= rives > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D cwnd+1 MSS; send two s= egments > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0... > > > >=A0 =A0 =A0 =A0to:=A0 =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arm= ing the > timer) > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. PTO times expires > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. (cwnd=3D1 MSS); (re)xmit one se= gment > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of (re)xmit sent in srep 2 = arrives > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D ssthresh =3D FlightSiz= e/2; send N=3Dcwnd > >=A0 =A0 =A0 =A0segments > > > >=A0 =A0 =A0 =A0For example, if FlightSize is 100 segments when t= imer > >=A0 =A0 =A0 =A0expires, > >=A0 =A0 =A0 =A0congestion control is the same in steps 1-3, but = in step > 4 > >=A0 =A0 =A0 =A0the > >=A0 =A0 =A0 =A0current standard congestion control allows transm= itting > 2 > >=A0 =A0 =A0 =A0segments, > >=A0 =A0 =A0 =A0while RACK-TLP would allow blasting 50 segments. > > > >=A0 =A0 =A0 =A0Question is: what is the justification to modify > standard > >=A0 =A0 =A0 =A0TCP > >=A0 =A0 =A0 =A0congestion control to use fast recovery instead o= f slow > >=A0 =A0 =A0 =A0start for a > >=A0 =A0 =A0 =A0case where timeout is needed to detect loss becau= se > there > >=A0 =A0 =A0 =A0is no > >=A0 =A0 =A0 =A0feedback and ack clock is lost? The draft does no= t give > any > >=A0 =A0 =A0 =A0justification. This clearly is in conflict with i= tems > (0) > >=A0 =A0 =A0 =A0and (1) > >=A0 =A0 =A0 =A0in BCP 133 (RFC 5033). > > > >=A0 =A0 =A0 =A0Furthermore, there is no implementation nor exper= imental > >=A0 =A0 =A0 =A0experience > >=A0 =A0 =A0 =A0evaluating this change. The implementation with > >=A0 =A0 =A0 =A0experimental experience > >=A0 =A0 =A0 =A0uses PRR (RFC 6937) which is an Experimental > specification > >=A0 =A0 =A0 =A0including a > >=A0 =A0 =A0 =A0novel "trick" that directs PRR fast recovery to > effectively > >=A0 =A0 =A0 =A0use slow > >=A0 =A0 =A0 =A0start in this case at hand. > > > > > >=A0 =A0 =A0 =A0> In other words, I am not seeing a case that req= uires > new > >=A0 =A0 =A0 =A0congestion > >=A0 =A0 =A0 =A0> control concepts except as discussed in 9.3. > > > >=A0 =A0 =A0 =A0See above. The change in standard congestion cont= rol for > >=A0 =A0 =A0 =A0(2). > >=A0 =A0 =A0 =A0The draft intends not to change congestion contro= l but > >=A0 =A0 =A0 =A0effectively it > >=A0 =A0 =A0 =A0does without any operational evidence. > > > >=A0 =A0 =A0 =A0What's also is missing and would be very useful: > > > >=A0 =A0 =A0 =A0- For (1), a hint for an implementer saying that = because > >=A0 =A0 =A0 =A0RACK-TLP is > >=A0 =A0 =A0 =A0=A0 =A0able to detect a loss of a rexmit unlike a= ny other > loss > >=A0 =A0 =A0 =A0detection > >=A0 =A0 =A0 =A0=A0 =A0algorithm, the sender MUST react twice to = congestion > >=A0 =A0 =A0 =A0(and cite > >=A0 =A0 =A0 =A0=A0 =A0RFC 5681). And cite a document where neces= sary > correct > >=A0 =A0 =A0 =A0actions > >=A0 =A0 =A0 =A0=A0 =A0are described. > > > >=A0 =A0 =A0 =A0- For (1), advise that an implementer needs to ke= ep > track > >=A0 =A0 =A0 =A0when it > >=A0 =A0 =A0 =A0=A0 =A0detects a loss of a retransmitted segment. = Current > >=A0 =A0 =A0 =A0algorithms > >=A0 =A0 =A0 =A0=A0 =A0in the draft detect a loss of retransmitte= d segment > >=A0 =A0 =A0 =A0exactly in > >=A0 =A0 =A0 =A0=A0 =A0the same way as loss of any other segment. = There > seems > >=A0 =A0 =A0 =A0to be > >=A0 =A0 =A0 =A0=A0 =A0nothing to track when a retransmission of = a > >=A0 =A0 =A0 =A0retransmitted segment > >=A0 =A0 =A0 =A0=A0 =A0takes place. Therefore, the algorithms sho= uld have > >=A0 =A0 =A0 =A0additional > >=A0 =A0 =A0 =A0=A0 =A0actions to correctly track when such a los= s is > detected. > > > >=A0 =A0 =A0 =A0- For (1), discussion on how many times a loss of = a > >=A0 =A0 =A0 =A0retransmission > >=A0 =A0 =A0 =A0=A0 =A0of the same segment may occur and be detec= ted. Seems > >=A0 =A0 =A0 =A0that it > >=A0 =A0 =A0 =A0=A0 =A0may be possible to drop a rexmitted segmen= t more than > >=A0 =A0 =A0 =A0once and > >=A0 =A0 =A0 =A0=A0 =A0detect it also several times?=A0 What are = the > >=A0 =A0 =A0 =A0implications? > > > >=A0 =A0 =A0 =A0- If previous is possible, then the algorithm pos= sibly > also > >=A0 =A0 =A0 =A0=A0 =A0may detect a loss of a new segment that wa= s sent > during > >=A0 =A0 =A0 =A0fast > >=A0 =A0 =A0 =A0=A0 =A0recovery? This is also loss in two success= ive windows > of > >=A0 =A0 =A0 =A0data, > >=A0 =A0 =A0 =A0=A0 =A0and cwnd MUST be lowered twice. This discu= ssion and > >=A0 =A0 =A0 =A0necessary > >=A0 =A0 =A0 =A0=A0 =A0actions to track it are missing, if such s= cenario is > >=A0 =A0 =A0 =A0possible. > > > >=A0 =A0 =A0 =A0> What am I missing? > > > >=A0 =A0 =A0 =A0Hope the above helps. > > > >=A0 =A0 =A0 =A0/Markku > > > > > > > > > > >=20 >=20 > --=_script-27384-1608194813-0001-2-- From nobody Thu Dec 17 00:56:50 2020 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 BAC173A156A; Thu, 17 Dec 2020 00:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 jmuiGzTsNuXQ; Thu, 17 Dec 2020 00:56:42 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94383A1566; Thu, 17 Dec 2020 00:56:41 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Thu, 17 Dec 2020 10:56:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=Cvu0QyNH5pME8NRUW 5p3RESfsVWuG+oDpOmqmLttJCk=; b=VHwHRdc0+4DSSzhjXAJIGdR6zJckQAIMG xuOfEiXefL6N3bu4vvzgnGN9D5ogcfznvAfV5ZaEh7PCTqjohNVfjTDqDOZAtpIb F/a2WrAYtrJGrz4H20kf/Ymq8gE+G1Av971/d9KDUL0FPJ+izCHzW6x9cis7lEaC ot/JS5enck= Received: from hp8x-60 (88-113-50-238.elisa-laajakaista.fi [88.113.50.238]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Thu, 17 Dec 2020 10:56:38 +0200 id 00000000005A0932.000000005FDB1D46.00004D15 Date: Thu, 17 Dec 2020 10:56:38 +0200 (EET) From: Markku Kojo To: Martin Duke cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-19759-1608195399-0001-2" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP)to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 08:56:45 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-19759-1608195399-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, Just one clarification inline. On Thu, 17 Dec 2020, Markku Kojo wrote: > Hi Martin, > > On Wed, 16 Dec 2020, Martin Duke wrote: > >> (1) Flightsize: in RFC 6675. Section 5, Step 4.2: >> >> (4.2) ssthresh =3D cwnd =3D (FlightSize / 2) >> >> The congestion window (cwnd) and slow start threshold >> (ssthresh) are reduced to half of FlightSize per [RFC5681= ]. >> Additionally, note that [RFC5681] requires that any >> segments sent as part of the Limited Transmit mechanism n= ot >> be counted in FlightSize for the purpose of the above >> equation. >>=20 >> IIUC the segments P21..P29 in your example were sent because of Limite= d=20 >> Transmit, >> and so don't count. The flightsize for the purposes of (4.2) is theref= ore=20 >> 20 after >> both losses, and the cwnd does not go up on the second loss. > > Incorrect. (And you corrected this in your later reply) > >> (2) >> " Even a single shot burst every time there is significant loss >> event is not acceptable, not to mention continuous aggressiveness, and >> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn >> about." >>=20 >> "Significant loss event" is the key phrase here. The intent of TLP/PTO = is=20 >> to >> equalize the treatment of a small packet loss whether it happened in t= he=20 >> middle of >> a burst or the end. Why should an isolated loss be treated differently=20 >> based on >> its position in the burst? This is just a logical extension of fast=20 >> retransmit, >> which also modified the RTO paradigm. The working group consensus is t= hat=20 >> this is >> a feature, not a bug; you're welcome to feel otherwise but I suspect y= ou're=20 >> in the >> rough here. > > An isolated loss in the end of flight and repairing it is handled as a=20 > separate case in the draft. It is easy to have a less conservative cong= estion=20 > control response for it, and I would be fine with that. > > The problem we are discussing is the "significant loss event" where eve= n a=20 > huge number of packets are lost, potentially indicating severe congesti= on.=20 > The draft accidentally handles it the same as a small packet loss. And = that=20 > is wrong. > > Why draft handles it accidentally wrong: because RACK-TLP has never bee= n=20 > implemented with the standard congestion control (RFC 6675) but with PR= R and=20 > the experimental evidence presented to the working group was based on t= he=20 > implementation with PRR. One may say that the WG was *accidentally*=20 > misguided. > > And as I have stated many times: PRR modifies RFC 6675 congestion contr= ol and=20 > includes necessary actions to handle a significant loss event properly. = But=20 > current standards track congestion control does not. To clarify: current standards track congestion control does not=20 handle such a significant loss event properly *if* it is detected by TLP=20 and would initiate fast recovery as specified in this draft. /Markku > And this draft=20 > explicitly modifies standards track congestion control but conceals thi= s=20 > significant modification in Sec. 9.3 when discussing the interaction wi= th=20 > congestion control. > > Best regards, > > /Markku > >> Regards >> Martin >>=20 >>=20 >> On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrot= e: >> Hi Martin, >> >> See inline. >> >> On Wed, 16 Dec 2020, Martin Duke wrote: >> >> > Hi Markku, >> > >> > There is a ton here, but I'll try to address the top points. >> Hopefully >> > they obviate the rest. >> >> Sorry for being verbose. I tried to be clear but you actually re= moved >> my >> key issues/questions ;) >> >> > 1. >> > [Markku] >> > "Hmm, not sure what you mean by "this is a new loss detection = after >> > acknowledgment of new data"? >> > But anyway, RFC 5681 gives the general principle to reduce cwn= d and >> > ssthresh twice if a retransmission is lost but IMHO (and I bel= ieve >> many >> > who have designed new loss recovery and CC algorithms or=20 >> implemented >> > them >> > agree) that it is hard to get things right if only congestion >> control >> > principles are available and no algorithm." >> > >> > [Martin] >> > So 6675 Sec 5 is quite explicit that there is only one cwnd >> reduction >> > per fast recovery episode, which ends once new data has been >> > acknowledged. >> >> To be more precise: fast recovery ends when the current window=20 >> becomes >> cumulatively acknowledged, that is, >> >> (4.1) RecoveryPoint (=3D HighData at the beginning) becomes=20 >> acknowledged >> >> I believe we agree and you meant this although new data below >> RecoveryPoint may become cumulatively acknowledged already earli= er >> during the fast recovery. Reno loss recovery in RFC 5681 ends, w= hen >> (any) new data has been acknowledged. >> >> > By definition, if a retransmission is lost it is because >> > newer data has been acknowledged, so it's a new recovery episo= de. >> >> Not sure where you have this definition? Newer than what are you >> referring to? >> >> But, yes, if a retransmission is lost with RFC 6675 algorithm, >> it requires RTO to be detected and definitely starts a new recov= ery >> episode. That is, a new recovery episode is enforced by step (1.= a) of >> NextSeg () which prevents retransmission if a segment that has=20 >> already >> been retransmitted. If RACK-TLP is used for detecting loss with = RFC >> 6675 >> things get different in many ways, because it may detect loss of = a >> retransmission. It would pretty much require an entire redesign >> of the algorith. For example, calculation of pipe does not consi= der >> segments that have been retransmitted more than once. >> >> > Meanwhile, during the Fast Recovery period the incoming acks >> implicitly >> > remove data from the network and therefore keep flightsize low= . >> >> Incorrect. FlightSize !=3D pipe. Only cumulative acks remove dat= a from >> FlightSize and new data transmitted during fast recovery inflate >> FlightSize. How FlightSize evolves depends on loss pattern as I = said. >> It is also possible that FlightSize is low, it may err in both >> directions. A simple example can be used as a proof for the case=20 >> where >> cwnd increases if a loss of retransmission is detected and repai= red: >> >> RFC 6675 recovery with RACK-TLP loss detection: >> (contains some inaccuracies because it has not been defined how >> lost rexmits are calculated into pipe) >> >> cwnd=3D20; packets P1,...,P20 in flight =3D current window of da= ta >> [P1 dropped and rexmit of P1 will also be dropped] >> >> DupAck w/SACK for P2 arrives >> [loss of P1 detected after one RTT from original xmit of P1] >> [cwnd=3Dssthresh=3D10] >> P1 is rexmitted (and it logically starts next window of data) >> >> DupAcks w/ SACK for original P3..11 arrive >> DupAck w/ SACK for original P12 arrives >> [cwnd-pipe =3D 10-9 >=3D1] >> send P21 >> DupAck w/SACK for P13 arrives >> send P22 >> ... >> DupAck w/SACK for P20 arrives >> send P29 >> [FlightSize=3D29] >> >> (Ack for rexmit of P1 would arrive here unless it got dropped) >> >> DupAck w/SACK for P21 arrives >> [loss of rexmit P1 detected after one RTT from rexmit of P1] >> >> SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D 14,5 >> >> CWND INCREASES when it should be at most 5 after halving it twic= e!!! >> >> > We can continue to go around on our interpretation of these >> documents, >> > but fundamentally if there is ambiguity in 5681/6675 we should = bis >> > those RFCs rather than expand the scope of RACK. >> >> As I said earlier, I am not opposing bis, though 5681bis wuold n= ot >> be needed, I think. >> >> But let me repeat: if we publish RACK-TLP now without necessary >> warnings >> or with a correct congesion control algorithm someone will try t= o >> implement RACK-TLP with RFC 6675 and it will be a total mesh. Th= e >> behavior will be unpredictable and quite likely unsafe congestio= n >> control behavior. >> >> > 2. >> > [Markku] >> > " In short: >> > When with a non-RACK-TLP implementation timer (RTO) expires: c= wnd=3D1 >> > MSS, >> > and slow start is entered. >> > When with a RACK_TLP implementation timer (PTO) expires, >> > normal fast recovery is entered (unless implementing >> > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4= .1." >> > >> > [Martin] >> > There may be a misunderstanding here. PTO is not the same as R= TO, >> and >> > both mechanisms exist! The loss response to a PTO is to send a >> probe; >> > the RTO response is as with conventional TCP. In Section 7.3: >> >> No, I don't think I misunderstood. If you call timeout with >> another name, it is still timeout. And congestion control does n= ot >> consider which segments to send (SND.UNA vs. probe w/ higher seq= uence >> number), only how much is sent. >> >> You ignored my major point where I decoupled congestion control = from >> loss >> detection and loss recovery and compared RFC 5681 behavior to=20 >> RACK-TLP >> behavior in exactly the same scenario where an entire flight is = lost >> and >> timer expires. >> >> Please comment why congestion control behavior is allowed to be >> radically >> different in these two implementations? >> >> RFC 5681 & RFC 6298 timeout: >> >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTTVAR (RTO used for ar= ming the timer) >> =C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires >> =C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSiz= e/2; rexmit one segment >> =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arriv= es >> =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segm= ents >> =C2=A0 =C2=A0 =C2=A0 =C2=A0... >> >> RACK-TLP timeout: >> >> =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PTO used = for arming the timer) >> =C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires >> =C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segme= nt >> =C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arr= ives >> =C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2= ; send N=3Dcwnd segments >> >> If FlightSize is 100 segments when timer expires, congestion con= trol >> is >> the same in steps 1-3, but in step 4 the standard congestion con= trol >> allows transmitting 2 segments, while RACK-TLP would allow >> blasting 50 segments. >> >> > After attempting to send a loss probe, regardless of whether a = loss >> >=C2=A0 =C2=A0 probe was sent, the sender MUST re-arm the RTO ti= mer, not the=20 >> PTO >> >=C2=A0 =C2=A0 timer, if FlightSize is not zero.=C2=A0 This ensu= res RTO recovery >> remains >> >=C2=A0 =C2=A0 the last resort if TLP fails. >> > " >> >> This does not prevent the above RACK-TLP behavior from getting >> realized. >> >> > So a pure RTO response exists in the case of persistent conges= tion >> that >> > causes losses of probes or their ACKs. >> >> Yes, RTO response exists BUT only after RACK-TLP at least once b= lasts >> the >> network. It may well be that with smaller windows RACK-TLP is >> successful >> during its TLP initiated overly aggressive "fast recovery" and n= ever >> enters RTO recovery because it may detect and repair also loss o= f >> rexmits. That is, it continues at too high rate even if lost rex= mits >> indicate that congestion persists in successive windows of data. = And >> worse, it is successful because it pushes away other compatible = TCP >> flows by being too aggressive and unfair. >> >> Even a single shot burst every time there is significant loss >> event is not acceptable, not to mention continuous aggressivenes= s,=20 >> and >> this is exactly what RFC 2914 and RFC 5033 explicitly address an= d=20 >> warn >> about. >> >> Are we ignoring these BCPs that have IETF consensus? >> >> And the other important question I'd like to have an answer: >> >> What is the justification to modify standard TCP congestion cont= rol=20 >> to >> use fast recovery instead of slow start for a case where timeout = is >> needed to detect the packet losses because there is no feedback = and >> ack >> clock is lost? RACK-TLP explicitly instructs to do so in Sec. 7.= 4.1. >> >> As I noted: based on what is written in the draft it does not in= tend >> to >> change congestion control but effectively it does. >> >> /Markku >> >> > Martin >> > >> > >> > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo >> > wrote: >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 Dec 2020, Martin Duke wro= te: >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks for the comments. The autho= rs will incorporate >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggestions after the IESG review. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> There's one thing I don't understa= nd in your comments: >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> " That is, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> where can an implementer find advi= ce for correct >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions with RACK-TLP, when: >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a loss of rexmitted segment is = detected >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an entire flight of data gets = dropped (and detected), >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0that is, when = there is no feedback available and a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 =C2=A0 =C2=A0is needed to d= etect the loss " >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section 9.3 is the discussion abou= t CC, and is clear that >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> implementer should use either 5681 = or 6937. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite nit: RFC 5681 provides b= asic CC concepts and >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful CC >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines but given that RACK-TLP M= UST implement SACK the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is not that useful and an i= mplementer quite likely >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0follows >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the algorithm in RFC 6675 (an= d not RFC 6937 at all >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0if not >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing PRR). >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 is not mentioned in Sec = 9.3, though it is >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requirements). >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went through the 6937 case in = detail. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but without correct CC actions. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681, it's pretty clear to me t= hat in (1) this is a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> detection after acknowledgment of = new data, and therefore >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> second halving of cwnd. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure what you mean by "this = is a new loss >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection after >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgment of new data"? >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, RFC 5681 gives the gener= al principle to reduce >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twice if a retransmission i= s lost but IMHO (and I >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0who have designed new loss recovery = and CC algorithms or >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented them >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that it is hard to get things = right if only >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0principles are available and no algo= rithm. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0That's why ALL mechanisms that we ha= ve include a quite >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algorithm >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0with all necessary variables and act= ions for loss recovery >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and often also pseudocode)= . Like this document >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0So the problem is that we do not hav= e a detailed enough >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tells exactly what to do w= hen a loss of rexmit is >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0detected. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, the algorithms in RFC 56= 81 and RFC 6675 refer >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0to >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) of RFC 5681 to reduce s= sthresh and cwnd when a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0loss >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a congestion control actio= n is detected: >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd =3D) ssthresh =3D Fligh= tSize / 2) >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 gives a warning not to = halve cwnd in the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this equation is what an im= plementer intuitively >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0would use >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading the relevant RFCs but i= t gives a wrong result >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0for >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding data when in fast recove= ry (when the sender is >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0in >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion avoidance and the equatio= n (4) is used to halve >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a correct result). >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisely, during fast recovery = FlightSize is inflated >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when new >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent and reduced when segmen= ts are cumulatively >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outcome is depends on the l= oss pattern. In the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is signficantly larger th= an in the beginning of >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when FlightSize was (correc= tly) used to determine >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwnd and ssthresh, i.e., e= quation (4) may result >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0in >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* cwnd upon detecting a l= oss of a rexmitted >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, instead >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0of further halving it. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever implementer might have no p= roblem to have it right >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0with some >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but I am afraid that there = will be incorrect >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implementations >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is currently specified. No= t all implementers have >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0spent >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant fraction of their career = in solving TCP >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2), the RTO timer is still op= erative so >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO recovery rules would still = follow. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0In short: >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a non-RACK-TLP implementat= ion timer (RTO) >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd=3D1 MSS, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow start is entered. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a RACK_TLP implementation = timer (PTO) expires, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast recovery is entered (unl= ess implementing >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So no RTO recovery as exp= licitly stated in Sec. >> >=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0This means that this document explic= itly modifies standard >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestion >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0control when there are no acks comin= g and the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission timer >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DSRTT+4*RTTVAR (RTO used = for arming the timer) >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO ti= mer expires >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D= 1 MSS; ssthresh=3DFlightSize/2; rexmit one >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0segment >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = rexmit sent in step 2 arrives >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = cwnd+1 MSS; send two segments >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0... >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO= ) (PRO used for arming the timer) >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO ti= mes expires >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D= 1 MSS); (re)xmit one segment >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = (re)xmit sent in srep 2 arrives >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = ssthresh =3D FlightSize/2; send N=3Dcwnd >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0segments >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, if FlightSize is 100 se= gments when timer >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0expires, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control is the same in st= eps 1-3, but in step 4 >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0current standard congestion control = allows transmitting 2 >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0segments, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TLP would allow blasting = 50 segments. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: what is the justificati= on to modify standard >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion control to use fast recov= ery instead of slow >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0case where timeout is needed to dete= ct loss because there >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0is no >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and ack clock is lost? The = draft does not give any >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0justification. This clearly is in co= nflict with items (0) >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1) >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (RFC 5033). >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, there is no implementat= ion nor experimental >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0experience >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating this change. The implemen= tation with >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental experience >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC 6937) which is an Expe= rimental specification >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0including a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "trick" that directs PRR fast = recovery to effectively >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this case at hand. >> > >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other words, I am not seeing a = case that requires new >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> control concepts except as discuss= ed in 9.3. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. The change in standard co= ngestion control for >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(2). >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft intends not to change cong= estion control but >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively it >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0does without any operational evidenc= e. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0What's also is missing and would be = very useful: >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a hint for an implementer = saying that because >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0able to detect a loss o= f a rexmit unlike any other loss >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0algorithm, the sender M= UST react twice to congestion >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0RFC 5681). And cite a d= ocument where necessary correct >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0actions >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0are described. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), advise that an implemente= r needs to keep track >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when it >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detects a loss of a ret= ransmitted segment. Current >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0in the draft detect a l= oss of retransmitted segment >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0the same way as loss of = any other segment. There seems >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0to be >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0nothing to track when a = retransmission of a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted segment >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0takes place. Therefore, = the algorithms should have >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0additional >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to correctly tr= ack when such a loss is detected. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), discussion on how many ti= mes a loss of a >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0of the same segment may = occur and be detected. Seems >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0that it >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may be possible to drop = a rexmitted segment more than >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0once and >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0detect it also several = times?=C2=A0 What are the >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0implications? >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous is possible, then the = algorithm possibly also >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0may detect a loss of a = new segment that was sent during >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0fast >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0recovery? This is also = loss in two successive windows of >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0data, >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0and cwnd MUST be lowere= d twice. This discussion and >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0actions to track it are = missing, if such scenario is >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0possible. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am I missing? >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the above helps. >> > >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku >> > >> > >> > >> > >> > >>=20 >>=20 > --=_script-19759-1608195399-0001-2-- From nobody Thu Dec 17 02:50:16 2020 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 98C1A3A1601; Thu, 17 Dec 2020 02:50:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, tuexen@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160820221460.14977.1292601307954405019@ietfa.amsl.com> Date: Thu, 17 Dec 2020 02:50:14 -0800 Archived-At: Subject: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 10:50:15 -0000 Robert Wilton has entered the following ballot position for draft-ietf-tcpm-rack-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, I didn't manage to review the algorithm in detail (way outside my area), but surrounding text was clear, understandable and interesting for someone without TCP expertise, so thank you for that. One minor NIT would be the change the footer from "RACK" to "RACK-TLP". Section 9.5 talks about using RACK for other protocols and I wanted to confirm that it does mean only RACK and not RACK-TLP for this case. Regards, Rob From nobody Thu Dec 17 04:46:21 2020 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 9B7643A03F8; Thu, 17 Dec 2020 04:46:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, tuexen@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <160820918017.10062.4021553447453861559@ietfa.amsl.com> Date: Thu, 17 Dec 2020 04:46:20 -0800 Archived-At: Subject: [tcpm] Magnus Westerlund's Yes on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 12:46:21 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-tcpm-rack-14: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1: In this document, these words will appear with that interpretation only when in UPPER CASE. Lower case uses of these words are not to be interpreted as carrying [RFC2119] significance. This addition to the RFC 8174 boiler text appears redundant and can be removed. I assume it predates RFC 8174. From nobody Thu Dec 17 05:09:07 2020 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 4445A3A061B for ; Thu, 17 Dec 2020 05:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.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 vgSrl_qUgagg for ; Thu, 17 Dec 2020 05:09:04 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 115073A046B for ; Thu, 17 Dec 2020 05:09:03 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id z20so19980050qtq.3 for ; Thu, 17 Dec 2020 05:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=fHghw/wX8IALS/gojKwCG85O0+a3zVhW7RXyqP0AmBs=; b=Jw7ezGuMXKESJoCK579KeSxQxWLCemt7k70hpQUCohfyFn7HrCae5EfU3aKyMGNx2u GErcgdY1wi9TLgNrPSkZkkiORnTv3JxPIGawlkdKecx8loKTIQCIswHbML0g1Bkuxi14 AAFdSIgzYHNkY8QpdWKAc7opcqJ7V3E6kOJJC8BWBRNBZkrkaRDxwaM9a8WMKgfEvcsL lwaIMbrG6npYKeklEyTnaPNrvsJ4Db71/PBbD+eqFu5OFRqH0STkJM9J2TLJXaUyn/WZ Np7HVZzCgeUKNyvxWEsL9SCeszVbvdb+eUI5/Oe2WKHZNvJ22wB28OEvGZxudMMOGfut yzAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=fHghw/wX8IALS/gojKwCG85O0+a3zVhW7RXyqP0AmBs=; b=qPeN/tqQVQEIWbgQjJ4Hq+BhOpdE1VLFOSHSbISYXwwf/CHTl+XiW0bJPJrvZZ5TEX zv3129Ov0A9DVZSTXjT7pcsq+uHS0gsrGPAGHEA40NMOxha79I3IfsV/CbX/zE6f2+i9 81i7AHPXF8RcXkRQZuwa8OPDGQ/uc5unL7EoPd7VgXPd3x71uemCtHDiF+0hImVqO3oL akP3xSbK8nNHMkKScFvbtwDnToJLW++ojxkELtqfg+tORt7Ak7Ov/uuSrSAL+7Q4Ck3m aGXUruxfjtHEz/hgfTrh1LcjOsb4HhX+fEdXqpCO4ZoMfrVKulyalvHCmkJBHViTiJM1 D2Dg== X-Gm-Message-State: AOAM53007wYFMyhMipOOh5eO+AdVsgu//TtB8iOr6l9zok+0K8lmTrXV aIpZyOocU4hhalbOzerK9UHmTqOHT8tHEHuJ X-Google-Smtp-Source: ABdhPJxX96WvpZrFoSaLv9WYVm8HUzcQDKC90qfdJy5qdTZ9uS0qfCGR4dMaqxAEQcS3AfDCz8bz2Q== X-Received: by 2002:ac8:2a8f:: with SMTP id b15mr38230013qta.33.1608210542511; Thu, 17 Dec 2020 05:09:02 -0800 (PST) Received: from [192.168.1.12] (cpe-174-102-117-3.columbus.res.rr.com. [174.102.117.3]) by smtp.gmail.com with ESMTPSA id f185sm3272168qkb.119.2020.12.17.05.09.00 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Dec 2020 05:09:01 -0800 (PST) To: tcpm@ietf.org References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> <68B1C03F-71F6-4854-B0F8-AE9D4121E9E2@strayalpha.com> From: Wesley Eddy Message-ID: Date: Thu, 17 Dec 2020 08:08:56 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A138A8AC84FD34DA98B32253" Content-Language: en-US Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 13:09:06 -0000 This is a multi-part message in MIME format. --------------A138A8AC84FD34DA98B32253 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/11/2020 2:25 PM, Ian Swett wrote: > > On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch > wrote: > > > >> On Dec 11, 2020, at 8:56 AM, Ian Swett >> > > wrote: >> >> In my opinion, we already have an issue, because a non-normative >> 'recommended' is used.  A reasonable reading is this was intended >> as the normative RECOMMENDED, but no one ever bothered to >> capitalize it, but it seems there's some disagreement on whether >> that was the case. > > Except that this RFC actually already includes the following > *explicit* language: > > In this document, these words will appear with that interpretation > only when in UPPER CASE. Lower case uses of these words are not to > be interpreted as carrying [RFC2119 ] significance. > > > Ok, well that's unusual. I don't know where you're seeing that text exactly.  The current 793bis draft has the BCP 14 boilerplate text, just like most other IETF documents. --------------A138A8AC84FD34DA98B32253 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/11/2020 2:25 PM, Ian Swett wrote:

On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch <touch@strayalpha.com> wrote:


On Dec 11, 2020, at 8:56 AM, Ian Swett <ianswett=40google.com@dmarc.ietf.org> wrote:

In my opinion, we already have an issue, because a non-normative 'recommended' is used.  A reasonable reading is this was intended as the normative RECOMMENDED, but no one ever bothered to capitalize it, but it seems there's some disagreement on whether that was the case.

Except that this RFC actually already includes the following *explicit* language:

   In this document, these words will appear with that interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

Ok, well that's unusual.

I don't know where you're seeing that text exactly.  The current 793bis draft has the BCP 14 boilerplate text, just like most other IETF documents.


--------------A138A8AC84FD34DA98B32253-- From nobody Thu Dec 17 07:30:31 2020 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 2A5DC3A0978; Thu, 17 Dec 2020 07:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uZXlEa988CEK; Thu, 17 Dec 2020 07:30:26 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 315A03A098C; Thu, 17 Dec 2020 07:30:26 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id v3so26199382ilo.5; Thu, 17 Dec 2020 07:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NuM7cWGHBtFp1z/CyN/jGHX5vOjGCa7ol9j0iLPWefg=; b=J6BfORDRt4UL5Nu5ERVlKNephPdmawa0CAewmeie+o/DP/CP9cXv0fZMqO9APRVdwH ORd1FLUSF7tewuuCeIg+rUo0fMHldXJSvyKEOnvPnGOzUoK+KS7xhVvxCRgo4j0hyGqZ gT2Pl/0OvHk4fy3SpuNHBrpsMqWYj7R7ERpkBZNUNcTGaM9aWvl+xiFptYgkMZRmVndJ Bljohy1LQT8mCJHpyn/pxh+ZWYpIsR+mUl1YPshjxtkE/xEWVuXLjphy4rchbSyoEusq DMRsYScqSHv+MyoYKSnPK7goQb9/SqSJBvsB4QmK2JYEBQ3YtlNGFECrRdAXVAsTtNVC ZUjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NuM7cWGHBtFp1z/CyN/jGHX5vOjGCa7ol9j0iLPWefg=; b=fbEgExzQgXzJYUo67RQvX1ys7tKtowKPWYsD7+aMr9n3uloA+Y2OKm+IKQURtkDwfe Xde5YixWY9ap5P6uGkQZx/LrEXXbAW74vBs4BfCuijvZidSjfxDCEQk3nnjH1PPGaBsc 6u2CfYm0+3N2KJmaFku48BhIxXg8bQvDcT2cLUl5365azgwsRjCgeb+X0CPGZAOTrr/h bhxMAPKMIZ3/B6kXVmQtqUdv/4sM6NSx3WLXqERj51s7KqFeA2tYnH6euiHqJESVgnTk x57/GE2Dm+3Cm1Kg3Oe75MScTGDPXPSsBn36ekKiG8SxoBWL2GKuhIJ6Aw1xNqdYPD4r yiWA== X-Gm-Message-State: AOAM532eZ49v1VZ8MH73qJ0NzIXEoccdddQqDN6lW/1Dpd630JpMRBvl steZg/PMld+Q8gHefZb5/kxw3GoWhIDnXKZx2DE= X-Google-Smtp-Source: ABdhPJyqkuDdOGn4KFjjQ4Y2y1VrrE0NK5K5nhh73R4oJ8K3WWg+OaagjcIl94NnyUy0u4zPfu7iuIFtJWhvu8kKqbQ= X-Received: by 2002:a92:155b:: with SMTP id v88mr49877706ilk.303.1608219025402; Thu, 17 Dec 2020 07:30:25 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Thu, 17 Dec 2020 07:30:15 -0800 Message-ID: To: Markku Kojo Cc: Neal Cardwell , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000baf22c05b6aaab91" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 15:30:30 -0000 --000000000000baf22c05b6aaab91 Content-Type: text/plain; charset="UTF-8" Hi Markku, Thanks, now I understand your objections. Martin On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo wrote: > Hi, > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > I spent a little longer looking at the specs more carefully, and I > explained (1) > > incorrectly in my last two messages. P21..29 are not Limited Transmit > packets. > > Correct. Just normal the rule that allows sending new data during fast > recovery. > > > However, unless I'm missing something else, 6675 is clear that the > recovery period > > does not end until the cumulative ack advances, meaning that detecting > the lost > > retransmission of P1 does not trigger another MD directly. > > As I have said earlier, RFC 6675 does not repeat all congestion control > principles from RFC 5681. It definitely honors the CC principle that > requires to treat a loss of a retransmission as a new congestion > indication and another MD. I believe I am obligated to know this as a > co-author of RFC 6675. ;) > > RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the > abstract: > > " ... conforms to the spirit of the current congestion control > specification (RFC 5681 ..." > > And in the intro: > > "The algorithm specified in this document is a straightforward > SACK-based loss recovery strategy that follows the guidelines > set in [RFC5681] ..." > > I don't think there is anything unclear in this. > > RFC 6675 and all other standard congestion controls (RFC 5581 and RFC > 6582) handle a loss of a retransmission by "enforcing" RTO to detect it. > And RTO guarantees MD. RACK-TLP changes the loss detection in this case > and therefore the standard congestion control algorithms do not have > actions to handle it corrrectly. That is the point. > > BR, > > /Markku > > > Thanks for this exercise! It's refreshed my memory of these details > after working > > on slightly different QUIC algorithms a long time. > > > > On Wed, Dec 16, 2020, 18:55 Martin Duke wrote: > > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > > > (4.2) ssthresh = cwnd = (FlightSize / 2) > > > > The congestion window (cwnd) and slow start threshold > > (ssthresh) are reduced to half of FlightSize per [RFC5681]. > > Additionally, note that [RFC5681] requires that any > > segments sent as part of the Limited Transmit mechanism not > > be counted in FlightSize for the purpose of the above > > equation. > > > > IIUC the segments P21..P29 in your example were sent because of Limited > > Transmit, and so don't count. The flightsize for the purposes of (4.2) is > > therefore 20 after both losses, and the cwnd does not go up on the second > > loss. > > > > (2) > > " Even a single shot burst every time there is significant loss > > event is not acceptable, not to mention continuous aggressiveness, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > > about." > > > > "Significant loss event" is the key phrase here. The intent of TLP/PTO > is to > > equalize the treatment of a small packet loss whether it happened in the > > middle of a burst or the end. Why should an isolated loss be treated > > differently based on its position in the burst? This is just a logical > > extension of fast retransmit, which also modified the RTO paradigm. The > > working group consensus is that this is a feature, not a bug; you're > welcome > > to feel otherwise but I suspect you're in the rough here. > > > > Regards > > Martin > > > > > > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote: > > Hi Martin, > > > > See inline. > > > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > > > Hi Markku, > > > > > > There is a ton here, but I'll try to address the top points. > > Hopefully > > > they obviate the rest. > > > > Sorry for being verbose. I tried to be clear but you actually > > removed my > > key issues/questions ;) > > > > > 1. > > > [Markku] > > > "Hmm, not sure what you mean by "this is a new loss detection > > after > > > acknowledgment of new data"? > > > But anyway, RFC 5681 gives the general principle to reduce > > cwnd and > > > ssthresh twice if a retransmission is lost but IMHO (and I > > believe many > > > who have designed new loss recovery and CC algorithms or > > implemented > > > them > > > agree) that it is hard to get things right if only congestion > > control > > > principles are available and no algorithm." > > > > > > [Martin] > > > So 6675 Sec 5 is quite explicit that there is only one cwnd > > reduction > > > per fast recovery episode, which ends once new data has been > > > acknowledged. > > > > To be more precise: fast recovery ends when the current window > > becomes > > cumulatively acknowledged, that is, > > > > (4.1) RecoveryPoint (= HighData at the beginning) becomes > > acknowledged > > > > I believe we agree and you meant this although new data below > > RecoveryPoint may become cumulatively acknowledged already > > earlier > > during the fast recovery. Reno loss recovery in RFC 5681 ends, > > when > > (any) new data has been acknowledged. > > > > > By definition, if a retransmission is lost it is because > > > newer data has been acknowledged, so it's a new recovery > > episode. > > > > Not sure where you have this definition? Newer than what are you > > referring to? > > > > But, yes, if a retransmission is lost with RFC 6675 algorithm, > > it requires RTO to be detected and definitely starts a new > > recovery > > episode. That is, a new recovery episode is enforced by step > > (1.a) of > > NextSeg () which prevents retransmission if a segment that has > > already > > been retransmitted. If RACK-TLP is used for detecting loss with > > RFC 6675 > > things get different in many ways, because it may detect loss of > > a > > retransmission. It would pretty much require an entire redesign > > of the algorith. For example, calculation of pipe does not > > consider > > segments that have been retransmitted more than once. > > > > > Meanwhile, during the Fast Recovery period the incoming acks > > implicitly > > > remove data from the network and therefore keep flightsize > > low. > > > > Incorrect. FlightSize != pipe. Only cumulative acks remove data > > from > > FlightSize and new data transmitted during fast recovery inflate > > FlightSize. How FlightSize evolves depends on loss pattern as I > > said. > > It is also possible that FlightSize is low, it may err in both > > directions. A simple example can be used as a proof for the case > > where > > cwnd increases if a loss of retransmission is detected and > > repaired: > > > > RFC 6675 recovery with RACK-TLP loss detection: > > (contains some inaccuracies because it has not been defined how > > lost rexmits are calculated into pipe) > > > > cwnd=20; packets P1,...,P20 in flight = current window of data > > [P1 dropped and rexmit of P1 will also be dropped] > > > > DupAck w/SACK for P2 arrives > > [loss of P1 detected after one RTT from original xmit of P1] > > [cwnd=ssthresh=10] > > P1 is rexmitted (and it logically starts next window of data) > > > > DupAcks w/ SACK for original P3..11 arrive > > DupAck w/ SACK for original P12 arrives > > [cwnd-pipe = 10-9 >=1] > > send P21 > > DupAck w/SACK for P13 arrives > > send P22 > > ... > > DupAck w/SACK for P20 arrives > > send P29 > > [FlightSize=29] > > > > (Ack for rexmit of P1 would arrive here unless it got dropped) > > > > DupAck w/SACK for P21 arrives > > [loss of rexmit P1 detected after one RTT from rexmit of P1] > > > > SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 > > > > CWND INCREASES when it should be at most 5 after halving it > > twice!!! > > > > > We can continue to go around on our interpretation of these > > documents, > > > but fundamentally if there is ambiguity in 5681/6675 we should > > bis > > > those RFCs rather than expand the scope of RACK. > > > > As I said earlier, I am not opposing bis, though 5681bis wuold > > not > > be needed, I think. > > > > But let me repeat: if we publish RACK-TLP now without necessary > > warnings > > or with a correct congesion control algorithm someone will try > > to > > implement RACK-TLP with RFC 6675 and it will be a total mesh. > > The > > behavior will be unpredictable and quite likely unsafe > > congestion > > control behavior. > > > > > 2. > > > [Markku] > > > " In short: > > > When with a non-RACK-TLP implementation timer (RTO) expires: > > cwnd=1 > > > MSS, > > > and slow start is entered. > > > When with a RACK_TLP implementation timer (PTO) expires, > > > normal fast recovery is entered (unless implementing > > > also PRR). So no RTO recovery as explicitly stated in Sec. > > 7.4.1." > > > > > > [Martin] > > > There may be a misunderstanding here. PTO is not the same as > > RTO, and > > > both mechanisms exist! The loss response to a PTO is to send a > > probe; > > > the RTO response is as with conventional TCP. In Section 7.3: > > > > No, I don't think I misunderstood. If you call timeout with > > another name, it is still timeout. And congestion control does > > not > > consider which segments to send (SND.UNA vs. probe w/ higher > > sequence > > number), only how much is sent. > > > > You ignored my major point where I decoupled congestion control > > from loss > > detection and loss recovery and compared RFC 5681 behavior to > > RACK-TLP > > behavior in exactly the same scenario where an entire flight is > > lost and > > timer expires. > > > > Please comment why congestion control behavior is allowed to be > > radically > > different in these two implementations? > > > > RFC 5681 & RFC 6298 timeout: > > > > RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > > 1. RTO timer expires > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment > > 3. Ack of rexmit sent in step 2 arrives > > 4. cwnd = cwnd+1 MSS; send two segments > > ... > > > > RACK-TLP timeout: > > > > PTO=min(2*SRTT,RTO) (PTO used for arming the timer) > > 1. PTO times expires > > 2. (cwnd=1 MSS); (re)xmit one segment > > 3. Ack of (re)xmit sent in srep 2 arrives > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments > > > > If FlightSize is 100 segments when timer expires, congestion > > control is > > the same in steps 1-3, but in step 4 the standard congestion > > control > > allows transmitting 2 segments, while RACK-TLP would allow > > blasting 50 segments. > > > > > After attempting to send a loss probe, regardless of whether a > > loss > > > probe was sent, the sender MUST re-arm the RTO timer, not > > the PTO > > > timer, if FlightSize is not zero. This ensures RTO > > recovery remains > > > the last resort if TLP fails. > > > " > > > > This does not prevent the above RACK-TLP behavior from getting > > realized. > > > > > So a pure RTO response exists in the case of persistent > > congestion that > > > causes losses of probes or their ACKs. > > > > Yes, RTO response exists BUT only after RACK-TLP at least once > > blasts the > > network. It may well be that with smaller windows RACK-TLP is > > successful > > during its TLP initiated overly aggressive "fast recovery" and > > never > > enters RTO recovery because it may detect and repair also loss > > of > > rexmits. That is, it continues at too high rate even if lost > > rexmits > > indicate that congestion persists in successive windows of data. > > And > > worse, it is successful because it pushes away other compatible > > TCP > > flows by being too aggressive and unfair. > > > > Even a single shot burst every time there is significant loss > > event is not acceptable, not to mention continuous > > aggressiveness, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address > > and warn > > about. > > > > Are we ignoring these BCPs that have IETF consensus? > > > > And the other important question I'd like to have an answer: > > > > What is the justification to modify standard TCP congestion > > control to > > use fast recovery instead of slow start for a case where timeout > > is > > needed to detect the packet losses because there is no feedback > > and ack > > clock is lost? RACK-TLP explicitly instructs to do so in Sec. > > 7.4.1. > > > > As I noted: based on what is written in the draft it does not > > intend to > > change congestion control but effectively it does. > > > > /Markku > > > > > Martin > > > > > > > > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > > > > > wrote: > > > Hi Martin, > > > > > > On Tue, 15 Dec 2020, Martin Duke wrote: > > > > > > > Hi Markku, > > > > > > > > Thanks for the comments. The authors will incorporate > > > many of your > > > > suggestions after the IESG review. > > > > > > > > There's one thing I don't understand in your comments: > > > > > > > > " That is, > > > > where can an implementer find advice for correct > > > congestion control > > > > actions with RACK-TLP, when: > > > > > > > > (1) a loss of rexmitted segment is detected > > > > (2) an entire flight of data gets dropped (and > > detected), > > > > that is, when there is no feedback available and > > a > > > timeout > > > > is needed to detect the loss " > > > > > > > > Section 9.3 is the discussion about CC, and is clear > > that > > > the > > > > implementer should use either 5681 or 6937. > > > > > > Just a cite nit: RFC 5681 provides basic CC concepts and > > > some useful CC > > > guidelines but given that RACK-TLP MUST implement SACK > > the > > > algorithm in > > > RFC 5681 is not that useful and an implementer quite > > likely > > > follows > > > mainly the algorithm in RFC 6675 (and not RFC 6937 at > > all > > > if not > > > implementing PRR). > > > And RFC 6675 is not mentioned in Sec 9.3, though it is > > > listed in the > > > Sec. 4 (Requirements). > > > > > > > You went through the 6937 case in detail. > > > > > > Yes, but without correct CC actions. > > > > > > > If 5681, it's pretty clear to me that in (1) this is a > > > new loss > > > > detection after acknowledgment of new data, and > > therefore > > > requires a > > > > second halving of cwnd. > > > > > > Hmm, not sure what you mean by "this is a new loss > > > detection after > > > acknowledgment of new data"? > > > But anyway, RFC 5681 gives the general principle to > > reduce > > > cwnd and > > > ssthresh twice if a retransmission is lost but IMHO (and > > I > > > believe many > > > who have designed new loss recovery and CC algorithms or > > > implemented them > > > agree) that it is hard to get things right if only > > > congestion control > > > principles are available and no algorithm. > > > That's why ALL mechanisms that we have include a quite > > > detailed algorithm > > > with all necessary variables and actions for loss > > recovery > > > and/or CC > > > purposes (and often also pseudocode). Like this document > > > does for loss > > > detection. > > > > > > So the problem is that we do not have a detailed enough > > > algorithm or > > > rule that tells exactly what to do when a loss of rexmit > > is > > > detected. > > > Even worse, the algorithms in RFC 5681 and RFC 6675 > > refer > > > to > > > equation (4) of RFC 5681 to reduce ssthresh and cwnd > > when a > > > loss > > > requiring a congestion control action is detected: > > > > > > (cwnd =) ssthresh = FlightSize / 2) > > > > > > And RFC 5681 gives a warning not to halve cwnd in the > > > equation but > > > FlightSize. > > > > > > That is, this equation is what an implementer > > intuitively > > > would use > > > when reading the relevant RFCs but it gives a wrong > > result > > > for > > > outstanding data when in fast recovery (when the sender > > is > > > in > > > congestion avoidance and the equation (4) is used to > > halve > > > cwnd, it > > > gives a correct result). > > > More precisely, during fast recovery FlightSize is > > inflated > > > when new > > > data is sent and reduced when segments are cumulatively > > > Acked. > > > What the outcome is depends on the loss pattern. In the > > > worst case, > > > FlightSize is signficantly larger than in the beginning > > of > > > the fast > > > recovery when FlightSize was (correctly) used to > > determine > > > the halved > > > value for cwnd and ssthresh, i.e., equation (4) may > > result > > > in > > > *increasing* cwnd upon detecting a loss of a rexmitted > > > segment, instead > > > of further halving it. > > > > > > A clever implementer might have no problem to have it > > right > > > with some > > > thinking but I am afraid that there will be incorrect > > > implementations > > > with what is currently specified. Not all implementers > > have > > > spent > > > signicicant fraction of their career in solving TCP > > > peculiarities. > > > > > > > For (2), the RTO timer is still operative so > > > > the RTO recovery rules would still follow. > > > > > > In short: > > > When with a non-RACK-TLP implementation timer (RTO) > > > expires: cwnd=1 MSS, > > > and slow start is entered. > > > When with a RACK_TLP implementation timer (PTO) expires, > > > normal fast recovery is entered (unless implementing > > > also PRR). So no RTO recovery as explicitly stated in > > Sec. > > > 7.4.1. > > > > > > This means that this document explicitly modifies > > standard > > > TCP congestion > > > control when there are no acks coming and the > > > retransmission timer > > > expires > > > > > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > > > 1. RTO timer expires > > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one > > > segment > > > 3. Ack of rexmit sent in step 2 arrives > > > 4. cwnd = cwnd+1 MSS; send two segments > > > ... > > > > > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the > > timer) > > > 1. PTO times expires > > > 2. (cwnd=1 MSS); (re)xmit one segment > > > 3. Ack of (re)xmit sent in srep 2 arrives > > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd > > > segments > > > > > > For example, if FlightSize is 100 segments when timer > > > expires, > > > congestion control is the same in steps 1-3, but in step > > 4 > > > the > > > current standard congestion control allows transmitting > > 2 > > > segments, > > > while RACK-TLP would allow blasting 50 segments. > > > > > > Question is: what is the justification to modify > > standard > > > TCP > > > congestion control to use fast recovery instead of slow > > > start for a > > > case where timeout is needed to detect loss because > > there > > > is no > > > feedback and ack clock is lost? The draft does not give > > any > > > justification. This clearly is in conflict with items > > (0) > > > and (1) > > > in BCP 133 (RFC 5033). > > > > > > Furthermore, there is no implementation nor experimental > > > experience > > > evaluating this change. The implementation with > > > experimental experience > > > uses PRR (RFC 6937) which is an Experimental > > specification > > > including a > > > novel "trick" that directs PRR fast recovery to > > effectively > > > use slow > > > start in this case at hand. > > > > > > > > > > In other words, I am not seeing a case that requires > > new > > > congestion > > > > control concepts except as discussed in 9.3. > > > > > > See above. The change in standard congestion control for > > > (2). > > > The draft intends not to change congestion control but > > > effectively it > > > does without any operational evidence. > > > > > > What's also is missing and would be very useful: > > > > > > - For (1), a hint for an implementer saying that because > > > RACK-TLP is > > > able to detect a loss of a rexmit unlike any other > > loss > > > detection > > > algorithm, the sender MUST react twice to congestion > > > (and cite > > > RFC 5681). And cite a document where necessary > > correct > > > actions > > > are described. > > > > > > - For (1), advise that an implementer needs to keep > > track > > > when it > > > detects a loss of a retransmitted segment. Current > > > algorithms > > > in the draft detect a loss of retransmitted segment > > > exactly in > > > the same way as loss of any other segment. There > > seems > > > to be > > > nothing to track when a retransmission of a > > > retransmitted segment > > > takes place. Therefore, the algorithms should have > > > additional > > > actions to correctly track when such a loss is > > detected. > > > > > > - For (1), discussion on how many times a loss of a > > > retransmission > > > of the same segment may occur and be detected. Seems > > > that it > > > may be possible to drop a rexmitted segment more than > > > once and > > > detect it also several times? What are the > > > implications? > > > > > > - If previous is possible, then the algorithm possibly > > also > > > may detect a loss of a new segment that was sent > > during > > > fast > > > recovery? This is also loss in two successive windows > > of > > > data, > > > and cwnd MUST be lowered twice. This discussion and > > > necessary > > > actions to track it are missing, if such scenario is > > > possible. > > > > > > > What am I missing? > > > > > > Hope the above helps. > > > > > > /Markku > > > > > > > > > > > > > > > > > > > > > --000000000000baf22c05b6aaab91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Markku,

Thanks, now I und= erstand your objections.

Martin
On Thu, D= ec 17, 2020 at 12:46 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:
Hi,

On Wed, 16 Dec 2020, Martin Duke wrote:

> I spent a little longer looking at the specs more carefully, and I exp= lained (1)
> incorrectly in my last two messages. P21..29 are not Limited Transmit = packets.=C2=A0

Correct. Just normal the rule that allows sending new data during fast
recovery.

> However, unless I'm missing something else, 6675 is clear that the= recovery period
> does not end until the cumulative ack advances, meaning that detecting= the lost
> retransmission of P1 does not trigger another MD directly.

As I have said earlier, RFC 6675 does not repeat all congestion control principles from RFC 5681. It definitely honors the CC principle that
requires to treat a loss of a retransmission as a new congestion
indication and another MD. I believe I am obligated to know this as a
co-author of RFC 6675. ;)

RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the abstract:

" ... conforms to the spirit of the current congestion control
=C2=A0 specification (RFC 5681 ..."

And in the intro:

=C2=A0 =C2=A0"The algorithm specified in this document is a straightfo= rward
=C2=A0 =C2=A0 SACK-based loss recovery strategy that follows the=C2=A0 guid= elines
=C2=A0 =C2=A0 set in [RFC5681] ..."

I don't think there is anything unclear in this.

RFC 6675 and all other standard congestion controls (RFC 5581 and RFC
6582) handle a loss of a retransmission by "enforcing" RTO to det= ect it.
And RTO guarantees MD. RACK-TLP changes the loss detection in this case and therefore the standard congestion control algorithms do not have
actions to handle it corrrectly. That is the point.

BR,

/Markku

> Thanks for this exercise! It's refreshed my memory of these detail= s after working
> on slightly different QUIC algorithms a long time.
>
> On Wed, Dec 16, 2020, 18:55 Martin Duke <martin.h.duke@gmail.com> wrote: > (1) Flightsize: in RFC 6675. Section 5, Step 4.2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4.2) ssthresh =3D cwnd =3D (FlightSize / 2= )
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The congestion window = (cwnd) and slow start threshold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ssthresh) are reduced= to half of FlightSize per [RFC5681].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionally, note tha= t [RFC5681] requires that any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segments sent as part = of the Limited Transmit mechanism not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be counted in FlightSi= ze for the purpose of the above
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equation.
>
> IIUC the segments P21..P29 in your example were sent because of Limite= d
> Transmit, and so don't count. The flightsize for the purposes of (= 4.2) is
> therefore 20 after both losses, and the cwnd does not go up on the sec= ond
> loss.
>
> (2)
> " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and=
> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn=
> about."
>
> "Significant loss event" is the key phrase here. The intent = of TLP/PTO is to
> equalize the treatment of a small packet loss whether it happened in t= he
> middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical=
> extension of fast retransmit, which also modified the RTO paradigm. Th= e
> working group consensus is that this is a feature, not a bug; you'= re welcome
> to feel otherwise but I suspect you're in the rough here.
>
> Regards
> Martin
>
>
> On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See inline.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 16 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There is a ton here, but I'll try t= o address the top points.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> they obviate the rest.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for being verbose. I tried to be clear= but you actually
>=C2=A0 =C2=A0 =C2=A0 =C2=A0removed my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key issues/questions ;)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "Hmm, not sure what you mean by &q= uot;this is a new loss detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> But anyway, RFC 5681 gives the general = principle to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> ssthresh twice if a retransmission is l= ost but IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> who have designed new loss recovery and= CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> agree) that it is hard to get things ri= ght if only congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> principles are available and no algorit= hm."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So 6675 Sec 5 is quite explicit that th= ere is only one cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduction
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> per fast recovery episode, which ends o= nce new data has been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be more precise: fast recovery ends when = the current window
>=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cumulatively acknowledged, that is,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(4.1) RecoveryPoint (=3D HighData at the beg= inning) becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledged
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we agree and you meant this althou= gh new data below
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RecoveryPoint may become cumulatively acknow= ledged already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during the fast recovery. Reno loss recovery= in RFC 5681 ends,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(any) new data has been acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition, if a retransmission is l= ost it is because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> newer data has been acknowledged, so it= 's a new recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure where you have this definition? New= er than what are you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0referring to?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But, yes, if a retransmission is lost with R= FC 6675 algorithm,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it requires RTO to be detected and definitel= y starts a new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. That is, a new recovery episode is = enforced by step
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1.a) of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0NextSeg () which prevents retransmission if = a segment that has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0been retransmitted. If RACK-TLP is used for = detecting loss with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0things get different in many ways, because i= t may detect loss of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission. It would pretty much require= an entire redesign
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the algorith. For example, calculation of= pipe does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments that have been retransmitted more t= han once.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Meanwhile, during the Fast Recovery per= iod the incoming acks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> remove data from the network and theref= ore keep flightsize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0low.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Incorrect. FlightSize !=3D pipe. Only cumula= tive acks remove data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize and new data transmitted during f= ast recovery inflate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. How FlightSize evolves depends o= n loss pattern as I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0said.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0It is also possible that FlightSize is low, = it may err in both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0directions. A simple example can be used as = a proof for the case
>=C2=A0 =C2=A0 =C2=A0 =C2=A0where
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd increases if a loss of retransmission i= s detected and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 recovery with RACK-TLP loss detecti= on:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(contains some inaccuracies because it has n= ot been defined how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost rexmits are calculated into pipe)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D20; packets P1,...,P20 in flight =3D = current window of data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 dropped and rexmit of P1 will also be dr= opped]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of P1 detected after one RTT from orig= inal xmit of P1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd=3Dssthresh=3D10]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0P1 is rexmitted (and it logically starts nex= t window of data)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAcks w/ SACK for original P3..11 arrive >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/ SACK for original P12 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd-pipe =3D 10-9 >=3D1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P21
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P13 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P20 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[FlightSize=3D29]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Ack for rexmit of P1 would arrive here unle= ss it got dropped)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P21 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of rexmit P1 detected after one RTT fr= om rexmit of P1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SET cwnd =3D ssthresh =3D FlightSize/2=3D 29= /2 =3D 14,5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CWND INCREASES when it should be at most 5 a= fter halving it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0twice!!!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> We can continue to go around on our int= erpretation of these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0documents,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> but fundamentally if there is ambiguity= in 5681/6675 we should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> those RFCs rather than expand the scope= of RACK.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I said earlier, I am not opposing bis, th= ough 5681bis wuold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be needed, I think.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But let me repeat: if we publish RACK-TLP no= w without necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0warnings
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or with a correct congesion control algorith= m someone will try
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement RACK-TLP with RFC 6675 and it will= be a total mesh.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior will be unpredictable and quite lik= ely unsafe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control behavior.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a non-RACK-TLP implementation= timer (RTO) expires:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a RACK_TLP implementation tim= er (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> normal fast recovery is entered (unless= implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> also PRR). So no RTO recovery as explic= itly stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There may be a misunderstanding here. P= TO is not the same as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTO, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> both mechanisms exist! The loss respons= e to a PTO is to send a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0probe;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO response is as with conventiona= l TCP. In Section 7.3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0No, I don't think I misunderstood. If yo= u call timeout with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0another name, it is still timeout. And conge= stion control does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider which segments to send (SND.UNA vs.= probe w/ higher
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number), only how much is sent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You ignored my major point where I decoupled= congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection and loss recovery and compared RFC= 5681 behavior to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior in exactly the same scenario where = an entire flight is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer expires.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Please comment why congestion control behavi= or is allowed to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0radically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0different in these two implementations?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 & RFC 6298 timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTT= VAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2= *SRTT,RTO) (PTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If FlightSize is 100 segments when timer exp= ires, congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same in steps 1-3, but in step 4 the sta= ndard congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0allows transmitting 2 segments, while RACK-T= LP would allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasting 50 segments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> After attempting to send a loss probe, = regardless of whether a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 probe was sent, the sender= MUST re-arm the RTO timer, not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 timer, if FlightSize is no= t zero.=C2=A0 This ensures RTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery remains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the last resort if TLP fai= ls.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not prevent the above RACK-TLP beh= avior from getting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0realized.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So a pure RTO response exists in the ca= se of persistent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> causes losses of probes or their ACKs.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, RTO response exists BUT only after RACK= -TLP at least once
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasts the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network. It may well be that with smaller wi= ndows RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0successful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during its TLP initiated overly aggressive &= quot;fast recovery" and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enters RTO recovery because it may detect an= d repair also loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits. That is, it continues at too high r= ate even if lost
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate that congestion persists in success= ive windows of data.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worse, it is successful because it pushes aw= ay other compatible
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0flows by being too aggressive and unfair. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even a single shot burst every time there is= significant loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0event is not acceptable, not to mention cont= inuous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0aggressiveness, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this is exactly what RFC 2914 and RFC 5033 e= xplicitly address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and warn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Are we ignoring these BCPs that have IETF co= nsensus?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And the other important question I'd lik= e to have an answer:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What is the justification to modify standard= TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use fast recovery instead of slow start for = a case where timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed to detect the packet losses because t= here is no feedback
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and ack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0clock is lost? RACK-TLP explicitly instructs= to do so in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I noted: based on what is written in the = draft it does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intend to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0change congestion control but effectively it= does.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Martin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Dec 16, 2020 at 11:39 AM Markku= Kojo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<kojo@cs.helsinki.fi>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 De= c 2020, Martin Duke wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markk= u,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks f= or the comments. The authors will incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggesti= ons after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There= 9;s one thing I don't understand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " T= hat is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where ca= n an implementer find advice for correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions = with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a lo= ss of rexmitted segment is detected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an e= ntire flight of data gets dropped (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0that is, when there is no feedback available and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0is needed to detect the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section = 9.3 is the discussion about CC, and is clear
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implemen= ter should use either 5681 or 6937.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite n= it: RFC 5681 provides basic CC concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful C= C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines bu= t given that RACK-TLP MUST implement SACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is n= ot that useful and an implementer quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the al= gorithm in RFC 6675 (and not RFC 6937 at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing = PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 = is not mentioned in Sec 9.3, though it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requi= rements).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went= through the 6937 case in detail.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but with= out correct CC actions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681,= it's pretty clear to me that in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detectio= n after acknowledgment of new data, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second h= alving of cwnd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure= what you mean by "this is a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection aft= er
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgmen= t of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, R= FC 5681 gives the general principle to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twic= e if a retransmission is lost but IMHO (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have desi= gned new loss recovery and CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented t= hem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that i= t is hard to get things right if only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles ar= e available and no algorithm.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That's wh= y ALL mechanisms that we have include a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algo= rithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all nece= ssary variables and actions for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and= often also pseudocode). Like this document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the proble= m is that we do not have a detailed enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tel= ls exactly what to do when a loss of rexmit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, t= he algorithms in RFC 5681 and RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) = of RFC 5681 to reduce ssthresh and cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a c= ongestion control action is detected:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd = =3D) ssthresh =3D FlightSize / 2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 = gives a warning not to halve cwnd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this= equation is what an implementer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading = the relevant RFCs but it gives a wrong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding d= ata when in fast recovery (when the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion av= oidance and the equation (4) is used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a corre= ct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisel= y, during fast recovery FlightSize is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent = and reduced when segments are cumulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outc= ome is depends on the loss pattern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is= signficantly larger than in the beginning
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when= FlightSize was (correctly) used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwn= d and ssthresh, i.e., equation (4) may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* = cwnd upon detecting a loss of a rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, inst= ead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further ha= lving it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever impl= ementer might have no problem to have it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but = I am afraid that there will be incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementatio= ns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is = currently specified. Not all implementers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant f= raction of their career in solving TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2),= the RTO timer is still operative so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO = recovery rules would still follow.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a n= on-RACK-TLP implementation timer (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd= =3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow star= t is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a R= ACK_TLP implementation timer (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast r= ecovery is entered (unless implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So= no RTO recovery as explicitly stated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means th= at this document explicitly modifies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when = there are no acks coming and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DS= RTT+4*RTTVAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. RTO timer expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2= =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. PTO times expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, = if FlightSize is 100 segments when timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol is the same in steps 1-3, but in step
>=C2=A0 =C2=A0 =C2=A0 =C2=A04
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current stand= ard congestion control allows transmitting
>=C2=A0 =C2=A0 =C2=A0 =C2=A02
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TL= P would allow blasting 50 segments.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: = what is the justification to modify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol to use fast recovery instead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where ti= meout is needed to detect loss because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and = ack clock is lost? The draft does not give
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification= . This clearly is in conflict with items
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (R= FC 5033).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, = there is no implementation nor experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating th= is change. The implementation with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental = experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC= 6937) which is an Experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "t= rick" that directs PRR fast recovery to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this= case at hand.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other= words, I am not seeing a case that requires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control = concepts except as discussed in 9.3.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. Th= e change in standard congestion control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft int= ends not to change congestion control but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively i= t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without = any operational evidence.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's al= so is missing and would be very useful:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a = hint for an implementer saying that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= able to detect a loss of a rexmit unlike any other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= algorithm, the sender MUST react twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= RFC 5681). And cite a document where necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= are described.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), ad= vise that an implementer needs to keep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detects a loss of a retransmitted segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= in the draft detect a loss of retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= the same way as loss of any other segment. There
>=C2=A0 =C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= nothing to track when a retransmission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted= segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= takes place. Therefore, the algorithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to correctly track when such a loss is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), di= scussion on how many times a loss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= of the same segment may occur and be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may be possible to drop a rexmitted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detect it also several times?=C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous= is possible, then the algorithm possibly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may detect a loss of a new segment that was sent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= recovery? This is also loss in two successive windows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= and cwnd MUST be lowered twice. This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to track it are missing, if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am = I missing?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the abov= e helps.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <snipping the rest>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>
>
--000000000000baf22c05b6aaab91-- From nobody Thu Dec 17 08:27:53 2020 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 0E3F73A0BAD for ; Thu, 17 Dec 2020 08:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 cRSCru0QnyWd for ; Thu, 17 Dec 2020 08:27:47 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 2B73D3A0BA4 for ; Thu, 17 Dec 2020 08:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XJIYtKrjds5lObx5iYIXzHsv69tV2GFJS7BB56J8unM=; b=Tn6MLM89fMUJoBSlO/L6RJ97y scqljusjwSw9yyWdGuWo7yUbz0XLFAKA6Zq0ust7/kiUhMiuOHENNQ+bsRt1ewI9sOJnQlLVwjKwm JeUxm5BbYlJOYCxRcXmNebsCMxNoHDU0bIqvZMj/oIJJ+kAAx/w3wiFO4D8r/GOUndYkJ7q2CohBq CwdKb4sHWKnhD2RMIxswgIsAQx2qfiSEZzA36Vr342CBueAfZg4gGuuTBfwOpQMGNXoZEeEKn5YkQ dHYRNj83Dz76jfNAnk2Clqzup0MU7TYXu8ruI6uwne38/HnqmHjD9kSip2bfGHCOuefbMI9hfWEkA GSO+kyofg==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53820 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kpw7y-001eSO-8D; Thu, 17 Dec 2020 11:27:46 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_63C52A8F-B2DB-417C-B041-9FEFC4C7AB79" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\)) From: Joseph Touch In-Reply-To: Date: Thu, 17 Dec 2020 08:27:41 -0800 Cc: tcpm@ietf.org Message-Id: References: <1716cf53-f4a9-e23b-804c-1f1e08a82d9f@mti-systems.com> <83CDFDB3-D743-41FD-87F2-DCA929DA4278@strayalpha.com> <68B1C03F-71F6-4854-B0F8-AE9D4121E9E2@strayalpha.com> To: Wes Eddy X-Mailer: Apple Mail (2.3654.20.0.2.21) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: 793bis: add SHOULD on other common options X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 16:27:51 -0000 --Apple-Mail=_63C52A8F-B2DB-417C-B041-9FEFC4C7AB79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 17, 2020, at 5:08 AM, Wesley Eddy wrote: >=20 > On 12/11/2020 2:25 PM, Ian Swett wrote: >>=20 >> On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch > wrote: >>=20 >>=20 >>> On Dec 11, 2020, at 8:56 AM, Ian Swett = > wrote: >>>=20 >>> In my opinion, we already have an issue, because a non-normative = 'recommended' is used. A reasonable reading is this was intended as the = normative RECOMMENDED, but no one ever bothered to capitalize it, but it = seems there's some disagreement on whether that was the case. >>=20 >> Except that this RFC actually already includes the following = *explicit* language: >>=20 >> In this document, these words will appear with that interpretation >> only when in UPPER CASE. Lower case uses of these words are not = to >> be interpreted as carrying [RFC2119 = ] significance. >>=20 >> Ok, well that's unusual. > I don't know where you're seeing that text exactly. The current = 793bis draft has the BCP 14 boilerplate text, just like most other IETF = documents. Not 793bis. We had been talking about the source of these common options - RFC7323. That doc uses =E2=80=9Crecommended=E2=80=9D but explicitly = differentiates that from =E2=80=9CRECOMMENDED=E2=80=9D. Joe --Apple-Mail=_63C52A8F-B2DB-417C-B041-9FEFC4C7AB79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Dec 17, 2020, at 5:08 AM, Wesley Eddy <wes@mti-systems.com>= wrote:

=20 =20
On 12/11/2020 2:25 PM, Ian Swett = wrote:

On Fri, Dec 11, 2020 at 12:52 PM Joseph Touch <touch@strayalpha.com> wrote:


On Dec 11, 2020, at 8:56 AM, Ian Swett = <ianswett=3D40google.com@dmarc.ietf.org> wrote:

In my opinion, we = already have an issue, because a non-normative 'recommended' is used.  A reasonable reading is this was = intended as the normative RECOMMENDED, but no one ever bothered to capitalize it, but it seems there's some disagreement on whether that was the = case.

Except that this RFC actually already = includes the following *explicit* language:

   In this document, these words will appear with that =
interpretation
   only when in UPPER CASE.  Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.

Ok, well that's unusual.

I don't know where you're seeing that = text exactly.  The current 793bis draft has the BCP 14 boilerplate text, just like most other IETF documents.

Not 793bis.

We had been talking about the source of these = common options - RFC7323.

That doc uses =E2=80=9Crecommended=E2=80=9D = but explicitly differentiates that = from =E2=80=9CRECOMMENDED=E2=80=9D.

Joe


= --Apple-Mail=_63C52A8F-B2DB-417C-B041-9FEFC4C7AB79-- From nobody Thu Dec 17 09:55:02 2020 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 129E13A0E54; Thu, 17 Dec 2020 09:55:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rack@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rack.all@ietf.org, tuexen@fh-muenster.de X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160822770059.15041.16286115220871304513@ietfa.amsl.com> Date: Thu, 17 Dec 2020 09:55:01 -0800 Archived-At: Subject: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 17:55:01 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tcpm-rack-14: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for presenting this complicated topic in a very easy-to-read manner! Section 3.3.2 1. The reordering window SHOULD be set to zero if no reordering has been observed on the connection so far, and either (a) three segments have been delivered out of order since the last recovery I assume there's some subtle technical difference between "reordering" and "segments delivered out of order" that makes this a reasonable thing to say ... but it would be nice if the distincion was made more clear (whether here or in earlier text). Section 6.2 Among all the segments newly ACKed or SACKed by this ACK that pass the checks above, update the RACK.rtt to be the RTT sample calculated using this ACK. Furthermore, record the most recent Segment.xmit_ts in RACK.xmit_ts if it is ahead of RACK.xmit_ts. If Segment.xmit_ts equals RACK.xmit_ts (e.g. due to clock granularity limits) then compare Segment.end_seq and RACK.end_seq to break the tie. Perhaps we should state what the result of breaking the tie is used for (i.e., updating RACK.segment & co.)? To avoid the issue above, RACK dynamically adapts to higher degrees of reordering using DSACK options from the receiver. Receiving an ACK with a DSACK option indicates a possible spurious retransmission, suggesting that RACK.reo_wnd may be too small. The RACK.reo_wnd increases linearly for every round trip in which the sender receives some DSACK option, so that after N distinct round trips in which a DSACK is received, the RACK.reo_wnd becomes (N+1) * min_RTT / 4, with an upper-bound of SRTT. What constitutes a "distinct round trip"? Return min(RACK.min_RTT / 4 * RACK.reo_wnd_mult, SRTT) I suggest reordering the expression to be min(RACK.reo_wnd_mult * RACK.min_RTT / 4, SRTT), to avoid needing to consider the order of operations and operator precedence in the pseudocode. (soapbox: in formal mathematics, there is no "division" operation, just multiplication by the multiplicative inverse, in part because it makes dealing with associativity and commutativity of operations harder to reason about.) Section 8 sender SHOULD cancel any other pending timer(s). An implementation is to have one timer with an additional state variable indicating the type of the timer. nit: maybe "is expected to have one timer", to avoid any risk of being interpreted as over-specifying implementation behavior? Is there anything to say about increasing the usage of fast recovery (vs RTO) potentially having an aggregate effect globally on how much data is in flight and increasing the overall risk of congestion? (I mostly assume not, but it's kind of my job to ask.) Section 13.1 In terms of how we reference it, RFC 3042 seems like it could be informative. From nobody Thu Dec 17 10:52:12 2020 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 AB1A63A0B21; Thu, 17 Dec 2020 10:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Zxl35cOdCufL; Thu, 17 Dec 2020 10:52:02 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640137.outbound.protection.outlook.com [40.107.64.137]) (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 7CDE63A0E28; Thu, 17 Dec 2020 10:52:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c7EQNZIH++66jjgzsLm9YL1DdWSGtuONI+7UNY3FmOqoBqVvLZQRZVEMPrT2waq7iI7SAqJlEYUqa2JOdO8iSLtWd/4ldWd4CkfPTFpuNYMKEfvzEq7OkPC5MCggmaBJZori8TO6hqSIMUXtJZcxEe67BXf9YU/LslTBMKGTuHA++V3B8DNdOCfU/WUHDc1Nk7QS+8pP+PHNcIy8gY9xbM/yQWGn7UIKJvv5iy4UGVAW/WBBxr6HicIHicYRVA+nv4lkfVK0oXAwvn47ZJ8GjLHWU5IXKynpfjT7YRw0DF5Bw3L0JtA3fqhLzLNXyRi/Kq+mwJ/GAAagnVy/6cKL9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OiMgI1KVTR+NEJQuG69LX5WZveeXxTtAFqmX7dyTA/E=; b=I7Atbj0945XS2Raeu7XQGamfDr0vm0GLzjFrJXvOwKYa2QJyRsQkqv1TKza5LioIqefYjaJLL2tlZfJqWJRbYyKw/uu5IPXLWJ7fnrB9xQpo19ebugQNsdPM+pOIjk3ZpVTkftJFx1A0jpBT4CKnF0KyTInXUPRMGpGco6+7TycvaqN5IDq9+RllD9XAb6nWEF3s1hJxqnVZsN5ZGXgx9mJMGqAJ4eYDwvLE1WznlIm0gG1FIvdHznbP3LD1JJwCO1gO+GmeSto/ZsAfBlJHOGossl4XtyOlSyQtkDwLFKDk0wInfXvdMjgbpBSoJfcKQbgVnBzTM/mCjOZKtnL5qA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OiMgI1KVTR+NEJQuG69LX5WZveeXxTtAFqmX7dyTA/E=; b=H2mPsoo10JZWhOzWKSi45Hskowu1YMudJEhSoUrb++B2GOzfRYLLnrVJyqkNRE2niIpUCH8JU8/JLEldqtFighO/R9TpkRgGnY4Xxt7g8gJzAx9P1LDPaFBKCDthbEZdmTbZ15ajJ0P/ZWzYVymb3Y/PbOcVMd4j45sEcVj/Ne4= Received: from (2a01:111:e400:c639::6) by CY1PR00MB0089.namprd00.prod.outlook.com (2a01:111:e400:c619::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3716.0; Thu, 17 Dec 2020 18:51:46 +0000 Received: from CY1PR00MB0172.namprd00.prod.outlook.com ([fe80::ad2a:2fe0:262c:e76f]) by CY1PR00MB0172.namprd00.prod.outlook.com ([fe80::ad2a:2fe0:262c:e76f%8]) with mapi id 15.20.3720.000; Thu, 17 Dec 2020 18:51:46 +0000 From: Praveen Balasubramanian To: "martin.h.duke@gmail.com" , "kojo@cs.helsinki.fi" CC: "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [EXTERNAL] Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard Thread-Index: AQHW1FF01btI7SQGVkejFRzXPAuBhKn7amWAgAA3ZGA= Date: Thu, 17 Dec 2020 18:51:46 +0000 Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=09440963-fd55-4d9d-9a4e-31f9b55d9629; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-17T18:48:29Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9:95cf:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c873fe82-ef30-46db-d242-08d8a2bccde7 x-ms-traffictypediagnostic: CY1PR00MB0089: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qe2zaublk/yf/0AVwz6+BFWhn+96gkIu72JxjSWADlXqMZ6UfY+Q2Vdvsd4HBfORu89Xt9gcnueF/FoDfuXqBnCcU/kPfq0VCXofaLPTG7WkgQyHXmrrGhTBiQ2oMXghbM9fI3DyCQ+dUeafD2lhP6mu7VklCT3Grs7/YmV/yIVZI/sJZauonbnDuhOC5SuO7XNjIxuzM/6ptEBdVVdH216/I91onIE3vWXhOWpVdBW9QvM+y//KKk+dl4p3BqAHs7EZhR4xjRiyBHQi7dghxpy6Uu80GOIDxUAgPZX+rnrXVr0qrU2HoyQBjztqq8JgcdQF/yCfCzINbBxUiO/zPp2AKsOCm6rmKaAbh5lzmNqq4tNJqjUer0o4wsH5FEJ0EM18fLE2KB/0BnugptOXW7orO9tVJ0efreuxZylIT7S15Yvpa+usaj7HkEf/YsxvHMqb3SAe8JpSvcMfRUXBHw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY1PR00MB0172.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(396003)(376002)(136003)(346002)(71200400001)(66556008)(186003)(30864003)(66446008)(8936002)(10290500003)(7696005)(9686003)(76116006)(4326008)(2906002)(55016002)(52536014)(8990500004)(6506007)(33656002)(110136005)(8676002)(5660300002)(66946007)(53546011)(66476007)(82960400001)(82950400001)(83380400001)(54906003)(316002)(478600001)(64756008)(86362001)(61000200002)(579004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?NUF4RkY4VDRjRXdZTmpRd1BlTHpMYVo5eVQzWWUzSFBMVVFyalpJWVRWQkFQ?= =?utf-8?B?UmNaMHM3K1FhOUpHRThjYUxRM0xiYVlaU3o0WUlJYmw3d0VVeGxyVGxQM1pS?= =?utf-8?B?dWNMTjdXOWxpL0JJeUFTVnFrcGhoRGU5czBqR3hhUE5lUGxaeHkxZ1lkR0M1?= =?utf-8?B?OVFyWDU2WlVGMTYzbnYzQisvUGM0ZUJxZllnbkpsZGcySTJFdlpoaVlkbUNE?= =?utf-8?B?ZDNJK2JlME1oM3Y0ZEdXREw0Z2lSMzVIZ3pqdlVmVW1EN0lvS3RsUGFWR2NH?= =?utf-8?B?akszQjJhdTVoSGthL0dacDMxbHZVeDZDS3AwdlB5VVd0RURUMHUrNkVTUXV6?= =?utf-8?B?NlMydlVKRm0yRkdiZWRxL1MxSXBhcGR0S09LVVhQVDlDdmw4OGx6eDBVaXUy?= =?utf-8?B?c2xmWXpTUU1UeWpMY2FMMGJ0Tzdlc1VsaEg2SXREVWVBdkVtL0JkZVpqbDhr?= =?utf-8?B?VlV2N2g0Ymd2ZkV6blYrajNJYzlEZDBwbkVsazhZWUZIZW83cEtNUml4cDZU?= =?utf-8?B?TFBiK2VpOW5RRTFvdkorenVmNlYrWkl1N3NmYjlGUkF5MnZYVXJhTHpVNkNl?= =?utf-8?B?WFNobTBCb0czNHBKUCswWkZoZWFOT3Y0dUNWTDhIOWhPc3JPRW5FOEtBcUtG?= =?utf-8?B?SnhVQ0dlcCs2MGhMajBSdzJmWUZGRXo3ajE2VlVkTFRtNFN6VW4rSHRteTly?= =?utf-8?B?M1pnNHd2bEV0ZUtsWkRSd2I1bDdGSG4wZW9lSGVETjdYSjFHc29qUGhxN3FQ?= =?utf-8?B?czBJOWltTTVzMS9Xc3RTbVk2NW5xZEsyZ0FYTmMxMUI5UG1YN0dXc3VGMTNT?= =?utf-8?B?OWVpaFJUcDZtaGM1dklIZnR1ako4OFlGSFJYR2FRUUUzM0MyMDBlVzdQeGR0?= =?utf-8?B?RDk1MFk2RElWb1VyZUJsYytPbEVmaTBNOWhFajR0VnovYm5HQ2JLd2IrN0t0?= =?utf-8?B?M1dsZUVDRXNhckM0bjltRVh0YitmQ01pUE9mdzNDVE45SWM4YXZyS2gwdWIx?= =?utf-8?B?eENmVkxqUGIxeXk3d3JmM0ZKRlkxMDY3YTUzWHZ3NGxGcFFvRnBtekYvWE9j?= =?utf-8?B?VVBMZGppdzh1U3F5UVdVcjEzYW5Ia2ZZdzRqd0c0OG9KT252aWRJTFRQdkQ4?= =?utf-8?B?VlRFWmszZU9za0ZFTVh0Smx2Mmp6bHMxUkVGOW4wU0ZTbVpRVFV0WXFyMm1E?= =?utf-8?B?SDBCTmU3ellXc0RwMnUwUUhMNU4zaW16U25TWlpDMEZrY3pGdGhJRCt0eUVi?= =?utf-8?B?SjVUYzkrYzVQNitRenlzZ05PaE96YldESmVFcURRcWxKdGZBS3NTTDdmU2M3?= =?utf-8?B?VFk1blpaaFVGWnhaRnc4ZG5jY1YxcnRBY1dtVmdnNzR2cFpMczhPSXZOMHZr?= =?utf-8?B?V0piNjZTMktKQUpLa2dHaHpkaU84RjBibXlPVlhjV3BKVXJ0REpOZU93SEg5?= =?utf-8?B?ajJGTzdTR0pGcXpjZ2ZGY1dkZ200TFgrc3VXV2Z4RVFHWnFaTWZqYmhRMUJo?= =?utf-8?Q?dDW7I13P2+0WcjafK+Xg465MXXb?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0172182657354535DF24E790B6C49CY1PR00MB0172namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CY1PR00MB0172.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c873fe82-ef30-46db-d242-08d8a2bccde7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 18:51:46.4308 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tqbV+2BoDenk6l+vDbTdaL/jGP32ctTNtFD2cea4t6I807tLMEBhvcAzgZYZzJBfFojvhpU60yEsYlvQnIIqJRkwRHjGnF1yGrz+LLlrplQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0089 Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 18:52:06 -0000 --_000_CY1PR00MB0172182657354535DF24E790B6C49CY1PR00MB0172namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIGEgbm90ZSBpbiB0aGlzIFJGQyBhYm91dCBjb25n ZXN0aW9uIGNvbnRyb2wgYWN0aW9uIHVwb24gZGV0ZWN0aW5nIGxvc3QgcmV0cmFuc21pc3Npb24o cykuDQoNCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIE1h cnRpbiBEdWtlDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTcsIDIwMjAgNzozMCBBTQ0KVG86 IE1hcmtrdSBLb2pvIDxrb2pvQGNzLmhlbHNpbmtpLmZpPg0KQ2M6IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9ucyA8dGNwbUBpZXRmLm9yZz47IGRyYWZ0LWlldGYtdGNwbS1yYWNrQGlldGYub3JnOyBN aWNoYWVsIFR1ZXhlbiA8dHVleGVuQGZoLW11ZW5zdGVyLmRlPjsgZHJhZnQtaWV0Zi10Y3BtLXJh Y2suYWxsQGlldGYub3JnOyBMYXN0IENhbGwgPGxhc3QtY2FsbEBpZXRmLm9yZz47IHRjcG0tY2hh aXJzIDx0Y3BtLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFt0Y3Bt XSBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXRjcG0tcmFjay0xMy50eHQ+KFRoZVJBQ0stVExQbG9z c2RldGVjdGlvbmFsZ29yaXRobWZvclRDUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSGkgTWFy a2t1LA0KDQpUaGFua3MsIG5vdyBJIHVuZGVyc3RhbmQgeW91ciBvYmplY3Rpb25zLg0KDQpNYXJ0 aW4NCg0KT24gVGh1LCBEZWMgMTcsIDIwMjAgYXQgMTI6NDYgQU0gTWFya2t1IEtvam8gPGtvam9A Y3MuaGVsc2lua2kuZmk8bWFpbHRvOmtvam9AY3MuaGVsc2lua2kuZmk+PiB3cm90ZToNCkhpLA0K DQpPbiBXZWQsIDE2IERlYyAyMDIwLCBNYXJ0aW4gRHVrZSB3cm90ZToNCg0KPiBJIHNwZW50IGEg bGl0dGxlIGxvbmdlciBsb29raW5nIGF0IHRoZSBzcGVjcyBtb3JlIGNhcmVmdWxseSwgYW5kIEkg ZXhwbGFpbmVkICgxKQ0KPiBpbmNvcnJlY3RseSBpbiBteSBsYXN0IHR3byBtZXNzYWdlcy4gUDIx Li4yOSBhcmUgbm90IExpbWl0ZWQgVHJhbnNtaXQgcGFja2V0cy4NCg0KQ29ycmVjdC4gSnVzdCBu b3JtYWwgdGhlIHJ1bGUgdGhhdCBhbGxvd3Mgc2VuZGluZyBuZXcgZGF0YSBkdXJpbmcgZmFzdA0K cmVjb3ZlcnkuDQoNCj4gSG93ZXZlciwgdW5sZXNzIEknbSBtaXNzaW5nIHNvbWV0aGluZyBlbHNl LCA2Njc1IGlzIGNsZWFyIHRoYXQgdGhlIHJlY292ZXJ5IHBlcmlvZA0KPiBkb2VzIG5vdCBlbmQg dW50aWwgdGhlIGN1bXVsYXRpdmUgYWNrIGFkdmFuY2VzLCBtZWFuaW5nIHRoYXQgZGV0ZWN0aW5n IHRoZSBsb3N0DQo+IHJldHJhbnNtaXNzaW9uIG9mIFAxIGRvZXMgbm90IHRyaWdnZXIgYW5vdGhl ciBNRCBkaXJlY3RseS4NCg0KQXMgSSBoYXZlIHNhaWQgZWFybGllciwgUkZDIDY2NzUgZG9lcyBu b3QgcmVwZWF0IGFsbCBjb25nZXN0aW9uIGNvbnRyb2wNCnByaW5jaXBsZXMgZnJvbSBSRkMgNTY4 MS4gSXQgZGVmaW5pdGVseSBob25vcnMgdGhlIENDIHByaW5jaXBsZSB0aGF0DQpyZXF1aXJlcyB0 byB0cmVhdCBhIGxvc3Mgb2YgYSByZXRyYW5zbWlzc2lvbiBhcyBhIG5ldyBjb25nZXN0aW9uDQpp bmRpY2F0aW9uIGFuZCBhbm90aGVyIE1ELiBJIGJlbGlldmUgSSBhbSBvYmxpZ2F0ZWQgdG8ga25v dyB0aGlzIGFzIGENCmNvLWF1dGhvciBvZiBSRkMgNjY3NS4gOykNCg0KUkZDIDY2NzUgZXhwbGlj aXRseSBpbmRpY2F0ZXMgdGhhdCBpdCBmb2xsb3dzIFJGQyA1NjgxIGJ5IHN0YXRpbmcgaW4gdGhl DQphYnN0cmFjdDoNCg0KIiAuLi4gY29uZm9ybXMgdG8gdGhlIHNwaXJpdCBvZiB0aGUgY3VycmVu dCBjb25nZXN0aW9uIGNvbnRyb2wNCiAgc3BlY2lmaWNhdGlvbiAoUkZDIDU2ODEgLi4uIg0KDQpB bmQgaW4gdGhlIGludHJvOg0KDQogICAiVGhlIGFsZ29yaXRobSBzcGVjaWZpZWQgaW4gdGhpcyBk b2N1bWVudCBpcyBhIHN0cmFpZ2h0Zm9yd2FyZA0KICAgIFNBQ0stYmFzZWQgbG9zcyByZWNvdmVy eSBzdHJhdGVneSB0aGF0IGZvbGxvd3MgdGhlICBndWlkZWxpbmVzDQogICAgc2V0IGluIFtSRkM1 NjgxXSAuLi4iDQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcgdW5jbGVhciBpbiB0 aGlzLg0KDQpSRkMgNjY3NSBhbmQgYWxsIG90aGVyIHN0YW5kYXJkIGNvbmdlc3Rpb24gY29udHJv bHMgKFJGQyA1NTgxIGFuZCBSRkMNCjY1ODIpIGhhbmRsZSBhIGxvc3Mgb2YgYSByZXRyYW5zbWlz c2lvbiBieSAiZW5mb3JjaW5nIiBSVE8gdG8gZGV0ZWN0IGl0Lg0KQW5kIFJUTyBndWFyYW50ZWVz IE1ELiBSQUNLLVRMUCBjaGFuZ2VzIHRoZSBsb3NzIGRldGVjdGlvbiBpbiB0aGlzIGNhc2UNCmFu ZCB0aGVyZWZvcmUgdGhlIHN0YW5kYXJkIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGRv IG5vdCBoYXZlDQphY3Rpb25zIHRvIGhhbmRsZSBpdCBjb3JycmVjdGx5LiBUaGF0IGlzIHRoZSBw b2ludC4NCg0KQlIsDQoNCi9NYXJra3UNCg0KPiBUaGFua3MgZm9yIHRoaXMgZXhlcmNpc2UhIEl0 J3MgcmVmcmVzaGVkIG15IG1lbW9yeSBvZiB0aGVzZSBkZXRhaWxzIGFmdGVyIHdvcmtpbmcNCj4g b24gc2xpZ2h0bHkgZGlmZmVyZW50IFFVSUMgYWxnb3JpdGhtcyBhIGxvbmcgdGltZS4NCj4NCj4g T24gV2VkLCBEZWMgMTYsIDIwMjAsIDE4OjU1IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCj4gKDEpIEZs aWdodHNpemU6IGluIFJGQyA2Njc1LiBTZWN0aW9uIDUsIFN0ZXAgNC4yOg0KPg0KPiAgICAgICAg KDQuMikgc3N0aHJlc2ggPSBjd25kID0gKEZsaWdodFNpemUgLyAyKQ0KPg0KPiAgICAgICAgICAg ICAgVGhlIGNvbmdlc3Rpb24gd2luZG93IChjd25kKSBhbmQgc2xvdyBzdGFydCB0aHJlc2hvbGQN Cj4gICAgICAgICAgICAgIChzc3RocmVzaCkgYXJlIHJlZHVjZWQgdG8gaGFsZiBvZiBGbGlnaHRT aXplIHBlciBbUkZDNTY4MV0uDQo+ICAgICAgICAgICAgICBBZGRpdGlvbmFsbHksIG5vdGUgdGhh dCBbUkZDNTY4MV0gcmVxdWlyZXMgdGhhdCBhbnkNCj4gICAgICAgICAgICAgIHNlZ21lbnRzIHNl bnQgYXMgcGFydCBvZiB0aGUgTGltaXRlZCBUcmFuc21pdCBtZWNoYW5pc20gbm90DQo+ICAgICAg ICAgICAgICBiZSBjb3VudGVkIGluIEZsaWdodFNpemUgZm9yIHRoZSBwdXJwb3NlIG9mIHRoZSBh Ym92ZQ0KPiAgICAgICAgICAgICAgZXF1YXRpb24uDQo+DQo+IElJVUMgdGhlIHNlZ21lbnRzIFAy MS4uUDI5IGluIHlvdXIgZXhhbXBsZSB3ZXJlIHNlbnQgYmVjYXVzZSBvZiBMaW1pdGVkDQo+IFRy YW5zbWl0LCBhbmQgc28gZG9uJ3QgY291bnQuIFRoZSBmbGlnaHRzaXplIGZvciB0aGUgcHVycG9z ZXMgb2YgKDQuMikgaXMNCj4gdGhlcmVmb3JlIDIwIGFmdGVyIGJvdGggbG9zc2VzLCBhbmQgdGhl IGN3bmQgZG9lcyBub3QgZ28gdXAgb24gdGhlIHNlY29uZA0KPiBsb3NzLg0KPg0KPiAoMikNCj4g IiBFdmVuIGEgc2luZ2xlIHNob3QgYnVyc3QgZXZlcnkgdGltZSB0aGVyZSBpcyBzaWduaWZpY2Fu dCBsb3NzDQo+IGV2ZW50IGlzIG5vdCBhY2NlcHRhYmxlLCBub3QgdG8gbWVudGlvbiBjb250aW51 b3VzIGFnZ3Jlc3NpdmVuZXNzLCBhbmQNCj4gdGhpcyBpcyBleGFjdGx5IHdoYXQgUkZDIDI5MTQg YW5kIFJGQyA1MDMzIGV4cGxpY2l0bHkgYWRkcmVzcyBhbmQgd2Fybg0KPiBhYm91dC4iDQo+DQo+ ICJTaWduaWZpY2FudCBsb3NzIGV2ZW50IiBpcyB0aGUga2V5IHBocmFzZSBoZXJlLiBUaGUgaW50 ZW50IG9mIFRMUC9QVE8gaXMgdG8NCj4gZXF1YWxpemUgdGhlIHRyZWF0bWVudCBvZiBhIHNtYWxs IHBhY2tldCBsb3NzIHdoZXRoZXIgaXQgaGFwcGVuZWQgaW4gdGhlDQo+IG1pZGRsZSBvZiBhIGJ1 cnN0IG9yIHRoZSBlbmQuIFdoeSBzaG91bGQgYW4gaXNvbGF0ZWQgbG9zcyBiZSB0cmVhdGVkDQo+ IGRpZmZlcmVudGx5IGJhc2VkIG9uIGl0cyBwb3NpdGlvbiBpbiB0aGUgYnVyc3Q/IFRoaXMgaXMg anVzdCBhIGxvZ2ljYWwNCj4gZXh0ZW5zaW9uIG9mIGZhc3QgcmV0cmFuc21pdCwgd2hpY2ggYWxz byBtb2RpZmllZCB0aGUgUlRPIHBhcmFkaWdtLiBUaGUNCj4gd29ya2luZyBncm91cCBjb25zZW5z dXMgaXMgdGhhdCB0aGlzIGlzIGEgZmVhdHVyZSwgbm90IGEgYnVnOyB5b3UncmUgd2VsY29tZQ0K PiB0byBmZWVsIG90aGVyd2lzZSBidXQgSSBzdXNwZWN0IHlvdSdyZSBpbiB0aGUgcm91Z2ggaGVy ZS4NCj4NCj4gUmVnYXJkcw0KPiBNYXJ0aW4NCj4NCj4NCj4gT24gV2VkLCBEZWMgMTYsIDIwMjAg YXQgNDoxMSBQTSBNYXJra3UgS29qbyA8a29qb0Bjcy5oZWxzaW5raS5maTxtYWlsdG86a29qb0Bj cy5oZWxzaW5raS5maT4+IHdyb3RlOg0KPiAgICAgICBIaSBNYXJ0aW4sDQo+DQo+ICAgICAgIFNl ZSBpbmxpbmUuDQo+DQo+ICAgICAgIE9uIFdlZCwgMTYgRGVjIDIwMjAsIE1hcnRpbiBEdWtlIHdy b3RlOg0KPg0KPiAgICAgICA+IEhpIE1hcmtrdSwNCj4gICAgICAgPg0KPiAgICAgICA+IFRoZXJl IGlzIGEgdG9uIGhlcmUsIGJ1dCBJJ2xsIHRyeSB0byBhZGRyZXNzIHRoZSB0b3AgcG9pbnRzLg0K PiAgICAgICBIb3BlZnVsbHkNCj4gICAgICAgPiB0aGV5IG9idmlhdGUgdGhlIHJlc3QuDQo+DQo+ ICAgICAgIFNvcnJ5IGZvciBiZWluZyB2ZXJib3NlLiBJIHRyaWVkIHRvIGJlIGNsZWFyIGJ1dCB5 b3UgYWN0dWFsbHkNCj4gICAgICAgcmVtb3ZlZCBteQ0KPiAgICAgICBrZXkgaXNzdWVzL3F1ZXN0 aW9ucyA7KQ0KPg0KPiAgICAgICA+IDEuDQo+ICAgICAgID4gW01hcmtrdV0NCj4gICAgICAgPiAi SG1tLCBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJ0aGlzIGlzIGEgbmV3IGxvc3MgZGV0ZWN0 aW9uDQo+ICAgICAgIGFmdGVyDQo+ICAgICAgID4gYWNrbm93bGVkZ21lbnQgb2YgbmV3IGRhdGEi Pw0KPiAgICAgICA+IEJ1dCBhbnl3YXksIFJGQyA1NjgxIGdpdmVzIHRoZSBnZW5lcmFsIHByaW5j aXBsZSB0byByZWR1Y2UNCj4gICAgICAgY3duZCBhbmQNCj4gICAgICAgPiBzc3RocmVzaCB0d2lj ZSBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3QgYnV0IElNSE8gKGFuZCBJDQo+ICAgICAgIGJl bGlldmUgbWFueQ0KPiAgICAgICA+IHdobyBoYXZlIGRlc2lnbmVkIG5ldyBsb3NzIHJlY292ZXJ5 IGFuZCBDQyBhbGdvcml0aG1zIG9yDQo+ICAgICAgIGltcGxlbWVudGVkDQo+ICAgICAgID4gdGhl bQ0KPiAgICAgICA+IGFncmVlKSB0aGF0IGl0IGlzIGhhcmQgdG8gZ2V0IHRoaW5ncyByaWdodCBp ZiBvbmx5IGNvbmdlc3Rpb24NCj4gICAgICAgY29udHJvbA0KPiAgICAgICA+IHByaW5jaXBsZXMg YXJlIGF2YWlsYWJsZSBhbmQgbm8gYWxnb3JpdGhtLiINCj4gICAgICAgPg0KPiAgICAgICA+IFtN YXJ0aW5dDQo+ICAgICAgID4gU28gNjY3NSBTZWMgNSBpcyBxdWl0ZSBleHBsaWNpdCB0aGF0IHRo ZXJlIGlzIG9ubHkgb25lIGN3bmQNCj4gICAgICAgcmVkdWN0aW9uDQo+ICAgICAgID4gcGVyIGZh c3QgcmVjb3ZlcnkgZXBpc29kZSwgd2hpY2ggZW5kcyBvbmNlIG5ldyBkYXRhIGhhcyBiZWVuDQo+ ICAgICAgID4gYWNrbm93bGVkZ2VkLg0KPg0KPiAgICAgICBUbyBiZSBtb3JlIHByZWNpc2U6IGZh c3QgcmVjb3ZlcnkgZW5kcyB3aGVuIHRoZSBjdXJyZW50IHdpbmRvdw0KPiAgICAgICBiZWNvbWVz DQo+ICAgICAgIGN1bXVsYXRpdmVseSBhY2tub3dsZWRnZWQsIHRoYXQgaXMsDQo+DQo+ICAgICAg ICg0LjEpIFJlY292ZXJ5UG9pbnQgKD0gSGlnaERhdGEgYXQgdGhlIGJlZ2lubmluZykgYmVjb21l cw0KPiAgICAgICBhY2tub3dsZWRnZWQNCj4NCj4gICAgICAgSSBiZWxpZXZlIHdlIGFncmVlIGFu ZCB5b3UgbWVhbnQgdGhpcyBhbHRob3VnaCBuZXcgZGF0YSBiZWxvdw0KPiAgICAgICBSZWNvdmVy eVBvaW50IG1heSBiZWNvbWUgY3VtdWxhdGl2ZWx5IGFja25vd2xlZGdlZCBhbHJlYWR5DQo+ICAg ICAgIGVhcmxpZXINCj4gICAgICAgZHVyaW5nIHRoZSBmYXN0IHJlY292ZXJ5LiBSZW5vIGxvc3Mg cmVjb3ZlcnkgaW4gUkZDIDU2ODEgZW5kcywNCj4gICAgICAgd2hlbg0KPiAgICAgICAoYW55KSBu ZXcgZGF0YSBoYXMgYmVlbiBhY2tub3dsZWRnZWQuDQo+DQo+ICAgICAgID4gQnkgZGVmaW5pdGlv biwgaWYgYSByZXRyYW5zbWlzc2lvbiBpcyBsb3N0IGl0IGlzIGJlY2F1c2UNCj4gICAgICAgPiBu ZXdlciBkYXRhIGhhcyBiZWVuIGFja25vd2xlZGdlZCwgc28gaXQncyBhIG5ldyByZWNvdmVyeQ0K PiAgICAgICBlcGlzb2RlLg0KPg0KPiAgICAgICBOb3Qgc3VyZSB3aGVyZSB5b3UgaGF2ZSB0aGlz IGRlZmluaXRpb24/IE5ld2VyIHRoYW4gd2hhdCBhcmUgeW91DQo+ICAgICAgIHJlZmVycmluZyB0 bz8NCj4NCj4gICAgICAgQnV0LCB5ZXMsIGlmIGEgcmV0cmFuc21pc3Npb24gaXMgbG9zdCB3aXRo IFJGQyA2Njc1IGFsZ29yaXRobSwNCj4gICAgICAgaXQgcmVxdWlyZXMgUlRPIHRvIGJlIGRldGVj dGVkIGFuZCBkZWZpbml0ZWx5IHN0YXJ0cyBhIG5ldw0KPiAgICAgICByZWNvdmVyeQ0KPiAgICAg ICBlcGlzb2RlLiBUaGF0IGlzLCBhIG5ldyByZWNvdmVyeSBlcGlzb2RlIGlzIGVuZm9yY2VkIGJ5 IHN0ZXANCj4gICAgICAgKDEuYSkgb2YNCj4gICAgICAgTmV4dFNlZyAoKSB3aGljaCBwcmV2ZW50 cyByZXRyYW5zbWlzc2lvbiBpZiBhIHNlZ21lbnQgdGhhdCBoYXMNCj4gICAgICAgYWxyZWFkeQ0K PiAgICAgICBiZWVuIHJldHJhbnNtaXR0ZWQuIElmIFJBQ0stVExQIGlzIHVzZWQgZm9yIGRldGVj dGluZyBsb3NzIHdpdGgNCj4gICAgICAgUkZDIDY2NzUNCj4gICAgICAgdGhpbmdzIGdldCBkaWZm ZXJlbnQgaW4gbWFueSB3YXlzLCBiZWNhdXNlIGl0IG1heSBkZXRlY3QgbG9zcyBvZg0KPiAgICAg ICBhDQo+ICAgICAgIHJldHJhbnNtaXNzaW9uLiBJdCB3b3VsZCBwcmV0dHkgbXVjaCByZXF1aXJl IGFuIGVudGlyZSByZWRlc2lnbg0KPiAgICAgICBvZiB0aGUgYWxnb3JpdGguIEZvciBleGFtcGxl LCBjYWxjdWxhdGlvbiBvZiBwaXBlIGRvZXMgbm90DQo+ICAgICAgIGNvbnNpZGVyDQo+ICAgICAg IHNlZ21lbnRzIHRoYXQgaGF2ZSBiZWVuIHJldHJhbnNtaXR0ZWQgbW9yZSB0aGFuIG9uY2UuDQo+ DQo+ICAgICAgID4gTWVhbndoaWxlLCBkdXJpbmcgdGhlIEZhc3QgUmVjb3ZlcnkgcGVyaW9kIHRo ZSBpbmNvbWluZyBhY2tzDQo+ICAgICAgIGltcGxpY2l0bHkNCj4gICAgICAgPiByZW1vdmUgZGF0 YSBmcm9tIHRoZSBuZXR3b3JrIGFuZCB0aGVyZWZvcmUga2VlcCBmbGlnaHRzaXplDQo+ICAgICAg IGxvdy4NCj4NCj4gICAgICAgSW5jb3JyZWN0LiBGbGlnaHRTaXplICE9IHBpcGUuIE9ubHkgY3Vt dWxhdGl2ZSBhY2tzIHJlbW92ZSBkYXRhDQo+ICAgICAgIGZyb20NCj4gICAgICAgRmxpZ2h0U2l6 ZSBhbmQgbmV3IGRhdGEgdHJhbnNtaXR0ZWQgZHVyaW5nIGZhc3QgcmVjb3ZlcnkgaW5mbGF0ZQ0K PiAgICAgICBGbGlnaHRTaXplLiBIb3cgRmxpZ2h0U2l6ZSBldm9sdmVzIGRlcGVuZHMgb24gbG9z cyBwYXR0ZXJuIGFzIEkNCj4gICAgICAgc2FpZC4NCj4gICAgICAgSXQgaXMgYWxzbyBwb3NzaWJs ZSB0aGF0IEZsaWdodFNpemUgaXMgbG93LCBpdCBtYXkgZXJyIGluIGJvdGgNCj4gICAgICAgZGly ZWN0aW9ucy4gQSBzaW1wbGUgZXhhbXBsZSBjYW4gYmUgdXNlZCBhcyBhIHByb29mIGZvciB0aGUg Y2FzZQ0KPiAgICAgICB3aGVyZQ0KPiAgICAgICBjd25kIGluY3JlYXNlcyBpZiBhIGxvc3Mgb2Yg cmV0cmFuc21pc3Npb24gaXMgZGV0ZWN0ZWQgYW5kDQo+ICAgICAgIHJlcGFpcmVkOg0KPg0KPiAg ICAgICBSRkMgNjY3NSByZWNvdmVyeSB3aXRoIFJBQ0stVExQIGxvc3MgZGV0ZWN0aW9uOg0KPiAg ICAgICAoY29udGFpbnMgc29tZSBpbmFjY3VyYWNpZXMgYmVjYXVzZSBpdCBoYXMgbm90IGJlZW4g ZGVmaW5lZCBob3cNCj4gICAgICAgbG9zdCByZXhtaXRzIGFyZSBjYWxjdWxhdGVkIGludG8gcGlw ZSkNCj4NCj4gICAgICAgY3duZD0yMDsgcGFja2V0cyBQMSwuLi4sUDIwIGluIGZsaWdodCA9IGN1 cnJlbnQgd2luZG93IG9mIGRhdGENCj4gICAgICAgW1AxIGRyb3BwZWQgYW5kIHJleG1pdCBvZiBQ MSB3aWxsIGFsc28gYmUgZHJvcHBlZF0NCj4NCj4gICAgICAgRHVwQWNrIHcvU0FDSyBmb3IgUDIg YXJyaXZlcw0KPiAgICAgICBbbG9zcyBvZiBQMSBkZXRlY3RlZCBhZnRlciBvbmUgUlRUIGZyb20g b3JpZ2luYWwgeG1pdCBvZiBQMV0NCj4gICAgICAgW2N3bmQ9c3N0aHJlc2g9MTBdDQo+ICAgICAg IFAxIGlzIHJleG1pdHRlZCAoYW5kIGl0IGxvZ2ljYWxseSBzdGFydHMgbmV4dCB3aW5kb3cgb2Yg ZGF0YSkNCj4NCj4gICAgICAgRHVwQWNrcyB3LyBTQUNLIGZvciBvcmlnaW5hbCBQMy4uMTEgYXJy aXZlDQo+ICAgICAgIER1cEFjayB3LyBTQUNLIGZvciBvcmlnaW5hbCBQMTIgYXJyaXZlcw0KPiAg ICAgICBbY3duZC1waXBlID0gMTAtOSA+PTFdDQo+ICAgICAgIHNlbmQgUDIxDQo+ICAgICAgIER1 cEFjayB3L1NBQ0sgZm9yIFAxMyBhcnJpdmVzDQo+ICAgICAgIHNlbmQgUDIyDQo+ICAgICAgIC4u Lg0KPiAgICAgICBEdXBBY2sgdy9TQUNLIGZvciBQMjAgYXJyaXZlcw0KPiAgICAgICBzZW5kIFAy OQ0KPiAgICAgICBbRmxpZ2h0U2l6ZT0yOV0NCj4NCj4gICAgICAgKEFjayBmb3IgcmV4bWl0IG9m IFAxIHdvdWxkIGFycml2ZSBoZXJlIHVubGVzcyBpdCBnb3QgZHJvcHBlZCkNCj4NCj4gICAgICAg RHVwQWNrIHcvU0FDSyBmb3IgUDIxIGFycml2ZXMNCj4gICAgICAgW2xvc3Mgb2YgcmV4bWl0IFAx IGRldGVjdGVkIGFmdGVyIG9uZSBSVFQgZnJvbSByZXhtaXQgb2YgUDFdDQo+DQo+ICAgICAgIFNF VCBjd25kID0gc3N0aHJlc2ggPSBGbGlnaHRTaXplLzI9IDI5LzIgPSAxNCw1DQo+DQo+ICAgICAg IENXTkQgSU5DUkVBU0VTIHdoZW4gaXQgc2hvdWxkIGJlIGF0IG1vc3QgNSBhZnRlciBoYWx2aW5n IGl0DQo+ICAgICAgIHR3aWNlISEhDQo+DQo+ICAgICAgID4gV2UgY2FuIGNvbnRpbnVlIHRvIGdv IGFyb3VuZCBvbiBvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlc2UNCj4gICAgICAgZG9jdW1lbnRz LA0KPiAgICAgICA+IGJ1dCBmdW5kYW1lbnRhbGx5IGlmIHRoZXJlIGlzIGFtYmlndWl0eSBpbiA1 NjgxLzY2NzUgd2Ugc2hvdWxkDQo+ICAgICAgIGJpcw0KPiAgICAgICA+IHRob3NlIFJGQ3MgcmF0 aGVyIHRoYW4gZXhwYW5kIHRoZSBzY29wZSBvZiBSQUNLLg0KPg0KPiAgICAgICBBcyBJIHNhaWQg ZWFybGllciwgSSBhbSBub3Qgb3Bwb3NpbmcgYmlzLCB0aG91Z2ggNTY4MWJpcyB3dW9sZA0KPiAg ICAgICBub3QNCj4gICAgICAgYmUgbmVlZGVkLCBJIHRoaW5rLg0KPg0KPiAgICAgICBCdXQgbGV0 IG1lIHJlcGVhdDogaWYgd2UgcHVibGlzaCBSQUNLLVRMUCBub3cgd2l0aG91dCBuZWNlc3NhcnkN Cj4gICAgICAgd2FybmluZ3MNCj4gICAgICAgb3Igd2l0aCBhIGNvcnJlY3QgY29uZ2VzaW9uIGNv bnRyb2wgYWxnb3JpdGhtIHNvbWVvbmUgd2lsbCB0cnkNCj4gICAgICAgdG8NCj4gICAgICAgaW1w bGVtZW50IFJBQ0stVExQIHdpdGggUkZDIDY2NzUgYW5kIGl0IHdpbGwgYmUgYSB0b3RhbCBtZXNo Lg0KPiAgICAgICBUaGUNCj4gICAgICAgYmVoYXZpb3Igd2lsbCBiZSB1bnByZWRpY3RhYmxlIGFu ZCBxdWl0ZSBsaWtlbHkgdW5zYWZlDQo+ICAgICAgIGNvbmdlc3Rpb24NCj4gICAgICAgY29udHJv bCBiZWhhdmlvci4NCj4NCj4gICAgICAgPiAyLg0KPiAgICAgICA+IFtNYXJra3VdDQo+ICAgICAg ID4gIiBJbiBzaG9ydDoNCj4gICAgICAgPiBXaGVuIHdpdGggYSBub24tUkFDSy1UTFAgaW1wbGVt ZW50YXRpb24gdGltZXIgKFJUTykgZXhwaXJlczoNCj4gICAgICAgY3duZD0xDQo+ICAgICAgID4g TVNTLA0KPiAgICAgICA+IGFuZCBzbG93IHN0YXJ0IGlzIGVudGVyZWQuDQo+ICAgICAgID4gV2hl biB3aXRoIGEgUkFDS19UTFAgaW1wbGVtZW50YXRpb24gdGltZXIgKFBUTykgZXhwaXJlcywNCj4g ICAgICAgPiBub3JtYWwgZmFzdCByZWNvdmVyeSBpcyBlbnRlcmVkICh1bmxlc3MgaW1wbGVtZW50 aW5nDQo+ICAgICAgID4gYWxzbyBQUlIpLiBTbyBubyBSVE8gcmVjb3ZlcnkgYXMgZXhwbGljaXRs eSBzdGF0ZWQgaW4gU2VjLg0KPiAgICAgICA3LjQuMS4iDQo+ICAgICAgID4NCj4gICAgICAgPiBb TWFydGluXQ0KPiAgICAgICA+IFRoZXJlIG1heSBiZSBhIG1pc3VuZGVyc3RhbmRpbmcgaGVyZS4g UFRPIGlzIG5vdCB0aGUgc2FtZSBhcw0KPiAgICAgICBSVE8sIGFuZA0KPiAgICAgICA+IGJvdGgg bWVjaGFuaXNtcyBleGlzdCEgVGhlIGxvc3MgcmVzcG9uc2UgdG8gYSBQVE8gaXMgdG8gc2VuZCBh DQo+ICAgICAgIHByb2JlOw0KPiAgICAgICA+IHRoZSBSVE8gcmVzcG9uc2UgaXMgYXMgd2l0aCBj b252ZW50aW9uYWwgVENQLiBJbiBTZWN0aW9uIDcuMzoNCj4NCj4gICAgICAgTm8sIEkgZG9uJ3Qg dGhpbmsgSSBtaXN1bmRlcnN0b29kLiBJZiB5b3UgY2FsbCB0aW1lb3V0IHdpdGgNCj4gICAgICAg YW5vdGhlciBuYW1lLCBpdCBpcyBzdGlsbCB0aW1lb3V0LiBBbmQgY29uZ2VzdGlvbiBjb250cm9s IGRvZXMNCj4gICAgICAgbm90DQo+ICAgICAgIGNvbnNpZGVyIHdoaWNoIHNlZ21lbnRzIHRvIHNl bmQgKFNORC5VTkEgdnMuIHByb2JlIHcvIGhpZ2hlcg0KPiAgICAgICBzZXF1ZW5jZQ0KPiAgICAg ICBudW1iZXIpLCBvbmx5IGhvdyBtdWNoIGlzIHNlbnQuDQo+DQo+ICAgICAgIFlvdSBpZ25vcmVk IG15IG1ham9yIHBvaW50IHdoZXJlIEkgZGVjb3VwbGVkIGNvbmdlc3Rpb24gY29udHJvbA0KPiAg ICAgICBmcm9tIGxvc3MNCj4gICAgICAgZGV0ZWN0aW9uIGFuZCBsb3NzIHJlY292ZXJ5IGFuZCBj b21wYXJlZCBSRkMgNTY4MSBiZWhhdmlvciB0bw0KPiAgICAgICBSQUNLLVRMUA0KPiAgICAgICBi ZWhhdmlvciBpbiBleGFjdGx5IHRoZSBzYW1lIHNjZW5hcmlvIHdoZXJlIGFuIGVudGlyZSBmbGln aHQgaXMNCj4gICAgICAgbG9zdCBhbmQNCj4gICAgICAgdGltZXIgZXhwaXJlcy4NCj4NCj4gICAg ICAgUGxlYXNlIGNvbW1lbnQgd2h5IGNvbmdlc3Rpb24gY29udHJvbCBiZWhhdmlvciBpcyBhbGxv d2VkIHRvIGJlDQo+ICAgICAgIHJhZGljYWxseQ0KPiAgICAgICBkaWZmZXJlbnQgaW4gdGhlc2Ug dHdvIGltcGxlbWVudGF0aW9ucz8NCj4NCj4gICAgICAgUkZDIDU2ODEgJiBSRkMgNjI5OCB0aW1l b3V0Og0KPg0KPiAgICAgICAgICAgICAgIFJUTz1TUlRUKzQqUlRUVkFSIChSVE8gdXNlZCBmb3Ig YXJtaW5nIHRoZSB0aW1lcikNCj4gICAgICAgICAgICAgIDEuIFJUTyB0aW1lciBleHBpcmVzDQo+ ICAgICAgICAgICAgICAyLiBjd25kPTEgTVNTOyBzc3RocmVzaD1GbGlnaHRTaXplLzI7IHJleG1p dCBvbmUgc2VnbWVudA0KPiAgICAgICAgICAgICAgMy4gQWNrIG9mIHJleG1pdCBzZW50IGluIHN0 ZXAgMiBhcnJpdmVzDQo+ICAgICAgICAgICAgICA0LiBjd25kID0gY3duZCsxIE1TUzsgc2VuZCB0 d28gc2VnbWVudHMNCj4gICAgICAgICAgICAgIC4uLg0KPg0KPiAgICAgICBSQUNLLVRMUCB0aW1l b3V0Og0KPg0KPiAgICAgICAgICAgICAgIFBUTz1taW4oMipTUlRULFJUTykgKFBUTyB1c2VkIGZv ciBhcm1pbmcgdGhlIHRpbWVyKQ0KPiAgICAgICAgICAgICAgMS4gUFRPIHRpbWVzIGV4cGlyZXMN Cj4gICAgICAgICAgICAgIDIuIChjd25kPTEgTVNTKTsgKHJlKXhtaXQgb25lIHNlZ21lbnQNCj4g ICAgICAgICAgICAgIDMuIEFjayBvZiAocmUpeG1pdCBzZW50IGluIHNyZXAgMiBhcnJpdmVzDQo+ ICAgICAgICAgICAgICA0LiBjd25kID0gc3N0aHJlc2ggPSBGbGlnaHRTaXplLzI7IHNlbmQgTj1j d25kIHNlZ21lbnRzDQo+DQo+ICAgICAgIElmIEZsaWdodFNpemUgaXMgMTAwIHNlZ21lbnRzIHdo ZW4gdGltZXIgZXhwaXJlcywgY29uZ2VzdGlvbg0KPiAgICAgICBjb250cm9sIGlzDQo+ICAgICAg IHRoZSBzYW1lIGluIHN0ZXBzIDEtMywgYnV0IGluIHN0ZXAgNCB0aGUgc3RhbmRhcmQgY29uZ2Vz dGlvbg0KPiAgICAgICBjb250cm9sDQo+ICAgICAgIGFsbG93cyB0cmFuc21pdHRpbmcgMiBzZWdt ZW50cywgd2hpbGUgUkFDSy1UTFAgd291bGQgYWxsb3cNCj4gICAgICAgYmxhc3RpbmcgNTAgc2Vn bWVudHMuDQo+DQo+ICAgICAgID4gQWZ0ZXIgYXR0ZW1wdGluZyB0byBzZW5kIGEgbG9zcyBwcm9i ZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGENCj4gICAgICAgbG9zcw0KPiAgICAgICA+ICAgIHBy b2JlIHdhcyBzZW50LCB0aGUgc2VuZGVyIE1VU1QgcmUtYXJtIHRoZSBSVE8gdGltZXIsIG5vdA0K PiAgICAgICB0aGUgUFRPDQo+ICAgICAgID4gICAgdGltZXIsIGlmIEZsaWdodFNpemUgaXMgbm90 IHplcm8uICBUaGlzIGVuc3VyZXMgUlRPDQo+ICAgICAgIHJlY292ZXJ5IHJlbWFpbnMNCj4gICAg ICAgPiAgICB0aGUgbGFzdCByZXNvcnQgaWYgVExQIGZhaWxzLg0KPiAgICAgICA+ICINCj4NCj4g ICAgICAgVGhpcyBkb2VzIG5vdCBwcmV2ZW50IHRoZSBhYm92ZSBSQUNLLVRMUCBiZWhhdmlvciBm cm9tIGdldHRpbmcNCj4gICAgICAgcmVhbGl6ZWQuDQo+DQo+ICAgICAgID4gU28gYSBwdXJlIFJU TyByZXNwb25zZSBleGlzdHMgaW4gdGhlIGNhc2Ugb2YgcGVyc2lzdGVudA0KPiAgICAgICBjb25n ZXN0aW9uIHRoYXQNCj4gICAgICAgPiBjYXVzZXMgbG9zc2VzIG9mIHByb2JlcyBvciB0aGVpciBB Q0tzLg0KPg0KPiAgICAgICBZZXMsIFJUTyByZXNwb25zZSBleGlzdHMgQlVUIG9ubHkgYWZ0ZXIg UkFDSy1UTFAgYXQgbGVhc3Qgb25jZQ0KPiAgICAgICBibGFzdHMgdGhlDQo+ICAgICAgIG5ldHdv cmsuIEl0IG1heSB3ZWxsIGJlIHRoYXQgd2l0aCBzbWFsbGVyIHdpbmRvd3MgUkFDSy1UTFAgaXMN Cj4gICAgICAgc3VjY2Vzc2Z1bA0KPiAgICAgICBkdXJpbmcgaXRzIFRMUCBpbml0aWF0ZWQgb3Zl cmx5IGFnZ3Jlc3NpdmUgImZhc3QgcmVjb3ZlcnkiIGFuZA0KPiAgICAgICBuZXZlcg0KPiAgICAg ICBlbnRlcnMgUlRPIHJlY292ZXJ5IGJlY2F1c2UgaXQgbWF5IGRldGVjdCBhbmQgcmVwYWlyIGFs c28gbG9zcw0KPiAgICAgICBvZg0KPiAgICAgICByZXhtaXRzLiBUaGF0IGlzLCBpdCBjb250aW51 ZXMgYXQgdG9vIGhpZ2ggcmF0ZSBldmVuIGlmIGxvc3QNCj4gICAgICAgcmV4bWl0cw0KPiAgICAg ICBpbmRpY2F0ZSB0aGF0IGNvbmdlc3Rpb24gcGVyc2lzdHMgaW4gc3VjY2Vzc2l2ZSB3aW5kb3dz IG9mIGRhdGEuDQo+ICAgICAgIEFuZA0KPiAgICAgICB3b3JzZSwgaXQgaXMgc3VjY2Vzc2Z1bCBi ZWNhdXNlIGl0IHB1c2hlcyBhd2F5IG90aGVyIGNvbXBhdGlibGUNCj4gICAgICAgVENQDQo+ICAg ICAgIGZsb3dzIGJ5IGJlaW5nIHRvbyBhZ2dyZXNzaXZlIGFuZCB1bmZhaXIuDQo+DQo+ICAgICAg IEV2ZW4gYSBzaW5nbGUgc2hvdCBidXJzdCBldmVyeSB0aW1lIHRoZXJlIGlzIHNpZ25pZmljYW50 IGxvc3MNCj4gICAgICAgZXZlbnQgaXMgbm90IGFjY2VwdGFibGUsIG5vdCB0byBtZW50aW9uIGNv bnRpbnVvdXMNCj4gICAgICAgYWdncmVzc2l2ZW5lc3MsIGFuZA0KPiAgICAgICB0aGlzIGlzIGV4 YWN0bHkgd2hhdCBSRkMgMjkxNCBhbmQgUkZDIDUwMzMgZXhwbGljaXRseSBhZGRyZXNzDQo+ICAg ICAgIGFuZCB3YXJuDQo+ICAgICAgIGFib3V0Lg0KPg0KPiAgICAgICBBcmUgd2UgaWdub3Jpbmcg dGhlc2UgQkNQcyB0aGF0IGhhdmUgSUVURiBjb25zZW5zdXM/DQo+DQo+ICAgICAgIEFuZCB0aGUg b3RoZXIgaW1wb3J0YW50IHF1ZXN0aW9uIEknZCBsaWtlIHRvIGhhdmUgYW4gYW5zd2VyOg0KPg0K PiAgICAgICBXaGF0IGlzIHRoZSBqdXN0aWZpY2F0aW9uIHRvIG1vZGlmeSBzdGFuZGFyZCBUQ1Ag Y29uZ2VzdGlvbg0KPiAgICAgICBjb250cm9sIHRvDQo+ICAgICAgIHVzZSBmYXN0IHJlY292ZXJ5 IGluc3RlYWQgb2Ygc2xvdyBzdGFydCBmb3IgYSBjYXNlIHdoZXJlIHRpbWVvdXQNCj4gICAgICAg aXMNCj4gICAgICAgbmVlZGVkIHRvIGRldGVjdCB0aGUgcGFja2V0IGxvc3NlcyBiZWNhdXNlIHRo ZXJlIGlzIG5vIGZlZWRiYWNrDQo+ICAgICAgIGFuZCBhY2sNCj4gICAgICAgY2xvY2sgaXMgbG9z dD8gUkFDSy1UTFAgZXhwbGljaXRseSBpbnN0cnVjdHMgdG8gZG8gc28gaW4gU2VjLg0KPiAgICAg ICA3LjQuMS4NCj4NCj4gICAgICAgQXMgSSBub3RlZDogYmFzZWQgb24gd2hhdCBpcyB3cml0dGVu IGluIHRoZSBkcmFmdCBpdCBkb2VzIG5vdA0KPiAgICAgICBpbnRlbmQgdG8NCj4gICAgICAgY2hh bmdlIGNvbmdlc3Rpb24gY29udHJvbCBidXQgZWZmZWN0aXZlbHkgaXQgZG9lcy4NCj4NCj4gICAg ICAgL01hcmtrdQ0KPg0KPiAgICAgICA+IE1hcnRpbg0KPiAgICAgICA+DQo+ICAgICAgID4NCj4g ICAgICAgPiBPbiBXZWQsIERlYyAxNiwgMjAyMCBhdCAxMTozOSBBTSBNYXJra3UgS29qbw0KPiAg ICAgICA8a29qb0Bjcy5oZWxzaW5raS5maTxtYWlsdG86a29qb0Bjcy5oZWxzaW5raS5maT4+DQo+ ICAgICAgID4gd3JvdGU6DQo+ICAgICAgID4gICAgICAgSGkgTWFydGluLA0KPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgT24gVHVlLCAxNSBEZWMgMjAyMCwgTWFydGluIER1a2Ugd3JvdGU6DQo+ ICAgICAgID4NCj4gICAgICAgPiAgICAgICA+IEhpIE1hcmtrdSwNCj4gICAgICAgPiAgICAgICA+ DQo+ICAgICAgID4gICAgICAgPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gVGhlIGF1dGhvcnMg d2lsbCBpbmNvcnBvcmF0ZQ0KPiAgICAgICA+ICAgICAgIG1hbnkgb2YgeW91cg0KPiAgICAgICA+ ICAgICAgID4gc3VnZ2VzdGlvbnMgYWZ0ZXIgdGhlIElFU0cgcmV2aWV3Lg0KPiAgICAgICA+ICAg ICAgID4NCj4gICAgICAgPiAgICAgICA+IFRoZXJlJ3Mgb25lIHRoaW5nIEkgZG9uJ3QgdW5kZXJz dGFuZCBpbiB5b3VyIGNvbW1lbnRzOg0KPiAgICAgICA+ICAgICAgID4NCj4gICAgICAgPiAgICAg ICA+ICIgVGhhdCBpcywNCj4gICAgICAgPiAgICAgICA+IHdoZXJlIGNhbiBhbiBpbXBsZW1lbnRl ciBmaW5kIGFkdmljZSBmb3IgY29ycmVjdA0KPiAgICAgICA+ICAgICAgIGNvbmdlc3Rpb24gY29u dHJvbA0KPiAgICAgICA+ICAgICAgID4gYWN0aW9ucyB3aXRoIFJBQ0stVExQLCB3aGVuOg0KPiAg ICAgICA+ICAgICAgID4NCj4gICAgICAgPiAgICAgICA+ICgxKSBhIGxvc3Mgb2YgcmV4bWl0dGVk IHNlZ21lbnQgaXMgZGV0ZWN0ZWQNCj4gICAgICAgPiAgICAgICA+ICgyKSBhbiBlbnRpcmUgZmxp Z2h0IG9mIGRhdGEgZ2V0cyBkcm9wcGVkIChhbmQNCj4gICAgICAgZGV0ZWN0ZWQpLA0KPiAgICAg ICA+ICAgICAgID4gICAgICB0aGF0IGlzLCB3aGVuIHRoZXJlIGlzIG5vIGZlZWRiYWNrIGF2YWls YWJsZSBhbmQNCj4gICAgICAgYQ0KPiAgICAgICA+ICAgICAgIHRpbWVvdXQNCj4gICAgICAgPiAg ICAgICA+ICAgICAgaXMgbmVlZGVkIHRvIGRldGVjdCB0aGUgbG9zcyAiDQo+ICAgICAgID4gICAg ICAgPg0KPiAgICAgICA+ICAgICAgID4gU2VjdGlvbiA5LjMgaXMgdGhlIGRpc2N1c3Npb24gYWJv dXQgQ0MsIGFuZCBpcyBjbGVhcg0KPiAgICAgICB0aGF0DQo+ICAgICAgID4gICAgICAgdGhlDQo+ ICAgICAgID4gICAgICAgPiBpbXBsZW1lbnRlciBzaG91bGQgdXNlIGVpdGhlciA1NjgxIG9yIDY5 MzcuDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICBKdXN0IGEgY2l0ZSBuaXQ6IFJGQyA1Njgx IHByb3ZpZGVzIGJhc2ljIENDIGNvbmNlcHRzIGFuZA0KPiAgICAgICA+ICAgICAgIHNvbWUgdXNl ZnVsIENDDQo+ICAgICAgID4gICAgICAgZ3VpZGVsaW5lcyBidXQgZ2l2ZW4gdGhhdCBSQUNLLVRM UCBNVVNUIGltcGxlbWVudCBTQUNLDQo+ICAgICAgIHRoZQ0KPiAgICAgICA+ICAgICAgIGFsZ29y aXRobSBpbg0KPiAgICAgICA+ICAgICAgIFJGQyA1NjgxIGlzIG5vdCB0aGF0IHVzZWZ1bCBhbmQg YW4gaW1wbGVtZW50ZXIgcXVpdGUNCj4gICAgICAgbGlrZWx5DQo+ICAgICAgID4gICAgICAgZm9s bG93cw0KPiAgICAgICA+ICAgICAgIG1haW5seSB0aGUgYWxnb3JpdGhtIGluIFJGQyA2Njc1IChh bmQgbm90IFJGQyA2OTM3IGF0DQo+ICAgICAgIGFsbA0KPiAgICAgICA+ICAgICAgIGlmIG5vdA0K PiAgICAgICA+ICAgICAgIGltcGxlbWVudGluZyBQUlIpLg0KPiAgICAgICA+ICAgICAgIEFuZCBS RkMgNjY3NSBpcyBub3QgbWVudGlvbmVkIGluIFNlYyA5LjMsIHRob3VnaCBpdCBpcw0KPiAgICAg ICA+ICAgICAgIGxpc3RlZCBpbiB0aGUNCj4gICAgICAgPiAgICAgICBTZWMuIDQgKFJlcXVpcmVt ZW50cykuDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICA+IFlvdSB3ZW50IHRocm91Z2ggdGhl IDY5MzcgY2FzZSBpbiBkZXRhaWwuDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICBZZXMsIGJ1 dCB3aXRob3V0IGNvcnJlY3QgQ0MgYWN0aW9ucy4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAg ID4gSWYgNTY4MSwgaXQncyBwcmV0dHkgY2xlYXIgdG8gbWUgdGhhdCBpbiAoMSkgdGhpcyBpcyBh DQo+ICAgICAgID4gICAgICAgbmV3IGxvc3MNCj4gICAgICAgPiAgICAgICA+IGRldGVjdGlvbiBh ZnRlciBhY2tub3dsZWRnbWVudCBvZiBuZXcgZGF0YSwgYW5kDQo+ICAgICAgIHRoZXJlZm9yZQ0K PiAgICAgICA+ICAgICAgIHJlcXVpcmVzIGENCj4gICAgICAgPiAgICAgICA+IHNlY29uZCBoYWx2 aW5nIG9mIGN3bmQuDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICBIbW0sIG5vdCBzdXJlIHdo YXQgeW91IG1lYW4gYnkgInRoaXMgaXMgYSBuZXcgbG9zcw0KPiAgICAgICA+ICAgICAgIGRldGVj dGlvbiBhZnRlcg0KPiAgICAgICA+ICAgICAgIGFja25vd2xlZGdtZW50IG9mIG5ldyBkYXRhIj8N Cj4gICAgICAgPiAgICAgICBCdXQgYW55d2F5LCBSRkMgNTY4MSBnaXZlcyB0aGUgZ2VuZXJhbCBw cmluY2lwbGUgdG8NCj4gICAgICAgcmVkdWNlDQo+ICAgICAgID4gICAgICAgY3duZCBhbmQNCj4g ICAgICAgPiAgICAgICBzc3RocmVzaCB0d2ljZSBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3Qg YnV0IElNSE8gKGFuZA0KPiAgICAgICBJDQo+ICAgICAgID4gICAgICAgYmVsaWV2ZSBtYW55DQo+ ICAgICAgID4gICAgICAgd2hvIGhhdmUgZGVzaWduZWQgbmV3IGxvc3MgcmVjb3ZlcnkgYW5kIEND IGFsZ29yaXRobXMgb3INCj4gICAgICAgPiAgICAgICBpbXBsZW1lbnRlZCB0aGVtDQo+ICAgICAg ID4gICAgICAgYWdyZWUpIHRoYXQgaXQgaXMgaGFyZCB0byBnZXQgdGhpbmdzIHJpZ2h0IGlmIG9u bHkNCj4gICAgICAgPiAgICAgICBjb25nZXN0aW9uIGNvbnRyb2wNCj4gICAgICAgPiAgICAgICBw cmluY2lwbGVzIGFyZSBhdmFpbGFibGUgYW5kIG5vIGFsZ29yaXRobS4NCj4gICAgICAgPiAgICAg ICBUaGF0J3Mgd2h5IEFMTCBtZWNoYW5pc21zIHRoYXQgd2UgaGF2ZSBpbmNsdWRlIGEgcXVpdGUN Cj4gICAgICAgPiAgICAgICBkZXRhaWxlZCBhbGdvcml0aG0NCj4gICAgICAgPiAgICAgICB3aXRo IGFsbCBuZWNlc3NhcnkgdmFyaWFibGVzIGFuZCBhY3Rpb25zIGZvciBsb3NzDQo+ICAgICAgIHJl Y292ZXJ5DQo+ICAgICAgID4gICAgICAgYW5kL29yIENDDQo+ICAgICAgID4gICAgICAgcHVycG9z ZXMgKGFuZCBvZnRlbiBhbHNvIHBzZXVkb2NvZGUpLiBMaWtlIHRoaXMgZG9jdW1lbnQNCj4gICAg ICAgPiAgICAgICBkb2VzIGZvciBsb3NzDQo+ICAgICAgID4gICAgICAgZGV0ZWN0aW9uLg0KPiAg ICAgICA+DQo+ICAgICAgID4gICAgICAgU28gdGhlIHByb2JsZW0gaXMgdGhhdCB3ZSBkbyBub3Qg aGF2ZSBhIGRldGFpbGVkIGVub3VnaA0KPiAgICAgICA+ICAgICAgIGFsZ29yaXRobSBvcg0KPiAg ICAgICA+ICAgICAgIHJ1bGUgdGhhdCB0ZWxscyBleGFjdGx5IHdoYXQgdG8gZG8gd2hlbiBhIGxv c3Mgb2YgcmV4bWl0DQo+ICAgICAgIGlzDQo+ICAgICAgID4gICAgICAgZGV0ZWN0ZWQuDQo+ICAg ICAgID4gICAgICAgRXZlbiB3b3JzZSwgdGhlIGFsZ29yaXRobXMgaW4gUkZDIDU2ODEgYW5kIFJG QyA2Njc1DQo+ICAgICAgIHJlZmVyDQo+ICAgICAgID4gICAgICAgdG8NCj4gICAgICAgPiAgICAg ICBlcXVhdGlvbiAoNCkgb2YgUkZDIDU2ODEgdG8gcmVkdWNlIHNzdGhyZXNoIGFuZCBjd25kDQo+ ICAgICAgIHdoZW4gYQ0KPiAgICAgICA+ICAgICAgIGxvc3MNCj4gICAgICAgPiAgICAgICByZXF1 aXJpbmcgYSBjb25nZXN0aW9uIGNvbnRyb2wgYWN0aW9uIGlzIGRldGVjdGVkOg0KPiAgICAgICA+ DQo+ICAgICAgID4gICAgICAgICAoY3duZCA9KSBzc3RocmVzaCA9IEZsaWdodFNpemUgLyAyKQ0K PiAgICAgICA+DQo+ICAgICAgID4gICAgICAgQW5kIFJGQyA1NjgxIGdpdmVzIGEgd2FybmluZyBu b3QgdG8gaGFsdmUgY3duZCBpbiB0aGUNCj4gICAgICAgPiAgICAgICBlcXVhdGlvbiBidXQNCj4g ICAgICAgPiAgICAgICBGbGlnaHRTaXplLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgVGhh dCBpcywgdGhpcyBlcXVhdGlvbiBpcyB3aGF0IGFuIGltcGxlbWVudGVyDQo+ICAgICAgIGludHVp dGl2ZWx5DQo+ICAgICAgID4gICAgICAgd291bGQgdXNlDQo+ICAgICAgID4gICAgICAgd2hlbiBy ZWFkaW5nIHRoZSByZWxldmFudCBSRkNzIGJ1dCBpdCBnaXZlcyBhIHdyb25nDQo+ICAgICAgIHJl c3VsdA0KPiAgICAgICA+ICAgICAgIGZvcg0KPiAgICAgICA+ICAgICAgIG91dHN0YW5kaW5nIGRh dGEgd2hlbiBpbiBmYXN0IHJlY292ZXJ5ICh3aGVuIHRoZSBzZW5kZXINCj4gICAgICAgaXMNCj4g ICAgICAgPiAgICAgICBpbg0KPiAgICAgICA+ICAgICAgIGNvbmdlc3Rpb24gYXZvaWRhbmNlIGFu ZCB0aGUgZXF1YXRpb24gKDQpIGlzIHVzZWQgdG8NCj4gICAgICAgaGFsdmUNCj4gICAgICAgPiAg ICAgICBjd25kLCBpdA0KPiAgICAgICA+ICAgICAgIGdpdmVzIGEgY29ycmVjdCByZXN1bHQpLg0K PiAgICAgICA+ICAgICAgIE1vcmUgcHJlY2lzZWx5LCBkdXJpbmcgZmFzdCByZWNvdmVyeSBGbGln aHRTaXplIGlzDQo+ICAgICAgIGluZmxhdGVkDQo+ICAgICAgID4gICAgICAgd2hlbiBuZXcNCj4g ICAgICAgPiAgICAgICBkYXRhIGlzIHNlbnQgYW5kIHJlZHVjZWQgd2hlbiBzZWdtZW50cyBhcmUg Y3VtdWxhdGl2ZWx5DQo+ICAgICAgID4gICAgICAgQWNrZWQuDQo+ICAgICAgID4gICAgICAgV2hh dCB0aGUgb3V0Y29tZSBpcyBkZXBlbmRzIG9uIHRoZSBsb3NzIHBhdHRlcm4uIEluIHRoZQ0KPiAg ICAgICA+ICAgICAgIHdvcnN0IGNhc2UsDQo+ICAgICAgID4gICAgICAgRmxpZ2h0U2l6ZSBpcyBz aWduZmljYW50bHkgbGFyZ2VyIHRoYW4gaW4gdGhlIGJlZ2lubmluZw0KPiAgICAgICBvZg0KPiAg ICAgICA+ICAgICAgIHRoZSBmYXN0DQo+ICAgICAgID4gICAgICAgcmVjb3Zlcnkgd2hlbiBGbGln aHRTaXplIHdhcyAoY29ycmVjdGx5KSB1c2VkIHRvDQo+ICAgICAgIGRldGVybWluZQ0KPiAgICAg ICA+ICAgICAgIHRoZSBoYWx2ZWQNCj4gICAgICAgPiAgICAgICB2YWx1ZSBmb3IgY3duZCBhbmQg c3N0aHJlc2gsIGkuZS4sIGVxdWF0aW9uICg0KSBtYXkNCj4gICAgICAgcmVzdWx0DQo+ICAgICAg ID4gICAgICAgaW4NCj4gICAgICAgPiAgICAgICAqaW5jcmVhc2luZyogY3duZCB1cG9uIGRldGVj dGluZyBhIGxvc3Mgb2YgYSByZXhtaXR0ZWQNCj4gICAgICAgPiAgICAgICBzZWdtZW50LCBpbnN0 ZWFkDQo+ICAgICAgID4gICAgICAgb2YgZnVydGhlciBoYWx2aW5nIGl0Lg0KPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgQSBjbGV2ZXIgaW1wbGVtZW50ZXIgbWlnaHQgaGF2ZSBubyBwcm9ibGVt IHRvIGhhdmUgaXQNCj4gICAgICAgcmlnaHQNCj4gICAgICAgPiAgICAgICB3aXRoIHNvbWUNCj4g ICAgICAgPiAgICAgICB0aGlua2luZyBidXQgSSBhbSBhZnJhaWQgdGhhdCB0aGVyZSB3aWxsIGJl IGluY29ycmVjdA0KPiAgICAgICA+ICAgICAgIGltcGxlbWVudGF0aW9ucw0KPiAgICAgICA+ICAg ICAgIHdpdGggd2hhdCBpcyBjdXJyZW50bHkgc3BlY2lmaWVkLiBOb3QgYWxsIGltcGxlbWVudGVy cw0KPiAgICAgICBoYXZlDQo+ICAgICAgID4gICAgICAgc3BlbnQNCj4gICAgICAgPiAgICAgICBz aWduaWNpY2FudCBmcmFjdGlvbiBvZiB0aGVpciBjYXJlZXIgaW4gc29sdmluZyBUQ1ANCj4gICAg ICAgPiAgICAgICBwZWN1bGlhcml0aWVzLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgPiBG b3IgKDIpLCB0aGUgUlRPIHRpbWVyIGlzIHN0aWxsIG9wZXJhdGl2ZSBzbw0KPiAgICAgICA+ICAg ICAgID4gdGhlIFJUTyByZWNvdmVyeSBydWxlcyB3b3VsZCBzdGlsbCBmb2xsb3cuDQo+ICAgICAg ID4NCj4gICAgICAgPiAgICAgICBJbiBzaG9ydDoNCj4gICAgICAgPiAgICAgICBXaGVuIHdpdGgg YSBub24tUkFDSy1UTFAgaW1wbGVtZW50YXRpb24gdGltZXIgKFJUTykNCj4gICAgICAgPiAgICAg ICBleHBpcmVzOiBjd25kPTEgTVNTLA0KPiAgICAgICA+ICAgICAgIGFuZCBzbG93IHN0YXJ0IGlz IGVudGVyZWQuDQo+ICAgICAgID4gICAgICAgV2hlbiB3aXRoIGEgUkFDS19UTFAgaW1wbGVtZW50 YXRpb24gdGltZXIgKFBUTykgZXhwaXJlcywNCj4gICAgICAgPiAgICAgICBub3JtYWwgZmFzdCBy ZWNvdmVyeSBpcyBlbnRlcmVkICh1bmxlc3MgaW1wbGVtZW50aW5nDQo+ICAgICAgID4gICAgICAg YWxzbyBQUlIpLiBTbyBubyBSVE8gcmVjb3ZlcnkgYXMgZXhwbGljaXRseSBzdGF0ZWQgaW4NCj4g ICAgICAgU2VjLg0KPiAgICAgICA+ICAgICAgIDcuNC4xLg0KPiAgICAgICA+DQo+ICAgICAgID4g ICAgICAgVGhpcyBtZWFucyB0aGF0IHRoaXMgZG9jdW1lbnQgZXhwbGljaXRseSBtb2RpZmllcw0K PiAgICAgICBzdGFuZGFyZA0KPiAgICAgICA+ICAgICAgIFRDUCBjb25nZXN0aW9uDQo+ICAgICAg ID4gICAgICAgY29udHJvbCB3aGVuIHRoZXJlIGFyZSBubyBhY2tzIGNvbWluZyBhbmQgdGhlDQo+ ICAgICAgID4gICAgICAgcmV0cmFuc21pc3Npb24gdGltZXINCj4gICAgICAgPiAgICAgICBleHBp cmVzDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICBmcm9tOiBSVE89U1JUVCs0KlJUVFZBUiAo UlRPIHVzZWQgZm9yIGFybWluZyB0aGUgdGltZXIpDQo+ICAgICAgID4gICAgICAgICAgICAgIDEu IFJUTyB0aW1lciBleHBpcmVzDQo+ICAgICAgID4gICAgICAgICAgICAgIDIuIGN3bmQ9MSBNU1M7 IHNzdGhyZXNoPUZsaWdodFNpemUvMjsgcmV4bWl0IG9uZQ0KPiAgICAgICA+ICAgICAgIHNlZ21l bnQNCj4gICAgICAgPiAgICAgICAgICAgICAgMy4gQWNrIG9mIHJleG1pdCBzZW50IGluIHN0ZXAg MiBhcnJpdmVzDQo+ICAgICAgID4gICAgICAgICAgICAgIDQuIGN3bmQgPSBjd25kKzEgTVNTOyBz ZW5kIHR3byBzZWdtZW50cw0KPiAgICAgICA+ICAgICAgICAgICAgICAuLi4NCj4gICAgICAgPg0K PiAgICAgICA+ICAgICAgIHRvOiAgIFBUTz1taW4oMipTUlRULFJUTykgKFBSTyB1c2VkIGZvciBh cm1pbmcgdGhlDQo+ICAgICAgIHRpbWVyKQ0KPiAgICAgICA+ICAgICAgICAgICAgICAxLiBQVE8g dGltZXMgZXhwaXJlcw0KPiAgICAgICA+ICAgICAgICAgICAgICAyLiAoY3duZD0xIE1TUyk7IChy ZSl4bWl0IG9uZSBzZWdtZW50DQo+ICAgICAgID4gICAgICAgICAgICAgIDMuIEFjayBvZiAocmUp eG1pdCBzZW50IGluIHNyZXAgMiBhcnJpdmVzDQo+ICAgICAgID4gICAgICAgICAgICAgIDQuIGN3 bmQgPSBzc3RocmVzaCA9IEZsaWdodFNpemUvMjsgc2VuZCBOPWN3bmQNCj4gICAgICAgPiAgICAg ICBzZWdtZW50cw0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgRm9yIGV4YW1wbGUsIGlmIEZs aWdodFNpemUgaXMgMTAwIHNlZ21lbnRzIHdoZW4gdGltZXINCj4gICAgICAgPiAgICAgICBleHBp cmVzLA0KPiAgICAgICA+ICAgICAgIGNvbmdlc3Rpb24gY29udHJvbCBpcyB0aGUgc2FtZSBpbiBz dGVwcyAxLTMsIGJ1dCBpbiBzdGVwDQo+ICAgICAgIDQNCj4gICAgICAgPiAgICAgICB0aGUNCj4g ICAgICAgPiAgICAgICBjdXJyZW50IHN0YW5kYXJkIGNvbmdlc3Rpb24gY29udHJvbCBhbGxvd3Mg dHJhbnNtaXR0aW5nDQo+ICAgICAgIDINCj4gICAgICAgPiAgICAgICBzZWdtZW50cywNCj4gICAg ICAgPiAgICAgICB3aGlsZSBSQUNLLVRMUCB3b3VsZCBhbGxvdyBibGFzdGluZyA1MCBzZWdtZW50 cy4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIFF1ZXN0aW9uIGlzOiB3aGF0IGlzIHRoZSBq dXN0aWZpY2F0aW9uIHRvIG1vZGlmeQ0KPiAgICAgICBzdGFuZGFyZA0KPiAgICAgICA+ICAgICAg IFRDUA0KPiAgICAgICA+ICAgICAgIGNvbmdlc3Rpb24gY29udHJvbCB0byB1c2UgZmFzdCByZWNv dmVyeSBpbnN0ZWFkIG9mIHNsb3cNCj4gICAgICAgPiAgICAgICBzdGFydCBmb3IgYQ0KPiAgICAg ICA+ICAgICAgIGNhc2Ugd2hlcmUgdGltZW91dCBpcyBuZWVkZWQgdG8gZGV0ZWN0IGxvc3MgYmVj YXVzZQ0KPiAgICAgICB0aGVyZQ0KPiAgICAgICA+ICAgICAgIGlzIG5vDQo+ICAgICAgID4gICAg ICAgZmVlZGJhY2sgYW5kIGFjayBjbG9jayBpcyBsb3N0PyBUaGUgZHJhZnQgZG9lcyBub3QgZ2l2 ZQ0KPiAgICAgICBhbnkNCj4gICAgICAgPiAgICAgICBqdXN0aWZpY2F0aW9uLiBUaGlzIGNsZWFy bHkgaXMgaW4gY29uZmxpY3Qgd2l0aCBpdGVtcw0KPiAgICAgICAoMCkNCj4gICAgICAgPiAgICAg ICBhbmQgKDEpDQo+ICAgICAgID4gICAgICAgaW4gQkNQIDEzMyAoUkZDIDUwMzMpLg0KPiAgICAg ICA+DQo+ICAgICAgID4gICAgICAgRnVydGhlcm1vcmUsIHRoZXJlIGlzIG5vIGltcGxlbWVudGF0 aW9uIG5vciBleHBlcmltZW50YWwNCj4gICAgICAgPiAgICAgICBleHBlcmllbmNlDQo+ICAgICAg ID4gICAgICAgZXZhbHVhdGluZyB0aGlzIGNoYW5nZS4gVGhlIGltcGxlbWVudGF0aW9uIHdpdGgN Cj4gICAgICAgPiAgICAgICBleHBlcmltZW50YWwgZXhwZXJpZW5jZQ0KPiAgICAgICA+ICAgICAg IHVzZXMgUFJSIChSRkMgNjkzNykgd2hpY2ggaXMgYW4gRXhwZXJpbWVudGFsDQo+ICAgICAgIHNw ZWNpZmljYXRpb24NCj4gICAgICAgPiAgICAgICBpbmNsdWRpbmcgYQ0KPiAgICAgICA+ICAgICAg IG5vdmVsICJ0cmljayIgdGhhdCBkaXJlY3RzIFBSUiBmYXN0IHJlY292ZXJ5IHRvDQo+ICAgICAg IGVmZmVjdGl2ZWx5DQo+ICAgICAgID4gICAgICAgdXNlIHNsb3cNCj4gICAgICAgPiAgICAgICBz dGFydCBpbiB0aGlzIGNhc2UgYXQgaGFuZC4NCj4gICAgICAgPg0KPiAgICAgICA+DQo+ICAgICAg ID4gICAgICAgPiBJbiBvdGhlciB3b3JkcywgSSBhbSBub3Qgc2VlaW5nIGEgY2FzZSB0aGF0IHJl cXVpcmVzDQo+ICAgICAgIG5ldw0KPiAgICAgICA+ICAgICAgIGNvbmdlc3Rpb24NCj4gICAgICAg PiAgICAgICA+IGNvbnRyb2wgY29uY2VwdHMgZXhjZXB0IGFzIGRpc2N1c3NlZCBpbiA5LjMuDQo+ ICAgICAgID4NCj4gICAgICAgPiAgICAgICBTZWUgYWJvdmUuIFRoZSBjaGFuZ2UgaW4gc3RhbmRh cmQgY29uZ2VzdGlvbiBjb250cm9sIGZvcg0KPiAgICAgICA+ICAgICAgICgyKS4NCj4gICAgICAg PiAgICAgICBUaGUgZHJhZnQgaW50ZW5kcyBub3QgdG8gY2hhbmdlIGNvbmdlc3Rpb24gY29udHJv bCBidXQNCj4gICAgICAgPiAgICAgICBlZmZlY3RpdmVseSBpdA0KPiAgICAgICA+ICAgICAgIGRv ZXMgd2l0aG91dCBhbnkgb3BlcmF0aW9uYWwgZXZpZGVuY2UuDQo+ICAgICAgID4NCj4gICAgICAg PiAgICAgICBXaGF0J3MgYWxzbyBpcyBtaXNzaW5nIGFuZCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bDoN Cj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIC0gRm9yICgxKSwgYSBoaW50IGZvciBhbiBpbXBs ZW1lbnRlciBzYXlpbmcgdGhhdCBiZWNhdXNlDQo+ICAgICAgID4gICAgICAgUkFDSy1UTFAgaXMN Cj4gICAgICAgPiAgICAgICAgICBhYmxlIHRvIGRldGVjdCBhIGxvc3Mgb2YgYSByZXhtaXQgdW5s aWtlIGFueSBvdGhlcg0KPiAgICAgICBsb3NzDQo+ICAgICAgID4gICAgICAgZGV0ZWN0aW9uDQo+ ICAgICAgID4gICAgICAgICAgYWxnb3JpdGhtLCB0aGUgc2VuZGVyIE1VU1QgcmVhY3QgdHdpY2Ug dG8gY29uZ2VzdGlvbg0KPiAgICAgICA+ICAgICAgIChhbmQgY2l0ZQ0KPiAgICAgICA+ICAgICAg ICAgIFJGQyA1NjgxKS4gQW5kIGNpdGUgYSBkb2N1bWVudCB3aGVyZSBuZWNlc3NhcnkNCj4gICAg ICAgY29ycmVjdA0KPiAgICAgICA+ICAgICAgIGFjdGlvbnMNCj4gICAgICAgPiAgICAgICAgICBh cmUgZGVzY3JpYmVkLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgLSBGb3IgKDEpLCBhZHZp c2UgdGhhdCBhbiBpbXBsZW1lbnRlciBuZWVkcyB0byBrZWVwDQo+ICAgICAgIHRyYWNrDQo+ICAg ICAgID4gICAgICAgd2hlbiBpdA0KPiAgICAgICA+ICAgICAgICAgIGRldGVjdHMgYSBsb3NzIG9m IGEgcmV0cmFuc21pdHRlZCBzZWdtZW50LiBDdXJyZW50DQo+ICAgICAgID4gICAgICAgYWxnb3Jp dGhtcw0KPiAgICAgICA+ICAgICAgICAgIGluIHRoZSBkcmFmdCBkZXRlY3QgYSBsb3NzIG9mIHJl dHJhbnNtaXR0ZWQgc2VnbWVudA0KPiAgICAgICA+ICAgICAgIGV4YWN0bHkgaW4NCj4gICAgICAg PiAgICAgICAgICB0aGUgc2FtZSB3YXkgYXMgbG9zcyBvZiBhbnkgb3RoZXIgc2VnbWVudC4gVGhl cmUNCj4gICAgICAgc2VlbXMNCj4gICAgICAgPiAgICAgICB0byBiZQ0KPiAgICAgICA+ICAgICAg ICAgIG5vdGhpbmcgdG8gdHJhY2sgd2hlbiBhIHJldHJhbnNtaXNzaW9uIG9mIGENCj4gICAgICAg PiAgICAgICByZXRyYW5zbWl0dGVkIHNlZ21lbnQNCj4gICAgICAgPiAgICAgICAgICB0YWtlcyBw bGFjZS4gVGhlcmVmb3JlLCB0aGUgYWxnb3JpdGhtcyBzaG91bGQgaGF2ZQ0KPiAgICAgICA+ICAg ICAgIGFkZGl0aW9uYWwNCj4gICAgICAgPiAgICAgICAgICBhY3Rpb25zIHRvIGNvcnJlY3RseSB0 cmFjayB3aGVuIHN1Y2ggYSBsb3NzIGlzDQo+ICAgICAgIGRldGVjdGVkLg0KPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgLSBGb3IgKDEpLCBkaXNjdXNzaW9uIG9uIGhvdyBtYW55IHRpbWVzIGEg bG9zcyBvZiBhDQo+ICAgICAgID4gICAgICAgcmV0cmFuc21pc3Npb24NCj4gICAgICAgPiAgICAg ICAgICBvZiB0aGUgc2FtZSBzZWdtZW50IG1heSBvY2N1ciBhbmQgYmUgZGV0ZWN0ZWQuIFNlZW1z DQo+ICAgICAgID4gICAgICAgdGhhdCBpdA0KPiAgICAgICA+ICAgICAgICAgIG1heSBiZSBwb3Nz aWJsZSB0byBkcm9wIGEgcmV4bWl0dGVkIHNlZ21lbnQgbW9yZSB0aGFuDQo+ICAgICAgID4gICAg ICAgb25jZSBhbmQNCj4gICAgICAgPiAgICAgICAgICBkZXRlY3QgaXQgYWxzbyBzZXZlcmFsIHRp bWVzPyAgV2hhdCBhcmUgdGhlDQo+ICAgICAgID4gICAgICAgaW1wbGljYXRpb25zPw0KPiAgICAg ICA+DQo+ICAgICAgID4gICAgICAgLSBJZiBwcmV2aW91cyBpcyBwb3NzaWJsZSwgdGhlbiB0aGUg YWxnb3JpdGhtIHBvc3NpYmx5DQo+ICAgICAgIGFsc28NCj4gICAgICAgPiAgICAgICAgICBtYXkg ZGV0ZWN0IGEgbG9zcyBvZiBhIG5ldyBzZWdtZW50IHRoYXQgd2FzIHNlbnQNCj4gICAgICAgZHVy aW5nDQo+ICAgICAgID4gICAgICAgZmFzdA0KPiAgICAgICA+ICAgICAgICAgIHJlY292ZXJ5PyBU aGlzIGlzIGFsc28gbG9zcyBpbiB0d28gc3VjY2Vzc2l2ZSB3aW5kb3dzDQo+ICAgICAgIG9mDQo+ ICAgICAgID4gICAgICAgZGF0YSwNCj4gICAgICAgPiAgICAgICAgICBhbmQgY3duZCBNVVNUIGJl IGxvd2VyZWQgdHdpY2UuIFRoaXMgZGlzY3Vzc2lvbiBhbmQNCj4gICAgICAgPiAgICAgICBuZWNl c3NhcnkNCj4gICAgICAgPiAgICAgICAgICBhY3Rpb25zIHRvIHRyYWNrIGl0IGFyZSBtaXNzaW5n LCBpZiBzdWNoIHNjZW5hcmlvIGlzDQo+ICAgICAgID4gICAgICAgcG9zc2libGUuDQo+ICAgICAg ID4NCj4gICAgICAgPiAgICAgICA+IFdoYXQgYW0gSSBtaXNzaW5nPw0KPiAgICAgICA+DQo+ICAg ICAgID4gICAgICAgSG9wZSB0aGUgYWJvdmUgaGVscHMuDQo+ICAgICAgID4NCj4gICAgICAgPiAg ICAgICAvTWFya2t1DQo+ICAgICAgID4NCj4gICAgICAgPg0KPiAgICAgICA+IDxzbmlwcGluZyB0 aGUgcmVzdD4NCj4gICAgICAgPg0KPiAgICAgICA+DQo+DQo+DQo+DQo= --_000_CY1PR00MB0172182657354535DF24E790B6C49CY1PR00MB0172namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGhhdmUgYSBub3RlIGluIHRoaXMgUkZDIGFi b3V0IGNvbmdlc3Rpb24gY29udHJvbCBhY3Rpb24gdXBvbiBkZXRlY3RpbmcgbG9zdCByZXRyYW5z bWlzc2lvbihzKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IHRjcG0gJmx0O3RjcG0tYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+ T24gQmVoYWxmIE9mIDwvYj4NCk1hcnRpbiBEdWtlPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBEZWNlbWJlciAxNywgMjAyMCA3OjMwIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJra3UgS29qbyAm bHQ7a29qb0Bjcy5oZWxzaW5raS5maSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5vcmcg RXh0ZW5zaW9ucyAmbHQ7dGNwbUBpZXRmLm9yZyZndDs7IGRyYWZ0LWlldGYtdGNwbS1yYWNrQGll dGYub3JnOyBNaWNoYWVsIFR1ZXhlbiAmbHQ7dHVleGVuQGZoLW11ZW5zdGVyLmRlJmd0OzsgZHJh ZnQtaWV0Zi10Y3BtLXJhY2suYWxsQGlldGYub3JnOyBMYXN0IENhbGwgJmx0O2xhc3QtY2FsbEBp ZXRmLm9yZyZndDs7IHRjcG0tY2hhaXJzICZsdDt0Y3BtLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW0VYVEVSTkFMXSBSZTogW3RjcG1dIExhc3QgQ2FsbDogJmx0O2Ry YWZ0LWlldGYtdGNwbS1yYWNrLTEzLnR4dCZndDsoVGhlUkFDSy1UTFBsb3NzZGV0ZWN0aW9uYWxn b3JpdGhtZm9yVENQKSB0byBQcm9wb3NlZCBTdGFuZGFyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWFya2t1LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsIG5vdyBJIHVuZGVyc3RhbmQg eW91ciBvYmplY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NYXJ0aW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMgMTcsIDIwMjAgYXQgMTI6NDYgQU0gTWFya2t1 IEtvam8gJmx0OzxhIGhyZWY9Im1haWx0bzprb2pvQGNzLmhlbHNpbmtpLmZpIj5rb2pvQGNzLmhl bHNpbmtpLmZpPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8YnI+DQo8YnI+DQpPbiBXZWQsIDE2IERlYyAy MDIwLCBNYXJ0aW4gRHVrZSB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEkgc3BlbnQgYSBsaXR0bGUg bG9uZ2VyIGxvb2tpbmcgYXQgdGhlIHNwZWNzIG1vcmUgY2FyZWZ1bGx5LCBhbmQgSSBleHBsYWlu ZWQgKDEpPGJyPg0KJmd0OyBpbmNvcnJlY3RseSBpbiBteSBsYXN0IHR3byBtZXNzYWdlcy4gUDIx Li4yOSBhcmUgbm90IExpbWl0ZWQgVHJhbnNtaXQgcGFja2V0cy4mbmJzcDs8YnI+DQo8YnI+DQpD b3JyZWN0LiBKdXN0IG5vcm1hbCB0aGUgcnVsZSB0aGF0IGFsbG93cyBzZW5kaW5nIG5ldyBkYXRh IGR1cmluZyBmYXN0IDxicj4NCnJlY292ZXJ5Ljxicj4NCjxicj4NCiZndDsgSG93ZXZlciwgdW5s ZXNzIEknbSBtaXNzaW5nIHNvbWV0aGluZyBlbHNlLCA2Njc1IGlzIGNsZWFyIHRoYXQgdGhlIHJl Y292ZXJ5IHBlcmlvZDxicj4NCiZndDsgZG9lcyBub3QgZW5kIHVudGlsIHRoZSBjdW11bGF0aXZl IGFjayBhZHZhbmNlcywgbWVhbmluZyB0aGF0IGRldGVjdGluZyB0aGUgbG9zdDxicj4NCiZndDsg cmV0cmFuc21pc3Npb24gb2YgUDEgZG9lcyBub3QgdHJpZ2dlciBhbm90aGVyIE1EIGRpcmVjdGx5 Ljxicj4NCjxicj4NCkFzIEkgaGF2ZSBzYWlkIGVhcmxpZXIsIFJGQyA2Njc1IGRvZXMgbm90IHJl cGVhdCBhbGwgY29uZ2VzdGlvbiBjb250cm9sIDxicj4NCnByaW5jaXBsZXMgZnJvbSBSRkMgNTY4 MS4gSXQgZGVmaW5pdGVseSBob25vcnMgdGhlIENDIHByaW5jaXBsZSB0aGF0PGJyPg0KcmVxdWly ZXMgdG8gdHJlYXQgYSBsb3NzIG9mIGEgcmV0cmFuc21pc3Npb24gYXMgYSBuZXcgY29uZ2VzdGlv biA8YnI+DQppbmRpY2F0aW9uIGFuZCBhbm90aGVyIE1ELiBJIGJlbGlldmUgSSBhbSBvYmxpZ2F0 ZWQgdG8ga25vdyB0aGlzIGFzIGEgPGJyPg0KY28tYXV0aG9yIG9mIFJGQyA2Njc1LiA7KTxicj4N Cjxicj4NClJGQyA2Njc1IGV4cGxpY2l0bHkgaW5kaWNhdGVzIHRoYXQgaXQgZm9sbG93cyBSRkMg NTY4MSBieSBzdGF0aW5nIGluIHRoZSA8YnI+DQphYnN0cmFjdDo8YnI+DQo8YnI+DQomcXVvdDsg Li4uIGNvbmZvcm1zIHRvIHRoZSBzcGlyaXQgb2YgdGhlIGN1cnJlbnQgY29uZ2VzdGlvbiBjb250 cm9sPGJyPg0KJm5ic3A7IHNwZWNpZmljYXRpb24gKFJGQyA1NjgxIC4uLiZxdW90Ozxicj4NCjxi cj4NCkFuZCBpbiB0aGUgaW50cm86PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyZxdW90O1RoZSBh bGdvcml0aG0gc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgaXMgYSBzdHJhaWdodGZvcndhcmQ8 YnI+DQombmJzcDsgJm5ic3A7IFNBQ0stYmFzZWQgbG9zcyByZWNvdmVyeSBzdHJhdGVneSB0aGF0 IGZvbGxvd3MgdGhlJm5ic3A7IGd1aWRlbGluZXM8YnI+DQombmJzcDsgJm5ic3A7IHNldCBpbiBb UkZDNTY4MV0gLi4uJnF1b3Q7PGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnl0 aGluZyB1bmNsZWFyIGluIHRoaXMuPGJyPg0KPGJyPg0KUkZDIDY2NzUgYW5kIGFsbCBvdGhlciBz dGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2xzIChSRkMgNTU4MSBhbmQgUkZDIDxicj4NCjY1ODIp IGhhbmRsZSBhIGxvc3Mgb2YgYSByZXRyYW5zbWlzc2lvbiBieSAmcXVvdDtlbmZvcmNpbmcmcXVv dDsgUlRPIHRvIGRldGVjdCBpdC4gPGJyPg0KQW5kIFJUTyBndWFyYW50ZWVzIE1ELiBSQUNLLVRM UCBjaGFuZ2VzIHRoZSBsb3NzIGRldGVjdGlvbiBpbiB0aGlzIGNhc2UgPGJyPg0KYW5kIHRoZXJl Zm9yZSB0aGUgc3RhbmRhcmQgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobXMgZG8gbm90IGhh dmUgPGJyPg0KYWN0aW9ucyB0byBoYW5kbGUgaXQgY29ycnJlY3RseS4gVGhhdCBpcyB0aGUgcG9p bnQuPGJyPg0KPGJyPg0KQlIsPGJyPg0KPGJyPg0KL01hcmtrdTxicj4NCjxicj4NCiZndDsgVGhh bmtzIGZvciB0aGlzIGV4ZXJjaXNlISBJdCdzIHJlZnJlc2hlZCBteSBtZW1vcnkgb2YgdGhlc2Ug ZGV0YWlscyBhZnRlciB3b3JraW5nPGJyPg0KJmd0OyBvbiBzbGlnaHRseSBkaWZmZXJlbnQgUVVJ QyBhbGdvcml0aG1zIGEgbG9uZyB0aW1lLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBXZWQsIERl YyAxNiwgMjAyMCwgMTg6NTUgTWFydGluIER1a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u aC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi5oLmR1a2VAZ21haWwuY29t PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAoMSkgRmxpZ2h0c2l6ZTogaW4gUkZDIDY2NzUuIFNl Y3Rpb24gNSwgU3RlcCA0LjI6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgKDQuMikgc3N0aHJlc2ggPSBjd25kID0gKEZsaWdodFNpemUgLyAyKTxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFRoZSBjb25nZXN0aW9uIHdpbmRvdyAoY3duZCkgYW5kIHNsb3cgc3RhcnQgdGhyZXNob2xk PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAoc3N0aHJlc2gpIGFyZSByZWR1Y2VkIHRvIGhhbGYgb2YgRmxpZ2h0U2l6ZSBwZXIgW1JGQzU2 ODFdLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgQWRkaXRpb25hbGx5LCBub3RlIHRoYXQgW1JGQzU2ODFdIHJlcXVpcmVzIHRoYXQgYW55 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBzZWdtZW50cyBzZW50IGFzIHBhcnQgb2YgdGhlIExpbWl0ZWQgVHJhbnNtaXQgbWVjaGFuaXNt IG5vdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgYmUgY291bnRlZCBpbiBGbGlnaHRTaXplIGZvciB0aGUgcHVycG9zZSBvZiB0aGUgYWJv dmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IGVxdWF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJSVVDIHRoZSBzZWdtZW50cyBQMjEu LlAyOSBpbiB5b3VyIGV4YW1wbGUgd2VyZSBzZW50IGJlY2F1c2Ugb2YgTGltaXRlZDxicj4NCiZn dDsgVHJhbnNtaXQsIGFuZCBzbyBkb24ndCBjb3VudC4gVGhlIGZsaWdodHNpemUgZm9yIHRoZSBw dXJwb3NlcyBvZiAoNC4yKSBpczxicj4NCiZndDsgdGhlcmVmb3JlIDIwIGFmdGVyIGJvdGggbG9z c2VzLCBhbmQgdGhlIGN3bmQgZG9lcyBub3QgZ28gdXAgb24gdGhlIHNlY29uZDxicj4NCiZndDsg bG9zcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgKDIpPGJyPg0KJmd0OyAmcXVvdDsgRXZlbiBhIHNp bmdsZSBzaG90IGJ1cnN0IGV2ZXJ5IHRpbWUgdGhlcmUgaXMgc2lnbmlmaWNhbnQgbG9zczxicj4N CiZndDsgZXZlbnQgaXMgbm90IGFjY2VwdGFibGUsIG5vdCB0byBtZW50aW9uIGNvbnRpbnVvdXMg YWdncmVzc2l2ZW5lc3MsIGFuZDxicj4NCiZndDsgdGhpcyBpcyBleGFjdGx5IHdoYXQgUkZDIDI5 MTQgYW5kIFJGQyA1MDMzIGV4cGxpY2l0bHkgYWRkcmVzcyBhbmQgd2Fybjxicj4NCiZndDsgYWJv dXQuJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O1NpZ25pZmljYW50IGxvc3MgZXZl bnQmcXVvdDsgaXMgdGhlIGtleSBwaHJhc2UgaGVyZS4gVGhlIGludGVudCBvZiBUTFAvUFRPIGlz IHRvPGJyPg0KJmd0OyBlcXVhbGl6ZSB0aGUgdHJlYXRtZW50IG9mIGEgc21hbGwgcGFja2V0IGxv c3Mgd2hldGhlciBpdCBoYXBwZW5lZCBpbiB0aGU8YnI+DQomZ3Q7IG1pZGRsZSBvZiBhIGJ1cnN0 IG9yIHRoZSBlbmQuIFdoeSBzaG91bGQgYW4gaXNvbGF0ZWQgbG9zcyBiZSB0cmVhdGVkPGJyPg0K Jmd0OyBkaWZmZXJlbnRseSBiYXNlZCBvbiBpdHMgcG9zaXRpb24gaW4gdGhlIGJ1cnN0PyBUaGlz IGlzIGp1c3QgYSBsb2dpY2FsPGJyPg0KJmd0OyBleHRlbnNpb24gb2YgZmFzdCByZXRyYW5zbWl0 LCB3aGljaCBhbHNvIG1vZGlmaWVkIHRoZSBSVE8gcGFyYWRpZ20uIFRoZTxicj4NCiZndDsgd29y a2luZyBncm91cCBjb25zZW5zdXMgaXMgdGhhdCB0aGlzIGlzIGEgZmVhdHVyZSwgbm90IGEgYnVn OyB5b3UncmUgd2VsY29tZTxicj4NCiZndDsgdG8gZmVlbCBvdGhlcndpc2UgYnV0IEkgc3VzcGVj dCB5b3UncmUgaW4gdGhlIHJvdWdoIGhlcmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHM8 YnI+DQomZ3Q7IE1hcnRpbjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFdlZCwg RGVjIDE2LCAyMDIwIGF0IDQ6MTEgUE0gTWFya2t1IEtvam8gJmx0OzxhIGhyZWY9Im1haWx0bzpr b2pvQGNzLmhlbHNpbmtpLmZpIiB0YXJnZXQ9Il9ibGFuayI+a29qb0Bjcy5oZWxzaW5raS5maTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIaSBNYXJ0 aW4sPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTZWUgaW5s aW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7T24gV2Vk LCAxNiBEZWMgMjAyMCwgTWFydGluIER1a2Ugd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEhpIE1hcmtrdSw8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IFRoZXJlIGlzIGEgdG9uIGhlcmUsIGJ1dCBJJ2xsIHRyeSB0byBhZGRyZXNzIHRoZSB0 b3AgcG9pbnRzLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtIb3BlZnVsbHk8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyB0aGV5IG9idmlhdGUgdGhl IHJlc3QuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTb3Jy eSBmb3IgYmVpbmcgdmVyYm9zZS4gSSB0cmllZCB0byBiZSBjbGVhciBidXQgeW91IGFjdHVhbGx5 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlbW92ZWQgbXk8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7a2V5IGlzc3Vlcy9xdWVzdGlvbnMgOyk8YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgMS48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBbTWFya2t1XTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7ICZxdW90O0htbSwgbm90IHN1cmUgd2hhdCB5b3UgbWVh biBieSAmcXVvdDt0aGlzIGlzIGEgbmV3IGxvc3MgZGV0ZWN0aW9uPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FmdGVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgYWNrbm93bGVkZ21lbnQgb2YgbmV3IGRhdGEmcXVvdDs/PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQnV0IGFueXdheSwgUkZDIDU2ODEgZ2l2ZXMgdGhl IGdlbmVyYWwgcHJpbmNpcGxlIHRvIHJlZHVjZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtjd25kIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 IHNzdGhyZXNoIHR3aWNlIGlmIGEgcmV0cmFuc21pc3Npb24gaXMgbG9zdCBidXQgSU1ITyAoYW5k IEk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmVsaWV2ZSBtYW55PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgd2hvIGhhdmUgZGVzaWduZWQgbmV3 IGxvc3MgcmVjb3ZlcnkgYW5kIENDIGFsZ29yaXRobXMgb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50ZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyB0aGVtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg YWdyZWUpIHRoYXQgaXQgaXMgaGFyZCB0byBnZXQgdGhpbmdzIHJpZ2h0IGlmIG9ubHkgY29uZ2Vz dGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250cm9sPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgcHJpbmNpcGxlcyBhcmUgYXZhaWxhYmxl IGFuZCBubyBhbGdvcml0aG0uJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBbTWFydGlu XTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFNvIDY2NzUgU2VjIDUg aXMgcXVpdGUgZXhwbGljaXQgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBjd25kPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlZHVjdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7IHBlciBmYXN0IHJlY292ZXJ5IGVwaXNvZGUsIHdoaWNoIGVuZHMg b25jZSBuZXcgZGF0YSBoYXMgYmVlbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IGFja25vd2xlZGdlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1RvIGJlIG1vcmUgcHJlY2lzZTogZmFzdCByZWNvdmVyeSBlbmRzIHdoZW4gdGhl IGN1cnJlbnQgd2luZG93PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlY29t ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3VtdWxhdGl2ZWx5IGFja25v d2xlZGdlZCwgdGhhdCBpcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyg0LjEpIFJlY292ZXJ5UG9pbnQgKD0gSGlnaERhdGEgYXQgdGhlIGJlZ2lubmluZykg YmVjb21lczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthY2tub3dsZWRnZWQ8 YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0kgYmVsaWV2ZSB3 ZSBhZ3JlZSBhbmQgeW91IG1lYW50IHRoaXMgYWx0aG91Z2ggbmV3IGRhdGEgYmVsb3c8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmVjb3ZlcnlQb2ludCBtYXkgYmVjb21lIGN1 bXVsYXRpdmVseSBhY2tub3dsZWRnZWQgYWxyZWFkeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtlYXJsaWVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2R1 cmluZyB0aGUgZmFzdCByZWNvdmVyeS4gUmVubyBsb3NzIHJlY292ZXJ5IGluIFJGQyA1NjgxIGVu ZHMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZW48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KGFueSkgbmV3IGRhdGEgaGFzIGJlZW4gYWNrbm93bGVk Z2VkLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBC eSBkZWZpbml0aW9uLCBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3QgaXQgaXMgYmVjYXVzZTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IG5ld2VyIGRhdGEgaGFzIGJl ZW4gYWNrbm93bGVkZ2VkLCBzbyBpdCdzIGEgbmV3IHJlY292ZXJ5PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2VwaXNvZGUuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtOb3Qgc3VyZSB3aGVyZSB5b3UgaGF2ZSB0aGlzIGRlZmluaXRpb24/ IE5ld2VyIHRoYW4gd2hhdCBhcmUgeW91PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3JlZmVycmluZyB0bz88YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0J1dCwgeWVzLCBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3Qgd2l0aCBSRkMgNjY3 NSBhbGdvcml0aG0sPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2l0IHJlcXVp cmVzIFJUTyB0byBiZSBkZXRlY3RlZCBhbmQgZGVmaW5pdGVseSBzdGFydHMgYSBuZXc8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVjb3Zlcnk8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZXBpc29kZS4gVGhhdCBpcywgYSBuZXcgcmVjb3ZlcnkgZXBpc29k ZSBpcyBlbmZvcmNlZCBieSBzdGVwPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OygxLmEpIG9mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO05leHRTZWcgKCkg d2hpY2ggcHJldmVudHMgcmV0cmFuc21pc3Npb24gaWYgYSBzZWdtZW50IHRoYXQgaGFzPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FscmVhZHk8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YmVlbiByZXRyYW5zbWl0dGVkLiBJZiBSQUNLLVRMUCBpcyB1c2Vk IGZvciBkZXRlY3RpbmcgbG9zcyB3aXRoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1JGQyA2Njc1PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaW5ncyBn ZXQgZGlmZmVyZW50IGluIG1hbnkgd2F5cywgYmVjYXVzZSBpdCBtYXkgZGV0ZWN0IGxvc3Mgb2Y8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyZXRyYW5zbWlzc2lvbi4gSXQgd291bGQgcHJldHR5IG11Y2ggcmVx dWlyZSBhbiBlbnRpcmUgcmVkZXNpZ248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7b2YgdGhlIGFsZ29yaXRoLiBGb3IgZXhhbXBsZSwgY2FsY3VsYXRpb24gb2YgcGlwZSBkb2Vz IG5vdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25zaWRlcjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWdtZW50cyB0aGF0IGhhdmUgYmVlbiByZXRy YW5zbWl0dGVkIG1vcmUgdGhhbiBvbmNlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBNZWFud2hpbGUsIGR1cmluZyB0aGUgRmFzdCBSZWNvdmVyeSBw ZXJpb2QgdGhlIGluY29taW5nIGFja3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7aW1wbGljaXRseTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHJl bW92ZSBkYXRhIGZyb20gdGhlIG5ldHdvcmsgYW5kIHRoZXJlZm9yZSBrZWVwIGZsaWdodHNpemU8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG93Ljxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SW5jb3JyZWN0LiBGbGlnaHRTaXplICE9IHBp cGUuIE9ubHkgY3VtdWxhdGl2ZSBhY2tzIHJlbW92ZSBkYXRhPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2Zyb208YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 RmxpZ2h0U2l6ZSBhbmQgbmV3IGRhdGEgdHJhbnNtaXR0ZWQgZHVyaW5nIGZhc3QgcmVjb3Zlcnkg aW5mbGF0ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGbGlnaHRTaXplLiBI b3cgRmxpZ2h0U2l6ZSBldm9sdmVzIGRlcGVuZHMgb24gbG9zcyBwYXR0ZXJuIGFzIEk8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2FpZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7SXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IEZsaWdodFNpemUgaXMgbG93 LCBpdCBtYXkgZXJyIGluIGJvdGg8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZGlyZWN0aW9ucy4gQSBzaW1wbGUgZXhhbXBsZSBjYW4gYmUgdXNlZCBhcyBhIHByb29mIGZvciB0 aGUgY2FzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVyZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjd25kIGluY3JlYXNlcyBpZiBhIGxvc3Mgb2Yg cmV0cmFuc21pc3Npb24gaXMgZGV0ZWN0ZWQgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3JlcGFpcmVkOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7UkZDIDY2NzUgcmVjb3Zlcnkgd2l0aCBSQUNLLVRMUCBsb3NzIGRldGVjdGlvbjo8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KGNvbnRhaW5zIHNvbWUgaW5hY2N1 cmFjaWVzIGJlY2F1c2UgaXQgaGFzIG5vdCBiZWVuIGRlZmluZWQgaG93PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvc3QgcmV4bWl0cyBhcmUgY2FsY3VsYXRlZCBpbnRvIHBp cGUpPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjd25kPTIw OyBwYWNrZXRzIFAxLC4uLixQMjAgaW4gZmxpZ2h0ID0gY3VycmVudCB3aW5kb3cgb2YgZGF0YTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbUDEgZHJvcHBlZCBhbmQgcmV4bWl0 IG9mIFAxIHdpbGwgYWxzbyBiZSBkcm9wcGVkXTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7RHVwQWNrIHcvU0FDSyBmb3IgUDIgYXJyaXZlczxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbbG9zcyBvZiBQMSBkZXRlY3RlZCBhZnRlciBvbmUg UlRUIGZyb20gb3JpZ2luYWwgeG1pdCBvZiBQMV08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7W2N3bmQ9c3N0aHJlc2g9MTBdPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1AxIGlzIHJleG1pdHRlZCAoYW5kIGl0IGxvZ2ljYWxseSBzdGFydHMgbmV4dCB3aW5k b3cgb2YgZGF0YSk8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0R1cEFja3Mgdy8gU0FDSyBmb3Igb3JpZ2luYWwgUDMuLjExIGFycml2ZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEdXBBY2sgdy8gU0FDSyBmb3Igb3JpZ2luYWwgUDEyIGFy cml2ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W2N3bmQtcGlwZSA9IDEw LTkgJmd0Oz0xXTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZW5kIFAyMTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEdXBBY2sgdy9TQUNLIGZvciBQMTMg YXJyaXZlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZW5kIFAyMjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7RHVwQWNrIHcvU0FDSyBmb3IgUDIwIGFycml2ZXM8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VuZCBQMjk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7W0ZsaWdodFNpemU9MjldPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsoQWNrIGZvciByZXhtaXQgb2YgUDEgd291bGQgYXJyaXZlIGhlcmUg dW5sZXNzIGl0IGdvdCBkcm9wcGVkKTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7RHVwQWNrIHcvU0FDSyBmb3IgUDIxIGFycml2ZXM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7W2xvc3Mgb2YgcmV4bWl0IFAxIGRldGVjdGVkIGFmdGVyIG9u ZSBSVFQgZnJvbSByZXhtaXQgb2YgUDFdPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtTRVQgY3duZCA9IHNzdGhyZXNoID0gRmxpZ2h0U2l6ZS8yPSAyOS8yID0g MTQsNTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q1dORCBJ TkNSRUFTRVMgd2hlbiBpdCBzaG91bGQgYmUgYXQgbW9zdCA1IGFmdGVyIGhhbHZpbmcgaXQ8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHdpY2UhISE8YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgV2UgY2FuIGNvbnRpbnVlIHRvIGdv IGFyb3VuZCBvbiBvdXIgaW50ZXJwcmV0YXRpb24gb2YgdGhlc2U8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnRzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7IGJ1dCBmdW5kYW1lbnRhbGx5IGlmIHRoZXJlIGlzIGFtYmlndWl0eSBpbiA1 NjgxLzY2NzUgd2Ugc2hvdWxkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jp czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHRob3NlIFJGQ3MgcmF0 aGVyIHRoYW4gZXhwYW5kIHRoZSBzY29wZSBvZiBSQUNLLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QXMgSSBzYWlkIGVhcmxpZXIsIEkgYW0gbm90IG9wcG9z aW5nIGJpcywgdGhvdWdoIDU2ODFiaXMgd3VvbGQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7bm90PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIG5lZWRl ZCwgSSB0aGluay48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0J1dCBsZXQgbWUgcmVwZWF0OiBpZiB3ZSBwdWJsaXNoIFJBQ0stVExQIG5vdyB3aXRob3V0IG5l Y2Vzc2FyeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3YXJuaW5nczxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvciB3aXRoIGEgY29ycmVjdCBjb25nZXNp b24gY29udHJvbCBhbGdvcml0aG0gc29tZW9uZSB3aWxsIHRyeTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtp bXBsZW1lbnQgUkFDSy1UTFAgd2l0aCBSRkMgNjY3NSBhbmQgaXQgd2lsbCBiZSBhIHRvdGFsIG1l c2guPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWhhdmlvciB3aWxsIGJlIHVucHJlZGljdGFibGUgYW5k IHF1aXRlIGxpa2VseSB1bnNhZmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Y29uZ2VzdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250cm9sIGJl aGF2aW9yLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyAyLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFtNYXJra3VdPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgJnF1b3Q7IEluIHNob3J0Ojxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFdoZW4gd2l0aCBhIG5vbi1S QUNLLVRMUCBpbXBsZW1lbnRhdGlvbiB0aW1lciAoUlRPKSBleHBpcmVzOjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjd25kPTE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBNU1MsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsgYW5kIHNsb3cgc3RhcnQgaXMgZW50ZXJlZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBXaGVuIHdpdGggYSBSQUNLX1RMUCBpbXBsZW1lbnRhdGlvbiB0aW1lciAo UFRPKSBleHBpcmVzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IG5v cm1hbCBmYXN0IHJlY292ZXJ5IGlzIGVudGVyZWQgKHVubGVzcyBpbXBsZW1lbnRpbmc8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBhbHNvIFBSUikuIFNvIG5vIFJUTyBy ZWNvdmVyeSBhcyBleHBsaWNpdGx5IHN0YXRlZCBpbiBTZWMuPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzcuNC4xLiZxdW90Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgW01h cnRpbl08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSBtYXkg YmUgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuIFBUTyBpcyBub3QgdGhlIHNhbWUgYXM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UlRPLCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBib3RoIG1lY2hhbmlzbXMgZXhpc3QhIFRoZSBsb3NzIHJl c3BvbnNlIHRvIGEgUFRPIGlzIHRvIHNlbmQgYTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtwcm9iZTs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyB0 aGUgUlRPIHJlc3BvbnNlIGlzIGFzIHdpdGggY29udmVudGlvbmFsIFRDUC4gSW4gU2VjdGlvbiA3 LjM6PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtObywgSSBk b24ndCB0aGluayBJIG1pc3VuZGVyc3Rvb2QuIElmIHlvdSBjYWxsIHRpbWVvdXQgd2l0aDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbm90aGVyIG5hbWUsIGl0IGlzIHN0aWxs IHRpbWVvdXQuIEFuZCBjb25nZXN0aW9uIGNvbnRyb2wgZG9lczxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtub3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Y29uc2lkZXIgd2hpY2ggc2VnbWVudHMgdG8gc2VuZCAoU05ELlVOQSB2cy4gcHJvYmUgdy8gaGln aGVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlcXVlbmNlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO251bWJlciksIG9ubHkgaG93IG11Y2ggaXMgc2Vu dC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1lvdSBpZ25v cmVkIG15IG1ham9yIHBvaW50IHdoZXJlIEkgZGVjb3VwbGVkIGNvbmdlc3Rpb24gY29udHJvbDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmcm9tIGxvc3M8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGV0ZWN0aW9uIGFuZCBsb3NzIHJlY292ZXJ5IGFuZCBj b21wYXJlZCBSRkMgNTY4MSBiZWhhdmlvciB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtSQUNLLVRMUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWhh dmlvciBpbiBleGFjdGx5IHRoZSBzYW1lIHNjZW5hcmlvIHdoZXJlIGFuIGVudGlyZSBmbGlnaHQg aXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG9zdCBhbmQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGltZXIgZXhwaXJlcy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BsZWFzZSBjb21tZW50IHdoeSBjb25nZXN0 aW9uIGNvbnRyb2wgYmVoYXZpb3IgaXMgYWxsb3dlZCB0byBiZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyYWRpY2FsbHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZGlmZmVyZW50IGluIHRoZXNlIHR3byBpbXBsZW1lbnRhdGlvbnM/PGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRkMgNTY4MSAmYW1wOyBSRkMgNjI5 OCB0aW1lb3V0Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJUTz1TUlRUKzQqUlRUVkFSIChSVE8gdXNlZCBm b3IgYXJtaW5nIHRoZSB0aW1lcik8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MS4gUlRPIHRpbWVyIGV4cGlyZXM8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4g Y3duZD0xIE1TUzsgc3N0aHJlc2g9RmxpZ2h0U2l6ZS8yOyByZXhtaXQgb25lIHNlZ21lbnQ8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7My4gQWNrIG9mIHJleG1pdCBzZW50IGluIHN0ZXAgMiBhcnJpdmVzPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzQuIGN3bmQg PSBjd25kKzEgTVNTOyBzZW5kIHR3byBzZWdtZW50czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JBQ0stVExQIHRpbWVvdXQ6PGJyPg0KJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyAmbmJzcDtQVE89bWluKDIqU1JUVCxSVE8pIChQVE8gdXNlZCBmb3IgYXJtaW5nIHRo ZSB0aW1lcik8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MS4gUFRPIHRpbWVzIGV4cGlyZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4gKGN3bmQ9MSBNU1Mp OyAocmUpeG1pdCBvbmUgc2VnbWVudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszLiBBY2sgb2YgKHJlKXhtaXQgc2VudCBpbiBz cmVwIDIgYXJyaXZlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDs0LiBjd25kID0gc3N0aHJlc2ggPSBGbGlnaHRTaXplLzI7IHNl bmQgTj1jd25kIHNlZ21lbnRzPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtJZiBGbGlnaHRTaXplIGlzIDEwMCBzZWdtZW50cyB3aGVuIHRpbWVyIGV4cGlyZXMs IGNvbmdlc3Rpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udHJvbCBp czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgc2FtZSBpbiBzdGVwcyAx LTMsIGJ1dCBpbiBzdGVwIDQgdGhlIHN0YW5kYXJkIGNvbmdlc3Rpb248YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udHJvbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDthbGxvd3MgdHJhbnNtaXR0aW5nIDIgc2VnbWVudHMsIHdoaWxlIFJBQ0stVExQIHdv dWxkIGFsbG93PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JsYXN0aW5nIDUw IHNlZ21lbnRzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBBZnRlciBhdHRlbXB0aW5nIHRvIHNlbmQgYSBsb3NzIHByb2JlLCByZWdhcmRsZXNzIG9m IHdoZXRoZXIgYTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb3NzPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7IHByb2JlIHdh cyBzZW50LCB0aGUgc2VuZGVyIE1VU1QgcmUtYXJtIHRoZSBSVE8gdGltZXIsIG5vdDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgUFRPPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7IHRpbWVyLCBpZiBGbGlnaHRTaXplIGlz IG5vdCB6ZXJvLiZuYnNwOyBUaGlzIGVuc3VyZXMgUlRPPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3JlY292ZXJ5IHJlbWFpbnM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIGxhc3QgcmVzb3J0IGlmIFRMUCBmYWlscy48 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAmcXVvdDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9lcyBub3QgcHJldmVu dCB0aGUgYWJvdmUgUkFDSy1UTFAgYmVoYXZpb3IgZnJvbSBnZXR0aW5nPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlYWxpemVkLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBTbyBhIHB1cmUgUlRPIHJlc3BvbnNlIGV4aXN0cyBp biB0aGUgY2FzZSBvZiBwZXJzaXN0ZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2Nvbmdlc3Rpb24gdGhhdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IGNhdXNlcyBsb3NzZXMgb2YgcHJvYmVzIG9yIHRoZWlyIEFDS3MuPGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtZZXMsIFJUTyByZXNwb25zZSBleGlzdHMg QlVUIG9ubHkgYWZ0ZXIgUkFDSy1UTFAgYXQgbGVhc3Qgb25jZTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtibGFzdHMgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO25ldHdvcmsuIEl0IG1heSB3ZWxsIGJlIHRoYXQgd2l0aCBzbWFsbGVyIHdpbmRvd3Mg UkFDSy1UTFAgaXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3VjY2Vzc2Z1 bDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkdXJpbmcgaXRzIFRMUCBpbml0 aWF0ZWQgb3Zlcmx5IGFnZ3Jlc3NpdmUgJnF1b3Q7ZmFzdCByZWNvdmVyeSZxdW90OyBhbmQ8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmV2ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZW50ZXJzIFJUTyByZWNvdmVyeSBiZWNhdXNlIGl0IG1heSBkZXRl Y3QgYW5kIHJlcGFpciBhbHNvIGxvc3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7b2Y8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmV4bWl0cy4gVGhhdCBp cywgaXQgY29udGludWVzIGF0IHRvbyBoaWdoIHJhdGUgZXZlbiBpZiBsb3N0PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JleG1pdHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7aW5kaWNhdGUgdGhhdCBjb25nZXN0aW9uIHBlcnNpc3RzIGluIHN1Y2Nlc3Np dmUgd2luZG93cyBvZiBkYXRhLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtB bmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d29yc2UsIGl0IGlzIHN1Y2Nl c3NmdWwgYmVjYXVzZSBpdCBwdXNoZXMgYXdheSBvdGhlciBjb21wYXRpYmxlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RDUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtmbG93cyBieSBiZWluZyB0b28gYWdncmVzc2l2ZSBhbmQgdW5mYWlyLjxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RXZlbiBhIHNpbmdsZSBzaG90 IGJ1cnN0IGV2ZXJ5IHRpbWUgdGhlcmUgaXMgc2lnbmlmaWNhbnQgbG9zczxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtldmVudCBpcyBub3QgYWNjZXB0YWJsZSwgbm90IHRvIG1l bnRpb24gY29udGludW91czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZ2dy ZXNzaXZlbmVzcywgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaXMg aXMgZXhhY3RseSB3aGF0IFJGQyAyOTE0IGFuZCBSRkMgNTAzMyBleHBsaWNpdGx5IGFkZHJlc3M8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIHdhcm48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWJvdXQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtBcmUgd2UgaWdub3JpbmcgdGhlc2UgQkNQcyB0aGF0IGhhdmUg SUVURiBjb25zZW5zdXM/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtBbmQgdGhlIG90aGVyIGltcG9ydGFudCBxdWVzdGlvbiBJJ2QgbGlrZSB0byBoYXZlIGFu IGFuc3dlcjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1do YXQgaXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbW9kaWZ5IHN0YW5kYXJkIFRDUCBjb25nZXN0aW9u PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnRyb2wgdG88YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlIGZhc3QgcmVjb3ZlcnkgaW5zdGVhZCBvZiBz bG93IHN0YXJ0IGZvciBhIGNhc2Ugd2hlcmUgdGltZW91dDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtpczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZWVk ZWQgdG8gZGV0ZWN0IHRoZSBwYWNrZXQgbG9zc2VzIGJlY2F1c2UgdGhlcmUgaXMgbm8gZmVlZGJh Y2s8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW5kIGFjazxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjbG9jayBpcyBsb3N0PyBSQUNLLVRMUCBleHBsaWNp dGx5IGluc3RydWN0cyB0byBkbyBzbyBpbiBTZWMuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzcuNC4xLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7QXMgSSBub3RlZDogYmFzZWQgb24gd2hhdCBpcyB3cml0dGVuIGluIHRoZSBkcmFmdCBp dCBkb2VzIG5vdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbnRlbmQgdG88 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y2hhbmdlIGNvbmdlc3Rpb24gY29u dHJvbCBidXQgZWZmZWN0aXZlbHkgaXQgZG9lcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOy9NYXJra3U8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgTWFydGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IE9uIFdlZCwgRGVjIDE2LCAyMDIw IGF0IDExOjM5IEFNIE1hcmtrdSBLb2pvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDs8YSBocmVmPSJtYWlsdG86a29qb0Bjcy5oZWxzaW5raS5maSIgdGFyZ2V0PSJfYmxh bmsiPmtvam9AY3MuaGVsc2lua2kuZmk8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGkgTWFydGluLDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtPbiBUdWUsIDE1IERlYyAyMDIw LCBNYXJ0aW4gRHVrZSB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBIaSBNYXJra3UsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLiBUaGUgYXV0aG9ycyB3aWxsIGluY29ycG9yYXRl PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDttYW55IG9mIHlvdXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgc3VnZ2VzdGlvbnMgYWZ0ZXIg dGhlIElFU0cgcmV2aWV3Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSdzIG9u ZSB0aGluZyBJIGRvbid0IHVuZGVyc3RhbmQgaW4geW91ciBjb21tZW50czo8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgJnF1b3Q7IFRoYXQgaXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHdoZXJlIGNh biBhbiBpbXBsZW1lbnRlciBmaW5kIGFkdmljZSBmb3IgY29ycmVjdDxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZ2Vz dGlvbiBjb250cm9sPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGFjdGlvbnMgd2l0aCBSQUNLLVRMUCwgd2hlbjo8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgKDEpIGEgbG9zcyBvZiByZXhtaXR0ZWQgc2Vn bWVudCBpcyBkZXRlY3RlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAoMikgYW4gZW50aXJlIGZsaWdodCBvZiBk YXRhIGdldHMgZHJvcHBlZCAoYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2RldGVjdGVkKSw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGF0IGlzLCB3 aGVuIHRoZXJlIGlzIG5vIGZlZWRiYWNrIGF2YWlsYWJsZSBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGltZW91dDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO2lzIG5lZWRlZCB0byBkZXRlY3QgdGhlIGxvc3MgJnF1b3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFNlY3Rpb24gOS4zIGlzIHRoZSBkaXNjdXNzaW9uIGFi b3V0IENDLCBhbmQgaXMgY2xlYXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dGhhdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGltcGxlbWVudGVyIHNob3VsZCB1c2Ug ZWl0aGVyIDU2ODEgb3IgNjkzNy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7SnVzdCBhIGNpdGUgbml0OiBSRkMgNTY4MSBwcm92aWRlcyBiYXNpYyBD QyBjb25jZXB0cyBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NvbWUgdXNlZnVsIENDPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtndWlkZWxp bmVzIGJ1dCBnaXZlbiB0aGF0IFJBQ0stVExQIE1VU1QgaW1wbGVtZW50IFNBQ0s8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbGdvcml0aG0gaW48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JGQyA1NjgxIGlzIG5vdCB0aGF0IHVzZWZ1bCBhbmQgYW4gaW1wbGVtZW50ZXIgcXVp dGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGlrZWx5PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtm b2xsb3dzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDttYWlubHkgdGhlIGFsZ29yaXRobSBpbiBSRkMgNjY3NSAoYW5kIG5v dCBSRkMgNjkzNyBhdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbGw8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2lmIG5vdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50aW5nIFBSUikuPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbmQg UkZDIDY2NzUgaXMgbm90IG1lbnRpb25lZCBpbiBTZWMgOS4zLCB0aG91Z2ggaXQgaXM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2xpc3RlZCBpbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlYy4gNCAoUmVxdWlyZW1lbnRzKS48YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBZb3Ugd2Vu dCB0aHJvdWdoIHRoZSA2OTM3IGNhc2UgaW4gZGV0YWlsLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtZZXMsIGJ1dCB3aXRob3V0IGNvcnJlY3QgQ0Mg YWN0aW9ucy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyBJZiA1NjgxLCBpdCdzIHByZXR0eSBjbGVhciB0byBtZSB0aGF0IGluICgxKSB0aGlz IGlzIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO25ldyBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGRldGVjdGlvbiBhZnRlciBh Y2tub3dsZWRnbWVudCBvZiBuZXcgZGF0YSwgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3RoZXJlZm9yZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVxdWlyZXMgYTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBz ZWNvbmQgaGFsdmluZyBvZiBjd25kLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtIbW0sIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgJnF1b3Q7dGhp cyBpcyBhIG5ldyBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRlY3Rpb24gYWZ0ZXI8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fja25v d2xlZGdtZW50IG9mIG5ldyBkYXRhJnF1b3Q7Pzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QnV0IGFueXdheSwgUkZDIDU2 ODEgZ2l2ZXMgdGhlIGdlbmVyYWwgcHJpbmNpcGxlIHRvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3JlZHVjZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3duZCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NzdGhyZXNo IHR3aWNlIGlmIGEgcmV0cmFuc21pc3Npb24gaXMgbG9zdCBidXQgSU1ITyAoYW5kPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0k8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlbGlldmUgbWFueTxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7d2hvIGhhdmUgZGVzaWduZWQgbmV3IGxvc3MgcmVjb3ZlcnkgYW5kIENDIGFsZ29yaXRo bXMgb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2ltcGxlbWVudGVkIHRoZW08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FncmVlKSB0aGF0IGl0 IGlzIGhhcmQgdG8gZ2V0IHRoaW5ncyByaWdodCBpZiBvbmx5PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25nZXN0aW9u IGNvbnRyb2w8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3ByaW5jaXBsZXMgYXJlIGF2YWlsYWJsZSBhbmQgbm8gYWxnb3Jp dGhtLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7VGhhdCdzIHdoeSBBTEwgbWVjaGFuaXNtcyB0aGF0IHdlIGhhdmUgaW5j bHVkZSBhIHF1aXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRhaWxlZCBhbGdvcml0aG08YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dpdGgg YWxsIG5lY2Vzc2FyeSB2YXJpYWJsZXMgYW5kIGFjdGlvbnMgZm9yIGxvc3M8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVjb3Zlcnk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZC9vciBDQzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cHVycG9zZXMgKGFuZCBvZnRlbiBhbHNvIHBzZXVkb2NvZGUpLiBMaWtlIHRoaXMgZG9j dW1lbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2RvZXMgZm9yIGxvc3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RldGVjdGlvbi48YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U28gdGhlIHByb2Js ZW0gaXMgdGhhdCB3ZSBkbyBub3QgaGF2ZSBhIGRldGFpbGVkIGVub3VnaDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxn b3JpdGhtIG9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtydWxlIHRoYXQgdGVsbHMgZXhhY3RseSB3aGF0IHRvIGRvIHdo ZW4gYSBsb3NzIG9mIHJleG1pdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtp czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZGV0ZWN0ZWQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFdmVuIHdvcnNlLCB0aGUgYWxnb3JpdGht cyBpbiBSRkMgNTY4MSBhbmQgUkZDIDY2NzU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cmVmZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtlcXVhdGlvbiAoNCkgb2YgUkZDIDU2 ODEgdG8gcmVkdWNlIHNzdGhyZXNoIGFuZCBjd25kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3doZW4gYTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG9zczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVxdWlyaW5nIGEgY29u Z2VzdGlvbiBjb250cm9sIGFjdGlvbiBpcyBkZXRlY3RlZDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IChjd25kID0pIHNzdGhyZXNoID0g RmxpZ2h0U2l6ZSAvIDIpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0FuZCBSRkMgNTY4MSBnaXZlcyBhIHdhcm5pbmcgbm90IHRvIGhhbHZlIGN3bmQg aW4gdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtlcXVhdGlvbiBidXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZsaWdodFNpemUuPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYXQgaXMsIHRo aXMgZXF1YXRpb24gaXMgd2hhdCBhbiBpbXBsZW1lbnRlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtpbnR1aXRpdmVseTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d291bGQgdXNlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3 aGVuIHJlYWRpbmcgdGhlIHJlbGV2YW50IFJGQ3MgYnV0IGl0IGdpdmVzIGEgd3Jvbmc8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVzdWx0PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3I8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO291dHN0YW5kaW5nIGRhdGEgd2hlbiBpbiBmYXN0IHJlY292ZXJ5ICh3aGVuIHRoZSBzZW5k ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtjb25nZXN0aW9uIGF2b2lkYW5jZSBhbmQgdGhlIGVxdWF0aW9uICg0KSBpcyB1c2Vk IHRvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2hhbHZlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtj d25kLCBpdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Z2l2ZXMgYSBjb3JyZWN0IHJlc3VsdCkuPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtNb3Jl IHByZWNpc2VseSwgZHVyaW5nIGZhc3QgcmVjb3ZlcnkgRmxpZ2h0U2l6ZSBpczxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbmZsYXRlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hlbiBuZXc8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RhdGEgaXMgc2VudCBhbmQgcmVkdWNlZCB3aGVuIHNlZ21lbnRzIGFyZSBjdW11bGF0 aXZlbHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0Fja2VkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hhdCB0aGUgb3V0Y29tZSBpcyBkZXBl bmRzIG9uIHRoZSBsb3NzIHBhdHRlcm4uIEluIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d29yc3QgY2FzZSw8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO0ZsaWdodFNpemUgaXMgc2lnbmZpY2FudGx5IGxhcmdlciB0aGFuIGluIHRoZSBiZWdp bm5pbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2Y8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Ro ZSBmYXN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtyZWNvdmVyeSB3aGVuIEZsaWdodFNpemUgd2FzIChjb3JyZWN0bHkp IHVzZWQgdG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGV0ZXJtaW5lPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt0aGUgaGFsdmVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt2YWx1ZSBmb3IgY3duZCBhbmQgc3N0aHJlc2gs IGkuZS4sIGVxdWF0aW9uICg0KSBtYXk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cmVzdWx0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KmluY3JlYXNpbmcqIGN3bmQgdXBvbiBk ZXRlY3RpbmcgYSBsb3NzIG9mIGEgcmV4bWl0dGVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWdtZW50LCBpbnN0ZWFk PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtvZiBmdXJ0aGVyIGhhbHZpbmcgaXQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0EgY2xldmVyIGltcGxlbWVudGVyIG1pZ2h0IGhh dmUgbm8gcHJvYmxlbSB0byBoYXZlIGl0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3JpZ2h0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt3aXRoIHNvbWU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoaW5raW5nIGJ1dCBJIGFt IGFmcmFpZCB0aGF0IHRoZXJlIHdpbGwgYmUgaW5jb3JyZWN0PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBsZW1lbnRh dGlvbnM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3dpdGggd2hhdCBpcyBjdXJyZW50bHkgc3BlY2lmaWVkLiBOb3QgYWxs IGltcGxlbWVudGVyczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtoYXZlPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtzcGVudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2lnbmljaWNhbnQgZnJhY3Rpb24gb2YgdGhlaXIgY2Fy ZWVyIGluIHNvbHZpbmcgVENQPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwZWN1bGlhcml0aWVzLjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEZvciAoMiksIHRoZSBS VE8gdGltZXIgaXMgc3RpbGwgb3BlcmF0aXZlIHNvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHRoZSBSVE8gcmVj b3ZlcnkgcnVsZXMgd291bGQgc3RpbGwgZm9sbG93Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJbiBzaG9ydDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4gd2l0aCBh IG5vbi1SQUNLLVRMUCBpbXBsZW1lbnRhdGlvbiB0aW1lciAoUlRPKTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhwaXJl czogY3duZD0xIE1TUyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBzbG93IHN0YXJ0IGlzIGVudGVyZWQuPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtXaGVuIHdpdGggYSBSQUNLX1RMUCBpbXBsZW1lbnRhdGlvbiB0aW1lciAoUFRPKSBleHBp cmVzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bm9ybWFsIGZhc3QgcmVjb3ZlcnkgaXMgZW50ZXJlZCAodW5sZXNzIGlt cGxlbWVudGluZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxzbyBQUlIpLiBTbyBubyBSVE8gcmVjb3ZlcnkgYXMgZXhw bGljaXRseSBzdGF0ZWQgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2Vj Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Ny40LjEuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoaXMgbWVhbnMgdGhhdCB0aGlzIGRvY3VtZW50IGV4cGxpY2l0bHkgbW9k aWZpZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3RhbmRhcmQ8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO1RDUCBjb25nZXN0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250cm9sIHdoZW4gdGhlcmUgYXJlIG5vIGFj a3MgY29taW5nIGFuZCB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JldHJhbnNtaXNzaW9uIHRpbWVyPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtleHBpcmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2Zyb206IFJUTz1TUlRUKzQqUlRUVkFSIChSVE8gdXNlZCBmb3IgYXJtaW5nIHRoZSB0aW1l cik8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEuIFJUTyB0aW1lciBleHBp cmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyLiBjd25kPTEgTVNTOyBz c3RocmVzaD1GbGlnaHRTaXplLzI7IHJleG1pdCBvbmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlZ21lbnQ8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMuIEFjayBvZiByZXhtaXQgc2VudCBpbiBz dGVwIDIgYXJyaXZlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7NC4gY3du ZCA9IGN3bmQrMSBNU1M7IHNlbmQgdHdvIHNlZ21lbnRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsuLi48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dG86Jm5ic3A7ICZuYnNwO1BUTz1taW4oMipTUlRULFJUTykgKFBSTyB1c2Vk IGZvciBhcm1pbmcgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RpbWVy KTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MS4gUFRPIHRpbWVzIGV4cGly ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIChjd25kPTEgTVNTKTsg KHJlKXhtaXQgb25lIHNlZ21lbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzMuIEFjayBvZiAocmUpeG1pdCBzZW50IGluIHNyZXAgMiBhcnJpdmVzPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs0LiBjd25kID0gc3N0aHJlc2ggPSBGbGlnaHRTaXplLzI7 IHNlbmQgTj1jd25kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWdtZW50czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGb3IgZXhhbXBsZSwgaWYgRmxpZ2h0U2l6ZSBpcyAx MDAgc2VnbWVudHMgd2hlbiB0aW1lcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhwaXJlcyw8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbmdl c3Rpb24gY29udHJvbCBpcyB0aGUgc2FtZSBpbiBzdGVwcyAxLTMsIGJ1dCBpbiBzdGVwPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZTxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Y3VycmVudCBzdGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2wgYWxsb3dzIHRyYW5zbWl0dGluZzxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWdtZW50cyw8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3doaWxlIFJBQ0stVExQIHdvdWxkIGFsbG93IGJsYXN0aW5nIDUwIHNlZ21lbnRz Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtRdWVz dGlvbiBpczogd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0byBtb2RpZnk8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3RhbmRhcmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RDUDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Y29uZ2VzdGlvbiBjb250cm9sIHRvIHVzZSBmYXN0IHJlY292ZXJ5IGluc3RlYWQgb2Ygc2xvdzxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c3RhcnQgZm9yIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2Ugd2hlcmUgdGltZW91dCBpcyBuZWVk ZWQgdG8gZGV0ZWN0IGxvc3MgYmVjYXVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt0aGVyZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXMgbm88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ZlZWRiYWNrIGFuZCBhY2sgY2xv Y2sgaXMgbG9zdD8gVGhlIGRyYWZ0IGRvZXMgbm90IGdpdmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7YW55PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtqdXN0aWZpY2F0aW9uLiBUaGlzIGNsZWFybHkg aXMgaW4gY29uZmxpY3Qgd2l0aCBpdGVtczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsoMCk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2FuZCAoMSk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luIEJDUCAxMzMgKFJGQyA1MDMz KS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RnVy dGhlcm1vcmUsIHRoZXJlIGlzIG5vIGltcGxlbWVudGF0aW9uIG5vciBleHBlcmltZW50YWw8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2V4cGVyaWVuY2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V2YWx1YXRpbmcgdGhpcyBjaGFuZ2UuIFRoZSBp bXBsZW1lbnRhdGlvbiB3aXRoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBlcmltZW50YWwgZXhwZXJpZW5jZTxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7dXNlcyBQUlIgKFJGQyA2OTM3KSB3aGljaCBpcyBhbiBFeHBlcmltZW50YWw8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3BlY2lmaWNhdGlvbjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW5j bHVkaW5nIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO25vdmVsICZxdW90O3RyaWNrJnF1b3Q7IHRoYXQgZGlyZWN0cyBQ UlIgZmFzdCByZWNvdmVyeSB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtl ZmZlY3RpdmVseTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7dXNlIHNsb3c8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YXJ0IGluIHRoaXMgY2Fz ZSBhdCBoYW5kLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgSW4gb3Ro ZXIgd29yZHMsIEkgYW0gbm90IHNlZWluZyBhIGNhc2UgdGhhdCByZXF1aXJlczxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZXc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbmdlc3Rpb248YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgY29udHJvbCBjb25jZXB0cyBleGNlcHQgYXMgZGlzY3Vzc2VkIGluIDkuMy48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VlIGFib3Zl LiBUaGUgY2hhbmdlIGluIHN0YW5kYXJkIGNvbmdlc3Rpb24gY29udHJvbCBmb3I8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OygyKS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1RoZSBkcmFmdCBpbnRlbmRzIG5vdCB0byBjaGFuZ2UgY29uZ2VzdGlv biBjb250cm9sIGJ1dDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWZmZWN0aXZlbHkgaXQ8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvZXMgd2l0 aG91dCBhbnkgb3BlcmF0aW9uYWwgZXZpZGVuY2UuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doYXQncyBhbHNvIGlzIG1pc3NpbmcgYW5kIHdvdWxk IGJlIHZlcnkgdXNlZnVsOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDstIEZvciAoMSksIGEgaGludCBmb3IgYW4gaW1wbGVtZW50ZXIgc2F5aW5nIHRo YXQgYmVjYXVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkFDSy1UTFAgaXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDth YmxlIHRvIGRldGVjdCBhIGxvc3Mgb2YgYSByZXhtaXQgdW5saWtlIGFueSBvdGhlcjxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRlY3Rpb248YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwOyAmbmJzcDthbGdvcml0aG0sIHRoZSBzZW5kZXIgTVVTVCByZWFjdCB0d2lj ZSB0byBjb25nZXN0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoYW5kIGNpdGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJz cDtSRkMgNTY4MSkuIEFuZCBjaXRlIGEgZG9jdW1lbnQgd2hlcmUgbmVjZXNzYXJ5PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvcnJlY3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FjdGlvbnM8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZuYnNwOyAmbmJzcDthcmUgZGVzY3JpYmVkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIEZvciAoMSksIGFkdmlzZSB0aGF0IGFuIGlt cGxlbWVudGVyIG5lZWRzIHRvIGtlZXA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dHJhY2s8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3doZW4gaXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDtkZXRlY3Rz IGEgbG9zcyBvZiBhIHJldHJhbnNtaXR0ZWQgc2VnbWVudC4gQ3VycmVudDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxn b3JpdGhtczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwO2luIHRoZSBkcmFmdCBkZXRlY3QgYSBsb3Nz IG9mIHJldHJhbnNtaXR0ZWQgc2VnbWVudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhhY3RseSBpbjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwO3RoZSBzYW1lIHdheSBhcyBsb3NzIG9mIGFueSBvdGhlciBzZWdtZW50LiBU aGVyZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWVtczxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 dG8gYmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDtub3RoaW5nIHRvIHRyYWNrIHdoZW4gYSByZXRy YW5zbWlzc2lvbiBvZiBhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZXRyYW5zbWl0dGVkIHNlZ21lbnQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyAmbmJzcDt0YWtlcyBwbGFjZS4gVGhlcmVmb3JlLCB0aGUgYWxnb3JpdGhtcyBzaG91 bGQgaGF2ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YWRkaXRpb25hbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwO2FjdGlv bnMgdG8gY29ycmVjdGx5IHRyYWNrIHdoZW4gc3VjaCBhIGxvc3MgaXM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGV0ZWN0ZWQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gRm9yICgxKSwgZGlzY3Vzc2lvbiBvbiBob3cgbWFu eSB0aW1lcyBhIGxvc3Mgb2YgYTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmV0cmFuc21pc3Npb248YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyAmbmJzcDtvZiB0aGUgc2FtZSBzZWdtZW50IG1heSBvY2N1ciBhbmQgYmUgZGV0ZWN0ZWQu IFNlZW1zPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt0aGF0IGl0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7bWF5IGJlIHBv c3NpYmxlIHRvIGRyb3AgYSByZXhtaXR0ZWQgc2VnbWVudCBtb3JlIHRoYW48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29u Y2UgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ZGV0ZWN0IGl0IGFsc28gc2V2ZXJhbCB0aW1l cz8mbmJzcDsgV2hhdCBhcmUgdGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbXBsaWNhdGlvbnM/PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0gSWYgcHJldmlvdXMgaXMg cG9zc2libGUsIHRoZW4gdGhlIGFsZ29yaXRobSBwb3NzaWJseTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthbHNvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7bWF5IGRldGVjdCBh IGxvc3Mgb2YgYSBuZXcgc2VnbWVudCB0aGF0IHdhcyBzZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2R1cmluZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZmFzdDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZu YnNwO3JlY292ZXJ5PyBUaGlzIGlzIGFsc28gbG9zcyBpbiB0d28gc3VjY2Vzc2l2ZSB3aW5kb3dz PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhLDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jm5ic3A7ICZuYnNwO2FuZCBjd25kIE1VU1QgYmUgbG93ZXJlZCB0d2ljZS4gVGhp cyBkaXNjdXNzaW9uIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmVjZXNzYXJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5i c3A7YWN0aW9ucyB0byB0cmFjayBpdCBhcmUgbWlzc2luZywgaWYgc3VjaCBzY2VuYXJpbyBpczxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7cG9zc2libGUuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgV2hhdCBhbSBJIG1pc3Npbmc/PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0hvcGUgdGhlIGFib3ZlIGhlbHBzLjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvTWFya2t1PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7ICZsdDtzbmlwcGluZyB0aGUgcmVzdCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR00MB0172182657354535DF24E790B6C49CY1PR00MB0172namp_-- From nobody Thu Dec 17 11:36:49 2020 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 3B5AE3A0EF6 for ; Thu, 17 Dec 2020 11:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 VXnVIruxR5DB for ; Thu, 17 Dec 2020 11:36:45 -0800 (PST) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 746803A0EE5 for ; Thu, 17 Dec 2020 11:36:44 -0800 (PST) Received: by mail-wm1-x32e.google.com with SMTP id v14so39545wml.1 for ; Thu, 17 Dec 2020 11:36:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3tXTKCEL9DQY82DzFBg0uef2sw+PcwqpNAPXv9bM1WY=; b=Z8fhngNg0hInH6baLqP+rYsD1/+MCXqDtsoTgjQNpQs5nOHdUv8S/wup+R6f580P0R 19Hhztq8rZqdYtAZpjmH7qYd2fAylddpO6YK6Dm0d2I9/wg5KCsJs2WjnUhuNyH630mo cQeGXRbYALLVJxojhHH+KA0z5xj2R3/liFoz35yeLDc12QLWGTTQLr0HaQavH4fBCVRf jNUO+qePn590h8mGPLHVBHyZ/CXrGoREsQJsQEkqaTYtMZO2XBp6S4C0lvhvAgJW0Cfx Lj+SEO1OP1kGTCWZgODpxScCqTtDBAl6NSMCIjrdZpkDkvqO3/3/heH/EbwUP20lcnU0 PKeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3tXTKCEL9DQY82DzFBg0uef2sw+PcwqpNAPXv9bM1WY=; b=m4W1gzJMhOcyM2wpMNcfuSDtEElrg299QFIe5GU+j392MPtCCPUvNzfPKF9QTGWWlF lio01t03+y7h2s0lnK+1ikAvVExQh9fP7OxrRnzkzCILN15GH3vzablpo3LU5826zLFB +cCL+Xh3ueoWvMsFCWeflPLQbC/A9BxxwEdftNer+VZNgFZWqbOvDn8WReZv4x2mDEGy l+041RH62I7yLfRqKLndev6Iu3lgcn7YiTcM7+MVs5ko6QGMwve6f3hJNzIoava0SCwa mosFa6uPEx2hWW47M9LXbRS2FLXpXistZUxrMrsfL5+AiUXa9bil1ZEez8FsPlHQr8XM Rv+g== X-Gm-Message-State: AOAM531koRh+wo/SymWj3kTGA7Dl3wv7uoUX2xR52Ig9F9dRu0xmpjb9 uH5ez/rP1u22MAo8QrIULQGe/vY6R1X+p4mArAYzfQ== X-Google-Smtp-Source: ABdhPJzBSXcO9DSDew8xYnwb6lc43hSMJbkZvKI+VygPTOsRC8ARl2Z+F8pQvfvmp4XPCe2q50VlH6Csv4Rhjk7JyVY= X-Received: by 2002:a1c:9d85:: with SMTP id g127mr887650wme.118.1608233802610; Thu, 17 Dec 2020 11:36:42 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Yuchung Cheng Date: Thu, 17 Dec 2020 11:35:59 -0800 Message-ID: To: Praveen Balasubramanian Cc: "martin.h.duke@gmail.com" , "kojo@cs.helsinki.fi" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000085976905b6ae1c2d" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 19:36:48 -0000 --00000000000085976905b6ae1c2d Content-Type: text/plain; charset="UTF-8" How about "9.3. Interaction with congestion control RACK-TLP intentionally decouples loss detection ... As mentioned in Figure 1 caption, RFC5681 mandates a principle that Loss in two successive windows of data, or the loss of a retransmission, should be taken as two indications of congestion, and therefore reacted separately. However implementation of RFC6675 pipe algorithm may not directly account for this newly detected congestion events properly. PRR [RFCxxxx] is RECOMMENDED for the specific congestion control actions taken upon the losses detected by RACK-TLP" To Makku's request for "what's the justification to enter fast recovery". Consider this example w/o RACK-TLP T0: Send 100 segments but application-limited. All are lost. T-2RTT: app writes so another 3 segments are sent. Made to the destination and triggered 3 DUPACKs T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions to burst ~50 packets with Reno In this case any ACK occured before RTO is (generally) considered clock-acked, and how I understand Van's initial design. This behavior existed decades before RACK-TLP. RACK-TLP essentially changes the "3-segments by app" to "1-segment by tcp". On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian < pravb@microsoft.com> wrote: > I agree that we should have a note in this RFC about congestion control > action upon detecting lost retransmission(s). > > > > *From:* tcpm *On Behalf Of * Martin Duke > *Sent:* Thursday, December 17, 2020 7:30 AM > *To:* Markku Kojo > *Cc:* tcpm@ietf.org Extensions ; > draft-ietf-tcpm-rack@ietf.org; Michael Tuexen ; > draft-ietf-tcpm-rack.all@ietf.org; Last Call ; > tcpm-chairs > *Subject:* [EXTERNAL] Re: [tcpm] Last Call: > (TheRACK-TLPlossdetectionalgorithmforTCP) to > Proposed Standard > > > > Hi Markku, > > > > Thanks, now I understand your objections. > > > > Martin > > > > On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo wrote: > > Hi, > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > I spent a little longer looking at the specs more carefully, and I > explained (1) > > incorrectly in my last two messages. P21..29 are not Limited Transmit > packets. > > Correct. Just normal the rule that allows sending new data during fast > recovery. > > > However, unless I'm missing something else, 6675 is clear that the > recovery period > > does not end until the cumulative ack advances, meaning that detecting > the lost > > retransmission of P1 does not trigger another MD directly. > > As I have said earlier, RFC 6675 does not repeat all congestion control > principles from RFC 5681. It definitely honors the CC principle that > requires to treat a loss of a retransmission as a new congestion > indication and another MD. I believe I am obligated to know this as a > co-author of RFC 6675. ;) > > RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the > abstract: > > " ... conforms to the spirit of the current congestion control > specification (RFC 5681 ..." > > And in the intro: > > "The algorithm specified in this document is a straightforward > SACK-based loss recovery strategy that follows the guidelines > set in [RFC5681] ..." > > I don't think there is anything unclear in this. > > RFC 6675 and all other standard congestion controls (RFC 5581 and RFC > 6582) handle a loss of a retransmission by "enforcing" RTO to detect it. > And RTO guarantees MD. RACK-TLP changes the loss detection in this case > and therefore the standard congestion control algorithms do not have > actions to handle it corrrectly. That is the point. > > BR, > > /Markku > > > Thanks for this exercise! It's refreshed my memory of these details > after working > > on slightly different QUIC algorithms a long time. > > > > On Wed, Dec 16, 2020, 18:55 Martin Duke wrote: > > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > > > (4.2) ssthresh = cwnd = (FlightSize / 2) > > > > The congestion window (cwnd) and slow start threshold > > (ssthresh) are reduced to half of FlightSize per [RFC5681]. > > Additionally, note that [RFC5681] requires that any > > segments sent as part of the Limited Transmit mechanism not > > be counted in FlightSize for the purpose of the above > > equation. > > > > IIUC the segments P21..P29 in your example were sent because of Limited > > Transmit, and so don't count. The flightsize for the purposes of (4.2) is > > therefore 20 after both losses, and the cwnd does not go up on the second > > loss. > > > > (2) > > " Even a single shot burst every time there is significant loss > > event is not acceptable, not to mention continuous aggressiveness, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn > > about." > > > > "Significant loss event" is the key phrase here. The intent of TLP/PTO > is to > > equalize the treatment of a small packet loss whether it happened in the > > middle of a burst or the end. Why should an isolated loss be treated > > differently based on its position in the burst? This is just a logical > > extension of fast retransmit, which also modified the RTO paradigm. The > > working group consensus is that this is a feature, not a bug; you're > welcome > > to feel otherwise but I suspect you're in the rough here. > > > > Regards > > Martin > > > > > > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote: > > Hi Martin, > > > > See inline. > > > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > > > Hi Markku, > > > > > > There is a ton here, but I'll try to address the top points. > > Hopefully > > > they obviate the rest. > > > > Sorry for being verbose. I tried to be clear but you actually > > removed my > > key issues/questions ;) > > > > > 1. > > > [Markku] > > > "Hmm, not sure what you mean by "this is a new loss detection > > after > > > acknowledgment of new data"? > > > But anyway, RFC 5681 gives the general principle to reduce > > cwnd and > > > ssthresh twice if a retransmission is lost but IMHO (and I > > believe many > > > who have designed new loss recovery and CC algorithms or > > implemented > > > them > > > agree) that it is hard to get things right if only congestion > > control > > > principles are available and no algorithm." > > > > > > [Martin] > > > So 6675 Sec 5 is quite explicit that there is only one cwnd > > reduction > > > per fast recovery episode, which ends once new data has been > > > acknowledged. > > > > To be more precise: fast recovery ends when the current window > > becomes > > cumulatively acknowledged, that is, > > > > (4.1) RecoveryPoint (= HighData at the beginning) becomes > > acknowledged > > > > I believe we agree and you meant this although new data below > > RecoveryPoint may become cumulatively acknowledged already > > earlier > > during the fast recovery. Reno loss recovery in RFC 5681 ends, > > when > > (any) new data has been acknowledged. > > > > > By definition, if a retransmission is lost it is because > > > newer data has been acknowledged, so it's a new recovery > > episode. > > > > Not sure where you have this definition? Newer than what are you > > referring to? > > > > But, yes, if a retransmission is lost with RFC 6675 algorithm, > > it requires RTO to be detected and definitely starts a new > > recovery > > episode. That is, a new recovery episode is enforced by step > > (1.a) of > > NextSeg () which prevents retransmission if a segment that has > > already > > been retransmitted. If RACK-TLP is used for detecting loss with > > RFC 6675 > > things get different in many ways, because it may detect loss of > > a > > retransmission. It would pretty much require an entire redesign > > of the algorith. For example, calculation of pipe does not > > consider > > segments that have been retransmitted more than once. > > > > > Meanwhile, during the Fast Recovery period the incoming acks > > implicitly > > > remove data from the network and therefore keep flightsize > > low. > > > > Incorrect. FlightSize != pipe. Only cumulative acks remove data > > from > > FlightSize and new data transmitted during fast recovery inflate > > FlightSize. How FlightSize evolves depends on loss pattern as I > > said. > > It is also possible that FlightSize is low, it may err in both > > directions. A simple example can be used as a proof for the case > > where > > cwnd increases if a loss of retransmission is detected and > > repaired: > > > > RFC 6675 recovery with RACK-TLP loss detection: > > (contains some inaccuracies because it has not been defined how > > lost rexmits are calculated into pipe) > > > > cwnd=20; packets P1,...,P20 in flight = current window of data > > [P1 dropped and rexmit of P1 will also be dropped] > > > > DupAck w/SACK for P2 arrives > > [loss of P1 detected after one RTT from original xmit of P1] > > [cwnd=ssthresh=10] > > P1 is rexmitted (and it logically starts next window of data) > > > > DupAcks w/ SACK for original P3..11 arrive > > DupAck w/ SACK for original P12 arrives > > [cwnd-pipe = 10-9 >=1] > > send P21 > > DupAck w/SACK for P13 arrives > > send P22 > > ... > > DupAck w/SACK for P20 arrives > > send P29 > > [FlightSize=29] > > > > (Ack for rexmit of P1 would arrive here unless it got dropped) > > > > DupAck w/SACK for P21 arrives > > [loss of rexmit P1 detected after one RTT from rexmit of P1] > > > > SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 > > > > CWND INCREASES when it should be at most 5 after halving it > > twice!!! > > > > > We can continue to go around on our interpretation of these > > documents, > > > but fundamentally if there is ambiguity in 5681/6675 we should > > bis > > > those RFCs rather than expand the scope of RACK. > > > > As I said earlier, I am not opposing bis, though 5681bis wuold > > not > > be needed, I think. > > > > But let me repeat: if we publish RACK-TLP now without necessary > > warnings > > or with a correct congesion control algorithm someone will try > > to > > implement RACK-TLP with RFC 6675 and it will be a total mesh. > > The > > behavior will be unpredictable and quite likely unsafe > > congestion > > control behavior. > > > > > 2. > > > [Markku] > > > " In short: > > > When with a non-RACK-TLP implementation timer (RTO) expires: > > cwnd=1 > > > MSS, > > > and slow start is entered. > > > When with a RACK_TLP implementation timer (PTO) expires, > > > normal fast recovery is entered (unless implementing > > > also PRR). So no RTO recovery as explicitly stated in Sec. > > 7.4.1." > > > > > > [Martin] > > > There may be a misunderstanding here. PTO is not the same as > > RTO, and > > > both mechanisms exist! The loss response to a PTO is to send a > > probe; > > > the RTO response is as with conventional TCP. In Section 7.3: > > > > No, I don't think I misunderstood. If you call timeout with > > another name, it is still timeout. And congestion control does > > not > > consider which segments to send (SND.UNA vs. probe w/ higher > > sequence > > number), only how much is sent. > > > > You ignored my major point where I decoupled congestion control > > from loss > > detection and loss recovery and compared RFC 5681 behavior to > > RACK-TLP > > behavior in exactly the same scenario where an entire flight is > > lost and > > timer expires. > > > > Please comment why congestion control behavior is allowed to be > > radically > > different in these two implementations? > > > > RFC 5681 & RFC 6298 timeout: > > > > RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > > 1. RTO timer expires > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment > > 3. Ack of rexmit sent in step 2 arrives > > 4. cwnd = cwnd+1 MSS; send two segments > > ... > > > > RACK-TLP timeout: > > > > PTO=min(2*SRTT,RTO) (PTO used for arming the timer) > > 1. PTO times expires > > 2. (cwnd=1 MSS); (re)xmit one segment > > 3. Ack of (re)xmit sent in srep 2 arrives > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments > > > > If FlightSize is 100 segments when timer expires, congestion > > control is > > the same in steps 1-3, but in step 4 the standard congestion > > control > > allows transmitting 2 segments, while RACK-TLP would allow > > blasting 50 segments. > > > > > After attempting to send a loss probe, regardless of whether a > > loss > > > probe was sent, the sender MUST re-arm the RTO timer, not > > the PTO > > > timer, if FlightSize is not zero. This ensures RTO > > recovery remains > > > the last resort if TLP fails. > > > " > > > > This does not prevent the above RACK-TLP behavior from getting > > realized. > > > > > So a pure RTO response exists in the case of persistent > > congestion that > > > causes losses of probes or their ACKs. > > > > Yes, RTO response exists BUT only after RACK-TLP at least once > > blasts the > > network. It may well be that with smaller windows RACK-TLP is > > successful > > during its TLP initiated overly aggressive "fast recovery" and > > never > > enters RTO recovery because it may detect and repair also loss > > of > > rexmits. That is, it continues at too high rate even if lost > > rexmits > > indicate that congestion persists in successive windows of data. > > And > > worse, it is successful because it pushes away other compatible > > TCP > > flows by being too aggressive and unfair. > > > > Even a single shot burst every time there is significant loss > > event is not acceptable, not to mention continuous > > aggressiveness, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address > > and warn > > about. > > > > Are we ignoring these BCPs that have IETF consensus? > > > > And the other important question I'd like to have an answer: > > > > What is the justification to modify standard TCP congestion > > control to > > use fast recovery instead of slow start for a case where timeout > > is > > needed to detect the packet losses because there is no feedback > > and ack > > clock is lost? RACK-TLP explicitly instructs to do so in Sec. > > 7.4.1. > > > > As I noted: based on what is written in the draft it does not > > intend to > > change congestion control but effectively it does. > > > > /Markku > > > > > Martin > > > > > > > > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > > > > > wrote: > > > Hi Martin, > > > > > > On Tue, 15 Dec 2020, Martin Duke wrote: > > > > > > > Hi Markku, > > > > > > > > Thanks for the comments. The authors will incorporate > > > many of your > > > > suggestions after the IESG review. > > > > > > > > There's one thing I don't understand in your comments: > > > > > > > > " That is, > > > > where can an implementer find advice for correct > > > congestion control > > > > actions with RACK-TLP, when: > > > > > > > > (1) a loss of rexmitted segment is detected > > > > (2) an entire flight of data gets dropped (and > > detected), > > > > that is, when there is no feedback available and > > a > > > timeout > > > > is needed to detect the loss " > > > > > > > > Section 9.3 is the discussion about CC, and is clear > > that > > > the > > > > implementer should use either 5681 or 6937. > > > > > > Just a cite nit: RFC 5681 provides basic CC concepts and > > > some useful CC > > > guidelines but given that RACK-TLP MUST implement SACK > > the > > > algorithm in > > > RFC 5681 is not that useful and an implementer quite > > likely > > > follows > > > mainly the algorithm in RFC 6675 (and not RFC 6937 at > > all > > > if not > > > implementing PRR). > > > And RFC 6675 is not mentioned in Sec 9.3, though it is > > > listed in the > > > Sec. 4 (Requirements). > > > > > > > You went through the 6937 case in detail. > > > > > > Yes, but without correct CC actions. > > > > > > > If 5681, it's pretty clear to me that in (1) this is a > > > new loss > > > > detection after acknowledgment of new data, and > > therefore > > > requires a > > > > second halving of cwnd. > > > > > > Hmm, not sure what you mean by "this is a new loss > > > detection after > > > acknowledgment of new data"? > > > But anyway, RFC 5681 gives the general principle to > > reduce > > > cwnd and > > > ssthresh twice if a retransmission is lost but IMHO (and > > I > > > believe many > > > who have designed new loss recovery and CC algorithms or > > > implemented them > > > agree) that it is hard to get things right if only > > > congestion control > > > principles are available and no algorithm. > > > That's why ALL mechanisms that we have include a quite > > > detailed algorithm > > > with all necessary variables and actions for loss > > recovery > > > and/or CC > > > purposes (and often also pseudocode). Like this document > > > does for loss > > > detection. > > > > > > So the problem is that we do not have a detailed enough > > > algorithm or > > > rule that tells exactly what to do when a loss of rexmit > > is > > > detected. > > > Even worse, the algorithms in RFC 5681 and RFC 6675 > > refer > > > to > > > equation (4) of RFC 5681 to reduce ssthresh and cwnd > > when a > > > loss > > > requiring a congestion control action is detected: > > > > > > (cwnd =) ssthresh = FlightSize / 2) > > > > > > And RFC 5681 gives a warning not to halve cwnd in the > > > equation but > > > FlightSize. > > > > > > That is, this equation is what an implementer > > intuitively > > > would use > > > when reading the relevant RFCs but it gives a wrong > > result > > > for > > > outstanding data when in fast recovery (when the sender > > is > > > in > > > congestion avoidance and the equation (4) is used to > > halve > > > cwnd, it > > > gives a correct result). > > > More precisely, during fast recovery FlightSize is > > inflated > > > when new > > > data is sent and reduced when segments are cumulatively > > > Acked. > > > What the outcome is depends on the loss pattern. In the > > > worst case, > > > FlightSize is signficantly larger than in the beginning > > of > > > the fast > > > recovery when FlightSize was (correctly) used to > > determine > > > the halved > > > value for cwnd and ssthresh, i.e., equation (4) may > > result > > > in > > > *increasing* cwnd upon detecting a loss of a rexmitted > > > segment, instead > > > of further halving it. > > > > > > A clever implementer might have no problem to have it > > right > > > with some > > > thinking but I am afraid that there will be incorrect > > > implementations > > > with what is currently specified. Not all implementers > > have > > > spent > > > signicicant fraction of their career in solving TCP > > > peculiarities. > > > > > > > For (2), the RTO timer is still operative so > > > > the RTO recovery rules would still follow. > > > > > > In short: > > > When with a non-RACK-TLP implementation timer (RTO) > > > expires: cwnd=1 MSS, > > > and slow start is entered. > > > When with a RACK_TLP implementation timer (PTO) expires, > > > normal fast recovery is entered (unless implementing > > > also PRR). So no RTO recovery as explicitly stated in > > Sec. > > > 7.4.1. > > > > > > This means that this document explicitly modifies > > standard > > > TCP congestion > > > control when there are no acks coming and the > > > retransmission timer > > > expires > > > > > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > > > 1. RTO timer expires > > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one > > > segment > > > 3. Ack of rexmit sent in step 2 arrives > > > 4. cwnd = cwnd+1 MSS; send two segments > > > ... > > > > > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the > > timer) > > > 1. PTO times expires > > > 2. (cwnd=1 MSS); (re)xmit one segment > > > 3. Ack of (re)xmit sent in srep 2 arrives > > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd > > > segments > > > > > > For example, if FlightSize is 100 segments when timer > > > expires, > > > congestion control is the same in steps 1-3, but in step > > 4 > > > the > > > current standard congestion control allows transmitting > > 2 > > > segments, > > > while RACK-TLP would allow blasting 50 segments. > > > > > > Question is: what is the justification to modify > > standard > > > TCP > > > congestion control to use fast recovery instead of slow > > > start for a > > > case where timeout is needed to detect loss because > > there > > > is no > > > feedback and ack clock is lost? The draft does not give > > any > > > justification. This clearly is in conflict with items > > (0) > > > and (1) > > > in BCP 133 (RFC 5033). > > > > > > Furthermore, there is no implementation nor experimental > > > experience > > > evaluating this change. The implementation with > > > experimental experience > > > uses PRR (RFC 6937) which is an Experimental > > specification > > > including a > > > novel "trick" that directs PRR fast recovery to > > effectively > > > use slow > > > start in this case at hand. > > > > > > > > > > In other words, I am not seeing a case that requires > > new > > > congestion > > > > control concepts except as discussed in 9.3. > > > > > > See above. The change in standard congestion control for > > > (2). > > > The draft intends not to change congestion control but > > > effectively it > > > does without any operational evidence. > > > > > > What's also is missing and would be very useful: > > > > > > - For (1), a hint for an implementer saying that because > > > RACK-TLP is > > > able to detect a loss of a rexmit unlike any other > > loss > > > detection > > > algorithm, the sender MUST react twice to congestion > > > (and cite > > > RFC 5681). And cite a document where necessary > > correct > > > actions > > > are described. > > > > > > - For (1), advise that an implementer needs to keep > > track > > > when it > > > detects a loss of a retransmitted segment. Current > > > algorithms > > > in the draft detect a loss of retransmitted segment > > > exactly in > > > the same way as loss of any other segment. There > > seems > > > to be > > > nothing to track when a retransmission of a > > > retransmitted segment > > > takes place. Therefore, the algorithms should have > > > additional > > > actions to correctly track when such a loss is > > detected. > > > > > > - For (1), discussion on how many times a loss of a > > > retransmission > > > of the same segment may occur and be detected. Seems > > > that it > > > may be possible to drop a rexmitted segment more than > > > once and > > > detect it also several times? What are the > > > implications? > > > > > > - If previous is possible, then the algorithm possibly > > also > > > may detect a loss of a new segment that was sent > > during > > > fast > > > recovery? This is also loss in two successive windows > > of > > > data, > > > and cwnd MUST be lowered twice. This discussion and > > > necessary > > > actions to track it are missing, if such scenario is > > > possible. > > > > > > > What am I missing? > > > > > > Hope the above helps. > > > > > > /Markku > > > > > > > > > > > > > > > > > > > > > > > --00000000000085976905b6ae1c2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How about
=C2=A0
"9.3.=C2=A0= Interaction with congestion control

RACK-TLP intentionally decoup= les loss detection ...=C2=A0
As mentioned in Figure 1 caption, RFC5681 m= andates a principle that
Loss in two successive windows of data, or the loss of a
r= etransmission, should be taken as two indications of congestion, and
the= refore reacted separately. However implementation of RFC6675 pipe
algori= thm may not directly account for this newly detected congestion
events p= roperly. PRR [RFCxxxx] is RECOMMENDED for the specific
congestion contr= ol actions taken upon the losses detected by RACK-TLP"


To Makku's request for "what's the jus= tification to enter fast recovery". Consider this example w/o RACK-TLP=

T0: Send 100 segments but application-limited. Al= l are lost.
T-2RTT: app writes so another 3 segments are sent. Ma= de to the destination and triggered 3 DUPACKs
T-3RTT: 3 DUPACK ar= rives. start fast recovery and subsequent cc reactions to burst ~50 packets= with Reno=C2=A0

In this case any ACK occured befo= re RTO is (generally) considered clock-acked, and how=C2=A0I understand Van= 's initial design.=C2=A0 This behavior existed decades before RACK-TLP.= RACK-TLP essentially changes the "3-segments by app" to "1-= segment by tcp".=C2=A0

On Thu, Dec 17, 2020 at 10:52 AM Praveen Ba= lasubramanian <pravb@microsoft.co= m> wrote:

I agree that we should have a note in this RFC about= congestion control action upon detecting lost retransmission(s).=

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Martin Duke
Sent: Thursday, December 17, 2020 7:30 AM
To: Markku Kojo <kojo@cs.helsinki.fi>
Cc: tcpm@ietf.org= Extensions <tcpm= @ietf.org>; draft-ietf-tcpm-rack@ietf.org; Michael Tuexen <tuexen@fh-muenster.de>; draft-ietf-tcpm-rack.all@ietf.org; Last Call <last-call@ietf.org>; tcpm-chai= rs <tcpm-chair= s@ietf.org>
Subject: [EXTERNAL] Re: [tcpm] Last Call: <draft-ietf-tcpm-rack-1= 3.txt>(TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard<= /u>

=C2=A0

Hi Markku,

=C2=A0

Thanks, now I understand your objections.<= /u>

=C2=A0

Martin

=C2=A0

On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:

Hi,

On Wed, 16 Dec 2020, Martin Duke wrote:

> I spent a little longer looking at the specs more carefully, and I exp= lained (1)
> incorrectly in my last two messages. P21..29 are not Limited Transmit = packets.=C2=A0

Correct. Just normal the rule that allows sending new data during fast
recovery.

> However, unless I'm missing something else, 6675 is clear that the= recovery period
> does not end until the cumulative ack advances, meaning that detecting= the lost
> retransmission of P1 does not trigger another MD directly.

As I have said earlier, RFC 6675 does not repeat all congestion control principles from RFC 5681. It definitely honors the CC principle that
requires to treat a loss of a retransmission as a new congestion
indication and another MD. I believe I am obligated to know this as a
co-author of RFC 6675. ;)

RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the abstract:

" ... conforms to the spirit of the current congestion control
=C2=A0 specification (RFC 5681 ..."

And in the intro:

=C2=A0 =C2=A0"The algorithm specified in this document is a straightfo= rward
=C2=A0 =C2=A0 SACK-based loss recovery strategy that follows the=C2=A0 guid= elines
=C2=A0 =C2=A0 set in [RFC5681] ..."

I don't think there is anything unclear in this.

RFC 6675 and all other standard congestion controls (RFC 5581 and RFC
6582) handle a loss of a retransmission by "enforcing" RTO to det= ect it.
And RTO guarantees MD. RACK-TLP changes the loss detection in this case and therefore the standard congestion control algorithms do not have
actions to handle it corrrectly. That is the point.

BR,

/Markku

> Thanks for this exercise! It's refreshed my memory of these detail= s after working
> on slightly different QUIC algorithms a long time.
>
> On Wed, Dec 16, 2020, 18:55 Martin Duke <martin.h.duke@gmail.com> wrote: > (1) Flightsize: in RFC 6675. Section 5, Step 4.2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4.2) ssthresh =3D cwnd =3D (FlightSize / 2= )
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The congestion window = (cwnd) and slow start threshold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ssthresh) are reduced= to half of FlightSize per [RFC5681].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionally, note tha= t [RFC5681] requires that any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segments sent as part = of the Limited Transmit mechanism not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be counted in FlightSi= ze for the purpose of the above
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equation.
>
> IIUC the segments P21..P29 in your example were sent because of Limite= d
> Transmit, and so don't count. The flightsize for the purposes of (= 4.2) is
> therefore 20 after both losses, and the cwnd does not go up on the sec= ond
> loss.
>
> (2)
> " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and=
> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn=
> about."
>
> "Significant loss event" is the key phrase here. The intent = of TLP/PTO is to
> equalize the treatment of a small packet loss whether it happened in t= he
> middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical=
> extension of fast retransmit, which also modified the RTO paradigm. Th= e
> working group consensus is that this is a feature, not a bug; you'= re welcome
> to feel otherwise but I suspect you're in the rough here.
>
> Regards
> Martin
>
>
> On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See inline.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 16 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There is a ton here, but I'll try t= o address the top points.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> they obviate the rest.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for being verbose. I tried to be clear= but you actually
>=C2=A0 =C2=A0 =C2=A0 =C2=A0removed my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key issues/questions ;)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "Hmm, not sure what you mean by &q= uot;this is a new loss detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> But anyway, RFC 5681 gives the general = principle to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> ssthresh twice if a retransmission is l= ost but IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> who have designed new loss recovery and= CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> agree) that it is hard to get things ri= ght if only congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> principles are available and no algorit= hm."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So 6675 Sec 5 is quite explicit that th= ere is only one cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduction
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> per fast recovery episode, which ends o= nce new data has been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be more precise: fast recovery ends when = the current window
>=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cumulatively acknowledged, that is,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(4.1) RecoveryPoint (=3D HighData at the beg= inning) becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledged
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we agree and you meant this althou= gh new data below
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RecoveryPoint may become cumulatively acknow= ledged already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during the fast recovery. Reno loss recovery= in RFC 5681 ends,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(any) new data has been acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition, if a retransmission is l= ost it is because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> newer data has been acknowledged, so it= 's a new recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure where you have this definition? New= er than what are you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0referring to?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But, yes, if a retransmission is lost with R= FC 6675 algorithm,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it requires RTO to be detected and definitel= y starts a new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. That is, a new recovery episode is = enforced by step
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1.a) of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0NextSeg () which prevents retransmission if = a segment that has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0been retransmitted. If RACK-TLP is used for = detecting loss with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0things get different in many ways, because i= t may detect loss of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission. It would pretty much require= an entire redesign
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the algorith. For example, calculation of= pipe does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments that have been retransmitted more t= han once.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Meanwhile, during the Fast Recovery per= iod the incoming acks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> remove data from the network and theref= ore keep flightsize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0low.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Incorrect. FlightSize !=3D pipe. Only cumula= tive acks remove data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize and new data transmitted during f= ast recovery inflate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. How FlightSize evolves depends o= n loss pattern as I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0said.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0It is also possible that FlightSize is low, = it may err in both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0directions. A simple example can be used as = a proof for the case
>=C2=A0 =C2=A0 =C2=A0 =C2=A0where
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd increases if a loss of retransmission i= s detected and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 recovery with RACK-TLP loss detecti= on:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(contains some inaccuracies because it has n= ot been defined how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost rexmits are calculated into pipe)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D20; packets P1,...,P20 in flight =3D = current window of data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 dropped and rexmit of P1 will also be dr= opped]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of P1 detected after one RTT from orig= inal xmit of P1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd=3Dssthresh=3D10]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0P1 is rexmitted (and it logically starts nex= t window of data)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAcks w/ SACK for original P3..11 arrive >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/ SACK for original P12 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd-pipe =3D 10-9 >=3D1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P21
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P13 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P20 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[FlightSize=3D29]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Ack for rexmit of P1 would arrive here unle= ss it got dropped)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P21 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of rexmit P1 detected after one RTT fr= om rexmit of P1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SET cwnd =3D ssthresh =3D FlightSize/2=3D 29= /2 =3D 14,5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CWND INCREASES when it should be at most 5 a= fter halving it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0twice!!!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> We can continue to go around on our int= erpretation of these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0documents,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> but fundamentally if there is ambiguity= in 5681/6675 we should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> those RFCs rather than expand the scope= of RACK.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I said earlier, I am not opposing bis, th= ough 5681bis wuold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be needed, I think.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But let me repeat: if we publish RACK-TLP no= w without necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0warnings
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or with a correct congesion control algorith= m someone will try
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement RACK-TLP with RFC 6675 and it will= be a total mesh.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior will be unpredictable and quite lik= ely unsafe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control behavior.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a non-RACK-TLP implementation= timer (RTO) expires:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a RACK_TLP implementation tim= er (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> normal fast recovery is entered (unless= implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> also PRR). So no RTO recovery as explic= itly stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There may be a misunderstanding here. P= TO is not the same as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTO, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> both mechanisms exist! The loss respons= e to a PTO is to send a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0probe;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO response is as with conventiona= l TCP. In Section 7.3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0No, I don't think I misunderstood. If yo= u call timeout with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0another name, it is still timeout. And conge= stion control does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider which segments to send (SND.UNA vs.= probe w/ higher
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number), only how much is sent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You ignored my major point where I decoupled= congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection and loss recovery and compared RFC= 5681 behavior to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior in exactly the same scenario where = an entire flight is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer expires.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Please comment why congestion control behavi= or is allowed to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0radically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0different in these two implementations?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 & RFC 6298 timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTT= VAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2= *SRTT,RTO) (PTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If FlightSize is 100 segments when timer exp= ires, congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same in steps 1-3, but in step 4 the sta= ndard congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0allows transmitting 2 segments, while RACK-T= LP would allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasting 50 segments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> After attempting to send a loss probe, = regardless of whether a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 probe was sent, the sender= MUST re-arm the RTO timer, not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 timer, if FlightSize is no= t zero.=C2=A0 This ensures RTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery remains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the last resort if TLP fai= ls.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not prevent the above RACK-TLP beh= avior from getting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0realized.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So a pure RTO response exists in the ca= se of persistent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> causes losses of probes or their ACKs.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, RTO response exists BUT only after RACK= -TLP at least once
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasts the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network. It may well be that with smaller wi= ndows RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0successful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during its TLP initiated overly aggressive &= quot;fast recovery" and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enters RTO recovery because it may detect an= d repair also loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits. That is, it continues at too high r= ate even if lost
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate that congestion persists in success= ive windows of data.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worse, it is successful because it pushes aw= ay other compatible
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0flows by being too aggressive and unfair. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even a single shot burst every time there is= significant loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0event is not acceptable, not to mention cont= inuous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0aggressiveness, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this is exactly what RFC 2914 and RFC 5033 e= xplicitly address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and warn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Are we ignoring these BCPs that have IETF co= nsensus?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And the other important question I'd lik= e to have an answer:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What is the justification to modify standard= TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use fast recovery instead of slow start for = a case where timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed to detect the packet losses because t= here is no feedback
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and ack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0clock is lost? RACK-TLP explicitly instructs= to do so in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I noted: based on what is written in the = draft it does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intend to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0change congestion control but effectively it= does.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Martin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Dec 16, 2020 at 11:39 AM Markku= Kojo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<kojo@cs.helsinki.fi>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 De= c 2020, Martin Duke wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markk= u,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks f= or the comments. The authors will incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggesti= ons after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There= 9;s one thing I don't understand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " T= hat is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where ca= n an implementer find advice for correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions = with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a lo= ss of rexmitted segment is detected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an e= ntire flight of data gets dropped (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0that is, when there is no feedback available and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0is needed to detect the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section = 9.3 is the discussion about CC, and is clear
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implemen= ter should use either 5681 or 6937.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite n= it: RFC 5681 provides basic CC concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful C= C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines bu= t given that RACK-TLP MUST implement SACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is n= ot that useful and an implementer quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the al= gorithm in RFC 6675 (and not RFC 6937 at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing = PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 = is not mentioned in Sec 9.3, though it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requi= rements).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went= through the 6937 case in detail.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but with= out correct CC actions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681,= it's pretty clear to me that in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detectio= n after acknowledgment of new data, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second h= alving of cwnd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure= what you mean by "this is a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection aft= er
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgmen= t of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, R= FC 5681 gives the general principle to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twic= e if a retransmission is lost but IMHO (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have desi= gned new loss recovery and CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented t= hem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that i= t is hard to get things right if only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles ar= e available and no algorithm.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That's wh= y ALL mechanisms that we have include a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algo= rithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all nece= ssary variables and actions for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and= often also pseudocode). Like this document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the proble= m is that we do not have a detailed enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tel= ls exactly what to do when a loss of rexmit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, t= he algorithms in RFC 5681 and RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) = of RFC 5681 to reduce ssthresh and cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a c= ongestion control action is detected:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd = =3D) ssthresh =3D FlightSize / 2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 = gives a warning not to halve cwnd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this= equation is what an implementer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading = the relevant RFCs but it gives a wrong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding d= ata when in fast recovery (when the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion av= oidance and the equation (4) is used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a corre= ct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisel= y, during fast recovery FlightSize is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent = and reduced when segments are cumulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outc= ome is depends on the loss pattern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is= signficantly larger than in the beginning
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when= FlightSize was (correctly) used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwn= d and ssthresh, i.e., equation (4) may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* = cwnd upon detecting a loss of a rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, inst= ead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further ha= lving it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever impl= ementer might have no problem to have it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but = I am afraid that there will be incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementatio= ns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is = currently specified. Not all implementers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant f= raction of their career in solving TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2),= the RTO timer is still operative so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO = recovery rules would still follow.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a n= on-RACK-TLP implementation timer (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd= =3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow star= t is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a R= ACK_TLP implementation timer (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast r= ecovery is entered (unless implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So= no RTO recovery as explicitly stated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means th= at this document explicitly modifies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when = there are no acks coming and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DS= RTT+4*RTTVAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. RTO timer expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2= =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. PTO times expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, = if FlightSize is 100 segments when timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol is the same in steps 1-3, but in step
>=C2=A0 =C2=A0 =C2=A0 =C2=A04
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current stand= ard congestion control allows transmitting
>=C2=A0 =C2=A0 =C2=A0 =C2=A02
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TL= P would allow blasting 50 segments.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: = what is the justification to modify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol to use fast recovery instead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where ti= meout is needed to detect loss because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and = ack clock is lost? The draft does not give
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification= . This clearly is in conflict with items
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (R= FC 5033).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, = there is no implementation nor experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating th= is change. The implementation with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental = experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC= 6937) which is an Experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "t= rick" that directs PRR fast recovery to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this= case at hand.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other= words, I am not seeing a case that requires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control = concepts except as discussed in 9.3.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. Th= e change in standard congestion control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft int= ends not to change congestion control but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively i= t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without = any operational evidence.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's al= so is missing and would be very useful:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a = hint for an implementer saying that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= able to detect a loss of a rexmit unlike any other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= algorithm, the sender MUST react twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= RFC 5681). And cite a document where necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= are described.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), ad= vise that an implementer needs to keep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detects a loss of a retransmitted segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= in the draft detect a loss of retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= the same way as loss of any other segment. There
>=C2=A0 =C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= nothing to track when a retransmission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted= segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= takes place. Therefore, the algorithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to correctly track when such a loss is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), di= scussion on how many times a loss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= of the same segment may occur and be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may be possible to drop a rexmitted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detect it also several times?=C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous= is possible, then the algorithm possibly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may detect a loss of a new segment that was sent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= recovery? This is also loss in two successive windows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= and cwnd MUST be lowered twice. This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to track it are missing, if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am = I missing?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the abov= e helps.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <snipping the rest>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>
>

--00000000000085976905b6ae1c2d-- From nobody Thu Dec 17 13:59:21 2020 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 0CAB53A00D3; Thu, 17 Dec 2020 13:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 AxW3H9oEod61; Thu, 17 Dec 2020 13:59:10 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 49DCA3A00D8; Thu, 17 Dec 2020 13:59:10 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id w12so299278ilm.12; Thu, 17 Dec 2020 13:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xbsP3NtwW/x96BSHg3gsd2YMvcxMXbfHDbg1JnPeVAc=; b=Xlv8pJPy0w9/JfSpIPgHYwjswb7GShzKyWvDp13iwqxBR4yRow0jh5NPsSIbbwQksx +jCfRuHpVcn3EMvz1Ji8OXiAOC1wLOXBSw6IyUcin1i9o/hPleyd518uhHjPo3eu03wM 3/gogVieLQAFhRtbzaWXy2t6LX+g3bT1fKnQT9sPuPetEvg8f8HdIUW0WCCuTwskwUuq YG7i3Z36rzHtx8KL8gHgnIxa6VM7jpPopa8dLIBQQs6pKp95h9QKyRZqagZtf+IMbbzI 0zc0civQVySXWPVcczBlhceRNS2ZsqIsswWamkATWiGuGeunecdcExJMgvpHHrSLxr8c yfiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xbsP3NtwW/x96BSHg3gsd2YMvcxMXbfHDbg1JnPeVAc=; b=gBwPanms/q9QDK6BHXiT+2DogXfx8Biv/JySm0F4F2t9zy7QHUD5fuGc1efUiMNZqE ts9UksVlQaYl7PsmEZ8Tbs+EOYNArroQ0XPu8oFnGiQBqX1i6Jw3ssIabCiMDryZvtf2 Gs60L8XYbgavK2tCual+lJHK4FX7s2r9DCk6e0wvcgxb6CyFDtZARncfEgLwVLQ4aWDE eqMGVe927iWM7BmmGzOgy+P9ZjRzd95QvwBJK1UuBzLYd6N4KRZG7uhnWAFPR2NtkFVB Kyd5UK7JTFbrPwxGD9kfmVxi4Zh1UavA0E7YP3dFbRYAS0r+nbN6zpjUADfYQWKUohKw 5qkA== X-Gm-Message-State: AOAM530mcrucEvHY0VL9Q9GJ9iz+c7RVbQYGCkVf0fEBQp1IEutn7HKz GDAavQvrBdF1WddXIzYBYap+LSucDJydGHJqeSY= X-Google-Smtp-Source: ABdhPJyVga0vC40PWttYnlteecKyl1uvsEU8R58H19KE78sOIETkvfRcQher2NUXMRyJE/DnK6c6BSIAm2MN3BlINmw= X-Received: by 2002:a92:d44f:: with SMTP id r15mr964609ilm.237.1608242349378; Thu, 17 Dec 2020 13:59:09 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Thu, 17 Dec 2020 13:58:59 -0800 Message-ID: To: Yuchung Cheng Cc: Praveen Balasubramanian , "kojo@cs.helsinki.fi" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f291f305b6b019e8" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 21:59:15 -0000 --000000000000f291f305b6b019e8 Content-Type: text/plain; charset="UTF-8" This is good, thanks. I might also add the sentence "In the absence of PRR, when TCP RACK detects a lost retransmission it MUST trigger a second congestion response" or something to that effect. What do you think? On Thu, Dec 17, 2020 at 11:36 AM Yuchung Cheng wrote: > How about > > "9.3. Interaction with congestion control > > RACK-TLP intentionally decouples loss detection ... > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. PRR [RFCxxxx] is RECOMMENDED for the specific > congestion control actions taken upon the losses detected by RACK-TLP" > > > To Makku's request for "what's the justification to enter fast recovery". > Consider this example w/o RACK-TLP > > T0: Send 100 segments but application-limited. All are lost. > T-2RTT: app writes so another 3 segments are sent. Made to the destination > and triggered 3 DUPACKs > T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions > to burst ~50 packets with Reno > > In this case any ACK occured before RTO is (generally) considered > clock-acked, and how I understand Van's initial design. This behavior > existed decades before RACK-TLP. RACK-TLP essentially changes the > "3-segments by app" to "1-segment by tcp". > > On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > >> I agree that we should have a note in this RFC about congestion control >> action upon detecting lost retransmission(s). >> >> >> >> *From:* tcpm *On Behalf Of * Martin Duke >> *Sent:* Thursday, December 17, 2020 7:30 AM >> *To:* Markku Kojo >> *Cc:* tcpm@ietf.org Extensions ; >> draft-ietf-tcpm-rack@ietf.org; Michael Tuexen ; >> draft-ietf-tcpm-rack.all@ietf.org; Last Call ; >> tcpm-chairs >> *Subject:* [EXTERNAL] Re: [tcpm] Last Call: >> (TheRACK-TLPlossdetectionalgorithmforTCP) to >> Proposed Standard >> >> >> >> Hi Markku, >> >> >> >> Thanks, now I understand your objections. >> >> >> >> Martin >> >> >> >> On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo wrote: >> >> Hi, >> >> On Wed, 16 Dec 2020, Martin Duke wrote: >> >> > I spent a little longer looking at the specs more carefully, and I >> explained (1) >> > incorrectly in my last two messages. P21..29 are not Limited Transmit >> packets. >> >> Correct. Just normal the rule that allows sending new data during fast >> recovery. >> >> > However, unless I'm missing something else, 6675 is clear that the >> recovery period >> > does not end until the cumulative ack advances, meaning that detecting >> the lost >> > retransmission of P1 does not trigger another MD directly. >> >> As I have said earlier, RFC 6675 does not repeat all congestion control >> principles from RFC 5681. It definitely honors the CC principle that >> requires to treat a loss of a retransmission as a new congestion >> indication and another MD. I believe I am obligated to know this as a >> co-author of RFC 6675. ;) >> >> RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the >> abstract: >> >> " ... conforms to the spirit of the current congestion control >> specification (RFC 5681 ..." >> >> And in the intro: >> >> "The algorithm specified in this document is a straightforward >> SACK-based loss recovery strategy that follows the guidelines >> set in [RFC5681] ..." >> >> I don't think there is anything unclear in this. >> >> RFC 6675 and all other standard congestion controls (RFC 5581 and RFC >> 6582) handle a loss of a retransmission by "enforcing" RTO to detect it. >> And RTO guarantees MD. RACK-TLP changes the loss detection in this case >> and therefore the standard congestion control algorithms do not have >> actions to handle it corrrectly. That is the point. >> >> BR, >> >> /Markku >> >> > Thanks for this exercise! It's refreshed my memory of these details >> after working >> > on slightly different QUIC algorithms a long time. >> > >> > On Wed, Dec 16, 2020, 18:55 Martin Duke >> wrote: >> > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: >> > >> > (4.2) ssthresh = cwnd = (FlightSize / 2) >> > >> > The congestion window (cwnd) and slow start threshold >> > (ssthresh) are reduced to half of FlightSize per [RFC5681]. >> > Additionally, note that [RFC5681] requires that any >> > segments sent as part of the Limited Transmit mechanism not >> > be counted in FlightSize for the purpose of the above >> > equation. >> > >> > IIUC the segments P21..P29 in your example were sent because of Limited >> > Transmit, and so don't count. The flightsize for the purposes of (4.2) >> is >> > therefore 20 after both losses, and the cwnd does not go up on the >> second >> > loss. >> > >> > (2) >> > " Even a single shot burst every time there is significant loss >> > event is not acceptable, not to mention continuous aggressiveness, and >> > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn >> > about." >> > >> > "Significant loss event" is the key phrase here. The intent of TLP/PTO >> is to >> > equalize the treatment of a small packet loss whether it happened in the >> > middle of a burst or the end. Why should an isolated loss be treated >> > differently based on its position in the burst? This is just a logical >> > extension of fast retransmit, which also modified the RTO paradigm. The >> > working group consensus is that this is a feature, not a bug; you're >> welcome >> > to feel otherwise but I suspect you're in the rough here. >> > >> > Regards >> > Martin >> > >> > >> > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo >> wrote: >> > Hi Martin, >> > >> > See inline. >> > >> > On Wed, 16 Dec 2020, Martin Duke wrote: >> > >> > > Hi Markku, >> > > >> > > There is a ton here, but I'll try to address the top points. >> > Hopefully >> > > they obviate the rest. >> > >> > Sorry for being verbose. I tried to be clear but you actually >> > removed my >> > key issues/questions ;) >> > >> > > 1. >> > > [Markku] >> > > "Hmm, not sure what you mean by "this is a new loss detection >> > after >> > > acknowledgment of new data"? >> > > But anyway, RFC 5681 gives the general principle to reduce >> > cwnd and >> > > ssthresh twice if a retransmission is lost but IMHO (and I >> > believe many >> > > who have designed new loss recovery and CC algorithms or >> > implemented >> > > them >> > > agree) that it is hard to get things right if only congestion >> > control >> > > principles are available and no algorithm." >> > > >> > > [Martin] >> > > So 6675 Sec 5 is quite explicit that there is only one cwnd >> > reduction >> > > per fast recovery episode, which ends once new data has been >> > > acknowledged. >> > >> > To be more precise: fast recovery ends when the current window >> > becomes >> > cumulatively acknowledged, that is, >> > >> > (4.1) RecoveryPoint (= HighData at the beginning) becomes >> > acknowledged >> > >> > I believe we agree and you meant this although new data below >> > RecoveryPoint may become cumulatively acknowledged already >> > earlier >> > during the fast recovery. Reno loss recovery in RFC 5681 ends, >> > when >> > (any) new data has been acknowledged. >> > >> > > By definition, if a retransmission is lost it is because >> > > newer data has been acknowledged, so it's a new recovery >> > episode. >> > >> > Not sure where you have this definition? Newer than what are you >> > referring to? >> > >> > But, yes, if a retransmission is lost with RFC 6675 algorithm, >> > it requires RTO to be detected and definitely starts a new >> > recovery >> > episode. That is, a new recovery episode is enforced by step >> > (1.a) of >> > NextSeg () which prevents retransmission if a segment that has >> > already >> > been retransmitted. If RACK-TLP is used for detecting loss with >> > RFC 6675 >> > things get different in many ways, because it may detect loss of >> > a >> > retransmission. It would pretty much require an entire redesign >> > of the algorith. For example, calculation of pipe does not >> > consider >> > segments that have been retransmitted more than once. >> > >> > > Meanwhile, during the Fast Recovery period the incoming acks >> > implicitly >> > > remove data from the network and therefore keep flightsize >> > low. >> > >> > Incorrect. FlightSize != pipe. Only cumulative acks remove data >> > from >> > FlightSize and new data transmitted during fast recovery inflate >> > FlightSize. How FlightSize evolves depends on loss pattern as I >> > said. >> > It is also possible that FlightSize is low, it may err in both >> > directions. A simple example can be used as a proof for the case >> > where >> > cwnd increases if a loss of retransmission is detected and >> > repaired: >> > >> > RFC 6675 recovery with RACK-TLP loss detection: >> > (contains some inaccuracies because it has not been defined how >> > lost rexmits are calculated into pipe) >> > >> > cwnd=20; packets P1,...,P20 in flight = current window of data >> > [P1 dropped and rexmit of P1 will also be dropped] >> > >> > DupAck w/SACK for P2 arrives >> > [loss of P1 detected after one RTT from original xmit of P1] >> > [cwnd=ssthresh=10] >> > P1 is rexmitted (and it logically starts next window of data) >> > >> > DupAcks w/ SACK for original P3..11 arrive >> > DupAck w/ SACK for original P12 arrives >> > [cwnd-pipe = 10-9 >=1] >> > send P21 >> > DupAck w/SACK for P13 arrives >> > send P22 >> > ... >> > DupAck w/SACK for P20 arrives >> > send P29 >> > [FlightSize=29] >> > >> > (Ack for rexmit of P1 would arrive here unless it got dropped) >> > >> > DupAck w/SACK for P21 arrives >> > [loss of rexmit P1 detected after one RTT from rexmit of P1] >> > >> > SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 >> > >> > CWND INCREASES when it should be at most 5 after halving it >> > twice!!! >> > >> > > We can continue to go around on our interpretation of these >> > documents, >> > > but fundamentally if there is ambiguity in 5681/6675 we should >> > bis >> > > those RFCs rather than expand the scope of RACK. >> > >> > As I said earlier, I am not opposing bis, though 5681bis wuold >> > not >> > be needed, I think. >> > >> > But let me repeat: if we publish RACK-TLP now without necessary >> > warnings >> > or with a correct congesion control algorithm someone will try >> > to >> > implement RACK-TLP with RFC 6675 and it will be a total mesh. >> > The >> > behavior will be unpredictable and quite likely unsafe >> > congestion >> > control behavior. >> > >> > > 2. >> > > [Markku] >> > > " In short: >> > > When with a non-RACK-TLP implementation timer (RTO) expires: >> > cwnd=1 >> > > MSS, >> > > and slow start is entered. >> > > When with a RACK_TLP implementation timer (PTO) expires, >> > > normal fast recovery is entered (unless implementing >> > > also PRR). So no RTO recovery as explicitly stated in Sec. >> > 7.4.1." >> > > >> > > [Martin] >> > > There may be a misunderstanding here. PTO is not the same as >> > RTO, and >> > > both mechanisms exist! The loss response to a PTO is to send a >> > probe; >> > > the RTO response is as with conventional TCP. In Section 7.3: >> > >> > No, I don't think I misunderstood. If you call timeout with >> > another name, it is still timeout. And congestion control does >> > not >> > consider which segments to send (SND.UNA vs. probe w/ higher >> > sequence >> > number), only how much is sent. >> > >> > You ignored my major point where I decoupled congestion control >> > from loss >> > detection and loss recovery and compared RFC 5681 behavior to >> > RACK-TLP >> > behavior in exactly the same scenario where an entire flight is >> > lost and >> > timer expires. >> > >> > Please comment why congestion control behavior is allowed to be >> > radically >> > different in these two implementations? >> > >> > RFC 5681 & RFC 6298 timeout: >> > >> > RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >> > 1. RTO timer expires >> > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment >> > 3. Ack of rexmit sent in step 2 arrives >> > 4. cwnd = cwnd+1 MSS; send two segments >> > ... >> > >> > RACK-TLP timeout: >> > >> > PTO=min(2*SRTT,RTO) (PTO used for arming the timer) >> > 1. PTO times expires >> > 2. (cwnd=1 MSS); (re)xmit one segment >> > 3. Ack of (re)xmit sent in srep 2 arrives >> > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments >> > >> > If FlightSize is 100 segments when timer expires, congestion >> > control is >> > the same in steps 1-3, but in step 4 the standard congestion >> > control >> > allows transmitting 2 segments, while RACK-TLP would allow >> > blasting 50 segments. >> > >> > > After attempting to send a loss probe, regardless of whether a >> > loss >> > > probe was sent, the sender MUST re-arm the RTO timer, not >> > the PTO >> > > timer, if FlightSize is not zero. This ensures RTO >> > recovery remains >> > > the last resort if TLP fails. >> > > " >> > >> > This does not prevent the above RACK-TLP behavior from getting >> > realized. >> > >> > > So a pure RTO response exists in the case of persistent >> > congestion that >> > > causes losses of probes or their ACKs. >> > >> > Yes, RTO response exists BUT only after RACK-TLP at least once >> > blasts the >> > network. It may well be that with smaller windows RACK-TLP is >> > successful >> > during its TLP initiated overly aggressive "fast recovery" and >> > never >> > enters RTO recovery because it may detect and repair also loss >> > of >> > rexmits. That is, it continues at too high rate even if lost >> > rexmits >> > indicate that congestion persists in successive windows of data. >> > And >> > worse, it is successful because it pushes away other compatible >> > TCP >> > flows by being too aggressive and unfair. >> > >> > Even a single shot burst every time there is significant loss >> > event is not acceptable, not to mention continuous >> > aggressiveness, and >> > this is exactly what RFC 2914 and RFC 5033 explicitly address >> > and warn >> > about. >> > >> > Are we ignoring these BCPs that have IETF consensus? >> > >> > And the other important question I'd like to have an answer: >> > >> > What is the justification to modify standard TCP congestion >> > control to >> > use fast recovery instead of slow start for a case where timeout >> > is >> > needed to detect the packet losses because there is no feedback >> > and ack >> > clock is lost? RACK-TLP explicitly instructs to do so in Sec. >> > 7.4.1. >> > >> > As I noted: based on what is written in the draft it does not >> > intend to >> > change congestion control but effectively it does. >> > >> > /Markku >> > >> > > Martin >> > > >> > > >> > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo >> > >> > > wrote: >> > > Hi Martin, >> > > >> > > On Tue, 15 Dec 2020, Martin Duke wrote: >> > > >> > > > Hi Markku, >> > > > >> > > > Thanks for the comments. The authors will incorporate >> > > many of your >> > > > suggestions after the IESG review. >> > > > >> > > > There's one thing I don't understand in your comments: >> > > > >> > > > " That is, >> > > > where can an implementer find advice for correct >> > > congestion control >> > > > actions with RACK-TLP, when: >> > > > >> > > > (1) a loss of rexmitted segment is detected >> > > > (2) an entire flight of data gets dropped (and >> > detected), >> > > > that is, when there is no feedback available and >> > a >> > > timeout >> > > > is needed to detect the loss " >> > > > >> > > > Section 9.3 is the discussion about CC, and is clear >> > that >> > > the >> > > > implementer should use either 5681 or 6937. >> > > >> > > Just a cite nit: RFC 5681 provides basic CC concepts and >> > > some useful CC >> > > guidelines but given that RACK-TLP MUST implement SACK >> > the >> > > algorithm in >> > > RFC 5681 is not that useful and an implementer quite >> > likely >> > > follows >> > > mainly the algorithm in RFC 6675 (and not RFC 6937 at >> > all >> > > if not >> > > implementing PRR). >> > > And RFC 6675 is not mentioned in Sec 9.3, though it is >> > > listed in the >> > > Sec. 4 (Requirements). >> > > >> > > > You went through the 6937 case in detail. >> > > >> > > Yes, but without correct CC actions. >> > > >> > > > If 5681, it's pretty clear to me that in (1) this is a >> > > new loss >> > > > detection after acknowledgment of new data, and >> > therefore >> > > requires a >> > > > second halving of cwnd. >> > > >> > > Hmm, not sure what you mean by "this is a new loss >> > > detection after >> > > acknowledgment of new data"? >> > > But anyway, RFC 5681 gives the general principle to >> > reduce >> > > cwnd and >> > > ssthresh twice if a retransmission is lost but IMHO (and >> > I >> > > believe many >> > > who have designed new loss recovery and CC algorithms or >> > > implemented them >> > > agree) that it is hard to get things right if only >> > > congestion control >> > > principles are available and no algorithm. >> > > That's why ALL mechanisms that we have include a quite >> > > detailed algorithm >> > > with all necessary variables and actions for loss >> > recovery >> > > and/or CC >> > > purposes (and often also pseudocode). Like this document >> > > does for loss >> > > detection. >> > > >> > > So the problem is that we do not have a detailed enough >> > > algorithm or >> > > rule that tells exactly what to do when a loss of rexmit >> > is >> > > detected. >> > > Even worse, the algorithms in RFC 5681 and RFC 6675 >> > refer >> > > to >> > > equation (4) of RFC 5681 to reduce ssthresh and cwnd >> > when a >> > > loss >> > > requiring a congestion control action is detected: >> > > >> > > (cwnd =) ssthresh = FlightSize / 2) >> > > >> > > And RFC 5681 gives a warning not to halve cwnd in the >> > > equation but >> > > FlightSize. >> > > >> > > That is, this equation is what an implementer >> > intuitively >> > > would use >> > > when reading the relevant RFCs but it gives a wrong >> > result >> > > for >> > > outstanding data when in fast recovery (when the sender >> > is >> > > in >> > > congestion avoidance and the equation (4) is used to >> > halve >> > > cwnd, it >> > > gives a correct result). >> > > More precisely, during fast recovery FlightSize is >> > inflated >> > > when new >> > > data is sent and reduced when segments are cumulatively >> > > Acked. >> > > What the outcome is depends on the loss pattern. In the >> > > worst case, >> > > FlightSize is signficantly larger than in the beginning >> > of >> > > the fast >> > > recovery when FlightSize was (correctly) used to >> > determine >> > > the halved >> > > value for cwnd and ssthresh, i.e., equation (4) may >> > result >> > > in >> > > *increasing* cwnd upon detecting a loss of a rexmitted >> > > segment, instead >> > > of further halving it. >> > > >> > > A clever implementer might have no problem to have it >> > right >> > > with some >> > > thinking but I am afraid that there will be incorrect >> > > implementations >> > > with what is currently specified. Not all implementers >> > have >> > > spent >> > > signicicant fraction of their career in solving TCP >> > > peculiarities. >> > > >> > > > For (2), the RTO timer is still operative so >> > > > the RTO recovery rules would still follow. >> > > >> > > In short: >> > > When with a non-RACK-TLP implementation timer (RTO) >> > > expires: cwnd=1 MSS, >> > > and slow start is entered. >> > > When with a RACK_TLP implementation timer (PTO) expires, >> > > normal fast recovery is entered (unless implementing >> > > also PRR). So no RTO recovery as explicitly stated in >> > Sec. >> > > 7.4.1. >> > > >> > > This means that this document explicitly modifies >> > standard >> > > TCP congestion >> > > control when there are no acks coming and the >> > > retransmission timer >> > > expires >> > > >> > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >> > > 1. RTO timer expires >> > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one >> > > segment >> > > 3. Ack of rexmit sent in step 2 arrives >> > > 4. cwnd = cwnd+1 MSS; send two segments >> > > ... >> > > >> > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the >> > timer) >> > > 1. PTO times expires >> > > 2. (cwnd=1 MSS); (re)xmit one segment >> > > 3. Ack of (re)xmit sent in srep 2 arrives >> > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd >> > > segments >> > > >> > > For example, if FlightSize is 100 segments when timer >> > > expires, >> > > congestion control is the same in steps 1-3, but in step >> > 4 >> > > the >> > > current standard congestion control allows transmitting >> > 2 >> > > segments, >> > > while RACK-TLP would allow blasting 50 segments. >> > > >> > > Question is: what is the justification to modify >> > standard >> > > TCP >> > > congestion control to use fast recovery instead of slow >> > > start for a >> > > case where timeout is needed to detect loss because >> > there >> > > is no >> > > feedback and ack clock is lost? The draft does not give >> > any >> > > justification. This clearly is in conflict with items >> > (0) >> > > and (1) >> > > in BCP 133 (RFC 5033). >> > > >> > > Furthermore, there is no implementation nor experimental >> > > experience >> > > evaluating this change. The implementation with >> > > experimental experience >> > > uses PRR (RFC 6937) which is an Experimental >> > specification >> > > including a >> > > novel "trick" that directs PRR fast recovery to >> > effectively >> > > use slow >> > > start in this case at hand. >> > > >> > > >> > > > In other words, I am not seeing a case that requires >> > new >> > > congestion >> > > > control concepts except as discussed in 9.3. >> > > >> > > See above. The change in standard congestion control for >> > > (2). >> > > The draft intends not to change congestion control but >> > > effectively it >> > > does without any operational evidence. >> > > >> > > What's also is missing and would be very useful: >> > > >> > > - For (1), a hint for an implementer saying that because >> > > RACK-TLP is >> > > able to detect a loss of a rexmit unlike any other >> > loss >> > > detection >> > > algorithm, the sender MUST react twice to congestion >> > > (and cite >> > > RFC 5681). And cite a document where necessary >> > correct >> > > actions >> > > are described. >> > > >> > > - For (1), advise that an implementer needs to keep >> > track >> > > when it >> > > detects a loss of a retransmitted segment. Current >> > > algorithms >> > > in the draft detect a loss of retransmitted segment >> > > exactly in >> > > the same way as loss of any other segment. There >> > seems >> > > to be >> > > nothing to track when a retransmission of a >> > > retransmitted segment >> > > takes place. Therefore, the algorithms should have >> > > additional >> > > actions to correctly track when such a loss is >> > detected. >> > > >> > > - For (1), discussion on how many times a loss of a >> > > retransmission >> > > of the same segment may occur and be detected. Seems >> > > that it >> > > may be possible to drop a rexmitted segment more than >> > > once and >> > > detect it also several times? What are the >> > > implications? >> > > >> > > - If previous is possible, then the algorithm possibly >> > also >> > > may detect a loss of a new segment that was sent >> > during >> > > fast >> > > recovery? This is also loss in two successive windows >> > of >> > > data, >> > > and cwnd MUST be lowered twice. This discussion and >> > > necessary >> > > actions to track it are missing, if such scenario is >> > > possible. >> > > >> > > > What am I missing? >> > > >> > > Hope the above helps. >> > > >> > > /Markku >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> >> --000000000000f291f305b6b019e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is good, thanks.

I might also add = the sentence "In the absence of PRR, when TCP RACK detects a lost retr= ansmission it MUST trigger a second congestion response" or something = to that effect. What do you think?

On Thu, Dec 17, 2020 at 11:36 AM Yu= chung Cheng <ycheng@google.com&= gt; wrote:
How about
=C2=A0
"9.3.=C2=A0 Inte= raction with congestion control

RACK-TLP intentionally decouples l= oss detection ...=C2=A0
As mentioned in Figure 1 caption, RFC5681 mandat= es a principle that
Loss in two succe= ssive windows of data, or the loss of a
retransmission, should be= taken as two indications of congestion, and
therefore reacted separatel= y. However implementation of RFC6675 pipe
algorithm may not directly acc= ount for this newly detected congestion
events properly. PRR [RFCxxxx] i= s RECOMMENDED for the specific
congestion control actions taken upon th= e losses detected by RACK-TLP"


= To Makku's request for "what's the justification to enter fast= recovery". Consider this example w/o RACK-TLP

T0: Send 100 segments but application-limited. All are lost.
T-= 2RTT: app writes so another 3 segments are sent. Made to the destination an= d triggered 3 DUPACKs
T-3RTT: 3 DUPACK arrives. start fast recove= ry and subsequent cc reactions to burst ~50 packets with Reno=C2=A0

In this case any ACK occured before RTO is (generally) co= nsidered clock-acked, and how=C2=A0I understand Van's initial design.= =C2=A0 This behavior existed decades before RACK-TLP. RACK-TLP essentially = changes the "3-segments by app" to "1-segment by tcp".= =C2=A0

On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian <pravb@microsoft.com> wrote:

I agree that we should have a note in this RFC about= congestion control action upon detecting lost retransmission(s).=

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Martin Duke
Sent: Thursday, December 17, 2020 7:30 AM
To: Markku Kojo <kojo@cs.helsinki.fi>
Cc: tcpm@ietf.org= Extensions <tcpm= @ietf.org>; draft-ietf-tcpm-rack@ietf.org; Michael Tuexen <tuexen@fh-muenster.de>; draft-ietf-tcpm-rack.all@ietf.org; Last Call <last-call@ietf.org>; tcpm-chai= rs <tcpm-chair= s@ietf.org>
Subject: [EXTERNAL] Re: [tcpm] Last Call: <draft-ietf-tcpm-rack-1= 3.txt>(TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard<= /u>

=C2=A0

Hi Markku,

=C2=A0

Thanks, now I understand your objections.<= /u>

=C2=A0

Martin

=C2=A0

On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:

Hi,

On Wed, 16 Dec 2020, Martin Duke wrote:

> I spent a little longer looking at the specs more carefully, and I exp= lained (1)
> incorrectly in my last two messages. P21..29 are not Limited Transmit = packets.=C2=A0

Correct. Just normal the rule that allows sending new data during fast
recovery.

> However, unless I'm missing something else, 6675 is clear that the= recovery period
> does not end until the cumulative ack advances, meaning that detecting= the lost
> retransmission of P1 does not trigger another MD directly.

As I have said earlier, RFC 6675 does not repeat all congestion control principles from RFC 5681. It definitely honors the CC principle that
requires to treat a loss of a retransmission as a new congestion
indication and another MD. I believe I am obligated to know this as a
co-author of RFC 6675. ;)

RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the abstract:

" ... conforms to the spirit of the current congestion control
=C2=A0 specification (RFC 5681 ..."

And in the intro:

=C2=A0 =C2=A0"The algorithm specified in this document is a straightfo= rward
=C2=A0 =C2=A0 SACK-based loss recovery strategy that follows the=C2=A0 guid= elines
=C2=A0 =C2=A0 set in [RFC5681] ..."

I don't think there is anything unclear in this.

RFC 6675 and all other standard congestion controls (RFC 5581 and RFC
6582) handle a loss of a retransmission by "enforcing" RTO to det= ect it.
And RTO guarantees MD. RACK-TLP changes the loss detection in this case and therefore the standard congestion control algorithms do not have
actions to handle it corrrectly. That is the point.

BR,

/Markku

> Thanks for this exercise! It's refreshed my memory of these detail= s after working
> on slightly different QUIC algorithms a long time.
>
> On Wed, Dec 16, 2020, 18:55 Martin Duke <martin.h.duke@gmail.com> wrote: > (1) Flightsize: in RFC 6675. Section 5, Step 4.2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4.2) ssthresh =3D cwnd =3D (FlightSize / 2= )
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The congestion window = (cwnd) and slow start threshold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ssthresh) are reduced= to half of FlightSize per [RFC5681].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionally, note tha= t [RFC5681] requires that any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segments sent as part = of the Limited Transmit mechanism not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be counted in FlightSi= ze for the purpose of the above
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equation.
>
> IIUC the segments P21..P29 in your example were sent because of Limite= d
> Transmit, and so don't count. The flightsize for the purposes of (= 4.2) is
> therefore 20 after both losses, and the cwnd does not go up on the sec= ond
> loss.
>
> (2)
> " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and=
> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn=
> about."
>
> "Significant loss event" is the key phrase here. The intent = of TLP/PTO is to
> equalize the treatment of a small packet loss whether it happened in t= he
> middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical=
> extension of fast retransmit, which also modified the RTO paradigm. Th= e
> working group consensus is that this is a feature, not a bug; you'= re welcome
> to feel otherwise but I suspect you're in the rough here.
>
> Regards
> Martin
>
>
> On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See inline.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 16 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There is a ton here, but I'll try t= o address the top points.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> they obviate the rest.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for being verbose. I tried to be clear= but you actually
>=C2=A0 =C2=A0 =C2=A0 =C2=A0removed my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key issues/questions ;)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "Hmm, not sure what you mean by &q= uot;this is a new loss detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> But anyway, RFC 5681 gives the general = principle to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> ssthresh twice if a retransmission is l= ost but IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> who have designed new loss recovery and= CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> agree) that it is hard to get things ri= ght if only congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> principles are available and no algorit= hm."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So 6675 Sec 5 is quite explicit that th= ere is only one cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduction
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> per fast recovery episode, which ends o= nce new data has been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be more precise: fast recovery ends when = the current window
>=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cumulatively acknowledged, that is,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(4.1) RecoveryPoint (=3D HighData at the beg= inning) becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledged
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we agree and you meant this althou= gh new data below
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RecoveryPoint may become cumulatively acknow= ledged already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during the fast recovery. Reno loss recovery= in RFC 5681 ends,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(any) new data has been acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition, if a retransmission is l= ost it is because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> newer data has been acknowledged, so it= 's a new recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure where you have this definition? New= er than what are you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0referring to?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But, yes, if a retransmission is lost with R= FC 6675 algorithm,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it requires RTO to be detected and definitel= y starts a new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. That is, a new recovery episode is = enforced by step
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1.a) of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0NextSeg () which prevents retransmission if = a segment that has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0been retransmitted. If RACK-TLP is used for = detecting loss with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0things get different in many ways, because i= t may detect loss of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission. It would pretty much require= an entire redesign
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the algorith. For example, calculation of= pipe does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments that have been retransmitted more t= han once.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Meanwhile, during the Fast Recovery per= iod the incoming acks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> remove data from the network and theref= ore keep flightsize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0low.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Incorrect. FlightSize !=3D pipe. Only cumula= tive acks remove data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize and new data transmitted during f= ast recovery inflate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. How FlightSize evolves depends o= n loss pattern as I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0said.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0It is also possible that FlightSize is low, = it may err in both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0directions. A simple example can be used as = a proof for the case
>=C2=A0 =C2=A0 =C2=A0 =C2=A0where
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd increases if a loss of retransmission i= s detected and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 recovery with RACK-TLP loss detecti= on:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(contains some inaccuracies because it has n= ot been defined how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost rexmits are calculated into pipe)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D20; packets P1,...,P20 in flight =3D = current window of data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 dropped and rexmit of P1 will also be dr= opped]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of P1 detected after one RTT from orig= inal xmit of P1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd=3Dssthresh=3D10]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0P1 is rexmitted (and it logically starts nex= t window of data)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAcks w/ SACK for original P3..11 arrive >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/ SACK for original P12 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd-pipe =3D 10-9 >=3D1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P21
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P13 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P20 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[FlightSize=3D29]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Ack for rexmit of P1 would arrive here unle= ss it got dropped)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P21 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of rexmit P1 detected after one RTT fr= om rexmit of P1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SET cwnd =3D ssthresh =3D FlightSize/2=3D 29= /2 =3D 14,5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CWND INCREASES when it should be at most 5 a= fter halving it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0twice!!!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> We can continue to go around on our int= erpretation of these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0documents,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> but fundamentally if there is ambiguity= in 5681/6675 we should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> those RFCs rather than expand the scope= of RACK.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I said earlier, I am not opposing bis, th= ough 5681bis wuold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be needed, I think.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But let me repeat: if we publish RACK-TLP no= w without necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0warnings
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or with a correct congesion control algorith= m someone will try
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement RACK-TLP with RFC 6675 and it will= be a total mesh.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior will be unpredictable and quite lik= ely unsafe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control behavior.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a non-RACK-TLP implementation= timer (RTO) expires:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a RACK_TLP implementation tim= er (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> normal fast recovery is entered (unless= implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> also PRR). So no RTO recovery as explic= itly stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There may be a misunderstanding here. P= TO is not the same as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTO, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> both mechanisms exist! The loss respons= e to a PTO is to send a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0probe;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO response is as with conventiona= l TCP. In Section 7.3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0No, I don't think I misunderstood. If yo= u call timeout with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0another name, it is still timeout. And conge= stion control does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider which segments to send (SND.UNA vs.= probe w/ higher
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number), only how much is sent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You ignored my major point where I decoupled= congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection and loss recovery and compared RFC= 5681 behavior to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior in exactly the same scenario where = an entire flight is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer expires.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Please comment why congestion control behavi= or is allowed to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0radically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0different in these two implementations?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 & RFC 6298 timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTT= VAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2= *SRTT,RTO) (PTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If FlightSize is 100 segments when timer exp= ires, congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same in steps 1-3, but in step 4 the sta= ndard congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0allows transmitting 2 segments, while RACK-T= LP would allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasting 50 segments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> After attempting to send a loss probe, = regardless of whether a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 probe was sent, the sender= MUST re-arm the RTO timer, not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 timer, if FlightSize is no= t zero.=C2=A0 This ensures RTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery remains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the last resort if TLP fai= ls.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not prevent the above RACK-TLP beh= avior from getting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0realized.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So a pure RTO response exists in the ca= se of persistent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> causes losses of probes or their ACKs.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, RTO response exists BUT only after RACK= -TLP at least once
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasts the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network. It may well be that with smaller wi= ndows RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0successful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during its TLP initiated overly aggressive &= quot;fast recovery" and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enters RTO recovery because it may detect an= d repair also loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits. That is, it continues at too high r= ate even if lost
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate that congestion persists in success= ive windows of data.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worse, it is successful because it pushes aw= ay other compatible
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0flows by being too aggressive and unfair. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even a single shot burst every time there is= significant loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0event is not acceptable, not to mention cont= inuous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0aggressiveness, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this is exactly what RFC 2914 and RFC 5033 e= xplicitly address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and warn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Are we ignoring these BCPs that have IETF co= nsensus?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And the other important question I'd lik= e to have an answer:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What is the justification to modify standard= TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use fast recovery instead of slow start for = a case where timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed to detect the packet losses because t= here is no feedback
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and ack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0clock is lost? RACK-TLP explicitly instructs= to do so in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I noted: based on what is written in the = draft it does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intend to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0change congestion control but effectively it= does.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Martin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Dec 16, 2020 at 11:39 AM Markku= Kojo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<kojo@cs.helsinki.fi>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 De= c 2020, Martin Duke wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markk= u,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks f= or the comments. The authors will incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggesti= ons after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There= 9;s one thing I don't understand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " T= hat is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where ca= n an implementer find advice for correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions = with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a lo= ss of rexmitted segment is detected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an e= ntire flight of data gets dropped (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0that is, when there is no feedback available and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0is needed to detect the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section = 9.3 is the discussion about CC, and is clear
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implemen= ter should use either 5681 or 6937.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite n= it: RFC 5681 provides basic CC concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful C= C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines bu= t given that RACK-TLP MUST implement SACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is n= ot that useful and an implementer quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the al= gorithm in RFC 6675 (and not RFC 6937 at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing = PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 = is not mentioned in Sec 9.3, though it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requi= rements).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went= through the 6937 case in detail.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but with= out correct CC actions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681,= it's pretty clear to me that in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detectio= n after acknowledgment of new data, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second h= alving of cwnd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure= what you mean by "this is a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection aft= er
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgmen= t of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, R= FC 5681 gives the general principle to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twic= e if a retransmission is lost but IMHO (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have desi= gned new loss recovery and CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented t= hem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that i= t is hard to get things right if only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles ar= e available and no algorithm.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That's wh= y ALL mechanisms that we have include a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algo= rithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all nece= ssary variables and actions for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and= often also pseudocode). Like this document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the proble= m is that we do not have a detailed enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tel= ls exactly what to do when a loss of rexmit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, t= he algorithms in RFC 5681 and RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) = of RFC 5681 to reduce ssthresh and cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a c= ongestion control action is detected:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd = =3D) ssthresh =3D FlightSize / 2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 = gives a warning not to halve cwnd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this= equation is what an implementer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading = the relevant RFCs but it gives a wrong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding d= ata when in fast recovery (when the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion av= oidance and the equation (4) is used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a corre= ct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisel= y, during fast recovery FlightSize is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent = and reduced when segments are cumulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outc= ome is depends on the loss pattern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is= signficantly larger than in the beginning
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when= FlightSize was (correctly) used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwn= d and ssthresh, i.e., equation (4) may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* = cwnd upon detecting a loss of a rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, inst= ead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further ha= lving it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever impl= ementer might have no problem to have it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but = I am afraid that there will be incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementatio= ns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is = currently specified. Not all implementers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant f= raction of their career in solving TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2),= the RTO timer is still operative so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO = recovery rules would still follow.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a n= on-RACK-TLP implementation timer (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd= =3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow star= t is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a R= ACK_TLP implementation timer (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast r= ecovery is entered (unless implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So= no RTO recovery as explicitly stated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means th= at this document explicitly modifies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when = there are no acks coming and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DS= RTT+4*RTTVAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. RTO timer expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2= =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. PTO times expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, = if FlightSize is 100 segments when timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol is the same in steps 1-3, but in step
>=C2=A0 =C2=A0 =C2=A0 =C2=A04
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current stand= ard congestion control allows transmitting
>=C2=A0 =C2=A0 =C2=A0 =C2=A02
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TL= P would allow blasting 50 segments.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: = what is the justification to modify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol to use fast recovery instead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where ti= meout is needed to detect loss because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and = ack clock is lost? The draft does not give
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification= . This clearly is in conflict with items
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (R= FC 5033).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, = there is no implementation nor experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating th= is change. The implementation with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental = experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC= 6937) which is an Experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "t= rick" that directs PRR fast recovery to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this= case at hand.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other= words, I am not seeing a case that requires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control = concepts except as discussed in 9.3.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. Th= e change in standard congestion control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft int= ends not to change congestion control but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively i= t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without = any operational evidence.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's al= so is missing and would be very useful:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a = hint for an implementer saying that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= able to detect a loss of a rexmit unlike any other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= algorithm, the sender MUST react twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= RFC 5681). And cite a document where necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= are described.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), ad= vise that an implementer needs to keep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detects a loss of a retransmitted segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= in the draft detect a loss of retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= the same way as loss of any other segment. There
>=C2=A0 =C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= nothing to track when a retransmission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted= segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= takes place. Therefore, the algorithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to correctly track when such a loss is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), di= scussion on how many times a loss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= of the same segment may occur and be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may be possible to drop a rexmitted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detect it also several times?=C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous= is possible, then the algorithm possibly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may detect a loss of a new segment that was sent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= recovery? This is also loss in two successive windows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= and cwnd MUST be lowered twice. This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to track it are missing, if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am = I missing?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the abov= e helps.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <snipping the rest>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>
>

--000000000000f291f305b6b019e8-- From nobody Thu Dec 17 14:55:48 2020 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 0E5463A0800 for ; Thu, 17 Dec 2020 14:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 VjnV9WJws_SV for ; Thu, 17 Dec 2020 14:55:43 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 D62D03A07F7 for ; Thu, 17 Dec 2020 14:55:42 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id d13so114578wrc.13 for ; Thu, 17 Dec 2020 14:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EUJ7sJUu1Q7k3yZonn7b5OurHUkI868giD5lOr/EmRg=; b=lmUjew2IdKMRZmy9DIAsBlrRPU16Z2vHx9MBVF9JwjTHjgziEeu8npgPp8cDWyTAXa YuXMPdc9//SD4oWdps9v03LmxCyfPAn/u4ifF7Qsefuyx8NdJC08rx6Z3JLQa3wCUclp LxPJXp79/KQfKfkwaj2yZ0WFY/I0kOPa8ImoqecR2lgw3kU9KjZFylQXCVrJxuVMxNDn WxeIx/nYtxrDL0/8gqBlirQZiKRP/B5fpoDJnuJJ/ASEd5uslSIQE5NKbq2R6nq+FlkW AqN2zZO4k+Vfg+AZOSNA88/qtzt1dr90FLnt0JvwO8zNt+CNF1hNlceFPngTf0uylV/1 KM6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EUJ7sJUu1Q7k3yZonn7b5OurHUkI868giD5lOr/EmRg=; b=Qg5AcFrVSggSir7XpKKLxtKZV5OblD48ACf/RcpPtFCuTPx3fnHxWqoCejQ3g7liue if8yR9bhKbOwLw8cgoCWoZ/zk9zE6wCoX/d2TNxzxionoRLb6FEGos2PiLKcoMWvpQ1q MiocJqCA+1VxdygOuA49FsRpnMI9AuiG1u+6l7bw7TUyqn75PqAy4eewQ1KkgMye1HcP 02XVGnvNAZ9j88yo6lfCfODt1NSE182XHyq4xAY5gGeyXOxMsRkt/8WqZiXMiVCugv9T uvYHwjR6LYgmYsHhjcyDbgzgY/IwC5XbbBlH3zI8yZ/97SWQx8TQCiCLCNRdc+rEJVuZ iX8g== X-Gm-Message-State: AOAM532jIa9jnfF9FVtJlMKNF2QPr8CYBzd33rxu+66Z3kJSDQY19Mj/ UTF2NLrf3Fu6oS3yATMz02q0d9DZOpYl06UIA+BWfw== X-Google-Smtp-Source: ABdhPJy15XgWJCZPCy/meQX+PFqtpYLUJtbIAwLHCbEFAAGulUWwiZsLUfY4TFg0cfHIekocZTOgQ8EhoBXssL0LC1A= X-Received: by 2002:adf:ef06:: with SMTP id e6mr1042967wro.231.1608245740620; Thu, 17 Dec 2020 14:55:40 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Yuchung Cheng Date: Thu, 17 Dec 2020 14:54:59 -0800 Message-ID: To: Martin Duke Cc: Praveen Balasubramanian , "kojo@cs.helsinki.fi" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000015383b05b6b0e42c" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 17 Dec 2020 22:55:47 -0000 --00000000000015383b05b6b0e42c Content-Type: text/plain; charset="UTF-8" On Thu, Dec 17, 2020 at 1:59 PM Martin Duke wrote: > This is good, thanks. > > I might also add the sentence "In the absence of PRR, when TCP RACK > detects a lost retransmission it MUST trigger a second congestion response" > or something to that effect. What do you think? > Sure I'd revise a bit to be even more detailed and consistent with the principle in RFC5681 "In the absence of PRR, when RACK-TLP detects a lost retransmission the congestion control MUST trigger an additional congestion response per the aforementioned principle in RFC5681. If multiple retransmissions were lost in a window, the congestion control specified in RFC5681 only reacts once per window, but some other congestion control may want to respond multiple times differently. The congestion control implementer is advised to carefully consider this subtle situation." > On Thu, Dec 17, 2020 at 11:36 AM Yuchung Cheng wrote: > >> How about >> >> "9.3. Interaction with congestion control >> >> RACK-TLP intentionally decouples loss detection ... >> As mentioned in Figure 1 caption, RFC5681 mandates a principle that >> Loss in two successive windows of data, or the loss of a >> retransmission, should be taken as two indications of congestion, and >> therefore reacted separately. However implementation of RFC6675 pipe >> algorithm may not directly account for this newly detected congestion >> events properly. PRR [RFCxxxx] is RECOMMENDED for the specific >> congestion control actions taken upon the losses detected by RACK-TLP" >> >> >> To Makku's request for "what's the justification to enter fast recovery". >> Consider this example w/o RACK-TLP >> >> T0: Send 100 segments but application-limited. All are lost. >> T-2RTT: app writes so another 3 segments are sent. Made to the >> destination and triggered 3 DUPACKs >> T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions >> to burst ~50 packets with Reno >> >> In this case any ACK occured before RTO is (generally) considered >> clock-acked, and how I understand Van's initial design. This behavior >> existed decades before RACK-TLP. RACK-TLP essentially changes the >> "3-segments by app" to "1-segment by tcp". >> >> On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian < >> pravb@microsoft.com> wrote: >> >>> I agree that we should have a note in this RFC about congestion control >>> action upon detecting lost retransmission(s). >>> >>> >>> >>> *From:* tcpm *On Behalf Of * Martin Duke >>> *Sent:* Thursday, December 17, 2020 7:30 AM >>> *To:* Markku Kojo >>> *Cc:* tcpm@ietf.org Extensions ; >>> draft-ietf-tcpm-rack@ietf.org; Michael Tuexen ; >>> draft-ietf-tcpm-rack.all@ietf.org; Last Call ; >>> tcpm-chairs >>> *Subject:* [EXTERNAL] Re: [tcpm] Last Call: >>> (TheRACK-TLPlossdetectionalgorithmforTCP) to >>> Proposed Standard >>> >>> >>> >>> Hi Markku, >>> >>> >>> >>> Thanks, now I understand your objections. >>> >>> >>> >>> Martin >>> >>> >>> >>> On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo >>> wrote: >>> >>> Hi, >>> >>> On Wed, 16 Dec 2020, Martin Duke wrote: >>> >>> > I spent a little longer looking at the specs more carefully, and I >>> explained (1) >>> > incorrectly in my last two messages. P21..29 are not Limited Transmit >>> packets. >>> >>> Correct. Just normal the rule that allows sending new data during fast >>> recovery. >>> >>> > However, unless I'm missing something else, 6675 is clear that the >>> recovery period >>> > does not end until the cumulative ack advances, meaning that detecting >>> the lost >>> > retransmission of P1 does not trigger another MD directly. >>> >>> As I have said earlier, RFC 6675 does not repeat all congestion control >>> principles from RFC 5681. It definitely honors the CC principle that >>> requires to treat a loss of a retransmission as a new congestion >>> indication and another MD. I believe I am obligated to know this as a >>> co-author of RFC 6675. ;) >>> >>> RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the >>> abstract: >>> >>> " ... conforms to the spirit of the current congestion control >>> specification (RFC 5681 ..." >>> >>> And in the intro: >>> >>> "The algorithm specified in this document is a straightforward >>> SACK-based loss recovery strategy that follows the guidelines >>> set in [RFC5681] ..." >>> >>> I don't think there is anything unclear in this. >>> >>> RFC 6675 and all other standard congestion controls (RFC 5581 and RFC >>> 6582) handle a loss of a retransmission by "enforcing" RTO to detect it. >>> And RTO guarantees MD. RACK-TLP changes the loss detection in this case >>> and therefore the standard congestion control algorithms do not have >>> actions to handle it corrrectly. That is the point. >>> >>> BR, >>> >>> /Markku >>> >>> > Thanks for this exercise! It's refreshed my memory of these details >>> after working >>> > on slightly different QUIC algorithms a long time. >>> > >>> > On Wed, Dec 16, 2020, 18:55 Martin Duke >>> wrote: >>> > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: >>> > >>> > (4.2) ssthresh = cwnd = (FlightSize / 2) >>> > >>> > The congestion window (cwnd) and slow start threshold >>> > (ssthresh) are reduced to half of FlightSize per >>> [RFC5681]. >>> > Additionally, note that [RFC5681] requires that any >>> > segments sent as part of the Limited Transmit mechanism >>> not >>> > be counted in FlightSize for the purpose of the above >>> > equation. >>> > >>> > IIUC the segments P21..P29 in your example were sent because of Limited >>> > Transmit, and so don't count. The flightsize for the purposes of (4.2) >>> is >>> > therefore 20 after both losses, and the cwnd does not go up on the >>> second >>> > loss. >>> > >>> > (2) >>> > " Even a single shot burst every time there is significant loss >>> > event is not acceptable, not to mention continuous aggressiveness, and >>> > this is exactly what RFC 2914 and RFC 5033 explicitly address and warn >>> > about." >>> > >>> > "Significant loss event" is the key phrase here. The intent of TLP/PTO >>> is to >>> > equalize the treatment of a small packet loss whether it happened in >>> the >>> > middle of a burst or the end. Why should an isolated loss be treated >>> > differently based on its position in the burst? This is just a logical >>> > extension of fast retransmit, which also modified the RTO paradigm. The >>> > working group consensus is that this is a feature, not a bug; you're >>> welcome >>> > to feel otherwise but I suspect you're in the rough here. >>> > >>> > Regards >>> > Martin >>> > >>> > >>> > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo >>> wrote: >>> > Hi Martin, >>> > >>> > See inline. >>> > >>> > On Wed, 16 Dec 2020, Martin Duke wrote: >>> > >>> > > Hi Markku, >>> > > >>> > > There is a ton here, but I'll try to address the top points. >>> > Hopefully >>> > > they obviate the rest. >>> > >>> > Sorry for being verbose. I tried to be clear but you actually >>> > removed my >>> > key issues/questions ;) >>> > >>> > > 1. >>> > > [Markku] >>> > > "Hmm, not sure what you mean by "this is a new loss detection >>> > after >>> > > acknowledgment of new data"? >>> > > But anyway, RFC 5681 gives the general principle to reduce >>> > cwnd and >>> > > ssthresh twice if a retransmission is lost but IMHO (and I >>> > believe many >>> > > who have designed new loss recovery and CC algorithms or >>> > implemented >>> > > them >>> > > agree) that it is hard to get things right if only congestion >>> > control >>> > > principles are available and no algorithm." >>> > > >>> > > [Martin] >>> > > So 6675 Sec 5 is quite explicit that there is only one cwnd >>> > reduction >>> > > per fast recovery episode, which ends once new data has been >>> > > acknowledged. >>> > >>> > To be more precise: fast recovery ends when the current window >>> > becomes >>> > cumulatively acknowledged, that is, >>> > >>> > (4.1) RecoveryPoint (= HighData at the beginning) becomes >>> > acknowledged >>> > >>> > I believe we agree and you meant this although new data below >>> > RecoveryPoint may become cumulatively acknowledged already >>> > earlier >>> > during the fast recovery. Reno loss recovery in RFC 5681 ends, >>> > when >>> > (any) new data has been acknowledged. >>> > >>> > > By definition, if a retransmission is lost it is because >>> > > newer data has been acknowledged, so it's a new recovery >>> > episode. >>> > >>> > Not sure where you have this definition? Newer than what are you >>> > referring to? >>> > >>> > But, yes, if a retransmission is lost with RFC 6675 algorithm, >>> > it requires RTO to be detected and definitely starts a new >>> > recovery >>> > episode. That is, a new recovery episode is enforced by step >>> > (1.a) of >>> > NextSeg () which prevents retransmission if a segment that has >>> > already >>> > been retransmitted. If RACK-TLP is used for detecting loss with >>> > RFC 6675 >>> > things get different in many ways, because it may detect loss of >>> > a >>> > retransmission. It would pretty much require an entire redesign >>> > of the algorith. For example, calculation of pipe does not >>> > consider >>> > segments that have been retransmitted more than once. >>> > >>> > > Meanwhile, during the Fast Recovery period the incoming acks >>> > implicitly >>> > > remove data from the network and therefore keep flightsize >>> > low. >>> > >>> > Incorrect. FlightSize != pipe. Only cumulative acks remove data >>> > from >>> > FlightSize and new data transmitted during fast recovery inflate >>> > FlightSize. How FlightSize evolves depends on loss pattern as I >>> > said. >>> > It is also possible that FlightSize is low, it may err in both >>> > directions. A simple example can be used as a proof for the case >>> > where >>> > cwnd increases if a loss of retransmission is detected and >>> > repaired: >>> > >>> > RFC 6675 recovery with RACK-TLP loss detection: >>> > (contains some inaccuracies because it has not been defined how >>> > lost rexmits are calculated into pipe) >>> > >>> > cwnd=20; packets P1,...,P20 in flight = current window of data >>> > [P1 dropped and rexmit of P1 will also be dropped] >>> > >>> > DupAck w/SACK for P2 arrives >>> > [loss of P1 detected after one RTT from original xmit of P1] >>> > [cwnd=ssthresh=10] >>> > P1 is rexmitted (and it logically starts next window of data) >>> > >>> > DupAcks w/ SACK for original P3..11 arrive >>> > DupAck w/ SACK for original P12 arrives >>> > [cwnd-pipe = 10-9 >=1] >>> > send P21 >>> > DupAck w/SACK for P13 arrives >>> > send P22 >>> > ... >>> > DupAck w/SACK for P20 arrives >>> > send P29 >>> > [FlightSize=29] >>> > >>> > (Ack for rexmit of P1 would arrive here unless it got dropped) >>> > >>> > DupAck w/SACK for P21 arrives >>> > [loss of rexmit P1 detected after one RTT from rexmit of P1] >>> > >>> > SET cwnd = ssthresh = FlightSize/2= 29/2 = 14,5 >>> > >>> > CWND INCREASES when it should be at most 5 after halving it >>> > twice!!! >>> > >>> > > We can continue to go around on our interpretation of these >>> > documents, >>> > > but fundamentally if there is ambiguity in 5681/6675 we should >>> > bis >>> > > those RFCs rather than expand the scope of RACK. >>> > >>> > As I said earlier, I am not opposing bis, though 5681bis wuold >>> > not >>> > be needed, I think. >>> > >>> > But let me repeat: if we publish RACK-TLP now without necessary >>> > warnings >>> > or with a correct congesion control algorithm someone will try >>> > to >>> > implement RACK-TLP with RFC 6675 and it will be a total mesh. >>> > The >>> > behavior will be unpredictable and quite likely unsafe >>> > congestion >>> > control behavior. >>> > >>> > > 2. >>> > > [Markku] >>> > > " In short: >>> > > When with a non-RACK-TLP implementation timer (RTO) expires: >>> > cwnd=1 >>> > > MSS, >>> > > and slow start is entered. >>> > > When with a RACK_TLP implementation timer (PTO) expires, >>> > > normal fast recovery is entered (unless implementing >>> > > also PRR). So no RTO recovery as explicitly stated in Sec. >>> > 7.4.1." >>> > > >>> > > [Martin] >>> > > There may be a misunderstanding here. PTO is not the same as >>> > RTO, and >>> > > both mechanisms exist! The loss response to a PTO is to send a >>> > probe; >>> > > the RTO response is as with conventional TCP. In Section 7.3: >>> > >>> > No, I don't think I misunderstood. If you call timeout with >>> > another name, it is still timeout. And congestion control does >>> > not >>> > consider which segments to send (SND.UNA vs. probe w/ higher >>> > sequence >>> > number), only how much is sent. >>> > >>> > You ignored my major point where I decoupled congestion control >>> > from loss >>> > detection and loss recovery and compared RFC 5681 behavior to >>> > RACK-TLP >>> > behavior in exactly the same scenario where an entire flight is >>> > lost and >>> > timer expires. >>> > >>> > Please comment why congestion control behavior is allowed to be >>> > radically >>> > different in these two implementations? >>> > >>> > RFC 5681 & RFC 6298 timeout: >>> > >>> > RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >>> > 1. RTO timer expires >>> > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment >>> > 3. Ack of rexmit sent in step 2 arrives >>> > 4. cwnd = cwnd+1 MSS; send two segments >>> > ... >>> > >>> > RACK-TLP timeout: >>> > >>> > PTO=min(2*SRTT,RTO) (PTO used for arming the timer) >>> > 1. PTO times expires >>> > 2. (cwnd=1 MSS); (re)xmit one segment >>> > 3. Ack of (re)xmit sent in srep 2 arrives >>> > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments >>> > >>> > If FlightSize is 100 segments when timer expires, congestion >>> > control is >>> > the same in steps 1-3, but in step 4 the standard congestion >>> > control >>> > allows transmitting 2 segments, while RACK-TLP would allow >>> > blasting 50 segments. >>> > >>> > > After attempting to send a loss probe, regardless of whether a >>> > loss >>> > > probe was sent, the sender MUST re-arm the RTO timer, not >>> > the PTO >>> > > timer, if FlightSize is not zero. This ensures RTO >>> > recovery remains >>> > > the last resort if TLP fails. >>> > > " >>> > >>> > This does not prevent the above RACK-TLP behavior from getting >>> > realized. >>> > >>> > > So a pure RTO response exists in the case of persistent >>> > congestion that >>> > > causes losses of probes or their ACKs. >>> > >>> > Yes, RTO response exists BUT only after RACK-TLP at least once >>> > blasts the >>> > network. It may well be that with smaller windows RACK-TLP is >>> > successful >>> > during its TLP initiated overly aggressive "fast recovery" and >>> > never >>> > enters RTO recovery because it may detect and repair also loss >>> > of >>> > rexmits. That is, it continues at too high rate even if lost >>> > rexmits >>> > indicate that congestion persists in successive windows of data. >>> > And >>> > worse, it is successful because it pushes away other compatible >>> > TCP >>> > flows by being too aggressive and unfair. >>> > >>> > Even a single shot burst every time there is significant loss >>> > event is not acceptable, not to mention continuous >>> > aggressiveness, and >>> > this is exactly what RFC 2914 and RFC 5033 explicitly address >>> > and warn >>> > about. >>> > >>> > Are we ignoring these BCPs that have IETF consensus? >>> > >>> > And the other important question I'd like to have an answer: >>> > >>> > What is the justification to modify standard TCP congestion >>> > control to >>> > use fast recovery instead of slow start for a case where timeout >>> > is >>> > needed to detect the packet losses because there is no feedback >>> > and ack >>> > clock is lost? RACK-TLP explicitly instructs to do so in Sec. >>> > 7.4.1. >>> > >>> > As I noted: based on what is written in the draft it does not >>> > intend to >>> > change congestion control but effectively it does. >>> > >>> > /Markku >>> > >>> > > Martin >>> > > >>> > > >>> > > On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo >>> > >>> > > wrote: >>> > > Hi Martin, >>> > > >>> > > On Tue, 15 Dec 2020, Martin Duke wrote: >>> > > >>> > > > Hi Markku, >>> > > > >>> > > > Thanks for the comments. The authors will incorporate >>> > > many of your >>> > > > suggestions after the IESG review. >>> > > > >>> > > > There's one thing I don't understand in your comments: >>> > > > >>> > > > " That is, >>> > > > where can an implementer find advice for correct >>> > > congestion control >>> > > > actions with RACK-TLP, when: >>> > > > >>> > > > (1) a loss of rexmitted segment is detected >>> > > > (2) an entire flight of data gets dropped (and >>> > detected), >>> > > > that is, when there is no feedback available and >>> > a >>> > > timeout >>> > > > is needed to detect the loss " >>> > > > >>> > > > Section 9.3 is the discussion about CC, and is clear >>> > that >>> > > the >>> > > > implementer should use either 5681 or 6937. >>> > > >>> > > Just a cite nit: RFC 5681 provides basic CC concepts and >>> > > some useful CC >>> > > guidelines but given that RACK-TLP MUST implement SACK >>> > the >>> > > algorithm in >>> > > RFC 5681 is not that useful and an implementer quite >>> > likely >>> > > follows >>> > > mainly the algorithm in RFC 6675 (and not RFC 6937 at >>> > all >>> > > if not >>> > > implementing PRR). >>> > > And RFC 6675 is not mentioned in Sec 9.3, though it is >>> > > listed in the >>> > > Sec. 4 (Requirements). >>> > > >>> > > > You went through the 6937 case in detail. >>> > > >>> > > Yes, but without correct CC actions. >>> > > >>> > > > If 5681, it's pretty clear to me that in (1) this is a >>> > > new loss >>> > > > detection after acknowledgment of new data, and >>> > therefore >>> > > requires a >>> > > > second halving of cwnd. >>> > > >>> > > Hmm, not sure what you mean by "this is a new loss >>> > > detection after >>> > > acknowledgment of new data"? >>> > > But anyway, RFC 5681 gives the general principle to >>> > reduce >>> > > cwnd and >>> > > ssthresh twice if a retransmission is lost but IMHO (and >>> > I >>> > > believe many >>> > > who have designed new loss recovery and CC algorithms or >>> > > implemented them >>> > > agree) that it is hard to get things right if only >>> > > congestion control >>> > > principles are available and no algorithm. >>> > > That's why ALL mechanisms that we have include a quite >>> > > detailed algorithm >>> > > with all necessary variables and actions for loss >>> > recovery >>> > > and/or CC >>> > > purposes (and often also pseudocode). Like this document >>> > > does for loss >>> > > detection. >>> > > >>> > > So the problem is that we do not have a detailed enough >>> > > algorithm or >>> > > rule that tells exactly what to do when a loss of rexmit >>> > is >>> > > detected. >>> > > Even worse, the algorithms in RFC 5681 and RFC 6675 >>> > refer >>> > > to >>> > > equation (4) of RFC 5681 to reduce ssthresh and cwnd >>> > when a >>> > > loss >>> > > requiring a congestion control action is detected: >>> > > >>> > > (cwnd =) ssthresh = FlightSize / 2) >>> > > >>> > > And RFC 5681 gives a warning not to halve cwnd in the >>> > > equation but >>> > > FlightSize. >>> > > >>> > > That is, this equation is what an implementer >>> > intuitively >>> > > would use >>> > > when reading the relevant RFCs but it gives a wrong >>> > result >>> > > for >>> > > outstanding data when in fast recovery (when the sender >>> > is >>> > > in >>> > > congestion avoidance and the equation (4) is used to >>> > halve >>> > > cwnd, it >>> > > gives a correct result). >>> > > More precisely, during fast recovery FlightSize is >>> > inflated >>> > > when new >>> > > data is sent and reduced when segments are cumulatively >>> > > Acked. >>> > > What the outcome is depends on the loss pattern. In the >>> > > worst case, >>> > > FlightSize is signficantly larger than in the beginning >>> > of >>> > > the fast >>> > > recovery when FlightSize was (correctly) used to >>> > determine >>> > > the halved >>> > > value for cwnd and ssthresh, i.e., equation (4) may >>> > result >>> > > in >>> > > *increasing* cwnd upon detecting a loss of a rexmitted >>> > > segment, instead >>> > > of further halving it. >>> > > >>> > > A clever implementer might have no problem to have it >>> > right >>> > > with some >>> > > thinking but I am afraid that there will be incorrect >>> > > implementations >>> > > with what is currently specified. Not all implementers >>> > have >>> > > spent >>> > > signicicant fraction of their career in solving TCP >>> > > peculiarities. >>> > > >>> > > > For (2), the RTO timer is still operative so >>> > > > the RTO recovery rules would still follow. >>> > > >>> > > In short: >>> > > When with a non-RACK-TLP implementation timer (RTO) >>> > > expires: cwnd=1 MSS, >>> > > and slow start is entered. >>> > > When with a RACK_TLP implementation timer (PTO) expires, >>> > > normal fast recovery is entered (unless implementing >>> > > also PRR). So no RTO recovery as explicitly stated in >>> > Sec. >>> > > 7.4.1. >>> > > >>> > > This means that this document explicitly modifies >>> > standard >>> > > TCP congestion >>> > > control when there are no acks coming and the >>> > > retransmission timer >>> > > expires >>> > > >>> > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) >>> > > 1. RTO timer expires >>> > > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one >>> > > segment >>> > > 3. Ack of rexmit sent in step 2 arrives >>> > > 4. cwnd = cwnd+1 MSS; send two segments >>> > > ... >>> > > >>> > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the >>> > timer) >>> > > 1. PTO times expires >>> > > 2. (cwnd=1 MSS); (re)xmit one segment >>> > > 3. Ack of (re)xmit sent in srep 2 arrives >>> > > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd >>> > > segments >>> > > >>> > > For example, if FlightSize is 100 segments when timer >>> > > expires, >>> > > congestion control is the same in steps 1-3, but in step >>> > 4 >>> > > the >>> > > current standard congestion control allows transmitting >>> > 2 >>> > > segments, >>> > > while RACK-TLP would allow blasting 50 segments. >>> > > >>> > > Question is: what is the justification to modify >>> > standard >>> > > TCP >>> > > congestion control to use fast recovery instead of slow >>> > > start for a >>> > > case where timeout is needed to detect loss because >>> > there >>> > > is no >>> > > feedback and ack clock is lost? The draft does not give >>> > any >>> > > justification. This clearly is in conflict with items >>> > (0) >>> > > and (1) >>> > > in BCP 133 (RFC 5033). >>> > > >>> > > Furthermore, there is no implementation nor experimental >>> > > experience >>> > > evaluating this change. The implementation with >>> > > experimental experience >>> > > uses PRR (RFC 6937) which is an Experimental >>> > specification >>> > > including a >>> > > novel "trick" that directs PRR fast recovery to >>> > effectively >>> > > use slow >>> > > start in this case at hand. >>> > > >>> > > >>> > > > In other words, I am not seeing a case that requires >>> > new >>> > > congestion >>> > > > control concepts except as discussed in 9.3. >>> > > >>> > > See above. The change in standard congestion control for >>> > > (2). >>> > > The draft intends not to change congestion control but >>> > > effectively it >>> > > does without any operational evidence. >>> > > >>> > > What's also is missing and would be very useful: >>> > > >>> > > - For (1), a hint for an implementer saying that because >>> > > RACK-TLP is >>> > > able to detect a loss of a rexmit unlike any other >>> > loss >>> > > detection >>> > > algorithm, the sender MUST react twice to congestion >>> > > (and cite >>> > > RFC 5681). And cite a document where necessary >>> > correct >>> > > actions >>> > > are described. >>> > > >>> > > - For (1), advise that an implementer needs to keep >>> > track >>> > > when it >>> > > detects a loss of a retransmitted segment. Current >>> > > algorithms >>> > > in the draft detect a loss of retransmitted segment >>> > > exactly in >>> > > the same way as loss of any other segment. There >>> > seems >>> > > to be >>> > > nothing to track when a retransmission of a >>> > > retransmitted segment >>> > > takes place. Therefore, the algorithms should have >>> > > additional >>> > > actions to correctly track when such a loss is >>> > detected. >>> > > >>> > > - For (1), discussion on how many times a loss of a >>> > > retransmission >>> > > of the same segment may occur and be detected. Seems >>> > > that it >>> > > may be possible to drop a rexmitted segment more than >>> > > once and >>> > > detect it also several times? What are the >>> > > implications? >>> > > >>> > > - If previous is possible, then the algorithm possibly >>> > also >>> > > may detect a loss of a new segment that was sent >>> > during >>> > > fast >>> > > recovery? This is also loss in two successive windows >>> > of >>> > > data, >>> > > and cwnd MUST be lowered twice. This discussion and >>> > > necessary >>> > > actions to track it are missing, if such scenario is >>> > > possible. >>> > > >>> > > > What am I missing? >>> > > >>> > > Hope the above helps. >>> > > >>> > > /Markku >>> > > >>> > > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> >>> --00000000000015383b05b6b0e42c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 17, 2020 at 1:59 PM Marti= n Duke <mar= tin.h.duke@gmail.com> wrote:
This is good, thanks.

I might also add the sentence "In the absence of PRR, when TCP RACK= detects a lost retransmission it MUST trigger a second congestion response= " or something to that effect. What do you think?
Sure I'd revise a bit to be even more detailed and consistent = with the principle in RFC5681
"In the absence=C2=A0of PRR, when RACK-TLP detects a lost= retransmission the congestion control MUST trigger an additional congestio= n response per the aforementioned principle in RFC5681.
If multip= le retransmissions were lost in a window, the congestion control specified = in RFC5681 only reacts once per window, but some other congestion control m= ay want to respond multiple times differently. The congestion control imple= menter is advised to carefully=C2=A0consider this subtle situation."



On Thu, Dec 17, 2020 at 11:36 AM Yuchung Cheng <ycheng@google.com> wrote:
= How about
=C2=A0
"9.3.=C2=A0 Interaction with cong= estion control

RACK-TLP intentionally decouples loss detection ...= =C2=A0
As mentioned in Figure 1 caption, RFC5681 mandates a principle th= at
Loss in two successive windows of = data, or the loss of a
retransmission, should be taken as two ind= ications of congestion, and
therefore reacted separately. However implem= entation of RFC6675 pipe
algorithm may not directly account for this new= ly detected congestion
events properly. PRR [RFCxxxx] is RECOMMENDED for= the specific
congestion control actions taken upon the losses detected= by RACK-TLP"


To Makku's re= quest for "what's the justification to enter fast recovery". = Consider this example w/o RACK-TLP

T0: Send 100 se= gments but application-limited. All are lost.
T-2RTT: app writes = so another 3 segments are sent. Made to the destination and triggered 3 DUP= ACKs
T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent= cc reactions to burst ~50 packets with Reno=C2=A0

In this case any ACK occured before RTO is (generally) considered clock-ac= ked, and how=C2=A0I understand Van's initial design.=C2=A0 This behavio= r existed decades before RACK-TLP. RACK-TLP essentially changes the "3= -segments by app" to "1-segment by tcp".=C2=A0
On Thu, D= ec 17, 2020 at 10:52 AM Praveen Balasubramanian <pravb@microsoft.com> wrote:

I agree that we should have a note in this RFC about= congestion control action upon detecting lost retransmission(s).=

=C2=A0

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of = Martin Duke
Sent: Thursday, December 17, 2020 7:30 AM
To: Markku Kojo <kojo@cs.helsinki.fi>
Cc: tcpm@ietf.org= Extensions <tcpm= @ietf.org>; draft-ietf-tcpm-rack@ietf.org; Michael Tuexen <tuexen@fh-muenster.de>; draft-ietf-tcpm-rack.all@ietf.org; Last Call <last-call@ietf.org>; tcpm-chai= rs <tcpm-chair= s@ietf.org>
Subject: [EXTERNAL] Re: [tcpm] Last Call: <draft-ietf-tcpm-rack-1= 3.txt>(TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard<= /u>

=C2=A0

Hi Markku,

=C2=A0

Thanks, now I understand your objections.<= /u>

=C2=A0

Martin

=C2=A0

On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo <kojo@cs.helsinki.fi> wrote:

Hi,

On Wed, 16 Dec 2020, Martin Duke wrote:

> I spent a little longer looking at the specs more carefully, and I exp= lained (1)
> incorrectly in my last two messages. P21..29 are not Limited Transmit = packets.=C2=A0

Correct. Just normal the rule that allows sending new data during fast
recovery.

> However, unless I'm missing something else, 6675 is clear that the= recovery period
> does not end until the cumulative ack advances, meaning that detecting= the lost
> retransmission of P1 does not trigger another MD directly.

As I have said earlier, RFC 6675 does not repeat all congestion control principles from RFC 5681. It definitely honors the CC principle that
requires to treat a loss of a retransmission as a new congestion
indication and another MD. I believe I am obligated to know this as a
co-author of RFC 6675. ;)

RFC 6675 explicitly indicates that it follows RFC 5681 by stating in the abstract:

" ... conforms to the spirit of the current congestion control
=C2=A0 specification (RFC 5681 ..."

And in the intro:

=C2=A0 =C2=A0"The algorithm specified in this document is a straightfo= rward
=C2=A0 =C2=A0 SACK-based loss recovery strategy that follows the=C2=A0 guid= elines
=C2=A0 =C2=A0 set in [RFC5681] ..."

I don't think there is anything unclear in this.

RFC 6675 and all other standard congestion controls (RFC 5581 and RFC
6582) handle a loss of a retransmission by "enforcing" RTO to det= ect it.
And RTO guarantees MD. RACK-TLP changes the loss detection in this case and therefore the standard congestion control algorithms do not have
actions to handle it corrrectly. That is the point.

BR,

/Markku

> Thanks for this exercise! It's refreshed my memory of these detail= s after working
> on slightly different QUIC algorithms a long time.
>
> On Wed, Dec 16, 2020, 18:55 Martin Duke <martin.h.duke@gmail.com> wrote: > (1) Flightsize: in RFC 6675. Section 5, Step 4.2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4.2) ssthresh =3D cwnd =3D (FlightSize / 2= )
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The congestion window = (cwnd) and slow start threshold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ssthresh) are reduced= to half of FlightSize per [RFC5681].
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionally, note tha= t [RFC5681] requires that any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segments sent as part = of the Limited Transmit mechanism not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be counted in FlightSi= ze for the purpose of the above
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equation.
>
> IIUC the segments P21..P29 in your example were sent because of Limite= d
> Transmit, and so don't count. The flightsize for the purposes of (= 4.2) is
> therefore 20 after both losses, and the cwnd does not go up on the sec= ond
> loss.
>
> (2)
> " Even a single shot burst every time there is significant loss > event is not acceptable, not to mention continuous aggressiveness, and=
> this is exactly what RFC 2914 and RFC 5033 explicitly address and warn=
> about."
>
> "Significant loss event" is the key phrase here. The intent = of TLP/PTO is to
> equalize the treatment of a small packet loss whether it happened in t= he
> middle of a burst or the end. Why should an isolated loss be treated > differently based on its position in the burst? This is just a logical=
> extension of fast retransmit, which also modified the RTO paradigm. Th= e
> working group consensus is that this is a feature, not a bug; you'= re welcome
> to feel otherwise but I suspect you're in the rough here.
>
> Regards
> Martin
>
>
> On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo <kojo@cs.helsinki.fi> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0See inline.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 16 Dec 2020, Martin Duke wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There is a ton here, but I'll try t= o address the top points.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> they obviate the rest.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for being verbose. I tried to be clear= but you actually
>=C2=A0 =C2=A0 =C2=A0 =C2=A0removed my
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key issues/questions ;)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "Hmm, not sure what you mean by &q= uot;this is a new loss detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0after
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledgment of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> But anyway, RFC 5681 gives the general = principle to reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> ssthresh twice if a retransmission is l= ost but IMHO (and I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> who have designed new loss recovery and= CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> them
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> agree) that it is hard to get things ri= ght if only congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> principles are available and no algorit= hm."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So 6675 Sec 5 is quite explicit that th= ere is only one cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduction
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> per fast recovery episode, which ends o= nce new data has been
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To be more precise: fast recovery ends when = the current window
>=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cumulatively acknowledged, that is,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(4.1) RecoveryPoint (=3D HighData at the beg= inning) becomes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledged
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we agree and you meant this althou= gh new data below
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RecoveryPoint may become cumulatively acknow= ledged already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0earlier
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during the fast recovery. Reno loss recovery= in RFC 5681 ends,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(any) new data has been acknowledged.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition, if a retransmission is l= ost it is because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> newer data has been acknowledged, so it= 's a new recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure where you have this definition? New= er than what are you
>=C2=A0 =C2=A0 =C2=A0 =C2=A0referring to?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But, yes, if a retransmission is lost with R= FC 6675 algorithm,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0it requires RTO to be detected and definitel= y starts a new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. That is, a new recovery episode is = enforced by step
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(1.a) of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0NextSeg () which prevents retransmission if = a segment that has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0already
>=C2=A0 =C2=A0 =C2=A0 =C2=A0been retransmitted. If RACK-TLP is used for = detecting loss with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0things get different in many ways, because i= t may detect loss of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission. It would pretty much require= an entire redesign
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of the algorith. For example, calculation of= pipe does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider
>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments that have been retransmitted more t= han once.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Meanwhile, during the Fast Recovery per= iod the incoming acks
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implicitly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> remove data from the network and theref= ore keep flightsize
>=C2=A0 =C2=A0 =C2=A0 =C2=A0low.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Incorrect. FlightSize !=3D pipe. Only cumula= tive acks remove data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize and new data transmitted during f= ast recovery inflate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. How FlightSize evolves depends o= n loss pattern as I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0said.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0It is also possible that FlightSize is low, = it may err in both
>=C2=A0 =C2=A0 =C2=A0 =C2=A0directions. A simple example can be used as = a proof for the case
>=C2=A0 =C2=A0 =C2=A0 =C2=A0where
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd increases if a loss of retransmission i= s detected and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 recovery with RACK-TLP loss detecti= on:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(contains some inaccuracies because it has n= ot been defined how
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost rexmits are calculated into pipe)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D20; packets P1,...,P20 in flight =3D = current window of data
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 dropped and rexmit of P1 will also be dr= opped]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of P1 detected after one RTT from orig= inal xmit of P1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd=3Dssthresh=3D10]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0P1 is rexmitted (and it logically starts nex= t window of data)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAcks w/ SACK for original P3..11 arrive >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/ SACK for original P12 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd-pipe =3D 10-9 >=3D1]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P21
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P13 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P22
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P20 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0send P29
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[FlightSize=3D29]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(Ack for rexmit of P1 would arrive here unle= ss it got dropped)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P21 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of rexmit P1 detected after one RTT fr= om rexmit of P1]
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0SET cwnd =3D ssthresh =3D FlightSize/2=3D 29= /2 =3D 14,5
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CWND INCREASES when it should be at most 5 a= fter halving it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0twice!!!
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> We can continue to go around on our int= erpretation of these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0documents,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> but fundamentally if there is ambiguity= in 5681/6675 we should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bis
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> those RFCs rather than expand the scope= of RACK.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I said earlier, I am not opposing bis, th= ough 5681bis wuold
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0be needed, I think.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0But let me repeat: if we publish RACK-TLP no= w without necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0warnings
>=C2=A0 =C2=A0 =C2=A0 =C2=A0or with a correct congesion control algorith= m someone will try
>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement RACK-TLP with RFC 6675 and it will= be a total mesh.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior will be unpredictable and quite lik= ely unsafe
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control behavior.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a non-RACK-TLP implementation= timer (RTO) expires:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> and slow start is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a RACK_TLP implementation tim= er (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> normal fast recovery is entered (unless= implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> also PRR). So no RTO recovery as explic= itly stated in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There may be a misunderstanding here. P= TO is not the same as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RTO, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> both mechanisms exist! The loss respons= e to a PTO is to send a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0probe;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO response is as with conventiona= l TCP. In Section 7.3:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0No, I don't think I misunderstood. If yo= u call timeout with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0another name, it is still timeout. And conge= stion control does
>=C2=A0 =C2=A0 =C2=A0 =C2=A0not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0consider which segments to send (SND.UNA vs.= probe w/ higher
>=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number), only how much is sent.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0You ignored my major point where I decoupled= congestion control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection and loss recovery and compared RFC= 5681 behavior to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior in exactly the same scenario where = an entire flight is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0lost and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer expires.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Please comment why congestion control behavi= or is allowed to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0radically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0different in these two implementations?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 & RFC 6298 timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRTT+4*RTT= VAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; = ssthresh=3DFlightSize/2; rexmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit = sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+= 1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP timeout:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3Dmin(2= *SRTT,RTO) (PTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expi= res
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS)= ; (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmi= t sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthr= esh =3D FlightSize/2; send N=3Dcwnd segments
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If FlightSize is 100 segments when timer exp= ires, congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the same in steps 1-3, but in step 4 the sta= ndard congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0allows transmitting 2 segments, while RACK-T= LP would allow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasting 50 segments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> After attempting to send a loss probe, = regardless of whether a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 probe was sent, the sender= MUST re-arm the RTO timer, not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the PTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 timer, if FlightSize is no= t zero.=C2=A0 This ensures RTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery remains
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the last resort if TLP fai= ls.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> "
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not prevent the above RACK-TLP beh= avior from getting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0realized.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> So a pure RTO response exists in the ca= se of persistent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> causes losses of probes or their ACKs.<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, RTO response exists BUT only after RACK= -TLP at least once
>=C2=A0 =C2=A0 =C2=A0 =C2=A0blasts the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0network. It may well be that with smaller wi= ndows RACK-TLP is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0successful
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during its TLP initiated overly aggressive &= quot;fast recovery" and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0never
>=C2=A0 =C2=A0 =C2=A0 =C2=A0enters RTO recovery because it may detect an= d repair also loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits. That is, it continues at too high r= ate even if lost
>=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate that congestion persists in success= ive windows of data.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And
>=C2=A0 =C2=A0 =C2=A0 =C2=A0worse, it is successful because it pushes aw= ay other compatible
>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0flows by being too aggressive and unfair. >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even a single shot burst every time there is= significant loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0event is not acceptable, not to mention cont= inuous
>=C2=A0 =C2=A0 =C2=A0 =C2=A0aggressiveness, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0this is exactly what RFC 2914 and RFC 5033 e= xplicitly address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and warn
>=C2=A0 =C2=A0 =C2=A0 =C2=A0about.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Are we ignoring these BCPs that have IETF co= nsensus?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0And the other important question I'd lik= e to have an answer:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0What is the justification to modify standard= TCP congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0control to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use fast recovery instead of slow start for = a case where timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0needed to detect the packet losses because t= here is no feedback
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and ack
>=C2=A0 =C2=A0 =C2=A0 =C2=A0clock is lost? RACK-TLP explicitly instructs= to do so in Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0As I noted: based on what is written in the = draft it does not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intend to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0change congestion control but effectively it= does.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Martin
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Dec 16, 2020 at 11:39 AM Markku= Kojo
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<kojo@cs.helsinki.fi>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 15 De= c 2020, Martin Duke wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markk= u,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks f= or the comments. The authors will incorporate
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of your<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggesti= ons after the IESG review.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There= 9;s one thing I don't understand in your comments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " T= hat is,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where ca= n an implementer find advice for correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions = with RACK-TLP, when:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a lo= ss of rexmitted segment is detected
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an e= ntire flight of data gets dropped (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected),
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0that is, when there is no feedback available and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0is needed to detect the loss "
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section = 9.3 is the discussion about CC, and is clear
>=C2=A0 =C2=A0 =C2=A0 =C2=A0that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> implemen= ter should use either 5681 or 6937.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a cite n= it: RFC 5681 provides basic CC concepts and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0some useful C= C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0guidelines bu= t given that RACK-TLP MUST implement SACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm in<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 is n= ot that useful and an implementer quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0likely
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly the al= gorithm in RFC 6675 (and not RFC 6937 at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementing = PRR).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6675 = is not mentioned in Sec 9.3, though it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in the=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (Requi= rements).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You went= through the 6937 case in detail.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but with= out correct CC actions.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681,= it's pretty clear to me that in (1) this is a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detectio= n after acknowledgment of new data, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second h= alving of cwnd.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not sure= what you mean by "this is a new loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection aft= er
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledgmen= t of new data"?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anyway, R= FC 5681 gives the general principle to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh twic= e if a retransmission is lost but IMHO (and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have desi= gned new loss recovery and CC algorithms or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented t= hem
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) that i= t is hard to get things right if only
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0principles ar= e available and no algorithm.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That's wh= y ALL mechanisms that we have include a quite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed algo= rithm
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all nece= ssary variables and actions for loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes (and= often also pseudocode). Like this document
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for loss=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the proble= m is that we do not have a detailed enough
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm or<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that tel= ls exactly what to do when a loss of rexmit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even worse, t= he algorithms in RFC 5681 and RFC 6675
>=C2=A0 =C2=A0 =C2=A0 =C2=A0refer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation (4) = of RFC 5681 to reduce ssthresh and cwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring a c= ongestion control action is detected:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (cwnd = =3D) ssthresh =3D FlightSize / 2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5681 = gives a warning not to halve cwnd in the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation but<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. >=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, this= equation is what an implementer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0intuitively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when reading = the relevant RFCs but it gives a wrong
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstanding d= ata when in fast recovery (when the sender
>=C2=A0 =C2=A0 =C2=A0 =C2=A0is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion av= oidance and the equation (4) is used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0halve
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a corre= ct result).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0More precisel= y, during fast recovery FlightSize is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0inflated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is sent = and reduced when segments are cumulatively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the outc= ome is depends on the loss pattern. In the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst case, >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize is= signficantly larger than in the beginning
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery when= FlightSize was (correctly) used to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0determine
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halved >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for cwn= d and ssthresh, i.e., equation (4) may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasing* = cwnd upon detecting a loss of a rexmitted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, inst= ead
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0of further ha= lving it.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever impl= ementer might have no problem to have it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0right
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking but = I am afraid that there will be incorrect
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implementatio= ns
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what is = currently specified. Not all implementers
>=C2=A0 =C2=A0 =C2=A0 =C2=A0have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicicant f= raction of their career in solving TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiarities= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2),= the RTO timer is still operative so
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO = recovery rules would still follow.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a n= on-RACK-TLP implementation timer (RTO)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: cwnd= =3D1 MSS,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow star= t is entered.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with a R= ACK_TLP implementation timer (PTO) expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fast r= ecovery is entered (unless implementing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR). So= no RTO recovery as explicitly stated in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0This means th= at this document explicitly modifies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP congestio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0control when = there are no acks coming and the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO=3DS= RTT+4*RTTVAR (RTO used for arming the timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. RTO timer expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit one
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 =C2= =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0timer)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A01. PTO times expires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcwnd
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0For example, = if FlightSize is 100 segments when timer
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol is the same in steps 1-3, but in step
>=C2=A0 =C2=A0 =C2=A0 =C2=A04
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current stand= ard congestion control allows transmitting
>=C2=A0 =C2=A0 =C2=A0 =C2=A02
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RACK-TL= P would allow blasting 50 segments.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question is: = what is the justification to modify
>=C2=A0 =C2=A0 =C2=A0 =C2=A0standard
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion co= ntrol to use fast recovery instead of slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0case where ti= meout is needed to detect loss because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0there
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback and = ack clock is lost? The draft does not give
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0justification= . This clearly is in conflict with items
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(0)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 133 (R= FC 5033).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermore, = there is no implementation nor experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experience >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluating th= is change. The implementation with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimental = experience
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR (RFC= 6937) which is an Experimental
>=C2=A0 =C2=A0 =C2=A0 =C2=A0specification
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0including a >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "t= rick" that directs PRR fast recovery to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in this= case at hand.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In other= words, I am not seeing a case that requires
>=C2=A0 =C2=A0 =C2=A0 =C2=A0new
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control = concepts except as discussed in 9.3.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above. Th= e change in standard congestion control for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft int= ends not to change congestion control but
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively i= t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does without = any operational evidence.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's al= so is missing and would be very useful:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), a = hint for an implementer saying that because
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP is >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= able to detect a loss of a rexmit unlike any other
>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= algorithm, the sender MUST react twice to congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= RFC 5681). And cite a document where necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0correct
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= are described.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), ad= vise that an implementer needs to keep
>=C2=A0 =C2=A0 =C2=A0 =C2=A0track
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detects a loss of a retransmitted segment. Current
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithms >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= in the draft detect a loss of retransmitted segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly in >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= the same way as loss of any other segment. There
>=C2=A0 =C2=A0 =C2=A0 =C2=A0seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= nothing to track when a retransmission of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmitted= segment
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= takes place. Therefore, the algorithms should have
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0additional >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to correctly track when such a loss is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1), di= scussion on how many times a loss of a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmissio= n
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= of the same segment may occur and be detected. Seems
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may be possible to drop a rexmitted segment more than
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= detect it also several times?=C2=A0 What are the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implications?=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If previous= is possible, then the algorithm possibly
>=C2=A0 =C2=A0 =C2=A0 =C2=A0also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= may detect a loss of a new segment that was sent
>=C2=A0 =C2=A0 =C2=A0 =C2=A0during
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= recovery? This is also loss in two successive windows
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= and cwnd MUST be lowered twice. This discussion and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0= actions to track it are missing, if such scenario is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am = I missing?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the abov= e helps.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0> <snipping the rest>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0>
>
>
>

--00000000000015383b05b6b0e42c-- From nobody Fri Dec 18 06:45:54 2020 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 8D0673A03FA for ; Fri, 18 Dec 2020 06:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 tgZm7oB2bS6G for ; Fri, 18 Dec 2020 06:45:46 -0800 (PST) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 77A7D3A0762 for ; Fri, 18 Dec 2020 06:45:46 -0800 (PST) Received: by mail-vk1-xa2c.google.com with SMTP id m145so567232vke.7 for ; Fri, 18 Dec 2020 06:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gTAcViMUIemCH47qDOdAigkN/fDD3Cisfv8QC7BFFiE=; b=WpwTnag5rJYi0wl5EN3pedJjKNu0liAH++IIYSVlL8LcBR2ccTYGy01ZJxkN5626SH FwXWjkWWfzLkUUByCbnUvYSnxtsjInpy+jgxA/JJl5jArHDoTu3EIDDqbX7m+3AEzZGa 73LaKrBrV2KEka/wAxEDG26wEVeufRxmi/M6aH3gHOvs+iq9lz8L2Ysla7+mhOXpmfx7 w6sJe0/kP//Ji+ejyNl14rTP1Z/JK4ORT86StBCHxNI86cLhZUiQjm8ERxWpdKoPQuAk DgEQ5pbJrg0hSPctJuSFiVX9o0t4ainG3XJSWypDhiuS3tBrLEGRfMuTbYK/nobKgutU PlEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gTAcViMUIemCH47qDOdAigkN/fDD3Cisfv8QC7BFFiE=; b=W0JiyQbW8lGhIc6YrKP6GO4EZF+jQWjtABxjz3/2MkAx8pk8sLAmab/Wh1AHiSqrRd jID4gL/zjCr4le5yNiHySIJ/8PzgRoH/L5BeG7gZBv3j8NmcWW5c4UGtAhhOzWkCBcFx VJwqUauDwSMBsR5lZOgjn0O/ocPsImcbCwCt0Ioqh+M+mznD7aDGyRy4wSVwYbBG5cX0 HJyafV3TdT1NBXHSZWBp6c5UCb2JavFv3+ZS40bOH/KblNldl2oTCM00BeKl8iAvNH/z i1u93PXg1bfj2qnMGYG4rWUBlJkCviwPNtdxBhG0ta4ksUhbZ+M6zxaCbeqDFeTD1CMu 6srw== X-Gm-Message-State: AOAM530Te6r5D4EWCvd0y5816oUK0osZ5U+H1AhBUCXnbm6R8DwH0739 8kiEh7t9KIKIuzqT4qpgT/o7ySoqQGH2Wbso+HvkI3PNT0DFwHi/ X-Google-Smtp-Source: ABdhPJwsUrYcdT8DqfLULsdB2NR/TQZLVgNlpXBm86qYO7BytrrZk6ZvEkckba1L1r/3aK7HO+A7dVQ5m9oqLu2Jfbg= X-Received: by 2002:a1f:3fc9:: with SMTP id m192mr4415105vka.17.1608302745213; Fri, 18 Dec 2020 06:45:45 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Neal Cardwell Date: Fri, 18 Dec 2020 09:45:28 -0500 Message-ID: To: Markku Kojo Cc: Martin Duke , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000d25aa405b6be2937" Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithm for TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 14:45:50 -0000 --000000000000d25aa405b6be2937 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 16, 2020 at 2:39 PM Markku Kojo wrote: > > For (2), the RTO timer is still operative so > > the RTO recovery rules would still follow. > > In short: > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=1 MSS, > and slow start is entered. > When with a RACK_TLP implementation timer (PTO) expires, > normal fast recovery is entered (unless implementing > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1. > > This means that this document explicitly modifies standard TCP congestion > control when there are no acks coming and the retransmission timer > expires > > from: RTO=SRTT+4*RTTVAR (RTO used for arming the timer) > It's also worth mentioning this aspect of [RFC6298]: (2.4) Whenever RTO is computed, if it is less than 1 second, then the RTO SHOULD be rounded up to 1 second. > 1. RTO timer expires > 2. cwnd=1 MSS; ssthresh=FlightSize/2; rexmit one segment > 3. Ack of rexmit sent in step 2 arrives > 4. cwnd = cwnd+1 MSS; send two segments > ... > > to: PTO=min(2*SRTT,RTO) (PRO used for arming the timer) > 1. PTO times expires > 2. (cwnd=1 MSS); (re)xmit one segment > It may be worthwhile to point out here that the RACK-TLP draft does not specify setting cwnd to 1 at this point, and the Linux TCP implementation from our team does not do this. The rationale is that at this point there is no solid evidence that anything has been lost, and setting cwnd to 1 at this point would make the algorithm more timid than the preceding approaches, for no good reason. > 3. Ack of (re)xmit sent in srep 2 arrives > 4. cwnd = ssthresh = FlightSize/2; send N=cwnd segments > That step (4) assumes a particular congestion control implementation that is different than what we would recommend. For example, if FlightSize is 100 segments when timer expires, > congestion control is the same in steps 1-3, but in step 4 the > current standard congestion control allows transmitting 2 segments, > while RACK-TLP would allow blasting 50 segments. > > Question is: what is the justification to modify standard TCP > congestion control to use fast recovery instead of slow start for a > case where timeout is needed to detect loss because there is no > feedback and ack clock is lost? The draft does not give any > justification. This clearly is in conflict with items (0) and (1) > in BCP 133 (RFC 5033). > The draft pointedly does not modify standard TCP congestion control. RACK-TLP does not specify using fast recovery instead of slow start for a case where timeout is needed to detect loss because there is no feedback and the ACK clock is lost. Rather, RACK-TLP only triggers fast recovery if there *is* ACK feedback providing an ACK clock and strong evidence of a packet loss. The main aspect of triggering loss recovery that is new is the approach of allowing a sender to transmit one additional "probe" segment in flight after 2*SRTT. Once this is accepted, the rest of the recovery process essentially follows from principles already generally accepted in the IETF TCP community. Put another way, it seems to me that if one is to object to TLP-triggered fast recovery, then the objection must be mounted specifically against the permission granted to the sender to transmit one additional "probe" segment in flight after 2*SRTT. Once that permission is granted, there is nothing really new about TLP-triggered fast recovery. Furthermore, there is no implementation nor experimental experience > evaluating this change. The implementation with experimental experience > uses PRR (RFC 6937) which is an Experimental specification including a > novel "trick" that directs PRR fast recovery to effectively use slow > start in this case at hand. > What do you think of Yuchung's latest suggestion for new text in "9.3. Interaction with congestion control" suggested by Yuchung Thursday afternoon (Dec 17), which explicitly recommends PRR? As mentioned earlier in this thread, there is considerable implementation and experimental experience with RACK-TLP plus PRR since the Linux TCP stack has been using RACK-TLP with PRR as the default loss recovery algorithm since Linux v4.18 in August 2018. The exact commit is: b38a51fec1c1 tcp: disable RFC6675 loss detection best, neal --000000000000d25aa405b6be2937 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 16, 2020 at 2:39 PM Markk= u Kojo <kojo@cs.helsinki.fi&g= t; wrote:
> For (2), the RTO timer is still operative so
> the RTO recovery rules would still follow.

In short:
When with a non-RACK-TLP implementation timer (RTO) expires: cwnd=3D1 MSS, =
and slow start is entered.
When with a RACK_TLP implementation timer (PTO) expires,
normal fast recovery is entered (unless implementing
also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1.

This means that this document explicitly modifies standard TCP congestion <= br> control when there are no acks coming and the retransmission timer
expires

from: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer)
<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;break-before:page;color:rgb(0,0,0)">
It's also = worth mentioning this aspect of [RFC6298]:
=
=C2=A0 =C2=A0(2.4) Whenever RTO is computed, if it is less than 1 secon= d, then the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0RTO SHOULD be rounded up = to 1 second.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO timer expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit= one segment
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments
=C2=A0 =C2=A0 =C2=A0 =C2=A0...

to:=C2=A0 =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the timer)
=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO times expires
=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment

It may be worthwhile to point out here that the= RACK-TLP draft does not specify setting cwnd to 1 at this point, and the L= inux TCP implementation from our team does not do this. The rationale is th= at at this point there is no solid evidence that anything has been lost, an= d setting cwnd to 1 at this point would make the algorithm more timid than = the preceding approaches, for no good reason.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 arrives
=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3D= cwnd segments

That step (4) assumes a partic= ular congestion control implementation that is different than what we would= recommend.


For example, if FlightSize is 100 segments when timer expires,
congestion control is the same in steps 1-3, but in step 4 the
current standard congestion control allows transmitting 2 segments,
while RACK-TLP would allow blasting 50 segments.

Question is: what is the justification to modify standard TCP
congestion control to use fast recovery instead of slow start for a
case where timeout is needed to detect loss because there is no
feedback and ack clock is lost? The draft does not give any
justification. This clearly is in conflict with items (0) and (1)
in BCP 133 (RFC 5033).

The draft pointe= dly does not modify standard TCP congestion control.

RACK-TLP does not specify using fast recovery instead of slow start for = a=C2=A0 case where timeout is needed to detect loss because there is no=C2= =A0 feedback and the ACK clock is lost. Rather, RACK-TLP only triggers fast= recovery if there *is* ACK feedback providing an ACK clock and strong evid= ence of a packet loss.

The main aspect of triggeri= ng loss recovery that is new is the approach of allowing a sender to transm= it one additional "probe" segment in flight after 2*SRTT. Once th= is is accepted, the rest of the recovery process essentially follows from p= rinciples already generally accepted in the IETF TCP community.
<= br>
Put another way, it seems to me that if one is to object to T= LP-triggered fast recovery, then the objection must be mounted specifically= against the permission granted to the sender to transmit one additional &q= uot;probe" segment in flight after 2*SRTT. Once that permission is gra= nted, there is nothing really new about TLP-triggered fast recovery.
<= div>
Furthermore, there is no implementation nor experimental experience
evaluating this change. The implementation with experimental experience uses PRR (RFC 6937) which is an Experimental specification including a
novel "trick" that directs PRR fast recovery to effectively use s= low
start in this case at hand.

What do you= think of Yuchung's latest suggestion for new text in "9.3.=C2=A0 = Interaction with congestion control" suggested by Yuchung Thursday aft= ernoon (Dec 17), which explicitly recommends PRR? As mentioned earlier in t= his thread, there is considerable implementation and experimental experienc= e with RACK-TLP plus PRR since the Linux TCP stack has been using RACK-TLP = with PRR as the default=C2=A0loss=C2=A0reco= very algorithm since Linux v4.18 in August 2018. The exact commit is:
=

=C2=A0 b38a51fec1c1 tcp:=C2=A0disable=C2=A0RFC6675=C2=A0loss=C2=A0detection

best,
neal
=

--000000000000d25aa405b6be2937-- From nobody Fri Dec 18 08:04:28 2020 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 3A27D3A0B16 for ; Thu, 17 Dec 2020 17:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 eT4zGI_qe79D for ; Thu, 17 Dec 2020 17:35:59 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 AB4933A0B12 for ; Thu, 17 Dec 2020 17:35:59 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id w7so303255uap.13 for ; Thu, 17 Dec 2020 17:35:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5t06hcd1UDu8DOCNAbOkMdDgHAel45UKzYala3IoXRA=; b=TVFG8TNYgOCkWgkPckgD8DXVCEJh8OIsrlrhNwQOo0Oiep1UTnIzIRGOil5BLD7FY1 n1l4x5A5N2DYEWZk5img+1fiONKyNLG2RQgsmwHh79kjkIwYKQIXUWvQOcDm8ZiSQ8sG Zz4awE77Z8d29a+25rQRcZgpLTapQ/QcOvjHlDmAE2554rduKxJ5ThYpfqD71wONukTM hEU1Jjm3U3ADU3VfTjZwLF0TGUwG3zHXEHJv0n1sDjzBcc+YdgYlEvBc5j8rPpYEMy6x 0DdPzbsxCeRQkc1FXL3Ofhme0qow3Zk71Abj63gK29RDps6osL7+xSccAFTYwniPevco /LZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5t06hcd1UDu8DOCNAbOkMdDgHAel45UKzYala3IoXRA=; b=K+eH7ufmz5L0g052PuiYGVhhrIwAh+9NyPnP255ItoDIQT1NlIwWRV8ujP9OaJtIoZ 7styyY/5dhjso/NOH8zSiuolxyUEQPSAgJab1tkxC0fhq91JpIPpIVhAbuYPwsAD/I5n V4/AwRFHhO4lCdWqg5npymM1npJp+PktMGLzIY9jMIV2F11EooCg+U7eBWvje83X/S6+ 5QTtqD8l36LnNm8i9digGAMXX8IyNyVY/j6hJEUiFAfJMKyJsLpYcDm7874ZX2TbrZ9z rMSJ9oudJUv52ADNo4IoQG/8wfNOGYKcEf9QG8G1eFb8kGxNbIIMkM3eW8eNPOViP9su 8o9w== X-Gm-Message-State: AOAM530FBKSjnRpwyJX+1ElgwZkeSFZXFh+bIPD0UribQT5bJvE7JkpU JSzevoNmUZMKaUzOOEwioJMkikdhvZHq8alAfPet/Q== X-Google-Smtp-Source: ABdhPJydMcTwK/v4JBE9Nk7g40izka04JV1iIAMCXURFPiVLCEO42U6/hroVBzZrCnepmWYP4nVTKuOlycKDdhAcpQI= X-Received: by 2002:ab0:2719:: with SMTP id s25mr1850618uao.63.1608255358162; Thu, 17 Dec 2020 17:35:58 -0800 (PST) MIME-Version: 1.0 References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: From: Neal Cardwell Date: Thu, 17 Dec 2020 20:35:41 -0500 Message-ID: To: Yuchung Cheng Cc: Praveen Balasubramanian , "martin.h.duke@gmail.com" , "kojo@cs.helsinki.fi" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005557ca05b6b32104" Archived-At: X-Mailman-Approved-At: Fri, 18 Dec 2020 08:04:27 -0800 Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 01:36:01 -0000 --0000000000005557ca05b6b32104 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 17, 2020 at 2:36 PM Yuchung Cheng wrote: > How about > > "9.3. Interaction with congestion control > > RACK-TLP intentionally decouples loss detection ... > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. PRR [RFCxxxx] is RECOMMENDED for the specific > congestion control actions taken upon the losses detected by RACK-TLP" > > > To Makku's request for "what's the justification to enter fast recovery". > Consider this example w/o RACK-TLP > > T0: Send 100 segments but application-limited. All are lost. > T-2RTT: app writes so another 3 segments are sent. Made to the destination > and triggered 3 DUPACKs > T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactions > to burst ~50 packets with Reno > > In this case any ACK occured before RTO is (generally) considered > clock-acked, and how I understand Van's initial design. This behavior > existed decades before RACK-TLP. RACK-TLP essentially changes the > "3-segments by app" to "1-segment by tcp". > To amplify Yuchung's nice example, and try to restate it in more general terms: As far as I'm aware, TLP probes do not introduce materially new congestion control behaviors, beyond what can happen with [RFC5681] and [RFC6675]. This is because a TLP probe serves much the same probing function that an application write() could have served, if the application had been so lucky as to time its write at the appropriate time (i.e. delay the write() of the last segment in the flight to be 2*SRTT after the preceding segment). Thus, for any scenario that one constructs where a TLP probe initiates a fast recovery episode, it is possible to construct, for a TCP implementation implementing just [RFC5681] and [RFC6675], an application write() pattern where the on-the-wire behavior is nearly identical to the TLP-initiated recovery. For folks concerned about a scenario with FlightSize of 100 segments, and a sender entering fast recovery and blasting 50 segments, the same behavior could happen with the existing RFCs [RFC5681] and [RFC6675], which allow that. And implementers who are worried about such bursts (a very reasonable thing to be worried about) should probably be implementing pacing and PRR, or something like that. But that was already true before RACK-TLP. best, neal --0000000000005557ca05b6b32104 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 17, 2020 at 2:36 PM Yuchung C= heng <ycheng@google.com> wro= te:
How about
=C2=A0
&= quot;9.3.=C2=A0 Interaction with congestion control

RACK-TLP inten= tionally decouples loss detection ...=C2=A0
As mentioned in Figure 1 cap= tion, RFC5681 mandates a principle that<= br>Loss in two successive windows of data, or the loss of a
retra= nsmission, should be taken as two indications of congestion, and
therefo= re reacted separately. However implementation of RFC6675 pipe
algorithm = may not directly account for this newly detected congestion
events prope= rly. PRR [RFCxxxx] is RECOMMENDED for the specific
congestion control a= ctions taken upon the losses detected by RACK-TLP"

=

To Makku's request for "what's the justifi= cation to enter fast recovery". Consider this example w/o RACK-TLP

T0: Send 100 segments but application-limited. All ar= e lost.
T-2RTT: app writes so another 3 segments are sent. Made t= o the destination and triggered 3 DUPACKs
T-3RTT: 3 DUPACK arrive= s. start fast recovery and subsequent cc reactions to burst ~50 packets wit= h Reno=C2=A0

In this case any ACK occured before R= TO is (generally) considered clock-acked, and how=C2=A0I understand Van'= ;s initial design.=C2=A0 This behavior existed decades before RACK-TLP. RAC= K-TLP essentially changes the "3-segments by app" to "1-segm= ent by tcp".=C2=A0

=
To amplify Yuchung's nice example, and try to restate it in more g= eneral terms:

As far as I'm aware, TLP probes do not introduce m= aterially new congestion control behaviors, beyond what can happen with [RF= C5681] and [RFC6675].

This is because a TLP probe serves much the sa= me probing function that an application write() could have served, if the a= pplication had been so lucky as to time its write at the appropriate time (= i.e. delay the write() of the last segment in the flight to be 2*SRTT after= the preceding segment).

Thus, for any scenario that one constructs = where a TLP probe initiates a fast recovery episode, it is possible to cons= truct, for a TCP implementation implementing just [RFC5681] and [RFC6675], = an application write() pattern where the on-the-wire behavior is nearly ide= ntical to the TLP-initiated recovery.

For folks concerned= about a scenario with FlightSize of 100 segments, and a sender entering fa= st recovery and blasting 50 segments, the same behavior could happen with t= he existing RFCs [RFC5681] and [RFC6675], which allow that. And implementer= s who are worried about such bursts (a very reasonable thing to be worried = about) should probably be implementing pacing and PRR, or something like th= at. But that was already true before RACK-TLP.

bes= t,
neal

--0000000000005557ca05b6b32104-- From nobody Fri Dec 18 09:33:06 2020 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 7C8943A0B08 for ; Fri, 18 Dec 2020 09:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 mqFtM5yYqlEF for ; Fri, 18 Dec 2020 09:32:59 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 981333A0B0A for ; Fri, 18 Dec 2020 09:32:59 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id g185so3427764wmf.3 for ; Fri, 18 Dec 2020 09:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RoZ8HHOUXijQCf246o1juRseqyI/tIesO5wqnCUCrZc=; b=tQbiMoY71mqMAzBIyV9DJEg7a5IgpY52EGUtnZJxFRn+d45NjnybG70V13V3JsYo92 N5Pmm3OWp+SnJL0YLRrTX6jP0SBuWEaONphzoBh5wZ/W/HD/Dz0bBgNHRwcwm7LNoPkU NGwDXisHqvpf0UEYI7exAQhdjjF9AquZKfvHlw3ctg3hN0uQsCeD25eQwWmEdlWRPNkf RlPz4abvHPOIvHuiBn1ouyJr2KKVuXqQUtPWZrz6v4xbUDHYMJ8/9aTr+fizXcGYIeUD l3fazfp0UK5a9JF6vM3zVn43jD8yb/qLC15rO1EatyrYvcVgwUDXFCFdpm0SYvtIKQlL hTOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RoZ8HHOUXijQCf246o1juRseqyI/tIesO5wqnCUCrZc=; b=OVTXSvJDcdjYKd+k569SK7CLpcASNtDe668UAMuZauj2tsaQLbbNHnRtXHNYjKldB/ yY4uYP/e7c8wDlrZ8cvOUFNgLOpjajjegPYws9KGjBxmAkweFZEARBCJC/+pPYL8z9Fu Pvh7cXWT7J6uNXZLDvaMqM+UD6A/fgk7iNtX8rmEbtHcqcwr2YwbKRZFcSTJCZf9l4ws aE9L+lLh+c6XK3cs54qDwzkMlb+JjTIycSiQgrtRA/rOOYcYnuZMwI+22IqyUzNbeK4F nT6o3jn4Ur8/aM+UAbcVG0DJAE0m9bhP8fK4l6AZY1fDtAXkb05O0Nu1lxaenRMFekE9 IyHQ== X-Gm-Message-State: AOAM532jFy1LXUMLZfgWjcwZaeuP/wp5DIfB1ke/3ytRym9nMx2MCNj3 hhJ/9/7v7vqDisaC2nVJkJD8sKo8tBdKDRkdOybvjA== X-Google-Smtp-Source: ABdhPJy3QiGJ5d1YHc66scn8JGw1+JIoOJU4FvlkQsERsfM8Hi3xLwAhnHbLCgI6p2sh6En4oeam+yuR2G0QlZFiuJM= X-Received: by 2002:a1c:6856:: with SMTP id d83mr5228897wmc.119.1608312777614; Fri, 18 Dec 2020 09:32:57 -0800 (PST) MIME-Version: 1.0 References: <160820221460.14977.1292601307954405019@ietfa.amsl.com> In-Reply-To: <160820221460.14977.1292601307954405019@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 09:32:20 -0800 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="000000000000ccb26605b6c07f1e" Archived-At: Subject: Re: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 17:33:02 -0000 --000000000000ccb26605b6c07f1e Content-Type: text/plain; charset="UTF-8" On Thu, Dec 17, 2020 at 2:50 AM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-tcpm-rack-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > I didn't manage to review the algorithm in detail (way outside my area), > but > surrounding text was clear, understandable and interesting for someone > without > TCP expertise, so thank you for that. > > One minor NIT would be the change the footer from "RACK" to "RACK-TLP". > Section 9.5 talks about using RACK for other protocols and I wanted to > confirm > that it does mean only RACK and not RACK-TLP for this case. > Thank you for your review. This is a good catch. QUIC does implement RACK-TLP not only RACK. We'll revise accordingly The over-abbreviated footer "RACK" will be removed and replaced by the RFCxxxx when published. > > Regards, > Rob > > > > --000000000000ccb26605b6c07f1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 17, 2020 at 2:50 AM Robert Wilton via= Datatracker <noreply@ietf.org&g= t; wrote:
Robert= Wilton has entered the following ballot position for
draft-ietf-tcpm-rack-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I didn't manage to review the algorithm in detail (way outside my area)= , but
surrounding text was clear, understandable and interesting for someone with= out
TCP expertise, so thank you for that.

One minor NIT would be the change the footer from "RACK" to "= ;RACK-TLP".

Section 9.5 talks about using RACK for other protocols and I wanted to conf= irm
that it does mean only RACK and not RACK-TLP for this case.
Thank you for your review. This is a good catch. QUIC does implement = RACK-TLP not only RACK. We'll revise accordingly

The over-abbreviated footer "RACK" will be removed and replace= d by the RFCxxxx when published.
=C2=A0

Regards,
Rob



--000000000000ccb26605b6c07f1e-- From nobody Fri Dec 18 09:54:35 2020 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 81B4B3A0B36 for ; Fri, 18 Dec 2020 09:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 BraWMO7LJyo1 for ; Fri, 18 Dec 2020 09:54:32 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 1E3223A0B44 for ; Fri, 18 Dec 2020 09:54:32 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id a12so3177707wrv.8 for ; Fri, 18 Dec 2020 09:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a31ofz8IC1XrX24PL8O/bBk8JnQacHjppCYj0rtKtgs=; b=EP3ysRXAIdsFi2ZwsT3/u+XGKR40FlzzF8sq39bsReb2IsKl/eWSuyCp6aVxjxzpLF mnh2dTAuGAhFYb6Htj1PuIQu5o0H1eM6RlVLHyKAwT4T7nLj389GQKYsVrQ0YMpILMAZ QyeoH63Pq3+RwborXGvWeN9f7CILqp4ygB2Lq8HC9Zivrb0MYRRMLH9B8oqS8+w7h3to FIEcyeonxsLZGAvTTTpVZ7FfCTTlAu0fd6goAqTZHmgTQnbjGdRppFeWXTdYDo3fF4Gd IESNqjN2xdVayvMlsWqK+wjByN5KusbGE58eEoaMpxbOJNxiTcyxBGboIO+VX5kWAFFY sAYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a31ofz8IC1XrX24PL8O/bBk8JnQacHjppCYj0rtKtgs=; b=CPYABY+aUHQGQSxutP1xLXgTA06bdHTrLqhIesKFYTyMr5wOMGAuSFUXX555sqz4Qz 4eA/V/KzRX5glWUzgF4wBHJzVlRX9hlt47cX3xU4LB7VlQ3knagBa7iy1yws477gO79I EJ1kXc9otF7sQMAJotfkTkP0vU6gASbjL+fvGziTSaUeB0XZVuqpyGxakMFECr0OS2rU ob8r/gHzvnlyHlvTKps+5bsou7HwJRIiVMXmeCG9irAHniJusSGVgo8yjEliztdX62F3 67seJXeWqVOqI64cRAI0ghQ16L5We4Ja9FThYp0QesC+2Jq+DZNTXvrUPqb3PhrPBRmz U8Tw== X-Gm-Message-State: AOAM533Dvt7Z53bJ5FRTCOwnrEgQmyPxQj3rSXS0uvMSOGFIIndcetDE mGTK5EGQsckc/R/kQq7GxmmgKNVvGXzQU2Mg7Jt3PA== X-Google-Smtp-Source: ABdhPJzY9KO3PTQwTJtjRyO3wuJeV++Z9fLyd8TWscyqUB2YUH19Tuz2JA6Ve25N71beSteTyZa8Jj0QJwrvHDSZn40= X-Received: by 2002:adf:ef06:: with SMTP id e6mr5638093wro.231.1608314070222; Fri, 18 Dec 2020 09:54:30 -0800 (PST) MIME-Version: 1.0 References: <160819163601.18444.15133884751875574217@ietfa.amsl.com> In-Reply-To: <160819163601.18444.15133884751875574217@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 09:53:52 -0800 Message-ID: To: Murray Kucherawy Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000d881fb05b6c0cc5c" Archived-At: Subject: Re: [tcpm] Murray Kucherawy's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 17:54:34 -0000 --000000000000d881fb05b6c0cc5c Content-Type: text/plain; charset="UTF-8" Thank you for your review. We'll expand the DUPACK on first use. The thought on the normative reference is nice. The document is related to but does not modify/update the two RFCs hence we think it's better to avoid confusion. i.e. readers of the other RFCs are not required to be aware of this draft. We will add more clarification text on the relation of the two RFCs in section 9.3 as well. On Wed, Dec 16, 2020 at 11:53 PM Murray Kucherawy via Datatracker < noreply@ietf.org> wrote: > Murray Kucherawy has entered the following ballot position for > draft-ietf-tcpm-rack-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this work. It's interesting stuff! > > Please expand DUPACK on first use. > Section 2 is curious. As I read it, it establishes a normative > recommendation > to use it, but doesn't update either of its antecedents (RFC 5681 or RFC > 6675) > such that someone reading those might be referred to this. > > > > --000000000000d881fb05b6c0cc5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your review. We'll expand the DUPAC= K on first use.

The thought on the normative refer= ence is nice. The document is related to but does not modify/update the two= RFCs hence we think it's better to avoid confusion. i.e. readers of th= e other RFCs are not required to be aware of this draft.=C2=A0 We will add = more clarification text on the relation of the two RFCs in section 9.3 as w= ell.

On Wed, Dec 16, 2020 at 11:53 PM Murray Kucherawy via Datat= racker <noreply@ietf.org> wro= te:
Murray Kuche= rawy has entered the following ballot position for
draft-ietf-tcpm-rack-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this work.=C2=A0 It's interesting stuff!

Please expand DUPACK on first use.

Section 2 is curious.=C2=A0 As I read it, it establishes a normative recomm= endation
to use it, but doesn't update either of its antecedents (RFC 5681 or RF= C 6675)
such that someone reading those might be referred to this.



--000000000000d881fb05b6c0cc5c-- From nobody Fri Dec 18 09:58:34 2020 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 535FD3A0B5A for ; Fri, 18 Dec 2020 09:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 XCXzMZYm0B78 for ; Fri, 18 Dec 2020 09:58:30 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 94CF93A0B32 for ; Fri, 18 Dec 2020 09:58:30 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id r4so3514810wmh.5 for ; Fri, 18 Dec 2020 09:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ETuW5ai4q30hRiXUWta0bDYkmPWgb5WzoB14SLj4sLQ=; b=nxkkNngvixIP0RAH+d09gbiW8LdtOKYZUzpI8Z6smsh5GZlGBkouXrozTxwptM3tQk /wApGUn9zFgWUJrICjC94IWcxV5i4EyNV8pF6ffJxxMvGLbRDkSnWzfM8xiQdmG3ZhZ2 3goek6z9fElmLcLtvT0TOubCTX1/h7l+tC0OjL/L7ohdklYn7k2+up4qomromCkyxHBp uhQUbq1YhVSawaak+Jykj7Pt36M1NY0WcSLKpP6rO4ydWShhbBnYcDC3nCbv9Xp18bTo RCM8F7VRySsw5eqWtz62FGVXmN/E9P5Y7D1XgYlUXE9JgNuk/cTtCdE1vQDP5JvWUIog Ng2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ETuW5ai4q30hRiXUWta0bDYkmPWgb5WzoB14SLj4sLQ=; b=tUtsaQD1RBFytrnBjwL4yVTzMW7BkWPNtWhvRCesd1LS9VzZkmPuk0Jn/Ez5uxGwH/ HZX7ZkgSCXvr4bHL8kJNJo7vNED8LjoOyqXutixGE9xpA68+l66s5RfgHsHDHHpXPXH1 FxxmaVv2/b9BCNoJUW7rO9dHWhAverPNlK+NOMiyC79GUpxvUWQLZ7KccNISFb992cAk TThftnl/Mvys0anTVXPJjGmaGIkr71VRWv3Ac3j3LZrcTBPcgDOZOiGezPI14PP20V3b BmlY8I2EBegJ9vgHHD4kNHuxlUELAYHxxXEifitjoM+BGbs4mj1UWBdwNFzkyMPCmP3c GeYg== X-Gm-Message-State: AOAM5309rPax9eLWxfUJu0+5+WAjL2GZ4/qyoeDJyXcVjaeUeEhu8uWH O8bMJQ2wDf49BdM3UMGvLSafjf/8IVt8HQokpXesPg== X-Google-Smtp-Source: ABdhPJyFEAXTVOG5wzV9F59AWpUq1qSCOby0nSWdSNISZ7aA8kH41VE4ibhn9yT3VONkxo282Of4vNuft1aPRKOnBjk= X-Received: by 2002:a1c:9d85:: with SMTP id g127mr5288678wme.118.1608314308934; Fri, 18 Dec 2020 09:58:28 -0800 (PST) MIME-Version: 1.0 References: <160818456961.27293.9184699786015901072@ietfa.amsl.com> In-Reply-To: <160818456961.27293.9184699786015901072@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 09:57:51 -0800 Message-ID: To: Erik Kline Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="00000000000012b47a05b6c0dbfd" Archived-At: Subject: Re: [tcpm] Erik Kline's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 17:58:32 -0000 --00000000000012b47a05b6c0dbfd Content-Type: text/plain; charset="UTF-8" Thank you for your review to improve the clarity. We'll revise accordingly "keeps", "a timestamp whose granularity is finer", "takes a longer time". On Wed, Dec 16, 2020 at 9:56 PM Erik Kline via Datatracker wrote: > Erik Kline has entered the following ballot position for > draft-ietf-tcpm-rack-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ nits ]] > > [ section 3.1 ] > > * "Conceptually, RACK puts a virtual timer for" > > Instead of "puts" perhaps "uses", "keeps", "imagines", or something? > > [ section 4 ] > > * "a timestamp whose granularity that is finer" -> > "a timestamp with a granularity that is finer", or > "a timestamp whose granularity is finer", perhaps > > [ section 9.4 ] > > * "sender takes longer time" -> "sender takes a longer time"? > > > > --00000000000012b47a05b6c0dbfd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for your review to improve the clarity. We&= #39;ll revise accordingly "keeps", "a timestamp whose granul= arity is finer", "takes a longer time".

On Wed, Dec 16, 2020= at 9:56 PM Erik Kline via Datatracker <noreply@ietf.org> wrote:
Erik Kline has entered the following ballot position fo= r
draft-ietf-tcpm-rack-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ nits ]]

[ section 3.1 ]

* "Conceptually, RACK puts a virtual timer for"

=C2=A0 Instead of "puts" perhaps "uses", "keeps&qu= ot;, "imagines", or something?

[ section 4 ]

* "a timestamp whose granularity that is finer" ->
=C2=A0 "a timestamp with a granularity that is finer",=C2=A0 or =C2=A0 "a timestamp whose granularity is finer", perhaps

[ section 9.4 ]

* "sender takes longer time" -> "sender takes a longer ti= me"?



--00000000000012b47a05b6c0dbfd-- From nobody Fri Dec 18 10:02:22 2020 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 F3CFA3A0B54 for ; Fri, 18 Dec 2020 10:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 KByMrQ_exmBB for ; Fri, 18 Dec 2020 10:02:13 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 089EA3A0B5B for ; Fri, 18 Dec 2020 10:02:12 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id g185so3538086wmf.3 for ; Fri, 18 Dec 2020 10:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ntQQH2wgBh4aX62S57dR32LK5HKehKVR4dZOiTqNPOY=; b=BTqKDucuBluvAJe/+GMVLxUPkC2HwlIXYQZNHTQST2e+6Wm957uLXSZEgzAv5ou6kP FsIyqxPiTsTEtMordl69BhDkRkJv2UootPDYGsK14bNUGti9FdkHuG2Gn4Vts7qPi4AF sY5OVNEPULJEnIplHU7f4f1QibHD9ismgAaJhX/71FCXH0YD9HDv98+LyB0jvg+AURdv y1ckVyorKKajdM5eWFJcNDU5srceTaKRY/fjOjodZXkx6BAQTXWKshm5GVbgpEqI/D4E mWaO0HP2FlmxpdOn5QtjXUI5VIQ8b0uQvurAYNjsgpEay4qXdf/yjIChrDuAEdnmlvm3 a5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ntQQH2wgBh4aX62S57dR32LK5HKehKVR4dZOiTqNPOY=; b=OXVIPfH/KDSaCixk9tdXJ5tRQzWTwnsZk19V91VEo/EKlNbNonKpkl1mcxfst8qjlv F1Q1s6hpw8w4zMZwAFimSKN+PlC1u7b3/HJNJiLnggIG/wTljeWGjEbhNblYDNI9yOv/ EcFgYbI7ZMImS2bkNhYPehITbjVexKs5cZrsQCYINesxThiS3ox+9kyrFrU5CZ30fPNz EASXW1snnbCxznigjFn3S0OHW1UWkUHWC38a7uHd2mjX3oIWblRd1X/33nHg1k2fjvh2 Mv0pCQZ33pUWV9ZbErlbiSOnl6YVwW8JHRj8t0dkHstXMQYD2xomiwboyHntsMWDqz1e RrKw== X-Gm-Message-State: AOAM530dUamPsXqt1ZJ39x/dvrHL/hcabGfuCmkOfFLZFTCy0Dgb90Dp YWiJ0u/9zn7qhgNdR7jarA+2Yto6r36KZFXgRHif0Q== X-Google-Smtp-Source: ABdhPJxHtHxlsJO1VIL/ts2sOwcL8uYZ6W1KwXRmN60k5Z/5ASnsq7HLJPHxNBBlbV80Jz8mQEKzemqms5FLqiShPa8= X-Received: by 2002:a1c:804a:: with SMTP id b71mr5323731wmd.21.1608314531197; Fri, 18 Dec 2020 10:02:11 -0800 (PST) MIME-Version: 1.0 References: <160818055846.21007.18172807717470668998@ietfa.amsl.com> In-Reply-To: <160818055846.21007.18172807717470668998@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 10:01:33 -0800 Message-ID: To: Barry Leiba Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="000000000000524b1505b6c0e825" Archived-At: Subject: Re: [tcpm] Barry Leiba's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 18:02:16 -0000 --000000000000524b1505b6c0e825 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 16, 2020 at 8:49 PM Barry Leiba via Datatracker < noreply@ietf.org> wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-tcpm-rack-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Just a very small comment: > > =E2=80=94 Section 1 =E2=80=94 > > In this document, these words will appear > with that interpretation only when in UPPER CASE. Lower case uses of > these words are not to be interpreted as carrying [RFC2119] > significance. > > I don=E2=80=99t particularly object to that quoted text, but it=E2=80=99s= redundant: the > (correct) BCP 14 boilerplate before it already says that. What=E2=80=99s= the > purpose > of adding this text? (I=E2=80=99m guessing it=E2=80=99s a remnant: it wa= s there with the > old > BCP 14 boilerplate frim 2119, and when you switched to 8174 you didn=E2= =80=99t > remove > this.) > We'll remove this redundant paragraph. Thanks for catching that! --000000000000524b1505b6c0e825 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 16, 2020 at 8:49 PM Barry= Leiba via Datatracker <noreply@ietf.org> wrote:
Barry Leiba has entered the following ballot position= for
draft-ietf-tcpm-rack-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Just a very small comment:

=E2=80=94 Section 1 =E2=80=94

=C2=A0 =C2=A0In this document, these words will appear
=C2=A0 =C2=A0with that interpretation only when in UPPER CASE.=C2=A0 Lower = case uses of
=C2=A0 =C2=A0these words are not to be interpreted as carrying [RFC2119] =C2=A0 =C2=A0significance.

I don=E2=80=99t particularly object to that quoted text, but it=E2=80=99s r= edundant: the
(correct) BCP 14 boilerplate before it already says that.=C2=A0 What=E2=80= =99s the purpose
of adding this text?=C2=A0 (I=E2=80=99m guessing it=E2=80=99s a remnant: it= was there with the old
BCP 14 boilerplate frim 2119, and when you switched to 8174 you didn=E2=80= =99t remove
this.)
We'll remove this redundant paragraph. Than= ks for catching that!

=C2=A0
--000000000000524b1505b6c0e825-- From nobody Fri Dec 18 10:03:22 2020 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 4AA073A0CE3 for ; Fri, 18 Dec 2020 10:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 pDa28N8zO0Wo for ; Fri, 18 Dec 2020 10:03:08 -0800 (PST) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 6D7EE3A0DBE for ; Fri, 18 Dec 2020 10:03:08 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id r4so3535303wmh.5 for ; Fri, 18 Dec 2020 10:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DdlP38A1EE/z1REJsscDR/JJtFKPCCRR6QtAQLglkh4=; b=Z6dn38rksorfuQXrYEu9V6LqoOl1uBxhs3ZgJhikW6c9WnaITf/eJeARNYW0GV38KO 2pLVgTryRGxCmNWZ8VJJfdsy8f6z+CM82RW9KItZK1+7X08LWk8EUedZa96qGLRIcV0M MBycduSzK0tMe9eii82A7W8JOtiBlZNuHQxLcUBmvcg9x98PViBgtKNxdnJbP0frsTD6 RUDNvo15bm+tGxXSBbkrFXkvwE0M1QUmiedknjzFw8NngB6B7etzxgvejIRRKVKq/B7J r0IoJV+HBwpQnWrAawrSA0txZqDW0Lwmnkb9k2CKf5jDchA/v8rPQg85G/3hqfUjUtbF SOmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DdlP38A1EE/z1REJsscDR/JJtFKPCCRR6QtAQLglkh4=; b=BYJE9HSe1CcqpBLnB1jNZFoGo0yIjbmP3GkCWYMVJH/RMRovSaLrMgDED3r1fWXNCt j9Njvcu0xzQo1VQ9EEv53reGwhefqK4LmwgfLRys/NpSo7vuKyMmdGwi5777JMnpCYfS 8Qj5USA3GWLWHs6qJeCivothNEiItIWBFQq9drp6AIn3vTG3ZmTbHvHy3rXcZzRWZ3L+ wJe0xry2Gduy67fWjxgAiLl8FNktU3WlxgFJeuKkGwOX1VyG6WQCOoytWwtFFFGioNIZ Z/vJSTTs1OZvK1P2+BlboCXNGtgA4GXhCKzDPTzonxbSWpaGTvaNVvUwBEVWRlF7zCSA HEiA== X-Gm-Message-State: AOAM530B7Np7WNWjelNB9NhlsDCuTMjLPEvEewjgnkRRlw/dGtN4z2gC KRmXo40x9l3JMyquHpBXsqwd0KPj81sCgjMIHHk3dw== X-Google-Smtp-Source: ABdhPJzOUVVIMtDlkq70A/IK19omes5p468rBeST6YuzTDvVwQVH625HyUm+ti0MNCnTcl1veAXt7h5nAnw98agiA94= X-Received: by 2002:a1c:7e4e:: with SMTP id z75mr5209843wmc.40.1608314586645; Fri, 18 Dec 2020 10:03:06 -0800 (PST) MIME-Version: 1.0 References: <160820918017.10062.4021553447453861559@ietfa.amsl.com> In-Reply-To: <160820918017.10062.4021553447453861559@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 10:02:29 -0800 Message-ID: To: Magnus Westerlund Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="000000000000a05ac405b6c0ebfa" Archived-At: Subject: Re: [tcpm] Magnus Westerlund's Yes on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 18:03:18 -0000 --000000000000a05ac405b6c0ebfa Content-Type: text/plain; charset="UTF-8" On Thu, Dec 17, 2020 at 4:46 AM Magnus Westerlund via Datatracker < noreply@ietf.org> wrote: > Magnus Westerlund has entered the following ballot position for > draft-ietf-tcpm-rack-14: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 1: > > In this document, these words will appear > with that interpretation only when in UPPER CASE. Lower case uses of > these words are not to be interpreted as carrying [RFC2119] > significance. > > This addition to the RFC 8174 boiler text appears redundant and can be > removed. > I assume it predates RFC 8174. > We'll remove this redundant text. Thanks for catching that! --000000000000a05ac405b6c0ebfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 17, 2020 at 4:46 AM Magnu= s Westerlund via Datatracker <norepl= y@ietf.org> wrote:
Magnus Westerlund has entered the following ballot position for<= br> draft-ietf-tcpm-rack-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1:

In this document, these words will appear
=C2=A0 =C2=A0with that interpretation only when in UPPER CASE.=C2=A0 Lower = case uses of
=C2=A0 =C2=A0these words are not to be interpreted as carrying [RFC2119] =C2=A0 =C2=A0significance.

This addition to the RFC 8174 boiler text appears redundant and can be remo= ved.
I assume it predates RFC 8174.
We'll remove this r= edundant=C2=A0text. Thanks for catching that!
=C2=A0
<= /div> --000000000000a05ac405b6c0ebfa-- From nobody Fri Dec 18 12:41:44 2020 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 68CCD3A0896; Fri, 18 Dec 2020 12:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 roxgbpYPuv0G; Fri, 18 Dec 2020 12:41:35 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE0E53A0880; Fri, 18 Dec 2020 12:41:32 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 18 Dec 2020 22:41:22 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=bI6ep3 2fcIzUZk2zpmAhtWE0d6jNHiTEnbG+ba1++kU=; b=b4ongEI2HZxHdYRZ9bz0nC Vbk3w+vJyMgOQMJrhG/KZP0Ni0hDmpszdqINFl0B4JL9Xm81oVnMOEE4WRRThkim w1wN38tTdFTvx7DrNXWTV/ai4QLX7mtxEYbLPancblhJVTjPbCU8hmh1349g2F11 mJlfAz2h8WE0Fy2JzBaCg= Received: from hp8x-60 (85-76-102-128-nat.elisa-mobile.fi [85.76.102.128]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Fri, 18 Dec 2020 22:41:22 +0200 id 00000000005A1477.000000005FDD13F2.00005454 Date: Fri, 18 Dec 2020 22:41:21 +0200 (EET) From: Markku Kojo To: Yuchung Cheng cc: Praveen Balasubramanian , "martin.h.duke@gmail.com" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-21614-1608324082-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call:(TheRACK-TLPlossdetectionalgorithmforTCP) toProposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 20:41:40 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-21614-1608324082-0001-2 Content-Type: text/plain; charset="iso-8859-15"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi, On Thu, 17 Dec 2020, Yuchung Cheng wrote: > How about > =A0 > "9.3.=A0 Interaction with congestion control >=20 > RACK-TLP intentionally decouples loss detection ...=A0 > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. PRR [RFCxxxx] is RECOMMENDED for the specificcongestio= n control actions taken > upon the losses detected by RACK-TLP" I believe you intend to add such a mention in Figure 1. So ACK for it. I think "... implementation of RFC6675 pipe algorithm may not directly account ..." is too mild expression, i.e., "may not" does not quite capture the=20 problem. The problem in my view is that RFC6675 algorithm simply breaks,=20 i.e., it possibly requires significant modification in many aspects, but=20 I cannot immediately say what all falls apart other than determining the=20 new value for cwnd & ssthresh with FlightSize and the pipe calculation.=20 Also, NextSeg () seemingly does not work for lost retransmissions, etc. I think the draft should say that RFC 6675 algorithm does not handle such=20 a second congestion response correctly. Therefore it MUST not be used but=20 a modified algorithm that carefully addresses such a case is needed. Unless I am not mistaken, PRR algorithm does not work without any=20 modification either (for reducing window again for a lost retransmission)= .=20 At least FlightSize cannot be used for deterniming new value for ssthresh=20 when a loss of a retransmission is detected in the middle of fast=20 recovery. I cannot tell for sure what else possibly breaks. If it is a=20 trivial change in PRR, I just don't see it immediately. But if it is, I=20 think it would be useful to explicitly point it out. Another important issue with detecting lost retransmissions is tracking=20 when this occurs. Currently RACK-TLP algorithm (pseudocode) detects a los= s=20 of a retransmitted segment in the same way as a loss of an original=20 transmission. In order to take an appropriate congestion response when th= e=20 loss of a retransmitted segment occurs, it would be good if the RACK-TLP=20 algorithm would track when this occurs and indicate it. In particular, I=20 think it would be very important when the congestion control actions are=20 in another document. Otherwise such a congestion control document would first need to modify=20 the RACK-TLP algorithm to add the necessary variables and actions. FYI: When we decoupled spurious retransmission detection and congestion=20 control response, the detection RFCs (EIFEL [RFC 3522] and F-RTO [RFC=20 5682] included the necessary variable for indicating that spurious=20 retransmission was detected and the algorithms set the variable. > To Makku's request for "what's the justification to enter fast recovery= ". Consider this example > w/o RACK-TLP >=20 > T0: Send 100 segments but application-limited. All are lost. > T-2RTT: app writes so another 3 segments are sent. Made to the destinat= ion and triggered 3 > DUPACKs > T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactio= ns to burst ~50 packets > with Reno=A0 >=20 > In this case any ACK occured before RTO is (generally) considered clock= -acked, and how=A0I > understand Van's initial design.=A0 This behavior existed decades befor= e RACK-TLP. RACK-TLP > essentially changes the "3-segments by app" to "1-segment by tcp".=A0 Ack, this kind of scenario is a problem with RFC 6675 loss detection and=20 recovery, but not with Reno loss recovery (RFC 5681) nor with Newreno=20 loss recovery (RFC 6582). Sure congestion control response for this scenario should be fixed with=20 RFC 6675. PRR is one such fix. But now we are discussing pure RFC 6675 (without PRR cc modification). My point is that we should not make things (congestion control behavior)=20 worse than in the current standard track algorithms even though there is=20 this problem with the current algorithm. I try to explain why I think=20 things may get worse if TLP probe is used to trigger fast recovery in=20 *all* scenarios where it detects a loss. So we compare RACK-TLP loss=20 detection to pure RFC 6675 DupAck detection when a TCP sender uses=20 standard RFC 6675 loss recovery and congestion control in both cases. (0) In the aforementioned scenario the same problem occurs also with RACK-TLP loss detection. No diffrence, both should be fixed/mitigated. Differences: (1) RFC 6675 has this burst problem only in the aforementioned scenario. RACK-TLP has also additional scenarios when this problem may occur: (a) Always when the sender is cwnd limited and the entire flight is lost. This case includes large transfers where cwnd is often large, resulting in large bursts. (b) Always when the sender is rwnd limited and the entire flight is lost. (c) Always when the sender remains application limited and the entire flight is lost. That is, when the sending application does not provide more data to send within a period of one RTO. This means that the burst problem is likely to occur more often with RACK-TLP because there are more occassions when a problematic scenario may emerge. This is an important difference that is likely to create more congestion with RACK-TLP detection than with DupAck-based detection, if TLP-detected loss always invokes fast recovery without necessary safeguards in the fast recovery algorithm (2) A combined effect of entering fast recovery when the entire flight is lost and capability to detect lost retransmissions: Important to note first: if there was severe congestion that continues it is likely that some (many) segments are dropped from the burst of retransmitted segments. In this case: RFC 6675 sender (re)transmits more segments ack-clocked at most for one RTT at half of the previous rate and then waits until RTO expires --> cwnd=3D1 RACK-TLP sender continues (re)transmitting segments ack-clocked at the half of the previous rate maybe for *several RTTs* until all segments repaired or RTO expires. If all losses are repaired and RACK-TLP does not take another congestion response when a lost retransmission is detected, it continues all the way without further cwnd reduction. Thereby RACK-TLP sender would be significantly more aggessive that RFC 6675 sender. If RACK-TLP takes another congestion response when a lost retransmission is detected, it is still more aggressive but much more reasonable as it halves cwnd again. (3) Maybe not that important: Three DupAcks provide some ack clocking feedback that can be used to mitigate pure RFC 6675 behavior. For example, the sender may derive the ack clock from these three DupAcks and use it to clock out the retransmissions (e.g., using at least doubled spacing compared to what is inferfed from DupAcks). Segment offloading (GRO) may interfere though? A single DupAck for RACK-TLP does not provide any ack clock information for this purposes. Best regards, /Markku > On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian wrote: > > I agree that we should have a note in this RFC about congestion c= ontrol action upon > detecting lost retransmission(s). > > =A0 > > From: tcpm On Behalf Of Martin Duke > Sent: Thursday, December 17, 2020 7:30 AM > To: Markku Kojo > Cc: tcpm@ietf.org Extensions ; draft-ietf-tcpm-rac= k@ietf.org; Michael > Tuexen ; draft-ietf-tcpm-rack.all@ietf.org= ; Last Call > ; tcpm-chairs > Subject: [EXTERNAL] Re: [tcpm] Last Call: > (TheRACK-TLPlossdetectionalgorithmfo= rTCP) to Proposed > Standard >=20 > =A0 >=20 > Hi Markku, >=20 > =A0 >=20 > Thanks, now I understand your objections. >=20 > =A0 >=20 > Martin >=20 > =A0 >=20 > On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo wrot= e: > > Hi, > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > I spent a little longer looking at the specs more carefully, an= d I explained > (1) > > incorrectly in my last two messages. P21..29 are not Limited Tr= ansmit > packets.=A0 > > Correct. Just normal the rule that allows sending new data during = fast > recovery. > > > However, unless I'm missing something else, 6675 is clear that = the recovery > period > > does not end until the cumulative ack advances, meaning that de= tecting the > lost > > retransmission of P1 does not trigger another MD directly. > > As I have said earlier, RFC 6675 does not repeat all congestion c= ontrol > principles from RFC 5681. It definitely honors the CC principle t= hat > requires to treat a loss of a retransmission as a new congestion > indication and another MD. I believe I am obligated to know this = as a > co-author of RFC 6675. ;) > > RFC 6675 explicitly indicates that it follows RFC 5681 by stating = in the > abstract: > > " ... conforms to the spirit of the current congestion control > =A0 specification (RFC 5681 ..." > > And in the intro: > > =A0 =A0"The algorithm specified in this document is a straightfor= ward > =A0 =A0 SACK-based loss recovery strategy that follows the=A0 gui= delines > =A0 =A0 set in [RFC5681] ..." > > I don't think there is anything unclear in this. > > RFC 6675 and all other standard congestion controls (RFC 5581 and = RFC > 6582) handle a loss of a retransmission by "enforcing" RTO to det= ect it. > And RTO guarantees MD. RACK-TLP changes the loss detection in thi= s case > and therefore the standard congestion control algorithms do not h= ave > actions to handle it corrrectly. That is the point. > > BR, > > /Markku > > > Thanks for this exercise! It's refreshed my memory of these det= ails after > working > > on slightly different QUIC algorithms a long time. > > > > On Wed, Dec 16, 2020, 18:55 Martin Duke wrote: > > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > > >=A0 =A0 =A0 =A0 (4.2) ssthresh =3D cwnd =3D (FlightSize / 2) > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 The congestion window (cwnd) and slo= w start threshold > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 (ssthresh) are reduced to half of Fl= ightSize per [RFC5681]. > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 Additionally, note that [RFC5681] re= quires that any > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 segments sent as part of the Limited = Transmit mechanism not > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 be counted in FlightSize for the pur= pose of the above > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 equation. > > > > IIUC the segments P21..P29 in your example were sent because of = Limited > > Transmit, and so don't count. The flightsize for the purposes o= f (4.2) is > > therefore 20 after both losses, and the cwnd does not go up on = the second > > loss. > > > > (2) > > " Even a single shot burst every time there is significant loss > > event is not acceptable, not to mention continuous aggressivene= ss, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address a= nd warn > > about." > > > > "Significant loss event" is the key phrase here. The intent of = TLP/PTO is to > > equalize the treatment of a small packet loss whether it happen= ed in the > > middle of a burst or the end. Why should an isolated loss be tr= eated > > differently based on its position in the burst? This is just a = logical > > extension of fast retransmit, which also modified the RTO parad= igm. The > > working group consensus is that this is a feature, not a bug; y= ou're welcome > > to feel otherwise but I suspect you're in the rough here. > > > > Regards > > Martin > > > > > > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo wrote: > >=A0 =A0 =A0 =A0Hi Martin, > > > >=A0 =A0 =A0 =A0See inline. > > > >=A0 =A0 =A0 =A0On Wed, 16 Dec 2020, Martin Duke wrote: > > > >=A0 =A0 =A0 =A0> Hi Markku, > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> There is a ton here, but I'll try to address th= e top points. > >=A0 =A0 =A0 =A0Hopefully > >=A0 =A0 =A0 =A0> they obviate the rest. > > > >=A0 =A0 =A0 =A0Sorry for being verbose. I tried to be clear but = you actually > >=A0 =A0 =A0 =A0removed my > >=A0 =A0 =A0 =A0key issues/questions ;) > > > >=A0 =A0 =A0 =A0> 1. > >=A0 =A0 =A0 =A0> [Markku] > >=A0 =A0 =A0 =A0> "Hmm, not sure what you mean by "this is a new = loss detection > >=A0 =A0 =A0 =A0after > >=A0 =A0 =A0 =A0> acknowledgment of new data"? > >=A0 =A0 =A0 =A0> But anyway, RFC 5681 gives the general principl= e to reduce > >=A0 =A0 =A0 =A0cwnd and > >=A0 =A0 =A0 =A0> ssthresh twice if a retransmission is lost but = IMHO (and I > >=A0 =A0 =A0 =A0believe many > >=A0 =A0 =A0 =A0> who have designed new loss recovery and CC algo= rithms or > >=A0 =A0 =A0 =A0implemented > >=A0 =A0 =A0 =A0> them > >=A0 =A0 =A0 =A0> agree) that it is hard to get things right if o= nly congestion > >=A0 =A0 =A0 =A0control > >=A0 =A0 =A0 =A0> principles are available and no algorithm." > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> [Martin] > >=A0 =A0 =A0 =A0> So 6675 Sec 5 is quite explicit that there is o= nly one cwnd > >=A0 =A0 =A0 =A0reduction > >=A0 =A0 =A0 =A0> per fast recovery episode, which ends once new = data has been > >=A0 =A0 =A0 =A0> acknowledged. > > > >=A0 =A0 =A0 =A0To be more precise: fast recovery ends when the c= urrent window > >=A0 =A0 =A0 =A0becomes > >=A0 =A0 =A0 =A0cumulatively acknowledged, that is, > > > >=A0 =A0 =A0 =A0(4.1) RecoveryPoint (=3D HighData at the beginnin= g) becomes > >=A0 =A0 =A0 =A0acknowledged > > > >=A0 =A0 =A0 =A0I believe we agree and you meant this although ne= w data below > >=A0 =A0 =A0 =A0RecoveryPoint may become cumulatively acknowledge= d already > >=A0 =A0 =A0 =A0earlier > >=A0 =A0 =A0 =A0during the fast recovery. Reno loss recovery in R= FC 5681 ends, > >=A0 =A0 =A0 =A0when > >=A0 =A0 =A0 =A0(any) new data has been acknowledged. > > > >=A0 =A0 =A0 =A0> By definition, if a retransmission is lost it i= s because > >=A0 =A0 =A0 =A0> newer data has been acknowledged, so it's a new = recovery > >=A0 =A0 =A0 =A0episode. > > > >=A0 =A0 =A0 =A0Not sure where you have this definition? Newer th= an what are you > >=A0 =A0 =A0 =A0referring to? > > > >=A0 =A0 =A0 =A0But, yes, if a retransmission is lost with RFC 66= 75 algorithm, > >=A0 =A0 =A0 =A0it requires RTO to be detected and definitely sta= rts a new > >=A0 =A0 =A0 =A0recovery > >=A0 =A0 =A0 =A0episode. That is, a new recovery episode is enfor= ced by step > >=A0 =A0 =A0 =A0(1.a) of > >=A0 =A0 =A0 =A0NextSeg () which prevents retransmission if a seg= ment that has > >=A0 =A0 =A0 =A0already > >=A0 =A0 =A0 =A0been retransmitted. If RACK-TLP is used for detec= ting loss with > >=A0 =A0 =A0 =A0RFC 6675 > >=A0 =A0 =A0 =A0things get different in many ways, because it may = detect loss of > >=A0 =A0 =A0 =A0a > >=A0 =A0 =A0 =A0retransmission. It would pretty much require an e= ntire redesign > >=A0 =A0 =A0 =A0of the algorith. For example, calculation of pipe = does not > >=A0 =A0 =A0 =A0consider > >=A0 =A0 =A0 =A0segments that have been retransmitted more than o= nce. > > > >=A0 =A0 =A0 =A0> Meanwhile, during the Fast Recovery period the = incoming acks > >=A0 =A0 =A0 =A0implicitly > >=A0 =A0 =A0 =A0> remove data from the network and therefore keep = flightsize > >=A0 =A0 =A0 =A0low. > > > >=A0 =A0 =A0 =A0Incorrect. FlightSize !=3D pipe. Only cumulative = acks remove data > >=A0 =A0 =A0 =A0from > >=A0 =A0 =A0 =A0FlightSize and new data transmitted during fast r= ecovery inflate > >=A0 =A0 =A0 =A0FlightSize. How FlightSize evolves depends on los= s pattern as I > >=A0 =A0 =A0 =A0said. > >=A0 =A0 =A0 =A0It is also possible that FlightSize is low, it ma= y err in both > >=A0 =A0 =A0 =A0directions. A simple example can be used as a pro= of for the case > >=A0 =A0 =A0 =A0where > >=A0 =A0 =A0 =A0cwnd increases if a loss of retransmission is det= ected and > >=A0 =A0 =A0 =A0repaired: > > > >=A0 =A0 =A0 =A0RFC 6675 recovery with RACK-TLP loss detection: > >=A0 =A0 =A0 =A0(contains some inaccuracies because it has not be= en defined how > >=A0 =A0 =A0 =A0lost rexmits are calculated into pipe) > > > >=A0 =A0 =A0 =A0cwnd=3D20; packets P1,...,P20 in flight =3D curre= nt window of data > >=A0 =A0 =A0 =A0[P1 dropped and rexmit of P1 will also be dropped= ] > > > >=A0 =A0 =A0 =A0DupAck w/SACK for P2 arrives > >=A0 =A0 =A0 =A0[loss of P1 detected after one RTT from original = xmit of P1] > >=A0 =A0 =A0 =A0[cwnd=3Dssthresh=3D10] > >=A0 =A0 =A0 =A0P1 is rexmitted (and it logically starts next win= dow of data) > > > >=A0 =A0 =A0 =A0DupAcks w/ SACK for original P3..11 arrive > >=A0 =A0 =A0 =A0DupAck w/ SACK for original P12 arrives > >=A0 =A0 =A0 =A0[cwnd-pipe =3D 10-9 >=3D1] > >=A0 =A0 =A0 =A0send P21 > >=A0 =A0 =A0 =A0DupAck w/SACK for P13 arrives > >=A0 =A0 =A0 =A0send P22 > >=A0 =A0 =A0 =A0... > >=A0 =A0 =A0 =A0DupAck w/SACK for P20 arrives > >=A0 =A0 =A0 =A0send P29 > >=A0 =A0 =A0 =A0[FlightSize=3D29] > > > >=A0 =A0 =A0 =A0(Ack for rexmit of P1 would arrive here unless it = got dropped) > > > >=A0 =A0 =A0 =A0DupAck w/SACK for P21 arrives > >=A0 =A0 =A0 =A0[loss of rexmit P1 detected after one RTT from re= xmit of P1] > > > >=A0 =A0 =A0 =A0SET cwnd =3D ssthresh =3D FlightSize/2=3D 29/2 =3D = 14,5 > > > >=A0 =A0 =A0 =A0CWND INCREASES when it should be at most 5 after = halving it > >=A0 =A0 =A0 =A0twice!!! > > > >=A0 =A0 =A0 =A0> We can continue to go around on our interpretat= ion of these > >=A0 =A0 =A0 =A0documents, > >=A0 =A0 =A0 =A0> but fundamentally if there is ambiguity in 5681= /6675 we should > >=A0 =A0 =A0 =A0bis > >=A0 =A0 =A0 =A0> those RFCs rather than expand the scope of RACK= . > > > >=A0 =A0 =A0 =A0As I said earlier, I am not opposing bis, though = 5681bis wuold > >=A0 =A0 =A0 =A0not > >=A0 =A0 =A0 =A0be needed, I think. > > > >=A0 =A0 =A0 =A0But let me repeat: if we publish RACK-TLP now wit= hout necessary > >=A0 =A0 =A0 =A0warnings > >=A0 =A0 =A0 =A0or with a correct congesion control algorithm som= eone will try > >=A0 =A0 =A0 =A0to > >=A0 =A0 =A0 =A0implement RACK-TLP with RFC 6675 and it will be a = total mesh. > >=A0 =A0 =A0 =A0The > >=A0 =A0 =A0 =A0behavior will be unpredictable and quite likely u= nsafe > >=A0 =A0 =A0 =A0congestion > >=A0 =A0 =A0 =A0control behavior. > > > >=A0 =A0 =A0 =A0> 2. > >=A0 =A0 =A0 =A0> [Markku] > >=A0 =A0 =A0 =A0> " In short: > >=A0 =A0 =A0 =A0> When with a non-RACK-TLP implementation timer (= RTO) expires: > >=A0 =A0 =A0 =A0cwnd=3D1 > >=A0 =A0 =A0 =A0> MSS, > >=A0 =A0 =A0 =A0> and slow start is entered. > >=A0 =A0 =A0 =A0> When with a RACK_TLP implementation timer (PTO) = expires, > >=A0 =A0 =A0 =A0> normal fast recovery is entered (unless impleme= nting > >=A0 =A0 =A0 =A0> also PRR). So no RTO recovery as explicitly sta= ted in Sec. > >=A0 =A0 =A0 =A07.4.1." > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> [Martin] > >=A0 =A0 =A0 =A0> There may be a misunderstanding here. PTO is no= t the same as > >=A0 =A0 =A0 =A0RTO, and > >=A0 =A0 =A0 =A0> both mechanisms exist! The loss response to a P= TO is to send a > >=A0 =A0 =A0 =A0probe; > >=A0 =A0 =A0 =A0> the RTO response is as with conventional TCP. I= n Section 7.3: > > > >=A0 =A0 =A0 =A0No, I don't think I misunderstood. If you call ti= meout with > >=A0 =A0 =A0 =A0another name, it is still timeout. And congestion = control does > >=A0 =A0 =A0 =A0not > >=A0 =A0 =A0 =A0consider which segments to send (SND.UNA vs. prob= e w/ higher > >=A0 =A0 =A0 =A0sequence > >=A0 =A0 =A0 =A0number), only how much is sent. > > > >=A0 =A0 =A0 =A0You ignored my major point where I decoupled cong= estion control > >=A0 =A0 =A0 =A0from loss > >=A0 =A0 =A0 =A0detection and loss recovery and compared RFC 5681 = behavior to > >=A0 =A0 =A0 =A0RACK-TLP > >=A0 =A0 =A0 =A0behavior in exactly the same scenario where an en= tire flight is > >=A0 =A0 =A0 =A0lost and > >=A0 =A0 =A0 =A0timer expires. > > > >=A0 =A0 =A0 =A0Please comment why congestion control behavior is = allowed to be > >=A0 =A0 =A0 =A0radically > >=A0 =A0 =A0 =A0different in these two implementations? > > > >=A0 =A0 =A0 =A0RFC 5681 & RFC 6298 timeout: > > > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0 RTO=3DSRTT+4*RTTVAR (RTO used for = arming the timer) > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. RTO timer expires > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. cwnd=3D1 MSS; ssthresh=3DFlight= Size/2; rexmit one segment > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of rexmit sent in step 2 ar= rives > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D cwnd+1 MSS; send two s= egments > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0... > > > >=A0 =A0 =A0 =A0RACK-TLP timeout: > > > >=A0 =A0 =A0 =A0=A0 =A0 =A0=A0 =A0PTO=3Dmin(2*SRTT,RTO) (PTO used = for arming the timer) > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. PTO times expires > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. (cwnd=3D1 MSS); (re)xmit one se= gment > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of (re)xmit sent in srep 2 = arrives > >=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D ssthresh =3D FlightSiz= e/2; send N=3Dcwnd segments > > > >=A0 =A0 =A0 =A0If FlightSize is 100 segments when timer expires, = congestion > >=A0 =A0 =A0 =A0control is > >=A0 =A0 =A0 =A0the same in steps 1-3, but in step 4 the standard = congestion > >=A0 =A0 =A0 =A0control > >=A0 =A0 =A0 =A0allows transmitting 2 segments, while RACK-TLP wo= uld allow > >=A0 =A0 =A0 =A0blasting 50 segments. > > > >=A0 =A0 =A0 =A0> After attempting to send a loss probe, regardle= ss of whether a > >=A0 =A0 =A0 =A0loss > >=A0 =A0 =A0 =A0>=A0 =A0 probe was sent, the sender MUST re-arm t= he RTO timer, not > >=A0 =A0 =A0 =A0the PTO > >=A0 =A0 =A0 =A0>=A0 =A0 timer, if FlightSize is not zero.=A0 Thi= s ensures RTO > >=A0 =A0 =A0 =A0recovery remains > >=A0 =A0 =A0 =A0>=A0 =A0 the last resort if TLP fails. > >=A0 =A0 =A0 =A0> " > > > >=A0 =A0 =A0 =A0This does not prevent the above RACK-TLP behavior = from getting > >=A0 =A0 =A0 =A0realized. > > > >=A0 =A0 =A0 =A0> So a pure RTO response exists in the case of pe= rsistent > >=A0 =A0 =A0 =A0congestion that > >=A0 =A0 =A0 =A0> causes losses of probes or their ACKs. > > > >=A0 =A0 =A0 =A0Yes, RTO response exists BUT only after RACK-TLP = at least once > >=A0 =A0 =A0 =A0blasts the > >=A0 =A0 =A0 =A0network. It may well be that with smaller windows = RACK-TLP is > >=A0 =A0 =A0 =A0successful > >=A0 =A0 =A0 =A0during its TLP initiated overly aggressive "fast = recovery" and > >=A0 =A0 =A0 =A0never > >=A0 =A0 =A0 =A0enters RTO recovery because it may detect and rep= air also loss > >=A0 =A0 =A0 =A0of > >=A0 =A0 =A0 =A0rexmits. That is, it continues at too high rate e= ven if lost > >=A0 =A0 =A0 =A0rexmits > >=A0 =A0 =A0 =A0indicate that congestion persists in successive w= indows of data. > >=A0 =A0 =A0 =A0And > >=A0 =A0 =A0 =A0worse, it is successful because it pushes away ot= her compatible > >=A0 =A0 =A0 =A0TCP > >=A0 =A0 =A0 =A0flows by being too aggressive and unfair. > > > >=A0 =A0 =A0 =A0Even a single shot burst every time there is sign= ificant loss > >=A0 =A0 =A0 =A0event is not acceptable, not to mention continuou= s > >=A0 =A0 =A0 =A0aggressiveness, and > >=A0 =A0 =A0 =A0this is exactly what RFC 2914 and RFC 5033 explic= itly address > >=A0 =A0 =A0 =A0and warn > >=A0 =A0 =A0 =A0about. > > > >=A0 =A0 =A0 =A0Are we ignoring these BCPs that have IETF consens= us? > > > >=A0 =A0 =A0 =A0And the other important question I'd like to have = an answer: > > > >=A0 =A0 =A0 =A0What is the justification to modify standard TCP = congestion > >=A0 =A0 =A0 =A0control to > >=A0 =A0 =A0 =A0use fast recovery instead of slow start for a cas= e where timeout > >=A0 =A0 =A0 =A0is > >=A0 =A0 =A0 =A0needed to detect the packet losses because there = is no feedback > >=A0 =A0 =A0 =A0and ack > >=A0 =A0 =A0 =A0clock is lost? RACK-TLP explicitly instructs to d= o so in Sec. > >=A0 =A0 =A0 =A07.4.1. > > > >=A0 =A0 =A0 =A0As I noted: based on what is written in the draft = it does not > >=A0 =A0 =A0 =A0intend to > >=A0 =A0 =A0 =A0change congestion control but effectively it does= . > > > >=A0 =A0 =A0 =A0/Markku > > > >=A0 =A0 =A0 =A0> Martin > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> On Wed, Dec 16, 2020 at 11:39 AM Markku Kojo > >=A0 =A0 =A0 =A0 > >=A0 =A0 =A0 =A0> wrote: > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Hi Martin, > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0On Tue, 15 Dec 2020, Martin Duke = wrote: > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> Hi Markku, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> Thanks for the comments. The au= thors will incorporate > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0many of your > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> suggestions after the IESG revi= ew. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> There's one thing I don't under= stand in your comments: > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> " That is, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> where can an implementer find a= dvice for correct > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion control > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> actions with RACK-TLP, when: > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> (1) a loss of rexmitted segment = is detected > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> (2) an entire flight of data ge= ts dropped (and > >=A0 =A0 =A0 =A0detected), > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> =A0 =A0 =A0that is, when there = is no feedback available and > >=A0 =A0 =A0 =A0a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0timeout > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> =A0 =A0 =A0is needed to detect = the loss " > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> Section 9.3 is the discussion a= bout CC, and is clear > >=A0 =A0 =A0 =A0that > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> implementer should use either 5= 681 or 6937. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Just a cite nit: RFC 5681 provide= s basic CC concepts and > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0some useful CC > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0guidelines but given that RACK-TL= P MUST implement SACK > >=A0 =A0 =A0 =A0the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0algorithm in > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0RFC 5681 is not that useful and a= n implementer quite > >=A0 =A0 =A0 =A0likely > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0follows > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0mainly the algorithm in RFC 6675 = (and not RFC 6937 at > >=A0 =A0 =A0 =A0all > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0if not > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0implementing PRR). > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0And RFC 6675 is not mentioned in = Sec 9.3, though it is > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0listed in the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Sec. 4 (Requirements). > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> You went through the 6937 case = in detail. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Yes, but without correct CC actio= ns. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> If 5681, it's pretty clear to m= e that in (1) this is a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0new loss > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> detection after acknowledgment = of new data, and > >=A0 =A0 =A0 =A0therefore > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0requires a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> second halving of cwnd. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Hmm, not sure what you mean by "t= his is a new loss > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0detection after > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0acknowledgment of new data"? > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0But anyway, RFC 5681 gives the ge= neral principle to > >=A0 =A0 =A0 =A0reduce > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0cwnd and > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0ssthresh twice if a retransmissio= n is lost but IMHO (and > >=A0 =A0 =A0 =A0I > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0believe many > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0who have designed new loss recove= ry and CC algorithms or > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0implemented them > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0agree) that it is hard to get thi= ngs right if only > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion control > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0principles are available and no a= lgorithm. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0That's why ALL mechanisms that we = have include a quite > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0detailed algorithm > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0with all necessary variables and = actions for loss > >=A0 =A0 =A0 =A0recovery > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0and/or CC > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0purposes (and often also pseudoco= de). Like this document > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0does for loss > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0detection. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0So the problem is that we do not = have a detailed enough > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0algorithm or > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0rule that tells exactly what to d= o when a loss of rexmit > >=A0 =A0 =A0 =A0is > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0detected. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Even worse, the algorithms in RFC = 5681 and RFC 6675 > >=A0 =A0 =A0 =A0refer > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0to > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0equation (4) of RFC 5681 to reduc= e ssthresh and cwnd > >=A0 =A0 =A0 =A0when a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0loss > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0requiring a congestion control ac= tion is detected: > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 (cwnd =3D) ssthresh =3D Fligh= tSize / 2) > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0And RFC 5681 gives a warning not = to halve cwnd in the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0equation but > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0FlightSize. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0That is, this equation is what an = implementer > >=A0 =A0 =A0 =A0intuitively > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0would use > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0when reading the relevant RFCs bu= t it gives a wrong > >=A0 =A0 =A0 =A0result > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0for > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0outstanding data when in fast rec= overy (when the sender > >=A0 =A0 =A0 =A0is > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0in > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion avoidance and the equa= tion (4) is used to > >=A0 =A0 =A0 =A0halve > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0cwnd, it > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0gives a correct result). > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0More precisely, during fast recov= ery FlightSize is > >=A0 =A0 =A0 =A0inflated > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0when new > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0data is sent and reduced when seg= ments are cumulatively > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Acked. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0What the outcome is depends on th= e loss pattern. In the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0worst case, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0FlightSize is signficantly larger = than in the beginning > >=A0 =A0 =A0 =A0of > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0the fast > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0recovery when FlightSize was (cor= rectly) used to > >=A0 =A0 =A0 =A0determine > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0the halved > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0value for cwnd and ssthresh, i.e.= , equation (4) may > >=A0 =A0 =A0 =A0result > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0in > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0*increasing* cwnd upon detecting = a loss of a rexmitted > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0segment, instead > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0of further halving it. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0A clever implementer might have n= o problem to have it > >=A0 =A0 =A0 =A0right > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0with some > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0thinking but I am afraid that the= re will be incorrect > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0implementations > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0with what is currently specified. = Not all implementers > >=A0 =A0 =A0 =A0have > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0spent > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0signicicant fraction of their car= eer in solving TCP > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0peculiarities. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> For (2), the RTO timer is still = operative so > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> the RTO recovery rules would st= ill follow. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0In short: > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0When with a non-RACK-TLP implemen= tation timer (RTO) > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0expires: cwnd=3D1 MSS, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0and slow start is entered. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0When with a RACK_TLP implementati= on timer (PTO) expires, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0normal fast recovery is entered (= unless implementing > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0also PRR). So no RTO recovery as = explicitly stated in > >=A0 =A0 =A0 =A0Sec. > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A07.4.1. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0This means that this document exp= licitly modifies > >=A0 =A0 =A0 =A0standard > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0TCP congestion > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0control when there are no acks co= ming and the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0retransmission timer > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0expires > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0from: RTO=3DSRTT+4*RTTVAR (RTO us= ed for arming the timer) > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. RTO timer expir= es > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. cwnd=3D1 MSS; s= sthresh=3DFlightSize/2; rexmit one > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0segment > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of rexmit s= ent in step 2 arrives > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D cwnd+1 = MSS; send two segments > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A0... > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0to:=A0 =A0PTO=3Dmin(2*SRTT,RTO) (= PRO used for arming the > >=A0 =A0 =A0 =A0timer) > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A01. PTO times expir= es > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A02. (cwnd=3D1 MSS); = (re)xmit one segment > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A03. Ack of (re)xmit = sent in srep 2 arrives > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0 =A0 =A04. cwnd =3D ssthre= sh =3D FlightSize/2; send N=3Dcwnd > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0segments > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0For example, if FlightSize is 100 = segments when timer > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0expires, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion control is the same in = steps 1-3, but in step > >=A0 =A0 =A0 =A04 > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0current standard congestion contr= ol allows transmitting > >=A0 =A0 =A0 =A02 > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0segments, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0while RACK-TLP would allow blasti= ng 50 segments. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Question is: what is the justific= ation to modify > >=A0 =A0 =A0 =A0standard > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0TCP > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion control to use fast re= covery instead of slow > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0start for a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0case where timeout is needed to d= etect loss because > >=A0 =A0 =A0 =A0there > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0is no > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0feedback and ack clock is lost? T= he draft does not give > >=A0 =A0 =A0 =A0any > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0justification. This clearly is in = conflict with items > >=A0 =A0 =A0 =A0(0) > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0and (1) > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0in BCP 133 (RFC 5033). > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Furthermore, there is no implemen= tation nor experimental > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0experience > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0evaluating this change. The imple= mentation with > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0experimental experience > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0uses PRR (RFC 6937) which is an E= xperimental > >=A0 =A0 =A0 =A0specification > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0including a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0novel "trick" that directs PRR fa= st recovery to > >=A0 =A0 =A0 =A0effectively > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0use slow > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0start in this case at hand. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> In other words, I am not seeing = a case that requires > >=A0 =A0 =A0 =A0new > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0congestion > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> control concepts except as disc= ussed in 9.3. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0See above. The change in standard = congestion control for > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0(2). > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0The draft intends not to change c= ongestion control but > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0effectively it > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0does without any operational evid= ence. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0What's also is missing and would = be very useful: > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0- For (1), a hint for an implemen= ter saying that because > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0RACK-TLP is > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0able to detect a loss of a = rexmit unlike any other > >=A0 =A0 =A0 =A0loss > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0detection > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0algorithm, the sender MUST = react twice to congestion > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0(and cite > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0RFC 5681). And cite a docu= ment where necessary > >=A0 =A0 =A0 =A0correct > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0actions > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0are described. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0- For (1), advise that an impleme= nter needs to keep > >=A0 =A0 =A0 =A0track > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0when it > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0detects a loss of a retran= smitted segment. Current > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0algorithms > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0in the draft detect a loss = of retransmitted segment > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0exactly in > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0the same way as loss of an= y other segment. There > >=A0 =A0 =A0 =A0seems > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0to be > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0nothing to track when a re= transmission of a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0retransmitted segment > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0takes place. Therefore, th= e algorithms should have > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0additional > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0actions to correctly track = when such a loss is > >=A0 =A0 =A0 =A0detected. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0- For (1), discussion on how many = times a loss of a > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0retransmission > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0of the same segment may oc= cur and be detected. Seems > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0that it > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0may be possible to drop a = rexmitted segment more than > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0once and > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0detect it also several tim= es?=A0 What are the > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0implications? > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0- If previous is possible, then t= he algorithm possibly > >=A0 =A0 =A0 =A0also > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0may detect a loss of a new = segment that was sent > >=A0 =A0 =A0 =A0during > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0fast > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0recovery? This is also los= s in two successive windows > >=A0 =A0 =A0 =A0of > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0data, > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0and cwnd MUST be lowered t= wice. This discussion and > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0necessary > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0=A0 =A0actions to track it are mi= ssing, if such scenario is > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0possible. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0> What am I missing? > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0Hope the above helps. > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0>=A0 =A0 =A0 =A0/Markku > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > >=A0 =A0 =A0 =A0> > > > > > > >=20 >=20 > --=_script-21614-1608324082-0001-2-- From nobody Fri Dec 18 13:32:02 2020 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 65CBD3A0809; Fri, 18 Dec 2020 13:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 X9P-X7UFwkHl; Fri, 18 Dec 2020 13:31:57 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DBF13A0803; Fri, 18 Dec 2020 13:31:55 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 18 Dec 2020 23:31:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=BtN5NxxB+ptGZkMzu 7P4HeV+PmIUMzCcbmkKcuKbAZk=; b=kLWS3MWVYqRiwIZVtOtnG+Nm9oQfTuhqf nzagvcdXci+usu0kndkPI31AXc/g1Oi5PeA2h7fV5umkJaQvbPLYjmsRudYowSxG 6WcggKvxaLsm3QdDoIyxI2+WB/dSuKMItrpZ1UmL6bmgwX8o+vT2Q/2uRywYxJ/A C6gH7RdJZ0= Received: from hp8x-60 (85-76-102-128-nat.elisa-mobile.fi [85.76.102.128]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Fri, 18 Dec 2020 23:31:50 +0200 id 00000000005A1477.000000005FDD1FC6.000038EE Date: Fri, 18 Dec 2020 23:31:49 +0200 (EET) From: Markku Kojo To: Praveen Balasubramanian cc: "ycheng@google.com" , "martin.h.duke@gmail.com" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-14601-1608327110-0001-2" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Last Call:(TheRACK-TLPlossdetectionalgorithmforTCP) toProposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 21:32:02 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-14601-1608327110-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On Fri, 18 Dec 2020, Praveen Balasubramanian wrote: >=20 > Looks good to me. I would omit =E2=80=9C, but some other congestion con= trol may want to respond > multiple times differently=E2=80=9D. Agreed to omit. The lost retransmissions of segments that were first=20 retransmitted during the same RTT are considered to be in the same window=20 of data, so it is enough to react once per RTT. Current standard congestion controls that are able to recover from=20 multiple losses per window may however take several RTTs to recover. NewReno takes 1 RTT per lost segment. RFC 6675 ideally requires just one=20 RTT but depending on the loss pattern the recovery in practice often take= s=20 several RTTs if there is a significant number of losses in one window of=20 data. RACK makes detection more efficient than DupAck-based detection, so=20 it is more likely that less RTTs are need with RACK, I believe. Anyway, any upcoming congestion control spec should carefully consider=20 how to handle the case where several lost rexmits were detected and they=20 were sent in different RTTs. The congestion control principle is that the=20 sender should react once per each subsequent RTT (window) in which a loss=20 is detected. This would make things much more complicated though. Best regards, /Markku > From: Yuchung Cheng > Sent: Thursday, December 17, 2020 2:55 PM > To: Martin Duke > Cc: Praveen Balasubramanian ; kojo@cs.helsinki.fi; = tcpm@ietf.org; > draft-ietf-tcpm-rack@ietf.org; tuexen@fh-muenster.de; draft-ietf-tcpm-r= ack.all@ietf.org; > last-call@ietf.org; tcpm-chairs@ietf.org > Subject: Re: [EXTERNAL] Re: [tcpm] Last Call: > (TheRACK-TLPlossdetectionalgorithmforTCP) = to Proposed Standard >=20 > =C2=A0 >=20 > =C2=A0 >=20 > =C2=A0 >=20 > On Thu, Dec 17, 2020 at 1:59 PM Martin Duke w= rote: > > This is good, thanks. > > =C2=A0 >=20 > I might also add the sentence "In the absence of PRR, when TCP RACK det= ects a lost > retransmission it MUST trigger a second congestion response" or somethi= ng to that > effect. What do you think? >=20 > Sure I'd revise a bit to be even more detailed and consistent with the = principle in RFC5681 >=20 > =C2=A0 >=20 > "In the absence=C2=A0of PRR, when RACK-TLP detects a lost retransmissio= n the congestion control > MUST trigger an additional congestion response per the aforementioned p= rinciple in RFC5681. >=20 > If multiple retransmissions were lost in a window, the congestion contr= ol specified in > RFC5681 only reacts once per window, but some other congestion control = may want to respond > multiple times differently. The congestion control implementer is advis= ed to > carefully=C2=A0consider this subtle situation." >=20 > =C2=A0 >=20 > =C2=A0 > > =C2=A0 > > On Thu, Dec 17, 2020 at 11:36 AM Yuchung Cheng wrote: > > How about >=20 > =C2=A0 >=20 > "9.3.=C2=A0 Interaction with congestion control >=20 >=20 > RACK-TLP intentionally decouples loss detection ...=C2=A0 > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. PRR [RFCxxxx] is RECOMMENDED for the specific >=20 > congestion control actions taken upon the losses detected by RACK-TLP" >=20 > =C2=A0 >=20 > =C2=A0 >=20 > To Makku's request for "what's the justification to enter fast recovery= ". > Consider this example w/o RACK-TLP >=20 > =C2=A0 >=20 > T0: Send 100 segments but application-limited. All are lost. >=20 > T-2RTT: app writes so another 3 segments are sent. Made to the destinat= ion and > triggered 3 DUPACKs >=20 > T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactio= ns to > burst ~50 packets with Reno=C2=A0 >=20 > =C2=A0 >=20 > In this case any ACK occured before RTO is (generally) considered clock= -acked, > and how=C2=A0I understand Van's initial design.=C2=A0 This behavior exi= sted decades before > RACK-TLP. RACK-TLP essentially changes the "3-segments by app" to "1-se= gment by > tcp".=C2=A0 >=20 > =C2=A0 >=20 > On Thu, Dec 17, 2020 at 10:52 AM Praveen Balasubramanian > wrote: > > I agree that we should have a note in this RFC about congestion > control action upon detecting lost retransmission(s). > > =C2=A0 > > From: tcpm On Behalf Of Martin Duke > Sent: Thursday, December 17, 2020 7:30 AM > To: Markku Kojo > Cc: tcpm@ietf.org Extensions ; > draft-ietf-tcpm-rack@ietf.org; Michael Tuexen > ; draft-ietf-tcpm-rack.all@ietf.org; Last = Call > ; tcpm-chairs > Subject: [EXTERNAL] Re: [tcpm] Last Call: > (TheRACK-TLPlossdetectionalgorithmfo= rTCP) > to Proposed Standard >=20 > =C2=A0 >=20 > Hi Markku, >=20 > =C2=A0 >=20 > Thanks, now I understand your objections. >=20 > =C2=A0 >=20 > Martin >=20 > =C2=A0 >=20 > On Thu, Dec 17, 2020 at 12:46 AM Markku Kojo wrot= e: > > Hi, > > On Wed, 16 Dec 2020, Martin Duke wrote: > > > I spent a little longer looking at the specs more carefully, > and I explained (1) > > incorrectly in my last two messages. P21..29 are not Limited > Transmit packets.=C2=A0 > > Correct. Just normal the rule that allows sending new data > during fast > recovery. > > > However, unless I'm missing something else, 6675 is clear > that the recovery period > > does not end until the cumulative ack advances, meaning that > detecting the lost > > retransmission of P1 does not trigger another MD directly. > > As I have said earlier, RFC 6675 does not repeat all congestion > control > principles from RFC 5681. It definitely honors the CC principle > that > requires to treat a loss of a retransmission as a new > congestion > indication and another MD. I believe I am obligated to know > this as a > co-author of RFC 6675. ;) > > RFC 6675 explicitly indicates that it follows RFC 5681 by > stating in the > abstract: > > " ... conforms to the spirit of the current congestion control > =C2=A0 specification (RFC 5681 ..." > > And in the intro: > > =C2=A0 =C2=A0"The algorithm specified in this document is a > straightforward > =C2=A0 =C2=A0 SACK-based loss recovery strategy that follows the=C2= =A0 > guidelines > =C2=A0 =C2=A0 set in [RFC5681] ..." > > I don't think there is anything unclear in this. > > RFC 6675 and all other standard congestion controls (RFC 5581 > and RFC > 6582) handle a loss of a retransmission by "enforcing" RTO to > detect it. > And RTO guarantees MD. RACK-TLP changes the loss detection in > this case > and therefore the standard congestion control algorithms do not > have > actions to handle it corrrectly. That is the point. > > BR, > > /Markku > > > Thanks for this exercise! It's refreshed my memory of these > details after working > > on slightly different QUIC algorithms a long time. > > > > On Wed, Dec 16, 2020, 18:55 Martin Duke > wrote: > > (1) Flightsize: in RFC 6675. Section 5, Step 4.2: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 (4.2) ssthresh =3D cwnd =3D (FlightS= ize / 2) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The congestion = window (cwnd) and slow start > threshold > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ssthresh) are = reduced to half of FlightSize per > [RFC5681]. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Additionally, n= ote that [RFC5681] requires that > any > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 segments sent a= s part of the Limited Transmit > mechanism not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be counted in F= lightSize for the purpose of the > above > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 equation. > > > > IIUC the segments P21..P29 in your example were sent because > of Limited > > Transmit, and so don't count. The flightsize for the purposes > of (4.2) is > > therefore 20 after both losses, and the cwnd does not go up > on the second > > loss. > > > > (2) > > " Even a single shot burst every time there is significant > loss > > event is not acceptable, not to mention continuous > aggressiveness, and > > this is exactly what RFC 2914 and RFC 5033 explicitly address > and warn > > about." > > > > "Significant loss event" is the key phrase here. The intent > of TLP/PTO is to > > equalize the treatment of a small packet loss whether it > happened in the > > middle of a burst or the end. Why should an isolated loss be > treated > > differently based on its position in the burst? This is just > a logical > > extension of fast retransmit, which also modified the RTO > paradigm. The > > working group consensus is that this is a feature, not a bug; > you're welcome > > to feel otherwise but I suspect you're in the rough here. > > > > Regards > > Martin > > > > > > On Wed, Dec 16, 2020 at 4:11 PM Markku Kojo > wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin, > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0See inline. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0On Wed, 16 Dec 2020, Martin Duke wrot= e: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Markku, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> There is a ton here, but I'll try t= o address the top > points. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Hopefully > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> they obviate the rest. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Sorry for being verbose. I tried to b= e clear but you > actually > >=C2=A0 =C2=A0 =C2=A0 =C2=A0removed my > >=C2=A0 =C2=A0 =C2=A0 =C2=A0key issues/questions ;) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> 1. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> "Hmm, not sure what you mean by "th= is is a new loss > detection > >=C2=A0 =C2=A0 =C2=A0 =C2=A0after > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledgment of new data"? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> But anyway, RFC 5681 gives the gene= ral principle to > reduce > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> ssthresh twice if a retransmission = is lost but IMHO > (and I > >=C2=A0 =C2=A0 =C2=A0 =C2=A0believe many > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> who have designed new loss recovery = and CC algorithms > or > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implemented > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> them > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> agree) that it is hard to get thing= s right if only > congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> principles are available and no alg= orithm." > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> So 6675 Sec 5 is quite explicit tha= t there is only > one cwnd > >=C2=A0 =C2=A0 =C2=A0 =C2=A0reduction > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> per fast recovery episode, which en= ds once new data > has been > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> acknowledged. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0To be more precise: fast recovery end= s when the current > window > >=C2=A0 =C2=A0 =C2=A0 =C2=A0becomes > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cumulatively acknowledged, that is, > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(4.1) RecoveryPoint (=3D HighData at = the beginning) > becomes > >=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowledged > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0I believe we agree and you meant this = although new data > below > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RecoveryPoint may become cumulatively = acknowledged > already > >=C2=A0 =C2=A0 =C2=A0 =C2=A0earlier > >=C2=A0 =C2=A0 =C2=A0 =C2=A0during the fast recovery. Reno loss r= ecovery in RFC > 5681 ends, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(any) new data has been acknowledged. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> By definition, if a retransmission = is lost it is > because > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> newer data has been acknowledged, s= o it's a new > recovery > >=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Not sure where you have this definiti= on? Newer than > what are you > >=C2=A0 =C2=A0 =C2=A0 =C2=A0referring to? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0But, yes, if a retransmission is lost = with RFC 6675 > algorithm, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0it requires RTO to be detected and de= finitely starts a > new > >=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery > >=C2=A0 =C2=A0 =C2=A0 =C2=A0episode. That is, a new recovery epis= ode is enforced by > step > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(1.a) of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0NextSeg () which prevents retransmiss= ion if a segment > that has > >=C2=A0 =C2=A0 =C2=A0 =C2=A0already > >=C2=A0 =C2=A0 =C2=A0 =C2=A0been retransmitted. If RACK-TLP is us= ed for detecting > loss with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0things get different in many ways, be= cause it may > detect loss of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmission. It would pretty much = require an entire > redesign > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of the algorith. For example, calcula= tion of pipe does > not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0consider > >=C2=A0 =C2=A0 =C2=A0 =C2=A0segments that have been retransmitted = more than once. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Meanwhile, during the Fast Recovery = period the > incoming acks > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implicitly > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> remove data from the network and th= erefore keep > flightsize > >=C2=A0 =C2=A0 =C2=A0 =C2=A0low. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Incorrect. FlightSize !=3D pipe. Only = cumulative acks > remove data > >=C2=A0 =C2=A0 =C2=A0 =C2=A0from > >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize and new data transmitted d= uring fast > recovery inflate > >=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSize. How FlightSize evolves de= pends on loss > pattern as I > >=C2=A0 =C2=A0 =C2=A0 =C2=A0said. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0It is also possible that FlightSize i= s low, it may err > in both > >=C2=A0 =C2=A0 =C2=A0 =C2=A0directions. A simple example can be u= sed as a proof for > the case > >=C2=A0 =C2=A0 =C2=A0 =C2=A0where > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd increases if a loss of retransmi= ssion is detected > and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0repaired: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 6675 recovery with RACK-TLP loss = detection: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(contains some inaccuracies because i= t has not been > defined how > >=C2=A0 =C2=A0 =C2=A0 =C2=A0lost rexmits are calculated into pipe= ) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D20; packets P1,...,P20 in flig= ht =3D current window > of data > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[P1 dropped and rexmit of P1 will als= o be dropped] > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of P1 detected after one RTT fr= om original xmit > of P1] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd=3Dssthresh=3D10] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0P1 is rexmitted (and it logically sta= rts next window of > data) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAcks w/ SACK for original P3..11 a= rrive > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/ SACK for original P12 arriv= es > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[cwnd-pipe =3D 10-9 >=3D1] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0send P21 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P13 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0send P22 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0... > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P20 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0send P29 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[FlightSize=3D29] > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(Ack for rexmit of P1 would arrive he= re unless it got > dropped) > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0DupAck w/SACK for P21 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0[loss of rexmit P1 detected after one = RTT from rexmit > of P1] > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0SET cwnd =3D ssthresh =3D FlightSize/= 2=3D 29/2 =3D 14,5 > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0CWND INCREASES when it should be at m= ost 5 after > halving it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0twice!!! > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> We can continue to go around on our = interpretation of > these > >=C2=A0 =C2=A0 =C2=A0 =C2=A0documents, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> but fundamentally if there is ambig= uity in 5681/6675 > we should > >=C2=A0 =C2=A0 =C2=A0 =C2=A0bis > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> those RFCs rather than expand the s= cope of RACK. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0As I said earlier, I am not opposing = bis, though > 5681bis wuold > >=C2=A0 =C2=A0 =C2=A0 =C2=A0not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0be needed, I think. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0But let me repeat: if we publish RACK= -TLP now without > necessary > >=C2=A0 =C2=A0 =C2=A0 =C2=A0warnings > >=C2=A0 =C2=A0 =C2=A0 =C2=A0or with a correct congesion control a= lgorithm someone > will try > >=C2=A0 =C2=A0 =C2=A0 =C2=A0to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0implement RACK-TLP with RFC 6675 and = it will be a total > mesh. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0The > >=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior will be unpredictable and qu= ite likely unsafe > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control behavior. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> 2. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Markku] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> " In short: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a non-RACK-TLP implementa= tion timer (RTO) > expires: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd=3D1 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> MSS, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> and slow start is entered. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> When with a RACK_TLP implementation = timer (PTO) > expires, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> normal fast recovery is entered (un= less implementing > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> also PRR). So no RTO recovery as ex= plicitly stated in > Sec. > >=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1." > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> [Martin] > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> There may be a misunderstanding her= e. PTO is not the > same as > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RTO, and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> both mechanisms exist! The loss res= ponse to a PTO is > to send a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0probe; > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO response is as with convent= ional TCP. In > Section 7.3: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0No, I don't think I misunderstood. If = you call timeout > with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0another name, it is still timeout. An= d congestion > control does > >=C2=A0 =C2=A0 =C2=A0 =C2=A0not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0consider which segments to send (SND.= UNA vs. probe w/ > higher > >=C2=A0 =C2=A0 =C2=A0 =C2=A0sequence > >=C2=A0 =C2=A0 =C2=A0 =C2=A0number), only how much is sent. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0You ignored my major point where I de= coupled congestion > control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0from loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detection and loss recovery and compa= red RFC 5681 > behavior to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0behavior in exactly the same scenario = where an entire > flight is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0lost and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0timer expires. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Please comment why congestion control = behavior is > allowed to be > >=C2=A0 =C2=A0 =C2=A0 =C2=A0radically > >=C2=A0 =C2=A0 =C2=A0 =C2=A0different in these two implementation= s? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 & RFC 6298 timeout: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 RTO=3DSRT= T+4*RTTVAR (RTO used for arming the > timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. RTO tim= er expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. cwnd=3D= 1 MSS; ssthresh=3DFlightSize/2; rexmit one > segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = rexmit sent in step 2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = cwnd+1 MSS; send two segments > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0... > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP timeout: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0PTO=3D= min(2*SRTT,RTO) (PTO used for arming the > timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A01. PTO tim= es expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A02. (cwnd=3D= 1 MSS); (re)xmit one segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A03. Ack of = (re)xmit sent in srep 2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A04. cwnd =3D = ssthresh =3D FlightSize/2; send N=3Dcwnd > segments > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0If FlightSize is 100 segments when ti= mer expires, > congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the same in steps 1-3, but in step 4 = the standard > congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0allows transmitting 2 segments, while = RACK-TLP would > allow > >=C2=A0 =C2=A0 =C2=A0 =C2=A0blasting 50 segments. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> After attempting to send a loss pro= be, regardless of > whether a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 probe was sent, the se= nder MUST re-arm the RTO > timer, not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the PTO > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 timer, if FlightSize i= s not zero.=C2=A0 This ensures > RTO > >=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery remains > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 the last resort if TLP = fails. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> " > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0This does not prevent the above RACK-= TLP behavior from > getting > >=C2=A0 =C2=A0 =C2=A0 =C2=A0realized. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> So a pure RTO response exists in th= e case of > persistent > >=C2=A0 =C2=A0 =C2=A0 =C2=A0congestion that > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> causes losses of probes or their AC= Ks. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, RTO response exists BUT only aft= er RACK-TLP at > least once > >=C2=A0 =C2=A0 =C2=A0 =C2=A0blasts the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0network. It may well be that with sma= ller windows > RACK-TLP is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0successful > >=C2=A0 =C2=A0 =C2=A0 =C2=A0during its TLP initiated overly aggre= ssive "fast > recovery" and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0never > >=C2=A0 =C2=A0 =C2=A0 =C2=A0enters RTO recovery because it may de= tect and repair > also loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits. That is, it continues at too = high rate even if > lost > >=C2=A0 =C2=A0 =C2=A0 =C2=A0rexmits > >=C2=A0 =C2=A0 =C2=A0 =C2=A0indicate that congestion persists in = successive windows > of data. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0And > >=C2=A0 =C2=A0 =C2=A0 =C2=A0worse, it is successful because it pu= shes away other > compatible > >=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0flows by being too aggressive and unf= air. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Even a single shot burst every time t= here is > significant loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0event is not acceptable, not to menti= on continuous > >=C2=A0 =C2=A0 =C2=A0 =C2=A0aggressiveness, and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0this is exactly what RFC 2914 and RFC = 5033 explicitly > address > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and warn > >=C2=A0 =C2=A0 =C2=A0 =C2=A0about. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Are we ignoring these BCPs that have = IETF consensus? > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0And the other important question I'd = like to have an > answer: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0What is the justification to modify s= tandard TCP > congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0control to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0use fast recovery instead of slow sta= rt for a case > where timeout > >=C2=A0 =C2=A0 =C2=A0 =C2=A0is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0needed to detect the packet losses be= cause there is no > feedback > >=C2=A0 =C2=A0 =C2=A0 =C2=A0and ack > >=C2=A0 =C2=A0 =C2=A0 =C2=A0clock is lost? RACK-TLP explicitly in= structs to do so > in Sec. > >=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0As I noted: based on what is written = in the draft it > does not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0intend to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0change congestion control but effecti= vely it does. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> Martin > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> On Wed, Dec 16, 2020 at 11:39 AM Ma= rkku Kojo > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Martin= , > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0On Tue, 1= 5 Dec 2020, Martin Duke wrote: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Mark= ku, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Thanks = for the comments. The authors will > incorporate > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0many of y= our > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> suggest= ions after the IESG review. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> There's = one thing I don't understand in your > comments: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> " That = is, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> where c= an an implementer find advice for > correct > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> actions = with RACK-TLP, when: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (1) a l= oss of rexmitted segment is detected > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> (2) an = entire flight of data gets dropped > (and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detected), > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0that is, when there is no feedback > available and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0timeout > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0 = =C2=A0 =C2=A0is needed to detect the loss " > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> Section = 9.3 is the discussion about CC, and > is clear > >=C2=A0 =C2=A0 =C2=A0 =C2=A0that > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> impleme= nter should use either 5681 or 6937. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Just a ci= te nit: RFC 5681 provides basic CC > concepts and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0some usef= ul CC > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0guideline= s but given that RACK-TLP MUST > implement SACK > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm = in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 5681 = is not that useful and an implementer > quite > >=C2=A0 =C2=A0 =C2=A0 =C2=A0likely > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0follows > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0mainly th= e algorithm in RFC 6675 (and not RFC > 6937 at > >=C2=A0 =C2=A0 =C2=A0 =C2=A0all > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0if not > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement= ing PRR). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 6= 675 is not mentioned in Sec 9.3, > though it is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0listed in = the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. 4 (R= equirements). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> You wen= t through the 6937 case in detail. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, but = without correct CC actions. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> If 5681= , it's pretty clear to me that in (1) > this is a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0new loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> detecti= on after acknowledgment of new data, > and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requires = a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> second = halving of cwnd. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hmm, not = sure what you mean by "this is a new > loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection = after > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0acknowled= gment of new data"? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0But anywa= y, RFC 5681 gives the general > principle to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0reduce > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0ssthresh = twice if a retransmission is lost but > IMHO (and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0I > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0believe m= any > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0who have = designed new loss recovery and CC > algorithms or > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement= ed them > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0agree) th= at it is hard to get things right if > only > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n control > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0principle= s are available and no algorithm. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That's wh= y ALL mechanisms that we have include > a quite > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detailed = algorithm > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with all = necessary variables and actions for > loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and/or CC > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0purposes = (and often also pseudocode). Like this > document > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does for = loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection= . > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0So the pr= oblem is that we do not have a > detailed enough > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm = or > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0rule that = tells exactly what to do when a loss > of rexmit > >=C2=A0 =C2=A0 =C2=A0 =C2=A0is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detected. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Even wors= e, the algorithms in RFC 5681 and RFC > 6675 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0refer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation = (4) of RFC 5681 to reduce ssthresh and > cwnd > >=C2=A0 =C2=A0 =C2=A0 =C2=A0when a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0requiring = a congestion control action is > detected: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 (c= wnd =3D) ssthresh =3D FlightSize / 2) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0And RFC 5= 681 gives a warning not to halve cwnd > in the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0equation = but > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSiz= e. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0That is, = this equation is what an implementer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0intuitively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0would use > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when read= ing the relevant RFCs but it gives a > wrong > >=C2=A0 =C2=A0 =C2=A0 =C2=A0result > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0for > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0outstandi= ng data when in fast recovery (when > the sender > >=C2=A0 =C2=A0 =C2=A0 =C2=A0is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n avoidance and the equation (4) is > used to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0halve > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0cwnd, it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0gives a c= orrect result). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0More prec= isely, during fast recovery FlightSize > is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0inflated > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when new > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data is s= ent and reduced when segments are > cumulatively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Acked. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What the = outcome is depends on the loss > pattern. In the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0worst cas= e, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0FlightSiz= e is signficantly larger than in the > beginning > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the fast > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0recovery = when FlightSize was (correctly) used > to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0determine > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the halve= d > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0value for = cwnd and ssthresh, i.e., equation (4) > may > >=C2=A0 =C2=A0 =C2=A0 =C2=A0result > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0*increasi= ng* cwnd upon detecting a loss of a > rexmitted > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment, = instead > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0of furthe= r halving it. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0A clever = implementer might have no problem to > have it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0right > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with some > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0thinking = but I am afraid that there will be > incorrect > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implement= ations > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0with what = is currently specified. Not all > implementers > >=C2=A0 =C2=A0 =C2=A0 =C2=A0have > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0spent > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0signicica= nt fraction of their career in solving > TCP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0peculiari= ties. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> For (2)= , the RTO timer is still operative so > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> the RTO = recovery rules would still follow. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0In short: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with = a non-RACK-TLP implementation timer > (RTO) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires: = cwnd=3D1 MSS, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and slow = start is entered. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0When with = a RACK_TLP implementation timer (PTO) > expires, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0normal fa= st recovery is entered (unless > implementing > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0also PRR)= . So no RTO recovery as explicitly > stated in > >=C2=A0 =C2=A0 =C2=A0 =C2=A0Sec. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A07.4.1. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0This mean= s that this document explicitly > modifies > >=C2=A0 =C2=A0 =C2=A0 =C2=A0standard > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP conge= stion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0control w= hen there are no acks coming and the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmi= ssion timer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0from: RTO= =3DSRTT+4*RTTVAR (RTO used for arming > the timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A01. RTO timer expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; > rexmit one > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A03. Ack of rexmit sent in step 2 arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A04. cwnd =3D cwnd+1 MSS; send two segments > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0... > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to:=C2=A0 = =C2=A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming > the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0timer) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A01. PTO times expires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A02. (cwnd=3D1 MSS); (re)xmit one segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A03. Ack of (re)xmit sent in srep 2 > arrives > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A04. cwnd =3D ssthresh =3D FlightSize/2; send > N=3Dcwnd > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0For examp= le, if FlightSize is 100 segments when > timer > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0expires, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n control is the same in steps 1-3, > but in step > >=C2=A0 =C2=A0 =C2=A0 =C2=A04 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0current s= tandard congestion control allows > transmitting > >=C2=A0 =C2=A0 =C2=A0 =C2=A02 > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0segments, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0while RAC= K-TLP would allow blasting 50 > segments. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Question = is: what is the justification to > modify > >=C2=A0 =C2=A0 =C2=A0 =C2=A0standard > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0TCP > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n control to use fast recovery instead > of slow > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start for = a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0case wher= e timeout is needed to detect loss > because > >=C2=A0 =C2=A0 =C2=A0 =C2=A0there > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0is no > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0feedback = and ack clock is lost? The draft does > not give > >=C2=A0 =C2=A0 =C2=A0 =C2=A0any > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0justifica= tion. This clearly is in conflict with > items > >=C2=A0 =C2=A0 =C2=A0 =C2=A0(0) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0and (1) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0in BCP 13= 3 (RFC 5033). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Furthermo= re, there is no implementation nor > experimental > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experienc= e > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0evaluatin= g this change. The implementation with > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0experimen= tal experience > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses PRR = (RFC 6937) which is an Experimental > >=C2=A0 =C2=A0 =C2=A0 =C2=A0specification > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0including = a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0novel "tr= ick" that directs PRR fast recovery to > >=C2=A0 =C2=A0 =C2=A0 =C2=A0effectively > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0use slow > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0start in = this case at hand. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> In othe= r words, I am not seeing a case that > requires > >=C2=A0 =C2=A0 =C2=A0 =C2=A0new > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0congestio= n > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> control = concepts except as discussed in 9.3. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0See above= . The change in standard congestion > control for > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(2). > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0The draft = intends not to change congestion > control but > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0effective= ly it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0does with= out any operational evidence. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0What's al= so is missing and would be very > useful: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1)= , a hint for an implementer saying > that because > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0RACK-TLP = is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0able to detect a loss of a rexmit unlike any > other > >=C2=A0 =C2=A0 =C2=A0 =C2=A0loss > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0detection > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0algorithm, the sender MUST react twice to > congestion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0(and cite > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0RFC 5681). And cite a document where > necessary > >=C2=A0 =C2=A0 =C2=A0 =C2=A0correct > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0actions > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0are described. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1)= , advise that an implementer needs to > keep > >=C2=A0 =C2=A0 =C2=A0 =C2=A0track > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0when it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0detects a loss of a retransmitted segment. > Current > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0algorithm= s > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0in the draft detect a loss of retransmitted > segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0exactly i= n > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0the same way as loss of any other segment. > There > >=C2=A0 =C2=A0 =C2=A0 =C2=A0seems > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0to be > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0nothing to track when a retransmission of a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmi= tted segment > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0takes place. Therefore, the algorithms > should have > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0additiona= l > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0actions to correctly track when such a loss > is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0detected. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- For (1)= , discussion on how many times a loss > of a > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0retransmi= ssion > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0of the same segment may occur and be > detected. Seems > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0that it > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0may be possible to drop a rexmitted segment > more than > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0once and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0detect it also several times?=C2=A0 What are the > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0implicati= ons? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0- If prev= ious is possible, then the algorithm > possibly > >=C2=A0 =C2=A0 =C2=A0 =C2=A0also > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0may detect a loss of a new segment that was > sent > >=C2=A0 =C2=A0 =C2=A0 =C2=A0during > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0fast > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0recovery? This is also loss in two > successive windows > >=C2=A0 =C2=A0 =C2=A0 =C2=A0of > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0data, > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0and cwnd MUST be lowered twice. This > discussion and > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0necessary > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2= =A0actions to track it are missing, if such > scenario is > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0possible. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0> What am = I missing? > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hope the = above helps. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0/Markku > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0> > > > > > > >=20 >=20 > --=_script-14601-1608327110-0001-2-- From nobody Fri Dec 18 16:41:41 2020 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 1DCA73A09AD; Fri, 18 Dec 2020 16:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 O-frcK9GVPYS; Fri, 18 Dec 2020 16:41:37 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F223A0965; Fri, 18 Dec 2020 16:41:36 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Sat, 19 Dec 2020 02:41:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=cRuHZo vc6WA4jOlc0E8Ui+MRYuPqUk9vu2PRLc4kyhA=; b=T3nw6lJFGLw7wSNE/OQ0ma obupN9uQrTkdVe9lahDOXbkJ05/Ga00ptHS1YKskR0f/WsevOP2+n4cj12KVwjNJ Cf4rIwQcxyXwiobzBf0Atd3UXZTQm5KyibasCDJerMMBYZ3sAF9I2724DA9n3pIx yShEeOz/ajdbIZQ1HvrAQ= Received: from hp8x-60 (85-76-102-128-nat.elisa-mobile.fi [85.76.102.128]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Sat, 19 Dec 2020 02:41:32 +0200 id 00000000005A0403.000000005FDD4C3C.000017F2 Date: Sat, 19 Dec 2020 02:41:31 +0200 (EET) From: Markku Kojo To: Neal Cardwell cc: Martin Duke , Yuchung Cheng , Last Call , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack@ietf.org, Michael Tuexen , draft-ietf-tcpm-rack.all@ietf.org, tcpm-chairs In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-6294-1608338492-0001-2" Content-ID: Archived-At: Subject: Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmfor TCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 00:41:40 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-6294-1608338492-0001-2 Content-Type: text/plain; charset="iso-8859-15"; format=flowed Content-Transfer-Encoding: quoted-printable Content-ID: Hi Neal, On Fri, 18 Dec 2020, Neal Cardwell wrote: >=20 >=20 > On Wed, Dec 16, 2020 at 2:39 PM Markku Kojo wrote= : > > For (2), the RTO timer is still operative so > > the RTO recovery rules would still follow. > > In short: > When with a non-RACK-TLP implementation timer (RTO) expires: cwnd= =3D1 MSS, > and slow start is entered. > When with a RACK_TLP implementation timer (PTO) expires, > normal fast recovery is entered (unless implementing > also PRR). So no RTO recovery as explicitly stated in Sec. 7.4.1. > > This means that this document explicitly modifies standard TCP co= ngestion > control when there are no acks coming and the retransmission time= r > expires > > from: RTO=3DSRTT+4*RTTVAR (RTO used for arming the timer) >=20 > It's also worth mentioning this aspect of [RFC6298]: Sure. > =A0 =A0(2.4) Whenever RTO is computed, if it is less than 1 second, the= n the > =A0 =A0 =A0 =A0 =A0RTO SHOULD be rounded up to 1 second. > =A0 > =A0 =A0 =A0 =A01. RTO timer expires > =A0 =A0 =A0 =A02. cwnd=3D1 MSS; ssthresh=3DFlightSize/2; rexmit o= ne segment > =A0 =A0 =A0 =A03. Ack of rexmit sent in step 2 arrives > =A0 =A0 =A0 =A04. cwnd =3D cwnd+1 MSS; send two segments > =A0 =A0 =A0 =A0... > > to:=A0 =A0PTO=3Dmin(2*SRTT,RTO) (PRO used for arming the timer) > =A0 =A0 =A0 =A01. PTO times expires > =A0 =A0 =A0 =A02. (cwnd=3D1 MSS); (re)xmit one segment >=20 >=20 > It may be worthwhile to point out here that the RACK-TLP draft does not = specify setting cwnd > to 1 at this point, and the Linux TCP implementation from our team does = not do this. The Yes, that's why I put it in parenthesis. In my view the RACK-TLP=20 draft implicitly limits cwnd to one segment by allowing just one TLP=20 probe segment. > rationale is that at this point there is no solid evidence that anythin= g has been lost, and > setting cwnd to 1 at this point would make the algorithm more timid tha= n the preceding > approaches, for no good reason. Sure, no need to set cwnd at this point. A good reason could be: No feedback, Ack clock lost? But, of course,=20 it is too early even though after the arrival of ack the sender may well=20 modify cwnd again. Like it now does, if it decides it was loss other than=20 probe segment. =A0 > =A0 =A0 =A0 =A03. Ack of (re)xmit sent in srep 2 arrives > =A0 =A0 =A0 =A04. cwnd =3D ssthresh =3D FlightSize/2; send N=3Dcw= nd segments >=20 >=20 > That step (4) assumes a particular congestion control implementation th= at is different than > what we would recommend. Ok. I just used the Standards Track formula as does the RACK-TLP draft in=20 its examples. And because RACK-TLP draft states it does not modify=20 current congestion control. > For example, if FlightSize is 100 segments when timer expires, > congestion control is the same in steps 1-3, but in step 4 the > current standard congestion control allows transmitting 2 segment= s, > while RACK-TLP would allow blasting 50 segments. > > Question is: what is the justification to modify standard TCP > congestion control to use fast recovery instead of slow start for = a > case where timeout is needed to detect loss because there is no > feedback and ack clock is lost? The draft does not give any > justification. This clearly is in conflict with items (0) and (1) > in BCP 133 (RFC 5033). >=20 >=20 > The draft pointedly does not modify standard TCP congestion control. >=20 > RACK-TLP does not specify using fast recovery instead of slow start for = a=A0 case where timeout > is needed to detect loss because there is no=A0 feedback and the ACK cl= ock is lost. Rather, > RACK-TLP only triggers fast recovery if there *is* ACK feedback providi= ng an ACK clock and > strong evidence of a packet loss. So here our views diverge. In the above steps I decoupled congestion=20 control from what segments are sent (rexmit and xmit are mentioned there=20 just as comments to check what is going on, they can be freely removed). Congestion control governs how many segments can be sent. In my view, when there is no feedback RACK TLP uses timeout (PTO) to help=20 make progress. Without the timeout it cannot make progress. Just like=20 an RFC 5681 sender, it cannot make progress until timeout expires.=20 So this should be taken as the criteria to (effectively) enter slow start= ,=20 once loss becomes detected. Or, at least I don't see any difference why different timeout value would=20 change the congestion control. When timeout expires RACK-TLP sends one segment (just like an RFC 5681=20 sender when RTO expires). The only difference is that RFC 5681 sender=20 selects a different segment (first unacknowledged segment) to retransmit=20 "blindly" in order to get feedback and start ACK clock. RACK-TLP sends=20 "blindly" the last segment from the retransmission queue (or a new=20 segment). Selecting a different segment for transmission upon timeout=20 does not change anything, in my view. In both cases it is a "blind"=20 selection; the sender does not know what was lost. And in both cases the=20 ACK for this one segment provides feedback about what potentially has=20 been lost. There the only difference is that the segment that RACK-TLP=20 selected to transmit is a better choice when SACK option is use because=20 it provides more information. If there is some difference in that the ACK for RACK-TLP provides=20 stronger evidence for packet loss (and what was lost), then it should be=20 also ok to modify the current standard TCP congestion control such that=20 upon RTO timeout the sender does not select the first unacknowledged=20 segment for blind retransmission but the last segment in the=20 retransmission queue (or maybe a new segment). With SACK this would=20 provide exactly the same information as TLP probe does. And, upon arrival=20 of the first ACK, RTO recovery would use similar rules as in RACK-TLP to=20 better decide whether it was spurious RTO or loss and move from slow=20 start to fast recovery and set cwnd=3Dssthresh. I really don't see how this change in "blindly" retrasmitted first segmen= t=20 in slow start would allow modifying congestion control for RTO recovery. > The main aspect of triggering loss recovery that is new is the approach = of allowing a sender > to transmit one additional "probe" segment in flight after 2*SRTT. Once = this is accepted, the > rest of the recovery process essentially follows from principles alread= y generally accepted > in the IETF TCP community. Could you please see above and explain (or provide a pointer to an RFC)=20 what are those "principles already generally accepted in the IETF TCP=20 community". That would help me to understand your point. > Put another way, it seems to me that if one is to object to TLP-trigger= ed fast recovery, then > the objection must be mounted specifically against the permission grant= ed to the sender to > transmit one additional "probe" segment in flight after 2*SRTT. Once th= at permission is > granted, there is nothing really new about TLP-triggered fast recovery. I am sorry but I still fail to see what is the preceding evidence that=20 makes this not new. A pointer could help. In my view the probe is not anything to object as long as it is not=20 considered as a cwnd increase in the later cwnd&ssthresh calculation=20 (a minor detail, but someone might later suggest first two then 4 and so=20 on probe segments with the justufication that it is just one more than=20 earlier). > Furthermore, there is no implementation nor experimental experien= ce > evaluating this change. The implementation with experimental expe= rience > uses PRR (RFC 6937) which is an Experimental specification includ= ing a > novel "trick" that directs PRR fast recovery to effectively use s= low > start in this case at hand. >=20 >=20 > What do you think of Yuchung's latest suggestion for new text in "9.3.=A0 = Interaction with > congestion control" suggested by Yuchung Thursday afternoon (Dec 17), w= hich explicitly > recommends PRR? As mentioned earlier in this thread, there is considera= ble implementation and > experimental experience with RACK-TLP plus PRR since the Linux TCP stac= k has been using > RACK-TLP with PRR as the default=A0loss=A0recovery algorithm since Linu= x v4.18 in August 2018. As I have already indicated, in my view PRR does not have the problem we=20 are discussing here because PRR-SSRB makes fast recovery to behave like=20 slow start. And PRR-CRB is even more conservative. So it would be a safe=20 choice for this problem unlike the current RFC 6675 algorithm. In other words, I only object allowing the use of RACK-TLP with the=20 RFC 6675 congestion control algorithm unmodified because it does not have=20 a safeguard like PRR. This does not mean that RACK-TLP document would=20 need to include the necessary modifications to the RFC 6675 algorithm. I don't know processwise but PRR possibly cannot be used as normative=20 requirement because it is currently Experimental? Not quite sure though. Best regards, /Markku > The exact commit is: >=20 > =A0 b38a51fec1c1 tcp:=A0disable=A0RFC6675=A0loss=A0detection >=20 > best, > neal --=_script-6294-1608338492-0001-2-- From nobody Fri Dec 18 18:00:07 2020 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 3A0B53A0D00 for ; Fri, 18 Dec 2020 18:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 nUgh0cmvf293 for ; Fri, 18 Dec 2020 18:00:00 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 F0F353A0D06 for ; Fri, 18 Dec 2020 17:59:59 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id r4so5009264wmh.5 for ; Fri, 18 Dec 2020 17:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PYvDrWORN0Ldky2A+uRlKYObZff+CC9fMTtDbHDvpb0=; b=I5zQg6ffbds1VC3u/HpieZqJXb5Rq42Xo0LVZgqxW5ZNRgC11XwjNApAWlx5XCEb3U lOBp3GP8+9E6aKcsUqnXqCWvZXfGALnXsybDrWeVfQrow8ZYrr8QeB5jOHZymTs6mnlo zz42AmJmmykAFFIwxNAJP2iPqcIfIgugH2x4gfjDNJebKvxJl/Lh65c65cyyCvG4J3E4 w+vfrilGx8Ue+9B/IrPCcLIBJ+ZHJUAGGHHNCz2ZutDnxBmEqm7sTTq27EMN4iR+nBII qUjqgY7Y5UyUNa4YrYOB4lf2sGuX1H2Ot677RmQXtZYsOQFYdJLy8rPuDplVbQFnjeyA smpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PYvDrWORN0Ldky2A+uRlKYObZff+CC9fMTtDbHDvpb0=; b=p7J/8GPCXWcZ01FOGy5tJ/d0HLe60RP+Fq+gRUvE7o1DH/ebUa5FrN3B16/MwP1XKH 9YnDo7R7BuRJOr28OafAeUeQ+Aoui7WPPnOCbaEQlpfj4NxiQ7e8wWKNG+hY4bJ6FkSS AhNZ2CHKj7PF+RDgMjPVyx1r3U++u0VtBJ1jlMbJqJBLVGqbLHsPBI5vxOI0l6kpETJV s6f2Z7w1XF34W5zOP82uBhQEQWLUKg3Y1v04tbFUel2izuOOBpZb9PDNykhJYaV4IenH 305NnHmNfQ0cMdtq5RTdQhuklsXANRQC66Ah9Ux2CGTNDvjyB0UsxV58EvC2rMGc1bp4 rTJg== X-Gm-Message-State: AOAM533dvqIP44dErbBjkl+305UyEdgARLWLSRGK/Ng6LBUwUU2IE+hc KOPL3ORaMe29F2SMUPRZMv7Tk77C8do1FAbRxTVhbA== X-Google-Smtp-Source: ABdhPJwtYfGqY30knXY/YJmaNiqJAzJ0F28feESC9fPI404lblynPNgnBMnG4rmJUMv8xS7/FA4xnDjWg0QHI2/MILQ= X-Received: by 2002:a1c:7e4e:: with SMTP id z75mr6329565wmc.40.1608343197642; Fri, 18 Dec 2020 17:59:57 -0800 (PST) MIME-Version: 1.0 References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> In-Reply-To: <160822770059.15041.16286115220871304513@ietfa.amsl.com> From: Yuchung Cheng Date: Fri, 18 Dec 2020 17:59:20 -0800 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="000000000000f96e4b05b6c794af" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 02:00:02 -0000 --000000000000f96e4b05b6c794af Content-Type: text/plain; charset="UTF-8" On Thu, Dec 17, 2020 at 9:55 AM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-tcpm-rack-14: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for presenting this complicated topic in a very easy-to-read > manner! > Thank you for your review. > > Section 3.3.2 > > 1. The reordering window SHOULD be set to zero if no reordering has > been observed on the connection so far, and either (a) three > segments have been delivered out of order since the last recovery > > I assume there's some subtle technical difference between "reordering" > and "segments delivered out of order" that makes this a reasonable thing > to say ... but it would be nice if the distincion was made more clear > (whether here or in earlier text). > Great idea to define reordering more precisely. In this document, reordering refers to when two TCP segments are delivered at the TCP receiver in a different order from they were sent at the TCP sender for a given TCP flow. Notice the ordering is chronological instead of sequential on TCP sequences. We'll add that definition on the first appearance of the word 'reordering' to clarify. > > Section 6.2 > > Among all the segments newly ACKed or SACKed by this ACK that pass > the checks above, update the RACK.rtt to be the RTT sample calculated > using this ACK. Furthermore, record the most recent Segment.xmit_ts > in RACK.xmit_ts if it is ahead of RACK.xmit_ts. If Segment.xmit_ts > equals RACK.xmit_ts (e.g. due to clock granularity limits) then > compare Segment.end_seq and RACK.end_seq to break the tie. > > Perhaps we should state what the result of breaking the tie is used for > (i.e., updating RACK.segment & co.)? > sure: we'll add "breaking the tie to update RACK.segment's associated states'. > > To avoid the issue above, RACK dynamically adapts to higher degrees > of reordering using DSACK options from the receiver. Receiving an > ACK with a DSACK option indicates a possible spurious retransmission, > suggesting that RACK.reo_wnd may be too small. The RACK.reo_wnd > increases linearly for every round trip in which the sender receives > some DSACK option, so that after N distinct round trips in which a > DSACK is received, the RACK.reo_wnd becomes (N+1) * min_RTT / 4, with > an upper-bound of SRTT. > > What constitutes a "distinct round trip"? > The distinct is redundant. It really means N round trips (which obviously are distinct and different from the other N-1). We'll remove 'distinct' word. > > Return min(RACK.min_RTT / 4 * RACK.reo_wnd_mult, SRTT) > > I suggest reordering the expression to be min(RACK.reo_wnd_mult * > RACK.min_RTT / 4, SRTT), to avoid needing to consider the order of > operations and operator precedence in the pseudocode. (soapbox: in > formal mathematics, there is no "division" operation, just > multiplication by the multiplicative inverse, in part because it makes > dealing with associativity and commutativity of operations harder to > reason about.) > Sure we'll change to the suggested more clear format. > > Section 8 > > sender SHOULD cancel any other pending timer(s). An implementation > is to have one timer with an additional state variable indicating the > type of the timer. > > nit: maybe "is expected to have one timer", to avoid any risk of being > interpreted as over-specifying implementation behavior? > good idea. will add "expected". > > Is there anything to say about increasing the usage of fast recovery > (vs RTO) potentially having an aggregate effect globally on how much > data is in flight and increasing the overall risk of congestion? (I > mostly assume not, but it's kind of my job to ask.) > Great question. We agree with you: our conjecture is that RACK-TLP reduces (loss-based) C.C. over-correction and BW under-utilization than C.C. under-correction, particularly for app-limited short flows. For bulk long flows that comprise the majority of the Internet traffic volume, most losses are well detected by the existing 3-dupack-rule since the flows' congestion windows are large enough to trigger 3 dupacks. RACK-TLP actually helps reduce spurious fast recoveries on moderately reordered paths for these long flows. But overall in our experience, the state of congestion is much dominated by the actual C.C. algorithms (e.g. slow-start, increase and decrease functions) of these long flows and less about #fast-recoveries. > > Section 13.1 > > In terms of how we reference it, RFC 3042 seems like it could be > informative. > Good catch. will move to normative --000000000000f96e4b05b6c794af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 17, 2020 at 9:55 AM Benja= min Kaduk via Datatracker <noreply@ietf.org> wrote:
Benjamin Kaduk has entered the following ballot po= sition for
draft-ietf-tcpm-rack-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tc= pm-rack/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for presenting this complicated topic in a very easy-to-read
manner!
Thank you for your review.
=C2=A0

Section 3.3.2

=C2=A0 =C2=A01.=C2=A0 The reordering window SHOULD be set to zero if no reo= rdering has
=C2=A0 =C2=A0 =C2=A0 =C2=A0been observed on the connection so far, and eith= er (a) three
=C2=A0 =C2=A0 =C2=A0 =C2=A0segments have been delivered out of order since = the last recovery

I assume there's some subtle technical difference between "reorder= ing"
and "segments delivered out of order" that makes this a reasonabl= e thing
to say ... but it would be nice if the distincion was made more clear
(whether here or in earlier text).
Great idea to defin= e reordering more precisely. In this document, reordering refers to when tw= o TCP segments are delivered at the TCP receiver in a different order from = they were sent at the TCP sender for a given TCP flow. Notice the ordering = is chronological instead of sequential on TCP sequences.

We'll add that definition on the first appearance of the word &#= 39;reordering' to clarify.
=C2=A0

Section 6.2

=C2=A0 =C2=A0Among all the segments newly ACKed or SACKed by this ACK that = pass
=C2=A0 =C2=A0the checks above, update the RACK.rtt to be the RTT sample cal= culated
=C2=A0 =C2=A0using this ACK.=C2=A0 Furthermore, record the most recent Segm= ent.xmit_ts
=C2=A0 =C2=A0in RACK.xmit_ts if it is ahead of RACK.xmit_ts.=C2=A0 If Segme= nt.xmit_ts
=C2=A0 =C2=A0equals RACK.xmit_ts (e.g. due to clock granularity limits) the= n
=C2=A0 =C2=A0compare Segment.end_seq and RACK.end_seq to break the tie.

Perhaps we should state what the result of breaking the tie is used for
(i.e., updating RACK.segment & co.)?

sure: we'll add "breaking the tie to update RACK.segment's a= ssociated states'.
=C2=A0

=C2=A0 =C2=A0To avoid the issue above, RACK dynamically adapts to higher de= grees
=C2=A0 =C2=A0of reordering using DSACK options from the receiver.=C2=A0 Rec= eiving an
=C2=A0 =C2=A0ACK with a DSACK option indicates a possible spurious retransm= ission,
=C2=A0 =C2=A0suggesting that RACK.reo_wnd may be too small.=C2=A0 The RACK.= reo_wnd
=C2=A0 =C2=A0increases linearly for every round trip in which the sender re= ceives
=C2=A0 =C2=A0some DSACK option, so that after N distinct round trips in whi= ch a
=C2=A0 =C2=A0DSACK is received, the RACK.reo_wnd becomes (N+1) * min_RTT / = 4, with
=C2=A0 =C2=A0an upper-bound of SRTT.

What constitutes a "distinct round trip"?
Th= e distinct is redundant. It really means N round trips (which obviously are= distinct and different from the other N-1). We'll remove 'distinct= ' word.
=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0Return min(RACK.min_RTT / 4 * RACK.reo_wnd_mult,= SRTT)

I suggest reordering the expression to be min(RACK.reo_wnd_mult *
RACK.min_RTT / 4, SRTT), to avoid needing to consider the order of
operations and operator precedence in the pseudocode.=C2=A0 (soapbox: in formal mathematics, there is no "division" operation, just
multiplication by the multiplicative inverse, in part because it makes
dealing with associativity and commutativity of operations harder to
reason about.)
Sure we'll change to the suggested = more clear format.
=C2=A0

Section 8

=C2=A0 =C2=A0sender SHOULD cancel any other pending timer(s).=C2=A0 An impl= ementation
=C2=A0 =C2=A0is to have one timer with an additional state variable indicat= ing the
=C2=A0 =C2=A0type of the timer.

nit: maybe "is expected to have one timer", to avoid any risk of = being
interpreted as over-specifying implementation behavior?
good idea. will add "expected".=C2=A0
=C2=A0

Is there anything to say about increasing the usage of fast recovery
(vs RTO) potentially having an aggregate effect globally on how much
data is in flight and increasing the overall risk of congestion?=C2=A0 (I mostly assume not, but it's kind of my job to ask.)
Great question. We agree with you: our conjecture is that RACK-TLP reduce= s (loss-based) C.C. over-correction and BW under-utilization than C.C. unde= r-correction, particularly for app-limited short flows. For bulk long flows= that comprise the majority of the Internet traffic volume, most losses are= well detected by the existing 3-dupack-rule since the flows' congestio= n windows are large enough to trigger 3 dupacks. RACK-TLP actually helps re= duce spurious fast recoveries on moderately reordered paths for these long = flows. But overall in our experience, the state of congestion is much domin= ated=C2=A0by the actual C.C. algorithms (e.g. slow-start, increase and decr= ease functions) of these long flows and less about #fast-recoveries.
<= div>=C2=A0

Section 13.1

In terms of how we reference it, RFC 3042 seems like it could be
informative.
Good catch. will move to normative=C2=A0<= /div>
--000000000000f96e4b05b6c794af-- From nobody Sat Dec 19 09:24:10 2020 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 618EF3A0115; Fri, 18 Dec 2020 11:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 leY9zyq6qv8q; Fri, 18 Dec 2020 11:36:01 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650128.outbound.protection.outlook.com [40.107.65.128]) (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 B5D373A0100; Fri, 18 Dec 2020 11:36:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eaJS1c7Qn7dQ11Ji5RE6OCdnUGZemHnz0HrUU1CdKsIeYpBl12fj2AsX12O77O5gZVbZN6CQ+vRMgihrrXqUxLZivXYAgA0WZAZZAU06JLXYTuhet5Wi5mk5HQYNf6NxcLDLTweXx5ZbfVPWVCFCBniHOaF4N07YqJoNLLZqUbHE/u/9D54VuDuxK3NpnB/UIeDcOdAmDtnPu7e3fpdTm1iuxKpiTtiFa4AFYZ7IYs7xLsEpBXrOvBDSKgGQHfiMlWtFz3P9YGypMKV4S4h0OZpBeqKAHCGUCI1eLl1y3fGcFKdGOQLBLFLJy2UEC/zVLeaZRxdJBXsg47Qkpmszsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WBKISMsomAz3wb2hpdCkfqO6iZuxGveigjL6QKxuAog=; b=Gb9vRO4ekOETtjqtYp92LAIq7waECpGl+kyf+1MV/+VGx7+QNHWgVgQ4EX2oBpLcpU+19L8AUXQeJGezR9AwJp59pWk/W/7WUHQuKY4MhU6cYsuOoMDfy8wj3i+Zyc9qlLEcgqTBdL1Byh2B7f1JArgkH0nqqnaeqPfCHCK4wiVeM84NmcxOMcQYUpld6+zXJW3pIZJRGjik/W2r/NEVulONPsvlDBHj0g04R5WD5pJeHeWofNTXG6yFcxfhTr63pQx8iavEFaFBOnWHBNAhrlF/z6u65riAfbogY2wrtixjv6AfjpKkmTKlJFREYxRFbEp/ZfKh/0O5UVNBYqrK4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WBKISMsomAz3wb2hpdCkfqO6iZuxGveigjL6QKxuAog=; b=F8yQnWy+yuAP4oPhz/q11F7V4NfGxS0pgB11cDRFbxy1gCSD4dOmuhz0CEbKftsLVvpJxTf6euOml4b5Jz4eje6vlKcH7f491rC303ely7Y+osY3y4ox6f/wB/sLqn+15e+AyzDbhOz7D1MZxsojdQsn3rPdXpoQTWZMzEhvTIE= Received: from (2603:10b6:102:15::19) by CO2PR00MB0072.namprd00.prod.outlook.com (2603:10b6:102:18::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3715.0; Fri, 18 Dec 2020 19:35:46 +0000 Received: from CO2PR00MB0166.namprd00.prod.outlook.com ([fe80::390c:92e4:6d2a:2c]) by CO2PR00MB0166.namprd00.prod.outlook.com ([fe80::390c:92e4:6d2a:2c%4]) with mapi id 15.20.3722.000; Fri, 18 Dec 2020 19:35:46 +0000 From: Praveen Balasubramanian To: "ycheng@google.com" , "martin.h.duke@gmail.com" CC: "kojo@cs.helsinki.fi" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [EXTERNAL] Re: [tcpm] Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard Thread-Index: AQHW1FF01btI7SQGVkejFRzXPAuBhKn7amWAgAA3ZGCAAA1FgIAAJ/SAgAAPpYCAAVpYoA== Date: Fri, 18 Dec 2020 19:35:45 +0000 Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=91864e44-a340-4282-aa92-65bcc8aa7d57; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-12-18T19:34:35Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7:95d1:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e2f99097-b0ae-4e48-b2b7-08d8a38c1da4 x-ms-traffictypediagnostic: CO2PR00MB0072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u3xwpkrA6wi/bd34MlRpQfN3yoJfnXak0VE6EP9Scx0i++YCNqhfhPP8R+Xc9OI1IZ8dIpBD4SubhKJMHYeBd1Hc2makZP8RzPI9MElGZQ06pP5yIT2w1Md8PzJbww0OzmZm48uaPvhPYUgCSPNJimWhcAPOvGb4pbOoWecDBL1e7Gfy1UCK9tHtUkX2RiqCwO94spwR+4cS9vxUFMynFYNb78fcD/n9zBC9PjTqJdajrQzh46UZ18jEJuuaxkEVdf76IDwOX+l29DLLGXneEcXdxfX7SeftJGOlMygatykCKSb2uONI0mpES3Ydb1lTs8sz5bGCyd4ex49+nWNzXPSVWFB8wL5XvlJh5Ha5THOpd+oVHBILcSlsOOYWKLq7cVAALS3LKPw+Vr9urFeg7g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO2PR00MB0166.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39860400002)(136003)(396003)(376002)(8936002)(66446008)(55016002)(316002)(86362001)(52536014)(5660300002)(66476007)(66946007)(64756008)(71200400001)(8990500004)(4326008)(53546011)(2906002)(110136005)(8676002)(7696005)(9686003)(30864003)(82960400001)(76116006)(33656002)(478600001)(6506007)(66556008)(82950400001)(10290500003)(54906003)(186003)(83380400001)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?TzZuSGJsNzZ3R2dPdDF5MGc5UkpueWRqYjNFVnYvZE9NTHdHQlU4dWIwSURB?= =?utf-8?B?SjNBWXNRS0NDSnN4ZjNqcHh6MUw3enpLRzZ0czdjaWJtMFNJalhPUXpqRDdu?= =?utf-8?B?Q2dSbFFZWC9hOWl5aXl3QzU1WjhEdnhEOVNWZzZSSEtxYW9FTjdQTU5Xb0JJ?= =?utf-8?B?WGlhOUFzcDBkUDdFbGQwVElFcnUxN1NwZnY4WDl5Slp4ZHdWTVROdm9scWJG?= =?utf-8?B?eG8zc0M0aHNaaVZWTUwwekpUMDhGTUdLUzFtcXI0c1Z6NWVkUFJzRk11b29S?= =?utf-8?B?Z1hPQ1ZsYTJrWWx0dTQwNEtiaWp3dHdJTGRMZkRmVHZ1K21ZOTd3MnBqSktD?= =?utf-8?B?ZDZFM2Z3dEJ1ZlBGczFaWlUzak8vY25DNUdOT3FKYU15b3N4OHBQVmNDU0Nj?= =?utf-8?B?ay9DZnI3dTYwaWE1b3k1aFdaL1YzbHo3ajJEamI1Z2xUeXo4Qk95dVFKdjlh?= =?utf-8?B?blZhN3dEWm5ESEVna2oyVVhDSkVDWnY3dFNDcjE3Z05JckljbFpjcHlZZGpD?= =?utf-8?B?ZFk0TVltVmt5NW1YeEhzTE5jMytYNEJkVUU2RC9nTXpUNnZlS2Mrd1hIUXA5?= =?utf-8?B?Zkw3dXlTTk9YM2Jta05oa05LUjdDQ1Fjc1JISU1XeTgxQzBZbVZJUXh2L1Vk?= =?utf-8?B?OTFnQ1BGRmFySFVJdHVvVkNKNSs4dFlqd2RiSGxkZXVnQWh2aTl3S3Qza0Ir?= =?utf-8?B?Y1NxNFVpRDRjcHlQcjZXaTZNOHdVS25IN0VjeXQxeDB0d1F3WHJ4RlJCTTQr?= =?utf-8?B?TGRBMlRTS0FnaG9CN0lDSklYVC91dDJYMG9yR09ON0Q3MkZhSXhUcVEvMHpI?= =?utf-8?B?NURBTjVVcFhvZXNyQm12cnNSbXFURG5RWFJKaU5yUjNVUXN3Q3l1UDJIeEtX?= =?utf-8?B?bWszdjFPL1pPZ2laQW56ckFoYzdMZUV5V0hLWTdyNmVEVlkvWHpua0VkZ053?= =?utf-8?B?Zlp5cEN2UmZBd2tCeEYxb3B6YWhLTWJ5RzVlblVZeVFiMnRDRkIzcjhZWm1x?= =?utf-8?B?YUhYekRWcXhZSE8vOXZ2V0plYWVJK3JGM3gyZm42RGhwZGRMZFVmS0I1Wmp4?= =?utf-8?B?V3VyOWp2UW9hZUM1d3FOYXE0VUNOdldnT3pSVVpnVVFYbDBwVnRieW8xMEk3?= =?utf-8?B?Mk8vOWxtV3c2RGJ4c0tmMUtGMGs3MHVxbHo4d2RJNDgwK3ZRYzVFbUpQeGtY?= =?utf-8?B?dVRzYU40NWpDdFZZWVBIbVpMOGxndnJGVjRLYmdTenJXL2dkd0RiWFdlRGRy?= =?utf-8?B?Q0lzQXg1ZlkyZ1liTkI0WjJBY0xmcW4yQzQ0UkJjNGdGb0h1RkovNzlRRE05?= =?utf-8?B?YzQxOW9lZFRjUlFRVnd5Skl2c1ZiL01vMWV4K1RKWkNQK1dUTHBrUXlGN2lI?= =?utf-8?B?WE9nM3RiUXpPUjZ6bUdZOGQ4R3JaS0xsOGVqZXArRU84Ly9lN3hSV1g4YlZO?= =?utf-8?B?cWZIYlQ5NTdSTDRyNzh0TFc4Y21ZYldkQlg1b3cxVUljM1dDNERYUHM5MENB?= =?utf-8?Q?8D2fa42lIaJOTvUq9+zgsaZf7CC?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO2PR00MB016669CA3B63D26781DE0EF1B6C39CO2PR00MB0166namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO2PR00MB0166.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2f99097-b0ae-4e48-b2b7-08d8a38c1da4 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2020 19:35:46.0047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nGmWTdDUKgl8/RkKGOedJApfFbnr1tHy/CVBxknbVFEmHIRwx66gPBN1QM5e6mAND1eMKroL7piacD7SjU/QoCVtqgraCHBxp3Qw+Dsklxo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR00MB0072 Archived-At: X-Mailman-Approved-At: Sat, 19 Dec 2020 09:24:09 -0800 Subject: Re: [tcpm] [EXTERNAL] Re: Last Call: (TheRACK-TLPlossdetectionalgorithmforTCP) to Proposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 19:36:06 -0000 --_000_CO2PR00MB016669CA3B63D26781DE0EF1B6C39CO2PR00MB0166namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TG9va3MgZ29vZCB0byBtZS4gSSB3b3VsZCBvbWl0IOKAnCwgYnV0IHNvbWUgb3RoZXIgY29uZ2Vz dGlvbiBjb250cm9sIG1heSB3YW50IHRvIHJlc3BvbmQgbXVsdGlwbGUgdGltZXMgZGlmZmVyZW50 bHnigJ0uDQoNCkZyb206IFl1Y2h1bmcgQ2hlbmcgPHljaGVuZ0Bnb29nbGUuY29tPg0KU2VudDog VGh1cnNkYXksIERlY2VtYmVyIDE3LCAyMDIwIDI6NTUgUE0NClRvOiBNYXJ0aW4gRHVrZSA8bWFy dGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi QG1pY3Jvc29mdC5jb20+OyBrb2pvQGNzLmhlbHNpbmtpLmZpOyB0Y3BtQGlldGYub3JnOyBkcmFm dC1pZXRmLXRjcG0tcmFja0BpZXRmLm9yZzsgdHVleGVuQGZoLW11ZW5zdGVyLmRlOyBkcmFmdC1p ZXRmLXRjcG0tcmFjay5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgdGNwbS1jaGFp cnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRVhURVJOQUxdIFJlOiBbdGNwbV0gTGFzdCBDYWxs OiA8ZHJhZnQtaWV0Zi10Y3BtLXJhY2stMTMudHh0PihUaGVSQUNLLVRMUGxvc3NkZXRlY3Rpb25h bGdvcml0aG1mb3JUQ1ApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCg0KDQpPbiBUaHUsIERlYyAx NywgMjAyMCBhdCAxOjU5IFBNIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxt YWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNClRoaXMgaXMgZ29vZCwgdGhh bmtzLg0KDQpJIG1pZ2h0IGFsc28gYWRkIHRoZSBzZW50ZW5jZSAiSW4gdGhlIGFic2VuY2Ugb2Yg UFJSLCB3aGVuIFRDUCBSQUNLIGRldGVjdHMgYSBsb3N0IHJldHJhbnNtaXNzaW9uIGl0IE1VU1Qg dHJpZ2dlciBhIHNlY29uZCBjb25nZXN0aW9uIHJlc3BvbnNlIiBvciBzb21ldGhpbmcgdG8gdGhh dCBlZmZlY3QuIFdoYXQgZG8geW91IHRoaW5rPw0KU3VyZSBJJ2QgcmV2aXNlIGEgYml0IHRvIGJl IGV2ZW4gbW9yZSBkZXRhaWxlZCBhbmQgY29uc2lzdGVudCB3aXRoIHRoZSBwcmluY2lwbGUgaW4g UkZDNTY4MQ0KDQoiSW4gdGhlIGFic2VuY2Ugb2YgUFJSLCB3aGVuIFJBQ0stVExQIGRldGVjdHMg YSBsb3N0IHJldHJhbnNtaXNzaW9uIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgTVVTVCB0cmlnZ2Vy IGFuIGFkZGl0aW9uYWwgY29uZ2VzdGlvbiByZXNwb25zZSBwZXIgdGhlIGFmb3JlbWVudGlvbmVk IHByaW5jaXBsZSBpbiBSRkM1NjgxLg0KSWYgbXVsdGlwbGUgcmV0cmFuc21pc3Npb25zIHdlcmUg bG9zdCBpbiBhIHdpbmRvdywgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBzcGVjaWZpZWQgaW4gUkZD NTY4MSBvbmx5IHJlYWN0cyBvbmNlIHBlciB3aW5kb3csIGJ1dCBzb21lIG90aGVyIGNvbmdlc3Rp b24gY29udHJvbCBtYXkgd2FudCB0byByZXNwb25kIG11bHRpcGxlIHRpbWVzIGRpZmZlcmVudGx5 LiBUaGUgY29uZ2VzdGlvbiBjb250cm9sIGltcGxlbWVudGVyIGlzIGFkdmlzZWQgdG8gY2FyZWZ1 bGx5IGNvbnNpZGVyIHRoaXMgc3VidGxlIHNpdHVhdGlvbi4iDQoNCg0KDQpPbiBUaHUsIERlYyAx NywgMjAyMCBhdCAxMTozNiBBTSBZdWNodW5nIENoZW5nIDx5Y2hlbmdAZ29vZ2xlLmNvbTxtYWls dG86eWNoZW5nQGdvb2dsZS5jb20+PiB3cm90ZToNCkhvdyBhYm91dA0KDQoiOS4zLiAgSW50ZXJh Y3Rpb24gd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wNCg0KUkFDSy1UTFAgaW50ZW50aW9uYWxseSBk ZWNvdXBsZXMgbG9zcyBkZXRlY3Rpb24gLi4uDQpBcyBtZW50aW9uZWQgaW4gRmlndXJlIDEgY2Fw dGlvbiwgUkZDNTY4MSBtYW5kYXRlcyBhIHByaW5jaXBsZSB0aGF0DQpMb3NzIGluIHR3byBzdWNj ZXNzaXZlIHdpbmRvd3Mgb2YgZGF0YSwgb3IgdGhlIGxvc3Mgb2YgYQ0KcmV0cmFuc21pc3Npb24s IHNob3VsZCBiZSB0YWtlbiBhcyB0d28gaW5kaWNhdGlvbnMgb2YgY29uZ2VzdGlvbiwgYW5kDQp0 aGVyZWZvcmUgcmVhY3RlZCBzZXBhcmF0ZWx5LiBIb3dldmVyIGltcGxlbWVudGF0aW9uIG9mIFJG QzY2NzUgcGlwZQ0KYWxnb3JpdGhtIG1heSBub3QgZGlyZWN0bHkgYWNjb3VudCBmb3IgdGhpcyBu ZXdseSBkZXRlY3RlZCBjb25nZXN0aW9uDQpldmVudHMgcHJvcGVybHkuIFBSUiBbUkZDeHh4eF0g aXMgUkVDT01NRU5ERUQgZm9yIHRoZSBzcGVjaWZpYw0KY29uZ2VzdGlvbiBjb250cm9sIGFjdGlv bnMgdGFrZW4gdXBvbiB0aGUgbG9zc2VzIGRldGVjdGVkIGJ5IFJBQ0stVExQIg0KDQoNClRvIE1h a2t1J3MgcmVxdWVzdCBmb3IgIndoYXQncyB0aGUganVzdGlmaWNhdGlvbiB0byBlbnRlciBmYXN0 IHJlY292ZXJ5Ii4gQ29uc2lkZXIgdGhpcyBleGFtcGxlIHcvbyBSQUNLLVRMUA0KDQpUMDogU2Vu ZCAxMDAgc2VnbWVudHMgYnV0IGFwcGxpY2F0aW9uLWxpbWl0ZWQuIEFsbCBhcmUgbG9zdC4NClQt MlJUVDogYXBwIHdyaXRlcyBzbyBhbm90aGVyIDMgc2VnbWVudHMgYXJlIHNlbnQuIE1hZGUgdG8g dGhlIGRlc3RpbmF0aW9uIGFuZCB0cmlnZ2VyZWQgMyBEVVBBQ0tzDQpULTNSVFQ6IDMgRFVQQUNL IGFycml2ZXMuIHN0YXJ0IGZhc3QgcmVjb3ZlcnkgYW5kIHN1YnNlcXVlbnQgY2MgcmVhY3Rpb25z IHRvIGJ1cnN0IH41MCBwYWNrZXRzIHdpdGggUmVubw0KDQpJbiB0aGlzIGNhc2UgYW55IEFDSyBv Y2N1cmVkIGJlZm9yZSBSVE8gaXMgKGdlbmVyYWxseSkgY29uc2lkZXJlZCBjbG9jay1hY2tlZCwg YW5kIGhvdyBJIHVuZGVyc3RhbmQgVmFuJ3MgaW5pdGlhbCBkZXNpZ24uICBUaGlzIGJlaGF2aW9y IGV4aXN0ZWQgZGVjYWRlcyBiZWZvcmUgUkFDSy1UTFAuIFJBQ0stVExQIGVzc2VudGlhbGx5IGNo YW5nZXMgdGhlICIzLXNlZ21lbnRzIGJ5IGFwcCIgdG8gIjEtc2VnbWVudCBieSB0Y3AiLg0KDQpP biBUaHUsIERlYyAxNywgMjAyMCBhdCAxMDo1MiBBTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8 cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K SSBhZ3JlZSB0aGF0IHdlIHNob3VsZCBoYXZlIGEgbm90ZSBpbiB0aGlzIFJGQyBhYm91dCBjb25n ZXN0aW9uIGNvbnRyb2wgYWN0aW9uIHVwb24gZGV0ZWN0aW5nIGxvc3QgcmV0cmFuc21pc3Npb24o cykuDQoNCkZyb206IHRjcG0gPHRjcG0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGNwbS1ib3Vu Y2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1hcnRpbiBEdWtlDQpTZW50OiBUaHVyc2RheSwg RGVjZW1iZXIgMTcsIDIwMjAgNzozMCBBTQ0KVG86IE1hcmtrdSBLb2pvIDxrb2pvQGNzLmhlbHNp bmtpLmZpPG1haWx0bzprb2pvQGNzLmhlbHNpbmtpLmZpPj4NCkNjOiB0Y3BtQGlldGYub3JnPG1h aWx0bzp0Y3BtQGlldGYub3JnPiBFeHRlbnNpb25zIDx0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3Bt QGlldGYub3JnPj47IGRyYWZ0LWlldGYtdGNwbS1yYWNrQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLXRjcG0tcmFja0BpZXRmLm9yZz47IE1pY2hhZWwgVHVleGVuIDx0dWV4ZW5AZmgtbXVlbnN0 ZXIuZGU8bWFpbHRvOnR1ZXhlbkBmaC1tdWVuc3Rlci5kZT4+OyBkcmFmdC1pZXRmLXRjcG0tcmFj ay5hbGxAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1yYWNrLmFsbEBpZXRmLm9yZz47 IExhc3QgQ2FsbCA8bGFzdC1jYWxsQGlldGYub3JnPG1haWx0bzpsYXN0LWNhbGxAaWV0Zi5vcmc+ PjsgdGNwbS1jaGFpcnMgPHRjcG0tY2hhaXJzQGlldGYub3JnPG1haWx0bzp0Y3BtLWNoYWlyc0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbdGNwbV0gTGFzdCBDYWxsOiA8ZHJh ZnQtaWV0Zi10Y3BtLXJhY2stMTMudHh0PihUaGVSQUNLLVRMUGxvc3NkZXRlY3Rpb25hbGdvcml0 aG1mb3JUQ1ApIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCkhpIE1hcmtrdSwNCg0KVGhhbmtzLCBu b3cgSSB1bmRlcnN0YW5kIHlvdXIgb2JqZWN0aW9ucy4NCg0KTWFydGluDQoNCk9uIFRodSwgRGVj IDE3LCAyMDIwIGF0IDEyOjQ2IEFNIE1hcmtrdSBLb2pvIDxrb2pvQGNzLmhlbHNpbmtpLmZpPG1h aWx0bzprb2pvQGNzLmhlbHNpbmtpLmZpPj4gd3JvdGU6DQpIaSwNCg0KT24gV2VkLCAxNiBEZWMg MjAyMCwgTWFydGluIER1a2Ugd3JvdGU6DQoNCj4gSSBzcGVudCBhIGxpdHRsZSBsb25nZXIgbG9v a2luZyBhdCB0aGUgc3BlY3MgbW9yZSBjYXJlZnVsbHksIGFuZCBJIGV4cGxhaW5lZCAoMSkNCj4g aW5jb3JyZWN0bHkgaW4gbXkgbGFzdCB0d28gbWVzc2FnZXMuIFAyMS4uMjkgYXJlIG5vdCBMaW1p dGVkIFRyYW5zbWl0IHBhY2tldHMuDQoNCkNvcnJlY3QuIEp1c3Qgbm9ybWFsIHRoZSBydWxlIHRo YXQgYWxsb3dzIHNlbmRpbmcgbmV3IGRhdGEgZHVyaW5nIGZhc3QNCnJlY292ZXJ5Lg0KDQo+IEhv d2V2ZXIsIHVubGVzcyBJJ20gbWlzc2luZyBzb21ldGhpbmcgZWxzZSwgNjY3NSBpcyBjbGVhciB0 aGF0IHRoZSByZWNvdmVyeSBwZXJpb2QNCj4gZG9lcyBub3QgZW5kIHVudGlsIHRoZSBjdW11bGF0 aXZlIGFjayBhZHZhbmNlcywgbWVhbmluZyB0aGF0IGRldGVjdGluZyB0aGUgbG9zdA0KPiByZXRy YW5zbWlzc2lvbiBvZiBQMSBkb2VzIG5vdCB0cmlnZ2VyIGFub3RoZXIgTUQgZGlyZWN0bHkuDQoN CkFzIEkgaGF2ZSBzYWlkIGVhcmxpZXIsIFJGQyA2Njc1IGRvZXMgbm90IHJlcGVhdCBhbGwgY29u Z2VzdGlvbiBjb250cm9sDQpwcmluY2lwbGVzIGZyb20gUkZDIDU2ODEuIEl0IGRlZmluaXRlbHkg aG9ub3JzIHRoZSBDQyBwcmluY2lwbGUgdGhhdA0KcmVxdWlyZXMgdG8gdHJlYXQgYSBsb3NzIG9m IGEgcmV0cmFuc21pc3Npb24gYXMgYSBuZXcgY29uZ2VzdGlvbg0KaW5kaWNhdGlvbiBhbmQgYW5v dGhlciBNRC4gSSBiZWxpZXZlIEkgYW0gb2JsaWdhdGVkIHRvIGtub3cgdGhpcyBhcyBhDQpjby1h dXRob3Igb2YgUkZDIDY2NzUuIDspDQoNClJGQyA2Njc1IGV4cGxpY2l0bHkgaW5kaWNhdGVzIHRo YXQgaXQgZm9sbG93cyBSRkMgNTY4MSBieSBzdGF0aW5nIGluIHRoZQ0KYWJzdHJhY3Q6DQoNCiIg Li4uIGNvbmZvcm1zIHRvIHRoZSBzcGlyaXQgb2YgdGhlIGN1cnJlbnQgY29uZ2VzdGlvbiBjb250 cm9sDQogIHNwZWNpZmljYXRpb24gKFJGQyA1NjgxIC4uLiINCg0KQW5kIGluIHRoZSBpbnRybzoN Cg0KICAgIlRoZSBhbGdvcml0aG0gc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgaXMgYSBzdHJh aWdodGZvcndhcmQNCiAgICBTQUNLLWJhc2VkIGxvc3MgcmVjb3Zlcnkgc3RyYXRlZ3kgdGhhdCBm b2xsb3dzIHRoZSAgZ3VpZGVsaW5lcw0KICAgIHNldCBpbiBbUkZDNTY4MV0gLi4uIg0KDQpJIGRv bid0IHRoaW5rIHRoZXJlIGlzIGFueXRoaW5nIHVuY2xlYXIgaW4gdGhpcy4NCg0KUkZDIDY2NzUg YW5kIGFsbCBvdGhlciBzdGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2xzIChSRkMgNTU4MSBhbmQg UkZDDQo2NTgyKSBoYW5kbGUgYSBsb3NzIG9mIGEgcmV0cmFuc21pc3Npb24gYnkgImVuZm9yY2lu ZyIgUlRPIHRvIGRldGVjdCBpdC4NCkFuZCBSVE8gZ3VhcmFudGVlcyBNRC4gUkFDSy1UTFAgY2hh bmdlcyB0aGUgbG9zcyBkZXRlY3Rpb24gaW4gdGhpcyBjYXNlDQphbmQgdGhlcmVmb3JlIHRoZSBz dGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtcyBkbyBub3QgaGF2ZQ0KYWN0aW9u cyB0byBoYW5kbGUgaXQgY29ycnJlY3RseS4gVGhhdCBpcyB0aGUgcG9pbnQuDQoNCkJSLA0KDQov TWFya2t1DQoNCj4gVGhhbmtzIGZvciB0aGlzIGV4ZXJjaXNlISBJdCdzIHJlZnJlc2hlZCBteSBt ZW1vcnkgb2YgdGhlc2UgZGV0YWlscyBhZnRlciB3b3JraW5nDQo+IG9uIHNsaWdodGx5IGRpZmZl cmVudCBRVUlDIGFsZ29yaXRobXMgYSBsb25nIHRpbWUuDQo+DQo+IE9uIFdlZCwgRGVjIDE2LCAy MDIwLCAxODo1NSBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQo+ICgxKSBGbGlnaHRzaXplOiBpbiBSRkMg NjY3NS4gU2VjdGlvbiA1LCBTdGVwIDQuMjoNCj4NCj4gICAgICAgICg0LjIpIHNzdGhyZXNoID0g Y3duZCA9IChGbGlnaHRTaXplIC8gMikNCj4NCj4gICAgICAgICAgICAgIFRoZSBjb25nZXN0aW9u IHdpbmRvdyAoY3duZCkgYW5kIHNsb3cgc3RhcnQgdGhyZXNob2xkDQo+ICAgICAgICAgICAgICAo c3N0aHJlc2gpIGFyZSByZWR1Y2VkIHRvIGhhbGYgb2YgRmxpZ2h0U2l6ZSBwZXIgW1JGQzU2ODFd Lg0KPiAgICAgICAgICAgICAgQWRkaXRpb25hbGx5LCBub3RlIHRoYXQgW1JGQzU2ODFdIHJlcXVp cmVzIHRoYXQgYW55DQo+ICAgICAgICAgICAgICBzZWdtZW50cyBzZW50IGFzIHBhcnQgb2YgdGhl IExpbWl0ZWQgVHJhbnNtaXQgbWVjaGFuaXNtIG5vdA0KPiAgICAgICAgICAgICAgYmUgY291bnRl ZCBpbiBGbGlnaHRTaXplIGZvciB0aGUgcHVycG9zZSBvZiB0aGUgYWJvdmUNCj4gICAgICAgICAg ICAgIGVxdWF0aW9uLg0KPg0KPiBJSVVDIHRoZSBzZWdtZW50cyBQMjEuLlAyOSBpbiB5b3VyIGV4 YW1wbGUgd2VyZSBzZW50IGJlY2F1c2Ugb2YgTGltaXRlZA0KPiBUcmFuc21pdCwgYW5kIHNvIGRv bid0IGNvdW50LiBUaGUgZmxpZ2h0c2l6ZSBmb3IgdGhlIHB1cnBvc2VzIG9mICg0LjIpIGlzDQo+ IHRoZXJlZm9yZSAyMCBhZnRlciBib3RoIGxvc3NlcywgYW5kIHRoZSBjd25kIGRvZXMgbm90IGdv IHVwIG9uIHRoZSBzZWNvbmQNCj4gbG9zcy4NCj4NCj4gKDIpDQo+ICIgRXZlbiBhIHNpbmdsZSBz aG90IGJ1cnN0IGV2ZXJ5IHRpbWUgdGhlcmUgaXMgc2lnbmlmaWNhbnQgbG9zcw0KPiBldmVudCBp cyBub3QgYWNjZXB0YWJsZSwgbm90IHRvIG1lbnRpb24gY29udGludW91cyBhZ2dyZXNzaXZlbmVz cywgYW5kDQo+IHRoaXMgaXMgZXhhY3RseSB3aGF0IFJGQyAyOTE0IGFuZCBSRkMgNTAzMyBleHBs aWNpdGx5IGFkZHJlc3MgYW5kIHdhcm4NCj4gYWJvdXQuIg0KPg0KPiAiU2lnbmlmaWNhbnQgbG9z cyBldmVudCIgaXMgdGhlIGtleSBwaHJhc2UgaGVyZS4gVGhlIGludGVudCBvZiBUTFAvUFRPIGlz IHRvDQo+IGVxdWFsaXplIHRoZSB0cmVhdG1lbnQgb2YgYSBzbWFsbCBwYWNrZXQgbG9zcyB3aGV0 aGVyIGl0IGhhcHBlbmVkIGluIHRoZQ0KPiBtaWRkbGUgb2YgYSBidXJzdCBvciB0aGUgZW5kLiBX aHkgc2hvdWxkIGFuIGlzb2xhdGVkIGxvc3MgYmUgdHJlYXRlZA0KPiBkaWZmZXJlbnRseSBiYXNl ZCBvbiBpdHMgcG9zaXRpb24gaW4gdGhlIGJ1cnN0PyBUaGlzIGlzIGp1c3QgYSBsb2dpY2FsDQo+ IGV4dGVuc2lvbiBvZiBmYXN0IHJldHJhbnNtaXQsIHdoaWNoIGFsc28gbW9kaWZpZWQgdGhlIFJU TyBwYXJhZGlnbS4gVGhlDQo+IHdvcmtpbmcgZ3JvdXAgY29uc2Vuc3VzIGlzIHRoYXQgdGhpcyBp cyBhIGZlYXR1cmUsIG5vdCBhIGJ1ZzsgeW91J3JlIHdlbGNvbWUNCj4gdG8gZmVlbCBvdGhlcndp c2UgYnV0IEkgc3VzcGVjdCB5b3UncmUgaW4gdGhlIHJvdWdoIGhlcmUuDQo+DQo+IFJlZ2FyZHMN Cj4gTWFydGluDQo+DQo+DQo+IE9uIFdlZCwgRGVjIDE2LCAyMDIwIGF0IDQ6MTEgUE0gTWFya2t1 IEtvam8gPGtvam9AY3MuaGVsc2lua2kuZmk8bWFpbHRvOmtvam9AY3MuaGVsc2lua2kuZmk+PiB3 cm90ZToNCj4gICAgICAgSGkgTWFydGluLA0KPg0KPiAgICAgICBTZWUgaW5saW5lLg0KPg0KPiAg ICAgICBPbiBXZWQsIDE2IERlYyAyMDIwLCBNYXJ0aW4gRHVrZSB3cm90ZToNCj4NCj4gICAgICAg PiBIaSBNYXJra3UsDQo+ICAgICAgID4NCj4gICAgICAgPiBUaGVyZSBpcyBhIHRvbiBoZXJlLCBi dXQgSSdsbCB0cnkgdG8gYWRkcmVzcyB0aGUgdG9wIHBvaW50cy4NCj4gICAgICAgSG9wZWZ1bGx5 DQo+ICAgICAgID4gdGhleSBvYnZpYXRlIHRoZSByZXN0Lg0KPg0KPiAgICAgICBTb3JyeSBmb3Ig YmVpbmcgdmVyYm9zZS4gSSB0cmllZCB0byBiZSBjbGVhciBidXQgeW91IGFjdHVhbGx5DQo+ICAg ICAgIHJlbW92ZWQgbXkNCj4gICAgICAga2V5IGlzc3Vlcy9xdWVzdGlvbnMgOykNCj4NCj4gICAg ICAgPiAxLg0KPiAgICAgICA+IFtNYXJra3VdDQo+ICAgICAgID4gIkhtbSwgbm90IHN1cmUgd2hh dCB5b3UgbWVhbiBieSAidGhpcyBpcyBhIG5ldyBsb3NzIGRldGVjdGlvbg0KPiAgICAgICBhZnRl cg0KPiAgICAgICA+IGFja25vd2xlZGdtZW50IG9mIG5ldyBkYXRhIj8NCj4gICAgICAgPiBCdXQg YW55d2F5LCBSRkMgNTY4MSBnaXZlcyB0aGUgZ2VuZXJhbCBwcmluY2lwbGUgdG8gcmVkdWNlDQo+ ICAgICAgIGN3bmQgYW5kDQo+ICAgICAgID4gc3N0aHJlc2ggdHdpY2UgaWYgYSByZXRyYW5zbWlz c2lvbiBpcyBsb3N0IGJ1dCBJTUhPIChhbmQgSQ0KPiAgICAgICBiZWxpZXZlIG1hbnkNCj4gICAg ICAgPiB3aG8gaGF2ZSBkZXNpZ25lZCBuZXcgbG9zcyByZWNvdmVyeSBhbmQgQ0MgYWxnb3JpdGht cyBvcg0KPiAgICAgICBpbXBsZW1lbnRlZA0KPiAgICAgICA+IHRoZW0NCj4gICAgICAgPiBhZ3Jl ZSkgdGhhdCBpdCBpcyBoYXJkIHRvIGdldCB0aGluZ3MgcmlnaHQgaWYgb25seSBjb25nZXN0aW9u DQo+ICAgICAgIGNvbnRyb2wNCj4gICAgICAgPiBwcmluY2lwbGVzIGFyZSBhdmFpbGFibGUgYW5k IG5vIGFsZ29yaXRobS4iDQo+ICAgICAgID4NCj4gICAgICAgPiBbTWFydGluXQ0KPiAgICAgICA+ IFNvIDY2NzUgU2VjIDUgaXMgcXVpdGUgZXhwbGljaXQgdGhhdCB0aGVyZSBpcyBvbmx5IG9uZSBj d25kDQo+ICAgICAgIHJlZHVjdGlvbg0KPiAgICAgICA+IHBlciBmYXN0IHJlY292ZXJ5IGVwaXNv ZGUsIHdoaWNoIGVuZHMgb25jZSBuZXcgZGF0YSBoYXMgYmVlbg0KPiAgICAgICA+IGFja25vd2xl ZGdlZC4NCj4NCj4gICAgICAgVG8gYmUgbW9yZSBwcmVjaXNlOiBmYXN0IHJlY292ZXJ5IGVuZHMg d2hlbiB0aGUgY3VycmVudCB3aW5kb3cNCj4gICAgICAgYmVjb21lcw0KPiAgICAgICBjdW11bGF0 aXZlbHkgYWNrbm93bGVkZ2VkLCB0aGF0IGlzLA0KPg0KPiAgICAgICAoNC4xKSBSZWNvdmVyeVBv aW50ICg9IEhpZ2hEYXRhIGF0IHRoZSBiZWdpbm5pbmcpIGJlY29tZXMNCj4gICAgICAgYWNrbm93 bGVkZ2VkDQo+DQo+ICAgICAgIEkgYmVsaWV2ZSB3ZSBhZ3JlZSBhbmQgeW91IG1lYW50IHRoaXMg YWx0aG91Z2ggbmV3IGRhdGEgYmVsb3cNCj4gICAgICAgUmVjb3ZlcnlQb2ludCBtYXkgYmVjb21l IGN1bXVsYXRpdmVseSBhY2tub3dsZWRnZWQgYWxyZWFkeQ0KPiAgICAgICBlYXJsaWVyDQo+ICAg ICAgIGR1cmluZyB0aGUgZmFzdCByZWNvdmVyeS4gUmVubyBsb3NzIHJlY292ZXJ5IGluIFJGQyA1 NjgxIGVuZHMsDQo+ICAgICAgIHdoZW4NCj4gICAgICAgKGFueSkgbmV3IGRhdGEgaGFzIGJlZW4g YWNrbm93bGVkZ2VkLg0KPg0KPiAgICAgICA+IEJ5IGRlZmluaXRpb24sIGlmIGEgcmV0cmFuc21p c3Npb24gaXMgbG9zdCBpdCBpcyBiZWNhdXNlDQo+ICAgICAgID4gbmV3ZXIgZGF0YSBoYXMgYmVl biBhY2tub3dsZWRnZWQsIHNvIGl0J3MgYSBuZXcgcmVjb3ZlcnkNCj4gICAgICAgZXBpc29kZS4N Cj4NCj4gICAgICAgTm90IHN1cmUgd2hlcmUgeW91IGhhdmUgdGhpcyBkZWZpbml0aW9uPyBOZXdl ciB0aGFuIHdoYXQgYXJlIHlvdQ0KPiAgICAgICByZWZlcnJpbmcgdG8/DQo+DQo+ICAgICAgIEJ1 dCwgeWVzLCBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3Qgd2l0aCBSRkMgNjY3NSBhbGdvcml0 aG0sDQo+ICAgICAgIGl0IHJlcXVpcmVzIFJUTyB0byBiZSBkZXRlY3RlZCBhbmQgZGVmaW5pdGVs eSBzdGFydHMgYSBuZXcNCj4gICAgICAgcmVjb3ZlcnkNCj4gICAgICAgZXBpc29kZS4gVGhhdCBp cywgYSBuZXcgcmVjb3ZlcnkgZXBpc29kZSBpcyBlbmZvcmNlZCBieSBzdGVwDQo+ICAgICAgICgx LmEpIG9mDQo+ICAgICAgIE5leHRTZWcgKCkgd2hpY2ggcHJldmVudHMgcmV0cmFuc21pc3Npb24g aWYgYSBzZWdtZW50IHRoYXQgaGFzDQo+ICAgICAgIGFscmVhZHkNCj4gICAgICAgYmVlbiByZXRy YW5zbWl0dGVkLiBJZiBSQUNLLVRMUCBpcyB1c2VkIGZvciBkZXRlY3RpbmcgbG9zcyB3aXRoDQo+ ICAgICAgIFJGQyA2Njc1DQo+ICAgICAgIHRoaW5ncyBnZXQgZGlmZmVyZW50IGluIG1hbnkgd2F5 cywgYmVjYXVzZSBpdCBtYXkgZGV0ZWN0IGxvc3Mgb2YNCj4gICAgICAgYQ0KPiAgICAgICByZXRy YW5zbWlzc2lvbi4gSXQgd291bGQgcHJldHR5IG11Y2ggcmVxdWlyZSBhbiBlbnRpcmUgcmVkZXNp Z24NCj4gICAgICAgb2YgdGhlIGFsZ29yaXRoLiBGb3IgZXhhbXBsZSwgY2FsY3VsYXRpb24gb2Yg cGlwZSBkb2VzIG5vdA0KPiAgICAgICBjb25zaWRlcg0KPiAgICAgICBzZWdtZW50cyB0aGF0IGhh dmUgYmVlbiByZXRyYW5zbWl0dGVkIG1vcmUgdGhhbiBvbmNlLg0KPg0KPiAgICAgICA+IE1lYW53 aGlsZSwgZHVyaW5nIHRoZSBGYXN0IFJlY292ZXJ5IHBlcmlvZCB0aGUgaW5jb21pbmcgYWNrcw0K PiAgICAgICBpbXBsaWNpdGx5DQo+ICAgICAgID4gcmVtb3ZlIGRhdGEgZnJvbSB0aGUgbmV0d29y ayBhbmQgdGhlcmVmb3JlIGtlZXAgZmxpZ2h0c2l6ZQ0KPiAgICAgICBsb3cuDQo+DQo+ICAgICAg IEluY29ycmVjdC4gRmxpZ2h0U2l6ZSAhPSBwaXBlLiBPbmx5IGN1bXVsYXRpdmUgYWNrcyByZW1v dmUgZGF0YQ0KPiAgICAgICBmcm9tDQo+ICAgICAgIEZsaWdodFNpemUgYW5kIG5ldyBkYXRhIHRy YW5zbWl0dGVkIGR1cmluZyBmYXN0IHJlY292ZXJ5IGluZmxhdGUNCj4gICAgICAgRmxpZ2h0U2l6 ZS4gSG93IEZsaWdodFNpemUgZXZvbHZlcyBkZXBlbmRzIG9uIGxvc3MgcGF0dGVybiBhcyBJDQo+ ICAgICAgIHNhaWQuDQo+ICAgICAgIEl0IGlzIGFsc28gcG9zc2libGUgdGhhdCBGbGlnaHRTaXpl IGlzIGxvdywgaXQgbWF5IGVyciBpbiBib3RoDQo+ICAgICAgIGRpcmVjdGlvbnMuIEEgc2ltcGxl IGV4YW1wbGUgY2FuIGJlIHVzZWQgYXMgYSBwcm9vZiBmb3IgdGhlIGNhc2UNCj4gICAgICAgd2hl cmUNCj4gICAgICAgY3duZCBpbmNyZWFzZXMgaWYgYSBsb3NzIG9mIHJldHJhbnNtaXNzaW9uIGlz IGRldGVjdGVkIGFuZA0KPiAgICAgICByZXBhaXJlZDoNCj4NCj4gICAgICAgUkZDIDY2NzUgcmVj b3Zlcnkgd2l0aCBSQUNLLVRMUCBsb3NzIGRldGVjdGlvbjoNCj4gICAgICAgKGNvbnRhaW5zIHNv bWUgaW5hY2N1cmFjaWVzIGJlY2F1c2UgaXQgaGFzIG5vdCBiZWVuIGRlZmluZWQgaG93DQo+ICAg ICAgIGxvc3QgcmV4bWl0cyBhcmUgY2FsY3VsYXRlZCBpbnRvIHBpcGUpDQo+DQo+ICAgICAgIGN3 bmQ9MjA7IHBhY2tldHMgUDEsLi4uLFAyMCBpbiBmbGlnaHQgPSBjdXJyZW50IHdpbmRvdyBvZiBk YXRhDQo+ICAgICAgIFtQMSBkcm9wcGVkIGFuZCByZXhtaXQgb2YgUDEgd2lsbCBhbHNvIGJlIGRy b3BwZWRdDQo+DQo+ICAgICAgIER1cEFjayB3L1NBQ0sgZm9yIFAyIGFycml2ZXMNCj4gICAgICAg W2xvc3Mgb2YgUDEgZGV0ZWN0ZWQgYWZ0ZXIgb25lIFJUVCBmcm9tIG9yaWdpbmFsIHhtaXQgb2Yg UDFdDQo+ICAgICAgIFtjd25kPXNzdGhyZXNoPTEwXQ0KPiAgICAgICBQMSBpcyByZXhtaXR0ZWQg KGFuZCBpdCBsb2dpY2FsbHkgc3RhcnRzIG5leHQgd2luZG93IG9mIGRhdGEpDQo+DQo+ICAgICAg IER1cEFja3Mgdy8gU0FDSyBmb3Igb3JpZ2luYWwgUDMuLjExIGFycml2ZQ0KPiAgICAgICBEdXBB Y2sgdy8gU0FDSyBmb3Igb3JpZ2luYWwgUDEyIGFycml2ZXMNCj4gICAgICAgW2N3bmQtcGlwZSA9 IDEwLTkgPj0xXQ0KPiAgICAgICBzZW5kIFAyMQ0KPiAgICAgICBEdXBBY2sgdy9TQUNLIGZvciBQ MTMgYXJyaXZlcw0KPiAgICAgICBzZW5kIFAyMg0KPiAgICAgICAuLi4NCj4gICAgICAgRHVwQWNr IHcvU0FDSyBmb3IgUDIwIGFycml2ZXMNCj4gICAgICAgc2VuZCBQMjkNCj4gICAgICAgW0ZsaWdo dFNpemU9MjldDQo+DQo+ICAgICAgIChBY2sgZm9yIHJleG1pdCBvZiBQMSB3b3VsZCBhcnJpdmUg aGVyZSB1bmxlc3MgaXQgZ290IGRyb3BwZWQpDQo+DQo+ICAgICAgIER1cEFjayB3L1NBQ0sgZm9y IFAyMSBhcnJpdmVzDQo+ICAgICAgIFtsb3NzIG9mIHJleG1pdCBQMSBkZXRlY3RlZCBhZnRlciBv bmUgUlRUIGZyb20gcmV4bWl0IG9mIFAxXQ0KPg0KPiAgICAgICBTRVQgY3duZCA9IHNzdGhyZXNo ID0gRmxpZ2h0U2l6ZS8yPSAyOS8yID0gMTQsNQ0KPg0KPiAgICAgICBDV05EIElOQ1JFQVNFUyB3 aGVuIGl0IHNob3VsZCBiZSBhdCBtb3N0IDUgYWZ0ZXIgaGFsdmluZyBpdA0KPiAgICAgICB0d2lj ZSEhIQ0KPg0KPiAgICAgICA+IFdlIGNhbiBjb250aW51ZSB0byBnbyBhcm91bmQgb24gb3VyIGlu dGVycHJldGF0aW9uIG9mIHRoZXNlDQo+ICAgICAgIGRvY3VtZW50cywNCj4gICAgICAgPiBidXQg ZnVuZGFtZW50YWxseSBpZiB0aGVyZSBpcyBhbWJpZ3VpdHkgaW4gNTY4MS82Njc1IHdlIHNob3Vs ZA0KPiAgICAgICBiaXMNCj4gICAgICAgPiB0aG9zZSBSRkNzIHJhdGhlciB0aGFuIGV4cGFuZCB0 aGUgc2NvcGUgb2YgUkFDSy4NCj4NCj4gICAgICAgQXMgSSBzYWlkIGVhcmxpZXIsIEkgYW0gbm90 IG9wcG9zaW5nIGJpcywgdGhvdWdoIDU2ODFiaXMgd3VvbGQNCj4gICAgICAgbm90DQo+ICAgICAg IGJlIG5lZWRlZCwgSSB0aGluay4NCj4NCj4gICAgICAgQnV0IGxldCBtZSByZXBlYXQ6IGlmIHdl IHB1Ymxpc2ggUkFDSy1UTFAgbm93IHdpdGhvdXQgbmVjZXNzYXJ5DQo+ICAgICAgIHdhcm5pbmdz DQo+ICAgICAgIG9yIHdpdGggYSBjb3JyZWN0IGNvbmdlc2lvbiBjb250cm9sIGFsZ29yaXRobSBz b21lb25lIHdpbGwgdHJ5DQo+ICAgICAgIHRvDQo+ICAgICAgIGltcGxlbWVudCBSQUNLLVRMUCB3 aXRoIFJGQyA2Njc1IGFuZCBpdCB3aWxsIGJlIGEgdG90YWwgbWVzaC4NCj4gICAgICAgVGhlDQo+ ICAgICAgIGJlaGF2aW9yIHdpbGwgYmUgdW5wcmVkaWN0YWJsZSBhbmQgcXVpdGUgbGlrZWx5IHVu c2FmZQ0KPiAgICAgICBjb25nZXN0aW9uDQo+ICAgICAgIGNvbnRyb2wgYmVoYXZpb3IuDQo+DQo+ ICAgICAgID4gMi4NCj4gICAgICAgPiBbTWFya2t1XQ0KPiAgICAgICA+ICIgSW4gc2hvcnQ6DQo+ ICAgICAgID4gV2hlbiB3aXRoIGEgbm9uLVJBQ0stVExQIGltcGxlbWVudGF0aW9uIHRpbWVyIChS VE8pIGV4cGlyZXM6DQo+ICAgICAgIGN3bmQ9MQ0KPiAgICAgICA+IE1TUywNCj4gICAgICAgPiBh bmQgc2xvdyBzdGFydCBpcyBlbnRlcmVkLg0KPiAgICAgICA+IFdoZW4gd2l0aCBhIFJBQ0tfVExQ IGltcGxlbWVudGF0aW9uIHRpbWVyIChQVE8pIGV4cGlyZXMsDQo+ICAgICAgID4gbm9ybWFsIGZh c3QgcmVjb3ZlcnkgaXMgZW50ZXJlZCAodW5sZXNzIGltcGxlbWVudGluZw0KPiAgICAgICA+IGFs c28gUFJSKS4gU28gbm8gUlRPIHJlY292ZXJ5IGFzIGV4cGxpY2l0bHkgc3RhdGVkIGluIFNlYy4N Cj4gICAgICAgNy40LjEuIg0KPiAgICAgICA+DQo+ICAgICAgID4gW01hcnRpbl0NCj4gICAgICAg PiBUaGVyZSBtYXkgYmUgYSBtaXN1bmRlcnN0YW5kaW5nIGhlcmUuIFBUTyBpcyBub3QgdGhlIHNh bWUgYXMNCj4gICAgICAgUlRPLCBhbmQNCj4gICAgICAgPiBib3RoIG1lY2hhbmlzbXMgZXhpc3Qh IFRoZSBsb3NzIHJlc3BvbnNlIHRvIGEgUFRPIGlzIHRvIHNlbmQgYQ0KPiAgICAgICBwcm9iZTsN Cj4gICAgICAgPiB0aGUgUlRPIHJlc3BvbnNlIGlzIGFzIHdpdGggY29udmVudGlvbmFsIFRDUC4g SW4gU2VjdGlvbiA3LjM6DQo+DQo+ICAgICAgIE5vLCBJIGRvbid0IHRoaW5rIEkgbWlzdW5kZXJz dG9vZC4gSWYgeW91IGNhbGwgdGltZW91dCB3aXRoDQo+ICAgICAgIGFub3RoZXIgbmFtZSwgaXQg aXMgc3RpbGwgdGltZW91dC4gQW5kIGNvbmdlc3Rpb24gY29udHJvbCBkb2VzDQo+ICAgICAgIG5v dA0KPiAgICAgICBjb25zaWRlciB3aGljaCBzZWdtZW50cyB0byBzZW5kIChTTkQuVU5BIHZzLiBw cm9iZSB3LyBoaWdoZXINCj4gICAgICAgc2VxdWVuY2UNCj4gICAgICAgbnVtYmVyKSwgb25seSBo b3cgbXVjaCBpcyBzZW50Lg0KPg0KPiAgICAgICBZb3UgaWdub3JlZCBteSBtYWpvciBwb2ludCB3 aGVyZSBJIGRlY291cGxlZCBjb25nZXN0aW9uIGNvbnRyb2wNCj4gICAgICAgZnJvbSBsb3NzDQo+ ICAgICAgIGRldGVjdGlvbiBhbmQgbG9zcyByZWNvdmVyeSBhbmQgY29tcGFyZWQgUkZDIDU2ODEg YmVoYXZpb3IgdG8NCj4gICAgICAgUkFDSy1UTFANCj4gICAgICAgYmVoYXZpb3IgaW4gZXhhY3Rs eSB0aGUgc2FtZSBzY2VuYXJpbyB3aGVyZSBhbiBlbnRpcmUgZmxpZ2h0IGlzDQo+ICAgICAgIGxv c3QgYW5kDQo+ICAgICAgIHRpbWVyIGV4cGlyZXMuDQo+DQo+ICAgICAgIFBsZWFzZSBjb21tZW50 IHdoeSBjb25nZXN0aW9uIGNvbnRyb2wgYmVoYXZpb3IgaXMgYWxsb3dlZCB0byBiZQ0KPiAgICAg ICByYWRpY2FsbHkNCj4gICAgICAgZGlmZmVyZW50IGluIHRoZXNlIHR3byBpbXBsZW1lbnRhdGlv bnM/DQo+DQo+ICAgICAgIFJGQyA1NjgxICYgUkZDIDYyOTggdGltZW91dDoNCj4NCj4gICAgICAg ICAgICAgICBSVE89U1JUVCs0KlJUVFZBUiAoUlRPIHVzZWQgZm9yIGFybWluZyB0aGUgdGltZXIp DQo+ICAgICAgICAgICAgICAxLiBSVE8gdGltZXIgZXhwaXJlcw0KPiAgICAgICAgICAgICAgMi4g Y3duZD0xIE1TUzsgc3N0aHJlc2g9RmxpZ2h0U2l6ZS8yOyByZXhtaXQgb25lIHNlZ21lbnQNCj4g ICAgICAgICAgICAgIDMuIEFjayBvZiByZXhtaXQgc2VudCBpbiBzdGVwIDIgYXJyaXZlcw0KPiAg ICAgICAgICAgICAgNC4gY3duZCA9IGN3bmQrMSBNU1M7IHNlbmQgdHdvIHNlZ21lbnRzDQo+ICAg ICAgICAgICAgICAuLi4NCj4NCj4gICAgICAgUkFDSy1UTFAgdGltZW91dDoNCj4NCj4gICAgICAg ICAgICAgICBQVE89bWluKDIqU1JUVCxSVE8pIChQVE8gdXNlZCBmb3IgYXJtaW5nIHRoZSB0aW1l cikNCj4gICAgICAgICAgICAgIDEuIFBUTyB0aW1lcyBleHBpcmVzDQo+ICAgICAgICAgICAgICAy LiAoY3duZD0xIE1TUyk7IChyZSl4bWl0IG9uZSBzZWdtZW50DQo+ICAgICAgICAgICAgICAzLiBB Y2sgb2YgKHJlKXhtaXQgc2VudCBpbiBzcmVwIDIgYXJyaXZlcw0KPiAgICAgICAgICAgICAgNC4g Y3duZCA9IHNzdGhyZXNoID0gRmxpZ2h0U2l6ZS8yOyBzZW5kIE49Y3duZCBzZWdtZW50cw0KPg0K PiAgICAgICBJZiBGbGlnaHRTaXplIGlzIDEwMCBzZWdtZW50cyB3aGVuIHRpbWVyIGV4cGlyZXMs IGNvbmdlc3Rpb24NCj4gICAgICAgY29udHJvbCBpcw0KPiAgICAgICB0aGUgc2FtZSBpbiBzdGVw cyAxLTMsIGJ1dCBpbiBzdGVwIDQgdGhlIHN0YW5kYXJkIGNvbmdlc3Rpb24NCj4gICAgICAgY29u dHJvbA0KPiAgICAgICBhbGxvd3MgdHJhbnNtaXR0aW5nIDIgc2VnbWVudHMsIHdoaWxlIFJBQ0st VExQIHdvdWxkIGFsbG93DQo+ICAgICAgIGJsYXN0aW5nIDUwIHNlZ21lbnRzLg0KPg0KPiAgICAg ICA+IEFmdGVyIGF0dGVtcHRpbmcgdG8gc2VuZCBhIGxvc3MgcHJvYmUsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBhDQo+ICAgICAgIGxvc3MNCj4gICAgICAgPiAgICBwcm9iZSB3YXMgc2VudCwgdGhl IHNlbmRlciBNVVNUIHJlLWFybSB0aGUgUlRPIHRpbWVyLCBub3QNCj4gICAgICAgdGhlIFBUTw0K PiAgICAgICA+ICAgIHRpbWVyLCBpZiBGbGlnaHRTaXplIGlzIG5vdCB6ZXJvLiAgVGhpcyBlbnN1 cmVzIFJUTw0KPiAgICAgICByZWNvdmVyeSByZW1haW5zDQo+ICAgICAgID4gICAgdGhlIGxhc3Qg cmVzb3J0IGlmIFRMUCBmYWlscy4NCj4gICAgICAgPiAiDQo+DQo+ICAgICAgIFRoaXMgZG9lcyBu b3QgcHJldmVudCB0aGUgYWJvdmUgUkFDSy1UTFAgYmVoYXZpb3IgZnJvbSBnZXR0aW5nDQo+ICAg ICAgIHJlYWxpemVkLg0KPg0KPiAgICAgICA+IFNvIGEgcHVyZSBSVE8gcmVzcG9uc2UgZXhpc3Rz IGluIHRoZSBjYXNlIG9mIHBlcnNpc3RlbnQNCj4gICAgICAgY29uZ2VzdGlvbiB0aGF0DQo+ICAg ICAgID4gY2F1c2VzIGxvc3NlcyBvZiBwcm9iZXMgb3IgdGhlaXIgQUNLcy4NCj4NCj4gICAgICAg WWVzLCBSVE8gcmVzcG9uc2UgZXhpc3RzIEJVVCBvbmx5IGFmdGVyIFJBQ0stVExQIGF0IGxlYXN0 IG9uY2UNCj4gICAgICAgYmxhc3RzIHRoZQ0KPiAgICAgICBuZXR3b3JrLiBJdCBtYXkgd2VsbCBi ZSB0aGF0IHdpdGggc21hbGxlciB3aW5kb3dzIFJBQ0stVExQIGlzDQo+ICAgICAgIHN1Y2Nlc3Nm dWwNCj4gICAgICAgZHVyaW5nIGl0cyBUTFAgaW5pdGlhdGVkIG92ZXJseSBhZ2dyZXNzaXZlICJm YXN0IHJlY292ZXJ5IiBhbmQNCj4gICAgICAgbmV2ZXINCj4gICAgICAgZW50ZXJzIFJUTyByZWNv dmVyeSBiZWNhdXNlIGl0IG1heSBkZXRlY3QgYW5kIHJlcGFpciBhbHNvIGxvc3MNCj4gICAgICAg b2YNCj4gICAgICAgcmV4bWl0cy4gVGhhdCBpcywgaXQgY29udGludWVzIGF0IHRvbyBoaWdoIHJh dGUgZXZlbiBpZiBsb3N0DQo+ICAgICAgIHJleG1pdHMNCj4gICAgICAgaW5kaWNhdGUgdGhhdCBj b25nZXN0aW9uIHBlcnNpc3RzIGluIHN1Y2Nlc3NpdmUgd2luZG93cyBvZiBkYXRhLg0KPiAgICAg ICBBbmQNCj4gICAgICAgd29yc2UsIGl0IGlzIHN1Y2Nlc3NmdWwgYmVjYXVzZSBpdCBwdXNoZXMg YXdheSBvdGhlciBjb21wYXRpYmxlDQo+ICAgICAgIFRDUA0KPiAgICAgICBmbG93cyBieSBiZWlu ZyB0b28gYWdncmVzc2l2ZSBhbmQgdW5mYWlyLg0KPg0KPiAgICAgICBFdmVuIGEgc2luZ2xlIHNo b3QgYnVyc3QgZXZlcnkgdGltZSB0aGVyZSBpcyBzaWduaWZpY2FudCBsb3NzDQo+ICAgICAgIGV2 ZW50IGlzIG5vdCBhY2NlcHRhYmxlLCBub3QgdG8gbWVudGlvbiBjb250aW51b3VzDQo+ICAgICAg IGFnZ3Jlc3NpdmVuZXNzLCBhbmQNCj4gICAgICAgdGhpcyBpcyBleGFjdGx5IHdoYXQgUkZDIDI5 MTQgYW5kIFJGQyA1MDMzIGV4cGxpY2l0bHkgYWRkcmVzcw0KPiAgICAgICBhbmQgd2Fybg0KPiAg ICAgICBhYm91dC4NCj4NCj4gICAgICAgQXJlIHdlIGlnbm9yaW5nIHRoZXNlIEJDUHMgdGhhdCBo YXZlIElFVEYgY29uc2Vuc3VzPw0KPg0KPiAgICAgICBBbmQgdGhlIG90aGVyIGltcG9ydGFudCBx dWVzdGlvbiBJJ2QgbGlrZSB0byBoYXZlIGFuIGFuc3dlcjoNCj4NCj4gICAgICAgV2hhdCBpcyB0 aGUganVzdGlmaWNhdGlvbiB0byBtb2RpZnkgc3RhbmRhcmQgVENQIGNvbmdlc3Rpb24NCj4gICAg ICAgY29udHJvbCB0bw0KPiAgICAgICB1c2UgZmFzdCByZWNvdmVyeSBpbnN0ZWFkIG9mIHNsb3cg c3RhcnQgZm9yIGEgY2FzZSB3aGVyZSB0aW1lb3V0DQo+ICAgICAgIGlzDQo+ICAgICAgIG5lZWRl ZCB0byBkZXRlY3QgdGhlIHBhY2tldCBsb3NzZXMgYmVjYXVzZSB0aGVyZSBpcyBubyBmZWVkYmFj aw0KPiAgICAgICBhbmQgYWNrDQo+ICAgICAgIGNsb2NrIGlzIGxvc3Q/IFJBQ0stVExQIGV4cGxp Y2l0bHkgaW5zdHJ1Y3RzIHRvIGRvIHNvIGluIFNlYy4NCj4gICAgICAgNy40LjEuDQo+DQo+ICAg ICAgIEFzIEkgbm90ZWQ6IGJhc2VkIG9uIHdoYXQgaXMgd3JpdHRlbiBpbiB0aGUgZHJhZnQgaXQg ZG9lcyBub3QNCj4gICAgICAgaW50ZW5kIHRvDQo+ICAgICAgIGNoYW5nZSBjb25nZXN0aW9uIGNv bnRyb2wgYnV0IGVmZmVjdGl2ZWx5IGl0IGRvZXMuDQo+DQo+ICAgICAgIC9NYXJra3UNCj4NCj4g ICAgICAgPiBNYXJ0aW4NCj4gICAgICAgPg0KPiAgICAgICA+DQo+ICAgICAgID4gT24gV2VkLCBE ZWMgMTYsIDIwMjAgYXQgMTE6MzkgQU0gTWFya2t1IEtvam8NCj4gICAgICAgPGtvam9AY3MuaGVs c2lua2kuZmk8bWFpbHRvOmtvam9AY3MuaGVsc2lua2kuZmk+Pg0KPiAgICAgICA+IHdyb3RlOg0K PiAgICAgICA+ICAgICAgIEhpIE1hcnRpbiwNCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIE9u IFR1ZSwgMTUgRGVjIDIwMjAsIE1hcnRpbiBEdWtlIHdyb3RlOg0KPiAgICAgICA+DQo+ICAgICAg ID4gICAgICAgPiBIaSBNYXJra3UsDQo+ICAgICAgID4gICAgICAgPg0KPiAgICAgICA+ICAgICAg ID4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMuIFRoZSBhdXRob3JzIHdpbGwgaW5jb3Jwb3JhdGUN Cj4gICAgICAgPiAgICAgICBtYW55IG9mIHlvdXINCj4gICAgICAgPiAgICAgICA+IHN1Z2dlc3Rp b25zIGFmdGVyIHRoZSBJRVNHIHJldmlldy4NCj4gICAgICAgPiAgICAgICA+DQo+ICAgICAgID4g ICAgICAgPiBUaGVyZSdzIG9uZSB0aGluZyBJIGRvbid0IHVuZGVyc3RhbmQgaW4geW91ciBjb21t ZW50czoNCj4gICAgICAgPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgPiAiIFRoYXQgaXMsDQo+ ICAgICAgID4gICAgICAgPiB3aGVyZSBjYW4gYW4gaW1wbGVtZW50ZXIgZmluZCBhZHZpY2UgZm9y IGNvcnJlY3QNCj4gICAgICAgPiAgICAgICBjb25nZXN0aW9uIGNvbnRyb2wNCj4gICAgICAgPiAg ICAgICA+IGFjdGlvbnMgd2l0aCBSQUNLLVRMUCwgd2hlbjoNCj4gICAgICAgPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgPiAoMSkgYSBsb3NzIG9mIHJleG1pdHRlZCBzZWdtZW50IGlzIGRldGVj dGVkDQo+ICAgICAgID4gICAgICAgPiAoMikgYW4gZW50aXJlIGZsaWdodCBvZiBkYXRhIGdldHMg ZHJvcHBlZCAoYW5kDQo+ICAgICAgIGRldGVjdGVkKSwNCj4gICAgICAgPiAgICAgICA+ICAgICAg dGhhdCBpcywgd2hlbiB0aGVyZSBpcyBubyBmZWVkYmFjayBhdmFpbGFibGUgYW5kDQo+ICAgICAg IGENCj4gICAgICAgPiAgICAgICB0aW1lb3V0DQo+ICAgICAgID4gICAgICAgPiAgICAgIGlzIG5l ZWRlZCB0byBkZXRlY3QgdGhlIGxvc3MgIg0KPiAgICAgICA+ICAgICAgID4NCj4gICAgICAgPiAg ICAgICA+IFNlY3Rpb24gOS4zIGlzIHRoZSBkaXNjdXNzaW9uIGFib3V0IENDLCBhbmQgaXMgY2xl YXINCj4gICAgICAgdGhhdA0KPiAgICAgICA+ICAgICAgIHRoZQ0KPiAgICAgICA+ICAgICAgID4g aW1wbGVtZW50ZXIgc2hvdWxkIHVzZSBlaXRoZXIgNTY4MSBvciA2OTM3Lg0KPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgSnVzdCBhIGNpdGUgbml0OiBSRkMgNTY4MSBwcm92aWRlcyBiYXNpYyBD QyBjb25jZXB0cyBhbmQNCj4gICAgICAgPiAgICAgICBzb21lIHVzZWZ1bCBDQw0KPiAgICAgICA+ ICAgICAgIGd1aWRlbGluZXMgYnV0IGdpdmVuIHRoYXQgUkFDSy1UTFAgTVVTVCBpbXBsZW1lbnQg U0FDSw0KPiAgICAgICB0aGUNCj4gICAgICAgPiAgICAgICBhbGdvcml0aG0gaW4NCj4gICAgICAg PiAgICAgICBSRkMgNTY4MSBpcyBub3QgdGhhdCB1c2VmdWwgYW5kIGFuIGltcGxlbWVudGVyIHF1 aXRlDQo+ICAgICAgIGxpa2VseQ0KPiAgICAgICA+ICAgICAgIGZvbGxvd3MNCj4gICAgICAgPiAg ICAgICBtYWlubHkgdGhlIGFsZ29yaXRobSBpbiBSRkMgNjY3NSAoYW5kIG5vdCBSRkMgNjkzNyBh dA0KPiAgICAgICBhbGwNCj4gICAgICAgPiAgICAgICBpZiBub3QNCj4gICAgICAgPiAgICAgICBp bXBsZW1lbnRpbmcgUFJSKS4NCj4gICAgICAgPiAgICAgICBBbmQgUkZDIDY2NzUgaXMgbm90IG1l bnRpb25lZCBpbiBTZWMgOS4zLCB0aG91Z2ggaXQgaXMNCj4gICAgICAgPiAgICAgICBsaXN0ZWQg aW4gdGhlDQo+ICAgICAgID4gICAgICAgU2VjLiA0IChSZXF1aXJlbWVudHMpLg0KPiAgICAgICA+ DQo+ICAgICAgID4gICAgICAgPiBZb3Ugd2VudCB0aHJvdWdoIHRoZSA2OTM3IGNhc2UgaW4gZGV0 YWlsLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgWWVzLCBidXQgd2l0aG91dCBjb3JyZWN0 IENDIGFjdGlvbnMuDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICA+IElmIDU2ODEsIGl0J3Mg cHJldHR5IGNsZWFyIHRvIG1lIHRoYXQgaW4gKDEpIHRoaXMgaXMgYQ0KPiAgICAgICA+ICAgICAg IG5ldyBsb3NzDQo+ICAgICAgID4gICAgICAgPiBkZXRlY3Rpb24gYWZ0ZXIgYWNrbm93bGVkZ21l bnQgb2YgbmV3IGRhdGEsIGFuZA0KPiAgICAgICB0aGVyZWZvcmUNCj4gICAgICAgPiAgICAgICBy ZXF1aXJlcyBhDQo+ICAgICAgID4gICAgICAgPiBzZWNvbmQgaGFsdmluZyBvZiBjd25kLg0KPiAg ICAgICA+DQo+ICAgICAgID4gICAgICAgSG1tLCBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICJ0 aGlzIGlzIGEgbmV3IGxvc3MNCj4gICAgICAgPiAgICAgICBkZXRlY3Rpb24gYWZ0ZXINCj4gICAg ICAgPiAgICAgICBhY2tub3dsZWRnbWVudCBvZiBuZXcgZGF0YSI/DQo+ICAgICAgID4gICAgICAg QnV0IGFueXdheSwgUkZDIDU2ODEgZ2l2ZXMgdGhlIGdlbmVyYWwgcHJpbmNpcGxlIHRvDQo+ICAg ICAgIHJlZHVjZQ0KPiAgICAgICA+ICAgICAgIGN3bmQgYW5kDQo+ICAgICAgID4gICAgICAgc3N0 aHJlc2ggdHdpY2UgaWYgYSByZXRyYW5zbWlzc2lvbiBpcyBsb3N0IGJ1dCBJTUhPIChhbmQNCj4g ICAgICAgSQ0KPiAgICAgICA+ICAgICAgIGJlbGlldmUgbWFueQ0KPiAgICAgICA+ICAgICAgIHdo byBoYXZlIGRlc2lnbmVkIG5ldyBsb3NzIHJlY292ZXJ5IGFuZCBDQyBhbGdvcml0aG1zIG9yDQo+ ICAgICAgID4gICAgICAgaW1wbGVtZW50ZWQgdGhlbQ0KPiAgICAgICA+ICAgICAgIGFncmVlKSB0 aGF0IGl0IGlzIGhhcmQgdG8gZ2V0IHRoaW5ncyByaWdodCBpZiBvbmx5DQo+ICAgICAgID4gICAg ICAgY29uZ2VzdGlvbiBjb250cm9sDQo+ICAgICAgID4gICAgICAgcHJpbmNpcGxlcyBhcmUgYXZh aWxhYmxlIGFuZCBubyBhbGdvcml0aG0uDQo+ICAgICAgID4gICAgICAgVGhhdCdzIHdoeSBBTEwg bWVjaGFuaXNtcyB0aGF0IHdlIGhhdmUgaW5jbHVkZSBhIHF1aXRlDQo+ICAgICAgID4gICAgICAg ZGV0YWlsZWQgYWxnb3JpdGhtDQo+ICAgICAgID4gICAgICAgd2l0aCBhbGwgbmVjZXNzYXJ5IHZh cmlhYmxlcyBhbmQgYWN0aW9ucyBmb3IgbG9zcw0KPiAgICAgICByZWNvdmVyeQ0KPiAgICAgICA+ ICAgICAgIGFuZC9vciBDQw0KPiAgICAgICA+ICAgICAgIHB1cnBvc2VzIChhbmQgb2Z0ZW4gYWxz byBwc2V1ZG9jb2RlKS4gTGlrZSB0aGlzIGRvY3VtZW50DQo+ICAgICAgID4gICAgICAgZG9lcyBm b3IgbG9zcw0KPiAgICAgICA+ICAgICAgIGRldGVjdGlvbi4NCj4gICAgICAgPg0KPiAgICAgICA+ ICAgICAgIFNvIHRoZSBwcm9ibGVtIGlzIHRoYXQgd2UgZG8gbm90IGhhdmUgYSBkZXRhaWxlZCBl bm91Z2gNCj4gICAgICAgPiAgICAgICBhbGdvcml0aG0gb3INCj4gICAgICAgPiAgICAgICBydWxl IHRoYXQgdGVsbHMgZXhhY3RseSB3aGF0IHRvIGRvIHdoZW4gYSBsb3NzIG9mIHJleG1pdA0KPiAg ICAgICBpcw0KPiAgICAgICA+ICAgICAgIGRldGVjdGVkLg0KPiAgICAgICA+ICAgICAgIEV2ZW4g d29yc2UsIHRoZSBhbGdvcml0aG1zIGluIFJGQyA1NjgxIGFuZCBSRkMgNjY3NQ0KPiAgICAgICBy ZWZlcg0KPiAgICAgICA+ICAgICAgIHRvDQo+ICAgICAgID4gICAgICAgZXF1YXRpb24gKDQpIG9m IFJGQyA1NjgxIHRvIHJlZHVjZSBzc3RocmVzaCBhbmQgY3duZA0KPiAgICAgICB3aGVuIGENCj4g ICAgICAgPiAgICAgICBsb3NzDQo+ICAgICAgID4gICAgICAgcmVxdWlyaW5nIGEgY29uZ2VzdGlv biBjb250cm9sIGFjdGlvbiBpcyBkZXRlY3RlZDoNCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAg ICAgKGN3bmQgPSkgc3N0aHJlc2ggPSBGbGlnaHRTaXplIC8gMikNCj4gICAgICAgPg0KPiAgICAg ICA+ICAgICAgIEFuZCBSRkMgNTY4MSBnaXZlcyBhIHdhcm5pbmcgbm90IHRvIGhhbHZlIGN3bmQg aW4gdGhlDQo+ICAgICAgID4gICAgICAgZXF1YXRpb24gYnV0DQo+ICAgICAgID4gICAgICAgRmxp Z2h0U2l6ZS4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIFRoYXQgaXMsIHRoaXMgZXF1YXRp b24gaXMgd2hhdCBhbiBpbXBsZW1lbnRlcg0KPiAgICAgICBpbnR1aXRpdmVseQ0KPiAgICAgICA+ ICAgICAgIHdvdWxkIHVzZQ0KPiAgICAgICA+ICAgICAgIHdoZW4gcmVhZGluZyB0aGUgcmVsZXZh bnQgUkZDcyBidXQgaXQgZ2l2ZXMgYSB3cm9uZw0KPiAgICAgICByZXN1bHQNCj4gICAgICAgPiAg ICAgICBmb3INCj4gICAgICAgPiAgICAgICBvdXRzdGFuZGluZyBkYXRhIHdoZW4gaW4gZmFzdCBy ZWNvdmVyeSAod2hlbiB0aGUgc2VuZGVyDQo+ICAgICAgIGlzDQo+ICAgICAgID4gICAgICAgaW4N Cj4gICAgICAgPiAgICAgICBjb25nZXN0aW9uIGF2b2lkYW5jZSBhbmQgdGhlIGVxdWF0aW9uICg0 KSBpcyB1c2VkIHRvDQo+ICAgICAgIGhhbHZlDQo+ICAgICAgID4gICAgICAgY3duZCwgaXQNCj4g ICAgICAgPiAgICAgICBnaXZlcyBhIGNvcnJlY3QgcmVzdWx0KS4NCj4gICAgICAgPiAgICAgICBN b3JlIHByZWNpc2VseSwgZHVyaW5nIGZhc3QgcmVjb3ZlcnkgRmxpZ2h0U2l6ZSBpcw0KPiAgICAg ICBpbmZsYXRlZA0KPiAgICAgICA+ICAgICAgIHdoZW4gbmV3DQo+ICAgICAgID4gICAgICAgZGF0 YSBpcyBzZW50IGFuZCByZWR1Y2VkIHdoZW4gc2VnbWVudHMgYXJlIGN1bXVsYXRpdmVseQ0KPiAg ICAgICA+ICAgICAgIEFja2VkLg0KPiAgICAgICA+ICAgICAgIFdoYXQgdGhlIG91dGNvbWUgaXMg ZGVwZW5kcyBvbiB0aGUgbG9zcyBwYXR0ZXJuLiBJbiB0aGUNCj4gICAgICAgPiAgICAgICB3b3Jz dCBjYXNlLA0KPiAgICAgICA+ICAgICAgIEZsaWdodFNpemUgaXMgc2lnbmZpY2FudGx5IGxhcmdl ciB0aGFuIGluIHRoZSBiZWdpbm5pbmcNCj4gICAgICAgb2YNCj4gICAgICAgPiAgICAgICB0aGUg ZmFzdA0KPiAgICAgICA+ICAgICAgIHJlY292ZXJ5IHdoZW4gRmxpZ2h0U2l6ZSB3YXMgKGNvcnJl Y3RseSkgdXNlZCB0bw0KPiAgICAgICBkZXRlcm1pbmUNCj4gICAgICAgPiAgICAgICB0aGUgaGFs dmVkDQo+ICAgICAgID4gICAgICAgdmFsdWUgZm9yIGN3bmQgYW5kIHNzdGhyZXNoLCBpLmUuLCBl cXVhdGlvbiAoNCkgbWF5DQo+ICAgICAgIHJlc3VsdA0KPiAgICAgICA+ICAgICAgIGluDQo+ICAg ICAgID4gICAgICAgKmluY3JlYXNpbmcqIGN3bmQgdXBvbiBkZXRlY3RpbmcgYSBsb3NzIG9mIGEg cmV4bWl0dGVkDQo+ICAgICAgID4gICAgICAgc2VnbWVudCwgaW5zdGVhZA0KPiAgICAgICA+ICAg ICAgIG9mIGZ1cnRoZXIgaGFsdmluZyBpdC4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIEEg Y2xldmVyIGltcGxlbWVudGVyIG1pZ2h0IGhhdmUgbm8gcHJvYmxlbSB0byBoYXZlIGl0DQo+ICAg ICAgIHJpZ2h0DQo+ICAgICAgID4gICAgICAgd2l0aCBzb21lDQo+ICAgICAgID4gICAgICAgdGhp bmtpbmcgYnV0IEkgYW0gYWZyYWlkIHRoYXQgdGhlcmUgd2lsbCBiZSBpbmNvcnJlY3QNCj4gICAg ICAgPiAgICAgICBpbXBsZW1lbnRhdGlvbnMNCj4gICAgICAgPiAgICAgICB3aXRoIHdoYXQgaXMg Y3VycmVudGx5IHNwZWNpZmllZC4gTm90IGFsbCBpbXBsZW1lbnRlcnMNCj4gICAgICAgaGF2ZQ0K PiAgICAgICA+ICAgICAgIHNwZW50DQo+ICAgICAgID4gICAgICAgc2lnbmljaWNhbnQgZnJhY3Rp b24gb2YgdGhlaXIgY2FyZWVyIGluIHNvbHZpbmcgVENQDQo+ICAgICAgID4gICAgICAgcGVjdWxp YXJpdGllcy4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgID4gRm9yICgyKSwgdGhlIFJUTyB0 aW1lciBpcyBzdGlsbCBvcGVyYXRpdmUgc28NCj4gICAgICAgPiAgICAgICA+IHRoZSBSVE8gcmVj b3ZlcnkgcnVsZXMgd291bGQgc3RpbGwgZm9sbG93Lg0KPiAgICAgICA+DQo+ICAgICAgID4gICAg ICAgSW4gc2hvcnQ6DQo+ICAgICAgID4gICAgICAgV2hlbiB3aXRoIGEgbm9uLVJBQ0stVExQIGlt cGxlbWVudGF0aW9uIHRpbWVyIChSVE8pDQo+ICAgICAgID4gICAgICAgZXhwaXJlczogY3duZD0x IE1TUywNCj4gICAgICAgPiAgICAgICBhbmQgc2xvdyBzdGFydCBpcyBlbnRlcmVkLg0KPiAgICAg ICA+ICAgICAgIFdoZW4gd2l0aCBhIFJBQ0tfVExQIGltcGxlbWVudGF0aW9uIHRpbWVyIChQVE8p IGV4cGlyZXMsDQo+ICAgICAgID4gICAgICAgbm9ybWFsIGZhc3QgcmVjb3ZlcnkgaXMgZW50ZXJl ZCAodW5sZXNzIGltcGxlbWVudGluZw0KPiAgICAgICA+ICAgICAgIGFsc28gUFJSKS4gU28gbm8g UlRPIHJlY292ZXJ5IGFzIGV4cGxpY2l0bHkgc3RhdGVkIGluDQo+ICAgICAgIFNlYy4NCj4gICAg ICAgPiAgICAgICA3LjQuMS4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIFRoaXMgbWVhbnMg dGhhdCB0aGlzIGRvY3VtZW50IGV4cGxpY2l0bHkgbW9kaWZpZXMNCj4gICAgICAgc3RhbmRhcmQN Cj4gICAgICAgPiAgICAgICBUQ1AgY29uZ2VzdGlvbg0KPiAgICAgICA+ICAgICAgIGNvbnRyb2wg d2hlbiB0aGVyZSBhcmUgbm8gYWNrcyBjb21pbmcgYW5kIHRoZQ0KPiAgICAgICA+ICAgICAgIHJl dHJhbnNtaXNzaW9uIHRpbWVyDQo+ICAgICAgID4gICAgICAgZXhwaXJlcw0KPiAgICAgICA+DQo+ ICAgICAgID4gICAgICAgZnJvbTogUlRPPVNSVFQrNCpSVFRWQVIgKFJUTyB1c2VkIGZvciBhcm1p bmcgdGhlIHRpbWVyKQ0KPiAgICAgICA+ICAgICAgICAgICAgICAxLiBSVE8gdGltZXIgZXhwaXJl cw0KPiAgICAgICA+ICAgICAgICAgICAgICAyLiBjd25kPTEgTVNTOyBzc3RocmVzaD1GbGlnaHRT aXplLzI7IHJleG1pdCBvbmUNCj4gICAgICAgPiAgICAgICBzZWdtZW50DQo+ICAgICAgID4gICAg ICAgICAgICAgIDMuIEFjayBvZiByZXhtaXQgc2VudCBpbiBzdGVwIDIgYXJyaXZlcw0KPiAgICAg ICA+ICAgICAgICAgICAgICA0LiBjd25kID0gY3duZCsxIE1TUzsgc2VuZCB0d28gc2VnbWVudHMN Cj4gICAgICAgPiAgICAgICAgICAgICAgLi4uDQo+ICAgICAgID4NCj4gICAgICAgPiAgICAgICB0 bzogICBQVE89bWluKDIqU1JUVCxSVE8pIChQUk8gdXNlZCBmb3IgYXJtaW5nIHRoZQ0KPiAgICAg ICB0aW1lcikNCj4gICAgICAgPiAgICAgICAgICAgICAgMS4gUFRPIHRpbWVzIGV4cGlyZXMNCj4g ICAgICAgPiAgICAgICAgICAgICAgMi4gKGN3bmQ9MSBNU1MpOyAocmUpeG1pdCBvbmUgc2VnbWVu dA0KPiAgICAgICA+ICAgICAgICAgICAgICAzLiBBY2sgb2YgKHJlKXhtaXQgc2VudCBpbiBzcmVw IDIgYXJyaXZlcw0KPiAgICAgICA+ICAgICAgICAgICAgICA0LiBjd25kID0gc3N0aHJlc2ggPSBG bGlnaHRTaXplLzI7IHNlbmQgTj1jd25kDQo+ICAgICAgID4gICAgICAgc2VnbWVudHMNCj4gICAg ICAgPg0KPiAgICAgICA+ICAgICAgIEZvciBleGFtcGxlLCBpZiBGbGlnaHRTaXplIGlzIDEwMCBz ZWdtZW50cyB3aGVuIHRpbWVyDQo+ICAgICAgID4gICAgICAgZXhwaXJlcywNCj4gICAgICAgPiAg ICAgICBjb25nZXN0aW9uIGNvbnRyb2wgaXMgdGhlIHNhbWUgaW4gc3RlcHMgMS0zLCBidXQgaW4g c3RlcA0KPiAgICAgICA0DQo+ICAgICAgID4gICAgICAgdGhlDQo+ICAgICAgID4gICAgICAgY3Vy cmVudCBzdGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2wgYWxsb3dzIHRyYW5zbWl0dGluZw0KPiAg ICAgICAyDQo+ICAgICAgID4gICAgICAgc2VnbWVudHMsDQo+ICAgICAgID4gICAgICAgd2hpbGUg UkFDSy1UTFAgd291bGQgYWxsb3cgYmxhc3RpbmcgNTAgc2VnbWVudHMuDQo+ICAgICAgID4NCj4g ICAgICAgPiAgICAgICBRdWVzdGlvbiBpczogd2hhdCBpcyB0aGUganVzdGlmaWNhdGlvbiB0byBt b2RpZnkNCj4gICAgICAgc3RhbmRhcmQNCj4gICAgICAgPiAgICAgICBUQ1ANCj4gICAgICAgPiAg ICAgICBjb25nZXN0aW9uIGNvbnRyb2wgdG8gdXNlIGZhc3QgcmVjb3ZlcnkgaW5zdGVhZCBvZiBz bG93DQo+ICAgICAgID4gICAgICAgc3RhcnQgZm9yIGENCj4gICAgICAgPiAgICAgICBjYXNlIHdo ZXJlIHRpbWVvdXQgaXMgbmVlZGVkIHRvIGRldGVjdCBsb3NzIGJlY2F1c2UNCj4gICAgICAgdGhl cmUNCj4gICAgICAgPiAgICAgICBpcyBubw0KPiAgICAgICA+ICAgICAgIGZlZWRiYWNrIGFuZCBh Y2sgY2xvY2sgaXMgbG9zdD8gVGhlIGRyYWZ0IGRvZXMgbm90IGdpdmUNCj4gICAgICAgYW55DQo+ ICAgICAgID4gICAgICAganVzdGlmaWNhdGlvbi4gVGhpcyBjbGVhcmx5IGlzIGluIGNvbmZsaWN0 IHdpdGggaXRlbXMNCj4gICAgICAgKDApDQo+ICAgICAgID4gICAgICAgYW5kICgxKQ0KPiAgICAg ICA+ICAgICAgIGluIEJDUCAxMzMgKFJGQyA1MDMzKS4NCj4gICAgICAgPg0KPiAgICAgICA+ICAg ICAgIEZ1cnRoZXJtb3JlLCB0aGVyZSBpcyBubyBpbXBsZW1lbnRhdGlvbiBub3IgZXhwZXJpbWVu dGFsDQo+ICAgICAgID4gICAgICAgZXhwZXJpZW5jZQ0KPiAgICAgICA+ICAgICAgIGV2YWx1YXRp bmcgdGhpcyBjaGFuZ2UuIFRoZSBpbXBsZW1lbnRhdGlvbiB3aXRoDQo+ICAgICAgID4gICAgICAg ZXhwZXJpbWVudGFsIGV4cGVyaWVuY2UNCj4gICAgICAgPiAgICAgICB1c2VzIFBSUiAoUkZDIDY5 MzcpIHdoaWNoIGlzIGFuIEV4cGVyaW1lbnRhbA0KPiAgICAgICBzcGVjaWZpY2F0aW9uDQo+ICAg ICAgID4gICAgICAgaW5jbHVkaW5nIGENCj4gICAgICAgPiAgICAgICBub3ZlbCAidHJpY2siIHRo YXQgZGlyZWN0cyBQUlIgZmFzdCByZWNvdmVyeSB0bw0KPiAgICAgICBlZmZlY3RpdmVseQ0KPiAg ICAgICA+ICAgICAgIHVzZSBzbG93DQo+ICAgICAgID4gICAgICAgc3RhcnQgaW4gdGhpcyBjYXNl IGF0IGhhbmQuDQo+ICAgICAgID4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgID4gSW4gb3Ro ZXIgd29yZHMsIEkgYW0gbm90IHNlZWluZyBhIGNhc2UgdGhhdCByZXF1aXJlcw0KPiAgICAgICBu ZXcNCj4gICAgICAgPiAgICAgICBjb25nZXN0aW9uDQo+ICAgICAgID4gICAgICAgPiBjb250cm9s IGNvbmNlcHRzIGV4Y2VwdCBhcyBkaXNjdXNzZWQgaW4gOS4zLg0KPiAgICAgICA+DQo+ICAgICAg ID4gICAgICAgU2VlIGFib3ZlLiBUaGUgY2hhbmdlIGluIHN0YW5kYXJkIGNvbmdlc3Rpb24gY29u dHJvbCBmb3INCj4gICAgICAgPiAgICAgICAoMikuDQo+ICAgICAgID4gICAgICAgVGhlIGRyYWZ0 IGludGVuZHMgbm90IHRvIGNoYW5nZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0DQo+ICAgICAgID4g ICAgICAgZWZmZWN0aXZlbHkgaXQNCj4gICAgICAgPiAgICAgICBkb2VzIHdpdGhvdXQgYW55IG9w ZXJhdGlvbmFsIGV2aWRlbmNlLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgV2hhdCdzIGFs c28gaXMgbWlzc2luZyBhbmQgd291bGQgYmUgdmVyeSB1c2VmdWw6DQo+ICAgICAgID4NCj4gICAg ICAgPiAgICAgICAtIEZvciAoMSksIGEgaGludCBmb3IgYW4gaW1wbGVtZW50ZXIgc2F5aW5nIHRo YXQgYmVjYXVzZQ0KPiAgICAgICA+ICAgICAgIFJBQ0stVExQIGlzDQo+ICAgICAgID4gICAgICAg ICAgYWJsZSB0byBkZXRlY3QgYSBsb3NzIG9mIGEgcmV4bWl0IHVubGlrZSBhbnkgb3RoZXINCj4g ICAgICAgbG9zcw0KPiAgICAgICA+ICAgICAgIGRldGVjdGlvbg0KPiAgICAgICA+ICAgICAgICAg IGFsZ29yaXRobSwgdGhlIHNlbmRlciBNVVNUIHJlYWN0IHR3aWNlIHRvIGNvbmdlc3Rpb24NCj4g ICAgICAgPiAgICAgICAoYW5kIGNpdGUNCj4gICAgICAgPiAgICAgICAgICBSRkMgNTY4MSkuIEFu ZCBjaXRlIGEgZG9jdW1lbnQgd2hlcmUgbmVjZXNzYXJ5DQo+ICAgICAgIGNvcnJlY3QNCj4gICAg ICAgPiAgICAgICBhY3Rpb25zDQo+ICAgICAgID4gICAgICAgICAgYXJlIGRlc2NyaWJlZC4NCj4g ICAgICAgPg0KPiAgICAgICA+ICAgICAgIC0gRm9yICgxKSwgYWR2aXNlIHRoYXQgYW4gaW1wbGVt ZW50ZXIgbmVlZHMgdG8ga2VlcA0KPiAgICAgICB0cmFjaw0KPiAgICAgICA+ICAgICAgIHdoZW4g aXQNCj4gICAgICAgPiAgICAgICAgICBkZXRlY3RzIGEgbG9zcyBvZiBhIHJldHJhbnNtaXR0ZWQg c2VnbWVudC4gQ3VycmVudA0KPiAgICAgICA+ICAgICAgIGFsZ29yaXRobXMNCj4gICAgICAgPiAg ICAgICAgICBpbiB0aGUgZHJhZnQgZGV0ZWN0IGEgbG9zcyBvZiByZXRyYW5zbWl0dGVkIHNlZ21l bnQNCj4gICAgICAgPiAgICAgICBleGFjdGx5IGluDQo+ICAgICAgID4gICAgICAgICAgdGhlIHNh bWUgd2F5IGFzIGxvc3Mgb2YgYW55IG90aGVyIHNlZ21lbnQuIFRoZXJlDQo+ICAgICAgIHNlZW1z DQo+ICAgICAgID4gICAgICAgdG8gYmUNCj4gICAgICAgPiAgICAgICAgICBub3RoaW5nIHRvIHRy YWNrIHdoZW4gYSByZXRyYW5zbWlzc2lvbiBvZiBhDQo+ICAgICAgID4gICAgICAgcmV0cmFuc21p dHRlZCBzZWdtZW50DQo+ICAgICAgID4gICAgICAgICAgdGFrZXMgcGxhY2UuIFRoZXJlZm9yZSwg dGhlIGFsZ29yaXRobXMgc2hvdWxkIGhhdmUNCj4gICAgICAgPiAgICAgICBhZGRpdGlvbmFsDQo+ ICAgICAgID4gICAgICAgICAgYWN0aW9ucyB0byBjb3JyZWN0bHkgdHJhY2sgd2hlbiBzdWNoIGEg bG9zcyBpcw0KPiAgICAgICBkZXRlY3RlZC4NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIC0g Rm9yICgxKSwgZGlzY3Vzc2lvbiBvbiBob3cgbWFueSB0aW1lcyBhIGxvc3Mgb2YgYQ0KPiAgICAg ICA+ICAgICAgIHJldHJhbnNtaXNzaW9uDQo+ICAgICAgID4gICAgICAgICAgb2YgdGhlIHNhbWUg c2VnbWVudCBtYXkgb2NjdXIgYW5kIGJlIGRldGVjdGVkLiBTZWVtcw0KPiAgICAgICA+ICAgICAg IHRoYXQgaXQNCj4gICAgICAgPiAgICAgICAgICBtYXkgYmUgcG9zc2libGUgdG8gZHJvcCBhIHJl eG1pdHRlZCBzZWdtZW50IG1vcmUgdGhhbg0KPiAgICAgICA+ICAgICAgIG9uY2UgYW5kDQo+ICAg ICAgID4gICAgICAgICAgZGV0ZWN0IGl0IGFsc28gc2V2ZXJhbCB0aW1lcz8gIFdoYXQgYXJlIHRo ZQ0KPiAgICAgICA+ICAgICAgIGltcGxpY2F0aW9ucz8NCj4gICAgICAgPg0KPiAgICAgICA+ICAg ICAgIC0gSWYgcHJldmlvdXMgaXMgcG9zc2libGUsIHRoZW4gdGhlIGFsZ29yaXRobSBwb3NzaWJs eQ0KPiAgICAgICBhbHNvDQo+ICAgICAgID4gICAgICAgICAgbWF5IGRldGVjdCBhIGxvc3Mgb2Yg YSBuZXcgc2VnbWVudCB0aGF0IHdhcyBzZW50DQo+ICAgICAgIGR1cmluZw0KPiAgICAgICA+ICAg ICAgIGZhc3QNCj4gICAgICAgPiAgICAgICAgICByZWNvdmVyeT8gVGhpcyBpcyBhbHNvIGxvc3Mg aW4gdHdvIHN1Y2Nlc3NpdmUgd2luZG93cw0KPiAgICAgICBvZg0KPiAgICAgICA+ICAgICAgIGRh dGEsDQo+ICAgICAgID4gICAgICAgICAgYW5kIGN3bmQgTVVTVCBiZSBsb3dlcmVkIHR3aWNlLiBU aGlzIGRpc2N1c3Npb24gYW5kDQo+ICAgICAgID4gICAgICAgbmVjZXNzYXJ5DQo+ICAgICAgID4g ICAgICAgICAgYWN0aW9ucyB0byB0cmFjayBpdCBhcmUgbWlzc2luZywgaWYgc3VjaCBzY2VuYXJp byBpcw0KPiAgICAgICA+ICAgICAgIHBvc3NpYmxlLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAg ICAgPiBXaGF0IGFtIEkgbWlzc2luZz8NCj4gICAgICAgPg0KPiAgICAgICA+ICAgICAgIEhvcGUg dGhlIGFib3ZlIGhlbHBzLg0KPiAgICAgICA+DQo+ICAgICAgID4gICAgICAgL01hcmtrdQ0KPiAg ICAgICA+DQo+ICAgICAgID4NCj4gICAgICAgPiA8c25pcHBpbmcgdGhlIHJlc3Q+DQo+ICAgICAg ID4NCj4gICAgICAgPg0KPg0KPg0KPg0K --_000_CO2PR00MB016669CA3B63D26781DE0EF1B6C39CO2PR00MB0166namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Mb29rcyBnb29kIHRvIG1lLiBJIHdvdWxkIG9taXQg4oCcLCBidXQgc29tZSBvdGhl ciBjb25nZXN0aW9uIGNvbnRyb2wgbWF5IHdhbnQgdG8gcmVzcG9uZCBtdWx0aXBsZSB0aW1lcyBk aWZmZXJlbnRseeKAnS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gWXVjaHVuZyBDaGVuZyAmbHQ7eWNoZW5nQGdvb2dsZS5j b20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMTcsIDIwMjAgMjo1 NSBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21haWwu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZi QG1pY3Jvc29mdC5jb20mZ3Q7OyBrb2pvQGNzLmhlbHNpbmtpLmZpOyB0Y3BtQGlldGYub3JnOyBk cmFmdC1pZXRmLXRjcG0tcmFja0BpZXRmLm9yZzsgdHVleGVuQGZoLW11ZW5zdGVyLmRlOyBkcmFm dC1pZXRmLXRjcG0tcmFjay5hbGxAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgdGNwbS1j aGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtFWFRFUk5BTF0gUmU6IFt0 Y3BtXSBMYXN0IENhbGw6ICZsdDtkcmFmdC1pZXRmLXRjcG0tcmFjay0xMy50eHQmZ3Q7KFRoZVJB Q0stVExQbG9zc2RldGVjdGlvbmFsZ29yaXRobWZvclRDUCkgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMgMTcs IDIwMjAgYXQgMTo1OSBQTSBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5o LmR1a2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGdvb2QsIHRoYW5rcy48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbWlnaHQgYWxzbyBhZGQgdGhlIHNl bnRlbmNlICZxdW90O0luIHRoZSBhYnNlbmNlIG9mIFBSUiwgd2hlbiBUQ1AgUkFDSyBkZXRlY3Rz IGEgbG9zdCByZXRyYW5zbWlzc2lvbiBpdCBNVVNUIHRyaWdnZXIgYSBzZWNvbmQgY29uZ2VzdGlv biByZXNwb25zZSZxdW90OyBvciBzb21ldGhpbmcgdG8gdGhhdCBlZmZlY3QuIFdoYXQgZG8geW91 IHRoaW5rPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlIEknZCByZXZpc2UgYSBiaXQgdG8gYmUgZXZl biBtb3JlIGRldGFpbGVkIGFuZCBjb25zaXN0ZW50IHdpdGggdGhlIHByaW5jaXBsZSBpbiBSRkM1 NjgxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90O0luIHRoZSBhYnNlbmNlJm5ic3A7b2YgUFJSLCB3aGVuIFJB Q0stVExQIGRldGVjdHMgYSBsb3N0IHJldHJhbnNtaXNzaW9uIHRoZSBjb25nZXN0aW9uIGNvbnRy b2wgTVVTVCB0cmlnZ2VyIGFuIGFkZGl0aW9uYWwgY29uZ2VzdGlvbiByZXNwb25zZSBwZXIgdGhl IGFmb3JlbWVudGlvbmVkIHByaW5jaXBsZSBpbiBSRkM1NjgxLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgbXVsdGlwbGUgcmV0cmFuc21pc3Np b25zIHdlcmUgbG9zdCBpbiBhIHdpbmRvdywgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBzcGVjaWZp ZWQgaW4gUkZDNTY4MSBvbmx5IHJlYWN0cyBvbmNlIHBlciB3aW5kb3csIGJ1dCBzb21lIG90aGVy IGNvbmdlc3Rpb24gY29udHJvbCBtYXkgd2FudCB0byByZXNwb25kIG11bHRpcGxlIHRpbWVzIGRp ZmZlcmVudGx5LiBUaGUgY29uZ2VzdGlvbiBjb250cm9sIGltcGxlbWVudGVyDQogaXMgYWR2aXNl ZCB0byBjYXJlZnVsbHkmbmJzcDtjb25zaWRlciB0aGlzIHN1YnRsZSBzaXR1YXRpb24uJnF1b3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFRodSwgRGVjIDE3LCAyMDIwIGF0IDExOjM2IEFNIFl1Y2h1bmcgQ2hlbmcgJmx0 OzxhIGhyZWY9Im1haWx0bzp5Y2hlbmdAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnljaGVu Z0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs5 LjMuJm5ic3A7IEludGVyYWN0aW9uIHdpdGggY29uZ2VzdGlvbiBjb250cm9sPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJBQ0stVExQIGludGVudGlv bmFsbHkgZGVjb3VwbGVzIGxvc3MgZGV0ZWN0aW9uIC4uLiZuYnNwOzxicj4NCkFzIG1lbnRpb25l ZCBpbiBGaWd1cmUgMSBjYXB0aW9uLCBSRkM1NjgxIG1hbmRhdGVzIGEgcHJpbmNpcGxlIHRoYXQ8 c3BhbiBzdHlsZT0iY29sb3I6IzUwMDA1MCI+PGJyPg0KTG9zcyBpbiB0d28gc3VjY2Vzc2l2ZSB3 aW5kb3dzIG9mIGRhdGEsIG9yIHRoZSBsb3NzIG9mIGE8YnI+DQo8L3NwYW4+cmV0cmFuc21pc3Np b24sIHNob3VsZCBiZSB0YWtlbiBhcyB0d28gaW5kaWNhdGlvbnMgb2YgY29uZ2VzdGlvbiwgYW5k PGJyPg0KdGhlcmVmb3JlIHJlYWN0ZWQgc2VwYXJhdGVseS4gSG93ZXZlciBpbXBsZW1lbnRhdGlv biBvZiBSRkM2Njc1IHBpcGU8YnI+DQphbGdvcml0aG0gbWF5IG5vdCBkaXJlY3RseSBhY2NvdW50 IGZvciB0aGlzIG5ld2x5IGRldGVjdGVkIGNvbmdlc3Rpb248YnI+DQpldmVudHMgcHJvcGVybHku IFBSUiBbUkZDeHh4eF0gaXMgUkVDT01NRU5ERUQgZm9yIHRoZSBzcGVjaWZpYzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbmdlc3Rpb24gY29udHJvbCBhY3Rp b25zIHRha2VuIHVwb24gdGhlIGxvc3NlcyBkZXRlY3RlZCBieSBSQUNLLVRMUCZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gTWFr a3UncyByZXF1ZXN0IGZvciAmcXVvdDt3aGF0J3MgdGhlIGp1c3RpZmljYXRpb24gdG8gZW50ZXIg ZmFzdCByZWNvdmVyeSZxdW90Oy4gQ29uc2lkZXIgdGhpcyBleGFtcGxlIHcvbyBSQUNLLVRMUDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UMDog U2VuZCAxMDAgc2VnbWVudHMgYnV0IGFwcGxpY2F0aW9uLWxpbWl0ZWQuIEFsbCBhcmUgbG9zdC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlQtMlJU VDogYXBwIHdyaXRlcyBzbyBhbm90aGVyIDMgc2VnbWVudHMgYXJlIHNlbnQuIE1hZGUgdG8gdGhl IGRlc3RpbmF0aW9uIGFuZCB0cmlnZ2VyZWQgMyBEVVBBQ0tzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ULTNSVFQ6IDMgRFVQQUNLIGFycml2ZXMu IHN0YXJ0IGZhc3QgcmVjb3ZlcnkgYW5kIHN1YnNlcXVlbnQgY2MgcmVhY3Rpb25zIHRvIGJ1cnN0 IH41MCBwYWNrZXRzIHdpdGggUmVubyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGlzIGNhc2UgYW55IEFDSyBvY2N1cmVkIGJl Zm9yZSBSVE8gaXMgKGdlbmVyYWxseSkgY29uc2lkZXJlZCBjbG9jay1hY2tlZCwgYW5kIGhvdyZu YnNwO0kgdW5kZXJzdGFuZCBWYW4ncyBpbml0aWFsIGRlc2lnbi4mbmJzcDsgVGhpcyBiZWhhdmlv ciBleGlzdGVkIGRlY2FkZXMgYmVmb3JlIFJBQ0stVExQLiBSQUNLLVRMUCBlc3NlbnRpYWxseSBj aGFuZ2VzIHRoZSAmcXVvdDszLXNlZ21lbnRzIGJ5IGFwcCZxdW90OyB0byAmcXVvdDsxLXNlZ21l bnQNCiBieSB0Y3AmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBEZWMgMTcsIDIwMjAgYXQgMTA6NTIgQU0gUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgaGF2ZSBhIG5vdGUgaW4gdGhp cyBSRkMgYWJvdXQgY29uZ2VzdGlvbiBjb250cm9sIGFjdGlvbiB1cG9uIGRldGVjdGluZyBsb3N0 IHJldHJhbnNtaXNzaW9uKHMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IHRjcG0gJmx0OzxhIGhyZWY9Im1haWx0bzp0 Y3BtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJ0aW4gRHVrZTxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgRGVjZW1iZXIgMTcsIDIwMjAgNzozMCBBTTxicj4NCjxiPlRvOjwvYj4g TWFya2t1IEtvam8gJmx0OzxhIGhyZWY9Im1haWx0bzprb2pvQGNzLmhlbHNpbmtpLmZpIiB0YXJn ZXQ9Il9ibGFuayI+a29qb0Bjcy5oZWxzaW5raS5maTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5v cmc8L2E+IEV4dGVuc2lvbnMgJmx0OzxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWlldGYtdGNwbS1yYWNrQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi10Y3Bt LXJhY2tAaWV0Zi5vcmc8L2E+OyBNaWNoYWVsIFR1ZXhlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR1 ZXhlbkBmaC1tdWVuc3Rlci5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR1ZXhlbkBmaC1tdWVuc3Rlci5k ZTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtdGNwbS1yYWNrLmFsbEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LWlldGYtdGNwbS1yYWNrLmFsbEBpZXRmLm9yZzwv YT47IExhc3QgQ2FsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmxhc3QtY2FsbEBpZXRmLm9yZzwvYT4mZ3Q7OyB0Y3BtLWNoYWlycyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRjcG0tY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNw bS1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhURVJOQUxd IFJlOiBbdGNwbV0gTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi10Y3BtLXJhY2stMTMudHh0Jmd0 OyhUaGVSQUNLLVRMUGxvc3NkZXRlY3Rpb25hbGdvcml0aG1mb3JUQ1ApIHRvIFByb3Bvc2VkIFN0 YW5kYXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGkgTWFya2t1LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhhbmtzLCBub3cgSSB1bmRlcnN0YW5kIHlvdXIgb2JqZWN0aW9ucy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1h cnRpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVGh1LCBEZWMgMTcsIDIwMjAgYXQgMTI6NDYgQU0gTWFya2t1IEtvam8gJmx0Ozxh IGhyZWY9Im1haWx0bzprb2pvQGNzLmhlbHNpbmtpLmZpIiB0YXJnZXQ9Il9ibGFuayI+a29qb0Bj cy5oZWxzaW5raS5maTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGksPGJyPg0KPGJyPg0KT24gV2VkLCAxNiBEZWMgMjAyMCwgTWFydGluIER1 a2Ugd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJIHNwZW50IGEgbGl0dGxlIGxvbmdlciBsb29raW5n IGF0IHRoZSBzcGVjcyBtb3JlIGNhcmVmdWxseSwgYW5kIEkgZXhwbGFpbmVkICgxKTxicj4NCiZn dDsgaW5jb3JyZWN0bHkgaW4gbXkgbGFzdCB0d28gbWVzc2FnZXMuIFAyMS4uMjkgYXJlIG5vdCBM aW1pdGVkIFRyYW5zbWl0IHBhY2tldHMuJm5ic3A7PGJyPg0KPGJyPg0KQ29ycmVjdC4gSnVzdCBu b3JtYWwgdGhlIHJ1bGUgdGhhdCBhbGxvd3Mgc2VuZGluZyBuZXcgZGF0YSBkdXJpbmcgZmFzdCA8 YnI+DQpyZWNvdmVyeS48YnI+DQo8YnI+DQomZ3Q7IEhvd2V2ZXIsIHVubGVzcyBJJ20gbWlzc2lu ZyBzb21ldGhpbmcgZWxzZSwgNjY3NSBpcyBjbGVhciB0aGF0IHRoZSByZWNvdmVyeSBwZXJpb2Q8 YnI+DQomZ3Q7IGRvZXMgbm90IGVuZCB1bnRpbCB0aGUgY3VtdWxhdGl2ZSBhY2sgYWR2YW5jZXMs IG1lYW5pbmcgdGhhdCBkZXRlY3RpbmcgdGhlIGxvc3Q8YnI+DQomZ3Q7IHJldHJhbnNtaXNzaW9u IG9mIFAxIGRvZXMgbm90IHRyaWdnZXIgYW5vdGhlciBNRCBkaXJlY3RseS48YnI+DQo8YnI+DQpB cyBJIGhhdmUgc2FpZCBlYXJsaWVyLCBSRkMgNjY3NSBkb2VzIG5vdCByZXBlYXQgYWxsIGNvbmdl c3Rpb24gY29udHJvbCA8YnI+DQpwcmluY2lwbGVzIGZyb20gUkZDIDU2ODEuIEl0IGRlZmluaXRl bHkgaG9ub3JzIHRoZSBDQyBwcmluY2lwbGUgdGhhdDxicj4NCnJlcXVpcmVzIHRvIHRyZWF0IGEg bG9zcyBvZiBhIHJldHJhbnNtaXNzaW9uIGFzIGEgbmV3IGNvbmdlc3Rpb24gPGJyPg0KaW5kaWNh dGlvbiBhbmQgYW5vdGhlciBNRC4gSSBiZWxpZXZlIEkgYW0gb2JsaWdhdGVkIHRvIGtub3cgdGhp cyBhcyBhIDxicj4NCmNvLWF1dGhvciBvZiBSRkMgNjY3NS4gOyk8YnI+DQo8YnI+DQpSRkMgNjY3 NSBleHBsaWNpdGx5IGluZGljYXRlcyB0aGF0IGl0IGZvbGxvd3MgUkZDIDU2ODEgYnkgc3RhdGlu ZyBpbiB0aGUgPGJyPg0KYWJzdHJhY3Q6PGJyPg0KPGJyPg0KJnF1b3Q7IC4uLiBjb25mb3JtcyB0 byB0aGUgc3Bpcml0IG9mIHRoZSBjdXJyZW50IGNvbmdlc3Rpb24gY29udHJvbDxicj4NCiZuYnNw OyBzcGVjaWZpY2F0aW9uIChSRkMgNTY4MSAuLi4mcXVvdDs8YnI+DQo8YnI+DQpBbmQgaW4gdGhl IGludHJvOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsmcXVvdDtUaGUgYWxnb3JpdGhtIHNwZWNp ZmllZCBpbiB0aGlzIGRvY3VtZW50IGlzIGEgc3RyYWlnaHRmb3J3YXJkPGJyPg0KJm5ic3A7ICZu YnNwOyBTQUNLLWJhc2VkIGxvc3MgcmVjb3Zlcnkgc3RyYXRlZ3kgdGhhdCBmb2xsb3dzIHRoZSZu YnNwOyBndWlkZWxpbmVzPGJyPg0KJm5ic3A7ICZuYnNwOyBzZXQgaW4gW1JGQzU2ODFdIC4uLiZx dW90Ozxicj4NCjxicj4NCkkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYW55dGhpbmcgdW5jbGVhciBp biB0aGlzLjxicj4NCjxicj4NClJGQyA2Njc1IGFuZCBhbGwgb3RoZXIgc3RhbmRhcmQgY29uZ2Vz dGlvbiBjb250cm9scyAoUkZDIDU1ODEgYW5kIFJGQyA8YnI+DQo2NTgyKSBoYW5kbGUgYSBsb3Nz IG9mIGEgcmV0cmFuc21pc3Npb24gYnkgJnF1b3Q7ZW5mb3JjaW5nJnF1b3Q7IFJUTyB0byBkZXRl Y3QgaXQuIDxicj4NCkFuZCBSVE8gZ3VhcmFudGVlcyBNRC4gUkFDSy1UTFAgY2hhbmdlcyB0aGUg bG9zcyBkZXRlY3Rpb24gaW4gdGhpcyBjYXNlIDxicj4NCmFuZCB0aGVyZWZvcmUgdGhlIHN0YW5k YXJkIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zIGRvIG5vdCBoYXZlIDxicj4NCmFjdGlv bnMgdG8gaGFuZGxlIGl0IGNvcnJyZWN0bHkuIFRoYXQgaXMgdGhlIHBvaW50Ljxicj4NCjxicj4N CkJSLDxicj4NCjxicj4NCi9NYXJra3U8YnI+DQo8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgdGhpcyBl eGVyY2lzZSEgSXQncyByZWZyZXNoZWQgbXkgbWVtb3J5IG9mIHRoZXNlIGRldGFpbHMgYWZ0ZXIg d29ya2luZzxicj4NCiZndDsgb24gc2xpZ2h0bHkgZGlmZmVyZW50IFFVSUMgYWxnb3JpdGhtcyBh IGxvbmcgdGltZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gV2VkLCBEZWMgMTYsIDIwMjAsIDE4 OjU1IE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgKDEpIEZsaWdodHNpemU6IGluIFJGQyA2Njc1LiBTZWN0aW9uIDUsIFN0ZXAg NC4yOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICg0LjIp IHNzdGhyZXNoID0gY3duZCA9IChGbGlnaHRTaXplIC8gMik8YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGUgY29uZ2Vz dGlvbiB3aW5kb3cgKGN3bmQpIGFuZCBzbG93IHN0YXJ0IHRocmVzaG9sZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgKHNzdGhyZXNoKSBh cmUgcmVkdWNlZCB0byBoYWxmIG9mIEZsaWdodFNpemUgcGVyIFtSRkM1NjgxXS48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkZGl0aW9u YWxseSwgbm90ZSB0aGF0IFtSRkM1NjgxXSByZXF1aXJlcyB0aGF0IGFueTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2VnbWVudHMgc2Vu dCBhcyBwYXJ0IG9mIHRoZSBMaW1pdGVkIFRyYW5zbWl0IG1lY2hhbmlzbSBub3Q8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlIGNvdW50 ZWQgaW4gRmxpZ2h0U2l6ZSBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhlIGFib3ZlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBlcXVhdGlvbi48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSUlVQyB0aGUgc2VnbWVudHMgUDIxLi5QMjkgaW4geW91ciBl eGFtcGxlIHdlcmUgc2VudCBiZWNhdXNlIG9mIExpbWl0ZWQ8YnI+DQomZ3Q7IFRyYW5zbWl0LCBh bmQgc28gZG9uJ3QgY291bnQuIFRoZSBmbGlnaHRzaXplIGZvciB0aGUgcHVycG9zZXMgb2YgKDQu MikgaXM8YnI+DQomZ3Q7IHRoZXJlZm9yZSAyMCBhZnRlciBib3RoIGxvc3NlcywgYW5kIHRoZSBj d25kIGRvZXMgbm90IGdvIHVwIG9uIHRoZSBzZWNvbmQ8YnI+DQomZ3Q7IGxvc3MuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7ICgyKTxicj4NCiZndDsgJnF1b3Q7IEV2ZW4gYSBzaW5nbGUgc2hvdCBidXJz dCBldmVyeSB0aW1lIHRoZXJlIGlzIHNpZ25pZmljYW50IGxvc3M8YnI+DQomZ3Q7IGV2ZW50IGlz IG5vdCBhY2NlcHRhYmxlLCBub3QgdG8gbWVudGlvbiBjb250aW51b3VzIGFnZ3Jlc3NpdmVuZXNz LCBhbmQ8YnI+DQomZ3Q7IHRoaXMgaXMgZXhhY3RseSB3aGF0IFJGQyAyOTE0IGFuZCBSRkMgNTAz MyBleHBsaWNpdGx5IGFkZHJlc3MgYW5kIHdhcm48YnI+DQomZ3Q7IGFib3V0LiZxdW90Ozxicj4N CiZndDsgPGJyPg0KJmd0OyAmcXVvdDtTaWduaWZpY2FudCBsb3NzIGV2ZW50JnF1b3Q7IGlzIHRo ZSBrZXkgcGhyYXNlIGhlcmUuIFRoZSBpbnRlbnQgb2YgVExQL1BUTyBpcyB0bzxicj4NCiZndDsg ZXF1YWxpemUgdGhlIHRyZWF0bWVudCBvZiBhIHNtYWxsIHBhY2tldCBsb3NzIHdoZXRoZXIgaXQg aGFwcGVuZWQgaW4gdGhlPGJyPg0KJmd0OyBtaWRkbGUgb2YgYSBidXJzdCBvciB0aGUgZW5kLiBX aHkgc2hvdWxkIGFuIGlzb2xhdGVkIGxvc3MgYmUgdHJlYXRlZDxicj4NCiZndDsgZGlmZmVyZW50 bHkgYmFzZWQgb24gaXRzIHBvc2l0aW9uIGluIHRoZSBidXJzdD8gVGhpcyBpcyBqdXN0IGEgbG9n aWNhbDxicj4NCiZndDsgZXh0ZW5zaW9uIG9mIGZhc3QgcmV0cmFuc21pdCwgd2hpY2ggYWxzbyBt b2RpZmllZCB0aGUgUlRPIHBhcmFkaWdtLiBUaGU8YnI+DQomZ3Q7IHdvcmtpbmcgZ3JvdXAgY29u c2Vuc3VzIGlzIHRoYXQgdGhpcyBpcyBhIGZlYXR1cmUsIG5vdCBhIGJ1ZzsgeW91J3JlIHdlbGNv bWU8YnI+DQomZ3Q7IHRvIGZlZWwgb3RoZXJ3aXNlIGJ1dCBJIHN1c3BlY3QgeW91J3JlIGluIHRo ZSByb3VnaCBoZXJlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0OyBNYXJ0 aW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBXZWQsIERlYyAxNiwgMjAyMCBh dCA0OjExIFBNIE1hcmtrdSBLb2pvICZsdDs8YSBocmVmPSJtYWlsdG86a29qb0Bjcy5oZWxzaW5r aS5maSIgdGFyZ2V0PSJfYmxhbmsiPmtvam9AY3MuaGVsc2lua2kuZmk8L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SGkgTWFydGluLDxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VlIGlubGluZS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO09uIFdlZCwgMTYgRGVjIDIwMjAs IE1hcnRpbiBEdWtlIHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBIaSBNYXJra3UsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGVyZSBp cyBhIHRvbiBoZXJlLCBidXQgSSdsbCB0cnkgdG8gYWRkcmVzcyB0aGUgdG9wIHBvaW50cy48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SG9wZWZ1bGx5PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgdGhleSBvYnZpYXRlIHRoZSByZXN0Ljxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U29ycnkgZm9yIGJlaW5nIHZl cmJvc2UuIEkgdHJpZWQgdG8gYmUgY2xlYXIgYnV0IHlvdSBhY3R1YWxseTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZW1vdmVkIG15PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2tleSBpc3N1ZXMvcXVlc3Rpb25zIDspPGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IDEuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgW01hcmtrdV08YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyAmcXVvdDtIbW0sIG5vdCBzdXJlIHdoYXQgeW91IG1lYW4gYnkgJnF1b3Q7dGhp cyBpcyBhIG5ldyBsb3NzIGRldGVjdGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDthZnRlcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGFja25v d2xlZGdtZW50IG9mIG5ldyBkYXRhJnF1b3Q7Pzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7IEJ1dCBhbnl3YXksIFJGQyA1NjgxIGdpdmVzIHRoZSBnZW5lcmFsIHByaW5j aXBsZSB0byByZWR1Y2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3duZCBh bmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBzc3RocmVzaCB0d2lj ZSBpZiBhIHJldHJhbnNtaXNzaW9uIGlzIGxvc3QgYnV0IElNSE8gKGFuZCBJPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlbGlldmUgbWFueTxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHdobyBoYXZlIGRlc2lnbmVkIG5ldyBsb3NzIHJlY292ZXJ5 IGFuZCBDQyBhbGdvcml0aG1zIG9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2ltcGxlbWVudGVkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgdGhl bTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGFncmVlKSB0aGF0IGl0 IGlzIGhhcmQgdG8gZ2V0IHRoaW5ncyByaWdodCBpZiBvbmx5IGNvbmdlc3Rpb248YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udHJvbDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7IHByaW5jaXBsZXMgYXJlIGF2YWlsYWJsZSBhbmQgbm8gYWxnb3Jp dGhtLiZxdW90Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgW01hcnRpbl08YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBTbyA2Njc1IFNlYyA1IGlzIHF1aXRlIGV4cGxp Y2l0IHRoYXQgdGhlcmUgaXMgb25seSBvbmUgY3duZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtyZWR1Y3Rpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyBwZXIgZmFzdCByZWNvdmVyeSBlcGlzb2RlLCB3aGljaCBlbmRzIG9uY2UgbmV3IGRhdGEg aGFzIGJlZW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBhY2tub3ds ZWRnZWQuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUbyBi ZSBtb3JlIHByZWNpc2U6IGZhc3QgcmVjb3ZlcnkgZW5kcyB3aGVuIHRoZSBjdXJyZW50IHdpbmRv dzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWNvbWVzPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2N1bXVsYXRpdmVseSBhY2tub3dsZWRnZWQsIHRoYXQg aXMsPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoNC4xKSBS ZWNvdmVyeVBvaW50ICg9IEhpZ2hEYXRhIGF0IHRoZSBiZWdpbm5pbmcpIGJlY29tZXM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWNrbm93bGVkZ2VkPGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJIGJlbGlldmUgd2UgYWdyZWUgYW5kIHlv dSBtZWFudCB0aGlzIGFsdGhvdWdoIG5ldyBkYXRhIGJlbG93PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1JlY292ZXJ5UG9pbnQgbWF5IGJlY29tZSBjdW11bGF0aXZlbHkgYWNr bm93bGVkZ2VkIGFscmVhZHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWFy bGllcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkdXJpbmcgdGhlIGZhc3Qg cmVjb3ZlcnkuIFJlbm8gbG9zcyByZWNvdmVyeSBpbiBSRkMgNTY4MSBlbmRzLDxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyhhbnkpIG5ldyBkYXRhIGhhcyBiZWVuIGFja25vd2xlZGdlZC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQnkgZGVmaW5pdGlvbiwg aWYgYSByZXRyYW5zbWlzc2lvbiBpcyBsb3N0IGl0IGlzIGJlY2F1c2U8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBuZXdlciBkYXRhIGhhcyBiZWVuIGFja25vd2xlZGdl ZCwgc28gaXQncyBhIG5ldyByZWNvdmVyeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtlcGlzb2RlLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Tm90IHN1cmUgd2hlcmUgeW91IGhhdmUgdGhpcyBkZWZpbml0aW9uPyBOZXdlciB0aGFuIHdo YXQgYXJlIHlvdTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWZlcnJpbmcg dG8/PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXQsIHll cywgaWYgYSByZXRyYW5zbWlzc2lvbiBpcyBsb3N0IHdpdGggUkZDIDY2NzUgYWxnb3JpdGhtLDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpdCByZXF1aXJlcyBSVE8gdG8gYmUg ZGV0ZWN0ZWQgYW5kIGRlZmluaXRlbHkgc3RhcnRzIGEgbmV3PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3JlY292ZXJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2VwaXNvZGUuIFRoYXQgaXMsIGEgbmV3IHJlY292ZXJ5IGVwaXNvZGUgaXMgZW5mb3JjZWQg Ynkgc3RlcDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoMS5hKSBvZjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOZXh0U2VnICgpIHdoaWNoIHByZXZlbnRz IHJldHJhbnNtaXNzaW9uIGlmIGEgc2VnbWVudCB0aGF0IGhhczxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDthbHJlYWR5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2JlZW4gcmV0cmFuc21pdHRlZC4gSWYgUkFDSy1UTFAgaXMgdXNlZCBmb3IgZGV0ZWN0aW5n IGxvc3Mgd2l0aDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRkMgNjY3NTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGluZ3MgZ2V0IGRpZmZlcmVudCBp biBtYW55IHdheXMsIGJlY2F1c2UgaXQgbWF5IGRldGVjdCBsb3NzIG9mPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2E8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cmV0cmFuc21pc3Npb24uIEl0IHdvdWxkIHByZXR0eSBtdWNoIHJlcXVpcmUgYW4gZW50aXJl IHJlZGVzaWduPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mIHRoZSBhbGdv cml0aC4gRm9yIGV4YW1wbGUsIGNhbGN1bGF0aW9uIG9mIHBpcGUgZG9lcyBub3Q8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uc2lkZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c2VnbWVudHMgdGhhdCBoYXZlIGJlZW4gcmV0cmFuc21pdHRlZCBtb3Jl IHRoYW4gb25jZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgTWVhbndoaWxlLCBkdXJpbmcgdGhlIEZhc3QgUmVjb3ZlcnkgcGVyaW9kIHRoZSBpbmNv bWluZyBhY2tzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2ltcGxpY2l0bHk8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyByZW1vdmUgZGF0YSBmcm9t IHRoZSBuZXR3b3JrIGFuZCB0aGVyZWZvcmUga2VlcCBmbGlnaHRzaXplPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvdy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0luY29ycmVjdC4gRmxpZ2h0U2l6ZSAhPSBwaXBlLiBPbmx5IGN1bXVs YXRpdmUgYWNrcyByZW1vdmUgZGF0YTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtmcm9tPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0ZsaWdodFNpemUgYW5k IG5ldyBkYXRhIHRyYW5zbWl0dGVkIGR1cmluZyBmYXN0IHJlY292ZXJ5IGluZmxhdGU8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7RmxpZ2h0U2l6ZS4gSG93IEZsaWdodFNpemUg ZXZvbHZlcyBkZXBlbmRzIG9uIGxvc3MgcGF0dGVybiBhcyBJPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3NhaWQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0l0IGlzIGFsc28gcG9zc2libGUgdGhhdCBGbGlnaHRTaXplIGlzIGxvdywgaXQgbWF5IGVyciBp biBib3RoPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RpcmVjdGlvbnMuIEEg c2ltcGxlIGV4YW1wbGUgY2FuIGJlIHVzZWQgYXMgYSBwcm9vZiBmb3IgdGhlIGNhc2U8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hlcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y3duZCBpbmNyZWFzZXMgaWYgYSBsb3NzIG9mIHJldHJhbnNtaXNzaW9u IGlzIGRldGVjdGVkIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyZXBh aXJlZDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JGQyA2 Njc1IHJlY292ZXJ5IHdpdGggUkFDSy1UTFAgbG9zcyBkZXRlY3Rpb246PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyhjb250YWlucyBzb21lIGluYWNjdXJhY2llcyBiZWNhdXNl IGl0IGhhcyBub3QgYmVlbiBkZWZpbmVkIGhvdzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtsb3N0IHJleG1pdHMgYXJlIGNhbGN1bGF0ZWQgaW50byBwaXBlKTxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3duZD0yMDsgcGFja2V0cyBQMSwu Li4sUDIwIGluIGZsaWdodCA9IGN1cnJlbnQgd2luZG93IG9mIGRhdGE8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7W1AxIGRyb3BwZWQgYW5kIHJleG1pdCBvZiBQMSB3aWxsIGFs c28gYmUgZHJvcHBlZF08YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0R1cEFjayB3L1NBQ0sgZm9yIFAyIGFycml2ZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7W2xvc3Mgb2YgUDEgZGV0ZWN0ZWQgYWZ0ZXIgb25lIFJUVCBmcm9tIG9yaWdp bmFsIHhtaXQgb2YgUDFdPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tjd25k PXNzdGhyZXNoPTEwXTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQMSBpcyBy ZXhtaXR0ZWQgKGFuZCBpdCBsb2dpY2FsbHkgc3RhcnRzIG5leHQgd2luZG93IG9mIGRhdGEpPGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtEdXBBY2tzIHcvIFNB Q0sgZm9yIG9yaWdpbmFsIFAzLi4xMSBhcnJpdmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7RHVwQWNrIHcvIFNBQ0sgZm9yIG9yaWdpbmFsIFAxMiBhcnJpdmVzPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tjd25kLXBpcGUgPSAxMC05ICZndDs9MV08YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VuZCBQMjE8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7RHVwQWNrIHcvU0FDSyBmb3IgUDEzIGFycml2ZXM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VuZCBQMjI8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Li4uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0R1cEFjayB3L1NBQ0sgZm9yIFAyMCBhcnJpdmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3NlbmQgUDI5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1tG bGlnaHRTaXplPTI5XTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7KEFjayBmb3IgcmV4bWl0IG9mIFAxIHdvdWxkIGFycml2ZSBoZXJlIHVubGVzcyBpdCBnb3Qg ZHJvcHBlZCk8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0R1 cEFjayB3L1NBQ0sgZm9yIFAyMSBhcnJpdmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1tsb3NzIG9mIHJleG1pdCBQMSBkZXRlY3RlZCBhZnRlciBvbmUgUlRUIGZyb20gcmV4 bWl0IG9mIFAxXTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 U0VUIGN3bmQgPSBzc3RocmVzaCA9IEZsaWdodFNpemUvMj0gMjkvMiA9IDE0LDU8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NXTkQgSU5DUkVBU0VTIHdoZW4g aXQgc2hvdWxkIGJlIGF0IG1vc3QgNSBhZnRlciBoYWx2aW5nIGl0PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3R3aWNlISEhPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFdlIGNhbiBjb250aW51ZSB0byBnbyBhcm91bmQgb24gb3Vy IGludGVycHJldGF0aW9uIG9mIHRoZXNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2RvY3VtZW50cyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBi dXQgZnVuZGFtZW50YWxseSBpZiB0aGVyZSBpcyBhbWJpZ3VpdHkgaW4gNTY4MS82Njc1IHdlIHNo b3VsZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiaXM8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyB0aG9zZSBSRkNzIHJhdGhlciB0aGFuIGV4cGFu ZCB0aGUgc2NvcGUgb2YgUkFDSy48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO0FzIEkgc2FpZCBlYXJsaWVyLCBJIGFtIG5vdCBvcHBvc2luZyBiaXMsIHRob3Vn aCA1NjgxYmlzIHd1b2xkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO25vdDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZSBuZWVkZWQsIEkgdGhpbmsuPGJy Pg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtCdXQgbGV0IG1lIHJl cGVhdDogaWYgd2UgcHVibGlzaCBSQUNLLVRMUCBub3cgd2l0aG91dCBuZWNlc3Nhcnk8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2FybmluZ3M8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7b3Igd2l0aCBhIGNvcnJlY3QgY29uZ2VzaW9uIGNvbnRyb2wgYWxn b3JpdGhtIHNvbWVvbmUgd2lsbCB0cnk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50IFJBQ0st VExQIHdpdGggUkZDIDY2NzUgYW5kIGl0IHdpbGwgYmUgYSB0b3RhbCBtZXNoLjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YmVoYXZpb3Igd2lsbCBiZSB1bnByZWRpY3RhYmxlIGFuZCBxdWl0ZSBsaWtlbHkg dW5zYWZlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbmdlc3Rpb248YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udHJvbCBiZWhhdmlvci48YnI+DQom Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgMi48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBbTWFya2t1XTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7ICZxdW90OyBJbiBzaG9ydDo8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBXaGVuIHdpdGggYSBub24tUkFDSy1UTFAgaW1wbGVt ZW50YXRpb24gdGltZXIgKFJUTykgZXhwaXJlczo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Y3duZD0xPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg TVNTLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGFuZCBzbG93IHN0 YXJ0IGlzIGVudGVyZWQuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsg V2hlbiB3aXRoIGEgUkFDS19UTFAgaW1wbGVtZW50YXRpb24gdGltZXIgKFBUTykgZXhwaXJlcyw8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBub3JtYWwgZmFzdCByZWNv dmVyeSBpcyBlbnRlcmVkICh1bmxlc3MgaW1wbGVtZW50aW5nPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsgYWxzbyBQUlIpLiBTbyBubyBSVE8gcmVjb3ZlcnkgYXMgZXhw bGljaXRseSBzdGF0ZWQgaW4gU2VjLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs3LjQuMS4mcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IFtNYXJ0aW5dPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUgbWF5IGJlIGEgbWlzdW5kZXJz dGFuZGluZyBoZXJlLiBQVE8gaXMgbm90IHRoZSBzYW1lIGFzPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1JUTywgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsgYm90aCBtZWNoYW5pc21zIGV4aXN0ISBUaGUgbG9zcyByZXNwb25zZSB0byBhIFBU TyBpcyB0byBzZW5kIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cHJvYmU7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgdGhlIFJUTyByZXNwb25z ZSBpcyBhcyB3aXRoIGNvbnZlbnRpb25hbCBUQ1AuIEluIFNlY3Rpb24gNy4zOjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Tm8sIEkgZG9uJ3QgdGhpbmsgSSBt aXN1bmRlcnN0b29kLiBJZiB5b3UgY2FsbCB0aW1lb3V0IHdpdGg8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7YW5vdGhlciBuYW1lLCBpdCBpcyBzdGlsbCB0aW1lb3V0LiBBbmQg Y29uZ2VzdGlvbiBjb250cm9sIGRvZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7bm90PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnNpZGVyIHdoaWNo IHNlZ21lbnRzIHRvIHNlbmQgKFNORC5VTkEgdnMuIHByb2JlIHcvIGhpZ2hlcjxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZXF1ZW5jZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtudW1iZXIpLCBvbmx5IGhvdyBtdWNoIGlzIHNlbnQuPGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtZb3UgaWdub3JlZCBteSBtYWpvciBw b2ludCB3aGVyZSBJIGRlY291cGxlZCBjb25nZXN0aW9uIGNvbnRyb2w8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZnJvbSBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2RldGVjdGlvbiBhbmQgbG9zcyByZWNvdmVyeSBhbmQgY29tcGFyZWQgUkZDIDU2 ODEgYmVoYXZpb3IgdG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkFDSy1U TFA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmVoYXZpb3IgaW4gZXhhY3Rs eSB0aGUgc2FtZSBzY2VuYXJpbyB3aGVyZSBhbiBlbnRpcmUgZmxpZ2h0IGlzPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvc3QgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3RpbWVyIGV4cGlyZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtQbGVhc2UgY29tbWVudCB3aHkgY29uZ2VzdGlvbiBjb250cm9sIGJl aGF2aW9yIGlzIGFsbG93ZWQgdG8gYmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cmFkaWNhbGx5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RpZmZlcmVu dCBpbiB0aGVzZSB0d28gaW1wbGVtZW50YXRpb25zPzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7UkZDIDU2ODEgJmFtcDsgUkZDIDYyOTggdGltZW91dDo8YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBSVE89U1JUVCs0KlJUVFZBUiAoUlRPIHVzZWQgZm9yIGFybWluZyB0aGUg dGltZXIpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzEuIFJUTyB0aW1lciBleHBpcmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIGN3bmQ9MSBNU1M7IHNz dGhyZXNoPUZsaWdodFNpemUvMjsgcmV4bWl0IG9uZSBzZWdtZW50PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzMuIEFjayBvZiBy ZXhtaXQgc2VudCBpbiBzdGVwIDIgYXJyaXZlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs0LiBjd25kID0gY3duZCsxIE1TUzsg c2VuZCB0d28gc2VnbWVudHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtSQUNLLVRMUCB0aW1lb3V0Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7 UFRPPW1pbigyKlNSVFQsUlRPKSAoUFRPIHVzZWQgZm9yIGFybWluZyB0aGUgdGltZXIpPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzEuIFBUTyB0aW1lcyBleHBpcmVzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIuIChjd25kPTEgTVNTKTsgKHJlKXhtaXQgb25l IHNlZ21lbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7My4gQWNrIG9mIChyZSl4bWl0IHNlbnQgaW4gc3JlcCAyIGFycml2ZXM8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7NC4gY3duZCA9IHNzdGhyZXNoID0gRmxpZ2h0U2l6ZS8yOyBzZW5kIE49Y3duZCBzZWdt ZW50czxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgRmxp Z2h0U2l6ZSBpcyAxMDAgc2VnbWVudHMgd2hlbiB0aW1lciBleHBpcmVzLCBjb25nZXN0aW9uPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnRyb2wgaXM8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIHNhbWUgaW4gc3RlcHMgMS0zLCBidXQgaW4gc3Rl cCA0IHRoZSBzdGFuZGFyZCBjb25nZXN0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2NvbnRyb2w8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxsb3dz IHRyYW5zbWl0dGluZyAyIHNlZ21lbnRzLCB3aGlsZSBSQUNLLVRMUCB3b3VsZCBhbGxvdzxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtibGFzdGluZyA1MCBzZWdtZW50cy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgQWZ0ZXIgYXR0 ZW1wdGluZyB0byBzZW5kIGEgbG9zcyBwcm9iZSwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGE8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bG9zczxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyBwcm9iZSB3YXMgc2VudCwgdGhlIHNl bmRlciBNVVNUIHJlLWFybSB0aGUgUlRPIHRpbWVyLCBub3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dGhlIFBUTzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aW1lciwgaWYgRmxpZ2h0U2l6ZSBpcyBub3QgemVyby4mbmJz cDsgVGhpcyBlbnN1cmVzIFJUTzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty ZWNvdmVyeSByZW1haW5zPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7IHRoZSBsYXN0IHJlc29ydCBpZiBUTFAgZmFpbHMuPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGlzIGRvZXMgbm90IHByZXZlbnQgdGhlIGFib3ZlIFJB Q0stVExQIGJlaGF2aW9yIGZyb20gZ2V0dGluZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtyZWFsaXplZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsgU28gYSBwdXJlIFJUTyByZXNwb25zZSBleGlzdHMgaW4gdGhlIGNhc2Ugb2Yg cGVyc2lzdGVudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25nZXN0aW9u IHRoYXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBjYXVzZXMgbG9z c2VzIG9mIHByb2JlcyBvciB0aGVpciBBQ0tzLjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7WWVzLCBSVE8gcmVzcG9uc2UgZXhpc3RzIEJVVCBvbmx5IGFmdGVy IFJBQ0stVExQIGF0IGxlYXN0IG9uY2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Ymxhc3RzIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtuZXR3b3Jr LiBJdCBtYXkgd2VsbCBiZSB0aGF0IHdpdGggc21hbGxlciB3aW5kb3dzIFJBQ0stVExQIGlzPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N1Y2Nlc3NmdWw8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHVyaW5nIGl0cyBUTFAgaW5pdGlhdGVkIG92ZXJseSBh Z2dyZXNzaXZlICZxdW90O2Zhc3QgcmVjb3ZlcnkmcXVvdDsgYW5kPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO25ldmVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2VudGVycyBSVE8gcmVjb3ZlcnkgYmVjYXVzZSBpdCBtYXkgZGV0ZWN0IGFuZCByZXBhaXIg YWxzbyBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JleG1pdHMuIFRoYXQgaXMsIGl0IGNvbnRpbnVl cyBhdCB0b28gaGlnaCByYXRlIGV2ZW4gaWYgbG9zdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtyZXhtaXRzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lu ZGljYXRlIHRoYXQgY29uZ2VzdGlvbiBwZXJzaXN0cyBpbiBzdWNjZXNzaXZlIHdpbmRvd3Mgb2Yg ZGF0YS48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5kPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dvcnNlLCBpdCBpcyBzdWNjZXNzZnVsIGJlY2F1c2Ug aXQgcHVzaGVzIGF3YXkgb3RoZXIgY29tcGF0aWJsZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtUQ1A8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Zmxvd3Mg YnkgYmVpbmcgdG9vIGFnZ3Jlc3NpdmUgYW5kIHVuZmFpci48YnI+DQomZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0V2ZW4gYSBzaW5nbGUgc2hvdCBidXJzdCBldmVyeSB0 aW1lIHRoZXJlIGlzIHNpZ25pZmljYW50IGxvc3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZXZlbnQgaXMgbm90IGFjY2VwdGFibGUsIG5vdCB0byBtZW50aW9uIGNvbnRpbnVv dXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWdncmVzc2l2ZW5lc3MsIGFu ZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGlzIGlzIGV4YWN0bHkgd2hh dCBSRkMgMjkxNCBhbmQgUkZDIDUwMzMgZXhwbGljaXRseSBhZGRyZXNzPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCB3YXJuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2Fib3V0Ljxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7QXJlIHdlIGlnbm9yaW5nIHRoZXNlIEJDUHMgdGhhdCBoYXZlIElFVEYgY29uc2Vuc3Vz Pzxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5kIHRoZSBv dGhlciBpbXBvcnRhbnQgcXVlc3Rpb24gSSdkIGxpa2UgdG8gaGF2ZSBhbiBhbnN3ZXI6PGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGF0IGlzIHRoZSBqdXN0 aWZpY2F0aW9uIHRvIG1vZGlmeSBzdGFuZGFyZCBUQ1AgY29uZ2VzdGlvbjxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250cm9sIHRvPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3VzZSBmYXN0IHJlY292ZXJ5IGluc3RlYWQgb2Ygc2xvdyBzdGFydCBmb3Ig YSBjYXNlIHdoZXJlIHRpbWVvdXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmVlZGVkIHRvIGRldGVjdCB0 aGUgcGFja2V0IGxvc3NlcyBiZWNhdXNlIHRoZXJlIGlzIG5vIGZlZWRiYWNrPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FuZCBhY2s8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Y2xvY2sgaXMgbG9zdD8gUkFDSy1UTFAgZXhwbGljaXRseSBpbnN0cnVjdHMg dG8gZG8gc28gaW4gU2VjLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs3LjQu MS48YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FzIEkgbm90 ZWQ6IGJhc2VkIG9uIHdoYXQgaXMgd3JpdHRlbiBpbiB0aGUgZHJhZnQgaXQgZG9lcyBub3Q8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW50ZW5kIHRvPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NoYW5nZSBjb25nZXN0aW9uIGNvbnRyb2wgYnV0IGVmZmVj dGl2ZWx5IGl0IGRvZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsvTWFya2t1PGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7IE1hcnRpbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBPbiBXZWQsIERlYyAxNiwgMjAyMCBhdCAxMTozOSBBTSBN YXJra3UgS29qbzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7PGEgaHJl Zj0ibWFpbHRvOmtvam9AY3MuaGVsc2lua2kuZmkiIHRhcmdldD0iX2JsYW5rIj5rb2pvQGNzLmhl bHNpbmtpLmZpPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyB3cm90ZTo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO0hpIE1hcnRpbiw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7T24gVHVlLCAxNSBEZWMgMjAyMCwgTWFydGluIER1a2Ug d3JvdGU6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsgSGkgTWFya2t1LDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBUaGFua3MgZm9y IHRoZSBjb21tZW50cy4gVGhlIGF1dGhvcnMgd2lsbCBpbmNvcnBvcmF0ZTxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWFu eSBvZiB5b3VyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IHN1Z2dlc3Rpb25zIGFmdGVyIHRoZSBJRVNHIHJldmll dy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgVGhlcmUncyBvbmUgdGhpbmcgSSBkb24n dCB1bmRlcnN0YW5kIGluIHlvdXIgY29tbWVudHM6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7ICZxdW90OyBUaGF0IGlzLDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyB3aGVyZSBjYW4gYW4gaW1wbGVtZW50 ZXIgZmluZCBhZHZpY2UgZm9yIGNvcnJlY3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbmdlc3Rpb24gY29udHJvbDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyBhY3Rpb25zIHdpdGggUkFDSy1UTFAsIHdoZW46PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7ICgxKSBhIGxvc3Mgb2YgcmV4bWl0dGVkIHNlZ21lbnQgaXMgZGV0ZWN0 ZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsgKDIpIGFuIGVudGlyZSBmbGlnaHQgb2YgZGF0YSBnZXRzIGRyb3Bw ZWQgKGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRlY3RlZCksPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBpcywgd2hlbiB0aGVyZSBpcyBu byBmZWVkYmFjayBhdmFpbGFibGUgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2E8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3RpbWVvdXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpcyBuZWVkZWQgdG8gZGV0ZWN0IHRoZSBsb3NzICZxdW90Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyBTZWN0aW9uIDkuMyBpcyB0aGUgZGlzY3Vzc2lvbiBhYm91dCBDQywgYW5kIGlz IGNsZWFyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoYXQ8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O3RoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyBpbXBsZW1lbnRlciBzaG91bGQgdXNlIGVpdGhlciA1NjgxIG9y IDY5MzcuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0p1c3QgYSBjaXRlIG5pdDogUkZDIDU2ODEgcHJvdmlkZXMgYmFzaWMgQ0MgY29uY2VwdHMgYW5k PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtzb21lIHVzZWZ1bCBDQzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Z3VpZGVsaW5lcyBidXQgZ2l2ZW4g dGhhdCBSQUNLLVRMUCBNVVNUIGltcGxlbWVudCBTQUNLPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3RoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxnb3JpdGhtIGluPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSRkMgNTY4 MSBpcyBub3QgdGhhdCB1c2VmdWwgYW5kIGFuIGltcGxlbWVudGVyIHF1aXRlPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xpa2VseTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9sbG93czxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7bWFpbmx5IHRoZSBhbGdvcml0aG0gaW4gUkZDIDY2NzUgKGFuZCBub3QgUkZDIDY5MzcgYXQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWxsPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpZiBub3Q8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2ltcGxlbWVudGluZyBQUlIpLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7QW5kIFJGQyA2Njc1IGlzIG5v dCBtZW50aW9uZWQgaW4gU2VjIDkuMywgdGhvdWdoIGl0IGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsaXN0ZWQgaW4g dGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtTZWMuIDQgKFJlcXVpcmVtZW50cykuPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgWW91IHdlbnQgdGhyb3VnaCB0aGUg NjkzNyBjYXNlIGluIGRldGFpbC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7WWVzLCBidXQgd2l0aG91dCBjb3JyZWN0IENDIGFjdGlvbnMuPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgSWYgNTY4 MSwgaXQncyBwcmV0dHkgY2xlYXIgdG8gbWUgdGhhdCBpbiAoMSkgdGhpcyBpcyBhPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtuZXcgbG9zczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBkZXRlY3Rpb24gYWZ0ZXIgYWNrbm93bGVkZ21lbnQg b2YgbmV3IGRhdGEsIGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGVy ZWZvcmU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3JlcXVpcmVzIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsgc2Vjb25kIGhhbHZpbmcg b2YgY3duZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7SG1tLCBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5ICZxdW90O3RoaXMgaXMgYSBuZXcgbG9z czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ZGV0ZWN0aW9uIGFmdGVyPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthY2tub3dsZWRnbWVudCBvZiBu ZXcgZGF0YSZxdW90Oz88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0J1dCBhbnl3YXksIFJGQyA1NjgxIGdpdmVzIHRoZSBn ZW5lcmFsIHByaW5jaXBsZSB0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDty ZWR1Y2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2N3bmQgYW5kPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzc3RocmVzaCB0d2ljZSBpZiBhIHJl dHJhbnNtaXNzaW9uIGlzIGxvc3QgYnV0IElNSE8gKGFuZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtJPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtiZWxpZXZlIG1hbnk8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dobyBoYXZl IGRlc2lnbmVkIG5ldyBsb3NzIHJlY292ZXJ5IGFuZCBDQyBhbGdvcml0aG1zIG9yPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbXBsZW1lbnRlZCB0aGVtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthZ3JlZSkgdGhhdCBpdCBpcyBoYXJkIHRvIGdl dCB0aGluZ3MgcmlnaHQgaWYgb25seTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZ2VzdGlvbiBjb250cm9sPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtwcmluY2lwbGVzIGFyZSBhdmFpbGFibGUgYW5kIG5vIGFsZ29yaXRobS48YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1RoYXQncyB3aHkgQUxMIG1lY2hhbmlzbXMgdGhhdCB3ZSBoYXZlIGluY2x1ZGUgYSBxdWl0ZTxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ZGV0YWlsZWQgYWxnb3JpdGhtPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aXRoIGFsbCBuZWNlc3Nhcnkg dmFyaWFibGVzIGFuZCBhY3Rpb25zIGZvciBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3JlY292ZXJ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthbmQvb3IgQ0M8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3B1cnBvc2Vz IChhbmQgb2Z0ZW4gYWxzbyBwc2V1ZG9jb2RlKS4gTGlrZSB0aGlzIGRvY3VtZW50PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkb2VzIGZvciBsb3NzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkZXRlY3Rpb24uPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NvIHRoZSBwcm9ibGVtIGlzIHRoYXQgd2Ug ZG8gbm90IGhhdmUgYSBkZXRhaWxlZCBlbm91Z2g8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FsZ29yaXRobSBvcjxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7cnVsZSB0aGF0IHRlbGxzIGV4YWN0bHkgd2hhdCB0byBkbyB3aGVuIGEgbG9zcyBvZiBy ZXhtaXQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aXM8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Rl dGVjdGVkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7RXZlbiB3b3JzZSwgdGhlIGFsZ29yaXRobXMgaW4gUkZDIDU2ODEg YW5kIFJGQyA2Njc1PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlZmVyPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt0bzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXF1YXRpb24gKDQpIG9mIFJGQyA1NjgxIHRvIHJlZHVjZSBz c3RocmVzaCBhbmQgY3duZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGVu IGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2xvc3M8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlcXVpcmluZyBhIGNvbmdlc3Rpb24gY29udHJv bCBhY3Rpb24gaXMgZGV0ZWN0ZWQ6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAoY3duZCA9KSBzc3RocmVzaCA9IEZsaWdodFNpemUgLyAy KTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtBbmQg UkZDIDU2ODEgZ2l2ZXMgYSB3YXJuaW5nIG5vdCB0byBoYWx2ZSBjd25kIGluIHRoZTxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZXF1YXRpb24gYnV0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGbGlnaHRTaXplLjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGF0IGlzLCB0aGlzIGVxdWF0aW9uIGlz IHdoYXQgYW4gaW1wbGVtZW50ZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 aW50dWl0aXZlbHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dvdWxkIHVzZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7d2hlbiByZWFkaW5nIHRo ZSByZWxldmFudCBSRkNzIGJ1dCBpdCBnaXZlcyBhIHdyb25nPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3Jlc3VsdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Zm9yPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvdXRzdGFuZGlu ZyBkYXRhIHdoZW4gaW4gZmFzdCByZWNvdmVyeSAod2hlbiB0aGUgc2VuZGVyPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2lzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29uZ2Vz dGlvbiBhdm9pZGFuY2UgYW5kIHRoZSBlcXVhdGlvbiAoNCkgaXMgdXNlZCB0bzxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtoYWx2ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y3duZCwgaXQ8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2dpdmVzIGEgY29ycmVjdCByZXN1bHQpLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TW9yZSBwcmVjaXNlbHksIGR1 cmluZyBmYXN0IHJlY292ZXJ5IEZsaWdodFNpemUgaXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7aW5mbGF0ZWQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3doZW4gbmV3PGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkYXRhIGlz IHNlbnQgYW5kIHJlZHVjZWQgd2hlbiBzZWdtZW50cyBhcmUgY3VtdWxhdGl2ZWx5PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtBY2tlZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO1doYXQgdGhlIG91dGNvbWUgaXMgZGVwZW5kcyBvbiB0aGUgbG9z cyBwYXR0ZXJuLiBJbiB0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3dvcnN0IGNhc2UsPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtGbGlnaHRT aXplIGlzIHNpZ25maWNhbnRseSBsYXJnZXIgdGhhbiBpbiB0aGUgYmVnaW5uaW5nPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGUgZmFzdDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7cmVjb3Zlcnkgd2hlbiBGbGlnaHRTaXplIHdhcyAoY29ycmVjdGx5KSB1c2VkIHRvPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RldGVybWluZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIGhh bHZlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7dmFsdWUgZm9yIGN3bmQgYW5kIHNzdGhyZXNoLCBpLmUuLCBlcXVhdGlv biAoNCkgbWF5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jlc3VsdDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7aW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyppbmNyZWFzaW5nKiBjd25kIHVwb24gZGV0ZWN0aW5nIGEgbG9z cyBvZiBhIHJleG1pdHRlZDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VnbWVudCwgaW5zdGVhZDxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2Yg ZnVydGhlciBoYWx2aW5nIGl0Ljxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtBIGNsZXZlciBpbXBsZW1lbnRlciBtaWdodCBoYXZlIG5vIHByb2JsZW0g dG8gaGF2ZSBpdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyaWdodDxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7d2l0aCBzb21lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGlua2luZyBidXQgSSBhbSBhZnJhaWQgdGhhdCB0 aGVyZSB3aWxsIGJlIGluY29ycmVjdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW1wbGVtZW50YXRpb25zPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt3aXRoIHdoYXQgaXMgY3VycmVudGx5IHNwZWNpZmllZC4gTm90IGFsbCBpbXBsZW1lbnRlcnM8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aGF2ZTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c3BlbnQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3NpZ25pY2ljYW50IGZyYWN0aW9uIG9mIHRoZWlyIGNhcmVlciBpbiBzb2x2aW5n IFRDUDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7cGVjdWxpYXJpdGllcy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyBGb3IgKDIpLCB0aGUgUlRPIHRpbWVyIGlzIHN0 aWxsIG9wZXJhdGl2ZSBzbzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyB0aGUgUlRPIHJlY292ZXJ5IHJ1bGVzIHdv dWxkIHN0aWxsIGZvbGxvdy48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SW4gc2hvcnQ6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtXaGVuIHdpdGggYSBub24tUkFDSy1UTFAg aW1wbGVtZW50YXRpb24gdGltZXIgKFJUTyk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4cGlyZXM6IGN3bmQ9MSBNU1Ms PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDthbmQgc2xvdyBzdGFydCBpcyBlbnRlcmVkLjxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7V2hlbiB3aXRo IGEgUkFDS19UTFAgaW1wbGVtZW50YXRpb24gdGltZXIgKFBUTykgZXhwaXJlcyw8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O25vcm1hbCBmYXN0IHJlY292ZXJ5IGlzIGVudGVyZWQgKHVubGVzcyBpbXBsZW1lbnRpbmc8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2Fsc28gUFJSKS4gU28gbm8gUlRPIHJlY292ZXJ5IGFzIGV4cGxpY2l0bHkgc3RhdGVk IGluPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlYy48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzcu NC4xLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtU aGlzIG1lYW5zIHRoYXQgdGhpcyBkb2N1bWVudCBleHBsaWNpdGx5IG1vZGlmaWVzPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YW5kYXJkPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUQ1AgY29uZ2Vz dGlvbjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Y29udHJvbCB3aGVuIHRoZXJlIGFyZSBubyBhY2tzIGNvbWluZyBhbmQg dGhlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtyZXRyYW5zbWlzc2lvbiB0aW1lcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXhwaXJlczxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmcm9tOiBSVE89 U1JUVCs0KlJUVFZBUiAoUlRPIHVzZWQgZm9yIGFybWluZyB0aGUgdGltZXIpPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxLiBSVE8gdGltZXIgZXhwaXJlczxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mi4gY3duZD0xIE1TUzsgc3N0aHJlc2g9RmxpZ2h0 U2l6ZS8yOyByZXhtaXQgb25lPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWdtZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDszLiBBY2sgb2YgcmV4bWl0IHNlbnQgaW4gc3RlcCAyIGFycml2ZXM8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzQuIGN3bmQgPSBjd25kKzEgTVNT OyBzZW5kIHR3byBzZWdtZW50czxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Li4uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Rv OiZuYnNwOyAmbmJzcDtQVE89bWluKDIqU1JUVCxSVE8pIChQUk8gdXNlZCBmb3IgYXJtaW5nIHRo ZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aW1lcik8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzEuIFBUTyB0aW1lcyBleHBpcmVzPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsyLiAoY3duZD0xIE1TUyk7IChyZSl4bWl0IG9uZSBz ZWdtZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDszLiBBY2sgb2YgKHJl KXhtaXQgc2VudCBpbiBzcmVwIDIgYXJyaXZlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7NC4gY3duZCA9IHNzdGhyZXNoID0gRmxpZ2h0U2l6ZS8yOyBzZW5kIE49Y3duZDxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7c2VnbWVudHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Rm9yIGV4YW1wbGUsIGlmIEZsaWdodFNpemUgaXMgMTAwIHNlZ21lbnRzIHdo ZW4gdGltZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2V4cGlyZXMsPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25nZXN0aW9uIGNvbnRyb2wg aXMgdGhlIHNhbWUgaW4gc3RlcHMgMS0zLCBidXQgaW4gc3RlcDxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0aGU8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2N1cnJlbnQgc3RhbmRh cmQgY29uZ2VzdGlvbiBjb250cm9sIGFsbG93cyB0cmFuc21pdHRpbmc8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Mjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VnbWVudHMsPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt3aGls ZSBSQUNLLVRMUCB3b3VsZCBhbGxvdyBibGFzdGluZyA1MCBzZWdtZW50cy48YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UXVlc3Rpb24gaXM6IHdoYXQg aXMgdGhlIGp1c3RpZmljYXRpb24gdG8gbW9kaWZ5PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3N0YW5kYXJkPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUQ1A8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nvbmdlc3Rpb24gY29u dHJvbCB0byB1c2UgZmFzdCByZWNvdmVyeSBpbnN0ZWFkIG9mIHNsb3c8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YXJ0 IGZvciBhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjYXNlIHdoZXJlIHRpbWVvdXQgaXMgbmVlZGVkIHRvIGRldGVjdCBs b3NzIGJlY2F1c2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlcmU8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2lzIG5vPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmZWVkYmFjayBhbmQgYWNrIGNsb2NrIGlzIGxvc3Q/IFRo ZSBkcmFmdCBkb2VzIG5vdCBnaXZlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2FueTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7anVzdGlmaWNhdGlvbi4gVGhpcyBjbGVhcmx5IGlzIGluIGNvbmZsaWN0 IHdpdGggaXRlbXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KDApPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDthbmQgKDEpPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpbiBCQ1AgMTMzIChSRkMgNTAzMykuPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Z1cnRoZXJtb3JlLCB0aGVy ZSBpcyBubyBpbXBsZW1lbnRhdGlvbiBub3IgZXhwZXJpbWVudGFsPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtleHBlcmll bmNlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtldmFsdWF0aW5nIHRoaXMgY2hhbmdlLiBUaGUgaW1wbGVtZW50YXRpb24g d2l0aDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ZXhwZXJpbWVudGFsIGV4cGVyaWVuY2U8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VzZXMgUFJS IChSRkMgNjkzNykgd2hpY2ggaXMgYW4gRXhwZXJpbWVudGFsPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb248YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2luY2x1ZGluZyBhPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtub3ZlbCAmcXVvdDt0cmljayZxdW90OyB0aGF0IGRpcmVjdHMgUFJSIGZhc3QgcmVjb3Zl cnkgdG88YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWZmZWN0aXZlbHk8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3VzZSBzbG93PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzdGFydCBpbiB0aGlzIGNhc2UgYXQgaGFuZC48YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IEluIG90aGVyIHdvcmRzLCBJIGFt IG5vdCBzZWVpbmcgYSBjYXNlIHRoYXQgcmVxdWlyZXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bmV3PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb25nZXN0aW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7IGNvbnRy b2wgY29uY2VwdHMgZXhjZXB0IGFzIGRpc2N1c3NlZCBpbiA5LjMuPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlZSBhYm92ZS4gVGhlIGNoYW5nZSBp biBzdGFuZGFyZCBjb25nZXN0aW9uIGNvbnRyb2wgZm9yPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsoMikuPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtUaGUgZHJhZnQgaW50ZW5kcyBub3QgdG8gY2hhbmdlIGNvbmdlc3Rpb24gY29udHJvbCBidXQ8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2VmZmVjdGl2ZWx5IGl0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkb2VzIHdpdGhvdXQgYW55IG9wZXJh dGlvbmFsIGV2aWRlbmNlLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtXaGF0J3MgYWxzbyBpcyBtaXNzaW5nIGFuZCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1 bDo8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSBG b3IgKDEpLCBhIGhpbnQgZm9yIGFuIGltcGxlbWVudGVyIHNheWluZyB0aGF0IGJlY2F1c2U8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1JBQ0stVExQIGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7YWJsZSB0byBkZXRlY3Qg YSBsb3NzIG9mIGEgcmV4bWl0IHVubGlrZSBhbnkgb3RoZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bG9zczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGV0ZWN0aW9uPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsg Jm5ic3A7YWxnb3JpdGhtLCB0aGUgc2VuZGVyIE1VU1QgcmVhY3QgdHdpY2UgdG8gY29uZ2VzdGlv bjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7KGFuZCBjaXRlPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7UkZDIDU2ODEpLiBB bmQgY2l0ZSBhIGRvY3VtZW50IHdoZXJlIG5lY2Vzc2FyeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtjb3JyZWN0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthY3Rpb25zPGJyPg0KJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsg Jm5ic3A7YXJlIGRlc2NyaWJlZC48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7LSBGb3IgKDEpLCBhZHZpc2UgdGhhdCBhbiBpbXBsZW1lbnRlciBuZWVk cyB0byBrZWVwPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RyYWNrPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDt3aGVuIGl0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7ZGV0ZWN0cyBhIGxvc3Mgb2YgYSBy ZXRyYW5zbWl0dGVkIHNlZ21lbnQuIEN1cnJlbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FsZ29yaXRobXM8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZuYnNwOyAmbmJzcDtpbiB0aGUgZHJhZnQgZGV0ZWN0IGEgbG9zcyBvZiByZXRyYW5zbWl0 dGVkIHNlZ21lbnQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2V4YWN0bHkgaW48YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDt0 aGUgc2FtZSB3YXkgYXMgbG9zcyBvZiBhbnkgb3RoZXIgc2VnbWVudC4gVGhlcmU8YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VlbXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RvIGJlPGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmbmJzcDsgJm5ic3A7bm90aGluZyB0byB0cmFjayB3aGVuIGEgcmV0cmFuc21pc3Npb24gb2Yg YTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7cmV0cmFuc21pdHRlZCBzZWdtZW50PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7 dGFrZXMgcGxhY2UuIFRoZXJlZm9yZSwgdGhlIGFsZ29yaXRobXMgc2hvdWxkIGhhdmU8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2FkZGl0aW9uYWw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDthY3Rpb25zIHRvIGNvcnJlY3Rs eSB0cmFjayB3aGVuIHN1Y2ggYSBsb3NzIGlzPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RldGVjdGVkLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDstIEZvciAoMSksIGRpc2N1c3Npb24gb24gaG93IG1hbnkgdGltZXMgYSBsb3Nz IG9mIGE8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3JldHJhbnNtaXNzaW9uPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgJm5ic3A7b2Yg dGhlIHNhbWUgc2VnbWVudCBtYXkgb2NjdXIgYW5kIGJlIGRldGVjdGVkLiBTZWVtczxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7dGhhdCBpdDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwO21heSBiZSBwb3NzaWJsZSB0byBkcm9w IGEgcmV4bWl0dGVkIHNlZ21lbnQgbW9yZSB0aGFuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvbmNlIGFuZDxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jm5ic3A7ICZuYnNwO2RldGVjdCBpdCBhbHNvIHNldmVyYWwgdGltZXM/Jm5ic3A7IFdoYXQg YXJlIHRoZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7aW1wbGljYXRpb25zPzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstIElmIHByZXZpb3VzIGlzIHBvc3NpYmxlLCB0aGVu IHRoZSBhbGdvcml0aG0gcG9zc2libHk8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7YWxzbzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwO21heSBkZXRlY3QgYSBsb3NzIG9mIGEgbmV3 IHNlZ21lbnQgdGhhdCB3YXMgc2VudDxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtkdXJpbmc8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2Zhc3Q8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDtyZWNvdmVyeT8g VGhpcyBpcyBhbHNvIGxvc3MgaW4gdHdvIHN1Y2Nlc3NpdmUgd2luZG93czxicj4NCiZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvZjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YSw8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw OyAmbmJzcDthbmQgY3duZCBNVVNUIGJlIGxvd2VyZWQgdHdpY2UuIFRoaXMgZGlzY3Vzc2lvbiBh bmQ8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO25lY2Vzc2FyeTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ICZuYnNwO2FjdGlvbnMgdG8g dHJhY2sgaXQgYXJlIG1pc3NpbmcsIGlmIHN1Y2ggc2NlbmFyaW8gaXM8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bvc3Np YmxlLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsm Z3Q7IFdoYXQgYW0gSSBtaXNzaW5nPzxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtIb3BlIHRoZSBhYm92ZSBoZWxwcy48YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7L01hcmtrdTxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0OyAmbHQ7c25p cHBpbmcgdGhlIHJlc3QmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CO2PR00MB016669CA3B63D26781DE0EF1B6C39CO2PR00MB0166namp_-- From nobody Sat Dec 19 09:24:15 2020 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 3166C3A0990; Fri, 18 Dec 2020 13:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 lufW1k_RFvfo; Fri, 18 Dec 2020 13:56:32 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757453A09C1; Fri, 18 Dec 2020 13:56:29 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Fri, 18 Dec 2020 23:56:27 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=Mw6JreVndLi1/m5xE KS1VjUVIHl0TBMC4+3rWLc8AgY=; b=UQjLC8PqCHqhMv7a2Dx7cOMTI6wHQBEjL ortAdfRKziY/tN3TYxGwNKnYStZcJYxmmDS8KehTHEXo3I4rrENYAecDTo5qpCA0 S/niG2tIVTA+ZSME6roqcMMTSpvBCYbUHbCHaf3eNlMtn0L9FaRxVFNRUJMfBvig CJGrO1G6+g= Received: from hp8x-60 (85-76-102-128-nat.elisa-mobile.fi [85.76.102.128]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Fri, 18 Dec 2020 23:56:27 +0200 id 00000000005A0170.000000005FDD258B.000006B8 Date: Fri, 18 Dec 2020 23:56:26 +0200 (EET) From: Markku Kojo To: Neal Cardwell cc: Yuchung Cheng , Praveen Balasubramanian , "martin.h.duke@gmail.com" , "tcpm@ietf.org" , "draft-ietf-tcpm-rack@ietf.org" , "tuexen@fh-muenster.de" , "draft-ietf-tcpm-rack.all@ietf.org" , "last-call@ietf.org" , "tcpm-chairs@ietf.org" In-Reply-To: Message-ID: References: <160557473030.20071.3820294165818082636@ietfa.amsl.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-1751-1608328587-0001-2" Archived-At: X-Mailman-Approved-At: Sat, 19 Dec 2020 09:24:09 -0800 Subject: Re: [tcpm] [EXTERNAL] Re: Last Call:(TheRACK-TLPlossdetectionalgorithmforTCP) toProposed Standard X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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, 18 Dec 2020 21:56:34 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-1751-1608328587-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi Neal, On Thu, 17 Dec 2020, Neal Cardwell wrote: > On Thu, Dec 17, 2020 at 2:36 PM Yuchung Cheng wrote= : > How about > =C2=A0 > "9.3.=C2=A0 Interaction with congestion control >=20 > RACK-TLP intentionally decouples loss detection ...=C2=A0 > As mentioned in Figure 1 caption, RFC5681 mandates a principle that > Loss in two successive windows of data, or the loss of a > retransmission, should be taken as two indications of congestion, and > therefore reacted separately. However implementation of RFC6675 pipe > algorithm may not directly account for this newly detected congestion > events properly. PRR [RFCxxxx] is RECOMMENDED for the specificcongestio= n control > actions taken upon the losses detected by RACK-TLP" >=20 > To Makku's request for "what's the justification to enter fast recovery= ". Consider this > example w/o RACK-TLP >=20 > T0: Send 100 segments but application-limited. All are lost. > T-2RTT: app writes so another 3 segments are sent. Made to the destinat= ion and > triggered 3 DUPACKs > T-3RTT: 3 DUPACK arrives. start fast recovery and subsequent cc reactio= ns to burst ~50 > packets with Reno=C2=A0 >=20 > In this case any ACK occured before RTO is (generally) considered clock= -acked, and > how=C2=A0I understand Van's initial design.=C2=A0 This behavior existed = decades before RACK-TLP. > RACK-TLP essentially changes the "3-segments by app" to "1-segment by t= cp".=C2=A0 >=20 >=20 > To amplify Yuchung's nice example, and try to restate it in more genera= l terms: >=20 > As far as I'm aware, TLP probes do not introduce materially new congest= ion control behaviors, > beyond what can happen with [RFC5681] and [RFC6675]. Please see my previous reply. No new congestion control behaviors if I=20 understand what you mean by that but there are more scenarios in which=20 loss of a full window is detected without RTO. > This is because a TLP probe serves much the same probing function that = an application write() > could have served, if the application had been so lucky as to time its = write at the > appropriate time (i.e. delay the write() of the last segment in the fli= ght to be 2*SRTT after > the preceding segment). >=20 > Thus, for any scenario that one constructs where a TLP probe initiates = a fast recovery > episode, it is possible to construct, for a TCP implementation implemen= ting just [RFC5681] > and [RFC6675], an application write() pattern where the on-the-wire beh= avior is nearly > identical to the TLP-initiated recovery. Except when the sender is congestion window limited. Receive window=20 limited is another case where application cannot write new data that=20 would get transmitted but a TLP probe could send the highest-sequence=20 segment? The draft is a bit unclear on this but I believe this was the intent=20 (draft says: "If such a segment is not available, ..." but in receive=20 window limited case such a new segment would be available but it cannot=20 be transmitted) > For folks concerned about a scenario with FlightSize of 100 segments, a= nd a sender entering > fast recovery and blasting 50 segments, the same behavior could happen = with the existing RFCs > [RFC5681] and [RFC6675], which allow that. And implementers who are wor= ried about such bursts > (a very reasonable thing to be worried about) should probably be implem= enting pacing and PRR, > or something like that. But that was already true before RACK-TLP. I would rather say it is a bug in RFC6675. Nobody paid sufficient=20 attention to such a scenario. Yes, PRR handles it fine, practically directing the sender to slow start=20 and start ack clock by limiting the number segments sent per incoming=20 Ack. Pure pacing over one RTT would not be enough in my opinion because i= t=20 still sends too many segments per RTT. Best regards, /Markku > best, > neal >=20 >=20 > --=_script-1751-1608328587-0001-2-- From nobody Mon Dec 21 00:20:28 2020 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 BCF053A0EF4 for ; Mon, 21 Dec 2020 00:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 e0P4unDyP987 for ; Mon, 21 Dec 2020 00:20:24 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BBAD3A0CA2 for ; Mon, 21 Dec 2020 00:20:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 269B925A28; Mon, 21 Dec 2020 09:20:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1608538822; bh=orI9WMD3FeyIGg2+6dfxes+6Aw6h36rILenO6dPxu3M=; h=From:To:CC:Subject:Date:From; b=N2bIjT6uHZM0jc2xlLyJfYgYeh0Hxgm3ZEcF/4Y7HI1PSELEgcNIcUTB8nw/w0Jtn i7ul0nykinxnXbTpKwSDu4oTBKSxmBAdT0UAn0FBXSKa3w1NvOvDeCuueC8GkRdaK1 ikCJFk/MxpJjw3/P9jQHlkGDut8YhH5NCG3xiXHg= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDfhcvvJWSyb; Mon, 21 Dec 2020 09:20:20 +0100 (CET) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 21 Dec 2020 09:20:20 +0100 (CET) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 21 Dec 2020 09:20:20 +0100 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Mon, 21 Dec 2020 09:20:20 +0100 From: "Scharf, Michael" To: Joseph Touch , Mirja Kuehlewind CC: Yoshifumi Nishida , tcpm IETF list Thread-Topic: Next steps for draft-ietf-tcpm-2140bis-06 Thread-Index: AdbXcew+RAOXR5VBROinmfBATQ2nbQ== Date: Mon, 21 Dec 2020 08:20:20 +0000 Message-ID: <287c102314004823883a71055173f0bb@hs-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: multipart/alternative; boundary="_000_287c102314004823883a71055173f0bbhsesslingende_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] Next steps for draft-ietf-tcpm-2140bis-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 08:20:27 -0000 --_000_287c102314004823883a71055173f0bbhsesslingende_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpUaGVyZSBoYXMgYmVlbiBubyBmb2xsb3ctdXAgbGlzdCBkaXNjdXNzaW9uLiBH aXZlbiB0aGUgbGFjayBvZiBmdXJ0aGVyIGlucHV0IGZyb20gdGhlIGNvbW11bml0eSwgdGhlIGNo YWlycyBhcHBhcmVudGx5IGhhdmUgdG8gbWFrZSBhIGNhbGwgb24gaG93IHRvIHByb2NlZWQgd2l0 aCBhcHBlbmRpeCBDIG9mIDIxNDBiaXMuDQoNCkhlcmUgaXMgbXkgY3VycmVudCB1bmRlcnN0YW5k aW5nIG9mIHRoZSBzaXR1YXRpb246DQoNCjEvIEFwcGVuZGl4IEMgaW4gZHJhZnQtaWV0Zi10Y3Bt LTIxNDBiaXMtMDYgaXMgbm90IGEgY29weSBvZiBkcmFmdC10b3VjaC10Y3BtLWF1dG9tYXRpYy1p dzsgdGhlIGNvbnRlbnQgaGFzIGJlZW4gcmV3cml0dGVuIHRvIGZpdCBpbnRvIHRoZSBzY29wZSBv ZiBkb2N1bWVudCBhcyBhIHJlc3VsdCBvZiBjb3JyZXNwb25kaW5nIFdHTEMgZmVlZGJhY2suIFRo ZXJlIGFyZSBmb2xsb3ctdXAgY29tbWVudHMgZnJvbSB0aGUgVENQTSB3b3JraW5nIGdyb3VwIHRo YXQgdGhlIGNvbnRlbnQgY291bGQgYmUgc2hvcnRlciwgYnV0IEkgYW0gbm90IGF3YXJlIG9mIHNw ZWNpZmljIHRleHQgc3VnZ2VzdGlvbnMgb3IgYW55IGZvcm0gb2YgcHJvZ3Jlc3MuDQoNCjIvIEFw YXJ0IGZyb20gdGhlIGF1dGhvcnMgYW5kIHNvbWUgZmV3IFRDUE0gY29udHJpYnV0b3JzLCB0aGUg cmVzdCBvZiB0aGUgVENQTSBjb21tdW5pdHkgYXBwYXJlbnRseSBzdGF5cyBzaWxlbnQuIE15IHJl YWRpbmcgaXMgdGhhdCBtYW55IFRDUE0gY29udHJpYnV0b3JzIGRvbuKAmXQgY2FyZSBhYm91dCBh cHBlbmRpeCBDIGFuZCBpdHMgbGVuZ3RoLiBJbiBzdWNoIGEgc2l0dWF0aW9uLCB0aGVyZSBpcyBu b3QgbXVjaCB0aGUgY2hhaXJzIGNhbiBkbyB0byByZWFjaCBjb25zZW5zdXMsIG90aGVyIHRoYW4s IHNheSwgdG9zc2luZyBhIGNvaW4uDQoNCjMvIGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2IGlz IGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYW5kIGNsZWFybHkgZmxhZ3MgYXBwZW5kaXggQyBh cyBhbiBleGFtcGxlLiBBbmQgYXBwZW5kaXggQyBpcyBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1bWVu dC4gVGhpcyB3aG9sZSBkaXNjdXNzaW9uIGlzIGFwcGFyZW50bHkgYWJvdXQgYSBtaW5vciBwYXJ0 IG9mIHRoZSBkb2N1bWVudC4NCg0KNC8gRmluaXNoaW5nIHRoaXMgZG9jdW1lbnQgbWF5IGJlIG1v cmUgaW1wb3J0YW50IGZvciB0aGUgV0cgdGhhbiBhcmd1aW5nIGFib3V0IGFuIGV4YW1wbGUgaW4g YW4gYXBwZW5kaXggb2YgYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC4gQmxvY2tpbmcgcHJvZ3Jl c3Mgb2YgMjE0MGJpcyBpbnNpZGUgVENQTSBiZWNhdXNlIG9mIHRoZSBsZW5ndGggb2YgYW4gYXBw ZW5kaXggZG9lcyBub3Qgc2VlbSB2ZXJ5IHVzZWZ1bC4gT3ZlcmFsbCwgaXQgaXMgY29tbXVuaXR5 IGNvbnNlbnN1cyB0aGF0IGl0IG1ha2VzIGEgbG90IG9mIHNlbnNlIHRvIHVwZGF0ZSAyMTQwIHdp dGggdGhpcyBkb2N1bWVudC4gV2l0aCB0aGUgY3VycmVudCAobGFjayBvZikgZmVlZGJhY2sgZnJv bSB0aGUgVENQTSBjb21tdW5pdHksIEkgZG9u4oCZdCBzZWUgaG93IHByb2dyZXNzIGNhbiBiZSBt YWRlIGluc2lkZSBUQ1BNIHJlZ2FyZGluZyBhcHBlbmRpeCBDLg0KDQpBcyBkb2N1bWVudCBzaGVw aGVyZCwgbXkgcHJvcG9zYWwgdG8gbW92ZSBmb3J3YXJkIGlzIGFzIGZvbGxvd3M6DQoNCjUvIEkg d2lsbCByZWNvcmQgaW4gbXkgc2hlcGhlcmQgd3JpdGUtdXAgdGhlIGtub3duIGNvbmNlcm5zIHJl Z2FyZGluZyBhcHBlbmRpeCBDIGFuZCBpdHMgbGVuZ3RoLCBhbmQgSSB3aWxsIGNsZWFybHkgc3Rh dGUgaW4gdGhlIHdyaXRlLXVwIHRoYXQgdGhlIGNvbnNlbnN1cyBvbiB3aGV0aGVyIHRvIGluY2x1 ZGUgYXBwZW5kaXggQyBpbiB0aGlzIGZvcm0gaXMgcm91Z2ggaW5zaWRlIFRDUE0uIFRodXMsIHRo ZSBwdXNoLWJhY2sgZnJvbSBwYXJ0cyBvZiB0aGUgd29ya2luZyBncm91cCBpcyBkb2N1bWVudGVk IGFuZCB2aXNpYmxlIGR1cmluZyBJRVRGIGxhc3QgY2FsbC4NCg0KNi8gSSBwbGFuIHRvIHNoaXAg dmVyc2lvbiAtMDYgdG8gdGhlIElFU0cgZW5kIG9mIHRoaXMgeWVhci4gVGhlIGRvY3VtZW50IHdp bGwgdGhlbiBnZXQgbW9yZSByZXZpZXdzLg0KDQpCZXN0IHJlZ2FyZHMNCg0KTWljaGFlbCAoYXMg ZG9jdW1lbnQgc2hlcGhlcmQpDQoNCg0KRnJvbTogSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFs cGhhLmNvbT4NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDIwIDQ6NTIgQU0NClRvOiBN aXJqYSBLdWVobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kPTQwZXJpY3Nzb24uY29tQGRtYXJjLmll dGYub3JnPg0KQ2M6IFlvc2hpZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFpbC5jb20+OyBTY2hh cmYsIE1pY2hhZWwgPE1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZT47IHRjcG0gSUVURiBs aXN0IDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0Y3BtXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLXRjcG0tMjE0MGJpcy0wNi50eHQNCg0KVG8gdGhlIFdHOg0KDQoNCk9uIERlYyAxNCwg MjAyMCwgYXQgMjo1NiBBTSwgTWlyamEgS3VlaGxld2luZCA8bWlyamEua3VlaGxld2luZD00MGVy aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86bWlyamEua3VlaGxld2luZD00MGVyaWNz c29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpJ4oCZbSBhbHNvIHN0aWxsIGNvbmNl cm5lZCBhYm91dCB0aGUgYXBwZW5kaXguIEkgdGhpbmsgYSBsaW5rIHRvIHRoZSBleHBpcmVkIGRy YWZ0IGFuZCBzb21lIHN1bW1hcnkgZGlzY3Vzc2lvbiB3b3VsZCBiZSBzdWZmaWNpZW50IHJhdGhl ciB0aGFuIGNvcHlpbmcgdGhlIHdob2xlIGV4cGlyZWQgZHJhZnQgaW4gdGhlIGFwcGVuZGl4IHRo YXQgbmV2ZXIgcmVhY2hlZCBhbnkgY29uc2Vuc3VzIGluIHRoZSBncm91cC4NCg0KV2UgaGF2ZSBh ZGRyZXNzZWQgdGhlc2UgY29tbWVudHMgYmVmb3JlIGFuZCBkaXNhZ3JlZSB3aXRoIHRoZW0uDQoN ClRoZSBtYXRlcmlhbCB3YXMgYXZhaWxhYmxlIHRvIHRoZSBXRyBmb3Igc2V2ZXJhbCBtb250aHMg YW5kIGhhcyByZWNlaXZlZCBubyBvYmplY3Rpb25zIGV4Y2VwdCBNaXJqYSdzIGR1cmluZyBXR0xD IGFuZCBZb3VzaGlmdW1p4oCZcyBub3cgbWFueSBtb250aHMgYWZ0ZXIgV0dMQy4NCg0KVGhlIGNv bnRlbnQgb2YgZXhwaXJlZCBJLURzIGNhbiBiZSByZW1vdmVkIGZyb20gcHVibGljIHZpZXcgYXQg YW55IHRpbWUsIHBlcjoNCmh0dHBzOi8vaWV0Zi5vcmcvYWJvdXQvZ3JvdXBzL2llc2cvc3RhdGVt ZW50cy9pbnRlcm5ldC1kcmFmdC1yZW1vdmFsLw0KDQpGaW5hbGx5LCBzZWUgdGhlICpleHBsaWNp dCogaW5zdHJ1Y3Rpb25zIGluIHRoZSByZXF1aXJlZCBib2lsZXJwbGF0ZSBvZiBldmVyeSBJLUQ6 DQoNCg0KICAgICAgIC4uLkl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0 cyBhcw0KDQogICByZWZlcmVuY2UgbWF0ZXJpYWwgLi4uDQoNCkkgd2lsbCBsZXQgbXkgY28tYXV0 aG9ycyBhZGRyZXNzIGhvdyB0byBwcm9jZWVkLg0KDQpKb2UNCg== --_000_287c102314004823883a71055173f0bbhsesslingende_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1h dGllcnQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFZv cmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNo biI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZv cm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3Js YWdlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBhbGwsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRo ZXJlIGhhcyBiZWVuIG5vIGZvbGxvdy11cCBsaXN0IGRpc2N1c3Npb24uIEdpdmVuIHRoZSBsYWNr IG9mIGZ1cnRoZXIgaW5wdXQgZnJvbSB0aGUgY29tbXVuaXR5LCB0aGUgY2hhaXJzIGFwcGFyZW50 bHkgaGF2ZSB0byBtYWtlIGEgY2FsbCBvbiBob3cgdG8gcHJvY2VlZCB3aXRoIGFwcGVuZGl4IEMg b2YgMjE0MGJpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+SGVyZSBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgb2YgdGhl IHNpdHVhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+MS8gQXBwZW5kaXggQyBpbiBkcmFmdC1pZXRmLXRjcG0tMjE0MGJp cy0wNiBpcyBub3QgYSBjb3B5IG9mIGRyYWZ0LXRvdWNoLXRjcG0tYXV0b21hdGljLWl3OyB0aGUg Y29udGVudCBoYXMgYmVlbiByZXdyaXR0ZW4gdG8gZml0IGludG8gdGhlIHNjb3BlIG9mIGRvY3Vt ZW50IGFzIGEgcmVzdWx0IG9mIGNvcnJlc3BvbmRpbmcgV0dMQyBmZWVkYmFjay4NCiBUaGVyZSBh cmUgZm9sbG93LXVwIGNvbW1lbnRzIGZyb20gdGhlIFRDUE0gd29ya2luZyBncm91cCB0aGF0IHRo ZSBjb250ZW50IGNvdWxkIGJlIHNob3J0ZXIsIGJ1dCBJIGFtIG5vdCBhd2FyZSBvZiBzcGVjaWZp YyB0ZXh0IHN1Z2dlc3Rpb25zIG9yIGFueSBmb3JtIG9mIHByb2dyZXNzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4yLyBBcGFy dCBmcm9tIHRoZSBhdXRob3JzIGFuZCBzb21lIGZldyBUQ1BNIGNvbnRyaWJ1dG9ycywgdGhlIHJl c3Qgb2YgdGhlIFRDUE0gY29tbXVuaXR5IGFwcGFyZW50bHkgc3RheXMgc2lsZW50LiBNeSByZWFk aW5nIGlzIHRoYXQgbWFueSBUQ1BNIGNvbnRyaWJ1dG9ycyBkb27igJl0IGNhcmUgYWJvdXQgYXBw ZW5kaXggQyBhbmQgaXRzIGxlbmd0aC4NCiBJbiBzdWNoIGEgc2l0dWF0aW9uLCB0aGVyZSBpcyBu b3QgbXVjaCB0aGUgY2hhaXJzIGNhbiBkbyB0byByZWFjaCBjb25zZW5zdXMsIG90aGVyIHRoYW4s IHNheSwgdG9zc2luZyBhIGNvaW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjMvIGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzLTA2 IGlzIGFuIGluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYW5kIGNsZWFybHkgZmxhZ3MgYXBwZW5kaXgg QyBhcyBhbiBleGFtcGxlLiBBbmQgYXBwZW5kaXggQyBpcyBhdCB0aGUgZW5kIG9mIHRoZSBkb2N1 bWVudC4gVGhpcyB3aG9sZSBkaXNjdXNzaW9uIGlzIGFwcGFyZW50bHkgYWJvdXQgYSBtaW5vcg0K IHBhcnQgb2YgdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj40LyBGaW5pc2hpbmcgdGhpcyBkb2N1bWVudCBt YXkgYmUgbW9yZSBpbXBvcnRhbnQgZm9yIHRoZSBXRyB0aGFuIGFyZ3VpbmcgYWJvdXQgYW4gZXhh bXBsZSBpbiBhbiBhcHBlbmRpeCBvZiBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LiBCbG9ja2lu ZyBwcm9ncmVzcyBvZiAyMTQwYmlzIGluc2lkZSBUQ1BNIGJlY2F1c2Ugb2YgdGhlIGxlbmd0aA0K IG9mIGFuIGFwcGVuZGl4IGRvZXMgbm90IHNlZW0gdmVyeSB1c2VmdWwuIE92ZXJhbGwsIGl0IGlz IGNvbW11bml0eSBjb25zZW5zdXMgdGhhdCBpdCBtYWtlcyBhIGxvdCBvZiBzZW5zZSB0byB1cGRh dGUgMjE0MCB3aXRoIHRoaXMgZG9jdW1lbnQuIFdpdGggdGhlIGN1cnJlbnQgKGxhY2sgb2YpIGZl ZWRiYWNrIGZyb20gdGhlIFRDUE0gY29tbXVuaXR5LCBJIGRvbuKAmXQgc2VlIGhvdyBwcm9ncmVz cyBjYW4gYmUgbWFkZSBpbnNpZGUgVENQTSByZWdhcmRpbmcNCiBhcHBlbmRpeCBDLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5B cyBkb2N1bWVudCBzaGVwaGVyZCwgbXkgcHJvcG9zYWwgdG8gbW92ZSBmb3J3YXJkIGlzIGFzIGZv bGxvd3M6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjUvIEkgd2lsbCByZWNvcmQgaW4gbXkgc2hlcGhlcmQgd3JpdGUtdXAgdGhl IGtub3duIGNvbmNlcm5zIHJlZ2FyZGluZyBhcHBlbmRpeCBDIGFuZCBpdHMgbGVuZ3RoLCBhbmQg SSB3aWxsIGNsZWFybHkgc3RhdGUgaW4gdGhlIHdyaXRlLXVwIHRoYXQgdGhlIGNvbnNlbnN1cyBv biB3aGV0aGVyIHRvIGluY2x1ZGUgYXBwZW5kaXggQyBpbiB0aGlzDQogZm9ybSBpcyByb3VnaCBp bnNpZGUgVENQTS4gVGh1cywgdGhlIHB1c2gtYmFjayBmcm9tIHBhcnRzIG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIGRvY3VtZW50ZWQgYW5kIHZpc2libGUgZHVyaW5nIElFVEYgbGFzdCBjYWxsLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj42LyBJIHBsYW4gdG8gc2hpcCB2ZXJzaW9uIC0wNiB0byB0aGUgSUVTRyBlbmQgb2YgdGhp cyB5ZWFyLiBUaGUgZG9jdW1lbnQgd2lsbCB0aGVuIGdldCBtb3JlIHJldmlld3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJl c3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5NaWNoYWVsIChhcyBkb2N1bWVudCBzaGVwaGVyZCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gSm9zZXBoIFRvdWNoICZsdDt0b3VjaEBzdHJheWFscGhhLmNvbSZndDsgPGJyPg0KPGI+ U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDE1LCAyMDIwIDQ6NTIgQU08YnI+DQo8Yj5Ubzo8 L2I+IE1pcmphIEt1ZWhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmQ9NDBlcmljc3Nvbi5jb21A ZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBZb3NoaWZ1bWkgTmlzaGlkYSAmbHQ7 bnNkLmlldGZAZ21haWwuY29tJmd0OzsgU2NoYXJmLCBNaWNoYWVsICZsdDtNaWNoYWVsLlNjaGFy ZkBocy1lc3NsaW5nZW4uZGUmZ3Q7OyB0Y3BtIElFVEYgbGlzdCAmbHQ7dGNwbUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXRjcG0tMjE0MGJpcy0wNi50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRvIHRoZSBXRzo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIERlYyAxNCwgMjAyMCwgYXQgMjo1NiBBTSwgTWlyamEgS3VlaGxld2luZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmciPm1pcmphLmt1ZWhsZXdpbmQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5J4oCZbSBhbHNvIHN0aWxsIGNvbmNlcm5lZCBhYm91dCB0aGUgYXBw ZW5kaXguIEkgdGhpbmsgYSBsaW5rIHRvIHRoZSBleHBpcmVkIGRyYWZ0IGFuZCBzb21lIHN1bW1h cnkgZGlzY3Vzc2lvbiB3b3VsZCBiZSBzdWZmaWNpZW50IHJhdGhlciB0aGFuIGNvcHlpbmcgdGhl IHdob2xlIGV4cGlyZWQgZHJhZnQgaW4gdGhlIGFwcGVuZGl4IHRoYXQgbmV2ZXIgcmVhY2hlZCBh bnkgY29uc2Vuc3VzDQogaW4gdGhlIGdyb3VwLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUg YWRkcmVzc2VkIHRoZXNlIGNvbW1lbnRzIGJlZm9yZSBhbmQgZGlzYWdyZWUgd2l0aCB0aGVtLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg bWF0ZXJpYWwgd2FzIGF2YWlsYWJsZSB0byB0aGUgV0cgZm9yIHNldmVyYWwgbW9udGhzIGFuZCBo YXMgcmVjZWl2ZWQgbm8gb2JqZWN0aW9ucyBleGNlcHQgTWlyamEncyBkdXJpbmcgV0dMQyBhbmQg WW91c2hpZnVtaeKAmXMgbm93IG1hbnkgbW9udGhzIGFmdGVyIFdHTEMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb250ZW50IG9mIGV4 cGlyZWQgSS1EcyBjYW4gYmUgcmVtb3ZlZCBmcm9tIHB1YmxpYyB2aWV3IGF0IGFueSB0aW1lLCBw ZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YSBocmVmPSJodHRwczovL2lldGYub3JnL2Fib3V0L2dyb3Vwcy9pZXNnL3N0YXRlbWVudHMvaW50 ZXJuZXQtZHJhZnQtcmVtb3ZhbC8iPmh0dHBzOi8vaWV0Zi5vcmcvYWJvdXQvZ3JvdXBzL2llc2cv c3RhdGVtZW50cy9pbnRlcm5ldC1kcmFmdC1yZW1vdmFsLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwgc2VlIHRoZSAqZXhw bGljaXQqIGluc3RydWN0aW9ucyBpbiB0aGUgcmVxdWlyZWQgYm9pbGVycGxhdGUgb2YgZXZlcnkg SS1EOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4uLi5JdCBpcyBpbmFwcHJvcHJp YXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVmZXJlbmNlIG1hdGVy aWFsIC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB3aWxsIGxldCBteSBjby1hdXRob3JzIGFkZHJlc3MgaG93IHRvIHByb2NlZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_287c102314004823883a71055173f0bbhsesslingende_-- From nobody Tue Dec 22 09:25:35 2020 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 4859E3A11AC; Tue, 22 Dec 2020 09:25:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <160865793025.27530.3318034260727413453@ietfa.amsl.com> Date: Tue, 22 Dec 2020 09:25:30 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-15.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:25:30 -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 WG of the IETF. Title : The RACK-TLP loss detection algorithm for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-15.txt Pages : 33 Date : 2020-12-22 Abstract: This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-15 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-15 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 Tue Dec 22 10:31:49 2020 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 2C8023A11EF; Tue, 22 Dec 2020 10:31:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-tcpm-rack.all@ietf.org, draft-ietf-tcpm-rack@ietf.org, martin.h.duke@gmail.com, rfc-editor@rfc-editor.org, tcpm-chairs@ietf.org, tcpm@ietf.org, tuexen@fh-muenster.de MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <160866189916.28506.11392747034242353024@ietfa.amsl.com> Date: Tue, 22 Dec 2020 10:31:39 -0800 Archived-At: Subject: [tcpm] Protocol Action: 'The RACK-TLP loss detection algorithm for TCP' to Proposed Standard (draft-ietf-tcpm-rack-15.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 18:31:39 -0000 The IESG has approved the following document: - 'The RACK-TLP loss detection algorithm for TCP' (draft-ietf-tcpm-rack-15.txt) as Proposed Standard This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Martin Duke and Magnus Westerlund. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ Technical Summary This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamps and selective acknowledgements (SACK) and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach. Working Group Summary The general approach was uncontroversial. As the algorithm is quite intricate, there were many comments to clarify the text and the pseudocode. Document Quality The core mechanisms described in the document are implemented in FreeBSD, Linux, and Windows. They are in active use on these platforms. RACK can also be used by other transport protocols. QUIC loss recovery uses the same ideas and there exists also an implementation for SCTP within a simulation environment. Personnel The document shepherd is Michael Tüxen. The Responsible AD is Martin Duke From nobody Wed Dec 23 08:25:06 2020 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 8EAA93A0BF6 for ; Wed, 23 Dec 2020 08:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 l4ApeIN-bJwY for ; Wed, 23 Dec 2020 08:25:02 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 CC58C3A0BEB for ; Wed, 23 Dec 2020 08:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-Id:To:References:Subject:Date: Mime-Version:Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=AUTic3iQZWenVQSnRFkKZdiGUDMSXbtdQEM8u5BGnbw=; b=oyqZO0uR+CAp5WGrkWwYMizIFZ 6RtJ3KwUNVfPCnvkcl4kasWXBJQDxV2lHyk6jhwdTf7ykik74voAoNX4im3IOGmSP7RvGssadlcIg DDvxXswRnYvm65z46WLcrsHGpohE2aS+fbE5tHr7mexU5OcYglCE3koXnYxBLwy5XjVk1VMux2eQj TyHgAeX8nfB0IfsvYC2SxNPNCfkEVICkOLPjUqH1QXiV4QLVXIqyihf7nn+s+O5Ts7kjrtu2KcXuE YTsLHwgNvACNa6L7MD2r3sSl3kP5aJQKlnqg4ncUfHRz4dyGKt1B2PlVBYJ7DRcC77PY7E9hbnj1u 4NkJbZ4g==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55437 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ks6wb-004IyG-7Y; Wed, 23 Dec 2020 11:25:02 -0500 From: Joseph Touch Content-Type: multipart/alternative; boundary="Apple-Mail=_BF6D841A-26ED-4508-92C8-D29F14A36367" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Wed, 23 Dec 2020 08:24:53 -0800 References: <160874037463.23530.8563775259935361876@ietfa.amsl.com> To: tcpm IETF list Message-Id: <052F35DD-1A5F-4F5A-9141-4662935A02DF@strayalpha.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [tcpm] Fwd: New Version Notification for draft-touch-tcpm-ao-test-vectors-02.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 16:25:05 -0000 --Apple-Mail=_BF6D841A-26ED-4508-92C8-D29F14A36367 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI.=20 The set now includes IPv6 test vectors. Joe > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-touch-tcpm-ao-test-vectors-02.txt > Date: December 23, 2020 at 8:19:34 AM PST > To: "Joe Touch" , "Joseph Touch" = , "Juhamatti Kuusisaari" = >=20 >=20 > A new version of I-D, draft-touch-tcpm-ao-test-vectors-02.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. >=20 > Name: draft-touch-tcpm-ao-test-vectors > Revision: 02 > Title: TCP-AO Test Vectors > Document date: 2020-12-23 > Group: Individual Submission > Pages: 26 > URL: = https://www.ietf.org/archive/id/draft-touch-tcpm-ao-test-vectors-02.txt > Status: = https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vectors/ > Htmlized: = https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-vectors > Htmlized: = https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-ao-test-vectors-02 >=20 > Abstract: > This document provides test vectors to validate implementations of > the two mandatory authentication algorithms specified for the TCP > Authentication Option over both IPv4 and IPv6. This includes > validation of the key derivation function (KDF) based on a set of > test connection parameters as well as validation of the message > authentication code (MAC). Vectors are provided for both currently > required pairs of KDF and MAC algorithms: one based on SHA-1 and the > other on AES-128. The vectors also validate both whole TCP segments > as well as segments whose options are excluded for NAT traversal. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 --Apple-Mail=_BF6D841A-26ED-4508-92C8-D29F14A36367 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI. 

The set now includes IPv6 test vectors.

Joe
Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-touch-tcpm-ao-test-vectors-02.txt
Date: = December 23, 2020 at 8:19:34 AM = PST
To: = "Joe Touch" <touch@strayalpha.com>, "Joseph Touch" <touch@strayalpha.com>, "Juhamatti Kuusisaari" <jkuusisaari@infinera.com>

A new version = of I-D, draft-touch-tcpm-ao-test-vectors-02.txt
has been = successfully submitted by Joe Touch and posted to the
IETF = repository.

Name: = draft-touch-tcpm-ao-test-vectors
Revision: 02
Title:= = TCP-AO Test Vectors
Document date: = 2020-12-23
Group: Individual Submission
Pages:= = 26
URL: =            https://www.ietf.org/archive/id/draft-touch-tcpm-ao-test-vector= s-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-touch-tcpm-ao-test-vecto= rs/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-tcpm-ao-test-= vectors
Htmlized: =       https://tools.ietf.org/html/draft-touch-tcpm-ao-test-vectors-02=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tcpm-ao-test-ve= ctors-02

Abstract:
=   This document provides test vectors to validate = implementations of
  the two mandatory = authentication algorithms specified for the TCP
=   Authentication Option over both IPv4 and IPv6. This = includes
  validation of the key derivation = function (KDF) based on a set of
  test = connection parameters as well as validation of the message
=   authentication code (MAC). Vectors are provided for both = currently
  required pairs of KDF and MAC = algorithms: one based on SHA-1 and the
  other = on AES-128. The vectors also validate both whole TCP segments
  as well as segments whose options are excluded = for NAT traversal.




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



= --Apple-Mail=_BF6D841A-26ED-4508-92C8-D29F14A36367-- From nobody Mon Dec 28 05:50:53 2020 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 22B5D3A0B2F; Mon, 28 Dec 2020 05:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de 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 e0W0f6zfOj1t; Mon, 28 Dec 2020 05:50:49 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDE43A0B22; Mon, 28 Dec 2020 05:50:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id EC66525A19; Mon, 28 Dec 2020 14:50:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1609163447; bh=b6kKX8yC35RTA2kDy6X5/Jco0aEaH//AUS7QeE45pPE=; h=From:To:CC:Subject:Date:From; b=JcQLUZTsrUXT2pdrSQZgZtFw/6IvGtsiksC2Wc18uhYIa2QDCfP3wS25P2xs64ruq RHH9lvva6YGI5U+1X5eWA/5vtVU1w2J/9GIAnB3DPlYNVi66shgWs+ZiTOhrYJvN19 wqzgq6Bh63pCS4hgSz1oLkA6PXFjEoDWfNsCkTyU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDzKawAUiRAR; Mon, 28 Dec 2020 14:50:46 +0100 (CET) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 28 Dec 2020 14:50:46 +0100 (CET) Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 28 Dec 2020 14:50:46 +0100 Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.1979.006; Mon, 28 Dec 2020 14:50:46 +0100 From: "Scharf, Michael" To: "draft-ietf-tcpm-2140bis@ietf.org" CC: tcpm IETF list Thread-Topic: Preparation of shepherd write-up for draft-ietf-tcpm-2140bis-06 Thread-Index: AdbdDEyr5Gaqj7IqSrCQFfBfh+bH1w== Date: Mon, 28 Dec 2020 13:50:45 +0000 Message-ID: <6ab76a404d784607a6ce84612bbb8fa2@hs-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.140.248] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Preparation of shepherd write-up for draft-ietf-tcpm-2140bis-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 13:50:51 -0000 Authors, I am preparing the shepherd write-up for draft-ietf-tcpm-2140bis. In additi= on to a small id-nit issue (which I have shared offlist already), I run int= o three issues in draft-ietf-tcpm-2140bis-06 during preparation of the writ= e-up: First, the table in Section 10 has the headline "CURRENT IMPLEMENTATION STA= TUS (as of 2016)". Given that the data is already a bit dated, I wonder whe= ther it would be possible to update this table? Otherwise, may be the word "current" should be removed? If no more recent d= ata can be gathered, I can write that in the shepherd write-up. Yet, others= could run into the date 2016 during IETF last call... Second, Section 7.3 states: "It is also possible to use sharing mechanisms over long timescales to adapt TCP's initial window automatically, as described further in Appendix A." I assume this refers to Appendix C? Given that I have to comment on appendi= x C in my write-up, I would like to ensure that this reference is correct i= n the document. Third, Section 2 states: "However, this document is intended to describe behavior that is already permitted by TCP standards. As a result, it provides informative guidance but does not use such normative language, except when quoting other documents." The last sentence may not be correct given that appendix C uses capital let= ter MUSTs. Note that TCPM has published informational documents with RFC211= 9/RFC8174 in the past already (e.g., RFC 8312), i.e., use of capital letter= words in informational descriptions of algorithms is not something new. No= netheless, the document 2140bis should at least be internally consistent. Best regards Michael From nobody Mon Dec 28 10:12:53 2020 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 8773C3A0CD9; Mon, 28 Dec 2020 10:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 zXBLXOJGS7wT; Mon, 28 Dec 2020 10:12:49 -0800 (PST) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 CB9A13A0CD8; Mon, 28 Dec 2020 10:12:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=miU1khrSklITfSpGZej0mhxwo7KJnS6Hq76AIY+GMBg=; b=veX7xOBWLpKKJqP5sHLJnB9zV rJWNL8yTNfUYA8E9AqSSK8XGbZuJB0GOVvbS5u2xFrqlpuVBjb572+S2YHLQ5EjVUfu5N/fCNP6mp JNtvfF7bHpbcooKj9Vo5M6FinHxTNJAU7XfO6GglE9YXqDtmJ4AnWGcBpCwiVaO0J8DjsxSNPE163 B2qYkUtjuQ6Wcl5z8jbYqZdKANXuOfX5UWelQdEEhD8m01TIYZ/NJZ5Iuau74L5xOUbyZVwnO92mN Ql+eyhOiV/pqY7t0C6P//0msodpC/Hfgcnf4hIGUJNDuQlID0qW75y1ZOkj0kbBZ08rGmqP5HNm+c QnX+9+ang==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:55646 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ktx0e-000Tb7-QI; Mon, 28 Dec 2020 13:12:49 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Joseph Touch In-Reply-To: <6ab76a404d784607a6ce84612bbb8fa2@hs-esslingen.de> Date: Mon, 28 Dec 2020 10:12:43 -0800 Cc: "draft-ietf-tcpm-2140bis@ietf.org" , tcpm IETF list Content-Transfer-Encoding: quoted-printable Message-Id: References: <6ab76a404d784607a6ce84612bbb8fa2@hs-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3654.40.0.2.32) X-OutGoing-Spam-Status: No, score=-0.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Preparation of shepherd write-up for draft-ietf-tcpm-2140bis-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 18:12:52 -0000 All items are addressed. If my coauthors would like to recheck the 2016 table, we can update the = doc to refer to =E2=80=9Cat the time of publication=E2=80=9D rather than = 2016. The -07 update will be reposted in a few minutes. Joe > On Dec 28, 2020, at 5:50 AM, Scharf, Michael = wrote: >=20 > Authors, >=20 > I am preparing the shepherd write-up for draft-ietf-tcpm-2140bis. In = addition to a small id-nit issue (which I have shared offlist already), = I run into three issues in draft-ietf-tcpm-2140bis-06 during preparation = of the write-up: >=20 > First, the table in Section 10 has the headline "CURRENT = IMPLEMENTATION STATUS (as of 2016)". Given that the data is already a = bit dated, I wonder whether it would be possible to update this table? >=20 > Otherwise, may be the word "current" should be removed? If no more = recent data can be gathered, I can write that in the shepherd write-up. = Yet, others could run into the date 2016 during IETF last call... >=20 > Second, Section 7.3 states: >=20 > "It is also possible to > use sharing mechanisms over long timescales to adapt TCP's initial > window automatically, as described further in Appendix A." >=20 > I assume this refers to Appendix C? Given that I have to comment on = appendix C in my write-up, I would like to ensure that this reference is = correct in the document. >=20 > Third, Section 2 states: >=20 > "However, this document is intended to describe behavior that is > already permitted by TCP standards. As a result, it provides > informative guidance but does not use such normative language, > except when quoting other documents." >=20 > The last sentence may not be correct given that appendix C uses = capital letter MUSTs. Note that TCPM has published informational = documents with RFC2119/RFC8174 in the past already (e.g., RFC 8312), = i.e., use of capital letter words in informational descriptions of = algorithms is not something new. Nonetheless, the document 2140bis = should at least be internally consistent. >=20 > Best regards >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Dec 28 10:21:31 2020 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 0EEE33A0AC1; Mon, 28 Dec 2020 10:21:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <160917969001.18376.6922825114972125244@ietfa.amsl.com> Date: Mon, 28 Dec 2020 10:21:30 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-2140bis-07.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 18:21:30 -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 WG of the IETF. Title : TCP Control Block Interdependence Authors : Joe Touch Michael Welzl Safiqul Islam Filename : draft-ietf-tcpm-2140bis-07.txt Pages : 34 Date : 2020-12-28 Abstract: This memo provides guidance to TCP implementers that are intended to help improve convergence to steady-state operation without affecting interoperability. It updates and replaces RFC 2140's description of interdependent TCP control blocks and the ways that part of TCP state can be shared among similar concurrent or consecutive connections. TCP state includes a combination of parameters, such as connection state, current round-trip time estimates, congestion control information, and process information. Most of this state is maintained on a per-connection basis in the TCP Control Block (TCB), but implementations can (and do) share certain TCB information across connections to the same host. Such sharing is intended to improve overall transient transport performance, while maintaining backward-compatibility with existing implementations. The sharing described herein is limited to only the TCB initialization and so has no effect on the long-term behavior of TCP after a connection has been established. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-2140bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-2140bis-07 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 Mon Dec 28 11:30:31 2020 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 3C10A3A0CDF; Mon, 28 Dec 2020 11:30:29 -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, SPF_PASS=-0.001, URIBL_BLOCKED=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 1Kp8wDKhRbUQ; Mon, 28 Dec 2020 11:30:27 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (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 85E8A3A0C93; Mon, 28 Dec 2020 11:30:25 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1ktyDj-00076I-EW; Mon, 28 Dec 2020 20:30:19 +0100 Received: from ti0182q160-1994.bb.online.no ([212.251.170.224] helo=[192.168.1.11]) by mail-mx11.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1ktyDj-0007Xn-36; Mon, 28 Dec 2020 20:30:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Michael Welzl In-Reply-To: Date: Mon, 28 Dec 2020 20:30:16 +0100 Cc: "Scharf, Michael" , tcpm IETF list , "draft-ietf-tcpm-2140bis@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3AFDC030-BB82-47EC-9ACB-9A943EAD0CB7@ifi.uio.no> References: <6ab76a404d784607a6ce84612bbb8fa2@hs-esslingen.de> To: Joseph Touch X-Mailer: Apple Mail (2.3608.120.23.2.4) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 212.251.170.224 is neither permitted nor denied by domain of ifi.uio.no) client-ip=212.251.170.224; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.11]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.032, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 902AF10C93F74AAC30E63F919AA30AF9C2392777 Archived-At: Subject: Re: [tcpm] Preparation of shepherd write-up for draft-ietf-tcpm-2140bis-06 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 19:30:29 -0000 > On Dec 28, 2020, at 7:12 PM, Joseph Touch = wrote: >=20 > All items are addressed. >=20 > If my coauthors would like to recheck the 2016 table, we can update = the doc to refer to =E2=80=9Cat the time of publication=E2=80=9D rather = than 2016. ACK. > The -07 update will be reposted in a few minutes. Thanks a lot for this update Joe! Cheers, Michael From nobody Tue Dec 29 12:07:12 2020 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 5107D3A091C; Tue, 29 Dec 2020 12:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 9Nv1GkQD-cAc; Tue, 29 Dec 2020 12:07:08 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DD0FF3A0927; Tue, 29 Dec 2020 12:07:07 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BTK6uw5004601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Dec 2020 15:07:01 -0500 Date: Tue, 29 Dec 2020 12:06:56 -0800 From: Benjamin Kaduk To: Yuchung Cheng Cc: The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Message-ID: <20201229200656.GG89068@kduck.mit.edu> References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 20:07:11 -0000 Hi Yuchung, On Fri, Dec 18, 2020 at 05:59:20PM -0800, Yuchung Cheng wrote: > On Thu, Dec 17, 2020 at 9:55 AM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-tcpm-rack-14: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for presenting this complicated topic in a very easy-to-read > > manner! > > > Thank you for your review. > > > > > > Section 3.3.2 > > > > 1. The reordering window SHOULD be set to zero if no reordering has > > been observed on the connection so far, and either (a) three > > segments have been delivered out of order since the last recovery > > > > I assume there's some subtle technical difference between "reordering" > > and "segments delivered out of order" that makes this a reasonable thing > > to say ... but it would be nice if the distincion was made more clear > > (whether here or in earlier text). > > > Great idea to define reordering more precisely. In this document, > reordering refers to when two TCP segments are delivered at the TCP > receiver in a different order from they were sent at the TCP sender for a > given TCP flow. Notice the ordering is chronological instead of sequential > on TCP sequences. > > We'll add that definition on the first appearance of the word 'reordering' > to clarify. I am quite confident that you know how this works, though I am not sure that I understand properly yet -- is the key distinction that "reordering has been observed" and "segments have been delivered out of order" refer to time vs TCP sequence number? (There's not actually a need to respond; I am sure the document will be correct. I am just curious, is all.) > > > > > Section 6.2 > > > > Among all the segments newly ACKed or SACKed by this ACK that pass > > the checks above, update the RACK.rtt to be the RTT sample calculated > > using this ACK. Furthermore, record the most recent Segment.xmit_ts > > in RACK.xmit_ts if it is ahead of RACK.xmit_ts. If Segment.xmit_ts > > equals RACK.xmit_ts (e.g. due to clock granularity limits) then > > compare Segment.end_seq and RACK.end_seq to break the tie. > > > > Perhaps we should state what the result of breaking the tie is used for > > (i.e., updating RACK.segment & co.)? > > > > sure: we'll add "breaking the tie to update RACK.segment's associated > states'. > > > > > > To avoid the issue above, RACK dynamically adapts to higher degrees > > of reordering using DSACK options from the receiver. Receiving an > > ACK with a DSACK option indicates a possible spurious retransmission, > > suggesting that RACK.reo_wnd may be too small. The RACK.reo_wnd > > increases linearly for every round trip in which the sender receives > > some DSACK option, so that after N distinct round trips in which a > > DSACK is received, the RACK.reo_wnd becomes (N+1) * min_RTT / 4, with > > an upper-bound of SRTT. > > > > What constitutes a "distinct round trip"? > > > The distinct is redundant. It really means N round trips (which obviously > are distinct and different from the other N-1). We'll remove 'distinct' > word. > > > > > > Return min(RACK.min_RTT / 4 * RACK.reo_wnd_mult, SRTT) > > > > I suggest reordering the expression to be min(RACK.reo_wnd_mult * > > RACK.min_RTT / 4, SRTT), to avoid needing to consider the order of > > operations and operator precedence in the pseudocode. (soapbox: in > > formal mathematics, there is no "division" operation, just > > multiplication by the multiplicative inverse, in part because it makes > > dealing with associativity and commutativity of operations harder to > > reason about.) > > > Sure we'll change to the suggested more clear format. > > > > > > Section 8 > > > > sender SHOULD cancel any other pending timer(s). An implementation > > is to have one timer with an additional state variable indicating the > > type of the timer. > > > > nit: maybe "is expected to have one timer", to avoid any risk of being > > interpreted as over-specifying implementation behavior? > > > good idea. will add "expected". > > > > > > Is there anything to say about increasing the usage of fast recovery > > (vs RTO) potentially having an aggregate effect globally on how much > > data is in flight and increasing the overall risk of congestion? (I > > mostly assume not, but it's kind of my job to ask.) > > > Great question. We agree with you: our conjecture is that RACK-TLP reduces > (loss-based) C.C. over-correction and BW under-utilization than C.C. > under-correction, particularly for app-limited short flows. For bulk long > flows that comprise the majority of the Internet traffic volume, most > losses are well detected by the existing 3-dupack-rule since the flows' > congestion windows are large enough to trigger 3 dupacks. RACK-TLP actually > helps reduce spurious fast recoveries on moderately reordered paths for > these long flows. But overall in our experience, the state of congestion is > much dominated by the actual C.C. algorithms (e.g. slow-start, increase and > decrease functions) of these long flows and less about #fast-recoveries. Okay. Thank you for thinking about it, and thanks for all the updates. -Ben > > > > > Section 13.1 > > > > In terms of how we reference it, RFC 3042 seems like it could be > > informative. > > > Good catch. will move to normative From nobody Tue Dec 29 20:05:07 2020 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 298003A0EB2 for ; Tue, 29 Dec 2020 20:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 6N4S4DVvqNjT for ; Tue, 29 Dec 2020 20:04:59 -0800 (PST) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 5F0033A0D2D for ; Tue, 29 Dec 2020 20:04:59 -0800 (PST) Received: by mail-vs1-xe2b.google.com with SMTP id s85so8038684vsc.3 for ; Tue, 29 Dec 2020 20:04:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wAsjKaUBlk1pcpJa/WVO6aDzIpCDhJ0n0+RJzGVXLgs=; b=CRHIBVsOM5K3GfIw6wwJSdkHaMnYpKmMwZX504szMWcQcsvVh9nu44+Oo/Fwn/0raa crhdawrW77AatWQcEVKHZvZ0kRS9aHdm6/ej56AjzQAD+/jM2enx6kXopNMThYMJ0vpY VviPCkh89dxlPwdm+rjyVxK+49IFuH2I1vf4qM9WszcfYZBrtB8+vsT2WI3oHz31g81O wTq6N3AL4sebFkRzJRYPgKJLXMDia7iVoJz39/hJAYZy2lKCPH8oKcnWwtWz9PEfLg3a TW98Nc6UfMdynIg9MwwzaTCW/0IfecYcXfDwG9m060l3/EgmksyAYJfV0Gez8vlUWBN8 E0FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wAsjKaUBlk1pcpJa/WVO6aDzIpCDhJ0n0+RJzGVXLgs=; b=kdMS/ZYve7LOJ+OY0ED7Gf3kJSIoZH14ABfT2vRtVKAWEUv7QhxsBTFTs4SdFNKqn/ eLc4soJ+jw5CK9HUfk+2DqcMpekNrgmLC3mZovqwe+4Ww24tJ3PpTyfUxfWN34F8D2pn FfDjRfi4TDNU+7bRfIQ2Gx4BK3iwy7Ji9y3LZv6pxOOnT2+WuAMoJc03MWjE0p1vPbAI 82ZcfpRzOX2oeZvqDBR4mgkrSOFBvpm2RMxMHJc7Kq0PyB84sLdA/H5apExFCnZzvVVs molIindvpWuoIB1o6Yk+WWYCb63w9z8sAnZAvsKQ5XiH/G8xsvN7u0Npt60yM9hzKpop 6wuw== X-Gm-Message-State: AOAM533W3pfuOBikrP1kfOPEV3M8bhmqejy706vWlbbHA+vGCrRHlou3 aIlEQy0aSy5bereo1A77VAjdCCfisX4gmtrBpEGZgA== X-Google-Smtp-Source: ABdhPJwMaj/33vBot2ULlXGXDeF5eTV52X1RvjAUoXPrn1vzglZ7dqcmQh911RFgf/jyAEwNheW7Fp2jVE64QhyO5V4= X-Received: by 2002:a67:cd9a:: with SMTP id r26mr32239319vsl.52.1609301098034; Tue, 29 Dec 2020 20:04:58 -0800 (PST) MIME-Version: 1.0 References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> <20201229200656.GG89068@kduck.mit.edu> In-Reply-To: <20201229200656.GG89068@kduck.mit.edu> From: Neal Cardwell Date: Tue, 29 Dec 2020 23:04:41 -0500 Message-ID: To: Benjamin Kaduk Cc: Yuchung Cheng , The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="0000000000004973f405b7a69c18" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 04:05:02 -0000 --0000000000004973f405b7a69c18 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk wrote: > > > Section 3.3.2 > > > > > > 1. The reordering window SHOULD be set to zero if no reordering has > > > been observed on the connection so far, and either (a) three > > > segments have been delivered out of order since the last > recovery > > > > > > I assume there's some subtle technical difference between "reordering" > > > and "segments delivered out of order" that makes this a reasonable > thing > > > to say ... but it would be nice if the distincion was made more clear > > > (whether here or in earlier text). > > > > > Great idea to define reordering more precisely. In this document, > > reordering refers to when two TCP segments are delivered at the TCP > > receiver in a different order from they were sent at the TCP sender for a > > given TCP flow. Notice the ordering is chronological instead of > sequential > > on TCP sequences. > > > > We'll add that definition on the first appearance of the word > 'reordering' > > to clarify. > > I am quite confident that you know how this works, though I am not sure > that I understand properly yet -- is the key distinction that "reordering > has been observed" and "segments have been delivered out of order" refer to > time vs TCP sequence number? (There's not actually a need to respond; I am > sure the document will be correct. I am just curious, is all.) > Benjamin, I think I did not previously understand your earlier remark: 'I assume there's some subtle technical difference between "reordering" and "segments delivered out of order" that makes this a reasonable thing to say... ' But now I think perhaps I understand what you were getting at: were you remarking that there is an apparent contradiction in the text between "no reordering has been observed on the connection so far" and "three segments have been delivered out of order", so that it seems impossible for the connection to meet the conditions for both "no reordering has been observed on the connection so far" and "(a) three segments have been delivered out of order since the last recovery"? I agree that the text of the draft as currently written seems contradictory or at least unclear. :-) The "three segments have been delivered out of order" phrase in the draft was meant to refer to three segments being SACKed. But now that you raise this point, it seems to me it would be more correct and clear to say something like "three segments have been SACKed", rather than "three segments have been delivered out of order". >From my perspective, the SACKed segments are not necessarily "delivered out of order", they merely have at least one hole in the sequence space. For example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out of order", and were they TCP segments we would not say that reordering has been observed; it's just that 2 is not (yet?) present. I also like the "three segments have been SACKed" phrase since the "have been SACKed" phrase is used in RFC6675 for a similar purpose in the description of "IsLost (SeqNum):" If it's not too late for edits, I would propose that the section you mentioned ("3.3.2 . Reordering window adaptation") that says: 1. The reordering window SHOULD be set to zero if no reordering has been observed on the connection so far, and either (a) three segments *have been delivered out of order* since the last recovery or (b) the sender is already in fast or RTO recovery. would be edited to: 1. The reordering window SHOULD be set to zero if no reordering has been observed on the connection so far, and either (a) three segments *have been SACKed* since the last recovery or (b) the sender is already in fast or RTO recovery. Benjamin, does that help address what you were talking about? best, neal --0000000000004973f405b7a69c18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 29, 2020 at 3:07 PM Benja= min Kaduk <kaduk@mit.edu> wrote:=
> > Section 3.3.2
> >
> >=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be set to zero= if no reordering has
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connection so far= , and either (a) three
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments have been delivered out of or= der since the last recovery
> >
> > I assume there's some subtle technical difference between &qu= ot;reordering"
> > and "segments delivered out of order" that makes this a= reasonable thing
> > to say ... but it would be nice if the distincion was made more c= lear
> > (whether here or in earlier text).
> >
> Great idea to define reordering more precisely. In this document,
> reordering refers to when two TCP segments are delivered at the TCP > receiver in a different order from they were sent at the TCP sender fo= r a
> given TCP flow. Notice the ordering is chronological instead of sequen= tial
> on TCP sequences.
>
> We'll add that definition on the first appearance of the word '= ;reordering'
> to clarify.

I am quite confident that you know how this works, though I am not sure
that I understand properly yet -- is the key distinction that "reorder= ing
has been observed" and "segments have been delivered out of order= " refer to
time vs TCP sequence number?=C2=A0 (There's not actually a need to resp= ond; I am
sure the document will be correct.=C2=A0 I am just curious, is all.)

Benjamin, I think I did not previously unders= tand your earlier remark: 'I assume there's some subtle technical d= ifference between "reordering"
and "segments delivered = out of order" that makes this a reasonable thing to say...=C2=A0'<= /div>

But no= w I think perhaps I understand what you were getting at: were you remarking= that there is an apparent contradiction in the text between "no reord= ering has been observed on the connection so far" and "three segments have been delivered out of order", so that it seems im= possible for the connection to meet the conditions for both "no reorde= ring has been observed on the connection so far" and "(a) three segments have been delivered out of order since the last recovery&qu= ot;?

I= agree that the text of the draft as currently written seems contradictory = or at least unclear. :-)

The=C2=A0"three segments have been delivered out of order" phrase in the draft = was meant to refer to three segments being SACKed. But now that you raise t= his point, it seems to me it would be more correct and clear to say somethi= ng like "three segments=C2=A0have been SACKed", rather than=C2=A0"three segments have been delivered out of order".=C2=A0

<= div class=3D"gmail_quote">From my perspective, the SACKed segments are not necessarily "deli= vered out of order", they merely have at least one hole in the sequenc= e space. For example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not &= quot;out of order", and were they TCP segments we would not say that r= eordering has been observed; it's just that 2 is not (yet?) present.

I also like the = "three segments=C2=A0have been SACKed" phrase since the "have been SACKed&q= uot; phrase is used in RFC6675 for a similar purpose in the description of = "IsLost (SeqNum):"

<= /div>
If it's not too late for edits, I would propose that the sect= ion you mentioned ("3.3.2. Reordering window adaptation") that says:

<= /div>
   1.  The re=
ordering window SHOULD be set to zero if no reordering has
       been observed on the connection so far, and either (a) three
       segments have been delivered out of order since the last reco=
very
       or (b) the sender is already in fast or RTO recovery.

would be edited to:

   1.  The reo=
rdering window SHOULD be set to zero if no reordering has
       been observed on the connection so far, and either (a) three
       segments have been SACKed since the last recovery
       or (b) the sender is already in fast or RTO recovery.

Benjamin, does that help =
address what you were talking about?

best,
neal

--0000000000004973f405b7a69c18-- From nobody Tue Dec 29 21:42:33 2020 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 7240C3A0FB3; Tue, 29 Dec 2020 21:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 aA-3ROKJW6rM; Tue, 29 Dec 2020 21:42:29 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0F1B33A0FB2; Tue, 29 Dec 2020 21:42:28 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BU5gGJJ029837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Dec 2020 00:42:20 -0500 Date: Tue, 29 Dec 2020 21:42:16 -0800 From: Benjamin Kaduk To: Neal Cardwell Cc: Yuchung Cheng , The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Message-ID: <20201230054144.GU89068@kduck.mit.edu> References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> <20201229200656.GG89068@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 05:42:32 -0000 Hi Neal, On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote: > On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk wrote: > > > > > Section 3.3.2 > > > > > > > > 1. The reordering window SHOULD be set to zero if no reordering has > > > > been observed on the connection so far, and either (a) three > > > > segments have been delivered out of order since the last > > recovery > > > > > > > > I assume there's some subtle technical difference between "reordering" > > > > and "segments delivered out of order" that makes this a reasonable > > thing > > > > to say ... but it would be nice if the distincion was made more clear > > > > (whether here or in earlier text). > > > > > > > Great idea to define reordering more precisely. In this document, > > > reordering refers to when two TCP segments are delivered at the TCP > > > receiver in a different order from they were sent at the TCP sender for a > > > given TCP flow. Notice the ordering is chronological instead of > > sequential > > > on TCP sequences. > > > > > > We'll add that definition on the first appearance of the word > > 'reordering' > > > to clarify. > > > > I am quite confident that you know how this works, though I am not sure > > that I understand properly yet -- is the key distinction that "reordering > > has been observed" and "segments have been delivered out of order" refer to > > time vs TCP sequence number? (There's not actually a need to respond; I am > > sure the document will be correct. I am just curious, is all.) > > > > Benjamin, I think I did not previously understand your earlier remark: 'I > assume there's some subtle technical difference between "reordering" > and "segments delivered out of order" that makes this a reasonable thing to > say... ' > > But now I think perhaps I understand what you were getting at: were you > remarking that there is an apparent contradiction in the text between "no > reordering has been observed on the connection so far" and "three segments > have been delivered out of order", so that it seems impossible for the > connection to meet the conditions for both "no reordering has been observed > on the connection so far" and "(a) three segments have been delivered out > of order since the last recovery"? Exactly so! Sorry for not having been more clear originally. > I agree that the text of the draft as currently written seems contradictory > or at least unclear. :-) Well, I guess I can feel better about having been confused by it, now :) > The "three segments have been delivered out of order" phrase in the draft > was meant to refer to three segments being SACKed. But now that you raise > this point, it seems to me it would be more correct and clear to say > something like "three segments have been SACKed", rather than "three > segments have been delivered out of order". > > From my perspective, the SACKed segments are not necessarily "delivered out > of order", they merely have at least one hole in the sequence space. For > example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out of > order", and were they TCP segments we would not say that reordering has > been observed; it's just that 2 is not (yet?) present. Indeed, there is some subjectivity in the definition of "out of order". (My initial draft comments on this document had included a request for more clarity on how to tell which segments are "out of order" as compared to some baseline, but I deleted it once I got to, IIRC, discussion in Section 6.2 about segments below RACK.fack getting acknowledged as being ones delivered out of order, which I took to be effectively a definition, and seemed well-formed at the time. Though perhaps that formulation is not well-defined for what it means for a retransmitted segment to be out-of-order...) If we apply the definition of "a segment is delivered out of order if, when it is ACKd, RACK.fack is greater than its sequence number" to your example above, it seems like we would conclude that 2 is out of order, but 3, 4, and 5 are in-order. (Right?) > I also like the "three segments have been SACKed" phrase since the "have > been SACKed" phrase is used in RFC6675 for a similar purpose in the > description of "IsLost (SeqNum):" Also a pretty compelling argument. > If it's not too late for edits, I would propose that the section you > mentioned ("3.3.2 > . > Reordering window adaptation") that says: > > 1. The reordering window SHOULD be set to zero if no reordering has > been observed on the connection so far, and either (a) three > segments *have been delivered out of order* since the last recovery > or (b) the sender is already in fast or RTO recovery. > > > would be edited to: > > > 1. The reordering window SHOULD be set to zero if no reordering has > been observed on the connection so far, and either (a) three > segments *have been SACKed* since the last recovery > or (b) the sender is already in fast or RTO recovery. > > > Benjamin, does that help address what you were talking about? Yes. From my point of view, that proposal is a big improvement. Thanks, Ben From nobody Wed Dec 30 05:55:46 2020 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 1DE5D3A0AD5 for ; Wed, 30 Dec 2020 05:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 kEQ1j6KYefcq for ; Wed, 30 Dec 2020 05:55:43 -0800 (PST) Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (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 0E3663A0AC3 for ; Wed, 30 Dec 2020 05:55:42 -0800 (PST) Received: by mail-vk1-xa32.google.com with SMTP id m145so3629716vke.7 for ; Wed, 30 Dec 2020 05:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ltftvTSAZPLpt4IMOr/eMnTrcoeUdYy9enm9sEN9t/E=; b=Du/jWvISvEliG0z2Dh2wdyLhr7+H4b2jsyTDPlmDNfxXC7MhJ+vIQJwqwLUYn+CGVg u9gnXvKV/+RKJhoYof9vCwVJFssLCyXcPjb0o/Fmo6yl8uB7XrbFqk6FycPyCyop/j9E SMEbnQaY8sdxbdJnPzmhkoW59EWAR8mt3Y765EM4oLPGcKSD75QKaubHdDP9UNaUsDNQ QLfvknOr+4eZSH0UCXH03t0LRO9jSYrZheAWDPBUUFgMBOq0+qZld5OjNTc/L/QGlNX7 Uf/ZUEsWh5E98zkv01+ojkB07t57XeiYItPkGNmxzn7IWuHjtqkv05+V1YYgs2br6XbG C6XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ltftvTSAZPLpt4IMOr/eMnTrcoeUdYy9enm9sEN9t/E=; b=Cto7p5uMHN9/BJuUfBACCv0KreVLgffcR2Ay1lq08tOHNUZsXMCp+BknYWlk5QYHA/ cdHznnfM7fzejNN3pQm1EYbnQA/qCod0e7h0ajDO71M8OyRnBHXRD4pfBo2leu5Acu1D WbY10YPCfpHlxRIQRK7+iWaIRjLzWim19qX3ymY7TX1knZdAmIl2D22YjTUArr+2bflE xQaJ3t+H3sB7fF4wyGVl3WpemfH0RMloYfKTJnDc1T7o7WEkoKaiTMfRf75TKHWYTNZr Znpg7hGJXlGgldeO0uwFxLY+Vn1NIIiwodfn2W+dRZ8EVBO7Hm4fB/jVVI2UiLYFZIWc NjMQ== X-Gm-Message-State: AOAM531WUFwts/Go+VNKX090/42bExCZ20v+44nODWg+UKcVEfDCzx9r jbL03DnMjf4NdWlNOqBg/OQaPVQqAkWVvlO2JGJvUA== X-Google-Smtp-Source: ABdhPJyvdTRYlJt9/Du3QG0Rkh+p3UYLoNhe2RWe00++vJqk6NsF2+7x+J/hs4nbX1lBw7nInVMZSnUgn3p1U9wiSYE= X-Received: by 2002:a1f:8d92:: with SMTP id p140mr35276595vkd.19.1609336541736; Wed, 30 Dec 2020 05:55:41 -0800 (PST) MIME-Version: 1.0 References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> <20201229200656.GG89068@kduck.mit.edu> <20201230054144.GU89068@kduck.mit.edu> In-Reply-To: <20201230054144.GU89068@kduck.mit.edu> From: Neal Cardwell Date: Wed, 30 Dec 2020 08:55:25 -0500 Message-ID: To: Benjamin Kaduk Cc: Yuchung Cheng , The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/alternative; boundary="000000000000e5650205b7aedc5b" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 13:55:45 -0000 --000000000000e5650205b7aedc5b Content-Type: text/plain; charset="UTF-8" On Wed, Dec 30, 2020 at 12:42 AM Benjamin Kaduk wrote: > Hi Neal, > > On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote: > > On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk wrote: > > > > > > > Section 3.3.2 > > > > > > > > > > 1. The reordering window SHOULD be set to zero if no > reordering has > > > > > been observed on the connection so far, and either (a) three > > > > > segments have been delivered out of order since the last > > > recovery > > > > > > > > > > I assume there's some subtle technical difference between > "reordering" > > > > > and "segments delivered out of order" that makes this a reasonable > > > thing > > > > > to say ... but it would be nice if the distincion was made more > clear > > > > > (whether here or in earlier text). > > > > > > > > > Great idea to define reordering more precisely. In this document, > > > > reordering refers to when two TCP segments are delivered at the TCP > > > > receiver in a different order from they were sent at the TCP sender > for a > > > > given TCP flow. Notice the ordering is chronological instead of > > > sequential > > > > on TCP sequences. > > > > > > > > We'll add that definition on the first appearance of the word > > > 'reordering' > > > > to clarify. > > > > > > I am quite confident that you know how this works, though I am not sure > > > that I understand properly yet -- is the key distinction that > "reordering > > > has been observed" and "segments have been delivered out of order" > refer to > > > time vs TCP sequence number? (There's not actually a need to respond; > I am > > > sure the document will be correct. I am just curious, is all.) > > > > > > > Benjamin, I think I did not previously understand your earlier remark: 'I > > assume there's some subtle technical difference between "reordering" > > and "segments delivered out of order" that makes this a reasonable thing > to > > say... ' > > > > But now I think perhaps I understand what you were getting at: were you > > remarking that there is an apparent contradiction in the text between "no > > reordering has been observed on the connection so far" and "three > segments > > have been delivered out of order", so that it seems impossible for the > > connection to meet the conditions for both "no reordering has been > observed > > on the connection so far" and "(a) three segments have been delivered out > > of order since the last recovery"? > > Exactly so! Sorry for not having been more clear originally. > > > I agree that the text of the draft as currently written seems > contradictory > > or at least unclear. :-) > > Well, I guess I can feel better about having been confused by it, now :) > Great. Thanks for raising this issue! > > The "three segments have been delivered out of order" phrase in the draft > > was meant to refer to three segments being SACKed. But now that you raise > > this point, it seems to me it would be more correct and clear to say > > something like "three segments have been SACKed", rather than "three > > segments have been delivered out of order". > > > > From my perspective, the SACKed segments are not necessarily "delivered > out > > of order", they merely have at least one hole in the sequence space. For > > example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out of > > order", and were they TCP segments we would not say that reordering has > > been observed; it's just that 2 is not (yet?) present. > > Indeed, there is some subjectivity in the definition of "out of order". > (My initial draft comments on this document had included a request for more > clarity on how to tell which segments are "out of order" as compared to > some baseline, but I deleted it once I got to, IIRC, discussion in Section > 6.2 about segments below RACK.fack getting acknowledged as being ones > delivered out of order, which I took to be effectively a definition, and > seemed well-formed at the time. Though perhaps that formulation is not > well-defined for what it means for a retransmitted segment to be > out-of-order...) If we apply the definition of "a segment is delivered out > of order if, when it is ACKd, RACK.fack is greater than its sequence > number" to your example above, it seems like we would conclude that 2 is > out > of order, but 3, 4, and 5 are in-order. (Right?) > Right, exactly. If there are no retransmissions and the sequence of packet deliveries is [1, 3, 4, 5, 2] then my intuition and RACK_detect_reordering() would not conclude that 3, 4, 5 are "reordering", but upon seeing that 2 is delivered both my intuition an RACK_detect_reordering() would declare that reordering has been seen. > > I also like the "three segments have been SACKed" phrase since the "have > > been SACKed" phrase is used in RFC6675 for a similar purpose in the > > description of "IsLost (SeqNum):" > > Also a pretty compelling argument. > > > If it's not too late for edits, I would propose that the section you > > mentioned ("3.3.2 > > . > > Reordering window adaptation") that says: > > > > 1. The reordering window SHOULD be set to zero if no reordering has > > been observed on the connection so far, and either (a) three > > segments *have been delivered out of order* since the last > recovery > > or (b) the sender is already in fast or RTO recovery. > > > > > > would be edited to: > > > > > > 1. The reordering window SHOULD be set to zero if no reordering has > > been observed on the connection so far, and either (a) three > > segments *have been SACKed* since the last recovery > > or (b) the sender is already in fast or RTO recovery. > > > > > > Benjamin, does that help address what you were talking about? > > Yes. From my point of view, that proposal is a big improvement. Great. Glad to hear it. We will talk it over among the draft co-authors and see if we can make this more clear. Thanks! neal --000000000000e5650205b7aedc5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 30, 2020 at 12:42 AM Benj= amin Kaduk <kaduk@mit.edu> wrote= :
Hi Neal,

On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote:
> On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > > > Section 3.3.2
> > > >
> > > >=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be s= et to zero if no reordering has
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connect= ion so far, and either (a) three
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments have been delivered= out of order since the last
> > recovery
> > > >
> > > > I assume there's some subtle technical difference b= etween "reordering"
> > > > and "segments delivered out of order" that ma= kes this a reasonable
> > thing
> > > > to say ... but it would be nice if the distincion was m= ade more clear
> > > > (whether here or in earlier text).
> > > >
> > > Great idea to define reordering more precisely. In this docu= ment,
> > > reordering refers to when two TCP segments are delivered at = the TCP
> > > receiver in a different order from they were sent at the TCP= sender for a
> > > given TCP flow. Notice the ordering is chronological instead= of
> > sequential
> > > on TCP sequences.
> > >
> > > We'll add that definition on the first appearance of the= word
> > 'reordering'
> > > to clarify.
> >
> > I am quite confident that you know how this works, though I am no= t sure
> > that I understand properly yet -- is the key distinction that &qu= ot;reordering
> > has been observed" and "segments have been delivered ou= t of order" refer to
> > time vs TCP sequence number?=C2=A0 (There's not actually a ne= ed to respond; I am
> > sure the document will be correct.=C2=A0 I am just curious, is al= l.)
> >
>
> Benjamin, I think I did not previously understand your earlier remark:= 'I
> assume there's some subtle technical difference between "reor= dering"
> and "segments delivered out of order" that makes this a reas= onable thing to
> say... '
>
> But now I think perhaps I understand what you were getting at: were yo= u
> remarking that there is an apparent contradiction in the text between = "no
> reordering has been observed on the connection so far" and "= three segments
> have been delivered out of order", so that it seems impossible fo= r the
> connection to meet the conditions for both "no reordering has bee= n observed
> on the connection so far" and "(a) three segments have been = delivered out
> of order since the last recovery"?

Exactly so!=C2=A0 Sorry for not having been more clear originally.

> I agree that the text of the draft as currently written seems contradi= ctory
> or at least unclear. :-)

Well, I guess I can feel better about having been confused by it, now :)

Great. Thanks for raising this issue!
=C2=A0
> The "three segments have been delivered out of order" phrase= in the draft
> was meant to refer to three segments being SACKed. But now that you ra= ise
> this point, it seems to me it would be more correct and clear to say > something like "three segments have been SACKed", rather tha= n "three
> segments have been delivered out of order".
>
> From my perspective, the SACKed segments are not necessarily "del= ivered out
> of order", they merely have at least one hole in the sequence spa= ce. For
> example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out= of
> order", and were they TCP segments we would not say that reorderi= ng has
> been observed; it's just that 2 is not (yet?) present.

Indeed, there is some subjectivity in the definition of "out of order&= quot;.
(My initial draft comments on this document had included a request for more=
clarity on how to tell which segments are "out of order" as compa= red to
some baseline, but I deleted it once I got to, IIRC, discussion in Section<= br> 6.2 about segments below RACK.fack getting acknowledged as being ones
delivered out of order, which I took to be effectively a definition, and seemed well-formed at the time.=C2=A0 Though perhaps that formulation is no= t
well-defined for what it means for a retransmitted segment to be
out-of-order...)=C2=A0 If we apply the definition of "a segment is del= ivered out
of order if, when it is ACKd, RACK.fack is greater than its sequence
number" to your example above, it seems like we would conclude that 2 = is out
of order, but 3, 4, and 5 are in-order.=C2=A0 (Right?)

Right, exactly. If there are no retransmissions and the seq= uence of packet deliveries is [1, 3, 4, 5, 2] then my intuition and RACK_detect_reordering() woul= d not conclude that=C2=A03, 4, 5 are "reordering", but upo= n seeing that 2 is delivered both my intuition an=C2=A0=C2=A0RACK_detect_re= ordering() would declare that reordering has been seen.

=C2=A0
> I also like the "three segments have been SACKed" phrase sin= ce the "have
> been SACKed" phrase is used in RFC6675 for a similar purpose in t= he
> description of "IsLost (SeqNum):"

Also a pretty compelling argument.

> If it's not too late for edits, I would propose that the section y= ou
> mentioned ("3.3.2
> <https://tools.ietf.org/htm= l/draft-ietf-tcpm-rack-15#section-3.3.2>.
> Reordering window adaptation") that says:
>
>=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be set to zero if n= o reordering has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connection so far, and= either (a) three
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments *have been delivered out of order*= since the last recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 or (b) the sender is already in fast or RTO= recovery.
>
>
> would be edited to:
>
>
>=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be set to zero if n= o reordering has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connection so far, and= either (a) three
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments *have been SACKed* since the last = recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 or (b) the sender is already in fast or RTO= recovery.
>
>
> Benjamin, does that help address what you were talking about?

Yes.=C2=A0 From my point of view, that proposal is a big improvement.

Great. Glad to hear it. We will talk it over amo= ng the draft co-authors and see if we can make this more clear.
<= br>
Thanks!

neal

=C2=A0
--000000000000e5650205b7aedc5b-- From nobody Wed Dec 30 09:47:20 2020 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 85EBD3A0AE6; Wed, 30 Dec 2020 09:47:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Michael Scharf via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Michael Scharf , iesg-secretary@ietf.org, michael.scharf@hs-esslingen.de, tcpm-chairs@ietf.org, tcpm@ietf.org Message-ID: <160935043853.8633.13073552668502860714@ietfa.amsl.com> Date: Wed, 30 Dec 2020 09:47:18 -0800 Archived-At: Subject: [tcpm] Publication has been requested for draft-ietf-tcpm-2140bis-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:47:19 -0000 Michael Scharf has requested publication of draft-ietf-tcpm-2140bis-07 as Informational on behalf of the TCPM working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tcpm-2140bis/ From nobody Wed Dec 30 09:50:07 2020 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 F0B143A0AF9 for ; Wed, 30 Dec 2020 09:50:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160935060596.4136.8484389560609897932@ietfa.amsl.com> Date: Wed, 30 Dec 2020 09:50:05 -0800 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:50:06 -0000 Changed milestone "Submit document on TCP Control Block Interdependence to the IESG for publication as Informational RFC", resolved as "Done", added draft-ietf-tcpm-2140bis to milestone. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Thu Dec 31 08:01:05 2020 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 ECBAB3A0A22 for ; Wed, 30 Dec 2020 09:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 B9WWooaMrh05 for ; Wed, 30 Dec 2020 09:12:16 -0800 (PST) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 1A86F3A0A1E for ; Wed, 30 Dec 2020 09:12:15 -0800 (PST) Received: by mail-wr1-x435.google.com with SMTP id w5so17970358wrm.11 for ; Wed, 30 Dec 2020 09:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qknqvin5xKaRi20p1qB7A5X2BwkoMj7pGkhWNzL9cIU=; b=GaOMMVqPym6Ik/SnE/Bmh5Pw/7CzHjSQyewTdXh5rspmy4kMjCqPhhmTLBJJ+5yTWC bpWlB8on8Zj98ao93uPZrl6+FGkrPp5Gz8GAnCbibZcnOKtEgARpHNfndLXo995pUnsw 1pHVdqQc/naPFBBccDymqejyHXJVIwtbC9otcRRKcsi0k49YECUW3VkLoRDeYW1Z8mhA IaaISV0UZmYyXSZrG1UJKLWiJEyuMnPmbz2Zo4kB/lWYvavAALHLHsNgEiA8knOQIuyS 6hR5wXdvH8YqqkTMSwILcK2JPOKj+jpsa5aSjm8QPwx939XKfVZlEzM72HsLcebJLr8J bDew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qknqvin5xKaRi20p1qB7A5X2BwkoMj7pGkhWNzL9cIU=; b=azcbYRGpXs3kraC6fJH4Mh1uqrLUq0JLjERBlgdQ2oBwtyHNamIhfitjCj1dEp5sim FitCncIIKkPSVTK2CZBT1gtlOP/5vh4MvcAe4fXHm/ZmD29qPi1+OqP15+bjVJc3LeVo fYK7GN8UKlC4hAi7680GkUe6XN+zEBhe417sXthjYqliVDldLdXaimSS0RPkuyxEsvzi D9J5fPivIkAsH/BVBmaAtCToFWkRmLOTY/sixoVORW4+Z1BomCtey8pqSFliWKeT9B+M Xt82GiEmUQ9EZUJFVKdjS3jMEoNbiWdO1N+Ez+y/t2Ay3f11cYAZC7HSNzrdb/jqgka1 9OqA== X-Gm-Message-State: AOAM531ju0jJOizcAEPYVvfthFAjtq5HC5gYYqUMPlzq8Rg8kY1++9Ku JVv+uOHkPgbJ6faEh8LL9LlyhUBb10fzkkLI+W82Eg== X-Google-Smtp-Source: ABdhPJw+eGYcVlpZ9/7I+ljIkUfrQ8lNTtXc12I97yvizDogGLQvanYwfHU8wqyT7XcOJRa2sYhRJCfDvlLWff5eLVY= X-Received: by 2002:adf:dc8b:: with SMTP id r11mr62218371wrj.131.1609348332620; Wed, 30 Dec 2020 09:12:12 -0800 (PST) MIME-Version: 1.0 References: <160822770059.15041.16286115220871304513@ietfa.amsl.com> <20201229200656.GG89068@kduck.mit.edu> <20201230054144.GU89068@kduck.mit.edu> In-Reply-To: From: Yuchung Cheng Date: Wed, 30 Dec 2020 09:11:35 -0800 Message-ID: To: Neal Cardwell Cc: Benjamin Kaduk , The IESG , draft-ietf-tcpm-rack@ietf.org, tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rack.all@ietf.org, Michael Tuexen Content-Type: multipart/mixed; boundary="000000000000b0483805b7b19b35" Archived-At: X-Mailman-Approved-At: Thu, 31 Dec 2020 08:01:04 -0800 Subject: Re: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rack-14: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 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 Dec 2020 17:12:20 -0000 --000000000000b0483805b7b19b35 Content-Type: multipart/alternative; boundary="000000000000b0483605b7b19b33" --000000000000b0483605b7b19b33 Content-Type: text/plain; charset="UTF-8" Thank you Ben for your review. Here is the latest proposed diff. Let us know what you think and we'll work w/ RFC editors to incorporate this minor change. On Wed, Dec 30, 2020 at 5:55 AM Neal Cardwell wrote: > > > On Wed, Dec 30, 2020 at 12:42 AM Benjamin Kaduk wrote: > >> Hi Neal, >> >> On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote: >> > On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk wrote: >> > >> > > > > Section 3.3.2 >> > > > > >> > > > > 1. The reordering window SHOULD be set to zero if no >> reordering has >> > > > > been observed on the connection so far, and either (a) >> three >> > > > > segments have been delivered out of order since the last >> > > recovery >> > > > > >> > > > > I assume there's some subtle technical difference between >> "reordering" >> > > > > and "segments delivered out of order" that makes this a reasonable >> > > thing >> > > > > to say ... but it would be nice if the distincion was made more >> clear >> > > > > (whether here or in earlier text). >> > > > > >> > > > Great idea to define reordering more precisely. In this document, >> > > > reordering refers to when two TCP segments are delivered at the TCP >> > > > receiver in a different order from they were sent at the TCP sender >> for a >> > > > given TCP flow. Notice the ordering is chronological instead of >> > > sequential >> > > > on TCP sequences. >> > > > >> > > > We'll add that definition on the first appearance of the word >> > > 'reordering' >> > > > to clarify. >> > > >> > > I am quite confident that you know how this works, though I am not >> sure >> > > that I understand properly yet -- is the key distinction that >> "reordering >> > > has been observed" and "segments have been delivered out of order" >> refer to >> > > time vs TCP sequence number? (There's not actually a need to >> respond; I am >> > > sure the document will be correct. I am just curious, is all.) >> > > >> > >> > Benjamin, I think I did not previously understand your earlier remark: >> 'I >> > assume there's some subtle technical difference between "reordering" >> > and "segments delivered out of order" that makes this a reasonable >> thing to >> > say... ' >> > >> > But now I think perhaps I understand what you were getting at: were you >> > remarking that there is an apparent contradiction in the text between >> "no >> > reordering has been observed on the connection so far" and "three >> segments >> > have been delivered out of order", so that it seems impossible for the >> > connection to meet the conditions for both "no reordering has been >> observed >> > on the connection so far" and "(a) three segments have been delivered >> out >> > of order since the last recovery"? >> >> Exactly so! Sorry for not having been more clear originally. >> >> > I agree that the text of the draft as currently written seems >> contradictory >> > or at least unclear. :-) >> >> Well, I guess I can feel better about having been confused by it, now :) >> > > Great. Thanks for raising this issue! > > >> > The "three segments have been delivered out of order" phrase in the >> draft >> > was meant to refer to three segments being SACKed. But now that you >> raise >> > this point, it seems to me it would be more correct and clear to say >> > something like "three segments have been SACKed", rather than "three >> > segments have been delivered out of order". >> > >> > From my perspective, the SACKed segments are not necessarily "delivered >> out >> > of order", they merely have at least one hole in the sequence space. For >> > example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out of >> > order", and were they TCP segments we would not say that reordering has >> > been observed; it's just that 2 is not (yet?) present. >> >> Indeed, there is some subjectivity in the definition of "out of order". >> (My initial draft comments on this document had included a request for >> more >> clarity on how to tell which segments are "out of order" as compared to >> some baseline, but I deleted it once I got to, IIRC, discussion in Section >> 6.2 about segments below RACK.fack getting acknowledged as being ones >> delivered out of order, which I took to be effectively a definition, and >> seemed well-formed at the time. Though perhaps that formulation is not >> well-defined for what it means for a retransmitted segment to be >> out-of-order...) If we apply the definition of "a segment is delivered >> out >> of order if, when it is ACKd, RACK.fack is greater than its sequence >> number" to your example above, it seems like we would conclude that 2 is >> out >> of order, but 3, 4, and 5 are in-order. (Right?) >> > > Right, exactly. If there are no retransmissions and the sequence of packet > deliveries is [1, 3, 4, 5, 2] then my intuition and > RACK_detect_reordering() would not conclude that 3, 4, 5 are > "reordering", but upon seeing that 2 is delivered both my intuition > an RACK_detect_reordering() would declare that reordering has been seen. > > > >> > I also like the "three segments have been SACKed" phrase since the "have >> > been SACKed" phrase is used in RFC6675 for a similar purpose in the >> > description of "IsLost (SeqNum):" >> >> Also a pretty compelling argument. >> >> > If it's not too late for edits, I would propose that the section you >> > mentioned ("3.3.2 >> > . >> > Reordering window adaptation") that says: >> > >> > 1. The reordering window SHOULD be set to zero if no reordering has >> > been observed on the connection so far, and either (a) three >> > segments *have been delivered out of order* since the last >> recovery >> > or (b) the sender is already in fast or RTO recovery. >> > >> > >> > would be edited to: >> > >> > >> > 1. The reordering window SHOULD be set to zero if no reordering has >> > been observed on the connection so far, and either (a) three >> > segments *have been SACKed* since the last recovery >> > or (b) the sender is already in fast or RTO recovery. >> > >> > >> > Benjamin, does that help address what you were talking about? >> >> Yes. From my point of view, that proposal is a big improvement. > > > Great. Glad to hear it. We will talk it over among the draft co-authors > and see if we can make this more clear. > > Thanks! > > neal > > > --000000000000b0483605b7b19b33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you Ben for your review. Here is the latest proposed= diff. Let us know what you think and we'll work w/ RFC editors to inco= rporate this minor change.

On Wed, Dec 30, 2020 at 5:55 AM Neal Cardwell <= ;ncardwell@google.com> wrote= :


On Wed, Dec 30, 2020 at 12:42 AM Benjamin Kaduk <= ;kaduk@mit.edu> w= rote:
Hi Neal,
On Tue, Dec 29, 2020 at 11:04:41PM -0500, Neal Cardwell wrote:
> On Tue, Dec 29, 2020 at 3:07 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > > > Section 3.3.2
> > > >
> > > >=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be s= et to zero if no reordering has
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connect= ion so far, and either (a) three
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments have been delivered= out of order since the last
> > recovery
> > > >
> > > > I assume there's some subtle technical difference b= etween "reordering"
> > > > and "segments delivered out of order" that ma= kes this a reasonable
> > thing
> > > > to say ... but it would be nice if the distincion was m= ade more clear
> > > > (whether here or in earlier text).
> > > >
> > > Great idea to define reordering more precisely. In this docu= ment,
> > > reordering refers to when two TCP segments are delivered at = the TCP
> > > receiver in a different order from they were sent at the TCP= sender for a
> > > given TCP flow. Notice the ordering is chronological instead= of
> > sequential
> > > on TCP sequences.
> > >
> > > We'll add that definition on the first appearance of the= word
> > 'reordering'
> > > to clarify.
> >
> > I am quite confident that you know how this works, though I am no= t sure
> > that I understand properly yet -- is the key distinction that &qu= ot;reordering
> > has been observed" and "segments have been delivered ou= t of order" refer to
> > time vs TCP sequence number?=C2=A0 (There's not actually a ne= ed to respond; I am
> > sure the document will be correct.=C2=A0 I am just curious, is al= l.)
> >
>
> Benjamin, I think I did not previously understand your earlier remark:= 'I
> assume there's some subtle technical difference between "reor= dering"
> and "segments delivered out of order" that makes this a reas= onable thing to
> say... '
>
> But now I think perhaps I understand what you were getting at: were yo= u
> remarking that there is an apparent contradiction in the text between = "no
> reordering has been observed on the connection so far" and "= three segments
> have been delivered out of order", so that it seems impossible fo= r the
> connection to meet the conditions for both "no reordering has bee= n observed
> on the connection so far" and "(a) three segments have been = delivered out
> of order since the last recovery"?

Exactly so!=C2=A0 Sorry for not having been more clear originally.

> I agree that the text of the draft as currently written seems contradi= ctory
> or at least unclear. :-)

Well, I guess I can feel better about having been confused by it, now :)

Great. Thanks for raising this issue!
=C2=A0
> The "three segments have been delivered out of order" phrase= in the draft
> was meant to refer to three segments being SACKed. But now that you ra= ise
> this point, it seems to me it would be more correct and clear to say > something like "three segments have been SACKed", rather tha= n "three
> segments have been delivered out of order".
>
> From my perspective, the SACKed segments are not necessarily "del= ivered out
> of order", they merely have at least one hole in the sequence spa= ce. For
> example, in the sequence [1, 3, 4, 5], the [3, 4, 5] are not "out= of
> order", and were they TCP segments we would not say that reorderi= ng has
> been observed; it's just that 2 is not (yet?) present.

Indeed, there is some subjectivity in the definition of "out of order&= quot;.
(My initial draft comments on this document had included a request for more=
clarity on how to tell which segments are "out of order" as compa= red to
some baseline, but I deleted it once I got to, IIRC, discussion in Section<= br> 6.2 about segments below RACK.fack getting acknowledged as being ones
delivered out of order, which I took to be effectively a definition, and seemed well-formed at the time.=C2=A0 Though perhaps that formulation is no= t
well-defined for what it means for a retransmitted segment to be
out-of-order...)=C2=A0 If we apply the definition of "a segment is del= ivered out
of order if, when it is ACKd, RACK.fack is greater than its sequence
number" to your example above, it seems like we would conclude that 2 = is out
of order, but 3, 4, and 5 are in-order.=C2=A0 (Right?)

Right, exactly. If there are no retransmissions and the seq= uence of packet deliveries is [1, 3, 4, 5, 2] then my intuition and RACK_detect_reordering() woul= d not conclude that=C2=A03, 4, 5 are "reordering", but upo= n seeing that 2 is delivered both my intuition an=C2=A0=C2=A0RACK_detect_re= ordering() would declare that reordering has been seen.

=C2=A0
> I also like the "three segments have been SACKed" phrase sin= ce the "have
> been SACKed" phrase is used in RFC6675 for a similar purpose in t= he
> description of "IsLost (SeqNum):"

Also a pretty compelling argument.

> If it's not too late for edits, I would propose that the section y= ou
> mentioned ("3.3.2
> <https://tools.ietf.org/htm= l/draft-ietf-tcpm-rack-15#section-3.3.2>.
> Reordering window adaptation") that says:
>
>=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be set to zero if n= o reordering has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connection so far, and= either (a) three
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments *have been delivered out of order*= since the last recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 or (b) the sender is already in fast or RTO= recovery.
>
>
> would be edited to:
>
>
>=C2=A0 =C2=A0 1.=C2=A0 The reordering window SHOULD be set to zero if n= o reordering has
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 been observed on the connection so far, and= either (a) three
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 segments *have been SACKed* since the last = recovery
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 or (b) the sender is already in fast or RTO= recovery.
>
>
> Benjamin, does that help address what you were talking about?

Yes.=C2=A0 From my point of view, that proposal is a big improvement.

Great. Glad to hear it. We will talk it over amo= ng the draft co-authors and see if we can make this more clear.
<= br>
Thanks!

neal

=C2=A0
--000000000000b0483605b7b19b33-- --000000000000b0483805b7b19b35 Content-Type: application/pdf; name="Diff_ draft-ietf-tcpm-rack-15.txt - rack-ietf-draft.txt.pdf" Content-Disposition: attachment; filename="Diff_ draft-ietf-tcpm-rack-15.txt - rack-ietf-draft.txt.pdf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kjbobzlg0 JVBERi0xLjQKJdPr6eEKMSAwIG9iago8PC9DcmVhdG9yIChNb3ppbGxhLzUuMCBcKE1hY2ludG9z aDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfN1wpIEFwcGxlV2ViS2l0LzUzNy4zNiBcKEtIVE1MLCBs aWtlIEdlY2tvXCkgQ2hyb21lLzg3LjAuNDI4MC44OCBTYWZhcmkvNTM3LjM2KQovUHJvZHVjZXIg KFNraWEvUERGIG04NykKL0NyZWF0aW9uRGF0ZSAoRDoyMDIwMTIzMDE3MDYwOSswMCcwMCcpCi9N b2REYXRlIChEOjIwMjAxMjMwMTcwNjA5KzAwJzAwJyk+PgplbmRvYmoKMyAwIG9iago8PC9jYSAx Ci9CTSAvTm9ybWFsPj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xp bmsKL0YgNAovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzExMy41NzQ5ODkgNzU0LjU0OTk5IDExNy43 NzQ5ODYgNzYyLjQyNDk5XQovQSA8PC9UeXBlIC9BY3Rpb24KL1MgL1VSSQovVVJJIChodHRwczov L3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRjcG0tcmFjay0xNS50eHQp Pj4KL1N0cnVjdFBhcmVudCAxMDAwMDA+PgplbmRvYmoKMTAgMCBvYmoKPDwvVHlwZSAvQW5ub3QK L1N1YnR5cGUgL0xpbmsKL0YgNAovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzExOS4zNDk5OTEgNzU0 LjU0OTk5IDIwMS43NzQ5OCA3NjIuNDI0OTldCi9BIDw8L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9V UkkgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRjcG0tcmFjay0xNS50 eHQpPj4KL1N0cnVjdFBhcmVudCAxMDAwMDE+PgplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZSAvQW5u b3QKL1N1YnR5cGUgL0xpbmsKL0YgNAovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzE2My40NDk5ODIg NjIzLjgyNTAxIDIwOC41OTk5OSA2MzEuNzAwMDFdCi9EZXN0IC9wYXJ0LTIKL1N0cnVjdFBhcmVu dCAxMDAwMDI+PgplbmRvYmoKMTIgMCBvYmoKPDwvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsK L0YgNAovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzQyMS4yMjQ5NSA2MjMuODI1MDEgNDY2LjM3NDkx IDYzMS43MDAwMV0KL0Rlc3QgL3BhcnQtMgovU3RydWN0UGFyZW50IDEwMDAwMz4+CmVuZG9iagox MyAwIG9iago8PC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovRiA0Ci9Cb3JkZXIgWzAgMCAw XQovUmVjdCBbMTYzLjQ0OTk4MiA0NjUuODAwMDUgMjA4LjU5OTk5IDQ3My42NzUwNV0KL0Rlc3Qg L3BhcnQtMwovU3RydWN0UGFyZW50IDEwMDAwND4+CmVuZG9iagoxNCAwIG9iago8PC9UeXBlIC9B bm5vdAovU3VidHlwZSAvTGluawovRiA0Ci9Cb3JkZXIgWzAgMCAwXQovUmVjdCBbNDIxLjIyNDk1 IDQ2NS44MDAwNSA0NjYuMzc0OTEgNDczLjY3NTA1XQovRGVzdCAvcGFydC0zCi9TdHJ1Y3RQYXJl bnQgMTAwMDA1Pj4KZW5kb2JqCjE1IDAgb2JqCjw8L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5r Ci9GIDQKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFsxNjMuNDQ5OTgyIDk2LjIwMDA3MyAyMDguNTk5 OTkgMTA0LjA3NTA3M10KL0Rlc3QgL3BhcnQtNAovU3RydWN0UGFyZW50IDEwMDAwNj4+CmVuZG9i agoxNiAwIG9iago8PC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovRiA0Ci9Cb3JkZXIgWzAg MCAwXQovUmVjdCBbNDIxLjIyNDk1IDk2LjIwMDA3MyA0NjYuMzc0OTEgMTA0LjA3NTA3M10KL0Rl c3QgL3BhcnQtNAovU3RydWN0UGFyZW50IDEwMDAwNz4+CmVuZG9iagoxNyAwIG9iago8PC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggMTMwMDI+PiBzdHJlYW0KeJztfduO7Day5Xt9RT4PMNni RaIENBrY3rYb83CAOQ0D8wEz3T4YdB/geP4fGEmZlanbkri4mapU5rKx7V1FBRmkqFjBuPFsXdP/ cyraf//7efBjaOzpf//r478+uhZblubkXGFOf/z943/9t9N/tr/3Z1N1/5Q97finltCcun//9tfT 5S9//P7xp7+60+//r++vNtXJFGXVdfeP/jdF9+jlL+2jP/328adf/ak+/faPtqOeN3Oy1dmXztjy ZO3pt399/LkojG//lO0f2/6p2j/u+vfy+vf+/385/fZ/P375DfRahrOztXH3Xm0oCv+9/dP0lKY4 l9Z5F7q5/fZ/Tn/uWtp+fy6Koh3Dt0+X7TjeX35ftj+b4tpDffm5f764/r3ls2zpWpLL7z5p29/7 Xy6/6+fV0hpzoSl/uvy/G69r7/6/RLc05iJ/o37X1+e26qFdgMsC+Ss7/Z+OleqyHP3S2+vv7eWP //XabhbYM9fnyp6Fsj43VT1c5m8r/dnrtJrrEoxfmjfnytZNUY3f2TqRtefSmGCaMZG5zvL758xX F6wM5XmyXsZvUDQzCrtOUZvz9KWY6pPk39t//+vDmOrcf5Htp3b/q3WmPgff1CdXVNW5Dr4efNP2 bNrfNG1r/9Xfflrua+srN0XVdlJfRui4P1c+mMunfv+hpXEnd/InU16eC91P9f1n37Sy5xQGP9eT J5rajno4l4U93f/TDjf5TT+mLe1o1P7nybjd78YjT5/qxh735E5lOZ5P//Ok5+53456nT3U9j3ty p/aVh1HXl19M+u5/Oe589lzX+6S3+ctsB6y7B9x1XRvn3Gn4325pZ79sCUNPWN9J5333XI0f6nka DthuDJM4fke4Of7koX4fmdH43ieO3xFujj95qBt/NGC7lULi+J+ve3X8yUP9jguj8UMxHD903bef bvgce/SLftyOYDJuK6ouj99/uI6/8PCYyY6jEQvuVLvEFaldxIpMHurGHw3oTk1FrkhHEL0iCw/P V2TEQjta0aR+pB3l9lc6ear/TEdjdoLJpvJgbQwPk6cu4suOeXBlKg8d5TYPk6d6HkZjtjz4ZIHp oySmXxCZfiwzTZUqNHvKbR6qudgcj9nyEFIFZ0+5zUOYi87xmB12pQrPnjICvebiczxmq2QURSIP PeUmD9OnenWkGEtMa1JFZk+5zYOZC83xmN3hqkrlwW6JxJ6HyVM9D3YsJ9vTbSoPLkZOTp/qeXBj OWmr1D3ZU27zUM335HjMloc6eU/WUXuyXtiT9WRPNsl7sonak83CnmzGe7I9AaUql0XMnpw+1auX xXhPOpO6J3vKCA13vifHY7Y8uFTs7im3eXBz7B6P2fLgU7G7p9zmwc+xezxmy0OZit095TYP5Ry7 x2O2PITkA0+IOvGEhSNPGGO3q1Oxu6fc5qGeY/d4zJaHZiQnI9TsniJaz156eq5oj7lopYdJlZw9 5fZ50Mwl53jMlgebKjl7ym0e7Fxyjsds/+5SJWdPuc2Dm0vO8ZjdyTxVcvaUEWfzueQcj9nyUKVK zp5ym4dqLjnHY7Y8hFTJ2VNu8xDmknM8ZrdfUiVnT7nNQz2XnOMx3aksUiVnT7ltKynmknM8ZsuD SZWcPeU2D2YuOcdjtjzYZJORjbIZ2QWjkR3LydKnysmecpsHP5eT4zFbHqrUPdlTbvNQzffkeEzX 2elTeaij9mS9sCfryZ5skvdkE7Unm4U92Yz3ZFWk7smecpOH6VMdD+MxWx5s6p7sKbd5sPM9OR6z 5cGlYndPuc2Dm2P3eMyWB5+K3T3lNg9+jt3jMVseylTs7im3eSjn2D0es+UhpGJ3T7nNQ5hj93jM loc6Fbt7ym0e6jl2j8dseWhGcjJC0+4pojXtpafnmvaYC3cKJlVy9pSbKzN9qnc0mLHkDDZVcvaU 2zzYueQcj9ny4NhzUE8R74FZeHrBBeMmXqEyVZb2lNsrU85l6XjMlocqVZb2lNs8VHNZOh6z5SGk ytKecpuHMJel4zFbHupUWdpTbvNQz2XpeEx3qgtL7tKeInqXLj0936VjLlquTMlyZeZSdYWrhacX uDJjeVtbVt72FPFcLTy9wJUdy9vaG5YrP5ezK1wtPL3AlR9L4Lr0LFflXPKucLXw9AJX5Vgm1xUr k+sF2/0KV5uW/p6riVW/rllXfb1gzV/hatP233M1sfPXYzt/DFcL9v0Vrja9AT1XE8t/k2z5b6Is /9Oneqf9xPLfjC3/MYEECxb/lUiCTf9Az9XEF9A4VpI3Cz6AFa42PQY9VxPvQONZSd4seAVWuNr0 IfRcTfwFTclK8mbBT7DC1aZXoedq4kFoAivJmwXPwQpXm36GnquJT6GpWUneLPgSVrja9Dz0XE28 DA3tZWgoL8PS0wtcTbwMpjCsKL+QRPO1+PicsQkjHWeWFecXEoKzTSfFhbOJR8IUjo3LupAQnG26 Li6cuWl0lmcF/YWE4GzToXHhbOK9MEXFCvsLCcHZppvjwtnEp2GKwAr8CwnB2abz48LZxNNhipoV +hcSgrNNl8iFs4n/w5iCFfwXknjOlh5f4MxMvCLGJLtFLqSb+tbssQsfE8+IMcmukQtpBB8LzpHJ sB0fye6RC2kEHwsOksmwHR9lqgnlQhrBRzk3okyG7fioUtXxC2kEH9VcIZ8M2/ERkgNpe9IIPsJC KO142I6PJjmYtieN4KOZG6cnw3YxvUVyQG1Pus3H9LFLWG8xkbk2PQvBxuUhTB+78DHJRTA2ORvh QhrBx0JGwmTYjo/krIQLaQQfC5kJk2E7PpJdKBfSCD4WnCiTYTs+kt0oF9IIPhYcKZNhOz6a9H26 6SW58NEs7dOJ78S4ZOfJhXSbj+ljl1D4if/EuGQHyoU0go8FF8pk2I4Pl4z7btM/cuHDLeC+m3hN jEt2m1xII/hYcJxMhu34SHadXEgj+FhwnkyG7fhIdp9cSCP4WHCgTIbt+Eh2oVxII/hYcKJMhu1y R2g3yoUkXoNfenxBgx8z0uVy3vq8//DHJU/7f57+/Oc//dv3//Fz2/CXv/z08/ePP/1atrTnUHWZ ynaUuGraLWBuGau/XjJW/+17l7W6nAV+791E9B6Kc93nct/G+PZ9OEZKZuzpPz+sd+XZm6ocPv8v 0M8/h79v+3Tn0rfs/HPQy/JvR338x0dVhnPt637BinMZbGdA/tdH5cPZV649MA9+/c/Rr8tzCIVv D2H/HHUCfj3o5D+S84DxFrnmA5vgz7Z9uMtOagcN58KUlS1P5rLFdkxZ3mR1vO1szLa7ze2WIX/J EQ/nqrSVr+8J5ddU9+psivYrLtw909xfG+rQst8M89YvCe3nsm4VUlffuwqgwRSgwV8+Btd+JLap hon2NeAKjgG5goPjrio0uEOLeBnDmHbLWxNcGTE6v+6ILf8LYAsObtAYpkYN5vqmvGsbWn13cxXL n0BXn+UK4qSs297uzplzK2S7j3dZyo579Ns9VvXsA/r2HS3AV77IL/2AvlamZN+Qc4q1XVTedlEn z89dcZSinelwF/mmRf+ycV0C2nUXFQ73WG33WPX9dRZgc+3QheukQtEUjbkvg61Ag3OgoUANrgAN t9c5a/gOGkqDGtA8bhs5uivIFaZAawUHx2v1DQ1uUUOJBv8l2+p6xBWch4XzQOziCcI3SO/El2wI ZbPYYIrKq0END21w30GDMWxXQ8QZNfifUEMNGko0+FWQLeJnYBD5BqBriFzH9BimPQqSBcmC5EM3 CJLVIEj+cUhuiCNt6T+rne6BVFBkQnkNu0KDG4TRFlFg3IGo3rBcPY+QVcPLNgg/1UCCHoKXnKDn QcNQ7o4pAqL4higQfvpf1xsW8dMUzJn2hqBrZ1pjmEOtQFmgrIbXaBAoq0GgnAGULXGqrcKeAApx ku4KUkBZUyKLLZ4HtApDLIYzR4Obn9l5uIzz4N8H7ApqIXCt0DzwzDOqQNB8jyzoz4OTAlA1fB1O QnCDGPYL3YAMzCXiCoM0YtevhE4Zx5xqbwi6eqr1zKlWoCxQFigLlNXwwg0CZQ6UIwKab6fauvgE UCj7f0IN6KvGITRQ0O0APBZRXF/9dS27dJ5wOteX3LXBT3/8/lGb7saw4Ebpa6uJZRGR4HVxrvp8 pdur4I3kcNIGrbiBXf2abwyewq9s64ioQFP6zytFb6v5PACnBjWo4ciaoUMNCZrIz6ABB3StCceo AOfPg/hUNi53GRHydT+IS4+Y6hHlJaP+okbcfmhVhDJYUo2wEcEDZTBTPcIjKC/RwmKMh6fdJ1AX 4OCL+9pGhE1Uvuz1CCc1Qg1qeJEGqRFbaoRlHOKNk2hUgxpeoeFpRKMaDtJgUYjWMFUxrsHDaC8Y 1IWs9QWiwPOA1nqYJlWtACjlEJ8i6HKXlENcoKwGNbxGg0BZDQLlDKDMOMTbXoWgalDDKzQIQZ+3 AYZi4RwfmHkES10UiAKmJMGuEMX47LYWPuRddWqqLsI52vEXET/U9nq2zrt6AF3YY1auwGRM2S3f nCtfVG6Ik1/qAlw7OVNO8RnwL/dJecWlTKhBDS/SIGXieRteVJmAMURNC9acKuEiYojaXueqBIyc WkFJFxFj0/jiOKqEi3CMD1QJ00SoEi7CV3A3S7QcSJPI1gBzsTyKUkyoVoo2mkVha7CsrEVpXbAI Di5diz4xvnQtji+E1Uph8h+dTcfnXPIJnzDNDncFQ1aHSzLUJKBFE2IdzBbCllneLAwhDVpmIQKj QCSIp3jmTbZ5wDEcmgese+LWZHyU8/aGG1Mhv9xn1IUVAfX5ZJL4YA0CDgGHgEPA8XDgYO4QMr6U jFfDAxtwGYwdampCrIJCM0GUI67g4LgrKPzR6g4F2kjGGyTpsJiFMh7au1AdAzi4QWOYUQbcRKBR l7rMJNpyn9S1LpKSapCUlJR8aikZ5V6+Scky5jZKH2H5v6uS4fPyK3jY9Ggz8yXKMla+Gt9FO1mB qErpt1UNMTeK+SiPQJj1+UrLSiU7mDqmqL2PMJjdN2sT8iN6goUHnt3zGSegZQS/OSjdIVDQhQ/5 MvhYuuer6ZBxHvwbxIAnA+HqBIeIDg1S2F6DgBs2YGMRHUuATVh09MFWxTdmSWQgjJ/5MxsIF1RI s4Kg1H3mMwhd7jMmDvWu7AiWBcuCZcGyYFmwLFi+QmiE/ft2sLWmeACCvqJ4ioNWHpJ4gIG6A31J Hjam0vOAd5N/rbaRz3CFuYIKGG0n/8EJjhAUSlMYXA7RjccqWGYcGtCRpEuAbzg4TOlG84BjQK4S rg3bQ0VA6OZXPASeSmqbAclyn1RSm8BJ4CRwEjgJnAROEyApGVeztQ+oVZbxyiT89cIoZSTQYMAz f0EYFJpYNu4gTXlIKpDdDV4QllETKOgC6BkvIcNjQFMkHDyfHRTuXbjboZkw4Z4jZLWBcgtKU4MK ImMDEBrcInahZciiKCE4eIGMZQXiCrKbM9UZwd5aOEhJRdnMpP9yn1SUjRBFiCJEEaIIUV4EUZgK CdY9oNZSRglxMOG/iw0GWVR4aZrzemQYiJsPq2AgPS+YEwxAdEwHjmaBexdOMMriOBL+yESBTS0Q FaBAQ2PwCQE4SIKfB21ew+YcaMhCoQKYK96WRNsPYVYFrrUE3zlvd1uDJKqgwwyTlvukCjoI54Rz wjnhnHBOOPdAnIuK+L7hnI8peFfeQ+BC16evJpd3u3PdXd1tq89Mseucuku9m1DZar4rXXBlu3mn 78a1DLvG+3BfHgcoYAPuyiCKyx4rz8E2TVOG6R6z57ryTVPMhFo38XZ69UAYWLar6xdcnou2pa7q e8NPiF0PxuAneN1j88Exu3DwtV15D37pKludQ9XtSjvaRrYM58aauh7soysX7uxd09TBzl9+HdqG ZrY2Cw3fUMPnZ2aK4Fz7qUyWYD64QWNcy2DOKWBX/pOitrapQjnfxNOG6zsO56ps12mw8xLmEcA8 1qqNl82qMKi8lzCQMFgTBlWxLQyCryUMnl8YVDF3ct8MveEB6WUWxlfRpz0+pg57fOgKHTA8z8JD 3Q61SRIOjvSplc/X4h1UeHBkDcFxe/CdI65eMjtxdACm4/bw7WUoei3htAcv0ob3naEx+GvN+BQ2 7PiEJ2M6fw5PkHb/4Wvm+BM+POfSa5VsXlhGN6p4/AzelvuMqr0SUJ+CTEGmIFOQKcgUZD4lZDJl wGxT7FlvhPZcQUmHoRXCBS9m6bQsPsASagIWjYEz7tDMoavUIKGZ8M551zWt0eSsUAJ3Iu8q5SdI 102BWxTXG4FlLKDEhnUhoEDLl0WG3X/QZ0e7SvlaIDgVD61VQgkWKPzphDQeYKCrFL/zDRVhGZKo ulozTFruk6qrJZwTzgnnhHPCOeHcA3GOKVTVuQSzQ5KMTHOKY6XiZUwvk5U5fnV/0Mo8ulOBrlKI s+F2MBPiUhn5JPYeJlVcwIM3XvK3UtMm1Zc3216/2mWgpCpxzZByuU+qEpfQV+gr9BX6Cn2Fvu+G voEpNebMI3Imn0Z0xKFCxusQ8hnkoHkNzxw20DmTw8oe4wakIsAGnHhKrxVPkfG+L6yy8ZVCIXz/ 2IWEI8spkvEQQRMq4CPrrIHIwxv9oLkTVsDn69hAdo8Fe3Aea+X3A1WcbIYXy31SxcmEQcIgYZAw SBj0thhE3ZfqbExOfWACJZ23SgM4sInoB4ExXxrAl150LovvDIJwsXb+6jAYfkCbofa4vQtOMGf0 CrSU0oVgMJrRd6PlTOTgy+zAIqP0svMX5SXcPFetICgV1zmD0OU+qbhOwbJgWbAsWBYsC5YFy58Q SoWhluWOFz9kLNCP5RYcnL9oIGP6N5SmtPBPsEnSRV8LVD8WT5C/7hzOHBav5Q2ie8ycju7iu4I7 EQbCYGlK342WcBs4D63QJsnXRIXyN19ATwKuQ4tvRsMuf9sgDUk5rwjkdwl92+B1+ywDJReGOkXK 5T65MFShr9BX6Cv0FfoKfd8MfWsqDLWqH5CvASU2tADTxrKMuefYLs0bFjNGE/EJKRBB4YuiYQ+j Ao+gMN4lnybAb9G4mwDjdKB89R/iXCcjoHzm8Pl5g4WC+StjgxIkNl+6gL/qcOMe9Bxj4He+cafH MiRxoa5TTFrukwt1Fc4J54RzwjnhnHDucTjH3A7sWlTMD0m8/TBfjA0v6aBNbBezVD7ZiC11NObu Ur6MDlpJeB97ly/7wcFp4z6MsckoNOEF6SWsz8YnctD3ufOFlTEq0HCBDYt0yTqMCtBGCbNI4MxX 7hiqqZt7Z3ix3Cd1c68wSBgkDBIGCYPeFoOoW3Vd42MwiAmU9MUDLgLCJaTht5fPoqU8BwJ88wX1 wypxWCWAERm0SoBXF2by8wbRjHE7EDFpc7MdVgsYWeZGhpJzVVXhdK5P5vS3v54GP/3x+4ftrCFN ODl/Mu70x98//vFR9HKiffLyl/ahiYiJCDFruz1bU49kDP95wIkbmOG/ZiGKCGNzRX0eC0Z6O2Le eAr06a7llTcRMQh3VJlBwHKfUU6kgPoUrAhWBCsvByulc65FkQuq3H5o8SJUVQ8qNkSDShPhUm67 nYEKfK98bK5ZyT9qIrwLoXHnwld1fWz4oAxj3hYx8BFhGLsfStxnGWMLEz95DzH/BUIRA4USXTgK g13GK1ngPDZcx8tvkjqy3l/l6u6IOLIOlAttjyfeHlT2ifcxdfWaCLX9LjzK5gHFE952o8G7r+Du gBdW7QJ4+eKyct7hRR9p8FGAjgNKiC/bI9Uq6jA3MqrTZcihaTkhOom+TApnD/BxQHSth4y5GXhw GCAEKTKm9mQMjUrN4FnEKlNwxpcpWoFOOeuLIFAQKAgUBAoCBYFfAYERlrz7eS08oNjdq5QYS5BP tEcAIyUdaIWLmmfMo6EjyRJCzL5SD+F9UwllEuikEfzOh4gfBVZQ1K0ZpU1BFcueSRXQaZSpO6BO JaokqiSqJKqmUoWqIOzrmApM7eiMUtU8IOH2S+MvXl9M5lsrfA6GlYvgZ4luo8FFkPIdwjOG51s0 QWjWcvT3YZBgNej7iMPMUfwFzJikz48ZKxfBMeDFkxZ1Ba8ntXS5XNgVNnHw4eBw2WEsOn06t3Rx LRgIv1VnGkBPlHv+hmdT7AGdRjmKA+pUgCZAE6AJ0ARoAjQe0JiAotI8IEsXfowJNXGQy40XwJiC Di3mhbyjTQN8TdeEmlHQ34eE4y7S/ys9tjhT4Pk1lxH0rER7G0OFccxkBOiUCuOQ4JHgkeB5O8HD OM9L6/OLCBzv9CL3YvN3VmcMOcJChS5C+YN3Vo8o0McIB+ddblBw4QvMoZxNzVnIAST4RUHZQRdW 5O9kK9DJdI8iHglVBOnygrh0PW8poCPWvtTogGPc6Cr4CRGEG/fXARSjojVmMAY6paI1hI3CRmGj sFHYKGx8LmxkcuFL94BKKhhheH9aRjGU0XiSrxQGti3Q9ouEmoTyN0eDbkZbKN7U8PuAexfdpZYg bfgqhvnyU2C5yT2kP774Oh9eHPPKNIAwVI2OGcSATqkiHcIt4ZZwS7gl3BJuxeMWVTyoLIso3LoH +4Su067k0KA/U7pzbWx70qo+8zCuPPqzL5tQ2eq+Dp+Fsl1wZbvA033pWo5d432YI9aUAjbgrgyi uGzx8hxs0zRlmG4me64r3zTFTEh1E2+nV88u+CW6uu6y8ly0LXVVz7+WGbsejMFP8Lov54NjduHg YWUL2XswSH0y7hyqbl/acb3bMpwba+p6sJGubLizd01ThwVFpg5tQzNbnIWGb6jh89s0RXCu/Vgm azAf/FY5YtrVtVThnAJ25T8pamubKpTzXTxtuL7kcK5K276zBVyJn0cF5nGtegjepVkVB5X3EgcS B+viwG6Lg+BriYMjiAPm0rgyPCALxUCvXsYTA8wWQPo/TCOwvyB20SEKR4Ch4wqfqsCfRPk0aOzC oo9dOHSSDjnkD84Jqdb0IvL2Cvx90F3FUQwPtfjyFnQeE4UojkrBN6xdqmEsVS98hqGgU+omPQGz gFnALGAWhSgOTJEbmJmSQWXzgGyzPUB3646Tw8A0CuJN8MtC9yvt6MTYSl8LxQeN8jV18WVA0LMO vcW8q5rP5aPVjbgCanEVFmjvZELdXhirS9/uCr2TcHCLQkAtmodFN+EmXNx7LOh5FYrcEEqVPpph KOiUKn0kYBYwC5gFzAJmAfOBKXIDM1PCqSoekQq6B4TCS14yQmg+K3ACUubLScRm1T1KrNCB2wn3 +/IwDa3AX1kY8gfL0YwgFMkOHsU8HaWMsRXVt8MQCmN1d1AFSpgpCdNNYRg2ZBfhN14rOmcXhnrj ZN6NUO9l6HFUabAZ9oBOqdJgAjQBmgBNgCZAE6BlADSm5FxlHpDY+SoNe5gjnydQQxRHp1CojSje kyLBHLlW08dR9e5mGAo6perdCZgFzKJ4EQoBsyjekyI3MDPF9ipXPAOEJphVlaoyo8ho0+UvreUL wPJJIfTNvznNwxnv8YU5LHyJrh1CbXa01hGDw2qnmF04OGSXLg+UMDiaeUIRKfhq4RjQlA4vLKPL 6x4RQqlqgjMMBZ1S1QQFzAJmAbOAWcAsYBYw3zA0Io/kfrb17hkg9DlB90tTVd4XrA5WCQGv1d4V oEcFeTeuQM4BC89pKhTF+1HkhtCINJLB2XaKocud+qgA4YA6fTL8FTALmAXMAmZRiGI/YPYR+TD3 s21ZCUK/NOVGEDrrCpYx5Aen80vg4BjxEVLiZYfYCpckqquReZi3hea7vvJgAlgUR6dI2IlraT0+ Iq1ncLadYijoNCrQOaBOnwx/BcwCZgGzgFkUotgRmCPyeu5n26p5BghNgLcdbsKEEU68DdFCsIIV 7OHgKFgKCmC+UD2Gt3z3vr5KYBnGVhrx+Z04uo12bwgdhtTFCS5YFxBas3GpBzoGh48lwpecwrWC E4TxSrD0Bl3R4Tnh7Ukh9PsahEZdD3M7204xFHQaFegcUKcCZgGzgFnALGAWMB+HIjcwR+T13M+2 tT0ohMKq7IJQQagg9Dkh1CG8cIhdh7g6mJAXxZdAqEGqmVk9hkZdD3M7204xFHQaFegcUKcCZgGz gFnALGAWxXEoMgNzGZHXcz/bNuVBIRSJ7JwQeqz8EgevIoPsQjSGheohsCNALNHME3YJvSTvRaFy jKJ4T4rcEBp1zc3tbDvFUNBpVKBzQJ0KmAXMAuZjUgiYRfGeFLmBOSKv53a2DUWdH0L3CEtKSIeB 0h/eUQbte/zgO9xqxt+mfQBYEIUgVBSi+DEIvSLluaqqcDrXJ3P6219Pg5/++P3D1649UNancDLu 9MffP/7xUfRo2T54+Uv7zBRpY271qd3ZFq7t8w61Y6amnVLx0DP8Bp1S8dBSCqQUPDXQiUJKgShE kUcpKJ1zrQ5w0QluP7Rw3wRPqwQRQdNtt3OVYBW9merQwZoHgPcewVi0wRqGJCXUf4AUDyov+GMY /TzwIgqBtyhEsTd4b6H6FEKp6tAzDF3utKKqQwuYBcyieBEKAbMo3pMiMzBXTHXo4PxTBHzRoLvL 5Qf5ijfi0CoBoigEoaIQxRNBKFUdeoahoFOqOrSAWcAsihehEDCL4j0pcgMzUx06+HBQCN3j8gPU wEMorBiB05+gmRumP+0Q2AXXqoTGdzr9CSd+wXIVsCu6RMmRVRpBqCjek2ILQiMjsYMLTNhVFRM0 fY/EvkHtFbsAfEcFTd/O1VP8Bp1GBIgNztVSCqQUSCmQUiAKURyXIlYpWI3EZlWCiKDpQST2XSVY PdFHhJHdT/RVcVDwpguaPCd4e1hThI8Eg/FpUA+Ag+8QuCY9QOAtClHsAd4LDWun6hAVNH07VU8x FHQaVYwsoE4FzAJmAbOAWRSiOA5FbmCOCCO7n22DOyiE7lGGRBD6JRDKD86b5GFkngzTohDFwSgS ILRag9CooOnb2XaKoaDTmCpj97OtgFnALGAWMItCFMelyA3MEfFh97NtXT2gUMcOVz7sceEeHBzf YAdtiDBSCkIPbfLE0IOuZYTQg2fO53dBCriI0KaLVleFPwWhonhjitwQykVDTzEUdMpFQwuYBcwC 5meEWQGzKETxNcBMVYdumqcwD9Ogu0uhDggL0LK5g5EUYyuMDIIGZWgehvZWGr8TjL3QzI30ELiI cEkwBY34vI6A3/mPZZcNIXT4BkeyY9jVqKFEgms4wR+VaE8pgEVxdIrcEMpVh55i6HKnNVcdWsAs YBYwC5gFzKI4LkVmYK6Z6tB1+zkeE0L3KJbxpRBKX40IA5kwBUSxjJdR5MM9fhH38BXIPCwKUTwF hMYUygrVqS7syfj4shh1TLHoUJ197dtT6R1S8TEvrOE3FRA9A3DQKRUQLa1AWoG0AmkFohDFgSkm WgGulNXqB7ROEBEd3fZL6ASrZ/qIQLL7md6WB0XvPUp1fCV6w5g2eN2FQ4NjnIQThEFisCsI67wV /ytzqZ4Hi4XeohDFQ870puTwOyaK+n6mv0EqPmGuHr8j4s0GZ/opgINOozzwAXUqrUBagbSCY1JI KxDFe1JQZ3pSJ2gios8GZ/q7TgDP9N9X4Luh/PTtgPnTuJARNieyIhFvUa4PLDjC23OVrUVw9ZXZ Ws+DrEJvUYjiSc70tubwm/PT3yAVn+nX7rVoOD/9FMBBp5yfXlqBtAJpBa9BIa1AFO9JQZ3pWZ2A 89NH6ASr8E356UvzFBZ5Gu/3SF+zfEgZD7n8pQ9QdYCD/0xT5IuZwylyGRPFkE6RsBOfBouF3qIQ xUPO9N5w+M356W+Qmnim5/z0UwAHnXJ+emkF0gqkFTwjxksrEIUoHnCm53QCW3B++gidYAW+bUH5 6dslOCZ675E5B1PRYAMyiuPkNVjKBVLw6J0PixNqvED7OnRSQLynLfI4HBJeJYK4wvdn0qqD0FsU ovjCM33pOfzm/PQ3SE0609uC89NPARx0yvnppRVIK5BWIK1AFKI4LgV1pmd1As5PH6ETrMI35acP 4aDovUfmHF1eBuPkwYqtCnKjtald0ihhw3BfDdF7mEYZJwFx/dmfUAPs6juiKBEFKgcKa9ziMdDM YR3dLVA4Coa9LwV5pm9/pvCb89PfIBXjd7mG35yffgrgoFPOTy+tQFqBtAJpBdIKng3pRJGsFayf 6UmdwHB++gidYM3Obyg/fVMcFL0RHOaMssuYP0aXpf3aK1d2QG+8iDze013tEl9IpzjyOsUouXOI 3sMSviNBNyzhGycaIRz6hu4KYjHSEKBOgbWQX9l5lGitYAOeIGxAegteXajp0EtyMCx++Jm+Ljj8 5vz0N0jF+L1S994azk8/BXDQKeenl1YgrUBagbQCaQXSCo5LQZ3pWZ2A89NH6AQrde+tYfz0Tdfw 9ej9nHi/S3YemkeC1R9S0EVmIXpjvIc4CfPgaFg3KAMQc/VW+tfoOlgIbsj27RFUeYT32IZPXyC7 B+RidnmQprvCDgQEVcN3HseVQ3hv0TvPqOM9E3pvnekbx+E35ae/Q2rimZ7y088AHHRK+emlFUgr kFYgrUBagbSC19EK1s/0pE5gKT99jE6wdqa3jJ++MZXQ+ymz8/D9MPxNtPkq7gi9D4LeEKQxIu0A PBCkj2Z4p63lCdoUH6qIBve8NgUdCIir/F4YAG8xTvP7kXeKb6DTKN94QJ0+GTYKNAWaAk2BpkBT oHnFt4gwrfuZ0DbHhLdXaVCOE6HSPE0t0uekUDUVUbwnBefnbUzD2XQj4rQGft4bpKb5eW1EnNbg 0DsFcNBpjKv6fuiVViCtQFrBa1BIKxDFe1Iwfl5aJ4iIxhr4eSN0glU/b0SY1v1M7+0DbjJFmSU5 Tb3odk5sIoX2QGi4hRFUO+TtOPTy4f2qFqH3MORi/D7QIu5xT2yCRRe+czo+jdd0hN6iEMWTUpBn emcp/HYRcVqDM/0NUjF+r9nkXUSc1uBMPwVw0GmUdzygTqUVSCuQVvAMGC+tQBSieMCZntUJIiLD Bmf6CJ1gzc7vKD99WT4AvZH43aXSCZT99B0mfJGOhOod+cpoHgBfRCH0FoUoHozeW2d6X3L4zfnp b5CaeKbn/PRTAAedcn56aQXSCkTxGhTSCkTxnhTUmZ7VCTg/fYROsHqmp/z0Vf0MUXY83u9S6QSa 6uH1ow2ioP0E2GDNOxDy1SJN8HegeeAxMipmb/UGh+i9JeiOIpdFIQoavbfO9GVN4bfn/PQ3SE07 03vOTz8FcNAp56eXViCtQFrBa7xBaQWieE8K6kzP6gScnz5CJ1g703vKT1+bg6L3HqVc6GwwmAeH ZT8PVbQNH4MbvH4DDo7WKiFtj49hpK8RwYPDRcx3VQkM8cN6y4+lUY4qpO5QAgXWVMUVW9A9KbjM Sr66JbgwCyxig8re4AnCRYTFX+hqKsNg03ED/c6fE4sffqYPhsNvzk9/g1SMUd/W8Jvz008BHHTK +emlFUgrkFYgrUBagbSC41JQZ3pWJ+D89BE6QbMG35SfvvEHRW+EFjkt8nSCHF9ANOFGkowlR/OF +H0pFuMloSeY0a2x+/sYlYDlkRXJTIgvCbdzIpw8GFqI4rkoyDN97Sn8Ljk//Q1SMX7/tILfJeen nwI46JTz00srkFYgrUBagbQCURyXgjrTszoB56eP0AnW7Pwl46c3RREOCt/0LS0JJvk9isLwZn8e q2DoGF9GBr2ohKC557xa5cAazQi+oaUXGtihYRqZsqFVPOMFIxlv4eQt1gcDsfelIA/1TeAAnHLU DzAVI/j3NQSnPPVzCAe9Uq56KQZSDKQYSDGQYvB8YCeKZMVg/VzPqgWUrz5KLVg19jPOelPY4qD4 DW/13CHW7lVKzXoE7BjF6Pix54xqg4PzfhI+xBEHLNLLPppHVP4cvDmUt7Jjgz20y9PeAnwvq9BY FAC/Nw72ppW6FIRXlLt+AKppJ/uK8tfPMRz0SjnspRlIM5BmIM1AmoEojkzBnOx5vYBy2UfpBWtH +4rz2beTy1/uFpatgRQ06jqYGsbbb/lwONq2ypu0oS6QM40OcZVgT+eB7ysTCPHepXfi81Co3K0o 3pOCPdpbx0E46bS/gSoODF89hJNO+ymGg15Jp700A2kG0gyeEeelGYhCFI842rN6Aem1v+sFaSZ/ zmvvqz0BPF+pWpjpBu3mDo0BKQSuAtcjUQjARfGeFOzR3lUUhAfSa38D1bSjfSC99lMMB72SXntp BtIMpBm8BoU0A1G8JwV3tGf1AtJrf9cLko72gfPat9/8jgCer2ItvmwGIiKKfMMQA0EJpkrB4rfQ YwChEo1RokA9DOBwgtCVIHA9IIUAXBTvScEe7X3DQTjptb+BauLRnvTaTzEc9Ep67aUZSDOQZvAa FNIMRPGeFNzRntULSK/9XS9IO9pzXvtg9wTwfIVrE+6cyVcxhodKrFbku0f2ABAjCgG4KETxYADf PNpXloLwmvTa30A17Whfk177KYaDXkmvvTQDaQaieA0KaQaieE8K7mjP6gWk1/6uFyQd7WvOa1+X T1EsJx/kZwztw9oDb82H1U6gpT1jSBytukhv+no4FoCLQhSPOdp30MdAOOm1v4Fq4tGe9NpPMRz0 SnrtpRlIM5BmIM1AFKI4LgV3tGf1AtJrf9cL0o72nNe+qV8NwPOF9sEG/krbjBVnBfmCfAG4KESR frRvMZmB8Ib02t9AFcOXX4HwhvTaTzEc9Ep67aUZSDOQZiDNQBSiOC4Fd7Rn9QLSax+hF6wiOOW1 b//JD+Aw2w1XnKWvO0kAPihoUe4aP0GcH8dfqUIDBq67o9C+t6AQgIviPSnIo70pDAfhnNf+DqoY wss1COe89jMMB71yXntpBtIMpBm8CIU0A1G8JwV1tKf1As5rH6MXrJr8I7z2Q73A+gi9wBURfouB wcCFzznsEQSXrzAstnvT1nioYcCCOpgC1s1ZCd9wBef7ub+z9Y3A+X60E55hJ0QYF4c7oSyidgJn Q6wecJcWft/0BchwDFhjC+8p+jorWHyLP6bgkwKvrKMxHLxxGy0JvJAMvkE4eIE+miedB9y7SFw4 9M6/dq2GDcOTgh2s1Uipch41IIqhy3tMgS7WhoNbdLF2gboq0DXZWGtEXQ13yZirn1ADWiuLuIIN rz9BxK5Der9DV6O71F0CEDHGAjjA2Skkgl6jDH0B9iqgFdB+NXgIaAW0L4dDLz/B5wXaCC/V4OgZ HnDXE/5+keSyCCqxHELS0SJxY79Ucj3nzF8RF0Yzh2sFMRROEOI0aoCD41vH0CLieQwphoi4iwTO KOugPOVRF+EC5qpgG7C+gZYE6gJPqj3AmUOFCulNGdn1aPASLfv1JAKgMsL7NDyTTrES9BrlZAqw VyGwEFgILAQWAguBXx2BDRc6UT/g9iIs0qAcoi3BMF8RjwEFFAoVgNiDxT+0NtNufGxU5o3jcHDa dozN0DCGAAaAQjv7Dtcz4QnCaGA69JV/g3ARMbvIfOuRBMZyCMk6KIdKJMzh4CUSmyXiClLgMWiu PA3gWGYjnMZd8YuIxvCoAS8ieueeXvaERaQ3HOzKQoUK6k1r501DxrJNQRT0SsayCZoFzYJmQbOg WdAsaP4E0Yjg4vvx1ha73uDDmyRREBI2/qFKMtD4h6sHwXnABoRWHuHC184coS6eIArYgq+Wnzm+ +pgObsMaCm2GxuAKywrRux1HvcExhvMYYmgJDXMQrb6BBo9iW7CUh0KQNv5hROS5opcEQyVkF3YF sQeOAS2oO4AS5MqjN+jXAoRMRG7K4Lw4QyXQa1R8b4C9CuuEdcI6YZ2wTliXEesi8kMGBzDzgHtW cEFL+GHzxj8oBGE1FZheC015GSUXbS7E9Vf4IjYwzYW2oCbgAm38u2aAg+0dVZHorspN9zfoNSos LsBe9dXoq3nqr4arAmJtTOFvZ6lQFuvN5v0jX1kvG7sWYFEI6LiBXcEC1NDVwxfS3tBswbvkXKr3 l7m+QziXqrbIU28Rrm6ILaNKCdm7baarpnT21ahDU7pz3fbV9ld9+tuvQt6ffdmEylb3CX8e5F1w Zbtg05VwLc+u8T7MIXRKARtwVwZRXICkPAfbNE0ZpjvTnuvKN00xe6PdzNvp1c30xRFdXXdNeS7a lrqq55g0Y9eDMfgJXsFqPjhmFw6+FlNp75a4duO5c6i6nWlHG8mW4dxY0xXivu+kKx/u7F3T1GFB tapD29DMVmeh4Rtq+PygTRFcV3xnsgjzwU0DurqqVnMK2JX/pKitbaoWhmfbeNpwfcvhXJW2fWkL bvH4eQQwj+sEwcusVgVC5b0EggTChkAI2wIh+FoC4RACIeJwPjhm1A9ws/Cl2XBdXWiqps/NvDoK NUJYSQ430EdXvLrw9h3aMMBHrfEnbayIw82Q73ohXOTmOd0sfEFqlFyGI7HoBB0YBlaiDCRs7+dj t2AgH0oV4x0z2McDZw6dJnTIHB99h8PyGprdDafJQlfo1SYXDp43wBTELdcaQETSnDeFxOVeXcxl hANjjYBWQCugFdAKaAW0Lwq0LsIrMjh6Ng9wC/MZLxmdvK8vzPlUMehUoXOvElLe+Kwz/hbgfPoG jJ+EuYmwYZdwgyEcjzLCaOzJGEuH8Q1KeYhvsGIFDEjkIQbOHCI7zW5CYCUdrwffOWYXDZ4QRUjn wiW88w2cBogY5dG/Hz2nkAh6jXItB9irgFZAK6AV0ApoBbSvArTUfUpdYc/8iMh/2BAXaCnPYyi2 HfOgxKNuvng+fowEfIMhjnyUIWSXvteWz9aCqBtX9iNuHvQiQlt+nPYwMsbuYH/Dso6vIMLbKpH4 z2gVhBdcQLPnl+obfEUXCEp8MZIEyN+o6ALwjbsdaQZwoFfudiTBpmBTsCnYFGwKNg8Cm9RdR11a V/4YnXy5oglV+/YIEOJtlRnLZewweEL6LD0PiFYZ45kS7m+EaAXVoz20hyjb8chQOihZ84MCCl52 AGMp4J0GGRExweaKQCmhpOaxID/BEkzbp/MjO8A37oKiGcCBXrkLigSbgk3BpmBTsCnYPAZseqoU S+dc3K9+UUKpPT4XYr/iGDkEbYJtjI9OgvUj14p8eK4OzGwngV65OjDan9qfaCdxRWicD1H7kwu2 qIrPMkWw3CtaJ56C3+m4bC28rgXeFIpK4xp4MyW8dgapivAGG/MzvaH5LCi4PWFX+TT0PVwkCUsC TzPQ6QhPAZCCPxjRZ6w4sTc6HtDJZ3xiGDT7J6iKkF2YXce7L+iZ59Tp4RjQcQPde2vlYjwZi3CT /+ugQsYiCFWEKkIVoYpQ5UVQhStV7YKLQhWqGparqx1BBd9lsQMMva8wTmCXF8b5qmHjtYLxkTsY SRICJ1cNslyJnvt3uvrxl1yJHn39+vr19X/B11+SVvRm+YLqf2///f8dCVnbCmVuZHN0cmVhbQpl bmRvYmoKMTkgMCBvYmoKPDwvVHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL0YgNAovQm9yZGVy IFswIDAgMF0KL1JlY3QgWzE2My40NDk5ODIgNTU4LjIwMDA3IDIwOC41OTk5OSA1NjYuMDc1MDdd Ci9EZXN0IC9wYXJ0LTUKL1N0cnVjdFBhcmVudCAxMDAwMDg+PgplbmRvYmoKMjAgMCBvYmoKPDwv VHlwZSAvQW5ub3QKL1N1YnR5cGUgL0xpbmsKL0YgNAovQm9yZGVyIFswIDAgMF0KL1JlY3QgWzQy MS4yMjQ5NSA1NTguMjAwMDcgNDY2LjM3NDkxIDU2Ni4wNzUwN10KL0Rlc3QgL3BhcnQtNQovU3Ry dWN0UGFyZW50IDEwMDAwOT4+CmVuZG9iagoyMSAwIG9iago8PC9UeXBlIC9Bbm5vdAovU3VidHlw ZSAvTGluawovRiA0Ci9Cb3JkZXIgWzAgMCAwXQovUmVjdCBbMTYxLjM0OTk5MSAzNzIuODc1MDYg MjEwLjE3NDk5IDM4MC43NTAwNl0KL0Rlc3QgL3BhcnQtNgovU3RydWN0UGFyZW50IDEwMDAxMD4+ CmVuZG9iagoyMiAwIG9iago8PC9UeXBlIC9Bbm5vdAovU3VidHlwZSAvTGluawovRiA0Ci9Cb3Jk ZXIgWzAgMCAwXQovUmVjdCBbNDE5LjEyNDk0IDM3Mi44NzUwNiA0NjcuOTQ5OTIgMzgwLjc1MDA2 XQovRGVzdCAvcGFydC02Ci9TdHJ1Y3RQYXJlbnQgMTAwMDExPj4KZW5kb2JqCjIzIDAgb2JqCjw8 L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9GIDQKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFsx NjEuMzQ5OTkxIDIxNC44NTAwNCAyMTAuMTc0OTkgMjIyLjcyNTA0XQovRGVzdCAvcGFydC03Ci9T dHJ1Y3RQYXJlbnQgMTAwMDEyPj4KZW5kb2JqCjI0IDAgb2JqCjw8L1R5cGUgL0Fubm90Ci9TdWJ0 eXBlIC9MaW5rCi9GIDQKL0JvcmRlciBbMCAwIDBdCi9SZWN0IFs0MTkuMTI0OTQgMjE0Ljg1MDA0 IDQ2Ny45NDk5MiAyMjIuNzI1MDRdCi9EZXN0IC9wYXJ0LTcKL1N0cnVjdFBhcmVudCAxMDAwMTM+ PgplbmRvYmoKMjUgMCBvYmoKPDwvRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDEzNTQ4Pj4g c3RyZWFtCnic7X3bjuy2kuV7fUU+D9A6IimJEnBwgG1v25iHBqYPDMwHzBwbGKAHaM//A6NL1k5d uDJjMUPKS4WNbe8qicEQRcUigysiCh+68Z9T2f/7b8Xsx9j50//6z4//+hiu+Lp2pxBKd/rrXx// 87+d/m//+6pwzfBPPbZd/tQ3dKfh33/+dpr+8tefH3/7LZz+/H+jvNY1J1fWzSDuj/E35XDr9Jf+ 1p9+//jbr9WpPf3+Ry9o1M2dfFNUdXC+Pnl/+v0/P/5elq7q/9T9H9//afo/4fz3+vz38f//OP3+ fz5++R1IrWMRfOvCRaqPZVn93P/pxpauLGofqhCHZ/v9f5/+Plzp5X4vy7Lvo+rvrvt+qmr6fd3/ 7MqzhHb6eby/PP+917Pu2/VNpt99tu1/X/0y/W58rr6tc1Ob+qfp/0N/w/Xh/6l2qT6T+i3kXh+f H6Me+wGYBqg6qzP+GVRppuEYh96ff++nP9Wv5+suoZ4731ePKtRt0TXtfJi/XZHnz4/VnYdg+dIq VzS+7cpm+c6uN/K+qJ2Lrls2cuen/Pnzya8OWB3rYjVerr7Rotu08NdbtK5YvxTXfDb5j/7f//pw rinGL7L/1Ka/xqo9+eDaIlZdewpl0xTt8LvLN+0L1/+m66+OX/2Pn2ay/s13dVn4sr35kbuy6WW0 Uwd/fBR16U+X//SNVr/pW4eTi7E7VSdXT43i+Rft5VdV56Zfxtmv2u19XevX0vpv3AW/ED/9YiV+ /OVS/Oa+QfxKWi++CmEpfvzFWvzwy5X49X2j+KW0XnyM4dS14cevii70t8z/Owzr5pfjyPrYtr20 4cezbuMv2suvRt2GX8bZr9rtfaNuS2nbidArWZXj6JxvKeKgijtN/x/0XPyibxLPTdpLo0FYP9On Bpcf+pvHd566fanGOAuWigya9QPIajY0ITRL3J7SbKHIoJlvac18S2mWuD2l2UKRQbPK0ZoNTQjN ErenNFsoMmhWV7RmQxNCs8TtKc0WigyaNZHWbGhCaJa4PaXZQpFBs7akNRuaEJolbk9ptlBk0KwL c83EFi6em17tctJsddukx6LbwcT2a4dMPcamt/VY3zbqsex20MN17Jsam8jfVOr2xJtaKjJoFmj7 XgfKvqduT2kWVva9rmj7PjYhNEvcntKsWtn3uqbt+9iE0Cxxe0qzemXf60jb97EJoVni9pRmcWXf 65a272MTQrPE7SnN2pV9rzvavo9NCM0St6c061b2vXG0fR+byDVL3Z7QbKnIoJkPtGZ+a9evaZa4 PaWZX1n8JmRb/LHpbYu/vm3SI6wsflN12XpUt0z5pMfqtkmPamXfm8Zn69HcMtyTHqvbJj2alTVv Yp2tR7xlpic9VrdNesSV7W7aNluP9pZRnvRY3Tbp0a4sdSxdrh5j09t6rG+b9tLlyi5HV2Xr4W4Z 3EmP1W2THm5lhaOP2Xr4W+Z10mN126SHX9ncWJXZelS3jOmkx+q2SY9qZWFjnb2CHpsK9KgTK+hl t4MeTbY9HZsK9GgS9nTZ7aBHlz9PO9k87VLztFvN07bMnqdj09t6rG8b9Vh2O+jhs+fp2FSgh0/M 02W3gx4he56OTQV6hMQ8XXY76FFlz9OxqUCPKjFPl90OetTZuD82FehRJ3B/2e2gR8zG/bGpQI+Y wP1lt4MebTbuj00FerQJ3F92O+jRZeP+2FSgR5fA/WW3vR6dy8b9seltPda3jXosux308PR+bGwi X8Gnbk+s4JeKDJoFej82NiE0S9ye0iysbG5X0/uxsQmhWeL2lGb1ygp3Db0fG5sQmiVuT2nWrOxy Fxtas7i1x9c0S9ye0iyuLHXXZlvqsangS2wTlnrZbTj5ssy11FPTm3psbhvPfsrVeYovXa6lnpoK 9HBbS73qdtDD51rqqalAD7+11KtuBz2qXEs9NRXoUW0t9arbQY86d+U7NRXoUW9XvqtuBz2a3JXv 1FSgR7Nd+a66HfRoc1e+U1OBHu125bvqdtAj+4xjairQI3HGsep2OA3PPuOYmt7WY33bdGy+OuPw zuXa06mpQA+3taerbgc9qux5OjYV6FEl5umy20GPJnuejk0FejSJebrsdtAjZs/TsalAj5iYp8tu Bz3a/HnayuZpm5qn7XqedvnztJPN0y41T7vVPPUuG/fHprf1WN826rHsdtDDZ+P+2FSgh0/g/rLb QY+QjftjU4EeIYH7y24HPeps3B+bCvSoE7i/7HbQo8nG/bGpQI8mgfvLbgc9Irsfm5qIV/DJ27cr +JUig2ZdtoUdmwpGqEtY2GW3vR6hzLawY9PbeqxvG/VYdjvo4bIt7NhUoIdLWNhlt4MePtvCjk0F eviEhV12O+hRZVvYsalAjyphYZfdDnrU2RZ2bCrQo05Y2GW3gx5NtoUdmwr0aBIWdtntoEebbWHH pgI92oSFXXY76JF9pjA1FeiROFNYdTsQTrPPFKamt/VY3zYxU1dnCr7KPlOYmgr0SJwprLod9Kiy 5+nYVKBHlZiny24HPZrseTo2FejRJObpsttBj5g9T8emAj1iYp4uux30aPPnaSubp21qnrareVqX 2fN0bHpbj/Vtox7Lbgc9XDbuj00FergE7i+7HfTw2bg/NhXo4RO4v+x20CNk4/7YVKBHSOD+sttB jzob98emAj3qBO4vux30aLJxf2wq0KNJ4P6y20GPyPIVpybyFXzq9sQKfqnIoFnH8hWnJoRmidtT mnUrm9uU7PnY1ESuWer2hGZLRQbNHL0fG5sQmiVuT2nmVna5Cdl2eWx6e76vb5v0CCu73FTZdnls KtCjStjlZbeDHnW2XR6bCvSoE3Z52e2gR5Ntl8emAj2ahF1edjvo0Wbb5bGpQI82YZeX3Q56dNl2 eWwq0KNL2OVlt0MwV5m9zh2b3tZjfdsU9VWurHD02evcsalAD59Y5y67HfQI2evcsalAj5BY5y67 HfTIP0GIshOE9W2THnd0KzswWN8m72Pn0MN09Pj/OP3973/795//+/f+V//4x0/ff/74269DIGwx hFWXZViE0zZFW3dDfLer3GcQeDmFjTdFLLuy63/9GRLMXwgtuFCjFrVHFxzb+Tm2enuhQlpVDd3i Z9R5R7dAD1h9Y5+8qtQG0SNRHo2V/4VWlx+SyIrCrxaOFd1H9hv85d9/HqLXx0j1U9FORmj2U/9l 9/v5KZrX93+c0AC42wagl1usvn/F2YO/ZmgY0Ki7ku2jQp8gLwqbEjhJ4AMiUfjzgH3wUxe1yOgc msRf9WwlPYg16qP8df6lLT8Tf/szqaquaKqyCSKgPA9zsrMg6KwrR1huE50lZVYSmRHKNKQ3pDek PxTp68ndNAH9jx+GbUnoJpx3rhLjfH37++/linEef+RwJujNHfwBoreEzQL/kaPXV6MlA4YoNEXg bLsGUc3tN9zWoai8a2UWnn/5/GhmfNSKqybeDMA3Bi9ACIv4VUZqV+5rfay2N0m/SWZ0FVfM6EIG wMI9D23ZMiCZR156rPDKH74oZOyrn+hJDZ9jLirWXVKUK5sq+X0sLsyfY9kiggvzzpcXKlaU3FER /Dm5V/8f8QKmvW0Te7mFixO8/TCK5l/QsK8vucVPYmsn2Ag3oSgbL8NWbCKgRWuwdk7gkJ/v/df6 pYUKnHzzzf8uCwqDPIO8O0TRJiujc/p96BsFZlKLtmfzBQVcN+CVRoMuoBbzmUitGxItPOqjo0Xx T446x6LgGotex81NxrKFQy2+qY0uv7rE7xz2AecVuuDQk0Ot4AUPR/fKltwJTgBme/IeR9UhNMMf Qzu9oRmCq2UMPbzVpJfRmk/+yIX3EecA/APimQjfOewDzit0wdGnE/jYAo6uaIou9uTIPuH9Mm24 sNWE1h8aYGTqsC2HKAatJrTlvCga3vA6hFYXukLwWPGrCjQkNXpAKAr3wU843jvUXkFK8vh6DZVp oeT59S74q+dkzjDSEAj0tn78Fhab9QPOS/GShFYX7gnxWPELDDQkeLMIH5A+hNHcJqPO+T7gky8+ gzn+YltMYwoWBa0ej1vQ3kMUQn1ACITq8jtu3Dm/487FFKaPkn5R9L4ze62ShjEBDWO2i6zdgY5Y 2cd4p7+Vtk/YDOnxhDAsQNct7STld8O4c343fISRhx5zfvFAvw/NbTLPfIDLv3kL2ckuNCrQPvFW E+5a6C0sxiTaoYwxCWpF775wHwjeMCCiHTe+ADdyejCdsdaB6tLn/7fc3GlAFLDW5pvFNSKmhQr4 U/PN4i4wu5MZuW8bwHOaMzys9G4Yoyntps5gQdMbOdwHTfPmz7gVua+aqzSort4Zt8xNvTjvhPB0 4wSI2WRBZy3tA9Q8vYT7Tj3wx3uph27LaOe54sli4KeP+kIpjYgC9txs39lL1QdEaOTp0xm8ydLj +mmeLMJ9px6E4r3UQ7dltDdb8dQv8NPngOXG4WeqMu8pv6inW8AtbMY5IW3k+e0l3hnBs0ieMqS4 DkGgi1cVcFdPHznybm7eb3we3TS8SUi9s13kGt/SIb8iKm6EQjVs2BFEC0XSdwZxVfEAUS9YGFpv vM+hnecZXCAe0BD449UN3KPTTgje3Z5xZsEfTcCYAeishbaY937yWz8ImhBs4O6L9xTDB4SgSQNa xgEi7EPvyR0SBS9kbcu8IDBjti2LcQeEEX0PMljg3Xh68drYztKRHIqsft6WZ5zh0cEt/JPDcDV4 4bEs5ufn8i4Qhifv855NnqICEYZWV9Gc3tofqIhC+zWeTpu1nfGSbEOz7cwaF9JCRbTMCIVqgM1b fskiCNR0i/L8FjiItLqKQKC4qOc9rBlxkYp7ED2eLfYUz9/HAmxoZ1QG+V6PPIAtK+/Rg4dJv7Ba HXKG9+4RiJB1g/H3xqY3DXyC0IHZJqsrd9hkHf3Bi3Z4PLsR7wn1jvmxAea9dXAQ6cxih5wTvvta B/JjMEzTu3pMBnktvDgwpjptNQVM9fkeZG0200JFbL8IharsQV7LjBwYapt+ZSIu5Y95UA+Xbs8D io5Su2aHZLRHUOINAjaiXmu7q0iRPCIGw6M+YOrlAEXppWt1cCvKH27RgRNHBKFnxC7Qu1p+T5Sx ruEj4GlGZ4Yo5CPGKzpI3YEuDp5nCufVjVwMaUDkCCwbREynkecILAazBrMGswazBrMGs28Ks4Hi 29Q9Kh/oCoa+VcXiIYrBY3qJLI8w2RlZZuED6oV8ZtSreCQLSPPE9uhyPAtXMAz3vnEKKSnC1nbD Urr/T5AXZwkCwodv28/yUhfDpOizzKh7ABeZesGrGZzCA8qwZHDp4dHHja1IGse4FGsbIEsL5VKs GToaOho6Gjpu0REXLmvLMza2UY6NksplsdtiI9yl4zBPxVBSvczLfG5Cq8H2XOAvxPhry8r+e6n7 VWIoW/mHIzhsn212qx0qfr79J4jL+OjFA/ILAH4iZqSUs7JKYlGay11RWaX74JwnhfLp3q5RToKA chJcXVRNe6/lyjieohmbGZsEmrvEE+gyPAd8juQbY5V++wJu0Hxvu377N1ehVddOYOo6wkMjOqCN UCsNNMUncTSa8tXZNEsm8/vTL+vmeuiC9pqRrgTkgqbzn+WGzUi/qpFmRPFOOrrmo2bCELpzfhCf NFcz7QJdaCXKsZgRvvTLFXPDndzWO1SwtNn9NWa3CPsz9pNoRWK8tutDIsvFA0NRoX2iAzL5GNVS r5IInyEIb8ohXYp+8iPy1R9SkYxPfc8/IF+L7cYDppGSSx6xgcq0UC55xC74a+ZQQV280eSPHGlg LvVquSgeJr1Y3v1DirTNh2Sx2n9mc6gBmjiHHJ8nlq4EwldezqiypVen1KPOMX0cicpInK5Xy/zc Rxr4qOQRdbND2cmM1N58+lLalckfdmVs/fTqar79SXSGA5OO+MnoQy/eHa9DaK4dX/b5zUydBlJm 7Ljp/Kx8uJFifTGcnkgvzZImsPMba/UUI2kI5TKJbDA0LZTLJLILMJtlVdDq6wLz29Me8TIUBkOI /BmLDekXsawagKZZMFMvZxbGeDr/sGLtTT63PxSlWF/MwyXJjcPWNIYKeHazvW27Q5XMQ6oyflny EC9KsfyWz414Y14tT0rj3cM83Z8uDp5xunBfeNLiTFUP9yzJrYK6Dz2x1sw0wZeWhg/IV9q5hnsk w3gNfGmhJEF4FzQ1c5hnDu/Tyk6siSn6WifWsjNVWYnNJzCHDJQ/8mTxkD06D8wwkoonVEEHQcQQ U0so95f9WrdHEedHnuEdkglBMQEFzyuBuZ7NrSqfJXoxro5f6+zkhFjs16CR5w/FkBnClpmuvKzp XLxhNTUAET8HX9MG7qVyM2wwfRxTebkWxGXM91JrUEoLFVFYIxSqgXRmQN/KgMoGkT/7QoidkTeB jlrJ8HjTCwx+F4mfQ3SUvUC69zKgGpsTWIEyA7cgHYdP36pHjuVLbOLO+WiPG682jVaC2IjLtqwp 9yjiDA0X79Lh64vppQzg+al8HUfcuYgNLwIr268R7wN2rue0zshJJoJpkePvCGcWJAZk5OiGzkXI T0UPGCBeQBT7rjYkOPYSiYJEDTgkmNrBb6wPmCUZoaJ01fCsE7lalHr2xy5yg6FpoSLeaYRCNYDZ zPormvWn8UZDDk1G/ib6FBY+IEwvik/LvqsNCY4hRRRRM+sHmHVC3Yz9GloV4OgbOgOA4nb/1qtN oxWVrbXx5YFkTLwzQt81hjc6cuA5M6YrloCCwO6RugFhq4edw/zOvHtYL805f2iMcU8vge3hSY1E u8gvvMNDojSJ9fDJ+SAEiEl6iXgPWYcoMkFpx/ityNY0hHKlqjcYmhYqIotGKFQDmA1sDGyOXd18 3X0nSqNuYPNlwYZ5cj6YEamL+zgm42otCGiYbUhD2IFtyofb8R7Bh2b45CP36BPSjM6hOVWsRHIE l5eOQMw4f+YDP48o/31fPtv7jjUxRQWabEUDDI08AkQLZtxccN8xLDSCIIT5JmuNC2mhIhZphEJV wMZssdni57PFd/YBHxC+KMXAT9GmVwY2ZotTZpNL9dxUjcQWc3TGeocqwA55ZDTTU+jVdXlsMSX4 hdNUB1g8j39AnizKM9Azkqk9pVvreSLqRVFmjw3a5YOoaSaApnMHtXCQew8zPNGhxPAC7BwTSfRO 8yDKKtJbDsxAmoZQks64xtC0UJLOaMBswGzAbMBswGzAbMB8xlCOZBl3KOJ7xAXNkp689ecxia5U mJH6SRGT4HPAkGi9dNlH5BxX9Ac/T1iFKGk0tjZ8WSDeBXhENkpDsZdCMULdjAwHV8p7NySXcg2V aaEkl9Lw1/DX8Nfw1/DX8Per4S/Hvmx3qLd7xIWHUk8e6lzMQBjFkhhfd1WhWGl4p1zdIqRUDEfg CxJq5kz7ssQePCQQSOgMpEfkRcW4R2eLuwaIkeSdrhExLZTknRrMGswazBrMGswazL4pzAooxbN9 Z7dDWd1DABFS0yEBCPoQaTt7CH2Et7PvXo4Wi+JT1emBLj/s+AHvW+ssSEZ6CZ2xG4+OK8feUxqs cEQ9X42Jr//wlCiGs/8ghNHMiUCPFe9Qxj52CKE/XUFKQZzMfEO6hsq0UBFzOEKhTwazhr+Gv4a/ hr+Gv4a/6vgriIe57FSj26He7iFISQMib+QzfKF8cMtTpnF9sXK0mmnkXrg28cJ1q0jOUbSBNCxg G/gLugCdizQHJwNC6egdvjwwHpKHVvnKrYCZRjFBRMpsF7mBsbRQEXk3QqFPBoGGjYaNho2GjYaN XwwbBeEisx2e36EK8GNR7CkdfxgvIHeFLwZyBCDSkRxGr9KY1KJc3aKEB+4aj0HAn5+vq9fGIym0 FXEQIxT6ZIbHLJJZJLNIR1mkVsQ1vlikIKlx2VJ0rViXO+SEQtuSI3JCvc3kVNy8vpbxfqxhfWHa +MIg0TXAFOuDaMaC8qep8ICZ3rYrnrnDFPgZO2c9T4ZmbvxHssOvoizHytogYloox8oymDWYNZg1 mDWYNZh9V5jlyFfNDvVajrgQ6FS9GWaITzlMe6+OqNeSQbfmEUYvsVYGWRdiq95RLu/p0xwSUZmc +xI58TRlfJrKZ+Lh8RueW6KTZ5xAmM+QDCGUtuUYYfjAYBgFC0XRp9v4ncPR5Q/j+WxY9On2tWrV Lcn8WmNoWijJ/DJgNmA2YDZgNmA2YDZgPmOoKEvxBZijpKpee+GjxEHoUIpvJs/VoWidH/bK3ScZ +6xjVVR1FxvfbKd4iKHuYWo9QKFXOXRVFbc2dd0CXsCiHGoxGam6iL7rujqup7gv2qbqunJjnocn 7x+v7dbvkxB1xuq6KPsrbdNuEWujbgX64B/w/EVuO8fqws6vFK/oLuyjftqFIjbDvPSLeeTrWHTe te18Ip3VCEUVuq6NCahtY3+h2wxO4sI3dOHTKrkyhtB/Lasx2HbufgKiyl9BCyiq+mzRet81sd7O 4vWF80uORVP7/p0lqB3y56jBc5wvpN+lu2oOmqoyc2Dm4Lo58LfNQaxaMwevYA64U+u2lLBVO8Gp 9cVH37pPvplD+xN40pzR4oDT7PDCUTwylwZfi1yxEDrcdNNV2PlTYDzsfPFIXpR6xcf05yuq93mx CU7CF+1ETse4FWpGwYyCGYXHGwWuLFMbSolRoOLs2mqHM4PAe5xpzzn89CHtzSMT5n+hPzKzO2Z3 8u2OZra1+ZDMzwywK/qA+sF86Z6MwsKP5NzBFhla8anF9Dzn2bS3NPRwYZob7EkKdSUXp2mIZohm iGaIZohmiHY3orlSEOc7203VjT72mGkmtOJTCSsG36AoKU2IUSRz8XkI+MRfEGJgagaeCwiBD6or yiQhwp6MXE96NVVx5A+fmxeSoGDME2zBE8ZgPBIf4EMPe0ZeLCjKX0MSQXKH+eZoDSVAquisMUKp BlAGUAZQBlAGUAZQHMOk6fSRBFt5mn6fYeX10gxnnB9CXBDls7rP84gfENpsfqzoXGyKRVJt6bK5 sGBhiJAEXgjIN5YR8M475t4Eew5JpEDXCDrEtUonP+Yx9FYoD0BEkrS1hkQglWRtGdAa0BrQGtAa 0BrQvivQCoiQs61n63dwYvKG9qHZ2cwCiy3w2zM8+AnH553ALkl0QfbkizwHsDTm92vGg4vw3lgP IFXEZYtQqtkks0lmk76qTXIizurFJnW1xCY5iozUlTuUk3fofWtGdZnlMctze5ZA8jOaJTDNWEDv wyM74vkcyPelOhaZJMU6ebeOEBlR32l16eNWfHJLexTwc8D0Q/yQ8OmgHpk7OCNvF1+SEvo5bvCo AVRybKsNVgKpHNvKENgQ2BDYENgQ2BD46yEwRSfr/ItWreetCn/KjQEDekZg5lvepQhF0afDEJT4 B3zSIpp6pGE+9TXuXD2biQZUZiAJPASmC93wB7RH8KjxgTk0/3rHxnxS45IGjJIv8UM/YEawbHsN xjgO2AbHgFSOA2boaOho6GjoaOho6Phc6EgRt7pQvSaMvX150IwqoHrc4AMXCedZXDRNE09Fv7I6 /fO30+ynv/78cK0bFlzVyVVDJu7TX//6+OOjHCdzf+/0l/629YcgICH1kgs/JYK/fAm8i5ovxpsR dMy/EsXVC81uylgC8iWCjzt9ALZWwEgLvi1aoal9aETHYxei8Avio8H5Kcl/Wvy6We+DP3Pc01PS czSnzaQEUgU0p/nm2FYVtqp4ilVFHULoFxHTouLHD/1ioYl+WlNUTr6k8AIKQy94u6TA57J6iSRv rQPAly3gT0Tn+7FbPZKBmIHY/SC262oP23/4zqEoXt3cCQe+U+7stoovCsBf5CXvuibhKUj894uN oF5ZVpylCQYT6GWbwnQtepbcmU5r7p3OcClDfzbPf6L5NlBUQC0C0iocQCiCEcr4yeH74HlcyNfs kMMeO7rhsMPnOMAvXyP+E1/CFkda/3oNQ8mD4zWIAqnkwfHLQrPh0NfGoYUouBM4Yqujt0iEFR4g 335BmJYlwzcc+qo4xKxWcp8coBJ3DNyULwpKFhZzv5W3sJjrVn5x4YCwGB4qF6i7YDNBI8iTfRDE 8JEpsHQLz2bC9hRiKKwbo5eGSnEQsVb0xv4Zaro8EBG5pDQbSARSuaQ0rwu0BoIGgi8EgqJZwm89 F/teGdAaCBoIPgAEmT6Oq6WQBtEgIC3NNqtxh3KiD8XQDN4ljST8FjoDXBX377APmleVUWNHz8HI p6rmZwnv8M3g2kJyGq3V4gEXGHpA6Rbe0GZkAKD9oRloRVc/5aN4+KPjDHX5yqT8A97w6wJQEnFe L/vFNSoBqaIsSBFKfTJIM1QxVHlCVHnOxZVov2io8iaowoiC6tJ0L5zbCe7foSg4RaEoNIjno2MA iQIK+mz31+5QL/WICxkRFpATAi0wzUC/s+Dl/ML1lyzgL89XU+u3DKSSjK5OVA4qCBhdPyakL90O eeYdei0vllIS8msUA1/szIIYEjuz2IiaG7r5Es3zR+QQSuGyAyK/4qKO5oZllFfiV0nQdQPXhzyP jibF88tAmFQEO63oWluKKSWVD9WDgGZ2AeAtVgKpoqP6CKUaAhsCGwIbAhsCGwK/PQILCGizzaqv 38x7gv0UMDMHDzHQNNMADg8ajojaKWG0C0+2guDKr7RQHw6dcmC0orXCqwforqOHZK+12QIqZ2uz O1k/XzfffkZkEE1AwIMI1VVMCsoDOFyI8M+ht3Q5nzSmEbGiUmBtIRFIpVJgGdAa0BrQGtAa0BrQ vi/QStLhXbaeYYfSew+lsn3dJE+KyeZwC8XcyXopP2ALGOGEaWawczqdNB7dncB1joiBduXxBCLN OB/aGQvNpqfDkiq0euAL6WEM5UcXDiLsAy4raAYhfnLa+w89wfAgAc5d+Go9bAEXhtfyNVei+rWX zeoaRIFUEdsqQqlPhsAGzQbNBs0GzQbNBs0HQrOAXDzb3tYvWhAQe2kVw6v0yuIFRELCPj4ESpDo hLlfaFmBL0Dzj/zTmvyy51wLHMCyunORIMJQTTsEHaUQXCFgQFzgAYNGdj706ZD8FvQqiPc2K5Yp zMjNohjVVl1DRFGq48tmdQ2JQKqIQxyh1CfDUwNaA1oDWgNaA1oD2mygFQTAzLaezbuV28OIqBjT weeFoH2VGfEvfN4U6EeEyTXgsMMsKHQxhYwqcPzShU/BAoNv4HkB79dForBW82FfVPuB0RM8w4Ou fa7ojM1gw9CAgTuHGEp3zoMrdBEfFR5SifITX7ZsayhJS61FFNsIpT4ZDhlAGUAZQBlAGUAdD1C1 IK5ittWJr1o9zSLh5bbuKSPhM6qXHzGI/JPzqRV5OBYFES2QBDEjrmYVq0XZVC+r27X1AFJFnLwI pT6Z6TGbZDbJbNJxNonKdOj7PkU2iSIjuXKHtNHwhM0yIpnN/To2NyADA2NiYdAvnO2Q0MtvVPk9 7xFlGHi+662DNA2tNPe8itmhH/mioFb4tB4NCSz6G5C6HgGwv1ZNqOZYShusBFI5lpIhsCGwIbAh 8NMadkPgF3lRr4jAFH3JuVet6EAjCTZp0EDBTELIcsEL170WHE9g887SUhuOJ2Az4QlmQkPVPfND BWzJTLh46uMgtWoWAl1dFpMxqD6pImczXRVV3cXGN5cx/VzyhRjqsppdmCx+6FUOXVXFi9ENoAW8 gEU51GJaxtRF9F3X1XH9pn3RNlXXlRs3aSjafnSadlMHkRB1Puuvi7K/0jbtFh036lagD/4Bz3N8 2zlWF3Z+DVWay7FMe3KhiM0wMf1iHvm6ny9tNU7MakU6CkUVuq6Nfvv629hf6Dajk7jwDV34/NBd GUPoP5fVIGw7d6iPH7u89YUznWQrCvZRfbZove+a/vvazO/1hfPrj0VT+/5tdvc8YI0e8BofoKmu GoqmcmYozFBcNxT1bUMRq9oMxbMYCviA3669ZdLNV4vO/huBm2+2dYnlDgtWeqHnEc8wQE8i9N8o JrWBHh8+ow6MMoMBhHRK00NyCfGl/tCrhSTgDK3Qi+ILuuLdC5o+MDkPnKJQVIAlSXgvH11AVJ8v qdLHAZVeoROsQgRdLOqIAMID8tvC6YOdeUhd6IELV2FMVEHrAo5rHANSRU6iCKUaOho6GjoaOho6 Gjo+Eh2j4Fhitslrd6ByWOAdIYoOvLt6wBHJA4716wdSRaEIEUq1SfXak4rL4+w60flpFHDJL4bK l92brbd5Mn8Nl6NwGQcXl3BOIc4Z7oPmg+FEw/DJ0UzX3AU8Zy5sWICKj4dXnHDQ8qA+FpuW+Xob LkfxEounfcHUxHSMtyK17JDUXwdsD/jkVJhzdkSqaCTqOgYKYpRmGLiBKyBVdM4ToVQDQQNBA0ED QQNBA8EjQFAUJ3QBQe9FIEgxqn34LD7rkB2BaIOLhCrGGEEeLW32HLRV0FVAb/yx+aaz+z40o3NG 53B06Rd1hiEwvTn2+WV+X/1oWo59bl+NfTUv9dW0nCPbV6LacS1V1dU3e2Tjh9stCxyVi3pkppcj vg3FLR2fxf6xT67I0pg/+WK7pRcGindVejWv+aDOgPYWD91uZeRjhBsb+D7glo5/54jEcKuEPcAe 7hRtAz5AKlcN1SDNIM0gzSDNIM0gTQHSqMR9Pu6QKd+svNyqZGSi5EeXdrJgnjNdcDsjJ73iWNF0 M3ygd4C6eFKLCGoyyjQ8RoGJhuCRE0QSeFpCE7kzCNB0wqRbhjYhSq9a2CEEaAgxfKIh/lSUX6HA 8nRwhfLrNUTkAnc3kAikcvn5DGgNaA1oDWgNaA1o3xZoOdJIu0MZi4x6VjSJjifqYdSlHVrLNUnR NE08Fe3Jnf7522n2019/fnTVsOqIp36YXTj99a+PPz7K8S30d05/6W9av0EBL6KrirLxixeYUTkO 8hcgT48Oi+VFHbEIurqo7AQMEte6wjd1ExZvgC/vDfmbvJMVUjIgYtMcUUwF1UuFmMFDhZ1DtjJ8 H6KoaJlW9OjCQHHFQyH+ya/yHjuSjLJGGyCVi6o0DLsDw4jOzYqZFdvdis13dfA4iqfZX7diHAEh lKXIilFhvMHtEBp+RAQTz1zFqYuhC8FOyOWiaJ8Vb3OxVnqlIzJKHEMjxr/B+3yhIv5BRu3jA4o0 PDQeSbF6A3a30AWkeb+YYg3nJy2zcS2Zc8dFBG+QD0jlIoINTw1PDU8NTw1PDU9fHU+p7OTB71BO 50mzH/DqIucdf3iC01TQVv7V8rHpuZfwYueABdULODrnwFeik+VDyNnwkBpmOoVkeUiwgJlO9Xje uHzeEWR5mnmhv3oAEMNlDt9gDJDKZQ435DLkMuQy5DLkMuSSIpcvqazeIeyQJxByn/DXSJ/c4lqj ejn8rp2R+pJjemwGGkjlmB72+rJfH3nEXUsSlPmSO+Juav23B+E2g6dDo+pz+rg1GTFPs564c9j1 6tXg5+DTYSqmvjo6F4IoSSfvAs5wTMPO+bBx5ALGDl29PhRTh+IEmkgr3l3Or7c169XwyUavhEz4 kjywXuMYkEoeWBs6GjoaOho6GjoaOj4VOnLHz7HdYYvOf9gQrfjikc9pbvRsNkxGl0Ese0rIx0+O fCk4Px9yFsFQLAcjIyEJDw2Jg+8cjdWdiagXwRh8/cYDEpM5hG/ZxSNf35jz1CeIiGh0NfljNOTz fZxdvADfyLPvNcABqeTZt8GmwabBpsGmwabB5kvApuMO3rsd0msrWvlDvJuQwkXHnb+9zxWmjYEX eJy2XOuZa7NF5jU6Pddji87RVLQjEBG2gJ0Hngf3WsOuyDiDC6pbowuAj2RCrZEPSCWZUIanhqeG p4anL2fYDU8NT5fIJ6CmXjaSVblHCu+ndLMp2uyHZrPTDMcRlf+5DypxulTon9YjcWO6D4Qx+Gph mBfvsod93JeCbkGTob2COCE3b2hpbgvvyuNJL1gUzLnAhy7BqksoV8GtCunEc/CLhKwMCt6JagH+ 2LJtMAZIFdFGI5RqyGXIZchlyGXIZcgFMUYQRDDbHLkdMmHzSFJDUfSHfQRhXjPPGbR1PPbwadn0 8owf8s5hQjpE/cioVsSn4eahEkLMfUSnRQYFmpzA16rN8HRBQ0sXJcpgLTzS/5aBoXpRB5heAkcX FiXiBxE+IJxwcHQhIuYWiQIYKioSeNn9rUEUSBXRRiOUatBs0GzQbNBs0GzQ/HWhWRQlcYHmUEqg 2V+oqXGQWjXL2m11WUzb5apeVm6riqruYuObi/af7q4QQ90b/vVAhF7l0FVV3L6FdQt4AYtyqMU0 pnURfdd1dVxPTF+0TdV15QYvQ9G6/vHamfPKs6LO6FcXZX+lbdqtzdmoW4E++Ac8z9ht51hd2Hm8 NoUuJK/25EIRm2Fi+sU88nU/X9pqnJjVKnlDKKrQdW1MoHAb+wvdZnQSF76hC5+frStjCP3nshqE bec/gibWohzq/Mww2IqCfVSfLVrvu6b/vjbze33h/Ppj0dS+f5vdLg/YXHvL/qqhaCpnhsIMxXVD EW4biljVr28okFZfw1BQie6qeodgziMuKOauhSF0mnmX4ZaeT/pM5/n1PHGWPyG9MYhgsnLprDaz FUjl0lnZN2DfwCO/ASppTRV3iKZ4m8lKJ+jCc5Jn7z8ywbzivMdJhqHvEmZcuPFhgw+Cy3Kx+SKA VC7LhX1n9p29+XcWBGHx8++sFVFNgyDmcAZn3edZo0MHIHAW4vQa9+XEWHwbcGTp6ic8jS+jLMoB CWv4OiN43tIrwgymKbwAQxaRVjg1/tXPTBQue/nMOtGZfhBlyY9bqfad2Xf2nt8ZFzlRu1L0nQk8 FBc4q/0OpZwVM2NncDherPbYc5oLOveAWQXaKjBaHZEZG0YxwxZ0fugScR80o8p5ZoliRTQoCnKD 6KLJuOoafOd6pdKOSMt9YAgPwFCRP/6CzGsQBVJFXNkIpRo0GzQbNBs0GzQbNH9daBactcy2t2GH ste8Mb8zh9V9bpkj8nVnBKhDm03HLkBQ4ofkSUtr0xh6RKSOJhyLVoyivADwwjPEoe9qmh+ayBtX 0IbLCgTgAWkFk9h5Girx9KHrbeFgGV6rG3nkACJycR4bSExLrURnrRFKNaA1oDWgNaA1oDWgfROg rSiiUF11O6Sk48lnfKVXaIGhueEztpnn8f61AKRBvn2RLLxCgTkU7jtIECUleBcHY0Z0/I0AdcY0 07WXaroPjNPwfdAteD87n2+CVxcPO0z4B/u4FtNXcRTCDVYCqRyF0BDYENgQ2BDYENgQ+OshMBVV Xzd+B6jkfZU8jNFZxHl2EqbiIFtnqKuBunzaO9oHjkVBUOI75x2+fI21+atdlLyCRA6IJDCL+AHY w8MxFKVY0ZlfbxwBGBVciECc1sugl4HT/ITj8/r9fA0RudQdG0gEUrnUHQa0BrQGtAa0BrQGtG8L tFR+oDrWOzCHrPaSAijxKbb4mHHF7PQQ8nnaEh+opBeukxHHo1hKjaZGLUQtEJHO0Z6RPx32AV2r dAjKIRW6bvj4NGAsY3Rh55A/Q0MMZvXAF8WXxdYtqlxx6b42AAekcum+DDYNNg02DTYNNg02XwM2 a0FEyWxb2O6Q4/hOf48MxmCWRJp9gQs/8aY512N3fpdF0zTxVLQnd/rnb6fZT3/9+eFcNaxH2lNX nVw4/fWvjz8+yvGN9rdOf+nvWs8GAZm6F1z4Mji/mA+HhNm8VgqL7ALY4EsVsPd82RarF6M4mnCd dkRhvFuYLfgk/OTZ6n+qWuKbEPAbe8njNxHmI8/PsYxEgXp27c764DK7RmfjdbDGHzxqQUPCi8Jj lWs+wKctyTnofRG7pm1lKAxtD5pJfOr+cwvwSOS57vqRgFTyXNeWK0+xXPky4FOHEHqsmbDnxw89 pvQ4dIaeMhLQIzmzaeqiF7yCHn7pQc84vO7hPxD6TWHyN3pTHj25hy2QF+0WUgLbJXBQxuiLzrvn M/IahjOgeaH4aqC6mgaHr05Al0/mXbuKy7c7/WYyU3uDBAW+IYE7/uKtaModim/YLLZZLJ7FTB/f 9ZZ8MJyJxoWM70PPEbR4USJaVwZbCHp/+XwSdEQRbkFrlVEEnE7pkDHs0FMOGWIw8Qc8aIEefzrx B2yBH1DvHAK/DziIN5KkpDG04er1bEAUSBV4jmc7812g2UyowoIB4ynvxeC97/Thr2KqJ8VUzbyP CPcBXy2cDPCdQzI9T9lAmanezIQSz5HBhoZa8ef6R4A5zU/AxAVaKz7j2REof5Vx3QgO7GabVVft gIiKSELHoxxiHeHWEz45n/xQj/Wkub3lHf68M55PZoFa4KNNepbg56BPAjKKSYgyYS4QEW7y6JwV eJNH04hwaAtSt0LxQTySwFSGeKz00ngo4gKkXD11ZhOAVqI0Tpdt4RqugFRRNb0IpaqAoJk3ZfN2 n5sVPgfegNFH1TyThndJw85hiWzFCccnbuKXGNAPIcsTvUhY/JS1WQKCNEiy9YgTDMNqHbyAtHLo ORxEFTRW/LpAcRfLU5izg5YB+FBFVxsfdzgtRFYFHyMiIgY8RnTwAtLKoQ8b1miuYF16vezzikzh Iw5pFQliBxIQGYg5ogjDTukSF4kJ+c0RvUrn9w4QSRwy5tmRH8+GiAgwHBwShD08Il4lrTZchdEN YgCpXIXRXXDIbNLjbdKdOxp+Z0Yv+OHaA1LnIdAq5to9ZA0F+Y9wSNBqxSEcyrRJXFx7U5Uim8QR 6WorenxIxBjPsIOuBuh94YOP+Oh1xbj9I3YL9BTljRiPaHem5l5cmBux+8Las89ICVF8Vml8NnFE 1ja6D8X6yXhI4Lk4T4Wka25ll0lOo1UkKWtruAJSScqagaCBoIGggaCBoIHgI0CQo5M1O5T+xZ8p /Bqhy4R3SPEH5nSKAGy5YHgsHfuEg4z5YsHQnXHNoxBJpsd6JgGpJNPD5qfNTzCTuNQRTRSVqYsC 3/7MfHY7VASAbkm8LqJHFgcePuVBbUaOHHqm84t9Pnrza62e79uVHRGxC53w5SxGbHnAiVaEGceu kMCjV4TdH7HTOKLAGh8bC4lhkIjE7+P0OGa36N8ArURnxhcMXMMVkCo6S4pQqoGggaCBoIGggaCB 4BEgSJEUYrlD7v2MEmD3xVLfZ9J4GMOJDhTRig5IPyJ0NAPZ6TMgRTYXXlAdQGnWzKUkynkpyvaD o+zg0QKM/dMzmzggnT+GUcxOQB9f8Olz4PvAWsGzE3gMAyEfIuKN47009rQc5WADPkAqRzkwSDNI M0gzSDNIM0hTgDSKQBDdDrnTsdmknX88t4uPO+fLc2HmHE/CU4yGf2Q+aD55Kh/Vr1gN/JD3cTRU zrFHsc4zdLPVSBTOLkPndMMZbG7URyaenE+rhgFcrwB0Rq5XvbJvGQlz+QQBx7mhAVRyFKkNVgKp HEXKENgQ2BDYENgQ2BD46yEwlbsnhh3SiUNnE/SmYSPI19Q4IAPCEXwNTS/tQ5Nq6/GoMYYqptjV K5yVkeKB9+XP5+4ibxwdjoNBSbHINJ3SFcZmYcA4Isn5AYFhOMEf79fl3wcfzXWNkNJy+YE2qASk cvmBDOsM6wzrDOsM6wzr9sQ6QazAbANW7ZG4m2eqwIhKveIOGc4mhFaaZd15r+AjySIY2eEDQnCF FS75DIY8i+SArHyKaVpgHr/FO5eBErR1PDucL9UAgQ8CBh8RAL2CfK0l6HPlE83q8WcyUJf2VT5n qa5bDwgQURCOMN/9rSExLbUTEU0jlGpAa0BrQGtAa0BrQPsmQNsJoiRmW896h3zph9SJeE53IR8L wYc8wCJMB9RH5CtcKhY4fqhLUrFEtefrh4p4WaIgCc0gbp4ZAS/oVeHgfa48LvAsEh4XMEeHh3w+ RJ5m9dyiLQG0EoRVzLeFa7gCUkUM1AilGggaCBoIGggaCBoIHgGCotCGCwjGUgSCFxJofXKhiM0g 1S+khs4VwbcuDOnNPsPlv026hqIKXdfG2Sc7PXZXuBhbV8b1C49FU/umamcfYAQXzppv+/gxqdrY X+iai6jpZVRF3XrX9uNwU9SPidurGkI/nqtvOaFuBTrHD/gNqduCzs/fQF2Eumqr4Na2dfsc8AEd UvdH7qr1hRcbK6xujfr49dyi9b5rYi2YV/DJfwF98G/w2+Lr/4/+3/8Ptq0gpQplbmRzdHJlYW0K ZW5kb2JqCjI4IDAgb2JqCjw8L1R5cGUgL0Fubm90Ci9TdWJ0eXBlIC9MaW5rCi9GIDQKL0JvcmRl ciBbMCAwIDBdCi9SZWN0IFszNDYuMTQ5OTYgNzQyLjQ3NTA0IDQyOS4wOTk5NSA3NDguNzc1MDJd Ci9BIDw8L1R5cGUgL0FjdGlvbgovUyAvVVJJCi9VUkkgKGh0dHA6Ly93d3cudG9vbHMuaWV0Zi5v cmcvdG9vbHMvcmZjZGlmZi8pPj4KL1N0cnVjdFBhcmVudCAxMDAwMTQ+PgplbmRvYmoKMjkgMCBv YmoKPDwvRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDEyMjM+PiBzdHJlYW0KeJztWG2LGzcQ /u5foc+F6DTSjF7gODj77kI/BNpiyA9om4SSKyT9/9BHK+2u1l55z6G9llKbtXdHmtG8v6y2Lg0f ZfB9o5vHkKz6+Xn3ZZdXrAgp5wypr7/u3n+nfgecNfn8kQF3+QREUvn701tVbr5+3N28derjHwO9 SF6REZ/JfRggJm8tN9i6P+5unlhFdfwAQgNvpKzXLI6sKGvV8Xl3awwxLsFlcXlcrt5LvR/+79Tx t93jsUNVgnY2kpup2mAMH3ClAZOMFuvYhSzb8Rd1m1dA98EYgzMYuwXnMBe44JlMpRDL87Df1Hvw KcADSoGNuIDzY4ENcgGXqODIvvzn8/J6/l/DWztzlb8F3cv6mbQeoICiIK7sDFdmxRd1DKq3FW7L xU91nVbYo7pPBhYk6uRjq+b7C/RsFStVFSyNxqS9jcn4pc0uI1mrhShQWiJRlfIwSn5RYRJEn+iL /AZGOsOwlzEi6VOjzIf8iO+XHZHXQ0Qi1MqtGFbWUdSBU1TOeK9jYGli2moCJGF1iPrpqaH1xhsK 2kS3GeRkPGhEjiXKdXLOqfYXeOdA0EAohhgVq/yYUUMFxBnEiQowNKB4vi9Fe0rtbya/ns1+ULe3 N+8O3z8AdHe3fzjAqtCr08HneLYL88IFNXSdM13OlNW+cbBvthlMkmbHptBZMCXzOc1I6zHY2auf 6kK0Nvk24A6dBaFhIYAt6zk2ATJyRSagQLgZo7gjYkGgMEcv4Mp3SPG+dzh3JO+ze9/B6MrBV2tX bI8ruVolvcP77HZN2zVUuBajcvX47jAmqNm7adu7kUZ0MC5X3Jd4t//fu/+r3t0TsO/218fDBV+1 k6/aoJIeXBUlsvVVTgx5kkPqjxCp+GoVaJWm26ZpLWmHziT7P7tK04WqvUTiqbXpvkpmcin26dSb rfboTX2DMflm7n/F87khFq1sj/6UF0K00TRkxAwL6FnYUohnueeco/WDJ4kjWX6JYLVLOyGzBlw9 UO5r2ESU1sWBPCkNvX7wgSJtaE1ch/kaBawNWll0oKdxI0g+XsSdeegKqdizfM/Aubeu5AgdRJ7k /JYVpHf6YRwzCj2nCSOQC3HDHF3eXtvcNGYXQq1pI4pozEfJUjtuTI3UGcb+WlKrHH1DjMc6Yz6N Rg2omQtUniI16ZJ4l/7QOLYFqTaO2wBHJG94fKr0qj+IZgwHsfGHbt7pZ6o2JlycS0atcFkhglnI bvjwX5QJuUrJE0lKOjrYpJGll+MGLJnMxD6u9CQraKOF06xarwXdP/WSB/LKei7250W31qhvmQgx EFp2MDN5afc/d+h8buGg6eCOBOhMZBW4oPBpR4zxGcGBxhDuCvtbWAhHImNgRvZAnsGfl+CgmUMF N0Q64JnIpzL9/hPCemYtZE1cCuud1UgociJsC26kaol0wGfCXj/q513T2D4/zCO/N2jrUfRyq8Ss SCIqhslDLJXB+PVeS2zyuuzZeLtnWwjnptdgV7dO3YVeP7F8rTbmh+hNaoK921v0m45ePuqmzG6p 69fv2Jam05qwVse7Z/QF7LVbdRSCQtHOtU1qo8jsoHbR672KIucXnlEzWtF/Z081voEsBWTrpZZs h1DwDmEYpI2g8yr1J5pVF0oKZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1R5cGUgL1BhZ2UK L1Jlc291cmNlcyA8PC9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJ XQovRXh0R1N0YXRlIDw8L0czIDMgMCBSPj4KL0ZvbnQgPDwvRjQgNCAwIFIKL0Y1IDUgMCBSCi9G NiA2IDAgUgovRjcgNyAwIFIKL0Y4IDggMCBSPj4+PgovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov QW5ub3RzIFs5IDAgUiAxMCAwIFIgMTEgMCBSIDEyIDAgUiAxMyAwIFIgMTQgMCBSIDE1IDAgUiAx NiAwIFJdCi9Db250ZW50cyAxNyAwIFIKL1N0cnVjdFBhcmVudHMgMAovUGFyZW50IDMwIDAgUj4+ CmVuZG9iagoxOCAwIG9iago8PC9UeXBlIC9QYWdlCi9SZXNvdXJjZXMgPDwvUHJvY1NldCBbL1BE RiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0KL0V4dEdTdGF0ZSA8PC9HMyAzIDAgUj4+ Ci9Gb250IDw8L0Y0IDQgMCBSCi9GNSA1IDAgUgovRjYgNiAwIFIKL0Y3IDcgMCBSCi9GOCA4IDAg Uj4+Pj4KL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL0Fubm90cyBbMTkgMCBSIDIwIDAgUiAyMSAw IFIgMjIgMCBSIDIzIDAgUiAyNCAwIFJdCi9Db250ZW50cyAyNSAwIFIKL1N0cnVjdFBhcmVudHMg MQovUGFyZW50IDMwIDAgUj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBlIC9QYWdlCi9SZXNvdXJj ZXMgPDwvUHJvY1NldCBbL1BERiAvVGV4dCAvSW1hZ2VCIC9JbWFnZUMgL0ltYWdlSV0KL0V4dEdT dGF0ZSA8PC9HMyAzIDAgUj4+Ci9Gb250IDw8L0Y0IDQgMCBSCi9GOCA4IDAgUgovRjI3IDI3IDAg Uj4+Pj4KL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL0Fubm90cyBbMjggMCBSXQovQ29udGVudHMg MjkgMCBSCi9TdHJ1Y3RQYXJlbnRzIDIKL1BhcmVudCAzMCAwIFI+PgplbmRvYmoKMzAgMCBvYmoK PDwvVHlwZSAvUGFnZXMKL0NvdW50IDMKL0tpZHMgWzIgMCBSIDE4IDAgUiAyNiAwIFJdPj4KZW5k b2JqCjMxIDAgb2JqCjw8L3BhcnQtMyBbMiAwIFIgL1hZWiAyOS4wNDk5OTcgNDc0LjIwMDA0IDBd Ci9wYXJ0LTQgWzIgMCBSIC9YWVogMjkuMDQ5OTk3IDEwNC42MDAwMzcgMF0KL3BhcnQtMiBbMiAw IFIgL1hZWiAyOS4wNDk5OTcgNjMyLjIyNDk4IDBdCi9wYXJ0LTUgWzE4IDAgUiAvWFlaIDI5LjA0 OTk5NyA1NjYuNjAwMDQgMF0KL3BhcnQtNiBbMTggMCBSIC9YWVogMjkuMDQ5OTk3IDM4MS4yNzUw NSAwXQovcGFydC03IFsxOCAwIFIgL1hZWiAyOS4wNDk5OTcgMjIzLjI1MDA2IDBdPj4KZW5kb2Jq CjM4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAzNyAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMD4+XQovSUQgKG5vZGUwMDAwMDczMCk+Pgpl bmRvYmoKMzcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTGluawovUCAzNiAwIFIKL0sg WzM4IDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogOSAwIFIKL1BnIDIgMCBSPj5dCi9JRCAobm9kZTAw MDAwNzI4KT4+CmVuZG9iagozOSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMzYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE+Pl0KL0lEIChu b2RlMDAwMDA3MzEpPj4KZW5kb2JqCjQxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCA0MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMj4+XQov SUQgKG5vZGUwMDAwMDczMik+PgplbmRvYmoKNDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTGluawovUCAzNiAwIFIKL0sgWzQxIDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogMTAgMCBSCi9Q ZyAyIDAgUj4+XQovSUQgKG5vZGUwMDAwMDcyOSk+PgplbmRvYmoKNDIgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAy IDAgUgovTUNJRCAzPj5dCi9JRCAobm9kZTAwMDAwNzMzKT4+CmVuZG9iagozNiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9USAovUCAzNSAwIFIKL0sgWzM3IDAgUiAzOSAwIFIgNDAgMCBS IDQyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyMjApPj4K ZW5kb2JqCjQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MyAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgND4+XQovSUQgKG5vZGUwMDAwMDcz NCk+PgplbmRvYmoKNDMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEgKL1AgMzUgMCBS Ci9LIFs0NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovU2NvcGUgL0NvbHVtbj4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjIx KT4+CmVuZG9iagozNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzM2IDAgUiA0MyAwIFJdCi9JRCAobm9kZTAwMDAwNDE0KT4+CmVuZG9iago0NyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDYgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDU+Pl0KL0lEIChub2RlMDAwMDA3MzUpPj4KZW5kb2JqCjQ2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ1IDAgUgovSyBbNDcgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2Rl MDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChu b2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjIy KT4+CmVuZG9iago0NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzQ2IDAgUl0KL0lEIChub2RlMDAwMDExNDkpPj4KZW5kb2JqCjUwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0OSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MiAwIFIKL01DSUQgNj4+XQovSUQgKG5vZGUwMDAwMDczNik+PgplbmRvYmoKNDkgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNDggMCBSCi9LIFs1MCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMy MikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAw MjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyMjMpPj4KZW5k b2JqCjUyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MSAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNz4+XQovSUQgKG5vZGUwMDAwMDczNyk+ PgplbmRvYmoKNTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNDggMCBSCi9L IFs1MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUw MDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5v ZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1Myld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDAyMjQpPj4KZW5kb2JqCjU0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA1MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgOD4+ XQovSUQgKG5vZGUwMDAwMDczOCk+PgplbmRvYmoKNTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgNDggMCBSCi9LIFs1NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5 NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyMjUpPj4KZW5kb2JqCjQ4IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNDkgMCBSIDUxIDAgUiA1MyAw IFJdCi9JRCAobm9kZTAwMDAxMTUwKT4+CmVuZG9iago1NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDk+Pl0KL0lEIChub2RlMDAwMDA3MzkpPj4KZW5kb2JqCjU2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDU1IDAgUgovSyBbNTcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjI2KT4+CmVuZG9iago1OSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTggMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEwPj5dCi9JRCAobm9kZTAwMDAwNzQwKT4+CmVuZG9i ago1OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA1NSAwIFIKL0sgWzU5IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDIyNyk+PgplbmRvYmoKNjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDYwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMT4+XQovSUQg KG5vZGUwMDAwMDc0MSk+PgplbmRvYmoKNjAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgNTUgMCBSCi9LIFs2MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5v ZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyMjgpPj4KZW5kb2JqCjU1IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTYgMCBSIDU4IDAgUiA2MCAwIFJdCi9J RCAobm9kZTAwMDAxMTUxKT4+CmVuZG9iago2NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgNjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEy Pj5dCi9JRCAobm9kZTAwMDAwNzQyKT4+CmVuZG9iago2MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCA2MiAwIFIKL0sgWzY0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAx MjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDIyOSk+PgplbmRvYmoKNjYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY1IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAxMz4+XQovSUQgKG5vZGUwMDAwMDc0Myk+PgplbmRvYmoKNjUg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjIgMCBSCi9LIFs2NiAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5v ZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkg KG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAy MzApPj4KZW5kb2JqCjY4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA2NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTQ+Pl0KL0lEIChub2Rl MDAwMDA3NDQpPj4KZW5kb2JqCjY3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDYyIDAgUgovSyBbNjggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAw MDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwMjMxKT4+CmVuZG9iago2MiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzYzIDAgUiA2NSAwIFIgNjcgMCBSXQovSUQgKG5v ZGUwMDAwMTE1Mik+PgplbmRvYmoKNzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDcwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNT4+XQov SUQgKG5vZGUwMDAwMDc0NSk+PgplbmRvYmoKNzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDcwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAx Nj4+XQovSUQgKG5vZGUwMDAwMDc0Nyk+PgplbmRvYmoKNzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDcwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgov TUNJRCAxNz4+XQovSUQgKG5vZGUwMDAwMDc0OCk+PgplbmRvYmoKNzAgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgNjkgMCBSCi9LIFs3MSAwIFIgNzIgMCBSIDczIDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9k ZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAo bm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDIz Mik+PgplbmRvYmoKNzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDc0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxOD4+XQovSUQgKG5vZGUw MDAwMDc0OSk+PgplbmRvYmoKNzQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag NjkgMCBSCi9LIFs3NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0 NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAw MTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAyMzMpPj4KZW5kb2JqCjc3IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA3NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIK L01DSUQgMTk+Pl0KL0lEIChub2RlMDAwMDA3NTApPj4KZW5kb2JqCjc4IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MiAwIFIKL01DSUQgMjA+Pl0KL0lEIChub2RlMDAwMDA3NTIpPj4KZW5kb2JqCjc5IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3NiAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMiAwIFIKL01DSUQgMjE+Pl0KL0lEIChub2RlMDAwMDA3NTMpPj4KZW5kb2JqCjc2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDY5IDAgUgovSyBbNzcgMCBSIDc4IDAg UiA3OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUw MDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5v ZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDAyMzQpPj4KZW5kb2JqCjY5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RSCi9QIDM0IDAgUgovSyBbNzAgMCBSIDc0IDAgUiA3NiAwIFJdCi9JRCAobm9kZTAwMDAxMTU1 KT4+CmVuZG9iago4MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag ODEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIyPj5dCi9JRCAobm9kZTAw MDAwNzU0KT4+CmVuZG9iago4MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4 MCAwIFIKL0sgWzgyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIw KSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAx NTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDIzNSk+PgplbmRvYmoKODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDgzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgov TUNJRCAyMz4+XQovSUQgKG5vZGUwMDAwMDc1NSk+PgplbmRvYmoKODMgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgODAgMCBSCi9LIFs4NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5v ZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyMzYpPj4KZW5kb2JqCjg2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4NSAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQ+Pl0KL0lEIChub2RlMDAwMDA3NTYpPj4KZW5k b2JqCjg1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgwIDAgUgovSyBbODYg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAy NjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAw MDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAwMjM3KT4+CmVuZG9iago4MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgov UCAzNCAwIFIKL0sgWzgxIDAgUiA4MyAwIFIgODUgMCBSXQovSUQgKG5vZGUwMDAwMTE1Nik+Pgpl bmRvYmoKODkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDg4IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyNT4+XQovSUQgKG5vZGUwMDAwMDc1 Nyk+PgplbmRvYmoKOTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDg4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyNj4+XQovSUQgKG5vZGUw MDAwMDc1OSk+PgplbmRvYmoKOTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDg4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyNz4+XQovSUQg KG5vZGUwMDAwMDc2MCk+PgplbmRvYmoKODggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgODcgMCBSCi9LIFs4OSAwIFIgOTAgMCBSIDkxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9k ZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDIzOCk+PgplbmRvYmoKOTMg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDkyIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyOD4+XQovSUQgKG5vZGUwMDAwMDc2MSk+PgplbmRv YmoKOTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODcgMCBSCi9LIFs5MyAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3 MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAw MTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDAyMzkpPj4KZW5kb2JqCjk1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA5NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjk+Pl0KL0lE IChub2RlMDAwMDA3NjIpPj4KZW5kb2JqCjk2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA5NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzA+ Pl0KL0lEIChub2RlMDAwMDA3NjQpPj4KZW5kb2JqCjk3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA5NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMzE+Pl0KL0lEIChub2RlMDAwMDA3NjUpPj4KZW5kb2JqCjk0IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDg3IDAgUgovSyBbOTUgMCBSIDk2IDAgUiA5NyAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNDAp Pj4KZW5kb2JqCjg3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgov SyBbODggMCBSIDkyIDAgUiA5NCAwIFJdCi9JRCAobm9kZTAwMDAxMTU5KT4+CmVuZG9iagoxMDAg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk5IDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMj4+XQovSUQgKG5vZGUwMDAwMDc2Nik+PgplbmRv YmoKOTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTggMCBSCi9LIFsxMDAg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDEx NzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAw MDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAwMjQxKT4+CmVuZG9iago5OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgov UCAzNCAwIFIKL0sgWzk5IDAgUl0KL0lEIChub2RlMDAwMDExNjApPj4KZW5kb2JqCjEwMyAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAyIDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMz4+XQovSUQgKG5vZGUwMDAwMDc2Nyk+PgplbmRvYmoK MTAyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMSAwIFIKL0sgWzEwMyAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2 NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAw MTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDAyNDIpPj4KZW5kb2JqCjEwNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgMTA0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzND4+XQov SUQgKG5vZGUwMDAwMDc2OCk+PgplbmRvYmoKMTA0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDEwMSAwIFIKL0sgWzEwNSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5 NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNDMpPj4KZW5kb2JqCjEwNyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA2IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAzNT4+XQovSUQgKG5vZGUwMDAwMDc2OSk+PgplbmRvYmoKMTA2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMSAwIFIKL0sgWzEwNyAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2Nykg KG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgy MCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDAyNDQpPj4KZW5kb2JqCjEwMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAz NCAwIFIKL0sgWzEwMiAwIFIgMTA0IDAgUiAxMDYgMCBSXQovSUQgKG5vZGUwMDAwMTE2MSk+Pgpl bmRvYmoKMTEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDkg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDM2Pj5dCi9JRCAobm9kZTAwMDAw NzcwKT4+CmVuZG9iagoxMDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA4 IDAgUgovSyBbMTEwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIw KSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAx NTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDI0NSk+PgplbmRvYmoKMTEyIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDM3Pj5dCi9JRCAobm9kZTAwMDAwNzcxKT4+CmVuZG9iagoxMTEgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA4IDAgUgovSyBbMTEyIDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5 KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAy MDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI0Nik+PgplbmRv YmoKMTE0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTMgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDM4Pj5dCi9JRCAobm9kZTAwMDAwNzcy KT4+CmVuZG9iagoxMTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA4IDAg UgovSyBbMTE0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAo bm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0 KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMDI0Nyk+PgplbmRvYmoKMTA4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA5IDAgUiAxMTEgMCBSIDExMyAwIFJdCi9JRCAobm9k ZTAwMDAxMTYyKT4+CmVuZG9iagoxMTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDExNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzk+Pl0K L0lEIChub2RlMDAwMDA3NzMpPj4KZW5kb2JqCjExNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMTUgMCBSCi9LIFsxMTcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEy OTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjQ4KT4+CmVuZG9iagoxMTUgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMTYgMCBSXQovSUQgKG5v ZGUwMDAwMTE2Myk+PgplbmRvYmoKMTIwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxMTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDQwPj5d Ci9JRCAobm9kZTAwMDAwNzc0KT4+CmVuZG9iagoxMTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgMTE4IDAgUgovSyBbMTIwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAx MjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI0OSk+PgplbmRvYmoKMTIyIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjEgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDQxPj5dCi9JRCAobm9kZTAwMDAwNzc1KT4+CmVuZG9iagox MjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTE4IDAgUgovSyBbMTIyIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDI1MCk+PgplbmRvYmoKMTI0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxMjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDQyPj5dCi9J RCAobm9kZTAwMDAwNzc2KT4+CmVuZG9iagoxMjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgMTE4IDAgUgovSyBbMTI0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI1MSk+PgplbmRvYmoKMTE4IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTE5IDAgUiAxMjEgMCBSIDEy MyAwIFJdCi9JRCAobm9kZTAwMDAxMTY0KT4+CmVuZG9iagoxMjcgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgNDM+Pl0KL0lEIChub2RlMDAwMDA3NzcpPj4KZW5kb2JqCjEyNiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjUgMCBSCi9LIFsxMjcgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjUyKT4+CmVu ZG9iagoxMjUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsx MjYgMCBSXQovSUQgKG5vZGUwMDAwMTE2NSk+PgplbmRvYmoKMTMwIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDQ0Pj5dCi9JRCAobm9kZTAwMDAwNzc4KT4+CmVuZG9iagoxMjkgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI4IDAgUgovSyBbMTMwIDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAw MzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAw MDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI1Myk+Pgpl bmRvYmoKMTMyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzEg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDQ1Pj5dCi9JRCAobm9kZTAwMDAw Nzc5KT4+CmVuZG9iagoxMzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI4 IDAgUgovSyBbMTMyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDI1NCk+PgplbmRvYmoKMTM0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDQ2Pj5dCi9JRCAobm9kZTAwMDAwNzgwKT4+CmVuZG9iagoxMzMgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI4IDAgUgovSyBbMTM0IDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIz KSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAy MDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI1NSk+PgplbmRv YmoKMTI4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTI5 IDAgUiAxMzEgMCBSIDEzMyAwIFJdCi9JRCAobm9kZTAwMDAxMTY2KT4+CmVuZG9iagoxMzcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzNiAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNDc+Pl0KL0lEIChub2RlMDAwMDA3ODEpPj4KZW5kb2Jq CjEzNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzUgMCBSCi9LIFsxMzcg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAy NjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAw MDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAwMjU2KT4+CmVuZG9iagoxMzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEzOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNDg+Pl0K L0lEIChub2RlMDAwMDA3ODIpPj4KZW5kb2JqCjEzOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMzUgMCBSCi9LIFsxMzkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEy OTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjU3KT4+CmVuZG9iagoxNDEgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE0MCAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgNDk+Pl0KL0lEIChub2RlMDAwMDA3ODMpPj4KZW5kb2JqCjE0 MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzUgMCBSCi9LIFsxNDEgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcp IChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4 MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMjU4KT4+CmVuZG9iagoxMzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1Ag MzQgMCBSCi9LIFsxMzYgMCBSIDEzOCAwIFIgMTQwIDAgUl0KL0lEIChub2RlMDAwMDExNjcpPj4K ZW5kb2JqCjE0NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQz IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA1MD4+XQovSUQgKG5vZGUwMDAw MDc4NCk+PgplbmRvYmoKMTQzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0 MiAwIFIKL0sgWzE0NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAw MTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAyNTkpPj4KZW5kb2JqCjE0NiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAg UgovTUNJRCA1MT4+XQovSUQgKG5vZGUwMDAwMDc4NSk+PgplbmRvYmoKMTQ1IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0MiAwIFIKL0sgWzE0NiAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5 OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAw MjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNjApPj4KZW5k b2JqCjE0OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ3IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA1Mj4+XQovSUQgKG5vZGUwMDAwMDc4 Nik+PgplbmRvYmoKMTQ3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0MiAw IFIKL0sgWzE0OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkg KG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4 NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDAyNjEpPj4KZW5kb2JqCjE0MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0MyAwIFIgMTQ1IDAgUiAxNDcgMCBSXQovSUQgKG5v ZGUwMDAwMTE2OCk+PgplbmRvYmoKMTUxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxNTAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDUzPj5d Ci9JRCAobm9kZTAwMDAwNzg3KT4+CmVuZG9iagoxNTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgMTQ5IDAgUgovSyBbMTUxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAx MjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI2Mik+PgplbmRvYmoKMTUzIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNTIgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDU0Pj5dCi9JRCAobm9kZTAwMDAwNzg4KT4+CmVuZG9iagox NTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTQ5IDAgUgovSyBbMTUzIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDI2Myk+PgplbmRvYmoKMTU1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxNTQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDU1Pj5dCi9J RCAobm9kZTAwMDAwNzg5KT4+CmVuZG9iagoxNTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgMTQ5IDAgUgovSyBbMTU1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI2NCk+PgplbmRvYmoKMTQ5IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTUwIDAgUiAxNTIgMCBSIDE1 NCAwIFJdCi9JRCAobm9kZTAwMDAxMTY5KT4+CmVuZG9iagoxNTggMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE1NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgNTY+Pl0KL0lEIChub2RlMDAwMDA3OTApPj4KZW5kb2JqCjE1NyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNTYgMCBSCi9LIFsxNTggMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjY1KT4+CmVu ZG9iagoxNTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsx NTcgMCBSXQovSUQgKG5vZGUwMDAwMTE3MCk+PgplbmRvYmoKMTYxIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNjAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDU3Pj5dCi9JRCAobm9kZTAwMDAwNzkyKT4+CmVuZG9iagoxNjMgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE2MiAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMiAwIFIKL01DSUQgNTg+Pl0KL0lEIChub2RlMDAwMDA3OTMpPj4KZW5kb2JqCjE2MiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9MaW5rCi9QIDE2MCAwIFIKL0sgWzE2MyAwIFIg PDwvVHlwZSAvT0JKUgovT2JqIDExIDAgUgovUGcgMiAwIFI+Pl0KL0lEIChub2RlMDAwMDA3OTEp Pj4KZW5kb2JqCjE2MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9USAovUCAxNTkgMCBS Ci9LIFsxNjEgMCBSIDE2MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovU2NvcGUgL0NvbHVtbj4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAwMjY2KT4+CmVuZG9iagoxNjUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDE2NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNTk+Pl0K L0lEIChub2RlMDAwMDA3OTUpPj4KZW5kb2JqCjE2NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTY2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJ RCA2MD4+XQovSUQgKG5vZGUwMDAwMDc5Nik+PgplbmRvYmoKMTY2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL0xpbmsKL1AgMTY0IDAgUgovSyBbMTY3IDAgUiA8PC9UeXBlIC9PQkpSCi9P YmogMTIgMCBSCi9QZyAyIDAgUj4+XQovSUQgKG5vZGUwMDAwMDc5NCk+PgplbmRvYmoKMTY0IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RICi9QIDE1OSAwIFIKL0sgWzE2NSAwIFIgMTY2 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNjcpPj4KZW5k b2JqCjE1OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE2 MCAwIFIgMTY0IDAgUl0KL0lEIChub2RlMDAwMDA0MTUpPj4KZW5kb2JqCjE3MCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTY5IDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAyIDAgUgovTUNJRCA2MT4+XQovSUQgKG5vZGUwMDAwMDc5Nyk+PgplbmRvYmoKMTY5IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE2OCAwIFIKL0sgWzE3MCAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5v ZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkg KG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAy NjgpPj4KZW5kb2JqCjE3MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMTcxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA2Mj4+XQovSUQgKG5v ZGUwMDAwMDc5OCk+PgplbmRvYmoKMTcxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDE2OCAwIFIKL0sgWzE3MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNjkpPj4KZW5kb2JqCjE3NCAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTczIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCA2Mz4+XQovSUQgKG5vZGUwMDAwMDc5OSk+PgplbmRvYmoKMTczIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE2OCAwIFIKL0sgWzE3NCAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNzAp Pj4KZW5kb2JqCjE2OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzE2OSAwIFIgMTcxIDAgUiAxNzMgMCBSXQovSUQgKG5vZGUwMDAwMTE3NCk+PgplbmRvYmoK MTc3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNzYgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDY0Pj5dCi9JRCAobm9kZTAwMDAwODAwKT4+ CmVuZG9iagoxNzYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTc1IDAgUgov SyBbMTc3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9k ZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAo bm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUx KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMDI3MSk+PgplbmRvYmoKMTc5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCAxNzggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDY1Pj5dCi9JRCAobm9kZTAwMDAwODAxKT4+CmVuZG9iagoxNzggMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMTc1IDAgUgovSyBbMTc5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9k ZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI3Mik+PgplbmRvYmoKMTgx IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxODAgMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDY2Pj5dCi9JRCAobm9kZTAwMDAwODAyKT4+CmVu ZG9iagoxODAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTc1IDAgUgovSyBb MTgxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAw MDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9k ZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMDI3Myk+PgplbmRvYmoKMTc1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RSCi9QIDM0IDAgUgovSyBbMTc2IDAgUiAxNzggMCBSIDE4MCAwIFJdCi9JRCAobm9kZTAwMDAx MTc1KT4+CmVuZG9iagoxODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDE4MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNjc+Pl0KL0lEIChu b2RlMDAwMDA4MDMpPj4KZW5kb2JqCjE4MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxODIgMCBSCi9LIFsxODQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjc0KT4+CmVuZG9iagoxODYgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE4NSAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgNjg+Pl0KL0lEIChub2RlMDAwMDA4MDQpPj4KZW5kb2JqCjE4NSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxODIgMCBSCi9LIFsxODYgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2Rl MDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChu b2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjc1 KT4+CmVuZG9iagoxODggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDE4NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgNjk+Pl0KL0lEIChub2Rl MDAwMDA4MDUpPj4KZW5kb2JqCjE4NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxODIgMCBSCi9LIFsxODggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2Rl MDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjc2KT4+CmVuZG9iagoxODIgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxODMgMCBSIDE4NSAwIFIgMTg3IDAgUl0K L0lEIChub2RlMDAwMDExNzYpPj4KZW5kb2JqCjE5MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTkwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJ RCA3MD4+XQovSUQgKG5vZGUwMDAwMDgwNik+PgplbmRvYmoKMTkwIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDE4OSAwIFIKL0sgWzE5MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5v ZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNzcpPj4KZW5kb2JqCjE5 MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTkyIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA3MT4+XQovSUQgKG5vZGUwMDAwMDgwNyk+Pgpl bmRvYmoKMTkyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE4OSAwIFIKL0sg WzE5MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUw MDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5v ZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1Myld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDAyNzgpPj4KZW5kb2JqCjE5NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTk0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA3 Mj4+XQovSUQgKG5vZGUwMDAwMDgwOCk+PgplbmRvYmoKMTk0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDE4OSAwIFIKL0sgWzE5NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyNzkpPj4KZW5kb2JqCjE4OSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE5MCAwIFIgMTky IDAgUiAxOTQgMCBSXQovSUQgKG5vZGUwMDAwMTE3Nyk+PgplbmRvYmoKMTk4IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxOTcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDczPj5dCi9JRCAobm9kZTAwMDAwODA5KT4+CmVuZG9iagoxOTcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTk2IDAgUgovSyBbMTk4IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI4 MCk+PgplbmRvYmoKMTk2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAg UgovSyBbMTk3IDAgUl0KL0lEIChub2RlMDAwMDExNzgpPj4KZW5kb2JqCjIwMSAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjAwIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAyIDAgUgovTUNJRCA3ND4+XQovSUQgKG5vZGUwMDAwMDgxMCk+PgplbmRvYmoKMjAwIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE5OSAwIFIKL0sgWzIwMSAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5v ZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkg KG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAy ODEpPj4KZW5kb2JqCjIwMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMjAyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA3NT4+XQovSUQgKG5v ZGUwMDAwMDgxMSk+PgplbmRvYmoKMjAyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDE5OSAwIFIKL0sgWzIwMyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyODIpPj4KZW5kb2JqCjIwNSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjA0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCA3Nj4+XQovSUQgKG5vZGUwMDAwMDgxMik+PgplbmRvYmoKMjA0IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE5OSAwIFIKL0sgWzIwNSAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyODMp Pj4KZW5kb2JqCjE5OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzIwMCAwIFIgMjAyIDAgUiAyMDQgMCBSXQovSUQgKG5vZGUwMDAwMTE3OSk+PgplbmRvYmoK MjA4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyMDcgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDc3Pj5dCi9JRCAobm9kZTAwMDAwODEzKT4+ CmVuZG9iagoyMDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjA2IDAgUgov SyBbMjA4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9k ZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAo bm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUx KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMDI4NCk+PgplbmRvYmoKMjEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCAyMDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDc4Pj5dCi9JRCAobm9kZTAwMDAwODE0KT4+CmVuZG9iagoyMDkgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMjA2IDAgUgovSyBbMjEwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9k ZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI4NSk+PgplbmRvYmoKMjEy IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyMTEgMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDc5Pj5dCi9JRCAobm9kZTAwMDAwODE1KT4+CmVu ZG9iagoyMTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjA2IDAgUgovSyBb MjEyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAw MDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9k ZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMDI4Nik+PgplbmRvYmoKMjA2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RSCi9QIDM0IDAgUgovSyBbMjA3IDAgUiAyMDkgMCBSIDIxMSAwIFJdCi9JRCAobm9kZTAwMDAx MTgwKT4+CmVuZG9iagoyMTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDIxNCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgODA+Pl0KL0lEIChu b2RlMDAwMDA4MTYpPj4KZW5kb2JqCjIxNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAyMTMgMCBSCi9LIFsyMTUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjg3KT4+CmVuZG9iagoyMTcgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDIxNiAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgODE+Pl0KL0lEIChub2RlMDAwMDA4MTcpPj4KZW5kb2JqCjIxNiAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyMTMgMCBSCi9LIFsyMTcgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2Rl MDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChu b2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjg4 KT4+CmVuZG9iagoyMTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDIxOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgODI+Pl0KL0lEIChub2Rl MDAwMDA4MTgpPj4KZW5kb2JqCjIxOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAyMTMgMCBSCi9LIFsyMTkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2Rl MDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjg5KT4+CmVuZG9iagoyMTMgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsyMTQgMCBSIDIxNiAwIFIgMjE4IDAgUl0K L0lEIChub2RlMDAwMDExODEpPj4KZW5kb2JqCjIyMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMjIxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJ RCA4Mz4+XQovSUQgKG5vZGUwMDAwMDgxOSk+PgplbmRvYmoKMjIxIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDIyMCAwIFIKL0sgWzIyMiAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5v ZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyOTApPj4KZW5kb2JqCjIy NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjIzIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA4ND4+XQovSUQgKG5vZGUwMDAwMDgyMCk+Pgpl bmRvYmoKMjIzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDIyMCAwIFIKL0sg WzIyNCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUw MDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5v ZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1Myld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDAyOTEpPj4KZW5kb2JqCjIyNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMjI1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA4 NT4+XQovSUQgKG5vZGUwMDAwMDgyMSk+PgplbmRvYmoKMjI1IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDIyMCAwIFIKL0sgWzIyNiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAyOTIpPj4KZW5kb2JqCjIyMCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzIyMSAwIFIgMjIz IDAgUiAyMjUgMCBSXQovSUQgKG5vZGUwMDAwMTE4Mik+PgplbmRvYmoKMjI5IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyMjggMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDg2Pj5dCi9JRCAobm9kZTAwMDAwODIyKT4+CmVuZG9iagoyMjggMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjI3IDAgUgovSyBbMjI5IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI5 Myk+PgplbmRvYmoKMjI3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAg UgovSyBbMjI4IDAgUl0KL0lEIChub2RlMDAwMDExODMpPj4KZW5kb2JqCjIzMiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjMxIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAyIDAgUgovTUNJRCA4Nz4+XQovSUQgKG5vZGUwMDAwMDgyMyk+PgplbmRvYmoKMjMzIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyMzEgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDg4Pj5dCi9JRCAobm9kZTAwMDAwODI1KT4+CmVuZG9i agoyMzQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDIzMSAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgODk+Pl0KL0lEIChub2RlMDAwMDA4MjYp Pj4KZW5kb2JqCjIzMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyMzAgMCBS Ci9LIFsyMzIgMCBSIDIzMyAwIFIgMjM0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkz KSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDI5NCk+PgplbmRvYmoKMjM2IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyMzUgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDkwPj5dCi9JRCAobm9kZTAwMDAwODI3KT4+CmVuZG9iagoyMzUg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjMwIDAgUgovSyBbMjM2IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAo bm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5 KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MDI5NSk+PgplbmRvYmoKMjM4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCAyMzcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDkxPj5dCi9JRCAo bm9kZTAwMDAwODI4KT4+CmVuZG9iagoyMzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDIzNyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgOTI+ Pl0KL0lEIChub2RlMDAwMDA4MzApPj4KZW5kb2JqCjI0MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjM3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgov TUNJRCA5Mz4+XQovSUQgKG5vZGUwMDAwMDgzMSk+PgplbmRvYmoKMjM3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDIzMCAwIFIKL0sgWzIzOCAwIFIgMjM5IDAgUiAyNDAgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcp IChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4 MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMjk2KT4+CmVuZG9iagoyMzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1Ag MzQgMCBSCi9LIFsyMzEgMCBSIDIzNSAwIFIgMjM3IDAgUl0KL0lEIChub2RlMDAwMDExODYpPj4K ZW5kb2JqCjI0MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjQy IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA5ND4+XQovSUQgKG5vZGUwMDAw MDgzMik+PgplbmRvYmoKMjQyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDI0 MSAwIFIKL0sgWzI0MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0 NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAw MTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAyOTcpPj4KZW5kb2JqCjI0MSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzI0MiAwIFJdCi9JRCAobm9kZTAwMDAxMTg3KT4+ CmVuZG9iagoyNDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI0 NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgOTU+Pl0KL0lEIChub2RlMDAw MDA4MzMpPj4KZW5kb2JqCjI0NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAy NDQgMCBSCi9LIFsyNDYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAw MDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwMjk4KT4+CmVuZG9iagoyNDggMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI0NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgOTY+Pl0KL0lEIChub2RlMDAwMDA4MzQpPj4KZW5kb2JqCjI0NyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyNDQgMCBSCi9LIFsyNDggMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMjk5KT4+CmVu ZG9iagoyNTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI0OSAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgOTc+Pl0KL0lEIChub2RlMDAwMDA4 MzUpPj4KZW5kb2JqCjI0OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyNDQg MCBSCi9LIFsyNTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEp IChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1 ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAw MDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAx Pj5dCi9JRCAobm9kZTAwMDAwMzAwKT4+CmVuZG9iagoyNDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsyNDUgMCBSIDI0NyAwIFIgMjQ5IDAgUl0KL0lEIChu b2RlMDAwMDExODgpPj4KZW5kb2JqCjI1MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgMjUyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCA5OD4+ XQovSUQgKG5vZGUwMDAwMDgzNik+PgplbmRvYmoKMjUyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDI1MSAwIFIKL0sgWzI1MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAw MTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMDEpPj4KZW5kb2JqCjI1MSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzI1MiAwIFJdCi9JRCAo bm9kZTAwMDAxMTg5KT4+CmVuZG9iagoyNTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDI1NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgOTk+ Pl0KL0lEIChub2RlMDAwMDA4MzcpPj4KZW5kb2JqCjI1NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCAyNTQgMCBSCi9LIFsyNTYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAw MDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzAyKT4+CmVuZG9iagoyNTggMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI1NyAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTAwPj5dCi9JRCAobm9kZTAwMDAwODM4KT4+CmVuZG9i agoyNTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjU0IDAgUgovSyBbMjU4 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAx MTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAw MDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMDMwMyk+PgplbmRvYmoKMjYwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAyNTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEwMT4+ XQovSUQgKG5vZGUwMDAwMDgzOSk+PgplbmRvYmoKMjU5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDI1NCAwIFIKL0sgWzI2MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAw MTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMDQpPj4KZW5kb2JqCjI1NCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzI1NSAwIFIgMjU3IDAg UiAyNTkgMCBSXQovSUQgKG5vZGUwMDAwMTE5MCk+PgplbmRvYmoKMjYzIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyNjIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDEwMj4+XQovSUQgKG5vZGUwMDAwMDg0MCk+PgplbmRvYmoKMjYyIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDI2MSAwIFIKL0sgWzI2MyAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUw MDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5v ZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMDUp Pj4KZW5kb2JqCjI2NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MjY0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMDM+Pl0KL0lEIChub2Rl MDAwMDA4NDEpPj4KZW5kb2JqCjI2NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAyNjEgMCBSCi9LIFsyNjUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2Rl MDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzA2KT4+CmVuZG9iagoyNjcgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI2NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MiAwIFIKL01DSUQgMTA0Pj5dCi9JRCAobm9kZTAwMDAwODQyKT4+CmVuZG9iagoyNjYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjYxIDAgUgovSyBbMjY3IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAw MDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9k ZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMwNyk+ PgplbmRvYmoKMjYxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgov SyBbMjYyIDAgUiAyNjQgMCBSIDI2NiAwIFJdCi9JRCAobm9kZTAwMDAxMTkxKT4+CmVuZG9iagoy NzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI2OSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTA1Pj5dCi9JRCAobm9kZTAwMDAwODQzKT4+ CmVuZG9iagoyNjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjY4IDAgUgov SyBbMjcwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9k ZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAo bm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUz KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMDMwOCk+PgplbmRvYmoKMjY4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RSCi9QIDM0IDAgUgovSyBbMjY5IDAgUl0KL0lEIChub2RlMDAwMDExOTIpPj4KZW5kb2Jq CjI3MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjcyIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMDY+Pl0KL0lEIChub2RlMDAwMDA4NDQp Pj4KZW5kb2JqCjI3MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyNzEgMCBS Ci9LIFsyNzMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChu b2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1Nzkp IChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAwMzA5KT4+CmVuZG9iagoyNzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDI3NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMTA3Pj5dCi9JRCAobm9kZTAwMDAwODQ1KT4+CmVuZG9iagoyNzQgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMjcxIDAgUgovSyBbMjc1IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAo bm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMxMCk+PgplbmRvYmoK Mjc3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyNzYgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEwOD4+XQovSUQgKG5vZGUwMDAwMDg0Nik+ PgplbmRvYmoKMjc2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDI3MSAwIFIK L0sgWzI3NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5v ZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkg KG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDAzMTEpPj4KZW5kb2JqCjI3MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9UUgovUCAzNCAwIFIKL0sgWzI3MiAwIFIgMjc0IDAgUiAyNzYgMCBSXQovSUQgKG5vZGUw MDAwMTE5Myk+PgplbmRvYmoKMjgwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAyNzkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEwOT4+XQov SUQgKG5vZGUwMDAwMDg0Nyk+PgplbmRvYmoKMjc5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDI3OCAwIFIKL0sgWzI4MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5 MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMTIpPj4KZW5kb2JqCjI4MiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjgxIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAxMTA+Pl0KL0lEIChub2RlMDAwMDA4NDgpPj4KZW5kb2JqCjI4 MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyNzggMCBSCi9LIFsyODIgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMzEzKT4+CmVuZG9iagoyODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDI4MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTExPj5dCi9J RCAobm9kZTAwMDAwODQ5KT4+CmVuZG9iagoyODMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgMjc4IDAgUgovSyBbMjg0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMxNCk+PgplbmRvYmoKMjc4IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMjc5IDAgUiAyODEgMCBSIDI4 MyAwIFJdCi9JRCAobm9kZTAwMDAxMTk0KT4+CmVuZG9iagoyODcgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDI4NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMTEyPj5dCi9JRCAobm9kZTAwMDAwODUwKT4+CmVuZG9iagoyODYgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMjg1IDAgUgovSyBbMjg3IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAw MzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAw MDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMxNSk+Pgpl bmRvYmoKMjg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyODgg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDExMz4+XQovSUQgKG5vZGUwMDAw MDg1MSk+PgplbmRvYmoKMjg4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDI4 NSAwIFIKL0sgWzI4OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0 NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAw MTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAzMTYpPj4KZW5kb2JqCjI5MSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjkwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAg UgovTUNJRCAxMTQ+Pl0KL0lEIChub2RlMDAwMDA4NTIpPj4KZW5kb2JqCjI5MCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyODUgMCBSCi9LIFsyOTEgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAz MjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAw MDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzE3KT4+CmVu ZG9iagoyODUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsy ODYgMCBSIDI4OCAwIFIgMjkwIDAgUl0KL0lEIChub2RlMDAwMDExOTUpPj4KZW5kb2JqCjI5NCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMjkzIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMTU+Pl0KL0lEIChub2RlMDAwMDA4NTMpPj4KZW5k b2JqCjI5MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAyOTIgMCBSCi9LIFsy OTQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAw MDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2Rl MDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAwMzE4KT4+CmVuZG9iagoyOTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDI5NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTE2 Pj5dCi9JRCAobm9kZTAwMDAwODU0KT4+CmVuZG9iagoyOTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMjkyIDAgUgovSyBbMjk2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMxOSk+PgplbmRvYmoKMjk4IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAyOTcgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDExNz4+XQovSUQgKG5vZGUwMDAwMDg1NSk+PgplbmRv YmoKMjk3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDI5MiAwIFIKL0sgWzI5 OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAw MDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUw MDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDAzMjApPj4KZW5kb2JqCjI5MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U UgovUCAzNCAwIFIKL0sgWzI5MyAwIFIgMjk1IDAgUiAyOTcgMCBSXQovSUQgKG5vZGUwMDAwMTE5 Nik+PgplbmRvYmoKMzAxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCAzMDAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDExOD4+XQovSUQgKG5v ZGUwMDAwMDg1Nik+PgplbmRvYmoKMzAwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDI5OSAwIFIKL0sgWzMwMSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMjEpPj4KZW5kb2JqCjI5OSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzMwMCAwIFJdCi9JRCAobm9kZTAwMDAx MTk3KT4+CmVuZG9iagozMDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDMwMyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTE5Pj5dCi9JRCAo bm9kZTAwMDAwODU4KT4+CmVuZG9iagozMDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDMwNSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTIw Pj5dCi9JRCAobm9kZTAwMDAwODU5KT4+CmVuZG9iagozMDUgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTGluawovUCAzMDMgMCBSCi9LIFszMDYgMCBSIDw8L1R5cGUgL09CSlIKL09iaiAx MyAwIFIKL1BnIDIgMCBSPj5dCi9JRCAobm9kZTAwMDAwODU3KT4+CmVuZG9iagozMDMgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEgKL1AgMzAyIDAgUgovSyBbMzA0IDAgUiAzMDUgMCBS XQovQSBbPDwvTyAvVGFibGUKL1Njb3BlIC9Db2x1bW4+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMyMik+PgplbmRvYmoK MzA4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAzMDcgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEyMT4+XQovSUQgKG5vZGUwMDAwMDg2MSk+ PgplbmRvYmoKMzEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAz MDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEyMj4+XQovSUQgKG5vZGUw MDAwMDg2Mik+PgplbmRvYmoKMzA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL0xpbmsK L1AgMzA3IDAgUgovSyBbMzEwIDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogMTQgMCBSCi9QZyAyIDAg Uj4+XQovSUQgKG5vZGUwMDAwMDg2MCk+PgplbmRvYmoKMzA3IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RICi9QIDMwMiAwIFIKL0sgWzMwOCAwIFIgMzA5IDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMjMpPj4KZW5kb2JqCjMwMiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzMwMyAwIFIgMzA3IDAgUl0KL0lE IChub2RlMDAwMDA0MTYpPj4KZW5kb2JqCjMxMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMzEyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAx MjM+Pl0KL0lEIChub2RlMDAwMDA4NjMpPj4KZW5kb2JqCjMxMiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9URAovUCAzMTEgMCBSCi9LIFszMTMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzI0KT4+CmVuZG9iagozMTUg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDMxNCAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTI0Pj5dCi9JRCAobm9kZTAwMDAwODY0KT4+CmVu ZG9iagozMTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzExIDAgUgovSyBb MzE1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAw MDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9k ZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMDMyNSk+PgplbmRvYmoKMzE3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAzMTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEy NT4+XQovSUQgKG5vZGUwMDAwMDg2NSk+PgplbmRvYmoKMzE2IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDMxMSAwIFIKL0sgWzMxNyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMjYpPj4KZW5kb2JqCjMxMSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzMxMiAwIFIgMzE0 IDAgUiAzMTYgMCBSXQovSUQgKG5vZGUwMDAwMTIwMSk+PgplbmRvYmoKMzIwIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAzMTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDEyNj4+XQovSUQgKG5vZGUwMDAwMDg2Nik+PgplbmRvYmoKMzE5IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDMxOCAwIFIKL0sgWzMyMCAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5v ZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkg KG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAz MjcpPj4KZW5kb2JqCjMyMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMzIxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMjc+Pl0KL0lEIChu b2RlMDAwMDA4NjcpPj4KZW5kb2JqCjMyMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAzMTggMCBSCi9LIFszMjIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChu b2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzI4KT4+CmVuZG9iagozMjQgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDMyMyAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgMTI4Pj5dCi9JRCAobm9kZTAwMDAwODY4KT4+CmVuZG9iagozMjMgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzE4IDAgUgovSyBbMzI0IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9k ZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAo bm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMy OSk+PgplbmRvYmoKMzE4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAg UgovSyBbMzE5IDAgUiAzMjEgMCBSIDMyMyAwIFJdCi9JRCAobm9kZTAwMDAxMjAyKT4+CmVuZG9i agozMjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDMyNiAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTI5Pj5dCi9JRCAobm9kZTAwMDAwODY5 KT4+CmVuZG9iagozMjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzI1IDAg UgovSyBbMzI3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAo bm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5 KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMDMzMCk+PgplbmRvYmoKMzI5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCAzMjggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDEzMD4+XQovSUQgKG5vZGUwMDAwMDg3MCk+PgplbmRvYmoKMzI4IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDMyNSAwIFIKL0sgWzMyOSAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkg KG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAx OCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMzEpPj4KZW5kb2Jq CjMzMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzMwIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMzE+Pl0KL0lEIChub2RlMDAwMDA4NzEp Pj4KZW5kb2JqCjMzMCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzMjUgMCBS Ci9LIFszMzEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChu b2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQp IChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAwMzMyKT4+CmVuZG9iagozMjUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVFIKL1AgMzQgMCBSCi9LIFszMjYgMCBSIDMyOCAwIFIgMzMwIDAgUl0KL0lEIChub2Rl MDAwMDEyMDMpPj4KZW5kb2JqCjMzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgMzMzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMzI+Pl0K L0lEIChub2RlMDAwMDA4NzIpPj4KZW5kb2JqCjMzMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAzMzIgMCBSCi9LIFszMzQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEy OTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzMzKT4+CmVuZG9iagozMzYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDMzNSAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMTMzPj5dCi9JRCAobm9kZTAwMDAwODczKT4+CmVuZG9iagoz MzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzMyIDAgUgovSyBbMzM2IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDMzNCk+PgplbmRvYmoKMzM4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAzMzcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEzND4+XQov SUQgKG5vZGUwMDAwMDg3NCk+PgplbmRvYmoKMzM3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDMzMiAwIFIKL0sgWzMzOCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5 NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMzUpPj4KZW5kb2JqCjMzMiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzMzMyAwIFIgMzM1IDAgUiAz MzcgMCBSXQovSUQgKG5vZGUwMDAwMTIwNCk+PgplbmRvYmoKMzQxIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAzNDAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDEzNT4+XQovSUQgKG5vZGUwMDAwMDg3NSk+PgplbmRvYmoKMzQwIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDMzOSAwIFIKL0sgWzM0MSAwIFJdCi9BIFs8PC9P IC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAw MDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUw MDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzMzYpPj4K ZW5kb2JqCjM0MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzQy IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxMzY+Pl0KL0lEIChub2RlMDAw MDA4NzYpPj4KZW5kb2JqCjM0MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAz MzkgMCBSCi9LIFszNDMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwMzM3KT4+CmVuZG9iagozNDUgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM0NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMTM3Pj5dCi9JRCAobm9kZTAwMDAwODc3KT4+CmVuZG9iagozNDQgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzM5IDAgUgovSyBbMzQ1IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAw MzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAw MDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDMzOCk+Pgpl bmRvYmoKMzM5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBb MzQwIDAgUiAzNDIgMCBSIDM0NCAwIFJdCi9JRCAobm9kZTAwMDAxMjA1KT4+CmVuZG9iagozNDgg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM0NyAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTM4Pj5dCi9JRCAobm9kZTAwMDAwODc4KT4+CmVu ZG9iagozNDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzQ2IDAgUgovSyBb MzQ4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAw MDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9k ZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMDMzOSk+PgplbmRvYmoKMzUwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAzNDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDEz OT4+XQovSUQgKG5vZGUwMDAwMDg3OSk+PgplbmRvYmoKMzQ5IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDM0NiAwIFIKL0sgWzM1MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUw MDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNDApPj4KZW5kb2JqCjM1MiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzUxIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNDA+Pl0KL0lEIChub2RlMDAwMDA4ODApPj4KZW5k b2JqCjM1MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzNDYgMCBSCi9LIFsz NTIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAw MDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2Rl MDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAwMzQxKT4+CmVuZG9iagozNDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VFIKL1AgMzQgMCBSCi9LIFszNDcgMCBSIDM0OSAwIFIgMzUxIDAgUl0KL0lEIChub2RlMDAwMDEy MDYpPj4KZW5kb2JqCjM1NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMzU0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNDE+Pl0KL0lEIChu b2RlMDAwMDA4ODEpPj4KZW5kb2JqCjM1NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAzNTMgMCBSCi9LIFszNTUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzQyKT4+CmVuZG9iagozNTcgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM1NiAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgMTQyPj5dCi9JRCAobm9kZTAwMDAwODgyKT4+CmVuZG9iagozNTYgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzUzIDAgUgovSyBbMzU3IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM0 Myk+PgplbmRvYmoKMzU5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCAzNTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE0Mz4+XQovSUQgKG5v ZGUwMDAwMDg4Myk+PgplbmRvYmoKMzU4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDM1MyAwIFIKL0sgWzM1OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5v ZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNDQpPj4KZW5kb2JqCjM1MyAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzM1NCAwIFIgMzU2IDAgUiAzNTggMCBS XQovSUQgKG5vZGUwMDAwMTIwNyk+PgplbmRvYmoKMzYyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCAzNjEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDE0ND4+XQovSUQgKG5vZGUwMDAwMDg4NCk+PgplbmRvYmoKMzYxIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDM2MCAwIFIKL0sgWzM2MiAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikg KG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAx NCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNDUpPj4KZW5kb2Jq CjM2NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzYzIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNDU+Pl0KL0lEIChub2RlMDAwMDA4ODUp Pj4KZW5kb2JqCjM2MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzNjAgMCBS Ci9LIFszNjQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChu b2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMp IChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAwMzQ2KT4+CmVuZG9iagozNjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDM2NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMTQ2Pj5dCi9JRCAobm9kZTAwMDAwODg2KT4+CmVuZG9iagozNjUgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMzYwIDAgUgovSyBbMzY2IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAo bm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM0Nyk+PgplbmRvYmoK MzYwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMzYxIDAg UiAzNjMgMCBSIDM2NSAwIFJdCi9JRCAobm9kZTAwMDAxMjA4KT4+CmVuZG9iagozNjkgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM2OCAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMTQ3Pj5dCi9JRCAobm9kZTAwMDAwODg3KT4+CmVuZG9iagoz NjggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzY3IDAgUgovSyBbMzY5IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2 KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAx ODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDM0OCk+PgplbmRvYmoKMzcxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAzNzAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE0OD4+XQov SUQgKG5vZGUwMDAwMDg4OCk+PgplbmRvYmoKMzcwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDM2NyAwIFIKL0sgWzM3MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5 NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNDkpPj4KZW5kb2JqCjM3MyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzcyIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAxNDk+Pl0KL0lEIChub2RlMDAwMDA4ODkpPj4KZW5kb2JqCjM3 MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzNjcgMCBSCi9LIFszNzMgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcp IChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4 MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMzUwKT4+CmVuZG9iagozNjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1Ag MzQgMCBSCi9LIFszNjggMCBSIDM3MCAwIFIgMzcyIDAgUl0KL0lEIChub2RlMDAwMDEyMDkpPj4K ZW5kb2JqCjM3NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzc1 IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNTA+Pl0KL0lEIChub2RlMDAw MDA4OTApPj4KZW5kb2JqCjM3NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAz NzQgMCBSCi9LIFszNzYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAw MDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwMzUxKT4+CmVuZG9iagozNzggMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM3NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMTUxPj5dCi9JRCAobm9kZTAwMDAwODkxKT4+CmVuZG9iagozNzcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzc0IDAgUgovSyBbMzc4IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAx MTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAw MDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM1Mik+Pgpl bmRvYmoKMzgwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAzNzkg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE1Mj4+XQovSUQgKG5vZGUwMDAw MDg5Mik+PgplbmRvYmoKMzc5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDM3 NCAwIFIKL0sgWzM4MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAw MTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAzNTMpPj4KZW5kb2JqCjM3NCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzM3NSAwIFIgMzc3IDAgUiAzNzkgMCBSXQovSUQg KG5vZGUwMDAwMTIxMCk+PgplbmRvYmoKMzgzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAzODIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE1 Mz4+XQovSUQgKG5vZGUwMDAwMDg5Myk+PgplbmRvYmoKMzg0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAzODIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDE1ND4+XQovSUQgKG5vZGUwMDAwMDg5NSk+PgplbmRvYmoKMzgyIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDM4MSAwIFIKL0sgWzM4MyAwIFIgMzg0IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9k ZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAo bm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM1 NCk+PgplbmRvYmoKMzg2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCAzODUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE1NT4+XQovSUQgKG5v ZGUwMDAwMDg5Nik+PgplbmRvYmoKMzg1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDM4MSAwIFIKL0sgWzM4NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNTUpPj4KZW5kb2JqCjM4OCAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzg3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCAxNTY+Pl0KL0lEIChub2RlMDAwMDA4OTcpPj4KZW5kb2JqCjM4OSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzg3IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNTc+Pl0KL0lEIChub2RlMDAwMDA4OTkpPj4KZW5kb2Jq CjM4NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzODEgMCBSCi9LIFszODgg MCBSIDM4OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5v ZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkg KG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDAzNTYpPj4KZW5kb2JqCjM4MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9UUgovUCAzNCAwIFIKL0sgWzM4MiAwIFIgMzg1IDAgUiAzODcgMCBSXQovSUQgKG5vZGUw MDAwMTIxMyk+PgplbmRvYmoKMzkyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAzOTEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE1OD4+XQov SUQgKG5vZGUwMDAwMDkwMCk+PgplbmRvYmoKMzkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDM5MCAwIFIKL0sgWzM5MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5 MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNTcpPj4KZW5kb2JqCjM5NCAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMzkzIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAxNTk+Pl0KL0lEIChub2RlMDAwMDA5MDEpPj4KZW5kb2JqCjM5 MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzOTAgMCBSCi9LIFszOTQgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMzU4KT4+CmVuZG9iagozOTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDM5NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTYwPj5dCi9J RCAobm9kZTAwMDAwOTAyKT4+CmVuZG9iagozOTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgMzkwIDAgUgovSyBbMzk2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM1OSk+PgplbmRvYmoKMzkwIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMzkxIDAgUiAzOTMgMCBSIDM5 NSAwIFJdCi9JRCAobm9kZTAwMDAxMjE0KT4+CmVuZG9iagozOTkgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDM5OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMTYxPj5dCi9JRCAobm9kZTAwMDAwOTAzKT4+CmVuZG9iagozOTggMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMzk3IDAgUgovSyBbMzk5IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAw MzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAw MDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM2MCk+Pgpl bmRvYmoKNDAxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MDAg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE2Mj4+XQovSUQgKG5vZGUwMDAw MDkwNCk+PgplbmRvYmoKNDAwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDM5 NyAwIFIKL0sgWzQwMSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0 NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAw MTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAzNjEpPj4KZW5kb2JqCjQwMyAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDAyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAg UgovTUNJRCAxNjM+Pl0KL0lEIChub2RlMDAwMDA5MDUpPj4KZW5kb2JqCjQwMiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAzOTcgMCBSCi9LIFs0MDMgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAz MjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAw MDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzYyKT4+CmVu ZG9iagozOTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsz OTggMCBSIDQwMCAwIFIgNDAyIDAgUl0KL0lEIChub2RlMDAwMDEyMTUpPj4KZW5kb2JqCjQwNiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDA1IDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNjQ+Pl0KL0lEIChub2RlMDAwMDA5MDYpPj4KZW5k b2JqCjQwNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDA1IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNjU+Pl0KL0lEIChub2RlMDAwMDA5 MDgpPj4KZW5kb2JqCjQwNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0MDQg MCBSCi9LIFs0MDYgMCBSIDQwNyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5v ZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNjMpPj4KZW5kb2JqCjQwOSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDA4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCAxNjY+Pl0KL0lEIChub2RlMDAwMDA5MDkpPj4KZW5kb2JqCjQwOCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0MDQgMCBSCi9LIFs0MDkgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2Rl MDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChu b2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzY0 KT4+CmVuZG9iago0MTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDQxMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTY3Pj5dCi9JRCAobm9k ZTAwMDAwOTEwKT4+CmVuZG9iago0MTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDQxMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTY4Pj5d Ci9JRCAobm9kZTAwMDAwOTEyKT4+CmVuZG9iago0MTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgNDA0IDAgUgovSyBbNDExIDAgUiA0MTIgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChu b2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzY1KT4+CmVuZG9iago0 MDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs0MDUgMCBS IDQwOCAwIFIgNDEwIDAgUl0KL0lEIChub2RlMDAwMDEyMTgpPj4KZW5kb2JqCjQxNSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDE0IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAxNjk+Pl0KL0lEIChub2RlMDAwMDA5MTMpPj4KZW5kb2JqCjQx NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0MTMgMCBSCi9LIFs0MTUgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYp IChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4 MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwMzY2KT4+CmVuZG9iago0MTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDQxNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTcwPj5dCi9J RCAobm9kZTAwMDAwOTE0KT4+CmVuZG9iago0MTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgNDEzIDAgUgovSyBbNDE3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0 KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM2Nyk+PgplbmRvYmoKNDE5IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MTggMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDE3MT4+XQovSUQgKG5vZGUwMDAwMDkxNSk+PgplbmRvYmoKNDE4 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQxMyAwIFIKL0sgWzQxOSAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2Nykg KG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgy MCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDAzNjgpPj4KZW5kb2JqCjQxMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAz NCAwIFIKL0sgWzQxNCAwIFIgNDE2IDAgUiA0MTggMCBSXQovSUQgKG5vZGUwMDAwMTIxOSk+Pgpl bmRvYmoKNDIyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MjEg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE3Mj4+XQovSUQgKG5vZGUwMDAw MDkxNik+PgplbmRvYmoKNDIxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQy MCAwIFIKL0sgWzQyMiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAw MTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDAzNjkpPj4KZW5kb2JqCjQyNCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDIzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAg UgovTUNJRCAxNzM+Pl0KL0lEIChub2RlMDAwMDA5MTcpPj4KZW5kb2JqCjQyMyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0MjAgMCBSCi9LIFs0MjQgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzcwKT4+CmVu ZG9iago0MjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDQyNSAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTc0Pj5dCi9JRCAobm9kZTAwMDAw OTE4KT4+CmVuZG9iago0MjUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNDIw IDAgUgovSyBbNDI2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIx KSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAx NTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDM3MSk+PgplbmRvYmoKNDIwIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNDIxIDAgUiA0MjMgMCBSIDQyNSAwIFJdCi9JRCAo bm9kZTAwMDAxMjIwKT4+CmVuZG9iago0MjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDQyOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTc1 Pj5dCi9JRCAobm9kZTAwMDAwOTE5KT4+CmVuZG9iago0MjggMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgNDI3IDAgUgovSyBbNDI5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAw MDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM3Mik+PgplbmRvYmoKNDMxIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MzAgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE3Nj4+XQovSUQgKG5vZGUwMDAwMDkyMCk+PgplbmRv YmoKNDMwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQyNyAwIFIKL0sgWzQz MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAw MTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUw MDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDAzNzMpPj4KZW5kb2JqCjQzMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgNDMyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxNzc+ Pl0KL0lEIChub2RlMDAwMDA5MjEpPj4KZW5kb2JqCjQzMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCA0MjcgMCBSCi9LIFs0MzMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAw MDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzc0KT4+CmVuZG9iago0MjcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs0MjggMCBSIDQzMCAw IFIgNDMyIDAgUl0KL0lEIChub2RlMDAwMDEyMjEpPj4KZW5kb2JqCjQzNiAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDM1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCAxNzg+Pl0KL0lEIChub2RlMDAwMDA5MjIpPj4KZW5kb2JqCjQzNSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0MzQgMCBSCi9LIFs0MzYgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2Rl MDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChu b2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzc1 KT4+CmVuZG9iago0MzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDQzNyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMTc5Pj5dCi9JRCAobm9k ZTAwMDAwOTIzKT4+CmVuZG9iago0MzcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgNDM0IDAgUgovSyBbNDM4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9k ZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM3Nik+PgplbmRvYmoKNDQwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0MzkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDE4MD4+XQovSUQgKG5vZGUwMDAwMDkyNCk+PgplbmRvYmoKNDM5IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQzNCAwIFIKL0sgWzQ0MCAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzNzcp Pj4KZW5kb2JqCjQzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzQzNSAwIFIgNDM3IDAgUiA0MzkgMCBSXQovSUQgKG5vZGUwMDAwMTIyMik+PgplbmRvYmoK NDQzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NDIgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE4MT4+XQovSUQgKG5vZGUwMDAwMDkyNSk+ PgplbmRvYmoKNDQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0 NDIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE4Mj4+XQovSUQgKG5vZGUw MDAwMDkyNyk+PgplbmRvYmoKNDQyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDQ0MSAwIFIKL0sgWzQ0MyAwIFIgNDQ0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkz KSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM3OCk+PgplbmRvYmoKNDQ2IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NDUgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDE4Mz4+XQovSUQgKG5vZGUwMDAwMDkyOCk+PgplbmRvYmoKNDQ1 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ0MSAwIFIKL0sgWzQ0NiAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3Mikg KG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgx OSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDAzNzkpPj4KZW5kb2JqCjQ0OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgNDQ3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxODQ+Pl0KL0lE IChub2RlMDAwMDA5MjkpPj4KZW5kb2JqCjQ0OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgNDQ3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAx ODU+Pl0KL0lEIChub2RlMDAwMDA5MzEpPj4KZW5kb2JqCjQ0NyAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9URAovUCA0NDEgMCBSCi9LIFs0NDggMCBSIDQ0OSAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMy MykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAw MjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODApPj4KZW5k b2JqCjQ0MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ0 MiAwIFIgNDQ1IDAgUiA0NDcgMCBSXQovSUQgKG5vZGUwMDAwMTIyNSk+PgplbmRvYmoKNDUyIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NTEgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE4Nj4+XQovSUQgKG5vZGUwMDAwMDkzMik+PgplbmRv YmoKNDUzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NTEgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE4Nz4+XQovSUQgKG5vZGUwMDAwMDkz NCk+PgplbmRvYmoKNDUxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ1MCAw IFIKL0sgWzQ1MiAwIFIgNDUzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9k ZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDM4MSk+PgplbmRvYmoKNDU1IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NTQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDE4OD4+XQovSUQgKG5vZGUwMDAwMDkzNSk+PgplbmRvYmoKNDU0IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ1MCAwIFIKL0sgWzQ1NSAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUw MDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5v ZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODIp Pj4KZW5kb2JqCjQ1NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag NDU2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxODk+Pl0KL0lEIChub2Rl MDAwMDA5MzYpPj4KZW5kb2JqCjQ1OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgNDU2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxOTA+Pl0K L0lEIChub2RlMDAwMDA5MzgpPj4KZW5kb2JqCjQ1NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCA0NTAgMCBSCi9LIFs0NTcgMCBSIDQ1OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5v ZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODMpPj4KZW5kb2JqCjQ1 MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ1MSAwIFIg NDU0IDAgUiA0NTYgMCBSXQovSUQgKG5vZGUwMDAwMTIyNik+PgplbmRvYmoKNDYxIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NjAgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDE5MT4+XQovSUQgKG5vZGUwMDAwMDkzOSk+PgplbmRvYmoKNDYy IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NjAgMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE5Mj4+XQovSUQgKG5vZGUwMDAwMDk0MSk+Pgpl bmRvYmoKNDYwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ1OSAwIFIKL0sg WzQ2MSAwIFIgNDYyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIw KSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAx NTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDM4NCk+PgplbmRvYmoKNDY0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA0NjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDE5Mz4+XQovSUQgKG5vZGUwMDAwMDk0Mik+PgplbmRvYmoKNDYzIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ1OSAwIFIKL0sgWzQ2NCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5 OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAw MjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODUpPj4KZW5k b2JqCjQ2NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDY1IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxOTQ+Pl0KL0lEIChub2RlMDAwMDA5 NDMpPj4KZW5kb2JqCjQ2NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgNDY1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxOTU+Pl0KL0lEIChu b2RlMDAwMDA5NDUpPj4KZW5kb2JqCjQ2NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCA0NTkgMCBSCi9LIFs0NjYgMCBSIDQ2NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAw MTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODYpPj4KZW5kb2JqCjQ1OSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ2MCAwIFIgNDYzIDAg UiA0NjUgMCBSXQovSUQgKG5vZGUwMDAwMTIyNyk+PgplbmRvYmoKNDcwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NjkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDE5Nj4+XQovSUQgKG5vZGUwMDAwMDk0Nik+PgplbmRvYmoKNDcxIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NjkgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDE5Nz4+XQovSUQgKG5vZGUwMDAwMDk0OCk+PgplbmRvYmoK NDY5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ2OCAwIFIKL0sgWzQ3MCAw IFIgNDcxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9k ZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAo bm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUx KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMDM4Nyk+PgplbmRvYmoKNDczIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCA0NzIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDE5OD4+XQovSUQgKG5vZGUwMDAwMDk0OSk+PgplbmRvYmoKNDcyIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDQ2OCAwIFIKL0sgWzQ3MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5v ZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODgpPj4KZW5kb2JqCjQ3 NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDc0IDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAxOTk+Pl0KL0lEIChub2RlMDAwMDA5NTApPj4K ZW5kb2JqCjQ3NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDc0 IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyMDA+Pl0KL0lEIChub2RlMDAw MDA5NTIpPj4KZW5kb2JqCjQ3NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0 NjggMCBSCi9LIFs0NzUgMCBSIDQ3NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkg KG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzODkpPj4KZW5kb2JqCjQ2OCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ2OSAwIFIgNDcyIDAgUiA0NzQg MCBSXQovSUQgKG5vZGUwMDAwMTIyOCk+PgplbmRvYmoKNDc5IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA0NzggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDIwMT4+XQovSUQgKG5vZGUwMDAwMDk1Myk+PgplbmRvYmoKNDgwIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0NzggMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDIwMj4+XQovSUQgKG5vZGUwMDAwMDk1NSk+PgplbmRvYmoKNDc4IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ3NyAwIFIKL0sgWzQ3OSAwIFIgNDgw IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAw MjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAw MDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMDM5MCk+PgplbmRvYmoKNDgyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCA0ODEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIwMz4+ XQovSUQgKG5vZGUwMDAwMDk1Nik+PgplbmRvYmoKNDgxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDQ3NyAwIFIKL0sgWzQ4MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAw MTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzOTEpPj4KZW5kb2JqCjQ4NCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDgzIDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyMDQ+Pl0KL0lEIChub2RlMDAwMDA5NTcpPj4KZW5kb2Jq CjQ4NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDgzIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyMDU+Pl0KL0lEIChub2RlMDAwMDA5NTkp Pj4KZW5kb2JqCjQ4MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0NzcgMCBS Ci9LIFs0ODQgMCBSIDQ4NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUw MDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDAzOTIpPj4KZW5kb2JqCjQ3NyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ3OCAwIFIgNDgxIDAgUiA0ODMgMCBSXQov SUQgKG5vZGUwMDAwMTIyOSk+PgplbmRvYmoKNDg4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCA0ODcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDIwNj4+XQovSUQgKG5vZGUwMDAwMDk2MCk+PgplbmRvYmoKNDg5IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0ODcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDIwNz4+XQovSUQgKG5vZGUwMDAwMDk2Mik+PgplbmRvYmoKNDg3IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ4NiAwIFIKL0sgWzQ4OCAwIFIgNDg5IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAo bm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1 KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MDU2Nyk+PgplbmRvYmoKNDkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA0OTAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIwOD4+XQovSUQg KG5vZGUwMDAwMDk2Myk+PgplbmRvYmoKNDkwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDQ4NiAwIFIKL0sgWzQ5MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyMzEpPj4KZW5kb2JqCjQ5MyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDkyIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAyIDAgUgovTUNJRCAyMDk+Pl0KL0lEIChub2RlMDAwMDA5NjQpPj4KZW5kb2JqCjQ5NCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNDkyIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAyMTA+Pl0KL0lEIChub2RlMDAwMDA5NjYpPj4KZW5k b2JqCjQ5MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0ODYgMCBSCi9LIFs0 OTMgMCBSIDQ5NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkg KG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4 NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDA1NjgpPj4KZW5kb2JqCjQ4NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzQ4NyAwIFIgNDkwIDAgUiA0OTIgMCBSXQovSUQgKG5v ZGUwMDAwMTIzMCk+PgplbmRvYmoKNDk3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCA0OTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIxMT4+ XQovSUQgKG5vZGUwMDAwMDk2Nyk+PgplbmRvYmoKNDk4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA0OTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDIxMj4+XQovSUQgKG5vZGUwMDAwMDk2OSk+PgplbmRvYmoKNDk2IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDQ5NSAwIFIKL0sgWzQ5NyAwIFIgNDk4IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAw MDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9k ZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDU3MSk+ PgplbmRvYmoKNTAwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA0 OTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIxMz4+XQovSUQgKG5vZGUw MDAwMDk3MCk+PgplbmRvYmoKNDk5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDQ5NSAwIFIKL0sgWzUwMCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUw MDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyMzMpPj4KZW5kb2JqCjUwMiAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTAxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAy IDAgUgovTUNJRCAyMTQ+Pl0KL0lEIChub2RlMDAwMDA5NzEpPj4KZW5kb2JqCjUwMyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTAxIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAyMTU+Pl0KL0lEIChub2RlMDAwMDA5NzMpPj4KZW5kb2JqCjUw MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA0OTUgMCBSCi9LIFs1MDIgMCBS IDUwMyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUw MDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5v ZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDA1NzIpPj4KZW5kb2JqCjQ5NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9UUgovUCAzNCAwIFIKL0sgWzQ5NiAwIFIgNDk5IDAgUiA1MDEgMCBSXQovSUQgKG5vZGUwMDAw MTIzMik+PgplbmRvYmoKNTA2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA1MDUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIxNj4+XQovSUQg KG5vZGUwMDAwMDk3NCk+PgplbmRvYmoKNTA3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA1MDUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIx Nz4+XQovSUQgKG5vZGUwMDAwMDk3Nik+PgplbmRvYmoKNTA1IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDUwNCAwIFIKL0sgWzUwNiAwIFIgNTA3IDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIy KSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAy MDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDU3NSk+PgplbmRv YmoKNTA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MDggMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIxOD4+XQovSUQgKG5vZGUwMDAwMDk3 Nyk+PgplbmRvYmoKNTA4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDUwNCAw IFIKL0sgWzUwOSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0Nykg KG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4 MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDEyMzUpPj4KZW5kb2JqCjUxMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTEwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgov TUNJRCAyMTk+Pl0KL0lEIChub2RlMDAwMDA5NzgpPj4KZW5kb2JqCjUxMiAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTEwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAyIDAgUgovTUNJRCAyMjA+Pl0KL0lEIChub2RlMDAwMDA5ODApPj4KZW5kb2JqCjUxMCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA1MDQgMCBSCi9LIFs1MTEgMCBSIDUxMiAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2 NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAw MTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDA1NzYpPj4KZW5kb2JqCjUwNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgov UCAzNCAwIFIKL0sgWzUwNSAwIFIgNTA4IDAgUiA1MTAgMCBSXQovSUQgKG5vZGUwMDAwMTIzNCk+ PgplbmRvYmoKNTE1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1 MTQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIyMT4+XQovSUQgKG5vZGUw MDAwMDk4MSk+PgplbmRvYmoKNTE0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDUxMyAwIFIKL0sgWzUxNSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUw MDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDA1NzkpPj4KZW5kb2JqCjUxNyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNTE2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAy IDAgUgovTUNJRCAyMjI+Pl0KL0lEIChub2RlMDAwMDA5ODIpPj4KZW5kb2JqCjUxNiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA1MTMgMCBSCi9LIFs1MTcgMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAw MDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2Rl MDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMjM3KT4+ CmVuZG9iago1MTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDUx OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjIzPj5dCi9JRCAobm9kZTAw MDAwOTgzKT4+CmVuZG9iago1MTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag NTEzIDAgUgovSyBbNTE5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAw MDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMDU4MCk+PgplbmRvYmoKNTEzIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTE0IDAgUiA1MTYgMCBSIDUxOCAwIFJdCi9J RCAobm9kZTAwMDAxMjM2KT4+CmVuZG9iago1MjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDUyMSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQg MjI0Pj5dCi9JRCAobm9kZTAwMDAwOTg0KT4+CmVuZG9iago1MjMgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDUyMSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMjI1Pj5dCi9JRCAobm9kZTAwMDAwOTg2KT4+CmVuZG9iago1MjEgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTIwIDAgUgovSyBbNTIyIDAgUiA1MjMgMCBSXQov QSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChu b2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUp IChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1Rh YmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAw NTgzKT4+CmVuZG9iago1MjUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDUyNCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjI2Pj5dCi9JRCAo bm9kZTAwMDAwOTg3KT4+CmVuZG9iago1MjQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgNTIwIDAgUgovSyBbNTI1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAo bm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI0MSk+PgplbmRvYmoKNTI3IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MjYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDIyNz4+XQovSUQgKG5vZGUwMDAwMDk4OCk+PgplbmRvYmoKNTI4IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MjYgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDIyOD4+XQovSUQgKG5vZGUwMDAwMDk5MCk+PgplbmRv YmoKNTI2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDUyMCAwIFIKL0sgWzUy NyAwIFIgNTI4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAo bm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0 KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMDU4NCk+PgplbmRvYmoKNTIwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTIxIDAgUiA1MjQgMCBSIDUyNiAwIFJdCi9JRCAobm9k ZTAwMDAxMjQwKT4+CmVuZG9iago1MzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDUzMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjI5Pj5d Ci9JRCAobm9kZTAwMDAwOTkxKT4+CmVuZG9iago1MzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDUzMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMjMwPj5dCi9JRCAobm9kZTAwMDAwOTkzKT4+CmVuZG9iago1MzAgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgNTI5IDAgUgovSyBbNTMxIDAgUiA1MzIgMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAw MDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2Rl MDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNTg3KT4+ CmVuZG9iago1MzQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDUz MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjMxPj5dCi9JRCAobm9kZTAw MDAwOTk0KT4+CmVuZG9iago1MzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag NTI5IDAgUgovSyBbNTM0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAx MTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAw MDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMTI0Myk+PgplbmRvYmoKNTM2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MzUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDIzMj4+XQovSUQgKG5vZGUwMDAwMDk5NSk+PgplbmRvYmoKNTM3IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1MzUgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDIzMz4+XQovSUQgKG5vZGUwMDAwMDk5Nyk+PgplbmRvYmoKNTM1 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDUyOSAwIFIKL0sgWzUzNiAwIFIg NTM3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAw MDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9k ZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMDU4OCk+PgplbmRvYmoKNTI5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RSCi9QIDM0IDAgUgovSyBbNTMwIDAgUiA1MzMgMCBSIDUzNSAwIFJdCi9JRCAobm9kZTAwMDAx MjQyKT4+CmVuZG9iago1NDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDUzOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjM0Pj5dCi9JRCAo bm9kZTAwMDAwOTk4KT4+CmVuZG9iago1NDEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDUzOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjM1 Pj5dCi9JRCAobm9kZTAwMDAxMDAwKT4+CmVuZG9iago1MzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgNTM4IDAgUgovSyBbNTQwIDAgUiA1NDEgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIp IChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIw MTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNTkxKT4+CmVuZG9i ago1NDMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU0MiAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjM2Pj5dCi9JRCAobm9kZTAwMDAxMDAx KT4+CmVuZG9iago1NDIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTM4IDAg UgovSyBbNTQzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAo bm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgz KSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMTI0NSk+PgplbmRvYmoKNTQ1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA1NDQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDIzNz4+XQovSUQgKG5vZGUwMDAwMTAwMik+PgplbmRvYmoKNTQ2IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1NDQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDIzOD4+XQovSUQgKG5vZGUwMDAwMTAwNCk+PgplbmRvYmoKNTQ0IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDUzOCAwIFIKL0sgWzU0NSAwIFIgNTQ2IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3 KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAx ODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDU5Mik+PgplbmRvYmoKNTM4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9Q IDM0IDAgUgovSyBbNTM5IDAgUiA1NDIgMCBSIDU0NCAwIFJdCi9JRCAobm9kZTAwMDAxMjQ0KT4+ CmVuZG9iago1NDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU0 OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjM5Pj5dCi9JRCAobm9kZTAw MDAxMDA1KT4+CmVuZG9iago1NTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDU0OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQwPj5dCi9J RCAobm9kZTAwMDAxMDA3KT4+CmVuZG9iago1NDggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgNTQ3IDAgUgovSyBbNTQ5IDAgUiA1NTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNTk1KT4+CmVuZG9iago1NTIg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU1MSAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQxPj5dCi9JRCAobm9kZTAwMDAxMDA4KT4+CmVu ZG9iago1NTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTQ3IDAgUgovSyBb NTUyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAw MDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9k ZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTI0Nyk+PgplbmRvYmoKNTU0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA1NTMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI0 Mj4+XQovSUQgKG5vZGUwMDAwMTAwOSk+PgplbmRvYmoKNTU1IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA1NTMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDI0Mz4+XQovSUQgKG5vZGUwMDAwMTAxMSk+PgplbmRvYmoKNTUzIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDU0NyAwIFIKL0sgWzU1NCAwIFIgNTU1IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9k ZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAo bm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDU5 Nik+PgplbmRvYmoKNTQ3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAg UgovSyBbNTQ4IDAgUiA1NTEgMCBSIDU1MyAwIFJdCi9JRCAobm9kZTAwMDAxMjQ2KT4+CmVuZG9i ago1NTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU1NyAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQ0Pj5dCi9JRCAobm9kZTAwMDAxMDEy KT4+CmVuZG9iago1NTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDU1NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQ1Pj5dCi9JRCAobm9k ZTAwMDAxMDE0KT4+CmVuZG9iago1NTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgNTU2IDAgUgovSyBbNTU4IDAgUiA1NTkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEy OTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNTk5KT4+CmVuZG9iago1NjEgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU2MCAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMjQ2Pj5dCi9JRCAobm9kZTAwMDAxMDE1KT4+CmVuZG9iago1 NjAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTU2IDAgUgovSyBbNTYxIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMTI0OSk+PgplbmRvYmoKNTYzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA1NjIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI0Nz4+XQov SUQgKG5vZGUwMDAwMTAxNik+PgplbmRvYmoKNTY0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCA1NjIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDI0OD4+XQovSUQgKG5vZGUwMDAwMTAxOCk+PgplbmRvYmoKNTYyIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDU1NiAwIFIKL0sgWzU2MyAwIFIgNTY0IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAw MzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAw MDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYwMCk+Pgpl bmRvYmoKNTU2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBb NTU3IDAgUiA1NjAgMCBSIDU2MiAwIFJdCi9JRCAobm9kZTAwMDAxMjQ4KT4+CmVuZG9iago1Njcg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU2NiAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjQ5Pj5dCi9JRCAobm9kZTAwMDAxMDE5KT4+CmVu ZG9iago1NjggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU2NiAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjUwPj5dCi9JRCAobm9kZTAwMDAx MDIxKT4+CmVuZG9iago1NjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTY1 IDAgUgovSyBbNTY3IDAgUiA1NjggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjAzKT4+CmVuZG9iago1NzAgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU2OSAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgMjUxPj5dCi9JRCAobm9kZTAwMDAxMDIyKT4+CmVuZG9iago1NjkgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTY1IDAgUgovSyBbNTcwIDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI1 MSk+PgplbmRvYmoKNTcyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA1NzEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI1Mj4+XQovSUQgKG5v ZGUwMDAwMTAyMyk+PgplbmRvYmoKNTczIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCA1NzEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI1Mz4+ XQovSUQgKG5vZGUwMDAwMTAyNSk+PgplbmRvYmoKNTcxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDU2NSAwIFIKL0sgWzU3MiAwIFIgNTczIDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAo bm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYwNCk+PgplbmRvYmoK NTY1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTY2IDAg UiA1NjkgMCBSIDU3MSAwIFJdCi9JRCAobm9kZTAwMDAxMjUwKT4+CmVuZG9iago1NzYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU3NSAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMjU0Pj5dCi9JRCAobm9kZTAwMDAxMDI2KT4+CmVuZG9iago1 NzcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU3NSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjU1Pj5dCi9JRCAobm9kZTAwMDAxMDI4KT4+ CmVuZG9iago1NzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTc0IDAgUgov SyBbNTc2IDAgUiA1NzcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAw MDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwNjA3KT4+CmVuZG9iago1NzkgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU3OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMjU2Pj5dCi9JRCAobm9kZTAwMDAxMDI5KT4+CmVuZG9iago1NzggMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTc0IDAgUgovSyBbNTc5IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAx MTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAw MDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI1Myk+Pgpl bmRvYmoKNTgxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1ODAg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI1Nz4+XQovSUQgKG5vZGUwMDAw MTAzMCk+PgplbmRvYmoKNTgyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA1ODAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI1OD4+XQovSUQg KG5vZGUwMDAwMTAzMik+PgplbmRvYmoKNTgwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDU3NCAwIFIKL0sgWzU4MSAwIFIgNTgyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAw MDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYwOCk+PgplbmRvYmoKNTc0IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTc1IDAgUiA1Nzgg MCBSIDU4MCAwIFJdCi9JRCAobm9kZTAwMDAxMjUyKT4+CmVuZG9iago1ODUgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU4NCAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMiAwIFIKL01DSUQgMjU5Pj5dCi9JRCAobm9kZTAwMDAxMDMzKT4+CmVuZG9iago1ODYgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU4NCAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjYwPj5dCi9JRCAobm9kZTAwMDAxMDM1KT4+CmVuZG9i ago1ODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTgzIDAgUgovSyBbNTg1 IDAgUiA1ODYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChu b2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1Nzkp IChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAwNjExKT4+CmVuZG9iago1ODggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDU4NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMjYxPj5dCi9JRCAobm9kZTAwMDAxMDM2KT4+CmVuZG9iago1ODcgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgNTgzIDAgUgovSyBbNTg4IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAo bm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI1NSk+PgplbmRvYmoK NTkwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1ODkgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI2Mj4+XQovSUQgKG5vZGUwMDAwMTAzNyk+ PgplbmRvYmoKNTkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1 ODkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI2Mz4+XQovSUQgKG5vZGUw MDAwMTAzOSk+PgplbmRvYmoKNTg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDU4MyAwIFIKL0sgWzU5MCAwIFIgNTkxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYxMik+PgplbmRvYmoKNTgzIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTg0IDAgUiA1ODcgMCBSIDU4 OSAwIFJdCi9JRCAobm9kZTAwMDAxMjU0KT4+CmVuZG9iago1OTQgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU5MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAw IFIKL01DSUQgMjY0Pj5dCi9JRCAobm9kZTAwMDAxMDQwKT4+CmVuZG9iago1OTUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDU5MyAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMiAwIFIKL01DSUQgMjY1Pj5dCi9JRCAobm9kZTAwMDAxMDQyKT4+CmVuZG9iago1OTMg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNTkyIDAgUgovSyBbNTk0IDAgUiA1 OTUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAw MDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2Rl MDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAwNjE1KT4+CmVuZG9iago1OTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDU5NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjY2 Pj5dCi9JRCAobm9kZTAwMDAxMDQzKT4+CmVuZG9iago1OTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgNTkyIDAgUgovSyBbNTk3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI1Nyk+PgplbmRvYmoKNTk5IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1OTggMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI2Nz4+XQovSUQgKG5vZGUwMDAwMTA0NCk+PgplbmRv YmoKNjAwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA1OTggMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI2OD4+XQovSUQgKG5vZGUwMDAwMTA0 Nik+PgplbmRvYmoKNTk4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDU5MiAw IFIKL0sgWzU5OSAwIFIgNjAwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9k ZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYxNik+PgplbmRvYmoKNTkyIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNTkzIDAgUiA1OTYgMCBSIDU5OCAwIFJd Ci9JRCAobm9kZTAwMDAxMjU2KT4+CmVuZG9iago2MDMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDYwMiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01D SUQgMjY5Pj5dCi9JRCAobm9kZTAwMDAxMDQ3KT4+CmVuZG9iago2MDQgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDYwMiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MiAwIFIKL01DSUQgMjcwPj5dCi9JRCAobm9kZTAwMDAxMDQ5KT4+CmVuZG9iago2MDIgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjAxIDAgUgovSyBbNjAzIDAgUiA2MDQgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYp IChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4 MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwNjE5KT4+CmVuZG9iago2MDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDYwNSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjcxPj5dCi9J RCAobm9kZTAwMDAxMDUwKT4+CmVuZG9iago2MDUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgNjAxIDAgUgovSyBbNjA2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0 KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI1OSk+PgplbmRvYmoKNjA4IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MDcgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDI3Mj4+XQovSUQgKG5vZGUwMDAwMTA1MSk+PgplbmRvYmoKNjA5 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MDcgMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI3Mz4+XQovSUQgKG5vZGUwMDAwMTA1Myk+Pgpl bmRvYmoKNjA3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDYwMSAwIFIKL0sg WzYwOCAwIFIgNjA5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIx KSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAx NTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDYyMCk+PgplbmRvYmoKNjAxIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNjAyIDAgUiA2MDUgMCBSIDYwNyAwIFJdCi9JRCAo bm9kZTAwMDAxMjU4KT4+CmVuZG9iago2MTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDYxMSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjc0 Pj5dCi9JRCAobm9kZTAwMDAxMDU0KT4+CmVuZG9iago2MTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDYxMSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIK L01DSUQgMjc1Pj5dCi9JRCAobm9kZTAwMDAxMDU2KT4+CmVuZG9iago2MTEgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjEwIDAgUgovSyBbNjEyIDAgUiA2MTMgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2Rl MDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChu b2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjIz KT4+CmVuZG9iago2MTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDYxNCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjc2Pj5dCi9JRCAobm9k ZTAwMDAxMDU3KT4+CmVuZG9iago2MTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgNjEwIDAgUgovSyBbNjE1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9k ZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI2MSk+PgplbmRvYmoKNjE3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDI3Nz4+XQovSUQgKG5vZGUwMDAwMTA1OCk+PgplbmRvYmoKNjE4IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MTYgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI3OD4+XQovSUQgKG5vZGUwMDAwMTA2MCk+PgplbmRvYmoK NjE2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDYxMCAwIFIKL0sgWzYxNyAw IFIgNjE4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9k ZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAo bm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0 KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMDYyNCk+PgplbmRvYmoKNjEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RSCi9QIDM0IDAgUgovSyBbNjExIDAgUiA2MTQgMCBSIDYxNiAwIFJdCi9JRCAobm9kZTAw MDAxMjYwKT4+CmVuZG9iago2MjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDYyMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjc5Pj5dCi9J RCAobm9kZTAwMDAxMDYxKT4+CmVuZG9iago2MjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDYyMCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQg MjgwPj5dCi9JRCAobm9kZTAwMDAxMDYzKT4+CmVuZG9iago2MjAgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgNjE5IDAgUgovSyBbNjIxIDAgUiA2MjIgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAz MjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAw MDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjI3KT4+CmVu ZG9iago2MjQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDYyMyAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjgxPj5dCi9JRCAobm9kZTAwMDAx MDY0KT4+CmVuZG9iago2MjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjE5 IDAgUgovSyBbNjI0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTI2Myk+PgplbmRvYmoKNjI2IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA2MjUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDI4Mj4+XQovSUQgKG5vZGUwMDAwMTA2NSk+PgplbmRvYmoKNjI3IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MjUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDI4Mz4+XQovSUQgKG5vZGUwMDAwMTA2Nyk+PgplbmRvYmoKNjI1IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDYxOSAwIFIKL0sgWzYyNiAwIFIgNjI3 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAw MjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAw MDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMDYyOCk+PgplbmRvYmoKNjE5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbNjIwIDAgUiA2MjMgMCBSIDYyNSAwIFJdCi9JRCAobm9kZTAwMDAxMjYy KT4+CmVuZG9iago2MzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDYyOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjg0Pj5dCi9JRCAobm9k ZTAwMDAxMDY4KT4+CmVuZG9iago2MzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDYyOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjg1Pj5d Ci9JRCAobm9kZTAwMDAxMDcwKT4+CmVuZG9iago2MjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgNjI4IDAgUgovSyBbNjMwIDAgUiA2MzEgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChu b2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjMxKT4+CmVuZG9iago2 MzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDYzMiAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjg2Pj5dCi9JRCAobm9kZTAwMDAxMDcxKT4+ CmVuZG9iago2MzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjI4IDAgUgov SyBbNjMzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9k ZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAo bm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUz KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTI2NSk+PgplbmRvYmoKNjM1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCA2MzQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDI4Nz4+XQovSUQgKG5vZGUwMDAwMTA3Mik+PgplbmRvYmoKNjM2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2MzQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDI4OD4+XQovSUQgKG5vZGUwMDAwMTA3NCk+PgplbmRvYmoKNjM0IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDYyOCAwIFIKL0sgWzYzNSAwIFIgNjM2IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAo bm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIw KSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MDYzMik+PgplbmRvYmoKNjI4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0 IDAgUgovSyBbNjI5IDAgUiA2MzIgMCBSIDYzNCAwIFJdCi9JRCAobm9kZTAwMDAxMjY0KT4+CmVu ZG9iago2MzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDYzOCAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjg5Pj5dCi9JRCAobm9kZTAwMDAx MDc1KT4+CmVuZG9iago2NDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDYzOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjkwPj5dCi9JRCAo bm9kZTAwMDAxMDc3KT4+CmVuZG9iago2MzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgNjM3IDAgUgovSyBbNjM5IDAgUiA2NDAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAw MDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjM1KT4+CmVuZG9iago2NDIgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY0MSAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjkxPj5dCi9JRCAobm9kZTAwMDAxMDc4KT4+CmVuZG9i ago2NDEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjM3IDAgUgovSyBbNjQy IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAx MTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAw MDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMTI2Nyk+PgplbmRvYmoKNjQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCA2NDMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI5Mj4+ XQovSUQgKG5vZGUwMDAwMTA3OSk+PgplbmRvYmoKNjQ1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA2NDMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDI5Mz4+XQovSUQgKG5vZGUwMDAwMTA4MSk+PgplbmRvYmoKNjQzIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDYzNyAwIFIKL0sgWzY0NCAwIFIgNjQ1IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAw MDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9k ZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDYzNik+ PgplbmRvYmoKNjM3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgov SyBbNjM4IDAgUiA2NDEgMCBSIDY0MyAwIFJdCi9JRCAobm9kZTAwMDAxMjY2KT4+CmVuZG9iago2 NDggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY0NyAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjk0Pj5dCi9JRCAobm9kZTAwMDAxMDgyKT4+ CmVuZG9iago2NDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY0 NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjk1Pj5dCi9JRCAobm9kZTAw MDAxMDg0KT4+CmVuZG9iago2NDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag NjQ2IDAgUgovSyBbNjQ4IDAgUiA2NDkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhu b2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMp IChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIy NDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJs ZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjM5KT4+CmVuZG9iago2NTEgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY1MCAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMiAwIFIKL01DSUQgMjk2Pj5dCi9JRCAobm9kZTAwMDAxMDg1KT4+CmVuZG9iago2NTAg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjQ2IDAgUgovSyBbNjUxIDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAo bm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5 KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MTI2OSk+PgplbmRvYmoKNjUzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA2NTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI5Nz4+XQovSUQg KG5vZGUwMDAwMTA4Nik+PgplbmRvYmoKNjU0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA2NTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDI5 OD4+XQovSUQgKG5vZGUwMDAwMTA4OCk+PgplbmRvYmoKNjUyIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDY0NiAwIFIKL0sgWzY1MyAwIFIgNjU0IDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIz KSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAy MDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDY0MCk+PgplbmRv YmoKNjQ2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNjQ3 IDAgUiA2NTAgMCBSIDY1MiAwIFJdCi9JRCAobm9kZTAwMDAxMjY4KT4+CmVuZG9iago2NTcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY1NiAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMjk5Pj5dCi9JRCAobm9kZTAwMDAxMDg5KT4+CmVuZG9i ago2NTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjU1IDAgUgovSyBbNjU3 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAx MTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAw MDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMTI3MSk+PgplbmRvYmoKNjU1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbNjU2IDAgUl0KL0lEIChub2RlMDAwMDEyNzApPj4KZW5kb2JqCjY2MCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNjU5IDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMDA+Pl0KL0lEIChub2RlMDAwMDEwOTApPj4KZW5k b2JqCjY1OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA2NTggMCBSCi9LIFs2 NjAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAw MDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2Rl MDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAwNjQ3KT4+CmVuZG9iago2NjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDY2MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzAx Pj5dCi9JRCAobm9kZTAwMDAxMDkxKT4+CmVuZG9iago2NjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgNjU4IDAgUgovSyBbNjYyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTI3Myk+PgplbmRvYmoKNjY0IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2NjMgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMwMj4+XQovSUQgKG5vZGUwMDAwMTA5Mik+PgplbmRv YmoKNjYzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDY1OCAwIFIKL0sgWzY2 NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAw MDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUw MDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDA2NDgpPj4KZW5kb2JqCjY1OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U UgovUCAzNCAwIFIKL0sgWzY1OSAwIFIgNjYxIDAgUiA2NjMgMCBSXQovSUQgKG5vZGUwMDAwMTI3 Mik+PgplbmRvYmoKNjY3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA2NjYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMwMz4+XQovSUQgKG5v ZGUwMDAwMTA5Myk+PgplbmRvYmoKNjY2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDY2NSAwIFIKL0sgWzY2NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyNzUpPj4KZW5kb2JqCjY2NSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzY2NiAwIFJdCi9JRCAobm9kZTAwMDAx Mjc0KT4+CmVuZG9iago2NzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDY2OSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzA0Pj5dCi9JRCAo bm9kZTAwMDAxMDk0KT4+CmVuZG9iago2NjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgNjY4IDAgUgovSyBbNjcwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAo bm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDY1NSk+PgplbmRvYmoKNjcyIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2NzEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDMwNT4+XQovSUQgKG5vZGUwMDAwMTA5NSk+PgplbmRvYmoKNjcxIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDY2OCAwIFIKL0sgWzY3MiAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5v ZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkg KG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEy NzcpPj4KZW5kb2JqCjY3NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgNjczIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMDY+Pl0KL0lEIChu b2RlMDAwMDEwOTYpPj4KZW5kb2JqCjY3MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCA2NjggMCBSCi9LIFs2NzQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChu b2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjU2KT4+CmVuZG9iago2NjggMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs2NjkgMCBSIDY3MSAwIFIgNjczIDAg Ul0KL0lEIChub2RlMDAwMDEyNzYpPj4KZW5kb2JqCjY3NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNjc2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgov TUNJRCAzMDc+Pl0KL0lEIChub2RlMDAwMDEwOTcpPj4KZW5kb2JqCjY3NiAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA2NzUgMCBSCi9LIFs2NzcgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIp IChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIw MTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjU5KT4+CmVuZG9i ago2NzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY3OCAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzA4Pj5dCi9JRCAobm9kZTAwMDAxMDk4 KT4+CmVuZG9iago2NzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjc1IDAg UgovSyBbNjc5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAo bm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgz KSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMTI3OSk+PgplbmRvYmoKNjgxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA2ODAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9N Q0lEIDMwOT4+XQovSUQgKG5vZGUwMDAwMTA5OSk+PgplbmRvYmoKNjgwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDY3NSAwIFIKL0sgWzY4MSAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykg KG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAx OSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDA2NjApPj4KZW5kb2Jq CjY3NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzY3NiAw IFIgNjc4IDAgUiA2ODAgMCBSXQovSUQgKG5vZGUwMDAwMTI3OCk+PgplbmRvYmoKNjg0IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2ODMgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMxMD4+XQovSUQgKG5vZGUwMDAwMTEwMCk+PgplbmRvYmoK NjgzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDY4MiAwIFIKL0sgWzY4NCAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2 NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAw MTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDA2NjMpPj4KZW5kb2JqCjY4NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgNjg1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMTE+Pl0K L0lEIChub2RlMDAwMDExMDEpPj4KZW5kb2JqCjY4NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCA2ODIgMCBSCi9LIFs2ODYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEy OTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMjgxKT4+CmVuZG9iago2ODggMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY4NyAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMzEyPj5dCi9JRCAobm9kZTAwMDAxMTAyKT4+CmVuZG9iago2 ODcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjgyIDAgUgovSyBbNjg4IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3 KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAx ODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDY2NCk+PgplbmRvYmoKNjgyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9Q IDM0IDAgUgovSyBbNjgzIDAgUiA2ODUgMCBSIDY4NyAwIFJdCi9JRCAobm9kZTAwMDAxMjgwKT4+ CmVuZG9iago2OTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY5 MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzEzPj5dCi9JRCAobm9kZTAw MDAxMTAzKT4+CmVuZG9iago2OTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag Njg5IDAgUgovSyBbNjkxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAw MDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMDY2Nyk+PgplbmRvYmoKNjkzIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA2OTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIg MCBSCi9NQ0lEIDMxND4+XQovSUQgKG5vZGUwMDAwMTEwNCk+PgplbmRvYmoKNjkyIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDY4OSAwIFIKL0sgWzY5MyAwIFJdCi9BIFs8PC9P IC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAw MTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUw MDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyODMpPj4K ZW5kb2JqCjY5NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNjk0 IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMTU+Pl0KL0lEIChub2RlMDAw MDExMDUpPj4KZW5kb2JqCjY5NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA2 ODkgMCBSCi9LIFs2OTUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAw MDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAwNjY4KT4+CmVuZG9iago2ODkgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs2OTAgMCBSIDY5MiAwIFIgNjk0IDAgUl0KL0lE IChub2RlMDAwMDEyODIpPj4KZW5kb2JqCjY5OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgNjk3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAz MTY+Pl0KL0lEIChub2RlMDAwMDExMDYpPj4KZW5kb2JqCjY5NyAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9URAovUCA2OTYgMCBSCi9LIFs2OTggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjcxKT4+CmVuZG9iago3MDAg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDY5OSAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzE3Pj5dCi9JRCAobm9kZTAwMDAxMTA3KT4+CmVu ZG9iago2OTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNjk2IDAgUgovSyBb NzAwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAw MDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9k ZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTI4NSk+PgplbmRvYmoKNzAyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA3MDEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMx OD4+XQovSUQgKG5vZGUwMDAwMTEwOCk+PgplbmRvYmoKNzAxIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDY5NiAwIFIKL0sgWzcwMiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDA2NzIpPj4KZW5kb2JqCjY5NiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzY5NyAwIFIgNjk5 IDAgUiA3MDEgMCBSXQovSUQgKG5vZGUwMDAwMTI4NCk+PgplbmRvYmoKNzA1IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3MDQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDIgMCBSCi9NQ0lEIDMxOT4+XQovSUQgKG5vZGUwMDAwMTEwOSk+PgplbmRvYmoKNzA0IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDcwMyAwIFIKL0sgWzcwNSAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5v ZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkg KG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEy ODcpPj4KZW5kb2JqCjcwMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAw IFIKL0sgWzcwNCAwIFJdCi9JRCAobm9kZTAwMDAxMjg2KT4+CmVuZG9iago3MDggMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDcwNyAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMiAwIFIKL01DSUQgMzIwPj5dCi9JRCAobm9kZTAwMDAxMTEwKT4+CmVuZG9iago3MDcg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNzA2IDAgUgovSyBbNzA4IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAo bm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1 KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MDY3OSk+PgplbmRvYmoKNzEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA3MDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMyMT4+XQovSUQg KG5vZGUwMDAwMTExMSk+PgplbmRvYmoKNzA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDcwNiAwIFIKL0sgWzcxMCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyODkpPj4KZW5kb2JqCjcxMiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzExIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAyIDAgUgovTUNJRCAzMjI+Pl0KL0lEIChub2RlMDAwMDExMTIpPj4KZW5kb2JqCjcxMSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3MDYgMCBSCi9LIFs3MTIgMCBSXQov QSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChu b2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjAp IChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1Rh YmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAw MzkzKT4+CmVuZG9iago3MDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQg MCBSCi9LIFs3MDcgMCBSIDcwOSAwIFIgNzExIDAgUl0KL0lEIChub2RlMDAwMDEyODgpPj4KZW5k b2JqCjcxNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzE0IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMjM+Pl0KL0lEIChub2RlMDAwMDEx MTMpPj4KZW5kb2JqCjcxNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3MTMg MCBSCi9LIFs3MTUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcp IChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1 ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAw MDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAx Pj5dCi9JRCAobm9kZTAwMDAxMjkxKT4+CmVuZG9iago3MTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3MTQgMCBSXQovSUQgKG5vZGUwMDAwMTI5MCk+Pgpl bmRvYmoKNzE4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3MTcg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMyND4+XQovSUQgKG5vZGUwMDAw MTExNSk+PgplbmRvYmoKNzIwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA3MTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMyNT4+XQovSUQg KG5vZGUwMDAwMTExNik+PgplbmRvYmoKNzE5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L0xpbmsKL1AgNzE3IDAgUgovSyBbNzIwIDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogMTUgMCBSCi9Q ZyAyIDAgUj4+XQovSUQgKG5vZGUwMDAwMTExNCk+PgplbmRvYmoKNzE3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RICi9QIDcxNiAwIFIKL0sgWzcxOCAwIFIgNzE5IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEyOTMpPj4KZW5kb2JqCjcyMiAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzIxIDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMjY+Pl0KL0lEIChub2RlMDAwMDExMTgpPj4KZW5kb2Jq CjcyNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzIzIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMjc+Pl0KL0lEIChub2RlMDAwMDExMTkp Pj4KZW5kb2JqCjcyMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9MaW5rCi9QIDcyMSAw IFIKL0sgWzcyNCAwIFIgPDwvVHlwZSAvT0JKUgovT2JqIDE2IDAgUgovUGcgMiAwIFI+Pl0KL0lE IChub2RlMDAwMDExMTcpPj4KZW5kb2JqCjcyMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9USAovUCA3MTYgMCBSCi9LIFs3MjIgMCBSIDcyMyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovU2Nv cGUgL0NvbHVtbj4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxMjk1KT4+CmVuZG9iago3MTYgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3MTcgMCBSIDcyMSAwIFJdCi9JRCAobm9kZTAw MDAwNDE3KT4+CmVuZG9iago3MjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDcyNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzI4Pj5dCi9J RCAobm9kZTAwMDAxMTIwKT4+CmVuZG9iago3MjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgNzI1IDAgUgovSyBbNzI3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkz KSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDY4Nik+PgplbmRvYmoKNzI5IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3MjggMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDMyOT4+XQovSUQgKG5vZGUwMDAwMTEyMSk+PgplbmRvYmoKNzI4 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDcyNSAwIFIKL0sgWzcyOSAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3Mikg KG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgx OSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDEyOTgpPj4KZW5kb2JqCjczMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgNzMwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMzA+Pl0KL0lE IChub2RlMDAwMDExMjIpPj4KZW5kb2JqCjczMCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCA3MjUgMCBSCi9LIFs3MzEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhu b2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUp IChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIy NDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJs ZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzk1KT4+CmVuZG9iago3MjUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3MjYgMCBSIDcyOCAwIFIgNzMw IDAgUl0KL0lEIChub2RlMDAwMDEyOTcpPj4KZW5kb2JqCjczNCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzMzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAg UgovTUNJRCAzMzE+Pl0KL0lEIChub2RlMDAwMDExMjMpPj4KZW5kb2JqCjczMyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3MzIgMCBSCi9LIFs3MzQgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAz MjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAw MDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjg5KT4+CmVu ZG9iago3MzYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDczNSAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzMyPj5dCi9JRCAobm9kZTAwMDAx MTI0KT4+CmVuZG9iago3MzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNzMy IDAgUgovSyBbNzM2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTMwMCk+PgplbmRvYmoKNzM4IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA3MzcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBS Ci9NQ0lEIDMzMz4+XQovSUQgKG5vZGUwMDAwMTEyNSk+PgplbmRvYmoKNzM3IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDczMiAwIFIKL0sgWzczOCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMy MykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAw MjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDA2OTApPj4KZW5k b2JqCjczMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzcz MyAwIFIgNzM1IDAgUiA3MzcgMCBSXQovSUQgKG5vZGUwMDAwMTI5OSk+PgplbmRvYmoKNzQxIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3NDAgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDMzND4+XQovSUQgKG5vZGUwMDAwMTEyNik+PgplbmRv YmoKNzQwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDczOSAwIFIKL0sgWzc0 MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAw MDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUw MDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDA2OTMpPj4KZW5kb2JqCjc0MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgNzQyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMzU+ Pl0KL0lEIChub2RlMDAwMDExMjcpPj4KZW5kb2JqCjc0MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCA3MzkgMCBSCi9LIFs3NDMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAw MDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzAyKT4+CmVuZG9iago3NDUgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc0NCAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzM2Pj5dCi9JRCAobm9kZTAwMDAxMTI4KT4+CmVuZG9i ago3NDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNzM5IDAgUgovSyBbNzQ1 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAw MjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAw MDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMDY5NCk+PgplbmRvYmoKNzM5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbNzQwIDAgUiA3NDIgMCBSIDc0NCAwIFJdCi9JRCAobm9kZTAwMDAxMzAx KT4+CmVuZG9iago3NDggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDc0NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzM3Pj5dCi9JRCAobm9k ZTAwMDAxMTI5KT4+CmVuZG9iago3NDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgNzQ2IDAgUgovSyBbNzQ4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9k ZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMDY5Nyk+PgplbmRvYmoKNzUwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3NDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDIgMCBSCi9NQ0lEIDMzOD4+XQovSUQgKG5vZGUwMDAwMTEzMCk+PgplbmRvYmoKNzQ5IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDc0NiAwIFIKL0sgWzc1MCAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUw MDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5v ZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEzMDQp Pj4KZW5kb2JqCjc1MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag NzUxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzMzk+Pl0KL0lEIChub2Rl MDAwMDExMzEpPj4KZW5kb2JqCjc1MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCA3NDYgMCBSCi9LIFs3NTIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2Rl MDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNjk4KT4+CmVuZG9iago3NDYgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3NDcgMCBSIDc0OSAwIFIgNzUxIDAgUl0K L0lEIChub2RlMDAwMDEzMDMpPj4KZW5kb2JqCjc1NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgNzU0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJ RCAzNDA+Pl0KL0lEIChub2RlMDAwMDExMzIpPj4KZW5kb2JqCjc1NCAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCA3NTMgMCBSCi9LIFs3NTUgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChu b2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNzAxKT4+CmVuZG9iago3 NTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc1NiAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzQxPj5dCi9JRCAobm9kZTAwMDAxMTMzKT4+ CmVuZG9iago3NTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNzUzIDAgUgov SyBbNzU3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9k ZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAo bm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUz KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTMwNik+PgplbmRvYmoKNzU5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCA3NTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lE IDM0Mj4+XQovSUQgKG5vZGUwMDAwMTEzNCk+PgplbmRvYmoKNzU4IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDc1MyAwIFIKL0sgWzc1OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQov SGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5v ZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkg KG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDA3MDIpPj4KZW5kb2JqCjc1 MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzc1NCAwIFIg NzU2IDAgUiA3NTggMCBSXQovSUQgKG5vZGUwMDAwMTMwNSk+PgplbmRvYmoKNzYyIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3NjEgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDIgMCBSCi9NQ0lEIDM0Mz4+XQovSUQgKG5vZGUwMDAwMTEzNSk+PgplbmRvYmoKNzYx IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDc2MCAwIFIKL0sgWzc2MiAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3Mikg KG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgx OSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDEzMDgpPj4KZW5kb2JqCjc2MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAz NCAwIFIKL0sgWzc2MSAwIFJdCi9JRCAobm9kZTAwMDAxMzA3KT4+CmVuZG9iago3NjUgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc2NCAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMiAwIFIKL01DSUQgMzQ0Pj5dCi9JRCAobm9kZTAwMDAxMTM2KT4+CmVuZG9iago3 NjQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgNzYzIDAgUgovSyBbNzY1IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2 KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAx ODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMDcwOSk+PgplbmRvYmoKNzY3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA3NjYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDM0NT4+XQov SUQgKG5vZGUwMDAwMTEzNyk+PgplbmRvYmoKNzY2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDc2MyAwIFIKL0sgWzc2NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5 NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEzMTApPj4KZW5kb2JqCjc2OSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzY4IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAyIDAgUgovTUNJRCAzNDY+Pl0KL0lEIChub2RlMDAwMDExMzgpPj4KZW5kb2JqCjc2 OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3NjMgMCBSCi9LIFs3NjkgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcp IChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4 MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAwNzEwKT4+CmVuZG9iago3NjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1Ag MzQgMCBSCi9LIFs3NjQgMCBSIDc2NiAwIFIgNzY4IDAgUl0KL0lEIChub2RlMDAwMDEzMDkpPj4K ZW5kb2JqCjc3MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzcx IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAyIDAgUgovTUNJRCAzNDc+Pl0KL0lEIChub2RlMDAw MDExMzkpPj4KZW5kb2JqCjc3MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3 NzAgMCBSCi9LIFs3NzIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxMzEyKT4+CmVuZG9iago3NzAgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3NzEgMCBSXQovSUQgKG5vZGUwMDAwMTMxMSk+ PgplbmRvYmoKNzc1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3 NzQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDIgMCBSCi9NQ0lEIDM0OD4+XQovSUQgKG5vZGUw MDAwMTE0MCk+PgplbmRvYmoKNzc0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDc3MyAwIFIKL0sgWzc3NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUw MDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDA3MTcpPj4KZW5kb2JqCjc3NyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzc2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAy IDAgUgovTUNJRCAzNDk+Pl0KL0lEIChub2RlMDAwMDExNDEpPj4KZW5kb2JqCjc3NiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3NzMgMCBSCi9LIFs3NzcgMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAw MDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2Rl MDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzE0KT4+ CmVuZG9iago3NzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc3 OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQgMzUwPj5dCi9JRCAobm9kZTAw MDAxMTQyKT4+CmVuZG9iago3NzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag NzczIDAgUgovSyBbNzc5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAw MDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMDcxOCk+PgplbmRvYmoKNzczIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNzc0IDAgUiA3NzYgMCBSIDc3OCAwIFJdCi9J RCAobm9kZTAwMDAxMzEzKT4+CmVuZG9iago3ODIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDc4MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMiAwIFIKL01DSUQg MzUxPj5dCi9JRCAobm9kZTAwMDAxMTQzKT4+CmVuZG9iago3ODEgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgNzgwIDAgUgovSyBbNzgyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9k ZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTMxNik+PgplbmRvYmoKNzgw IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbNzgxIDAgUl0K L0lEIChub2RlMDAwMDEzMTUpPj4KZW5kb2JqCjc4NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgNzg0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01D SUQgMD4+XQovSUQgKG5vZGUwMDAwMTMyMCk+PgplbmRvYmoKNzg2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3ODQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4 IDAgUgovTUNJRCAxPj5dCi9JRCAobm9kZTAwMDAxMzIxKT4+CmVuZG9iago3ODcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc4NCAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMTggMCBSCi9NQ0lEIDI+Pl0KL0lEIChub2RlMDAwMDEzMjIpPj4KZW5kb2JqCjc4NCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3ODMgMCBSCi9LIFs3ODUgMCBSIDc4 NiAwIFIgNzg3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAo bm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5 KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMDcyNSk+PgplbmRvYmoKNzg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA3ODggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCAzPj5dCi9JRCAobm9kZTAwMDAxMzI0KT4+CmVuZG9iago3ODggMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgNzgzIDAgUgovSyBbNzg5IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAo bm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTMyMyk+PgplbmRvYmoK NzkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3OTAgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA0Pj5dCi9JRCAobm9kZTAwMDAxMzI1KT4+ CmVuZG9iago3OTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc5 MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDU+Pl0KL0lEIChub2RlMDAw MDEzMjYpPj4KZW5kb2JqCjc5MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgNzkwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNj4+XQovSUQg KG5vZGUwMDAwMTMyNyk+PgplbmRvYmoKNzkwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDc4MyAwIFIKL0sgWzc5MSAwIFIgNzkyIDAgUiA3OTMgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMp IChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIw MTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNzI2KT4+CmVuZG9i ago3ODMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3ODQg MCBSIDc4OCAwIFIgNzkwIDAgUl0KL0lEIChub2RlMDAwMDEzMTkpPj4KZW5kb2JqCjc5NiAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgNzk1IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNz4+XQovSUQgKG5vZGUwMDAwMTMzMSk+PgplbmRvYmoK Nzk3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3OTUgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA4Pj5dCi9JRCAobm9kZTAwMDAxMzMyKT4+ CmVuZG9iago3OTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDc5 NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDk+Pl0KL0lEIChub2RlMDAw MDEzMzMpPj4KZW5kb2JqCjc5NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA3 OTQgMCBSCi9LIFs3OTYgMCBSIDc5NyAwIFIgNzk4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAw MDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTMzMCk+PgplbmRvYmoKODAwIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA3OTkgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMD4+XQovSUQgKG5vZGUwMDAwMTMzNSk+PgplbmRv YmoKNzk5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDc5NCAwIFIKL0sgWzgw MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAw MTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUw MDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDEzMzQpPj4KZW5kb2JqCjgwMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgODAxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTE+ Pl0KL0lEIChub2RlMDAwMDEzMzcpPj4KZW5kb2JqCjgwMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCA3OTQgMCBSCi9LIFs4MDIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAw MDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzM2KT4+CmVuZG9iago3OTQgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs3OTUgMCBSIDc5OSAw IFIgODAxIDAgUl0KL0lEIChub2RlMDAwMDEzMjgpPj4KZW5kb2JqCjgwNSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODA0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMTI+Pl0KL0lEIChub2RlMDAwMDEzNDIpPj4KZW5kb2JqCjgwNCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4MDMgMCBSCi9LIFs4MDUgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2Rl MDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChu b2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzQx KT4+CmVuZG9iago4MDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDgwNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDEzPj5dCi9JRCAobm9k ZTAwMDAxMzQ0KT4+CmVuZG9iago4MDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgODAzIDAgUgovSyBbODA3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9k ZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTM0Myk+PgplbmRvYmoKODA5IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4MDggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDE4IDAgUgovTUNJRCAxND4+XQovSUQgKG5vZGUwMDAwMTM0Nik+PgplbmRvYmoKODA4IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgwMyAwIFIKL0sgWzgwOSAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEzNDUp Pj4KZW5kb2JqCjgwMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIK L0sgWzgwNCAwIFIgODA2IDAgUiA4MDggMCBSXQovSUQgKG5vZGUwMDAwMTMzOSk+PgplbmRvYmoK ODEyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4MTEgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNT4+XQovSUQgKG5vZGUwMDAwMTM1MSk+ PgplbmRvYmoKODExIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgxMCAwIFIK L0sgWzgxMiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5v ZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkg KG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDEzNTApPj4KZW5kb2JqCjgxNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgODEzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01D SUQgMTY+Pl0KL0lEIChub2RlMDAwMDEzNTMpPj4KZW5kb2JqCjgxMyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCA4MTAgMCBSCi9LIFs4MTQgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChu b2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzUyKT4+CmVuZG9iago4 MTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDgxNSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE3Pj5dCi9JRCAobm9kZTAwMDAxMzU1KT4+ CmVuZG9iago4MTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODEwIDAgUgov SyBbODE2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9k ZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAo bm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0 KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTM1NCk+PgplbmRvYmoKODEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RSCi9QIDM0IDAgUgovSyBbODExIDAgUiA4MTMgMCBSIDgxNSAwIFJdCi9JRCAobm9kZTAw MDAxMzQ4KT4+CmVuZG9iago4MTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDgxOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE4Pj5dCi9J RCAobm9kZTAwMDAxMzYwKT4+CmVuZG9iago4MTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgODE3IDAgUgovSyBbODE5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkz KSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTM1OSk+PgplbmRvYmoKODIxIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4MjAgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAxOT4+XQovSUQgKG5vZGUwMDAwMTM2Mik+PgplbmRvYmoKODIw IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgxNyAwIFIKL0sgWzgyMSAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3Mikg KG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgx OSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDEzNjEpPj4KZW5kb2JqCjgyMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgODIyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjA+Pl0KL0lE IChub2RlMDAwMDEzNjQpPj4KZW5kb2JqCjgyMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCA4MTcgMCBSCi9LIFs4MjMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhu b2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUp IChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIy NDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJs ZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzYzKT4+CmVuZG9iago4MTcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs4MTggMCBSIDgyMCAwIFIgODIy IDAgUl0KL0lEIChub2RlMDAwMDEzNTcpPj4KZW5kb2JqCjgyNiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODI1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgMjE+Pl0KL0lEIChub2RlMDAwMDEzNjkpPj4KZW5kb2JqCjgyNSAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4MjQgMCBSCi9LIFs4MjYgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAz MjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAw MDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzY4KT4+CmVu ZG9iago4MjggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDgyNyAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIyPj5dCi9JRCAobm9kZTAwMDAx MzcxKT4+CmVuZG9iago4MjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODI0 IDAgUgovSyBbODI4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTM3MCk+PgplbmRvYmoKODMwIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA4MjkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAg UgovTUNJRCAyMz4+XQovSUQgKG5vZGUwMDAwMTM3Myk+PgplbmRvYmoKODI5IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgyNCAwIFIKL0sgWzgzMCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMy MykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAw MjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEzNzIpPj4KZW5k b2JqCjgyNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzgy NSAwIFIgODI3IDAgUiA4MjkgMCBSXQovSUQgKG5vZGUwMDAwMTM2Nik+PgplbmRvYmoKODMzIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4MzIgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyND4+XQovSUQgKG5vZGUwMDAwMTM3OCk+PgplbmRv YmoKODMyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDgzMSAwIFIKL0sgWzgz MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAw MDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUw MDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDEzNzcpPj4KZW5kb2JqCjgzNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgODM0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjU+ Pl0KL0lEIChub2RlMDAwMDEzODApPj4KZW5kb2JqCjgzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCA4MzEgMCBSCi9LIFs4MzUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAw MDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzc5KT4+CmVuZG9iago4MzcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDgzNiAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI2Pj5dCi9JRCAobm9kZTAwMDAxMzgyKT4+CmVuZG9i ago4MzYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODMxIDAgUgovSyBbODM3 IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAw MjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAw MDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMTM4MSk+PgplbmRvYmoKODMxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbODMyIDAgUiA4MzQgMCBSIDgzNiAwIFJdCi9JRCAobm9kZTAwMDAxMzc1 KT4+CmVuZG9iago4NDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDgzOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI3Pj5dCi9JRCAobm9k ZTAwMDAxMzg4KT4+CmVuZG9iago4MzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgODM4IDAgUgovSyBbODQwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9k ZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTM4Nyk+PgplbmRvYmoKODM4IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbODM5IDAgUl0KL0lEIChub2RlMDAwMDEz ODQpPj4KZW5kb2JqCjg0MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgODQyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjg+Pl0KL0lEIChu b2RlMDAwMDEzOTQpPj4KZW5kb2JqCjg0MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCA4NDEgMCBSCi9LIFs4NDMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxMzkzKT4+CmVuZG9iago4NDUgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDg0NCAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMTggMCBSCi9NQ0lEIDI5Pj5dCi9JRCAobm9kZTAwMDAxMzk2KT4+CmVuZG9iago4NDQgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODQxIDAgUgovSyBbODQ1IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTM5 NSk+PgplbmRvYmoKODQ3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA4NDYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAzMD4+XQovSUQgKG5v ZGUwMDAwMTM5OCk+PgplbmRvYmoKODQ2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDg0MSAwIFIKL0sgWzg0NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5v ZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDEzOTcpPj4KZW5kb2JqCjg0MSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzg0MiAwIFIgODQ0IDAgUiA4NDYgMCBS XQovSUQgKG5vZGUwMDAwMTM5MSk+PgplbmRvYmoKODUwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA4NDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCAzMT4+XQovSUQgKG5vZGUwMDAwMTQwNSk+PgplbmRvYmoKODUxIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4NDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDE4IDAgUgovTUNJRCAzMj4+XQovSUQgKG5vZGUwMDAwMTQwNik+PgplbmRvYmoKODQ5IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDg0OCAwIFIKL0sgWzg1MCAwIFIgODUxIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2 KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAx ODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMTQwNCk+PgplbmRvYmoKODUzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA4NTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAzMz4+XQov SUQgKG5vZGUwMDAwMTQwOCk+PgplbmRvYmoKODUyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDg0OCAwIFIKL0sgWzg1MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5 NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE0MDcpPj4KZW5kb2JqCjg1NSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODU0IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAxOCAwIFIKL01DSUQgMzQ+Pl0KL0lEIChub2RlMDAwMDE0MTApPj4KZW5kb2JqCjg1 NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODU0IDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMzU+Pl0KL0lEIChub2RlMDAwMDE0MTEpPj4K ZW5kb2JqCjg1NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4NDggMCBSCi9L IFs4NTUgMCBSIDg1NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAw MTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDE0MDkpPj4KZW5kb2JqCjg0OCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzg0OSAwIFIgODUyIDAgUiA4NTQgMCBSXQovSUQg KG5vZGUwMDAwMTQwMik+PgplbmRvYmoKODU5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA4NTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAz Nj4+XQovSUQgKG5vZGUwMDAwMTQxNik+PgplbmRvYmoKODYwIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCA4NTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAg UgovTUNJRCAzNz4+XQovSUQgKG5vZGUwMDAwMTQxNyk+PgplbmRvYmoKODU4IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDg1NyAwIFIKL0sgWzg1OSAwIFIgODYwIDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9k ZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAo bm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQx NSk+PgplbmRvYmoKODYyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA4NjEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAzOD4+XQovSUQgKG5v ZGUwMDAwMTQxOSk+PgplbmRvYmoKODYxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDg1NyAwIFIKL0sgWzg2MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE0MTgpPj4KZW5kb2JqCjg2NCAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODYzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMzk+Pl0KL0lEIChub2RlMDAwMDE0MjEpPj4KZW5kb2JqCjg2NSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODYzIDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNDA+Pl0KL0lEIChub2RlMDAwMDE0MjIpPj4KZW5kb2Jq Cjg2MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4NTcgMCBSCi9LIFs4NjQg MCBSIDg2NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5v ZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkg KG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDE0MjApPj4KZW5kb2JqCjg1NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9UUgovUCAzNCAwIFIKL0sgWzg1OCAwIFIgODYxIDAgUiA4NjMgMCBSXQovSUQgKG5vZGUw MDAwMTQxMyk+PgplbmRvYmoKODY4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA4NjcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA0MT4+XQov SUQgKG5vZGUwMDAwMTQyNyk+PgplbmRvYmoKODY3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDg2NiAwIFIKL0sgWzg2OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5 MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE0MjYpPj4KZW5kb2JqCjg3MCAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODY5IDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAxOCAwIFIKL01DSUQgNDI+Pl0KL0lEIChub2RlMDAwMDE0MjkpPj4KZW5kb2JqCjg2 OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4NjYgMCBSCi9LIFs4NzAgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxNDI4KT4+CmVuZG9iago4NzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDg3MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDQzPj5dCi9J RCAobm9kZTAwMDAxNDMxKT4+CmVuZG9iago4NzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgODY2IDAgUgovSyBbODcyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1 KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQzMCk+PgplbmRvYmoKODY2IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbODY3IDAgUiA4NjkgMCBSIDg3 MSAwIFJdCi9JRCAobm9kZTAwMDAxNDI0KT4+CmVuZG9iago4NzUgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDg3NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDQ0Pj5dCi9JRCAobm9kZTAwMDAxNDM2KT4+CmVuZG9iago4NzQgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgODczIDAgUgovSyBbODc1IDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAw MzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAw MDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQzNSk+Pgpl bmRvYmoKODc3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4NzYg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA0NT4+XQovSUQgKG5vZGUwMDAw MTQzOCk+PgplbmRvYmoKODc2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDg3 MyAwIFIKL0sgWzg3NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0 NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAw MTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDE0MzcpPj4KZW5kb2JqCjg3OSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODc4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgNDY+Pl0KL0lEIChub2RlMDAwMDE0NDApPj4KZW5kb2JqCjg3OCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4NzMgMCBSCi9LIFs4NzkgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAz MjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAw MDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNDM5KT4+CmVu ZG9iago4NzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs4 NzQgMCBSIDg3NiAwIFIgODc4IDAgUl0KL0lEIChub2RlMDAwMDE0MzMpPj4KZW5kb2JqCjg4MiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODgxIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNDc+Pl0KL0lEIChub2RlMDAwMDE0NDUpPj4KZW5k b2JqCjg4MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4ODAgMCBSCi9LIFs4 ODIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAw MDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2Rl MDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAxNDQ0KT4+CmVuZG9iago4ODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDg4MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDQ4 Pj5dCi9JRCAobm9kZTAwMDAxNDQ3KT4+CmVuZG9iago4ODMgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgODgwIDAgUgovSyBbODg0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQ0Nik+PgplbmRvYmoKODg2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4ODUgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA0OT4+XQovSUQgKG5vZGUwMDAwMTQ0OCk+PgplbmRv YmoKODg1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDg4MCAwIFIKL0sgWzg4 NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAw MDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUw MDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDAzOTQpPj4KZW5kb2JqCjg4MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U UgovUCAzNCAwIFIKL0sgWzg4MSAwIFIgODgzIDAgUiA4ODUgMCBSXQovSUQgKG5vZGUwMDAwMTQ0 Mik+PgplbmRvYmoKODg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCA4ODggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA1MD4+XQovSUQgKG5v ZGUwMDAwMTQ1Myk+PgplbmRvYmoKODg4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDg4NyAwIFIKL0sgWzg4OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5v ZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE0NTIpPj4KZW5kb2JqCjg5MSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgODkwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgNTE+Pl0KL0lEIChub2RlMDAwMDE0NTUpPj4KZW5kb2JqCjg5MCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA4ODcgMCBSCi9LIFs4OTEgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2Rl MDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChu b2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNDU0 KT4+CmVuZG9iago4OTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDg5MiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDUyPj5dCi9JRCAobm9k ZTAwMDAxNDU3KT4+CmVuZG9iago4OTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgODg3IDAgUgovSyBbODkzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9k ZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQ1Nik+PgplbmRvYmoKODg3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbODg4IDAgUiA4OTAgMCBSIDg5MiAwIFJd Ci9JRCAobm9kZTAwMDAxNDUwKT4+CmVuZG9iago4OTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDg5NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9N Q0lEIDUzPj5dCi9JRCAobm9kZTAwMDAxNDYyKT4+CmVuZG9iago4OTUgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgODk0IDAgUgovSyBbODk2IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAo bm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQ2MSk+PgplbmRvYmoK ODk4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA4OTcgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA1ND4+XQovSUQgKG5vZGUwMDAwMTQ2NCk+ PgplbmRvYmoKODk3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDg5NCAwIFIK L0sgWzg5OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5v ZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4Mykg KG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDE0NjMpPj4KZW5kb2JqCjkwMCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgODk5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01D SUQgNTU+Pl0KL0lEIChub2RlMDAwMDE0NjYpPj4KZW5kb2JqCjg5OSAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCA4OTQgMCBSCi9LIFs5MDAgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChu b2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNDY1KT4+CmVuZG9iago4 OTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs4OTUgMCBS IDg5NyAwIFIgODk5IDAgUl0KL0lEIChub2RlMDAwMDE0NTkpPj4KZW5kb2JqCjkwMyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTAyIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAxOCAwIFIKL01DSUQgNTY+Pl0KL0lEIChub2RlMDAwMDE0NzEpPj4KZW5kb2JqCjkw MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5MDEgMCBSCi9LIFs5MDMgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYp IChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4 MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxNDcwKT4+CmVuZG9iago5MDUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDkwNCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDU3Pj5dCi9J RCAobm9kZTAwMDAxNDczKT4+CmVuZG9iago5MDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgOTAxIDAgUgovSyBbOTA1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0 KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQ3Mik+PgplbmRvYmoKOTA3IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5MDYgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCA1OD4+XQovSUQgKG5vZGUwMDAwMTQ3NCk+PgplbmRvYmoKOTA2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDkwMSAwIFIKL0sgWzkwNyAwIFJd Ci9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2Nykg KG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgy MCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAv VGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAw MDAzOTYpPj4KZW5kb2JqCjkwMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAz NCAwIFIKL0sgWzkwMiAwIFIgOTA0IDAgUiA5MDYgMCBSXQovSUQgKG5vZGUwMDAwMTQ2OCk+Pgpl bmRvYmoKOTEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5MDkg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA1OT4+XQovSUQgKG5vZGUwMDAw MTQ3OSk+PgplbmRvYmoKOTA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDkw OCAwIFIKL0sgWzkxMCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAw MTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDE0NzgpPj4KZW5kb2JqCjkxMiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTExIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgNjA+Pl0KL0lEIChub2RlMDAwMDE0ODEpPj4KZW5kb2JqCjkxMSAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5MDggMCBSCi9LIFs5MTIgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNDgwKT4+CmVu ZG9iago5MTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDkxMyAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDYxPj5dCi9JRCAobm9kZTAwMDAx NDgyKT4+CmVuZG9iago5MTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTA4 IDAgUgovSyBbOTE0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIx KSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAx NTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMDM5Nyk+PgplbmRvYmoKOTA4IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbOTA5IDAgUiA5MTEgMCBSIDkxMyAwIFJdCi9JRCAo bm9kZTAwMDAxNDc2KT4+CmVuZG9iago5MTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDkxNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDYy Pj5dCi9JRCAobm9kZTAwMDAxNDg4KT4+CmVuZG9iago5MTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgOTE1IDAgUgovSyBbOTE3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTQ4Nyk+PgplbmRvYmoKOTE1IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbOTE2IDAgUl0KL0lE IChub2RlMDAwMDE0ODQpPj4KZW5kb2JqCjkyMCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgOTE5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQg NjM+Pl0KL0lEIChub2RlMDAwMDE0OTQpPj4KZW5kb2JqCjkxOSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9URAovUCA5MTggMCBSCi9LIFs5MjAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNDkzKT4+CmVuZG9iago5MjIg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDkyMSAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDY0Pj5dCi9JRCAobm9kZTAwMDAxNDk2KT4+CmVu ZG9iago5MjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTE4IDAgUgovSyBb OTIyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAw MDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9k ZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTQ5NSk+PgplbmRvYmoKOTI0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA5MjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA2 NT4+XQovSUQgKG5vZGUwMDAwMTQ5OCk+PgplbmRvYmoKOTIzIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDkxOCAwIFIKL0sgWzkyNCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE0OTcpPj4KZW5kb2JqCjkxOCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzkxOSAwIFIgOTIx IDAgUiA5MjMgMCBSXQovSUQgKG5vZGUwMDAwMTQ5MSk+PgplbmRvYmoKOTI3IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5MjYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCA2Nj4+XQovSUQgKG5vZGUwMDAwMTUwMyk+PgplbmRvYmoKOTI2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDkyNSAwIFIKL0sgWzkyNyAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5v ZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkg KG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1 MDIpPj4KZW5kb2JqCjkyOSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgOTI4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNjc+Pl0KL0lEIChu b2RlMDAwMDE1MDUpPj4KZW5kb2JqCjkyOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCA5MjUgMCBSCi9LIFs5MjkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChu b2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNTA0KT4+CmVuZG9iago5MzEgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDkzMCAwIFIKL0sgWzw8L1R5cGUgL01DUgov UGcgMTggMCBSCi9NQ0lEIDY4Pj5dCi9JRCAobm9kZTAwMDAxNTA3KT4+CmVuZG9iago5MzAgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTI1IDAgUgovSyBbOTMxIDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9k ZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAo bm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTUw Nik+PgplbmRvYmoKOTI1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAg UgovSyBbOTI2IDAgUiA5MjggMCBSIDkzMCAwIFJdCi9JRCAobm9kZTAwMDAxNTAwKT4+CmVuZG9i ago5MzQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDkzMyAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDY5Pj5dCi9JRCAobm9kZTAwMDAxNTEy KT4+CmVuZG9iago5MzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTMyIDAg UgovSyBbOTM0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAo bm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5 KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMTUxMSk+PgplbmRvYmoKOTM2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCA5MzUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCA3MD4+XQovSUQgKG5vZGUwMDAwMTUxNCk+PgplbmRvYmoKOTM1IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDkzMiAwIFIKL0sgWzkzNiAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkg KG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAx OCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1MTMpPj4KZW5kb2Jq CjkzOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTM3IDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNzE+Pl0KL0lEIChub2RlMDAwMDE1MTYp Pj4KZW5kb2JqCjkzNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5MzIgMCBS Ci9LIFs5MzggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChu b2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQp IChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAxNTE1KT4+CmVuZG9iago5MzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVFIKL1AgMzQgMCBSCi9LIFs5MzMgMCBSIDkzNSAwIFIgOTM3IDAgUl0KL0lEIChub2Rl MDAwMDE1MDkpPj4KZW5kb2JqCjk0MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgOTQwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNzI+Pl0K L0lEIChub2RlMDAwMDE1MjEpPj4KZW5kb2JqCjk0MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCA5MzkgMCBSCi9LIFs5NDEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEy OTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNTIwKT4+CmVuZG9iago5NDMgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk0MiAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDczPj5dCi9JRCAobm9kZTAwMDAxNTIzKT4+CmVuZG9iago5 NDIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTM5IDAgUgovSyBbOTQzIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMTUyMik+PgplbmRvYmoKOTQ1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCA5NDQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA3ND4+XQov SUQgKG5vZGUwMDAwMTUyNSk+PgplbmRvYmoKOTQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDkzOSAwIFIKL0sgWzk0NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5 NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1MjQpPj4KZW5kb2JqCjkzOSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzk0MCAwIFIgOTQyIDAgUiA5 NDQgMCBSXQovSUQgKG5vZGUwMDAwMTUxOCk+PgplbmRvYmoKOTQ4IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5NDcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4 IDAgUgovTUNJRCA3NT4+XQovSUQgKG5vZGUwMDAwMTUzMCk+PgplbmRvYmoKOTQ3IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDk0NiAwIFIKL0sgWzk0OCAwIFJdCi9BIFs8PC9P IC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAw MDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUw MDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1MjkpPj4K ZW5kb2JqCjk1MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTQ5 IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgNzY+Pl0KL0lEIChub2RlMDAw MDE1MzIpPj4KZW5kb2JqCjk0OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5 NDYgMCBSCi9LIFs5NTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxNTMxKT4+CmVuZG9iago5NTIgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk1MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDc3Pj5dCi9JRCAobm9kZTAwMDAxNTM0KT4+CmVuZG9iago5NTEgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTQ2IDAgUgovSyBbOTUyIDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAw MzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAw MDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTUzMyk+Pgpl bmRvYmoKOTQ2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBb OTQ3IDAgUiA5NDkgMCBSIDk1MSAwIFJdCi9JRCAobm9kZTAwMDAxNTI3KT4+CmVuZG9iago5NTUg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk1NCAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDc4Pj5dCi9JRCAobm9kZTAwMDAxNTM5KT4+CmVu ZG9iago5NTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTUzIDAgUgovSyBb OTU1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAw MDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9k ZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTUzOCk+PgplbmRvYmoKOTU3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCA5NTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA3 OT4+XQovSUQgKG5vZGUwMDAwMTU0MSk+PgplbmRvYmoKOTU2IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDk1MyAwIFIKL0sgWzk1NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUw MDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1NDApPj4KZW5kb2JqCjk1OSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTU4IDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgODA+Pl0KL0lEIChub2RlMDAwMDE1NDMpPj4KZW5k b2JqCjk1OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5NTMgMCBSCi9LIFs5 NTkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAw MDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2Rl MDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAxNTQyKT4+CmVuZG9iago5NTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VFIKL1AgMzQgMCBSCi9LIFs5NTQgMCBSIDk1NiAwIFIgOTU4IDAgUl0KL0lEIChub2RlMDAwMDE1 MzYpPj4KZW5kb2JqCjk2MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgOTYxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgODE+Pl0KL0lEIChu b2RlMDAwMDE1NDkpPj4KZW5kb2JqCjk2MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCA5NjAgMCBSCi9LIFs5NjIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChu b2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNTQ4KT4+CmVuZG9iago5NjAgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs5NjEgMCBSXQovSUQgKG5vZGUwMDAw MTU0NSk+PgplbmRvYmoKOTY1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCA5NjQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA4Mj4+XQovSUQg KG5vZGUwMDAwMTU1NSk+PgplbmRvYmoKOTY0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDk2MyAwIFIKL0sgWzk2NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5Mykg KG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1NTQpPj4KZW5kb2JqCjk2NyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTY2IDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAxOCAwIFIKL01DSUQgODM+Pl0KL0lEIChub2RlMDAwMDE1NTcpPj4KZW5kb2JqCjk2NiAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5NjMgMCBSCi9LIFs5NjcgMCBSXQov QSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChu b2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkp IChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1Rh YmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAx NTU2KT4+CmVuZG9iago5NjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDk2OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDg0Pj5dCi9JRCAo bm9kZTAwMDAxNTU5KT4+CmVuZG9iago5NjggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgOTYzIDAgUgovSyBbOTY5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAo bm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTU1OCk+PgplbmRvYmoKOTYzIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbOTY0IDAgUiA5NjYgMCBSIDk2OCAw IFJdCi9JRCAobm9kZTAwMDAxNTUyKT4+CmVuZG9iago5NzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk3MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBS Ci9NQ0lEIDg1Pj5dCi9JRCAobm9kZTAwMDAxNTY0KT4+CmVuZG9iago5NzEgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgOTcwIDAgUgovSyBbOTcyIDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIy KSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAy MDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTU2Myk+PgplbmRv YmoKOTc0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5NzMgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA4Nj4+XQovSUQgKG5vZGUwMDAwMTU2 Nik+PgplbmRvYmoKOTczIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDk3MCAw IFIKL0sgWzk3NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0Nykg KG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4 MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDE1NjUpPj4KZW5kb2JqCjk3NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTc1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIK L01DSUQgODc+Pl0KL0lEIChub2RlMDAwMDE1NjgpPj4KZW5kb2JqCjk3NSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5NzAgMCBSCi9LIFs5NzYgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMp IChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIw MTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNTY3KT4+CmVuZG9i ago5NzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs5NzEg MCBSIDk3MyAwIFIgOTc1IDAgUl0KL0lEIChub2RlMDAwMDE1NjEpPj4KZW5kb2JqCjk3OSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTc4IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgODg+Pl0KL0lEIChub2RlMDAwMDE1NzQpPj4KZW5kb2Jq Cjk3OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5NzcgMCBSCi9LIFs5Nzkg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDEx NzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAw MDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAxNTczKT4+CmVuZG9iago5NzcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIK L1AgMzQgMCBSCi9LIFs5NzggMCBSXQovSUQgKG5vZGUwMDAwMTU3MCk+PgplbmRvYmoKOTgyIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5ODEgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA4OT4+XQovSUQgKG5vZGUwMDAwMTU4MCk+PgplbmRv YmoKOTg0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5ODMgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA5MD4+XQovSUQgKG5vZGUwMDAwMTU4 Mik+PgplbmRvYmoKOTgzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL0xpbmsKL1AgOTgx IDAgUgovSyBbOTg0IDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogMTkgMCBSCi9QZyAxOCAwIFI+Pl0K L0lEIChub2RlMDAwMDE1ODEpPj4KZW5kb2JqCjk4MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9USAovUCA5ODAgMCBSCi9LIFs5ODIgMCBSIDk4MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQov U2NvcGUgL0NvbHVtbj4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNTc5KT4+CmVuZG9iago5ODYgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk4NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MTggMCBSCi9NQ0lEIDkxPj5dCi9JRCAobm9kZTAwMDAxNTg1KT4+CmVuZG9iago5ODggMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk4NyAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDkyPj5dCi9JRCAobm9kZTAwMDAxNTg3KT4+CmVuZG9iago5 ODcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTGluawovUCA5ODUgMCBSCi9LIFs5ODgg MCBSIDw8L1R5cGUgL09CSlIKL09iaiAyMCAwIFIKL1BnIDE4IDAgUj4+XQovSUQgKG5vZGUwMDAw MTU4Nik+PgplbmRvYmoKOTg1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RICi9QIDk4 MCAwIFIKL0sgWzk4NiAwIFIgOTg3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9TY29wZSAvQ29sdW1u Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDE1ODQpPj4KZW5kb2JqCjk4MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9UUgovUCAzNCAwIFIKL0sgWzk4MSAwIFIgOTg1IDAgUl0KL0lEIChub2RlMDAwMDE1NzcpPj4K ZW5kb2JqCjk5MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTkw IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgOTM+Pl0KL0lEIChub2RlMDAw MDE1OTMpPj4KZW5kb2JqCjk5MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5 ODkgMCBSCi9LIFs5OTEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxNTkyKT4+CmVuZG9iago5ODkgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFs5OTAgMCBSXQovSUQgKG5vZGUwMDAwMTU4OSk+ PgplbmRvYmoKOTk0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCA5 OTMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCA5ND4+XQovSUQgKG5vZGUw MDAwMTU5OSk+PgplbmRvYmoKOTkzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDk5MiAwIFIKL0sgWzk5NCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUw MDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDE1OTgpPj4KZW5kb2JqCjk5NiAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgOTk1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAx OCAwIFIKL01DSUQgOTU+Pl0KL0lEIChub2RlMDAwMDE2MDEpPj4KZW5kb2JqCjk5NSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCA5OTIgMCBSCi9LIFs5OTYgMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAw MDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2Rl MDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjAwKT4+ CmVuZG9iago5OTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDk5 NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDk2Pj5dCi9JRCAobm9kZTAw MDAxNjAzKT4+CmVuZG9iago5OTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag OTkyIDAgUgovSyBbOTk4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAw MDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMTYwMik+PgplbmRvYmoKOTkyIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbOTkzIDAgUiA5OTUgMCBSIDk5NyAwIFJdCi9J RCAobm9kZTAwMDAxNTk2KT4+CmVuZG9iagoxMDAxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCAxMDAwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01D SUQgOTc+Pl0KL0lEIChub2RlMDAwMDE2MDkpPj4KZW5kb2JqCjEwMDAgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgOTk5IDAgUgovSyBbMTAwMSAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkg KG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAx OCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2MDgpPj4KZW5kb2Jq Cjk5OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEwMDAg MCBSXQovSUQgKG5vZGUwMDAwMTYwNSk+PgplbmRvYmoKMTAwNCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAwMyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDk4Pj5dCi9JRCAobm9kZTAwMDAxNjE1KT4+CmVuZG9iagoxMDAzIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMDIgMCBSCi9LIFsxMDA0IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAw MDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9k ZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTYxNCk+ PgplbmRvYmoKMTAwNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTAwNSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDk5Pj5dCi9JRCAobm9k ZTAwMDAxNjE3KT4+CmVuZG9iagoxMDA1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDEwMDIgMCBSCi9LIFsxMDA2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAo bm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTYxNik+PgplbmRvYmoKMTAwOCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAwNyAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMTggMCBSCi9NQ0lEIDEwMD4+XQovSUQgKG5vZGUwMDAwMTYxOSk+PgplbmRvYmoKMTAw NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDAyIDAgUgovSyBbMTAwOCAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2 NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAw MTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDE2MTgpPj4KZW5kb2JqCjEwMDIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIK L1AgMzQgMCBSCi9LIFsxMDAzIDAgUiAxMDA1IDAgUiAxMDA3IDAgUl0KL0lEIChub2RlMDAwMDE2 MTIpPj4KZW5kb2JqCjEwMTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0 Ci9QIDEwMTAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMDE+Pl0KL0lE IChub2RlMDAwMDE2MjQpPj4KZW5kb2JqCjEwMTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvVEQKL1AgMTAwOSAwIFIKL0sgWzEwMTEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMg Wyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEy OTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAw MDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9U YWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjIzKT4+CmVuZG9iagoxMDEzIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDEyIDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTAyPj5dCi9JRCAobm9kZTAwMDAxNjI2KT4+CmVuZG9i agoxMDEyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMDkgMCBSCi9LIFsx MDEzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAw MDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9k ZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTYyNSk+PgplbmRvYmoKMTAxNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTAxNCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lE IDEwMz4+XQovSUQgKG5vZGUwMDAwMTYyOCk+PgplbmRvYmoKMTAxNCAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCAxMDA5IDAgUgovSyBbMTAxNSAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykg KG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAx OSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2MjcpPj4KZW5kb2Jq CjEwMDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMDEw IDAgUiAxMDEyIDAgUiAxMDE0IDAgUl0KL0lEIChub2RlMDAwMDE2MjEpPj4KZW5kb2JqCjEwMTgg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwMTcgMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMDQ+Pl0KL0lEIChub2RlMDAwMDE2MzMpPj4K ZW5kb2JqCjEwMTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTAxNiAwIFIK L0sgWzEwMTggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChu b2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1Nzkp IChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIy NTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5d Ci9JRCAobm9kZTAwMDAxNjMyKT4+CmVuZG9iagoxMDIwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCAxMDE5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIK L01DSUQgMTA1Pj5dCi9JRCAobm9kZTAwMDAxNjM1KT4+CmVuZG9iagoxMDE5IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMTYgMCBSCi9LIFsxMDIwIDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAx MTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAw MDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTYzNCk+Pgpl bmRvYmoKMTAyMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAy MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDEwNj4+XQovSUQgKG5vZGUw MDAwMTYzNyk+PgplbmRvYmoKMTAyMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxMDE2IDAgUgovSyBbMTAyMiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5v ZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2MzYpPj4KZW5kb2JqCjEwMTYgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMDE3IDAgUiAxMDE5IDAgUiAxMDIx IDAgUl0KL0lEIChub2RlMDAwMDE2MzApPj4KZW5kb2JqCjEwMjUgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwMjQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4 IDAgUgovTUNJRCAxMDc+Pl0KL0lEIChub2RlMDAwMDE2NDIpPj4KZW5kb2JqCjEwMjQgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTAyMyAwIFIKL0sgWzEwMjUgMCBSXQovQSBb PDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2Rl MDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChu b2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxl Ci9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjQx KT4+CmVuZG9iagoxMDI3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCAxMDI2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTA4Pj5dCi9JRCAo bm9kZTAwMDAxNjQ0KT4+CmVuZG9iagoxMDI2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDEwMjMgMCBSCi9LIFsxMDI3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0 KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTY0Myk+PgplbmRvYmoKMTAyOSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAyOCAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDEwOT4+XQovSUQgKG5vZGUwMDAwMTY0Nik+PgplbmRvYmoK MTAyOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDIzIDAgUgovSyBbMTAy OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAw MDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUw MDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDE2NDUpPj4KZW5kb2JqCjEwMjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VFIKL1AgMzQgMCBSCi9LIFsxMDI0IDAgUiAxMDI2IDAgUiAxMDI4IDAgUl0KL0lEIChub2RlMDAw MDE2MzkpPj4KZW5kb2JqCjEwMzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDEwMzEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMTA+Pl0K L0lEIChub2RlMDAwMDE2NTIpPj4KZW5kb2JqCjEwMzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgMTAzMCAwIFIKL0sgWzEwMzIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAw MDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjUxKT4+CmVuZG9iagoxMDMwIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTAzMSAwIFJdCi9J RCAobm9kZTAwMDAxNjQ4KT4+CmVuZG9iagoxMDM1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL05vblN0cnVjdAovUCAxMDM0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01D SUQgMTExPj5dCi9JRCAobm9kZTAwMDAxNjU4KT4+CmVuZG9iagoxMDM0IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwMzMgMCBSCi9LIFsxMDM1IDAgUl0KL0EgWzw8L08gL1Rh YmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIy KSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAy MDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3Bh biAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTY1Nyk+PgplbmRv YmoKMTAzNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTAzNiAw IFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDExMj4+XQovSUQgKG5vZGUwMDAw MTY2MCk+PgplbmRvYmoKMTAzNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAx MDMzIDAgUgovSyBbMTAzNyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAw MTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUw MDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5v ZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xT cGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2NTkpPj4KZW5kb2JqCjEwMzkgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwMzggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1Bn IDE4IDAgUgovTUNJRCAxMTM+Pl0KL0lEIChub2RlMDAwMDE2NjIpPj4KZW5kb2JqCjEwMzggMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTAzMyAwIFIKL0sgWzEwMzkgMCBSXQov QSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChu b2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjAp IChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1Rh YmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAx NjYxKT4+CmVuZG9iagoxMDMzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0 IDAgUgovSyBbMTAzNCAwIFIgMTAzNiAwIFIgMTAzOCAwIFJdCi9JRCAobm9kZTAwMDAxNjU1KT4+ CmVuZG9iagoxMDQyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAx MDQxIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTE0Pj5dCi9JRCAobm9k ZTAwMDAxNjY3KT4+CmVuZG9iagoxMDQxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDEwNDAgMCBSCi9LIFsxMDQyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAo bm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTY2Nik+PgplbmRvYmoKMTA0NCAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA0MyAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMTggMCBSCi9NQ0lEIDExNT4+XQovSUQgKG5vZGUwMDAwMTY2OSk+PgplbmRvYmoKMTA0 MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDQwIDAgUgovSyBbMTA0NCAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3 MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAw MTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDE2NjgpPj4KZW5kb2JqCjEwNDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEwNDUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMTY+ Pl0KL0lEIChub2RlMDAwMDE2NzEpPj4KZW5kb2JqCjEwNDUgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMTA0MCAwIFIKL0sgWzEwNDYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2Rl MDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjcwKT4+CmVuZG9iagoxMDQw IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA0MSAwIFIg MTA0MyAwIFIgMTA0NSAwIFJdCi9JRCAobm9kZTAwMDAxNjY0KT4+CmVuZG9iagoxMDQ5IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDQ4IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTE3Pj5dCi9JRCAobm9kZTAwMDAxNjc4KT4+CmVuZG9i agoxMDUwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDQ4IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTE4Pj5dCi9JRCAobm9kZTAwMDAx Njc5KT4+CmVuZG9iagoxMDUxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCAxMDQ4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTE5Pj5dCi9J RCAobm9kZTAwMDAxNjgwKT4+CmVuZG9iagoxMDQ4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDEwNDcgMCBSCi9LIFsxMDQ5IDAgUiAxMDUwIDAgUiAxMDUxIDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAw MDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9k ZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTY3Nyk+ PgplbmRvYmoKMTA1MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTA1MiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDEyMD4+XQovSUQgKG5v ZGUwMDAwMTY4Mik+PgplbmRvYmoKMTA1MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxMDQ3IDAgUgovSyBbMTA1MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2ODEpPj4KZW5kb2JqCjEwNTUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwNTQgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAxMjE+Pl0KL0lEIChub2RlMDAwMDE2ODQpPj4KZW5kb2JqCjEw NTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwNTQgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMjI+Pl0KL0lEIChub2RlMDAwMDE2ODUp Pj4KZW5kb2JqCjEwNTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDEwNTQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMjM+Pl0KL0lEIChu b2RlMDAwMDE2ODYpPj4KZW5kb2JqCjEwNTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgMTA0NyAwIFIKL0sgWzEwNTUgMCBSIDEwNTYgMCBSIDEwNTcgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAz MjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAw MDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjgzKT4+CmVu ZG9iagoxMDQ3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBb MTA0OCAwIFIgMTA1MiAwIFIgMTA1NCAwIFJdCi9JRCAobm9kZTAwMDAxNjc1KT4+CmVuZG9iagox MDYwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDU5IDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTI0Pj5dCi9JRCAobm9kZTAwMDAxNjkx KT4+CmVuZG9iagoxMDU5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwNTgg MCBSCi9LIFsxMDYwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIw KSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAx NTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTY5MCk+PgplbmRvYmoKMTA2MiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA2MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDEyNT4+XQovSUQgKG5vZGUwMDAwMTY5Myk+PgplbmRvYmoKMTA2MSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDU4IDAgUgovSyBbMTA2MiAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUw MDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5v ZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE2OTIp Pj4KZW5kb2JqCjEwNjQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDEwNjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMjY+Pl0KL0lEIChu b2RlMDAwMDE2OTUpPj4KZW5kb2JqCjEwNjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgMTA1OCAwIFIKL0sgWzEwNjQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhu b2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUp IChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIy NDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJs ZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNjk0KT4+CmVuZG9iagoxMDU4IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA1OSAwIFIgMTA2MSAwIFIg MTA2MyAwIFJdCi9JRCAobm9kZTAwMDAxNjg4KT4+CmVuZG9iagoxMDY3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDY2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMTI3Pj5dCi9JRCAobm9kZTAwMDAxNzAwKT4+CmVuZG9iagoxMDY2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwNjUgMCBSCi9LIFsxMDY3IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAo bm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1 KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MTY5OSk+PgplbmRvYmoKMTA2OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTA2OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDEyOD4+XQov SUQgKG5vZGUwMDAwMTcwMik+PgplbmRvYmoKMTA2OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMDY1IDAgUgovSyBbMTA2OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAw MTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3MDEpPj4KZW5kb2JqCjEwNzEgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwNzAgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMjk+Pl0KL0lEIChub2RlMDAwMDE3MDQpPj4KZW5k b2JqCjEwNzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA2NSAwIFIKL0sg WzEwNzEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2Rl MDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChu b2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQp XT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9J RCAobm9kZTAwMDAxNzAzKT4+CmVuZG9iagoxMDY1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RSCi9QIDM0IDAgUgovSyBbMTA2NiAwIFIgMTA2OCAwIFIgMTA3MCAwIFJdCi9JRCAobm9k ZTAwMDAxNjk3KT4+CmVuZG9iagoxMDc0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxMDczIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTMw Pj5dCi9JRCAobm9kZTAwMDAxNzA5KT4+CmVuZG9iagoxMDczIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDEwNzIgMCBSCi9LIFsxMDc0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9k ZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTcwOCk+PgplbmRvYmoKMTA3 NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA3NSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDEzMT4+XQovSUQgKG5vZGUwMDAwMTcxMSk+ PgplbmRvYmoKMTA3NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDcyIDAg UgovSyBbMTA3NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0Nykg KG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4 MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDE3MTApPj4KZW5kb2JqCjEwNzggMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwNzcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAg UgovTUNJRCAxMzI+Pl0KL0lEIChub2RlMDAwMDE3MTIpPj4KZW5kb2JqCjEwNzcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA3MiAwIFIKL0sgWzEwNzggMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAw MDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2Rl MDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzk4KT4+ CmVuZG9iagoxMDcyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgov SyBbMTA3MyAwIFIgMTA3NSAwIFIgMTA3NyAwIFJdCi9JRCAobm9kZTAwMDAxNzA2KT4+CmVuZG9i agoxMDgxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDgwIDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTMzPj5dCi9JRCAobm9kZTAwMDAx NzE3KT4+CmVuZG9iagoxMDgwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEw NzkgMCBSCi9LIFsxMDgxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAw MDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMTcxNik+PgplbmRvYmoKMTA4MyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA4MiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MTggMCBSCi9NQ0lEIDEzND4+XQovSUQgKG5vZGUwMDAwMTcxOSk+PgplbmRvYmoKMTA4MiAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDc5IDAgUgovSyBbMTA4MyAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5v ZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkg KG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3 MTgpPj4KZW5kb2JqCjEwNzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQg MCBSCi9LIFsxMDgwIDAgUiAxMDgyIDAgUl0KL0lEIChub2RlMDAwMDE3MTQpPj4KZW5kb2JqCjEw ODYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwODUgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMzU+Pl0KL0lEIChub2RlMDAwMDE3MjYp Pj4KZW5kb2JqCjEwODUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA4NCAw IFIKL0sgWzEwODYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcp IChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1 ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAw MDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAx Pj5dCi9JRCAobm9kZTAwMDAxNzI1KT4+CmVuZG9iagoxMDg0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA4NSAwIFJdCi9JRCAobm9kZTAwMDAxNzIyKT4+ CmVuZG9iagoxMDg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAx MDg4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTM2Pj5dCi9JRCAobm9k ZTAwMDAxNzMyKT4+CmVuZG9iagoxMDg4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDEwODcgMCBSCi9LIFsxMDg5IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAo bm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTczMSk+PgplbmRvYmoKMTA5MSAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTA5MCAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMTggMCBSCi9NQ0lEIDEzNz4+XQovSUQgKG5vZGUwMDAwMTczNCk+PgplbmRvYmoKMTA5 MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMDg3IDAgUgovSyBbMTA5MSAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3 MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAw MTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDE3MzMpPj4KZW5kb2JqCjEwOTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEwOTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxMzg+ Pl0KL0lEIChub2RlMDAwMDE3MzYpPj4KZW5kb2JqCjEwOTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMTA4NyAwIFIKL0sgWzEwOTMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2Rl MDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxNzM1KT4+CmVuZG9iagoxMDg3 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA4OCAwIFIg MTA5MCAwIFIgMTA5MiAwIFJdCi9JRCAobm9kZTAwMDAxNzI5KT4+CmVuZG9iagoxMDk2IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMDk1IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTM5Pj5dCi9JRCAobm9kZTAwMDAxNzQxKT4+CmVuZG9i agoxMDk1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEwOTQgMCBSCi9LIFsx MDk2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAw MDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9k ZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTc0MCk+PgplbmRvYmoKMTA5OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTA5NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lE IDE0MD4+XQovSUQgKG5vZGUwMDAwMTc0Myk+PgplbmRvYmoKMTA5NyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCAxMDk0IDAgUgovSyBbMTA5OCAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkg KG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAx OCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3NDIpPj4KZW5kb2Jq CjExMDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEwOTkgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNDE+Pl0KL0lEIChub2RlMDAwMDE3 NDUpPj4KZW5kb2JqCjEwOTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTA5 NCAwIFIKL0sgWzExMDAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAw MDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxNzQ0KT4+CmVuZG9iagoxMDk0IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTA5NSAwIFIgMTA5NyAwIFIgMTA5OSAwIFJd Ci9JRCAobm9kZTAwMDAxNzM4KT4+CmVuZG9iagoxMTAzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCAxMTAyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIK L01DSUQgMTQyPj5dCi9JRCAobm9kZTAwMDAxNzUwKT4+CmVuZG9iagoxMTAyIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExMDEgMCBSCi9LIFsxMTAzIDAgUl0KL0EgWzw8L08g L1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAw MzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAw MDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93 U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTc0OSk+Pgpl bmRvYmoKMTEwNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTEw NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE0Mz4+XQovSUQgKG5vZGUw MDAwMTc1Mik+PgplbmRvYmoKMTEwNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxMTAxIDAgUgovSyBbMTEwNSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3NTEpPj4KZW5kb2JqCjExMDcgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExMDYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAxNDQ+Pl0KL0lEIChub2RlMDAwMDE3NTQpPj4KZW5kb2JqCjExMDYg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTEwMSAwIFIKL0sgWzExMDcgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcp IChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4 MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxNzUzKT4+CmVuZG9iagoxMTAxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9Q IDM0IDAgUgovSyBbMTEwMiAwIFIgMTEwNCAwIFIgMTEwNiAwIFJdCi9JRCAobm9kZTAwMDAxNzQ3 KT4+CmVuZG9iagoxMTEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAov UCAxMTA5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTQ1Pj5dCi9JRCAo bm9kZTAwMDAxNzU5KT4+CmVuZG9iagoxMTA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RECi9QIDExMDggMCBSCi9LIFsxMTEwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFso bm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkz KSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAy MjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFi bGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTc1OCk+PgplbmRvYmoKMTExMiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTExMSAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDE0Nj4+XQovSUQgKG5vZGUwMDAwMTc2MSk+PgplbmRvYmoK MTExMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTA4IDAgUgovSyBbMTEx MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAw MTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUw MDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDE3NjApPj4KZW5kb2JqCjExMTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDExMTMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAx NDc+Pl0KL0lEIChub2RlMDAwMDE3NjIpPj4KZW5kb2JqCjExMTMgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMTEwOCAwIFIKL0sgWzExMTQgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChu b2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwMzk5KT4+CmVuZG9iagox MTA4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTEwOSAw IFIgMTExMSAwIFIgMTExMyAwIFJdCi9JRCAobm9kZTAwMDAxNzU2KT4+CmVuZG9iagoxMTE3IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTE2IDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTQ4Pj5dCi9JRCAobm9kZTAwMDAxNzY3KT4+CmVu ZG9iagoxMTE2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExMTUgMCBSCi9L IFsxMTE3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9k ZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAo bm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUx KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTc2Nik+PgplbmRvYmoKMTExOSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTExOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9N Q0lEIDE0OT4+XQovSUQgKG5vZGUwMDAwMTc2OSk+PgplbmRvYmoKMTExOCAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTE1IDAgUgovSyBbMTExOSAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5 OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAw MjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3NjgpPj4KZW5k b2JqCjExMjEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExMjAg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNTA+Pl0KL0lEIChub2RlMDAw MDE3NzApPj4KZW5kb2JqCjExMjAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTExNSAwIFIKL0sgWzExMjEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2Rl MDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAwNDAxKT4+CmVuZG9iagoxMTE1IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTExNiAwIFIgMTExOCAwIFIgMTEyMCAw IFJdCi9JRCAobm9kZTAwMDAxNzY0KT4+CmVuZG9iagoxMTI0IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTIzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgMTUxPj5dCi9JRCAobm9kZTAwMDAxNzc1KT4+CmVuZG9iagoxMTIzIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExMjIgMCBSCi9LIFsxMTI0IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAw MDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9k ZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTc3NCk+ PgplbmRvYmoKMTEyNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTEyNSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE1Mj4+XQovSUQgKG5v ZGUwMDAwMTc3Nyk+PgplbmRvYmoKMTEyNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxMTIyIDAgUgovSyBbMTEyNiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3NzYpPj4KZW5kb2JqCjExMjggMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExMjcgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAxNTM+Pl0KL0lEIChub2RlMDAwMDE3NzkpPj4KZW5kb2JqCjEx MjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTEyMiAwIFIKL0sgWzExMjgg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAy NjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAw MDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAxNzc4KT4+CmVuZG9iagoxMTIyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbMTEyMyAwIFIgMTEyNSAwIFIgMTEyNyAwIFJdCi9JRCAobm9kZTAwMDAx NzcyKT4+CmVuZG9iagoxMTMxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCAxMTMwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTU0Pj5dCi9J RCAobm9kZTAwMDAxNzg1KT4+CmVuZG9iagoxMTMwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDExMjkgMCBSCi9LIFsxMTMxIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAx Mjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTc4NCk+PgplbmRvYmoKMTEyOSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzExMzAgMCBSXQovSUQg KG5vZGUwMDAwMTc4MSk+PgplbmRvYmoKMTEzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTEzMyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lE IDE1NT4+XQovSUQgKG5vZGUwMDAwMTc5MSk+PgplbmRvYmoKMTEzMyAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCAxMTMyIDAgUgovSyBbMTEzNCAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikg KG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAx NCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3OTApPj4KZW5kb2Jq CjExMzYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExMzUgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNTY+Pl0KL0lEIChub2RlMDAwMDE3 OTMpPj4KZW5kb2JqCjExMzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTEz MiAwIFIKL0sgWzExMzYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxNzkyKT4+CmVuZG9iagoxMTM4IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTM3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAx OCAwIFIKL01DSUQgMTU3Pj5dCi9JRCAobm9kZTAwMDAxNzk1KT4+CmVuZG9iagoxMTM3IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExMzIgMCBSCi9LIFsxMTM4IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9k ZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAo bm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTc5 NCk+PgplbmRvYmoKMTEzMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAw IFIKL0sgWzExMzMgMCBSIDExMzUgMCBSIDExMzcgMCBSXQovSUQgKG5vZGUwMDAwMTc4OCk+Pgpl bmRvYmoKMTE0MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTE0 MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE1OD4+XQovSUQgKG5vZGUw MDAwMTgwMCk+PgplbmRvYmoKMTE0MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxMTM5IDAgUgovSyBbMTE0MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5v ZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE3OTkpPj4KZW5kb2JqCjExNDMgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNDIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAxNTk+Pl0KL0lEIChub2RlMDAwMDE4MDIpPj4KZW5kb2JqCjExNDIg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTEzOSAwIFIKL0sgWzExNDMgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxODAxKT4+CmVuZG9iagoxMTQ1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxMTQ0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTYwPj5d Ci9JRCAobm9kZTAwMDAxODA0KT4+CmVuZG9iagoxMTQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDExMzkgMCBSCi9LIFsxMTQ1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAw MDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTgwMyk+PgplbmRvYmoKMTEzOSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzExNDAgMCBSIDEx NDIgMCBSIDExNDQgMCBSXQovSUQgKG5vZGUwMDAwMTc5Nyk+PgplbmRvYmoKMTE0OCAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTE0NyAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDE2MT4+XQovSUQgKG5vZGUwMDAwMTgxMCk+PgplbmRvYmoK MTE0NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTQ2IDAgUgovSyBbMTE0 OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAw MTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUw MDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDE4MDkpPj4KZW5kb2JqCjExNDYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VFIKL1AgMzQgMCBSCi9LIFsxMTQ3IDAgUl0KL0lEIChub2RlMDAwMDE4MDYpPj4KZW5kb2JqCjEx NTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNTAgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNjI+Pl0KL0lEIChub2RlMDAwMDE4MTYp Pj4KZW5kb2JqCjExNTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDExNTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNjM+Pl0KL0lEIChu b2RlMDAwMDE4MTgpPj4KZW5kb2JqCjExNTIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv TGluawovUCAxMTUwIDAgUgovSyBbMTE1MyAwIFIgPDwvVHlwZSAvT0JKUgovT2JqIDIxIDAgUgov UGcgMTggMCBSPj5dCi9JRCAobm9kZTAwMDAxODE3KT4+CmVuZG9iagoxMTUwIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RICi9QIDExNDkgMCBSCi9LIFsxMTUxIDAgUiAxMTUyIDAgUl0K L0EgWzw8L08gL1RhYmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4MTUpPj4KZW5kb2JqCjEx NTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNTQgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNjQ+Pl0KL0lEIChub2RlMDAwMDE4MjEp Pj4KZW5kb2JqCjExNTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDExNTYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNjU+Pl0KL0lEIChu b2RlMDAwMDE4MjMpPj4KZW5kb2JqCjExNTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv TGluawovUCAxMTU0IDAgUgovSyBbMTE1NyAwIFIgPDwvVHlwZSAvT0JKUgovT2JqIDIyIDAgUgov UGcgMTggMCBSPj5dCi9JRCAobm9kZTAwMDAxODIyKT4+CmVuZG9iagoxMTU0IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL1RICi9QIDExNDkgMCBSCi9LIFsxMTU1IDAgUiAxMTU2IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9TY29wZSAvQ29sdW1uPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+ IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4MjApPj4KZW5kb2JqCjEx NDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMTUwIDAg UiAxMTU0IDAgUl0KL0lEIChub2RlMDAwMDE4MTMpPj4KZW5kb2JqCjExNjAgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAxNjY+Pl0KL0lEIChub2RlMDAwMDE4MjkpPj4KZW5kb2JqCjExNTkg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTE1OCAwIFIKL0sgWzExNjAgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxODI4KT4+CmVuZG9iagoxMTU4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9Q IDM0IDAgUgovSyBbMTE1OSAwIFJdCi9JRCAobm9kZTAwMDAxODI1KT4+CmVuZG9iagoxMTYzIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTYyIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTY3Pj5dCi9JRCAobm9kZTAwMDAxODM1KT4+CmVu ZG9iagoxMTYyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExNjEgMCBSCi9L IFsxMTYzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9k ZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAo bm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUx KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTgzNCk+PgplbmRvYmoKMTE2NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTE2NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9N Q0lEIDE2OD4+XQovSUQgKG5vZGUwMDAwMTgzNyk+PgplbmRvYmoKMTE2NCAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTYxIDAgUgovSyBbMTE2NSAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5 OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAw MjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4MzYpPj4KZW5k b2JqCjExNjcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNjYg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNjk+Pl0KL0lEIChub2RlMDAw MDE4MzkpPj4KZW5kb2JqCjExNjYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTE2MSAwIFIKL0sgWzExNjcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2Rl MDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxODM4KT4+CmVuZG9iagoxMTYxIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTE2MiAwIFIgMTE2NCAwIFIgMTE2NiAw IFJdCi9JRCAobm9kZTAwMDAxODMyKT4+CmVuZG9iagoxMTcwIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTY5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgMTcwPj5dCi9JRCAobm9kZTAwMDAxODQ0KT4+CmVuZG9iagoxMTY5IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExNjggMCBSCi9LIFsxMTcwIDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAw MDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9k ZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTg0Myk+ PgplbmRvYmoKMTE3MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTE3MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE3MT4+XQovSUQgKG5v ZGUwMDAwMTg0Nik+PgplbmRvYmoKMTE3MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxMTY4IDAgUgovSyBbMTE3MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4NDUpPj4KZW5kb2JqCjExNzQgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExNzMgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAxNzI+Pl0KL0lEIChub2RlMDAwMDE4NDgpPj4KZW5kb2JqCjEx NzMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTE2OCAwIFIKL0sgWzExNzQg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAy NjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAw MDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAxODQ3KT4+CmVuZG9iagoxMTY4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbMTE2OSAwIFIgMTE3MSAwIFIgMTE3MyAwIFJdCi9JRCAobm9kZTAwMDAx ODQxKT4+CmVuZG9iagoxMTc3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVj dAovUCAxMTc2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTczPj5dCi9J RCAobm9kZTAwMDAxODU0KT4+CmVuZG9iagoxMTc2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RECi9QIDExNzUgMCBSCi9LIFsxMTc3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAx Mjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTg1Myk+PgplbmRvYmoKMTE3NSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzExNzYgMCBSXQovSUQg KG5vZGUwMDAwMTg1MCk+PgplbmRvYmoKMTE4MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTE3OSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lE IDE3ND4+XQovSUQgKG5vZGUwMDAwMTg2MCk+PgplbmRvYmoKMTE3OSAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCAxMTc4IDAgUgovSyBbMTE4MCAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikg KG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAx NCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4NTkpPj4KZW5kb2Jq CjExODIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExODEgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNzU+Pl0KL0lEIChub2RlMDAwMDE4 NjIpPj4KZW5kb2JqCjExODEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTE3 OCAwIFIKL0sgWzExODIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDEx NDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAw MDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxODYxKT4+CmVuZG9iagoxMTg0IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTgzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAx OCAwIFIKL01DSUQgMTc2Pj5dCi9JRCAobm9kZTAwMDAxODY0KT4+CmVuZG9iagoxMTgzIDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExNzggMCBSCi9LIFsxMTg0IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9k ZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAo bm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTg2 Myk+PgplbmRvYmoKMTE3OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAw IFIKL0sgWzExNzkgMCBSIDExODEgMCBSIDExODMgMCBSXQovSUQgKG5vZGUwMDAwMTg1Nyk+Pgpl bmRvYmoKMTE4NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTE4 NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE3Nz4+XQovSUQgKG5vZGUw MDAwMTg3MCk+PgplbmRvYmoKMTE4NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxMTg1IDAgUgovSyBbMTE4NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5v ZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4NjkpPj4KZW5kb2JqCjExODUgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMTg2IDAgUl0KL0lEIChub2RlMDAw MDE4NjYpPj4KZW5kb2JqCjExOTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3Ry dWN0Ci9QIDExODkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxNzg+Pl0K L0lEIChub2RlMDAwMDE4NzYpPj4KZW5kb2JqCjExODkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEQKL1AgMTE4OCAwIFIKL0sgWzExOTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRl cnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAw MDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2Rl MDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9P IC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxODc1KT4+CmVuZG9iagoxMTkyIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMTkxIDAgUgovSyBbPDwv VHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTc5Pj5dCi9JRCAobm9kZTAwMDAxODc4KT4+CmVu ZG9iagoxMTkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDExODggMCBSCi9L IFsxMTkyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9k ZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAo bm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUz KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQov SUQgKG5vZGUwMDAwMTg3Nyk+PgplbmRvYmoKMTE5NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTE5MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9N Q0lEIDE4MD4+XQovSUQgKG5vZGUwMDAwMTg4MCk+PgplbmRvYmoKMTE5MyAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTg4IDAgUgovSyBbMTE5NCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMy MykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAw MjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE4NzkpPj4KZW5k b2JqCjExODggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsx MTg5IDAgUiAxMTkxIDAgUiAxMTkzIDAgUl0KL0lEIChub2RlMDAwMDE4NzMpPj4KZW5kb2JqCjEx OTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDExOTYgMCBSCi9L IFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxODE+Pl0KL0lEIChub2RlMDAwMDE4ODYp Pj4KZW5kb2JqCjExOTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTE5NSAw IFIKL0sgWzExOTcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcp IChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1 ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAw MDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAx Pj5dCi9JRCAobm9kZTAwMDAxODg1KT4+CmVuZG9iagoxMTk1IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTE5NiAwIFJdCi9JRCAobm9kZTAwMDAxODgyKT4+ CmVuZG9iagoxMjAwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAx MTk5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTgyPj5dCi9JRCAobm9k ZTAwMDAxODkyKT4+CmVuZG9iagoxMTk5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RE Ci9QIDExOTggMCBSCi9LIFsxMjAwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9k ZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAo bm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3 KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTg5MSk+PgplbmRvYmoKMTIwMiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTIwMSAwIFIKL0sgWzw8L1R5cGUgL01D UgovUGcgMTggMCBSCi9NQ0lEIDE4Mz4+XQovSUQgKG5vZGUwMDAwMTg5NCk+PgplbmRvYmoKMTIw MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMTk4IDAgUgovSyBbMTIwMiAw IFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3 MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAw MTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwv TyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2Rl MDAwMDE4OTMpPj4KZW5kb2JqCjEyMDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEyMDMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxODQ+ Pl0KL0lEIChub2RlMDAwMDE4OTYpPj4KZW5kb2JqCjEyMDMgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMTE5OCAwIFIKL0sgWzEyMDQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2Rl MDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxODk1KT4+CmVuZG9iagoxMTk4 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTE5OSAwIFIg MTIwMSAwIFIgMTIwMyAwIFJdCi9JRCAobm9kZTAwMDAxODg5KT4+CmVuZG9iagoxMjA3IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjA2IDAgUgovSyBbPDwvVHlw ZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTg1Pj5dCi9JRCAobm9kZTAwMDAxOTAxKT4+CmVuZG9i agoxMjA2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyMDUgMCBSCi9LIFsx MjA3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAw MDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9k ZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+ PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQg KG5vZGUwMDAwMTkwMCk+PgplbmRvYmoKMTIwOSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9Ob25TdHJ1Y3QKL1AgMTIwOCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lE IDE4Nj4+XQovSUQgKG5vZGUwMDAwMTkwMyk+PgplbmRvYmoKMTIwOCAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9URAovUCAxMjA1IDAgUgovSyBbMTIwOSAwIFJdCi9BIFs8PC9PIC9UYWJs ZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkg KG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAx OCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4g MT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5MDIpPj4KZW5kb2Jq CjEyMTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyMTAgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAxODc+Pl0KL0lEIChub2RlMDAwMDE5 MDUpPj4KZW5kb2JqCjEyMTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTIw NSAwIFIKL0sgWzEyMTEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAw MDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxOTA0KT4+CmVuZG9iagoxMjA1IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTIwNiAwIFIgMTIwOCAwIFIgMTIxMCAwIFJd Ci9JRCAobm9kZTAwMDAxODk4KT4+CmVuZG9iagoxMjE0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL05vblN0cnVjdAovUCAxMjEzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIK L01DSUQgMTg4Pj5dCi9JRCAobm9kZTAwMDAxOTEyKT4+CmVuZG9iagoxMjE1IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjEzIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAxOCAwIFIKL01DSUQgMTg5Pj5dCi9JRCAobm9kZTAwMDAxOTEzKT4+CmVuZG9iagoxMjE2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjEzIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTkwPj5dCi9JRCAobm9kZTAwMDAxOTE0KT4+ CmVuZG9iagoxMjEzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyMTIgMCBS Ci9LIFsxMjE0IDAgUiAxMjE1IDAgUiAxMjE2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJz IFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAwMDAx MjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9kZTAw MDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTkxMSk+PgplbmRvYmoKMTIxOCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTIxNyAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE5MT4+XQovSUQgKG5vZGUwMDAwMTkxNik+PgplbmRv YmoKMTIxNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjEyIDAgUgovSyBb MTIxOCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5vZGUw MDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4MykgKG5v ZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1Myld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDE5MTUpPj4KZW5kb2JqCjEyMjAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDEyMTkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJ RCAxOTI+Pl0KL0lEIChub2RlMDAwMDE5MTgpPj4KZW5kb2JqCjEyMTkgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMTIxMiAwIFIKL0sgWzEyMjAgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAzMjMp IChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAwMDIw MTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTE3KT4+CmVuZG9i agoxMjEyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTIx MyAwIFIgMTIxNyAwIFIgMTIxOSAwIFJdCi9JRCAobm9kZTAwMDAxOTA5KT4+CmVuZG9iagoxMjIz IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjIyIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTkzPj5dCi9JRCAobm9kZTAwMDAxOTI0KT4+ CmVuZG9iagoxMjIyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyMjEgMCBS Ci9LIFsxMjIzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAo bm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgz KSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMTkyMyk+PgplbmRvYmoKMTIyMSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEyMjIgMCBSXQovSUQgKG5vZGUwMDAwMTkyMCk+Pgpl bmRvYmoKMTIyNiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTIy NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDE5ND4+XQovSUQgKG5vZGUw MDAwMTkzMCk+PgplbmRvYmoKMTIyNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAov UCAxMjI0IDAgUgovSyBbMTIyNiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUw MDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5v ZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0Nykg KG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9D b2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5MjkpPj4KZW5kb2JqCjEyMjggMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyMjcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAxOTU+Pl0KL0lEIChub2RlMDAwMDE5MzIpPj4KZW5kb2JqCjEyMjcg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTIyNCAwIFIKL0sgWzEyMjggMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIp IChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4 MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxOTMxKT4+CmVuZG9iagoxMjMwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxMjI5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTk2Pj5d Ci9JRCAobm9kZTAwMDAxOTM0KT4+CmVuZG9iagoxMjI5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDEyMjQgMCBSCi9LIFsxMjMwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAw MDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTkzMyk+PgplbmRvYmoKMTIyNCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEyMjUgMCBSIDEy MjcgMCBSIDEyMjkgMCBSXQovSUQgKG5vZGUwMDAwMTkyNyk+PgplbmRvYmoKMTIzMyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTIzMiAwIFIKL0sgWzw8L1R5cGUg L01DUgovUGcgMTggMCBSCi9NQ0lEIDE5Nz4+XQovSUQgKG5vZGUwMDAwMTkzOSk+PgplbmRvYmoK MTIzMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjMxIDAgUgovSyBbMTIz MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAw MDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUw MDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4g PDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChu b2RlMDAwMDE5MzgpPj4KZW5kb2JqCjEyMzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDEyMzQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAx OTg+Pl0KL0lEIChub2RlMDAwMDE5NDEpPj4KZW5kb2JqCjEyMzQgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMTIzMSAwIFIKL0sgWzEyMzUgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChu b2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTQwKT4+CmVuZG9iagox MjM3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjM2IDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMTk5Pj5dCi9JRCAobm9kZTAwMDAxOTQz KT4+CmVuZG9iagoxMjM2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyMzEg MCBSCi9LIFsxMjM3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIx KSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAx NTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTk0Mik+PgplbmRvYmoKMTIzMSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEyMzIgMCBSIDEyMzQgMCBSIDEyMzYgMCBSXQov SUQgKG5vZGUwMDAwMTkzNik+PgplbmRvYmoKMTI0MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9Ob25TdHJ1Y3QKL1AgMTIzOSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9N Q0lEIDIwMD4+XQovSUQgKG5vZGUwMDAwMTk0OCk+PgplbmRvYmoKMTIzOSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjM4IDAgUgovSyBbMTI0MCAwIFJdCi9BIFs8PC9PIC9U YWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMy MikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAw MjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1Nw YW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5NDcpPj4KZW5k b2JqCjEyNDIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyNDEg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMDE+Pl0KL0lEIChub2RlMDAw MDE5NTApPj4KZW5kb2JqCjEyNDEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTIzOCAwIFIKL0sgWzEyNDIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2Rl MDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTQ5KT4+CmVuZG9iagoxMjQ0IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjQzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMjAyPj5dCi9JRCAobm9kZTAwMDAxOTUyKT4+CmVuZG9iagoxMjQzIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyMzggMCBSCi9LIFsxMjQ0IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAo bm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIw KSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MTk1MSk+PgplbmRvYmoKMTIzOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAz NCAwIFIKL0sgWzEyMzkgMCBSIDEyNDEgMCBSIDEyNDMgMCBSXQovSUQgKG5vZGUwMDAwMTk0NSk+ PgplbmRvYmoKMTI0NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTI0NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIwMz4+XQovSUQgKG5v ZGUwMDAwMTk1OCk+PgplbmRvYmoKMTI0NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxMjQ1IDAgUgovSyBbMTI0NyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkg KG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5NTcpPj4KZW5kb2JqCjEyNDUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMjQ2IDAgUl0KL0lEIChub2Rl MDAwMDE5NTQpPj4KZW5kb2JqCjEyNTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEyNDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMDQ+ Pl0KL0lEIChub2RlMDAwMDE5NjQpPj4KZW5kb2JqCjEyNDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMTI0OCAwIFIKL0sgWzEyNTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hl YWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2Rl MDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChu b2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTYzKT4+CmVuZG9iagoxMjUy IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjUxIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjA1Pj5dCi9JRCAobm9kZTAwMDAxOTY2KT4+ CmVuZG9iagoxMjUxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyNDggMCBS Ci9LIFsxMjUyIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAo bm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgz KSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAy MjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+ XQovSUQgKG5vZGUwMDAwMTk2NSk+PgplbmRvYmoKMTI1NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTI1MyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBS Ci9NQ0lEIDIwNj4+XQovSUQgKG5vZGUwMDAwMTk2OCk+PgplbmRvYmoKMTI1MyAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjQ4IDAgUgovSyBbMTI1NCAwIFJdCi9BIFs8PC9P IC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAw MDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUw MDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5NjcpPj4K ZW5kb2JqCjEyNDggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9L IFsxMjQ5IDAgUiAxMjUxIDAgUiAxMjUzIDAgUl0KL0lEIChub2RlMDAwMDE5NjEpPj4KZW5kb2Jq CjEyNTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyNTYgMCBS Ci9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMDc+Pl0KL0lEIChub2RlMDAwMDE5 NzMpPj4KZW5kb2JqCjEyNTYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI1 NSAwIFIKL0sgWzEyNTcgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAy MjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAw MDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2Rl MDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3Bh biAxPj5dCi9JRCAobm9kZTAwMDAxOTcyKT4+CmVuZG9iagoxMjU5IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjU4IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAx OCAwIFIKL01DSUQgMjA4Pj5dCi9JRCAobm9kZTAwMDAxOTc1KT4+CmVuZG9iagoxMjU4IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyNTUgMCBSCi9LIFsxMjU5IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9k ZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAo bm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTk3 NCk+PgplbmRvYmoKMTI2MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMTI2MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIwOT4+XQovSUQg KG5vZGUwMDAwMTk3Nyk+PgplbmRvYmoKMTI2MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCAxMjU1IDAgUgovSyBbMTI2MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5 NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDE5NzYpPj4KZW5kb2JqCjEyNTUgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMjU2IDAgUiAxMjU4IDAg UiAxMjYwIDAgUl0KL0lEIChub2RlMDAwMDE5NzApPj4KZW5kb2JqCjEyNjQgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyNjMgMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAyMTA+Pl0KL0lEIChub2RlMDAwMDE5ODIpPj4KZW5kb2JqCjEyNjMg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI2MiAwIFIKL0sgWzEyNjQgMCBS XQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYp IChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4 MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08g L1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAw MDAxOTgxKT4+CmVuZG9iagoxMjY2IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxMjY1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjExPj5d Ci9JRCAobm9kZTAwMDAxOTg0KT4+CmVuZG9iagoxMjY1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDEyNjIgMCBSCi9LIFsxMjY2IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAw MDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMTk4Myk+PgplbmRvYmoKMTI2OCAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTI2NyAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIxMj4+XQovSUQgKG5vZGUwMDAwMTk4Nik+Pgpl bmRvYmoKMTI2NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjYyIDAgUgov SyBbMTI2OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5v ZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkg KG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDE5ODUpPj4KZW5kb2JqCjEyNjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMjYzIDAgUiAxMjY1IDAgUiAxMjY3IDAgUl0KL0lEIChu b2RlMDAwMDE5NzkpPj4KZW5kb2JqCjEyNzEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDEyNzAgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAy MTM+Pl0KL0lEIChub2RlMDAwMDE5OTEpPj4KZW5kb2JqCjEyNzAgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMTI2OSAwIFIKL0sgWzEyNzEgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChu b2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTkwKT4+CmVuZG9iagox MjczIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjcyIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjE0Pj5dCi9JRCAobm9kZTAwMDAxOTkz KT4+CmVuZG9iagoxMjcyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyNjkg MCBSCi9LIFsxMjczIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMTk5Mik+PgplbmRvYmoKMTI3NSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTI3NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDIxNT4+XQovSUQgKG5vZGUwMDAwMTk5NCk+PgplbmRvYmoKMTI3NCAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMjY5IDAgUgovSyBbMTI3NSAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDA0MDAp Pj4KZW5kb2JqCjEyNjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBS Ci9LIFsxMjcwIDAgUiAxMjcyIDAgUiAxMjc0IDAgUl0KL0lEIChub2RlMDAwMDE5ODgpPj4KZW5k b2JqCjEyNzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyNzcg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMTY+Pl0KL0lEIChub2RlMDAw MDE5OTkpPj4KZW5kb2JqCjEyNzcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTI3NiAwIFIKL0sgWzEyNzggMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2Rl MDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAxOTk4KT4+CmVuZG9iagoxMjgwIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjc5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMjE3Pj5dCi9JRCAobm9kZTAwMDAyMDAxKT4+CmVuZG9iagoxMjc5IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyNzYgMCBSCi9LIFsxMjgwIDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAo bm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5 KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MjAwMCk+PgplbmRvYmoKMTI4MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTI4MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIxOD4+XQov SUQgKG5vZGUwMDAwMjAwMyk+PgplbmRvYmoKMTI4MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMjc2IDAgUgovSyBbMTI4MiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAw MTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIwMDIpPj4KZW5kb2JqCjEyNzYgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMjc3IDAgUiAxMjc5 IDAgUiAxMjgxIDAgUl0KL0lEIChub2RlMDAwMDE5OTYpPj4KZW5kb2JqCjEyODUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEyODQgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAyMTk+Pl0KL0lEIChub2RlMDAwMDIwMDkpPj4KZW5kb2JqCjEy ODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI4MyAwIFIKL0sgWzEyODUg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDEx NzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAw MDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAyMDA4KT4+CmVuZG9iagoxMjgzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RS Ci9QIDM0IDAgUgovSyBbMTI4NCAwIFJdCi9JRCAobm9kZTAwMDAyMDA1KT4+CmVuZG9iagoxMjg4 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjg3IDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjIwPj5dCi9JRCAobm9kZTAwMDAyMDE1KT4+ CmVuZG9iagoxMjkwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAx Mjg5IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjIxPj5dCi9JRCAobm9k ZTAwMDAyMDE3KT4+CmVuZG9iagoxMjg5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL0xp bmsKL1AgMTI4NyAwIFIKL0sgWzEyOTAgMCBSIDw8L1R5cGUgL09CSlIKL09iaiAyMyAwIFIKL1Bn IDE4IDAgUj4+XQovSUQgKG5vZGUwMDAwMjAxNik+PgplbmRvYmoKMTI4NyAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9USAovUCAxMjg2IDAgUgovSyBbMTI4OCAwIFIgMTI4OSAwIFJdCi9B IFs8PC9PIC9UYWJsZQovU2NvcGUgL0NvbHVtbj4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDE0KT4+CmVuZG9iagoxMjky IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjkxIDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjIyPj5dCi9JRCAobm9kZTAwMDAyMDIwKT4+ CmVuZG9iagoxMjk0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAx MjkzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjIzPj5dCi9JRCAobm9k ZTAwMDAyMDIyKT4+CmVuZG9iagoxMjkzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL0xp bmsKL1AgMTI5MSAwIFIKL0sgWzEyOTQgMCBSIDw8L1R5cGUgL09CSlIKL09iaiAyNCAwIFIKL1Bn IDE4IDAgUj4+XQovSUQgKG5vZGUwMDAwMjAyMSk+PgplbmRvYmoKMTI5MSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9USAovUCAxMjg2IDAgUgovSyBbMTI5MiAwIFIgMTI5MyAwIFJdCi9B IFs8PC9PIC9UYWJsZQovU2NvcGUgL0NvbHVtbj4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8 PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDE5KT4+CmVuZG9iagoxMjg2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTI4NyAwIFIg MTI5MSAwIFJdCi9JRCAobm9kZTAwMDAyMDEyKT4+CmVuZG9iagoxMjk3IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMjk2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMjI0Pj5dCi9JRCAobm9kZTAwMDAyMDI3KT4+CmVuZG9iagoxMjk2IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEyOTUgMCBSCi9LIFsxMjk3IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAo bm9kZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1 KSAobm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MjAyNik+PgplbmRvYmoKMTI5OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTI5OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIyNT4+XQov SUQgKG5vZGUwMDAwMjAyOSk+PgplbmRvYmoKMTI5OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMjk1IDAgUgovSyBbMTI5OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAw MTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIwMjgpPj4KZW5kb2JqCjEzMDEgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzMDAgMCBSCi9LIFs8PC9U eXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMjY+Pl0KL0lEIChub2RlMDAwMDIwMzEpPj4KZW5k b2JqCjEzMDAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTI5NSAwIFIKL0sg WzEzMDEgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2Rl MDAwMDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChu b2RlMDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQp XT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9J RCAobm9kZTAwMDAyMDMwKT4+CmVuZG9iagoxMjk1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0K L1MgL1RSCi9QIDM0IDAgUgovSyBbMTI5NiAwIFIgMTI5OCAwIFIgMTMwMCAwIFJdCi9JRCAobm9k ZTAwMDAyMDI0KT4+CmVuZG9iagoxMzA0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxMzAzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjI3 Pj5dCi9JRCAobm9kZTAwMDAyMDM2KT4+CmVuZG9iagoxMzAzIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDEzMDIgMCBSCi9LIFsxMzA0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9k ZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjAzNSk+PgplbmRvYmoKMTMw NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTMwNSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIyOD4+XQovSUQgKG5vZGUwMDAwMjAzOCk+ PgplbmRvYmoKMTMwNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzAyIDAg UgovSyBbMTMwNiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0Nykg KG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4 MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDIwMzcpPj4KZW5kb2JqCjEzMDggMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzMDcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAg UgovTUNJRCAyMjk+Pl0KL0lEIChub2RlMDAwMDIwNDApPj4KZW5kb2JqCjEzMDcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTMwMiAwIFIKL0sgWzEzMDggMCBSXQovQSBbPDwv TyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAw MDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2Rl MDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9S b3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDM5KT4+ CmVuZG9iagoxMzAyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgov SyBbMTMwMyAwIFIgMTMwNSAwIFIgMTMwNyAwIFJdCi9JRCAobm9kZTAwMDAyMDMzKT4+CmVuZG9i agoxMzExIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzEwIDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjMwPj5dCi9JRCAobm9kZTAwMDAy MDQ2KT4+CmVuZG9iagoxMzEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEz MDkgMCBSCi9LIFsxMzExIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAx MTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAw MDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMjA0NSk+PgplbmRvYmoKMTMwOSAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEzMTAgMCBSXQovSUQgKG5vZGUwMDAwMjA0 Mik+PgplbmRvYmoKMTMxNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMTMxMyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIzMT4+XQovSUQg KG5vZGUwMDAwMjA1Mik+PgplbmRvYmoKMTMxMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCAxMzEyIDAgUgovSyBbMTMxNCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5 MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIwNTEpPj4KZW5kb2JqCjEzMTYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzMTUgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMzI+Pl0KL0lEIChub2RlMDAwMDIwNTQpPj4KZW5kb2Jq CjEzMTUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTMxMiAwIFIKL0sgWzEz MTYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAw MDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2Rl MDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAyMDUzKT4+CmVuZG9iagoxMzE4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAxMzE3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQg MjMzPj5dCi9JRCAobm9kZTAwMDAyMDU2KT4+CmVuZG9iagoxMzE3IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDEzMTIgMCBSCi9LIFsxMzE4IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAo bm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjA1NSk+PgplbmRvYmoK MTMxMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzEzMTMg MCBSIDEzMTUgMCBSIDEzMTcgMCBSXQovSUQgKG5vZGUwMDAwMjA0OSk+PgplbmRvYmoKMTMyMSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTMyMCAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIzND4+XQovSUQgKG5vZGUwMDAwMjA2Mik+Pgpl bmRvYmoKMTMyMCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzE5IDAgUgov SyBbMTMyMSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5v ZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4Mykg KG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDIwNjEpPj4KZW5kb2JqCjEzMTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzIwIDAgUl0KL0lEIChub2RlMDAwMDIwNTgpPj4KZW5k b2JqCjEzMjQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzMjMg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyMzU+Pl0KL0lEIChub2RlMDAw MDIwNjgpPj4KZW5kb2JqCjEzMjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTMyMiAwIFIKL0sgWzEzMjQgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2Rl MDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDY3KT4+CmVuZG9iagoxMzI2IDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzI1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMjM2Pj5dCi9JRCAobm9kZTAwMDAyMDcwKT4+CmVuZG9iagoxMzI1IDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzMjIgMCBSCi9LIFsxMzI2IDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAo bm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5 KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MjA2OSk+PgplbmRvYmoKMTMyOCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTMyNyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDIzNz4+XQov SUQgKG5vZGUwMDAwMjA3Mik+PgplbmRvYmoKMTMyNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMzIyIDAgUgovSyBbMTMyOCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAw MTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIwNzEpPj4KZW5kb2JqCjEzMjIgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzIzIDAgUiAxMzI1 IDAgUiAxMzI3IDAgUl0KL0lEIChub2RlMDAwMDIwNjUpPj4KZW5kb2JqCjEzMzEgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzMzAgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAyMzg+Pl0KL0lEIChub2RlMDAwMDIwNzcpPj4KZW5kb2JqCjEz MzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTMyOSAwIFIKL0sgWzEzMzEg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAy NjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAw MDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAyMDc2KT4+CmVuZG9iagoxMzMzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxMzMyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjM5 Pj5dCi9JRCAobm9kZTAwMDAyMDc5KT4+CmVuZG9iagoxMzMyIDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDEzMjkgMCBSCi9LIFsxMzMzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9k ZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjA3OCk+PgplbmRvYmoKMTMz NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTMzNCAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI0MD4+XQovSUQgKG5vZGUwMDAwMjA4MSk+ PgplbmRvYmoKMTMzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzI5IDAg UgovSyBbMTMzNSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkg KG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4 NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDIwODApPj4KZW5kb2JqCjEzMjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzMwIDAgUiAxMzMyIDAgUiAxMzM0IDAgUl0KL0lE IChub2RlMDAwMDIwNzQpPj4KZW5kb2JqCjEzMzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDEzMzcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJ RCAyNDE+Pl0KL0lEIChub2RlMDAwMDIwODYpPj4KZW5kb2JqCjEzMzcgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMTMzNiAwIFIKL0sgWzEzMzggMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIp IChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIw MTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDg1KT4+CmVuZG9i agoxMzQwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzM5IDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjQyPj5dCi9JRCAobm9kZTAwMDAy MDg4KT4+CmVuZG9iagoxMzM5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEz MzYgMCBSCi9LIFsxMzQwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAx MTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAw MDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMjA4Nyk+PgplbmRvYmoKMTM0MiAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTM0MSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcg MTggMCBSCi9NQ0lEIDI0Mz4+XQovSUQgKG5vZGUwMDAwMjA5MCk+PgplbmRvYmoKMTM0MSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzM2IDAgUgovSyBbMTM0MiAwIFJdCi9B IFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5v ZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkg KG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFi bGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIw ODkpPj4KZW5kb2JqCjEzMzYgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQg MCBSCi9LIFsxMzM3IDAgUiAxMzM5IDAgUiAxMzQxIDAgUl0KL0lEIChub2RlMDAwMDIwODMpPj4K ZW5kb2JqCjEzNDUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEz NDQgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNDQ+Pl0KL0lEIChub2Rl MDAwMDIwOTUpPj4KZW5kb2JqCjEzNDQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgMTM0MyAwIFIKL0sgWzEzNDUgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChu b2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMDk0KT4+CmVuZG9iagoxMzQ3IDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzQ2IDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAxOCAwIFIKL01DSUQgMjQ1Pj5dCi9JRCAobm9kZTAwMDAyMDk3KT4+CmVuZG9iagoxMzQ2 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzNDMgMCBSCi9LIFsxMzQ3IDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcy KSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAx ODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMjA5Nik+PgplbmRvYmoKMTM0OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgMTM0OCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI0Nj4+ XQovSUQgKG5vZGUwMDAwMjA5OSk+PgplbmRvYmoKMTM0OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9URAovUCAxMzQzIDAgUgovSyBbMTM0OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVh ZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUw MDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5v ZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8 L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIwOTgpPj4KZW5kb2JqCjEzNDMg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzQ0IDAgUiAx MzQ2IDAgUiAxMzQ4IDAgUl0KL0lEIChub2RlMDAwMDIwOTIpPj4KZW5kb2JqCjEzNTIgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzNTEgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNDc+Pl0KL0lEIChub2RlMDAwMDIxMDQpPj4KZW5kb2Jq CjEzNTEgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTM1MCAwIFIKL0sgWzEz NTIgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAw MDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2Rl MDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAyMTAzKT4+CmVuZG9iagoxMzU0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAxMzUzIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQg MjQ4Pj5dCi9JRCAobm9kZTAwMDAyMTA2KT4+CmVuZG9iagoxMzUzIDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDEzNTAgMCBSCi9LIFsxMzU0IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAo bm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjEwNSk+PgplbmRvYmoK MTM1NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTM1NSAwIFIK L0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI0OT4+XQovSUQgKG5vZGUwMDAwMjEw OCk+PgplbmRvYmoKMTM1NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzUw IDAgUgovSyBbMTM1NiAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIy MSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAw MTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUw MDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFu IDE+Pl0KL0lEIChub2RlMDAwMDIxMDcpPj4KZW5kb2JqCjEzNTAgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzUxIDAgUiAxMzUzIDAgUiAxMzU1IDAgUl0K L0lEIChub2RlMDAwMDIxMDEpPj4KZW5kb2JqCjEzNTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDEzNTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCAyNTA+Pl0KL0lEIChub2RlMDAwMDIxMTUpPj4KZW5kb2JqCjEzNjAgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzNTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IK L1BnIDE4IDAgUgovTUNJRCAyNTE+Pl0KL0lEIChub2RlMDAwMDIxMTYpPj4KZW5kb2JqCjEzNjEg MCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzNTggMCBSCi9LIFs8 PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNTI+Pl0KL0lEIChub2RlMDAwMDIxMTcpPj4K ZW5kb2JqCjEzNjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEz NTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNTM+Pl0KL0lEIChub2Rl MDAwMDIxMTgpPj4KZW5kb2JqCjEzNjMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9u U3RydWN0Ci9QIDEzNTggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNTQ+ Pl0KL0lEIChub2RlMDAwMDIxMTkpPj4KZW5kb2JqCjEzNTggMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVEQKL1AgMTM1NyAwIFIKL0sgWzEzNTkgMCBSIDEzNjAgMCBSIDEzNjEgMCBSIDEz NjIgMCBSIDEzNjMgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjAp IChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1 NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAw MDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAx Pj5dCi9JRCAobm9kZTAwMDAyMTE0KT4+CmVuZG9iagoxMzY1IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzY0IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAw IFIKL01DSUQgMjU1Pj5dCi9JRCAobm9kZTAwMDAyMTIxKT4+CmVuZG9iagoxMzY0IDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzNTcgMCBSCi9LIFsxMzY1IDAgUl0KL0EgWzw8 L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAw MDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9k ZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQov Um93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjEyMCk+ PgplbmRvYmoKMTM2NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTM2NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI1Nj4+XQovSUQgKG5v ZGUwMDAwMjEyMyk+PgplbmRvYmoKMTM2OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9O b25TdHJ1Y3QKL1AgMTM2NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI1 Nz4+XQovSUQgKG5vZGUwMDAwMjEyNCk+PgplbmRvYmoKMTM2OSAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTM2NiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDI1OD4+XQovSUQgKG5vZGUwMDAwMjEyNSk+PgplbmRvYmoKMTM2NiAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzU3IDAgUgovSyBbMTM2NyAwIFIgMTM2OCAw IFIgMTM2OSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5v ZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkg KG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDIxMjIpPj4KZW5kb2JqCjEzNTcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzU4IDAgUiAxMzY0IDAgUiAxMzY2IDAgUl0KL0lEIChu b2RlMDAwMDIxMTIpPj4KZW5kb2JqCjEzNzIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv Tm9uU3RydWN0Ci9QIDEzNzEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAy NTk+Pl0KL0lEIChub2RlMDAwMDIxMzApPj4KZW5kb2JqCjEzNzEgMCBvYmoKPDwvVHlwZSAvU3Ry dWN0RWxlbQovUyAvVEQKL1AgMTM3MCAwIFIKL0sgWzEzNzIgMCBSXQovQSBbPDwvTyAvVGFibGUK L0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChu b2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQp IChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+ PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMTI5KT4+CmVuZG9iagox Mzc0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzczIDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjYwPj5dCi9JRCAobm9kZTAwMDAyMTMy KT4+CmVuZG9iagoxMzczIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzNzAg MCBSCi9LIFsxMzc0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMjEzMSk+PgplbmRvYmoKMTM3NiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTM3NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDI2MT4+XQovSUQgKG5vZGUwMDAwMjEzNCk+PgplbmRvYmoKMTM3NSAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzcwIDAgUgovSyBbMTM3NiAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUw MDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5v ZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIxMzMp Pj4KZW5kb2JqCjEzNzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBS Ci9LIFsxMzcxIDAgUiAxMzczIDAgUiAxMzc1IDAgUl0KL0lEIChub2RlMDAwMDIxMjcpPj4KZW5k b2JqCjEzNzkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzNzgg MCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNjI+Pl0KL0lEIChub2RlMDAw MDIxMzkpPj4KZW5kb2JqCjEzNzggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1Ag MTM3NyAwIFIKL0sgWzEzNzkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAw MDAyMjApIChub2RlMDAwMDAyNjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2Rl MDAwMDE1NzkpIChub2RlMDAwMDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChu b2RlMDAwMDIyNTEpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29s U3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMTM4KT4+CmVuZG9iagoxMzgxIDAgb2JqCjw8L1R5cGUg L1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzgwIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9Q ZyAxOCAwIFIKL01DSUQgMjYzPj5dCi9JRCAobm9kZTAwMDAyMTQxKT4+CmVuZG9iagoxMzgwIDAg b2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzNzcgMCBSCi9LIFsxMzgxIDAgUl0K L0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAo bm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5 KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9U YWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAw MjE0MCk+PgplbmRvYmoKMTM4MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTM4MiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI2ND4+XQov SUQgKG5vZGUwMDAwMjE0Myk+PgplbmRvYmoKMTM4MiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxMzc3IDAgUgovSyBbMTM4MyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMDIyMSkgKG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAw MTI5NSkgKG5vZGUwMDAwMTU4NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIxNDIpPj4KZW5kb2JqCjEzNzcgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzc4IDAgUiAxMzgw IDAgUiAxMzgyIDAgUl0KL0lEIChub2RlMDAwMDIxMzYpPj4KZW5kb2JqCjEzODYgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzODUgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAyNjU+Pl0KL0lEIChub2RlMDAwMDIxNDgpPj4KZW5kb2JqCjEz ODUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTM4NCAwIFIKL0sgWzEzODYg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjApIChub2RlMDAwMDAy NjYpIChub2RlMDAwMDAzMjIpIChub2RlMDAwMDEyOTMpIChub2RlMDAwMDE1NzkpIChub2RlMDAw MDE4MTUpIChub2RlMDAwMDIwMTQpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTEpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAyMTQ3KT4+CmVuZG9iagoxMzg4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxMzg3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjY2 Pj5dCi9JRCAobm9kZTAwMDAyMTUwKT4+CmVuZG9iagoxMzg3IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDEzODQgMCBSCi9LIFsxMzg4IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAxMTQ3KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9k ZTAwMDAxMjk0KSAobm9kZTAwMDAxNTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjE0OSk+PgplbmRvYmoKMTM5 MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTM4OSAwIFIKL0sg Wzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI2Nz4+XQovSUQgKG5vZGUwMDAwMjE1Mik+ PgplbmRvYmoKMTM4OSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxMzg0IDAg UgovSyBbMTM5MCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMSkg KG5vZGUwMDAwMDI2NykgKG5vZGUwMDAwMDMyMykgKG5vZGUwMDAwMTI5NSkgKG5vZGUwMDAwMTU4 NCkgKG5vZGUwMDAwMTgyMCkgKG5vZGUwMDAwMjAxOSkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAw MjI1NCldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+ Pl0KL0lEIChub2RlMDAwMDIxNTEpPj4KZW5kb2JqCjEzODQgMCBvYmoKPDwvVHlwZSAvU3RydWN0 RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxMzg1IDAgUiAxMzg3IDAgUiAxMzg5IDAgUl0KL0lE IChub2RlMDAwMDIxNDUpPj4KZW5kb2JqCjEzOTMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDEzOTIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJ RCAyNjg+Pl0KL0lEIChub2RlMDAwMDIxNTgpPj4KZW5kb2JqCjEzOTIgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMTM5MSAwIFIKL0sgWzEzOTMgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkp IChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIw MTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMTU3KT4+CmVuZG9i agoxMzkxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBbMTM5 MiAwIFJdCi9JRCAobm9kZTAwMDAyMTU0KT4+CmVuZG9iagoxMzk2IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxMzk1IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAx OCAwIFIKL01DSUQgMjY5Pj5dCi9JRCAobm9kZTAwMDAyMTY0KT4+CmVuZG9iagoxMzk1IDAgb2Jq Cjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDEzOTQgMCBSCi9LIFsxMzk2IDAgUl0KL0Eg Wzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9k ZTAwMDAwMzIyKSAobm9kZTAwMDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAo bm9kZTAwMDAyMDE0KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJs ZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjE2 Myk+PgplbmRvYmoKMTM5OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMTM5NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI3MD4+XQovSUQg KG5vZGUwMDAwMjE2Nik+PgplbmRvYmoKMTM5NyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCAxMzk0IDAgUgovSyBbMTM5OCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5 NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIxNjUpPj4KZW5kb2JqCjE0MDAgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDEzOTkgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyNzE+Pl0KL0lEIChub2RlMDAwMDIxNjgpPj4KZW5kb2Jq CjEzOTkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTM5NCAwIFIKL0sgWzE0 MDAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAw MDAyNjcpIChub2RlMDAwMDAzMjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2Rl MDAwMDE4MjApIChub2RlMDAwMDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAyMTY3KT4+CmVuZG9iagoxMzk0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L1RSCi9QIDM0IDAgUgovSyBbMTM5NSAwIFIgMTM5NyAwIFIgMTM5OSAwIFJdCi9JRCAobm9kZTAw MDAyMTYxKT4+CmVuZG9iagoxNDAzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0 cnVjdAovUCAxNDAyIDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjcyPj5d Ci9JRCAobm9kZTAwMDAyMTczKT4+CmVuZG9iagoxNDAyIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVs ZW0KL1MgL1RECi9QIDE0MDEgMCBSCi9LIFsxNDAzIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFk ZXJzIFsobm9kZTAwMDAwMjIwKSAobm9kZTAwMDAwMjY2KSAobm9kZTAwMDAwMzIyKSAobm9kZTAw MDAxMjkzKSAobm9kZTAwMDAxNTc5KSAobm9kZTAwMDAxODE1KSAobm9kZTAwMDAyMDE0KSAobm9k ZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjUxKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwv TyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjE3Mik+PgplbmRvYmoKMTQwNSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQwNCAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI3Mz4+XQovSUQgKG5vZGUwMDAwMjE3NSk+Pgpl bmRvYmoKMTQwNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNDAxIDAgUgov SyBbMTQwNSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMTE0NykgKG5v ZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAwMTI5NCkgKG5vZGUwMDAwMTU4Mykg KG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDIxNzQpPj4KZW5kb2JqCjE0MDcgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDE0MDYgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCAyNzQ+Pl0KL0lEIChub2RlMDAwMDIxNzcpPj4KZW5kb2JqCjE0MDYgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTQwMSAwIFIKL0sgWzE0MDcgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDAyMjEpIChub2RlMDAwMDAyNjcpIChub2RlMDAwMDAz MjMpIChub2RlMDAwMDEyOTUpIChub2RlMDAwMDE1ODQpIChub2RlMDAwMDE4MjApIChub2RlMDAw MDIwMTkpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTQpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMTc2KT4+CmVu ZG9iagoxNDAxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RSCi9QIDM0IDAgUgovSyBb MTQwMiAwIFIgMTQwNCAwIFIgMTQwNiAwIFJdCi9JRCAobm9kZTAwMDAyMTcwKT4+CmVuZG9iagox NDEwIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDA5IDAgUgov SyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjc1Pj5dCi9JRCAobm9kZTAwMDAyMTgz KT4+CmVuZG9iagoxNDA5IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0MDgg MCBSCi9LIFsxNDEwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ3 KSAobm9kZTAwMDAxMTcyKSAobm9kZTAwMDAxMTk5KSAobm9kZTAwMDAxMjk0KSAobm9kZTAwMDAx NTgzKSAobm9kZTAwMDAxODE5KSAobm9kZTAwMDAyMDE4KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAw MDAyMjUzKV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMjE4Mik+PgplbmRvYmoKMTQwOCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0MDkgMCBSXQovSUQgKG5vZGUwMDAwMjE3OSk+ PgplbmRvYmoKMTQxMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1Ag MTQxMiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI3Nj4+XQovSUQgKG5v ZGUwMDAwMjE4OSk+PgplbmRvYmoKMTQxMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U RAovUCAxNDExIDAgUgovSyBbMTQxMyAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5v ZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5Mykg KG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0 NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxl Ci9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIxODgpPj4KZW5kb2JqCjE0MTUgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE0MTQgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDE4IDAgUgovTUNJRCAyNzc+Pl0KL0lEIChub2RlMDAwMDIxOTEpPj4KZW5kb2JqCjE0 MTQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTQxMSAwIFIKL0sgWzE0MTUg MCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDEx NzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAw MDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8 L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9k ZTAwMDAyMTkwKT4+CmVuZG9iagoxNDE3IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05v blN0cnVjdAovUCAxNDE2IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjc4 Pj5dCi9JRCAobm9kZTAwMDAyMTkzKT4+CmVuZG9iagoxNDE2IDAgb2JqCjw8L1R5cGUgL1N0cnVj dEVsZW0KL1MgL1RECi9QIDE0MTEgMCBSCi9LIFsxNDE3IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9I ZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9k ZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAo bm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4g PDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjE5Mik+PgplbmRvYmoKMTQx MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0MTIgMCBS IDE0MTQgMCBSIDE0MTYgMCBSXQovSUQgKG5vZGUwMDAwMjE4Nik+PgplbmRvYmoKMTQyMCAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQxOSAwIFIKL0sgWzw8L1R5 cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI3OT4+XQovSUQgKG5vZGUwMDAwMjE5OCk+PgplbmRv YmoKMTQxOSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNDE4IDAgUgovSyBb MTQyMCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUw MDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5v ZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSld Pj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lE IChub2RlMDAwMDIxOTcpPj4KZW5kb2JqCjE0MjIgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDE0MjEgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJ RCAyODA+Pl0KL0lEIChub2RlMDAwMDIyMDApPj4KZW5kb2JqCjE0MjEgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEQKL1AgMTQxOCAwIFIKL0sgWzE0MjIgMCBSXQovQSBbPDwvTyAvVGFi bGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkp IChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIw MTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFu IDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMTk5KT4+CmVuZG9i agoxNDI0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDIzIDAg UgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjgxPj5dCi9JRCAobm9kZTAwMDAy MjAyKT4+CmVuZG9iagoxNDIzIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0 MTggMCBSCi9LIFsxNDI0IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAw MjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAw MDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9k ZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gMT4+XQovSUQgKG5vZGUwMDAwMjIwMSk+PgplbmRvYmoKMTQxOCAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0MTkgMCBSIDE0MjEgMCBSIDE0MjMgMCBS XQovSUQgKG5vZGUwMDAwMjE5NSk+PgplbmRvYmoKMTQyNyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RF bGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQyNiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBS Ci9NQ0lEIDI4Mj4+XQovSUQgKG5vZGUwMDAwMjIwNyk+PgplbmRvYmoKMTQyNiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNDI1IDAgUgovSyBbMTQyNyAwIFJdCi9BIFs8PC9P IC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAw MDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUw MDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jv d1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIyMDYpPj4K ZW5kb2JqCjE0MjkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE0 MjggMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyODM+Pl0KL0lEIChub2Rl MDAwMDIyMDkpPj4KZW5kb2JqCjE0MjggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQK L1AgMTQyNSAwIFIKL0sgWzE0MjkgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2Rl MDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChu b2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcp IChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQov Q29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMjA4KT4+CmVuZG9iagoxNDMxIDAgb2JqCjw8L1R5 cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDMwIDAgUgovSyBbPDwvVHlwZSAvTUNS Ci9QZyAxOCAwIFIKL01DSUQgMjg0Pj5dCi9JRCAobm9kZTAwMDAyMjExKT4+CmVuZG9iagoxNDMw IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0MjUgMCBSCi9LIFsxNDMxIDAg Ul0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3 KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAx ODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9P IC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUw MDAwMjIxMCk+PgplbmRvYmoKMTQyNSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgov UCAzNCAwIFIKL0sgWzE0MjYgMCBSIDE0MjggMCBSIDE0MzAgMCBSXQovSUQgKG5vZGUwMDAwMjIw NCk+PgplbmRvYmoKMTQzNCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QK L1AgMTQzMyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI4NT4+XQovSUQg KG5vZGUwMDAwMjIxNik+PgplbmRvYmoKMTQzMyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9T IC9URAovUCAxNDMyIDAgUgovSyBbMTQzNCAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBb KG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5 MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAw MjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1Rh YmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIyMTUpPj4KZW5kb2JqCjE0MzYgMCBvYmoK PDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE0MzUgMCBSCi9LIFs8PC9UeXBl IC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyODY+Pl0KL0lEIChub2RlMDAwMDIyMTgpPj4KZW5kb2Jq CjE0MzUgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTQzMiAwIFIKL0sgWzE0 MzYgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAw MDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2Rl MDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+ IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAo bm9kZTAwMDAyMjE3KT4+CmVuZG9iagoxNDM4IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1Mg L05vblN0cnVjdAovUCAxNDM3IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQg Mjg3Pj5dCi9JRCAobm9kZTAwMDAyMjIwKT4+CmVuZG9iagoxNDM3IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDE0MzIgMCBSCi9LIFsxNDM4IDAgUl0KL0EgWzw8L08gL1RhYmxl Ci9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAo bm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5 KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAx Pj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjIxOSk+PgplbmRvYmoK MTQzMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0MzMg MCBSIDE0MzUgMCBSIDE0MzcgMCBSXQovSUQgKG5vZGUwMDAwMjIxMyk+PgplbmRvYmoKMTQ0MSAw IG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ0MCAwIFIKL0sgWzw8 L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI4OD4+XQovSUQgKG5vZGUwMDAwMjIyNSk+Pgpl bmRvYmoKMTQ0MCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNDM5IDAgUgov SyBbMTQ0MSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5v ZGUwMDAwMDI2NikgKG5vZGUwMDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkg KG5vZGUwMDAwMTgxNSkgKG5vZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1 MSldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0K L0lEIChub2RlMDAwMDIyMjQpPj4KZW5kb2JqCjE0NDMgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvTm9uU3RydWN0Ci9QIDE0NDIgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgov TUNJRCAyODk+Pl0KL0lEIChub2RlMDAwMDIyMjcpPj4KZW5kb2JqCjE0NDIgMCBvYmoKPDwvVHlw ZSAvU3RydWN0RWxlbQovUyAvVEQKL1AgMTQzOSAwIFIKL0sgWzE0NDMgMCBSXQovQSBbPDwvTyAv VGFibGUKL0hlYWRlcnMgWyhub2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDEx OTkpIChub2RlMDAwMDEyOTQpIChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAw MDIwMTgpIChub2RlMDAwMDIyNDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dT cGFuIDE+PiA8PC9PIC9UYWJsZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMjI2KT4+CmVu ZG9iagoxNDQ1IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDQ0 IDAgUgovSyBbPDwvVHlwZSAvTUNSCi9QZyAxOCAwIFIKL01DSUQgMjkwPj5dCi9JRCAobm9kZTAw MDAyMjI5KT4+CmVuZG9iagoxNDQ0IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9Q IDE0MzkgMCBSCi9LIFsxNDQ1IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAw MDAwMjIxKSAobm9kZTAwMDAwMjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9k ZTAwMDAxNTg0KSAobm9kZTAwMDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAo bm9kZTAwMDAyMjU0KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0Nv bFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjIyOCk+PgplbmRvYmoKMTQzOSAwIG9iago8PC9UeXBl IC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0NDAgMCBSIDE0NDIgMCBSIDE0NDQg MCBSXQovSUQgKG5vZGUwMDAwMjIyMik+PgplbmRvYmoKMTQ0OCAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ0NyAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTgg MCBSCi9NQ0lEIDI5MT4+XQovSUQgKG5vZGUwMDAwMjIzNCk+PgplbmRvYmoKMTQ0NyAwIG9iago8 PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9URAovUCAxNDQ2IDAgUgovSyBbMTQ0OCAwIFJdCi9BIFs8 PC9PIC9UYWJsZQovSGVhZGVycyBbKG5vZGUwMDAwMDIyMCkgKG5vZGUwMDAwMDI2NikgKG5vZGUw MDAwMDMyMikgKG5vZGUwMDAwMTI5MykgKG5vZGUwMDAwMTU3OSkgKG5vZGUwMDAwMTgxNSkgKG5v ZGUwMDAwMjAxNCkgKG5vZGUwMDAwMjI0NykgKG5vZGUwMDAwMjI1MSldPj4gPDwvTyAvVGFibGUK L1Jvd1NwYW4gMT4+IDw8L08gL1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIyMzMp Pj4KZW5kb2JqCjE0NTAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9Q IDE0NDkgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJRCAyOTI+Pl0KL0lEIChu b2RlMDAwMDIyMzYpPj4KZW5kb2JqCjE0NDkgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAv VEQKL1AgMTQ0NiAwIFIKL0sgWzE0NTAgMCBSXQovQSBbPDwvTyAvVGFibGUKL0hlYWRlcnMgWyhu b2RlMDAwMDExNDcpIChub2RlMDAwMDExNzIpIChub2RlMDAwMDExOTkpIChub2RlMDAwMDEyOTQp IChub2RlMDAwMDE1ODMpIChub2RlMDAwMDE4MTkpIChub2RlMDAwMDIwMTgpIChub2RlMDAwMDIy NDcpIChub2RlMDAwMDIyNTMpXT4+IDw8L08gL1RhYmxlCi9Sb3dTcGFuIDE+PiA8PC9PIC9UYWJs ZQovQ29sU3BhbiAxPj5dCi9JRCAobm9kZTAwMDAyMjM1KT4+CmVuZG9iagoxNDUyIDAgb2JqCjw8 L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDUxIDAgUgovSyBbPDwvVHlwZSAv TUNSCi9QZyAxOCAwIFIKL01DSUQgMjkzPj5dCi9JRCAobm9kZTAwMDAyMjM3KT4+CmVuZG9iagox NDUxIDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL1RECi9QIDE0NDYgMCBSCi9LIFsxNDUy IDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAwMjIxKSAobm9kZTAwMDAw MjY3KSAobm9kZTAwMDAwMzIzKSAobm9kZTAwMDAxMjk1KSAobm9kZTAwMDAxNTg0KSAobm9kZTAw MDAxODIwKSAobm9kZTAwMDAyMDE5KSAobm9kZTAwMDAyMjQ3KSAobm9kZTAwMDAyMjU0KV0+PiA8 PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5v ZGUwMDAwMDQwMik+PgplbmRvYmoKMTQ0NiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9U UgovUCAzNCAwIFIKL0sgWzE0NDcgMCBSIDE0NDkgMCBSIDE0NTEgMCBSXQovSUQgKG5vZGUwMDAw MjIzMSk+PgplbmRvYmoKMTQ1NSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25TdHJ1 Y3QKL1AgMTQ1NCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMTggMCBSCi9NQ0lEIDI5ND4+XQov SUQgKG5vZGUwMDAwMjI0Myk+PgplbmRvYmoKMTQ1NCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVt Ci9TIC9URAovUCAxNDUzIDAgUgovSyBbMTQ1NSAwIFJdCi9BIFs8PC9PIC9UYWJsZQovSGVhZGVy cyBbKG5vZGUwMDAwMTE0NykgKG5vZGUwMDAwMTE3MikgKG5vZGUwMDAwMTE5OSkgKG5vZGUwMDAw MTI5NCkgKG5vZGUwMDAwMTU4MykgKG5vZGUwMDAwMTgxOSkgKG5vZGUwMDAwMjAxOCkgKG5vZGUw MDAwMjI0NykgKG5vZGUwMDAwMjI1MyldPj4gPDwvTyAvVGFibGUKL1Jvd1NwYW4gMT4+IDw8L08g L1RhYmxlCi9Db2xTcGFuIDE+Pl0KL0lEIChub2RlMDAwMDIyNDIpPj4KZW5kb2JqCjE0NTMgMCBv YmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVFIKL1AgMzQgMCBSCi9LIFsxNDU0IDAgUl0KL0lE IChub2RlMDAwMDIyMzkpPj4KZW5kb2JqCjE0NTggMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDE0NTcgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDE4IDAgUgovTUNJ RCAyOTU+Pl0KL0lEIChub2RlMDAwMDIyNDgpPj4KZW5kb2JqCjE0NTcgMCBvYmoKPDwvVHlwZSAv U3RydWN0RWxlbQovUyAvVEgKL1AgMTQ1NiAwIFIKL0sgWzE0NTggMCBSXQovQSBbPDwvTyAvVGFi bGUKL1Njb3BlIC9Db2x1bW4+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUK L0NvbFNwYW4gNT4+XQovSUQgKG5vZGUwMDAwMjI0Nyk+PgplbmRvYmoKMTQ1NiAwIG9iago8PC9U eXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0NTcgMCBSXQovSUQgKG5vZGUw MDAwMjI0Nik+PgplbmRvYmoKMTQ2MSAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Ob25T dHJ1Y3QKL1AgMTQ2MCAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMjYgMCBSCi9NQ0lEIDA+Pl0K L0lEIChub2RlMDAwMDIyNTIpPj4KZW5kb2JqCjE0NjAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxl bQovUyAvVEgKL1AgMTQ1OSAwIFIKL0sgWzE0NjEgMCBSXQovQSBbPDwvTyAvVGFibGUKL1Njb3Bl IC9Db2x1bW4+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNwYW4g MT4+XQovSUQgKG5vZGUwMDAwMjI1MSk+PgplbmRvYmoKMTQ2MyAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ2MiAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMjYg MCBSCi9NQ0lEIDE+Pl0KL0lEIChub2RlMDAwMDIyNTUpPj4KZW5kb2JqCjE0NjIgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvVEgKL1AgMTQ1OSAwIFIKL0sgWzE0NjMgMCBSXQovQSBbPDwv TyAvVGFibGUKL1Njb3BlIC9Db2x1bW4+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAv VGFibGUKL0NvbFNwYW4gMT4+XQovSUQgKG5vZGUwMDAwMjI1NCk+PgplbmRvYmoKMTQ1OSAwIG9i ago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0NjAgMCBSIDE0NjIg MCBSXQovSUQgKG5vZGUwMDAwMjI0OSk+PgplbmRvYmoKMTQ2NiAwIG9iago8PC9UeXBlIC9TdHJ1 Y3RFbGVtCi9TIC9Ob25TdHJ1Y3QKL1AgMTQ2NSAwIFIKL0sgWzw8L1R5cGUgL01DUgovUGcgMjYg MCBSCi9NQ0lEIDI+Pl0KL0lEIChub2RlMDAwMDIyNTkpPj4KZW5kb2JqCjE0NjcgMCBvYmoKPDwv VHlwZSAvU3RydWN0RWxlbQovUyAvTm9uU3RydWN0Ci9QIDE0NjUgMCBSCi9LIFs8PC9UeXBlIC9N Q1IKL1BnIDI2IDAgUgovTUNJRCAzPj5dCi9JRCAobm9kZTAwMDAyMjYwKT4+CmVuZG9iagoxNDY5 IDAgb2JqCjw8L1R5cGUgL1N0cnVjdEVsZW0KL1MgL05vblN0cnVjdAovUCAxNDY4IDAgUgovSyBb PDwvVHlwZSAvTUNSCi9QZyAyNiAwIFIKL01DSUQgND4+XQovSUQgKG5vZGUwMDAwMjI2Mik+Pgpl bmRvYmoKMTQ2OCAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9MaW5rCi9QIDE0NjUgMCBS Ci9LIFsxNDY5IDAgUiA8PC9UeXBlIC9PQkpSCi9PYmogMjggMCBSCi9QZyAyNiAwIFI+Pl0KL0lE IChub2RlMDAwMDIyNjEpPj4KZW5kb2JqCjE0NzAgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQov UyAvTm9uU3RydWN0Ci9QIDE0NjUgMCBSCi9LIFs8PC9UeXBlIC9NQ1IKL1BnIDI2IDAgUgovTUNJ RCA1Pj5dCi9JRCAobm9kZTAwMDAyMjYzKT4+CmVuZG9iagoxNDY1IDAgb2JqCjw8L1R5cGUgL1N0 cnVjdEVsZW0KL1MgL1RECi9QIDE0NjQgMCBSCi9LIFsxNDY2IDAgUiAxNDY3IDAgUiAxNDY4IDAg UiAxNDcwIDAgUl0KL0EgWzw8L08gL1RhYmxlCi9IZWFkZXJzIFsobm9kZTAwMDAxMTQ2KSAobm9k ZTAwMDAyMjQ3KV0+PiA8PC9PIC9UYWJsZQovUm93U3BhbiAxPj4gPDwvTyAvVGFibGUKL0NvbFNw YW4gNT4+XQovSUQgKG5vZGUwMDAwMjI1OCk+PgplbmRvYmoKMTQ2NCAwIG9iago8PC9UeXBlIC9T dHJ1Y3RFbGVtCi9TIC9UUgovUCAzNCAwIFIKL0sgWzE0NjUgMCBSXQovSUQgKG5vZGUwMDAwMjI1 Nyk+PgplbmRvYmoKMzQgMCBvYmoKPDwvVHlwZSAvU3RydWN0RWxlbQovUyAvVGFibGUKL1AgMzMg MCBSCi9LIFszNSAwIFIgNDUgMCBSIDQ4IDAgUiA1NSAwIFIgNjIgMCBSIDY5IDAgUiA4MCAwIFIg ODcgMCBSIDk4IDAgUiAxMDEgMCBSIDEwOCAwIFIgMTE1IDAgUiAxMTggMCBSIDEyNSAwIFIgMTI4 IDAgUiAxMzUgMCBSIDE0MiAwIFIgMTQ5IDAgUiAxNTYgMCBSIDE1OSAwIFIgMTY4IDAgUiAxNzUg MCBSIDE4MiAwIFIgMTg5IDAgUiAxOTYgMCBSIDE5OSAwIFIgMjA2IDAgUiAyMTMgMCBSIDIyMCAw IFIgMjI3IDAgUiAyMzAgMCBSIDI0MSAwIFIgMjQ0IDAgUiAyNTEgMCBSIDI1NCAwIFIgMjYxIDAg UiAyNjggMCBSIDI3MSAwIFIgMjc4IDAgUiAyODUgMCBSIDI5MiAwIFIgMjk5IDAgUiAzMDIgMCBS IDMxMSAwIFIgMzE4IDAgUiAzMjUgMCBSIDMzMiAwIFIgMzM5IDAgUiAzNDYgMCBSIDM1MyAwIFIg MzYwIDAgUiAzNjcgMCBSIDM3NCAwIFIgMzgxIDAgUiAzOTAgMCBSIDM5NyAwIFIgNDA0IDAgUiA0 MTMgMCBSIDQyMCAwIFIgNDI3IDAgUiA0MzQgMCBSIDQ0MSAwIFIgNDUwIDAgUiA0NTkgMCBSIDQ2 OCAwIFIgNDc3IDAgUiA0ODYgMCBSIDQ5NSAwIFIgNTA0IDAgUiA1MTMgMCBSIDUyMCAwIFIgNTI5 IDAgUiA1MzggMCBSIDU0NyAwIFIgNTU2IDAgUiA1NjUgMCBSIDU3NCAwIFIgNTgzIDAgUiA1OTIg MCBSIDYwMSAwIFIgNjEwIDAgUiA2MTkgMCBSIDYyOCAwIFIgNjM3IDAgUiA2NDYgMCBSIDY1NSAw IFIgNjU4IDAgUiA2NjUgMCBSIDY2OCAwIFIgNjc1IDAgUiA2ODIgMCBSIDY4OSAwIFIgNjk2IDAg UiA3MDMgMCBSIDcwNiAwIFIgNzEzIDAgUiA3MTYgMCBSIDcyNSAwIFIgNzMyIDAgUiA3MzkgMCBS IDc0NiAwIFIgNzUzIDAgUiA3NjAgMCBSIDc2MyAwIFIgNzcwIDAgUiA3NzMgMCBSIDc4MCAwIFIg NzgzIDAgUiA3OTQgMCBSIDgwMyAwIFIgODEwIDAgUiA4MTcgMCBSIDgyNCAwIFIgODMxIDAgUiA4 MzggMCBSIDg0MSAwIFIgODQ4IDAgUiA4NTcgMCBSIDg2NiAwIFIgODczIDAgUiA4ODAgMCBSIDg4 NyAwIFIgODk0IDAgUiA5MDEgMCBSIDkwOCAwIFIgOTE1IDAgUiA5MTggMCBSIDkyNSAwIFIgOTMy IDAgUiA5MzkgMCBSIDk0NiAwIFIgOTUzIDAgUiA5NjAgMCBSIDk2MyAwIFIgOTcwIDAgUiA5Nzcg MCBSIDk4MCAwIFIgOTg5IDAgUiA5OTIgMCBSIDk5OSAwIFIgMTAwMiAwIFIgMTAwOSAwIFIgMTAx NiAwIFIgMTAyMyAwIFIgMTAzMCAwIFIgMTAzMyAwIFIgMTA0MCAwIFIgMTA0NyAwIFIgMTA1OCAw IFIgMTA2NSAwIFIgMTA3MiAwIFIgMTA3OSAwIFIgMTA4NCAwIFIgMTA4NyAwIFIgMTA5NCAwIFIg MTEwMSAwIFIgMTEwOCAwIFIgMTExNSAwIFIgMTEyMiAwIFIgMTEyOSAwIFIgMTEzMiAwIFIgMTEz OSAwIFIgMTE0NiAwIFIgMTE0OSAwIFIgMTE1OCAwIFIgMTE2MSAwIFIgMTE2OCAwIFIgMTE3NSAw IFIgMTE3OCAwIFIgMTE4NSAwIFIgMTE4OCAwIFIgMTE5NSAwIFIgMTE5OCAwIFIgMTIwNSAwIFIg MTIxMiAwIFIgMTIyMSAwIFIgMTIyNCAwIFIgMTIzMSAwIFIgMTIzOCAwIFIgMTI0NSAwIFIgMTI0 OCAwIFIgMTI1NSAwIFIgMTI2MiAwIFIgMTI2OSAwIFIgMTI3NiAwIFIgMTI4MyAwIFIgMTI4NiAw IFIgMTI5NSAwIFIgMTMwMiAwIFIgMTMwOSAwIFIgMTMxMiAwIFIgMTMxOSAwIFIgMTMyMiAwIFIg MTMyOSAwIFIgMTMzNiAwIFIgMTM0MyAwIFIgMTM1MCAwIFIgMTM1NyAwIFIgMTM3MCAwIFIgMTM3 NyAwIFIgMTM4NCAwIFIgMTM5MSAwIFIgMTM5NCAwIFIgMTQwMSAwIFIgMTQwOCAwIFIgMTQxMSAw IFIgMTQxOCAwIFIgMTQyNSAwIFIgMTQzMiAwIFIgMTQzOSAwIFIgMTQ0NiAwIFIgMTQ1MyAwIFIg MTQ1NiAwIFIgMTQ1OSAwIFIgMTQ2NCAwIFJdCi9JRCAobm9kZTAwMDAxMTQ1KT4+CmVuZG9iagoz MyAwIG9iago8PC9UeXBlIC9TdHJ1Y3RFbGVtCi9TIC9Eb2N1bWVudAovTGFuZyAoZW4tVVMpCi9Q IDMyIDAgUgovSyBbMzQgMCBSXQovSUQgKG5vZGUwMDAwMDIxOSk+PgplbmRvYmoKMTQ3MSAwIG9i agpbMzggMCBSIDM5IDAgUiA0MSAwIFIgNDIgMCBSIDQ0IDAgUiA0NyAwIFIgNTAgMCBSIDUyIDAg UiA1NCAwIFIgNTcgMCBSIDU5IDAgUiA2MSAwIFIgNjQgMCBSIDY2IDAgUiA2OCAwIFIgNzEgMCBS IDcyIDAgUiA3MyAwIFIgNzUgMCBSIDc3IDAgUiA3OCAwIFIgNzkgMCBSIDgyIDAgUiA4NCAwIFIg ODYgMCBSIDg5IDAgUiA5MCAwIFIgOTEgMCBSIDkzIDAgUiA5NSAwIFIgOTYgMCBSIDk3IDAgUiAx MDAgMCBSIDEwMyAwIFIgMTA1IDAgUiAxMDcgMCBSIDExMCAwIFIgMTEyIDAgUiAxMTQgMCBSIDEx NyAwIFIgMTIwIDAgUiAxMjIgMCBSIDEyNCAwIFIgMTI3IDAgUiAxMzAgMCBSIDEzMiAwIFIgMTM0 IDAgUiAxMzcgMCBSIDEzOSAwIFIgMTQxIDAgUiAxNDQgMCBSIDE0NiAwIFIgMTQ4IDAgUiAxNTEg MCBSIDE1MyAwIFIgMTU1IDAgUiAxNTggMCBSIDE2MSAwIFIgMTYzIDAgUiAxNjUgMCBSIDE2NyAw IFIgMTcwIDAgUiAxNzIgMCBSIDE3NCAwIFIgMTc3IDAgUiAxNzkgMCBSIDE4MSAwIFIgMTg0IDAg UiAxODYgMCBSIDE4OCAwIFIgMTkxIDAgUiAxOTMgMCBSIDE5NSAwIFIgMTk4IDAgUiAyMDEgMCBS IDIwMyAwIFIgMjA1IDAgUiAyMDggMCBSIDIxMCAwIFIgMjEyIDAgUiAyMTUgMCBSIDIxNyAwIFIg MjE5IDAgUiAyMjIgMCBSIDIyNCAwIFIgMjI2IDAgUiAyMjkgMCBSIDIzMiAwIFIgMjMzIDAgUiAy MzQgMCBSIDIzNiAwIFIgMjM4IDAgUiAyMzkgMCBSIDI0MCAwIFIgMjQzIDAgUiAyNDYgMCBSIDI0 OCAwIFIgMjUwIDAgUiAyNTMgMCBSIDI1NiAwIFIgMjU4IDAgUiAyNjAgMCBSIDI2MyAwIFIgMjY1 IDAgUiAyNjcgMCBSIDI3MCAwIFIgMjczIDAgUiAyNzUgMCBSIDI3NyAwIFIgMjgwIDAgUiAyODIg MCBSIDI4NCAwIFIgMjg3IDAgUiAyODkgMCBSIDI5MSAwIFIgMjk0IDAgUiAyOTYgMCBSIDI5OCAw IFIgMzAxIDAgUiAzMDQgMCBSIDMwNiAwIFIgMzA4IDAgUiAzMTAgMCBSIDMxMyAwIFIgMzE1IDAg UiAzMTcgMCBSIDMyMCAwIFIgMzIyIDAgUiAzMjQgMCBSIDMyNyAwIFIgMzI5IDAgUiAzMzEgMCBS IDMzNCAwIFIgMzM2IDAgUiAzMzggMCBSIDM0MSAwIFIgMzQzIDAgUiAzNDUgMCBSIDM0OCAwIFIg MzUwIDAgUiAzNTIgMCBSIDM1NSAwIFIgMzU3IDAgUiAzNTkgMCBSIDM2MiAwIFIgMzY0IDAgUiAz NjYgMCBSIDM2OSAwIFIgMzcxIDAgUiAzNzMgMCBSIDM3NiAwIFIgMzc4IDAgUiAzODAgMCBSIDM4 MyAwIFIgMzg0IDAgUiAzODYgMCBSIDM4OCAwIFIgMzg5IDAgUiAzOTIgMCBSIDM5NCAwIFIgMzk2 IDAgUiAzOTkgMCBSIDQwMSAwIFIgNDAzIDAgUiA0MDYgMCBSIDQwNyAwIFIgNDA5IDAgUiA0MTEg MCBSIDQxMiAwIFIgNDE1IDAgUiA0MTcgMCBSIDQxOSAwIFIgNDIyIDAgUiA0MjQgMCBSIDQyNiAw IFIgNDI5IDAgUiA0MzEgMCBSIDQzMyAwIFIgNDM2IDAgUiA0MzggMCBSIDQ0MCAwIFIgNDQzIDAg UiA0NDQgMCBSIDQ0NiAwIFIgNDQ4IDAgUiA0NDkgMCBSIDQ1MiAwIFIgNDUzIDAgUiA0NTUgMCBS IDQ1NyAwIFIgNDU4IDAgUiA0NjEgMCBSIDQ2MiAwIFIgNDY0IDAgUiA0NjYgMCBSIDQ2NyAwIFIg NDcwIDAgUiA0NzEgMCBSIDQ3MyAwIFIgNDc1IDAgUiA0NzYgMCBSIDQ3OSAwIFIgNDgwIDAgUiA0 ODIgMCBSIDQ4NCAwIFIgNDg1IDAgUiA0ODggMCBSIDQ4OSAwIFIgNDkxIDAgUiA0OTMgMCBSIDQ5 NCAwIFIgNDk3IDAgUiA0OTggMCBSIDUwMCAwIFIgNTAyIDAgUiA1MDMgMCBSIDUwNiAwIFIgNTA3 IDAgUiA1MDkgMCBSIDUxMSAwIFIgNTEyIDAgUiA1MTUgMCBSIDUxNyAwIFIgNTE5IDAgUiA1MjIg MCBSIDUyMyAwIFIgNTI1IDAgUiA1MjcgMCBSIDUyOCAwIFIgNTMxIDAgUiA1MzIgMCBSIDUzNCAw IFIgNTM2IDAgUiA1MzcgMCBSIDU0MCAwIFIgNTQxIDAgUiA1NDMgMCBSIDU0NSAwIFIgNTQ2IDAg UiA1NDkgMCBSIDU1MCAwIFIgNTUyIDAgUiA1NTQgMCBSIDU1NSAwIFIgNTU4IDAgUiA1NTkgMCBS IDU2MSAwIFIgNTYzIDAgUiA1NjQgMCBSIDU2NyAwIFIgNTY4IDAgUiA1NzAgMCBSIDU3MiAwIFIg NTczIDAgUiA1NzYgMCBSIDU3NyAwIFIgNTc5IDAgUiA1ODEgMCBSIDU4MiAwIFIgNTg1IDAgUiA1 ODYgMCBSIDU4OCAwIFIgNTkwIDAgUiA1OTEgMCBSIDU5NCAwIFIgNTk1IDAgUiA1OTcgMCBSIDU5 OSAwIFIgNjAwIDAgUiA2MDMgMCBSIDYwNCAwIFIgNjA2IDAgUiA2MDggMCBSIDYwOSAwIFIgNjEy IDAgUiA2MTMgMCBSIDYxNSAwIFIgNjE3IDAgUiA2MTggMCBSIDYyMSAwIFIgNjIyIDAgUiA2MjQg MCBSIDYyNiAwIFIgNjI3IDAgUiA2MzAgMCBSIDYzMSAwIFIgNjMzIDAgUiA2MzUgMCBSIDYzNiAw IFIgNjM5IDAgUiA2NDAgMCBSIDY0MiAwIFIgNjQ0IDAgUiA2NDUgMCBSIDY0OCAwIFIgNjQ5IDAg UiA2NTEgMCBSIDY1MyAwIFIgNjU0IDAgUiA2NTcgMCBSIDY2MCAwIFIgNjYyIDAgUiA2NjQgMCBS IDY2NyAwIFIgNjcwIDAgUiA2NzIgMCBSIDY3NCAwIFIgNjc3IDAgUiA2NzkgMCBSIDY4MSAwIFIg Njg0IDAgUiA2ODYgMCBSIDY4OCAwIFIgNjkxIDAgUiA2OTMgMCBSIDY5NSAwIFIgNjk4IDAgUiA3 MDAgMCBSIDcwMiAwIFIgNzA1IDAgUiA3MDggMCBSIDcxMCAwIFIgNzEyIDAgUiA3MTUgMCBSIDcx OCAwIFIgNzIwIDAgUiA3MjIgMCBSIDcyNCAwIFIgNzI3IDAgUiA3MjkgMCBSIDczMSAwIFIgNzM0 IDAgUiA3MzYgMCBSIDczOCAwIFIgNzQxIDAgUiA3NDMgMCBSIDc0NSAwIFIgNzQ4IDAgUiA3NTAg MCBSIDc1MiAwIFIgNzU1IDAgUiA3NTcgMCBSIDc1OSAwIFIgNzYyIDAgUiA3NjUgMCBSIDc2NyAw IFIgNzY5IDAgUiA3NzIgMCBSIDc3NSAwIFIgNzc3IDAgUiA3NzkgMCBSIDc4MiAwIFJdCmVuZG9i agoxNDcyIDAgb2JqCls3ODUgMCBSIDc4NiAwIFIgNzg3IDAgUiA3ODkgMCBSIDc5MSAwIFIgNzky IDAgUiA3OTMgMCBSIDc5NiAwIFIgNzk3IDAgUiA3OTggMCBSIDgwMCAwIFIgODAyIDAgUiA4MDUg MCBSIDgwNyAwIFIgODA5IDAgUiA4MTIgMCBSIDgxNCAwIFIgODE2IDAgUiA4MTkgMCBSIDgyMSAw IFIgODIzIDAgUiA4MjYgMCBSIDgyOCAwIFIgODMwIDAgUiA4MzMgMCBSIDgzNSAwIFIgODM3IDAg UiA4NDAgMCBSIDg0MyAwIFIgODQ1IDAgUiA4NDcgMCBSIDg1MCAwIFIgODUxIDAgUiA4NTMgMCBS IDg1NSAwIFIgODU2IDAgUiA4NTkgMCBSIDg2MCAwIFIgODYyIDAgUiA4NjQgMCBSIDg2NSAwIFIg ODY4IDAgUiA4NzAgMCBSIDg3MiAwIFIgODc1IDAgUiA4NzcgMCBSIDg3OSAwIFIgODgyIDAgUiA4 ODQgMCBSIDg4NiAwIFIgODg5IDAgUiA4OTEgMCBSIDg5MyAwIFIgODk2IDAgUiA4OTggMCBSIDkw MCAwIFIgOTAzIDAgUiA5MDUgMCBSIDkwNyAwIFIgOTEwIDAgUiA5MTIgMCBSIDkxNCAwIFIgOTE3 IDAgUiA5MjAgMCBSIDkyMiAwIFIgOTI0IDAgUiA5MjcgMCBSIDkyOSAwIFIgOTMxIDAgUiA5MzQg MCBSIDkzNiAwIFIgOTM4IDAgUiA5NDEgMCBSIDk0MyAwIFIgOTQ1IDAgUiA5NDggMCBSIDk1MCAw IFIgOTUyIDAgUiA5NTUgMCBSIDk1NyAwIFIgOTU5IDAgUiA5NjIgMCBSIDk2NSAwIFIgOTY3IDAg UiA5NjkgMCBSIDk3MiAwIFIgOTc0IDAgUiA5NzYgMCBSIDk3OSAwIFIgOTgyIDAgUiA5ODQgMCBS IDk4NiAwIFIgOTg4IDAgUiA5OTEgMCBSIDk5NCAwIFIgOTk2IDAgUiA5OTggMCBSIDEwMDEgMCBS IDEwMDQgMCBSIDEwMDYgMCBSIDEwMDggMCBSIDEwMTEgMCBSIDEwMTMgMCBSIDEwMTUgMCBSIDEw MTggMCBSIDEwMjAgMCBSIDEwMjIgMCBSIDEwMjUgMCBSIDEwMjcgMCBSIDEwMjkgMCBSIDEwMzIg MCBSIDEwMzUgMCBSIDEwMzcgMCBSIDEwMzkgMCBSIDEwNDIgMCBSIDEwNDQgMCBSIDEwNDYgMCBS IDEwNDkgMCBSIDEwNTAgMCBSIDEwNTEgMCBSIDEwNTMgMCBSIDEwNTUgMCBSIDEwNTYgMCBSIDEw NTcgMCBSIDEwNjAgMCBSIDEwNjIgMCBSIDEwNjQgMCBSIDEwNjcgMCBSIDEwNjkgMCBSIDEwNzEg MCBSIDEwNzQgMCBSIDEwNzYgMCBSIDEwNzggMCBSIDEwODEgMCBSIDEwODMgMCBSIDEwODYgMCBS IDEwODkgMCBSIDEwOTEgMCBSIDEwOTMgMCBSIDEwOTYgMCBSIDEwOTggMCBSIDExMDAgMCBSIDEx MDMgMCBSIDExMDUgMCBSIDExMDcgMCBSIDExMTAgMCBSIDExMTIgMCBSIDExMTQgMCBSIDExMTcg MCBSIDExMTkgMCBSIDExMjEgMCBSIDExMjQgMCBSIDExMjYgMCBSIDExMjggMCBSIDExMzEgMCBS IDExMzQgMCBSIDExMzYgMCBSIDExMzggMCBSIDExNDEgMCBSIDExNDMgMCBSIDExNDUgMCBSIDEx NDggMCBSIDExNTEgMCBSIDExNTMgMCBSIDExNTUgMCBSIDExNTcgMCBSIDExNjAgMCBSIDExNjMg MCBSIDExNjUgMCBSIDExNjcgMCBSIDExNzAgMCBSIDExNzIgMCBSIDExNzQgMCBSIDExNzcgMCBS IDExODAgMCBSIDExODIgMCBSIDExODQgMCBSIDExODcgMCBSIDExOTAgMCBSIDExOTIgMCBSIDEx OTQgMCBSIDExOTcgMCBSIDEyMDAgMCBSIDEyMDIgMCBSIDEyMDQgMCBSIDEyMDcgMCBSIDEyMDkg MCBSIDEyMTEgMCBSIDEyMTQgMCBSIDEyMTUgMCBSIDEyMTYgMCBSIDEyMTggMCBSIDEyMjAgMCBS IDEyMjMgMCBSIDEyMjYgMCBSIDEyMjggMCBSIDEyMzAgMCBSIDEyMzMgMCBSIDEyMzUgMCBSIDEy MzcgMCBSIDEyNDAgMCBSIDEyNDIgMCBSIDEyNDQgMCBSIDEyNDcgMCBSIDEyNTAgMCBSIDEyNTIg MCBSIDEyNTQgMCBSIDEyNTcgMCBSIDEyNTkgMCBSIDEyNjEgMCBSIDEyNjQgMCBSIDEyNjYgMCBS IDEyNjggMCBSIDEyNzEgMCBSIDEyNzMgMCBSIDEyNzUgMCBSIDEyNzggMCBSIDEyODAgMCBSIDEy ODIgMCBSIDEyODUgMCBSIDEyODggMCBSIDEyOTAgMCBSIDEyOTIgMCBSIDEyOTQgMCBSIDEyOTcg MCBSIDEyOTkgMCBSIDEzMDEgMCBSIDEzMDQgMCBSIDEzMDYgMCBSIDEzMDggMCBSIDEzMTEgMCBS IDEzMTQgMCBSIDEzMTYgMCBSIDEzMTggMCBSIDEzMjEgMCBSIDEzMjQgMCBSIDEzMjYgMCBSIDEz MjggMCBSIDEzMzEgMCBSIDEzMzMgMCBSIDEzMzUgMCBSIDEzMzggMCBSIDEzNDAgMCBSIDEzNDIg MCBSIDEzNDUgMCBSIDEzNDcgMCBSIDEzNDkgMCBSIDEzNTIgMCBSIDEzNTQgMCBSIDEzNTYgMCBS IDEzNTkgMCBSIDEzNjAgMCBSIDEzNjEgMCBSIDEzNjIgMCBSIDEzNjMgMCBSIDEzNjUgMCBSIDEz NjcgMCBSIDEzNjggMCBSIDEzNjkgMCBSIDEzNzIgMCBSIDEzNzQgMCBSIDEzNzYgMCBSIDEzNzkg MCBSIDEzODEgMCBSIDEzODMgMCBSIDEzODYgMCBSIDEzODggMCBSIDEzOTAgMCBSIDEzOTMgMCBS IDEzOTYgMCBSIDEzOTggMCBSIDE0MDAgMCBSIDE0MDMgMCBSIDE0MDUgMCBSIDE0MDcgMCBSIDE0 MTAgMCBSIDE0MTMgMCBSIDE0MTUgMCBSIDE0MTcgMCBSIDE0MjAgMCBSIDE0MjIgMCBSIDE0MjQg MCBSIDE0MjcgMCBSIDE0MjkgMCBSIDE0MzEgMCBSIDE0MzQgMCBSIDE0MzYgMCBSIDE0MzggMCBS IDE0NDEgMCBSIDE0NDMgMCBSIDE0NDUgMCBSIDE0NDggMCBSIDE0NTAgMCBSIDE0NTIgMCBSIDE0 NTUgMCBSIDE0NTggMCBSXQplbmRvYmoKMTQ3MyAwIG9iagpbMTQ2MSAwIFIgMTQ2MyAwIFIgMTQ2 NiAwIFIgMTQ2NyAwIFIgMTQ2OSAwIFIgMTQ3MCAwIFJdCmVuZG9iagoxNDc0IDAgb2JqCjw8L1R5 cGUgL1BhcmVudFRyZWUKL051bXMgWzAgMTQ3MSAwIFIgMSAxNDcyIDAgUiAyIDE0NzMgMCBSIDEw MDAwMCAzNyAwIFIgMTAwMDAxIDQwIDAgUiAxMDAwMDIgMTYyIDAgUiAxMDAwMDMgMTY2IDAgUiAx MDAwMDQgMzA1IDAgUiAxMDAwMDUgMzA5IDAgUiAxMDAwMDYgNzE5IDAgUiAxMDAwMDcgNzIzIDAg UiAxMDAwMDggOTgzIDAgUiAxMDAwMDkgOTg3IDAgUiAxMDAwMTAgMTE1MiAwIFIgMTAwMDExIDEx NTYgMCBSIDEwMDAxMiAxMjg5IDAgUiAxMDAwMTMgMTI5MyAwIFIgMTAwMDE0IDE0NjggMCBSXT4+ CmVuZG9iagoxNDc1IDAgb2JqCjw8L0xpbWl0cyBbKG5vZGUwMDAwMDIxOSkgKG5vZGUwMDAwMjI2 MyldCi9OYW1lcyBbKG5vZGUwMDAwMDIxOSkgMzMgMCBSIChub2RlMDAwMDAyMjApIDM2IDAgUiAo bm9kZTAwMDAwMjIxKSA0MyAwIFIgKG5vZGUwMDAwMDIyMikgNDYgMCBSIChub2RlMDAwMDAyMjMp IDQ5IDAgUiAobm9kZTAwMDAwMjI0KSA1MSAwIFIgKG5vZGUwMDAwMDIyNSkgNTMgMCBSIChub2Rl MDAwMDAyMjYpIDU2IDAgUiAobm9kZTAwMDAwMjI3KSA1OCAwIFIgKG5vZGUwMDAwMDIyOCkgNjAg MCBSIChub2RlMDAwMDAyMjkpIDYzIDAgUiAobm9kZTAwMDAwMjMwKSA2NSAwIFIgKG5vZGUwMDAw MDIzMSkgNjcgMCBSIChub2RlMDAwMDAyMzIpIDcwIDAgUiAobm9kZTAwMDAwMjMzKSA3NCAwIFIg KG5vZGUwMDAwMDIzNCkgNzYgMCBSIChub2RlMDAwMDAyMzUpIDgxIDAgUiAobm9kZTAwMDAwMjM2 KSA4MyAwIFIgKG5vZGUwMDAwMDIzNykgODUgMCBSIChub2RlMDAwMDAyMzgpIDg4IDAgUiAobm9k ZTAwMDAwMjM5KSA5MiAwIFIgKG5vZGUwMDAwMDI0MCkgOTQgMCBSIChub2RlMDAwMDAyNDEpIDk5 IDAgUiAobm9kZTAwMDAwMjQyKSAxMDIgMCBSIChub2RlMDAwMDAyNDMpIDEwNCAwIFIgKG5vZGUw MDAwMDI0NCkgMTA2IDAgUiAobm9kZTAwMDAwMjQ1KSAxMDkgMCBSIChub2RlMDAwMDAyNDYpIDEx MSAwIFIgKG5vZGUwMDAwMDI0NykgMTEzIDAgUiAobm9kZTAwMDAwMjQ4KSAxMTYgMCBSIChub2Rl MDAwMDAyNDkpIDExOSAwIFIgKG5vZGUwMDAwMDI1MCkgMTIxIDAgUiAobm9kZTAwMDAwMjUxKSAx MjMgMCBSIChub2RlMDAwMDAyNTIpIDEyNiAwIFIgKG5vZGUwMDAwMDI1MykgMTI5IDAgUiAobm9k ZTAwMDAwMjU0KSAxMzEgMCBSIChub2RlMDAwMDAyNTUpIDEzMyAwIFIgKG5vZGUwMDAwMDI1Nikg MTM2IDAgUiAobm9kZTAwMDAwMjU3KSAxMzggMCBSIChub2RlMDAwMDAyNTgpIDE0MCAwIFIgKG5v ZGUwMDAwMDI1OSkgMTQzIDAgUiAobm9kZTAwMDAwMjYwKSAxNDUgMCBSIChub2RlMDAwMDAyNjEp IDE0NyAwIFIgKG5vZGUwMDAwMDI2MikgMTUwIDAgUiAobm9kZTAwMDAwMjYzKSAxNTIgMCBSIChu b2RlMDAwMDAyNjQpIDE1NCAwIFIgKG5vZGUwMDAwMDI2NSkgMTU3IDAgUiAobm9kZTAwMDAwMjY2 KSAxNjAgMCBSIChub2RlMDAwMDAyNjcpIDE2NCAwIFIgKG5vZGUwMDAwMDI2OCkgMTY5IDAgUiAo bm9kZTAwMDAwMjY5KSAxNzEgMCBSIChub2RlMDAwMDAyNzApIDE3MyAwIFIgKG5vZGUwMDAwMDI3 MSkgMTc2IDAgUiAobm9kZTAwMDAwMjcyKSAxNzggMCBSIChub2RlMDAwMDAyNzMpIDE4MCAwIFIg KG5vZGUwMDAwMDI3NCkgMTgzIDAgUiAobm9kZTAwMDAwMjc1KSAxODUgMCBSIChub2RlMDAwMDAy NzYpIDE4NyAwIFIgKG5vZGUwMDAwMDI3NykgMTkwIDAgUiAobm9kZTAwMDAwMjc4KSAxOTIgMCBS IChub2RlMDAwMDAyNzkpIDE5NCAwIFIgKG5vZGUwMDAwMDI4MCkgMTk3IDAgUiAobm9kZTAwMDAw MjgxKSAyMDAgMCBSIChub2RlMDAwMDAyODIpIDIwMiAwIFIgKG5vZGUwMDAwMDI4MykgMjA0IDAg UiAobm9kZTAwMDAwMjg0KSAyMDcgMCBSIChub2RlMDAwMDAyODUpIDIwOSAwIFIgKG5vZGUwMDAw MDI4NikgMjExIDAgUiAobm9kZTAwMDAwMjg3KSAyMTQgMCBSIChub2RlMDAwMDAyODgpIDIxNiAw IFIgKG5vZGUwMDAwMDI4OSkgMjE4IDAgUiAobm9kZTAwMDAwMjkwKSAyMjEgMCBSIChub2RlMDAw MDAyOTEpIDIyMyAwIFIgKG5vZGUwMDAwMDI5MikgMjI1IDAgUiAobm9kZTAwMDAwMjkzKSAyMjgg MCBSIChub2RlMDAwMDAyOTQpIDIzMSAwIFIgKG5vZGUwMDAwMDI5NSkgMjM1IDAgUiAobm9kZTAw MDAwMjk2KSAyMzcgMCBSIChub2RlMDAwMDAyOTcpIDI0MiAwIFIgKG5vZGUwMDAwMDI5OCkgMjQ1 IDAgUiAobm9kZTAwMDAwMjk5KSAyNDcgMCBSIChub2RlMDAwMDAzMDApIDI0OSAwIFIgKG5vZGUw MDAwMDMwMSkgMjUyIDAgUiAobm9kZTAwMDAwMzAyKSAyNTUgMCBSIChub2RlMDAwMDAzMDMpIDI1 NyAwIFIgKG5vZGUwMDAwMDMwNCkgMjU5IDAgUiAobm9kZTAwMDAwMzA1KSAyNjIgMCBSIChub2Rl MDAwMDAzMDYpIDI2NCAwIFIgKG5vZGUwMDAwMDMwNykgMjY2IDAgUiAobm9kZTAwMDAwMzA4KSAy NjkgMCBSIChub2RlMDAwMDAzMDkpIDI3MiAwIFIgKG5vZGUwMDAwMDMxMCkgMjc0IDAgUiAobm9k ZTAwMDAwMzExKSAyNzYgMCBSIChub2RlMDAwMDAzMTIpIDI3OSAwIFIgKG5vZGUwMDAwMDMxMykg MjgxIDAgUiAobm9kZTAwMDAwMzE0KSAyODMgMCBSIChub2RlMDAwMDAzMTUpIDI4NiAwIFIgKG5v ZGUwMDAwMDMxNikgMjg4IDAgUiAobm9kZTAwMDAwMzE3KSAyOTAgMCBSIChub2RlMDAwMDAzMTgp IDI5MyAwIFIgKG5vZGUwMDAwMDMxOSkgMjk1IDAgUiAobm9kZTAwMDAwMzIwKSAyOTcgMCBSIChu b2RlMDAwMDAzMjEpIDMwMCAwIFIgKG5vZGUwMDAwMDMyMikgMzAzIDAgUiAobm9kZTAwMDAwMzIz KSAzMDcgMCBSIChub2RlMDAwMDAzMjQpIDMxMiAwIFIgKG5vZGUwMDAwMDMyNSkgMzE0IDAgUiAo bm9kZTAwMDAwMzI2KSAzMTYgMCBSIChub2RlMDAwMDAzMjcpIDMxOSAwIFIgKG5vZGUwMDAwMDMy OCkgMzIxIDAgUiAobm9kZTAwMDAwMzI5KSAzMjMgMCBSIChub2RlMDAwMDAzMzApIDMyNiAwIFIg KG5vZGUwMDAwMDMzMSkgMzI4IDAgUiAobm9kZTAwMDAwMzMyKSAzMzAgMCBSIChub2RlMDAwMDAz MzMpIDMzMyAwIFIgKG5vZGUwMDAwMDMzNCkgMzM1IDAgUiAobm9kZTAwMDAwMzM1KSAzMzcgMCBS IChub2RlMDAwMDAzMzYpIDM0MCAwIFIgKG5vZGUwMDAwMDMzNykgMzQyIDAgUiAobm9kZTAwMDAw MzM4KSAzNDQgMCBSIChub2RlMDAwMDAzMzkpIDM0NyAwIFIgKG5vZGUwMDAwMDM0MCkgMzQ5IDAg UiAobm9kZTAwMDAwMzQxKSAzNTEgMCBSIChub2RlMDAwMDAzNDIpIDM1NCAwIFIgKG5vZGUwMDAw MDM0MykgMzU2IDAgUiAobm9kZTAwMDAwMzQ0KSAzNTggMCBSIChub2RlMDAwMDAzNDUpIDM2MSAw IFIgKG5vZGUwMDAwMDM0NikgMzYzIDAgUiAobm9kZTAwMDAwMzQ3KSAzNjUgMCBSIChub2RlMDAw MDAzNDgpIDM2OCAwIFIgKG5vZGUwMDAwMDM0OSkgMzcwIDAgUiAobm9kZTAwMDAwMzUwKSAzNzIg MCBSIChub2RlMDAwMDAzNTEpIDM3NSAwIFIgKG5vZGUwMDAwMDM1MikgMzc3IDAgUiAobm9kZTAw MDAwMzUzKSAzNzkgMCBSIChub2RlMDAwMDAzNTQpIDM4MiAwIFIgKG5vZGUwMDAwMDM1NSkgMzg1 IDAgUiAobm9kZTAwMDAwMzU2KSAzODcgMCBSIChub2RlMDAwMDAzNTcpIDM5MSAwIFIgKG5vZGUw MDAwMDM1OCkgMzkzIDAgUiAobm9kZTAwMDAwMzU5KSAzOTUgMCBSIChub2RlMDAwMDAzNjApIDM5 OCAwIFIgKG5vZGUwMDAwMDM2MSkgNDAwIDAgUiAobm9kZTAwMDAwMzYyKSA0MDIgMCBSIChub2Rl MDAwMDAzNjMpIDQwNSAwIFIgKG5vZGUwMDAwMDM2NCkgNDA4IDAgUiAobm9kZTAwMDAwMzY1KSA0 MTAgMCBSIChub2RlMDAwMDAzNjYpIDQxNCAwIFIgKG5vZGUwMDAwMDM2NykgNDE2IDAgUiAobm9k ZTAwMDAwMzY4KSA0MTggMCBSIChub2RlMDAwMDAzNjkpIDQyMSAwIFIgKG5vZGUwMDAwMDM3MCkg NDIzIDAgUiAobm9kZTAwMDAwMzcxKSA0MjUgMCBSIChub2RlMDAwMDAzNzIpIDQyOCAwIFIgKG5v ZGUwMDAwMDM3MykgNDMwIDAgUiAobm9kZTAwMDAwMzc0KSA0MzIgMCBSIChub2RlMDAwMDAzNzUp IDQzNSAwIFIgKG5vZGUwMDAwMDM3NikgNDM3IDAgUiAobm9kZTAwMDAwMzc3KSA0MzkgMCBSIChu b2RlMDAwMDAzNzgpIDQ0MiAwIFIgKG5vZGUwMDAwMDM3OSkgNDQ1IDAgUiAobm9kZTAwMDAwMzgw KSA0NDcgMCBSIChub2RlMDAwMDAzODEpIDQ1MSAwIFIgKG5vZGUwMDAwMDM4MikgNDU0IDAgUiAo bm9kZTAwMDAwMzgzKSA0NTYgMCBSIChub2RlMDAwMDAzODQpIDQ2MCAwIFIgKG5vZGUwMDAwMDM4 NSkgNDYzIDAgUiAobm9kZTAwMDAwMzg2KSA0NjUgMCBSIChub2RlMDAwMDAzODcpIDQ2OSAwIFIg KG5vZGUwMDAwMDM4OCkgNDcyIDAgUiAobm9kZTAwMDAwMzg5KSA0NzQgMCBSIChub2RlMDAwMDAz OTApIDQ3OCAwIFIgKG5vZGUwMDAwMDM5MSkgNDgxIDAgUiAobm9kZTAwMDAwMzkyKSA0ODMgMCBS IChub2RlMDAwMDAzOTMpIDcxMSAwIFIgKG5vZGUwMDAwMDM5NCkgODg1IDAgUiAobm9kZTAwMDAw Mzk1KSA3MzAgMCBSIChub2RlMDAwMDAzOTYpIDkwNiAwIFIgKG5vZGUwMDAwMDM5NykgOTEzIDAg UiAobm9kZTAwMDAwMzk4KSAxMDc3IDAgUiAobm9kZTAwMDAwMzk5KSAxMTEzIDAgUiAobm9kZTAw MDAwNDAwKSAxMjc0IDAgUiAobm9kZTAwMDAwNDAxKSAxMTIwIDAgUiAobm9kZTAwMDAwNDAyKSAx NDUxIDAgUiAobm9kZTAwMDAwNDE0KSAzNSAwIFIgKG5vZGUwMDAwMDQxNSkgMTU5IDAgUiAobm9k ZTAwMDAwNDE2KSAzMDIgMCBSIChub2RlMDAwMDA0MTcpIDcxNiAwIFIgKG5vZGUwMDAwMDU2Nykg NDg3IDAgUiAobm9kZTAwMDAwNTY4KSA0OTIgMCBSIChub2RlMDAwMDA1NzEpIDQ5NiAwIFIgKG5v ZGUwMDAwMDU3MikgNTAxIDAgUiAobm9kZTAwMDAwNTc1KSA1MDUgMCBSIChub2RlMDAwMDA1NzYp IDUxMCAwIFIgKG5vZGUwMDAwMDU3OSkgNTE0IDAgUiAobm9kZTAwMDAwNTgwKSA1MTggMCBSIChu b2RlMDAwMDA1ODMpIDUyMSAwIFIgKG5vZGUwMDAwMDU4NCkgNTI2IDAgUiAobm9kZTAwMDAwNTg3 KSA1MzAgMCBSIChub2RlMDAwMDA1ODgpIDUzNSAwIFIgKG5vZGUwMDAwMDU5MSkgNTM5IDAgUiAo bm9kZTAwMDAwNTkyKSA1NDQgMCBSIChub2RlMDAwMDA1OTUpIDU0OCAwIFIgKG5vZGUwMDAwMDU5 NikgNTUzIDAgUiAobm9kZTAwMDAwNTk5KSA1NTcgMCBSIChub2RlMDAwMDA2MDApIDU2MiAwIFIg KG5vZGUwMDAwMDYwMykgNTY2IDAgUiAobm9kZTAwMDAwNjA0KSA1NzEgMCBSIChub2RlMDAwMDA2 MDcpIDU3NSAwIFIgKG5vZGUwMDAwMDYwOCkgNTgwIDAgUiAobm9kZTAwMDAwNjExKSA1ODQgMCBS IChub2RlMDAwMDA2MTIpIDU4OSAwIFIgKG5vZGUwMDAwMDYxNSkgNTkzIDAgUiAobm9kZTAwMDAw NjE2KSA1OTggMCBSIChub2RlMDAwMDA2MTkpIDYwMiAwIFIgKG5vZGUwMDAwMDYyMCkgNjA3IDAg UiAobm9kZTAwMDAwNjIzKSA2MTEgMCBSIChub2RlMDAwMDA2MjQpIDYxNiAwIFIgKG5vZGUwMDAw MDYyNykgNjIwIDAgUiAobm9kZTAwMDAwNjI4KSA2MjUgMCBSIChub2RlMDAwMDA2MzEpIDYyOSAw IFIgKG5vZGUwMDAwMDYzMikgNjM0IDAgUiAobm9kZTAwMDAwNjM1KSA2MzggMCBSIChub2RlMDAw MDA2MzYpIDY0MyAwIFIgKG5vZGUwMDAwMDYzOSkgNjQ3IDAgUiAobm9kZTAwMDAwNjQwKSA2NTIg MCBSIChub2RlMDAwMDA2NDcpIDY1OSAwIFIgKG5vZGUwMDAwMDY0OCkgNjYzIDAgUiAobm9kZTAw MDAwNjU1KSA2NjkgMCBSIChub2RlMDAwMDA2NTYpIDY3MyAwIFIgKG5vZGUwMDAwMDY1OSkgNjc2 IDAgUiAobm9kZTAwMDAwNjYwKSA2ODAgMCBSIChub2RlMDAwMDA2NjMpIDY4MyAwIFIgKG5vZGUw MDAwMDY2NCkgNjg3IDAgUiAobm9kZTAwMDAwNjY3KSA2OTAgMCBSIChub2RlMDAwMDA2NjgpIDY5 NCAwIFIgKG5vZGUwMDAwMDY3MSkgNjk3IDAgUiAobm9kZTAwMDAwNjcyKSA3MDEgMCBSIChub2Rl MDAwMDA2NzkpIDcwNyAwIFIgKG5vZGUwMDAwMDY4NikgNzI2IDAgUiAobm9kZTAwMDAwNjg5KSA3 MzMgMCBSIChub2RlMDAwMDA2OTApIDczNyAwIFIgKG5vZGUwMDAwMDY5MykgNzQwIDAgUiAobm9k ZTAwMDAwNjk0KSA3NDQgMCBSIChub2RlMDAwMDA2OTcpIDc0NyAwIFIgKG5vZGUwMDAwMDY5OCkg NzUxIDAgUiAobm9kZTAwMDAwNzAxKSA3NTQgMCBSIChub2RlMDAwMDA3MDIpIDc1OCAwIFIgKG5v ZGUwMDAwMDcwOSkgNzY0IDAgUiAobm9kZTAwMDAwNzEwKSA3NjggMCBSIChub2RlMDAwMDA3MTcp IDc3NCAwIFIgKG5vZGUwMDAwMDcxOCkgNzc4IDAgUiAobm9kZTAwMDAwNzI1KSA3ODQgMCBSIChu b2RlMDAwMDA3MjYpIDc5MCAwIFIgKG5vZGUwMDAwMDcyOCkgMzcgMCBSIChub2RlMDAwMDA3Mjkp IDQwIDAgUiAobm9kZTAwMDAwNzMwKSAzOCAwIFIgKG5vZGUwMDAwMDczMSkgMzkgMCBSIChub2Rl MDAwMDA3MzIpIDQxIDAgUiAobm9kZTAwMDAwNzMzKSA0MiAwIFIgKG5vZGUwMDAwMDczNCkgNDQg MCBSIChub2RlMDAwMDA3MzUpIDQ3IDAgUiAobm9kZTAwMDAwNzM2KSA1MCAwIFIgKG5vZGUwMDAw MDczNykgNTIgMCBSIChub2RlMDAwMDA3MzgpIDU0IDAgUiAobm9kZTAwMDAwNzM5KSA1NyAwIFIg KG5vZGUwMDAwMDc0MCkgNTkgMCBSIChub2RlMDAwMDA3NDEpIDYxIDAgUiAobm9kZTAwMDAwNzQy KSA2NCAwIFIgKG5vZGUwMDAwMDc0MykgNjYgMCBSIChub2RlMDAwMDA3NDQpIDY4IDAgUiAobm9k ZTAwMDAwNzQ1KSA3MSAwIFIgKG5vZGUwMDAwMDc0NykgNzIgMCBSIChub2RlMDAwMDA3NDgpIDcz IDAgUiAobm9kZTAwMDAwNzQ5KSA3NSAwIFIgKG5vZGUwMDAwMDc1MCkgNzcgMCBSIChub2RlMDAw MDA3NTIpIDc4IDAgUiAobm9kZTAwMDAwNzUzKSA3OSAwIFIgKG5vZGUwMDAwMDc1NCkgODIgMCBS IChub2RlMDAwMDA3NTUpIDg0IDAgUiAobm9kZTAwMDAwNzU2KSA4NiAwIFIgKG5vZGUwMDAwMDc1 NykgODkgMCBSIChub2RlMDAwMDA3NTkpIDkwIDAgUiAobm9kZTAwMDAwNzYwKSA5MSAwIFIgKG5v ZGUwMDAwMDc2MSkgOTMgMCBSIChub2RlMDAwMDA3NjIpIDk1IDAgUiAobm9kZTAwMDAwNzY0KSA5 NiAwIFIgKG5vZGUwMDAwMDc2NSkgOTcgMCBSIChub2RlMDAwMDA3NjYpIDEwMCAwIFIgKG5vZGUw MDAwMDc2NykgMTAzIDAgUiAobm9kZTAwMDAwNzY4KSAxMDUgMCBSIChub2RlMDAwMDA3NjkpIDEw NyAwIFIgKG5vZGUwMDAwMDc3MCkgMTEwIDAgUiAobm9kZTAwMDAwNzcxKSAxMTIgMCBSIChub2Rl MDAwMDA3NzIpIDExNCAwIFIgKG5vZGUwMDAwMDc3MykgMTE3IDAgUiAobm9kZTAwMDAwNzc0KSAx MjAgMCBSIChub2RlMDAwMDA3NzUpIDEyMiAwIFIgKG5vZGUwMDAwMDc3NikgMTI0IDAgUiAobm9k ZTAwMDAwNzc3KSAxMjcgMCBSIChub2RlMDAwMDA3NzgpIDEzMCAwIFIgKG5vZGUwMDAwMDc3OSkg MTMyIDAgUiAobm9kZTAwMDAwNzgwKSAxMzQgMCBSIChub2RlMDAwMDA3ODEpIDEzNyAwIFIgKG5v ZGUwMDAwMDc4MikgMTM5IDAgUiAobm9kZTAwMDAwNzgzKSAxNDEgMCBSIChub2RlMDAwMDA3ODQp IDE0NCAwIFIgKG5vZGUwMDAwMDc4NSkgMTQ2IDAgUiAobm9kZTAwMDAwNzg2KSAxNDggMCBSIChu b2RlMDAwMDA3ODcpIDE1MSAwIFIgKG5vZGUwMDAwMDc4OCkgMTUzIDAgUiAobm9kZTAwMDAwNzg5 KSAxNTUgMCBSIChub2RlMDAwMDA3OTApIDE1OCAwIFIgKG5vZGUwMDAwMDc5MSkgMTYyIDAgUiAo bm9kZTAwMDAwNzkyKSAxNjEgMCBSIChub2RlMDAwMDA3OTMpIDE2MyAwIFIgKG5vZGUwMDAwMDc5 NCkgMTY2IDAgUiAobm9kZTAwMDAwNzk1KSAxNjUgMCBSIChub2RlMDAwMDA3OTYpIDE2NyAwIFIg KG5vZGUwMDAwMDc5NykgMTcwIDAgUiAobm9kZTAwMDAwNzk4KSAxNzIgMCBSIChub2RlMDAwMDA3 OTkpIDE3NCAwIFIgKG5vZGUwMDAwMDgwMCkgMTc3IDAgUiAobm9kZTAwMDAwODAxKSAxNzkgMCBS IChub2RlMDAwMDA4MDIpIDE4MSAwIFIgKG5vZGUwMDAwMDgwMykgMTg0IDAgUiAobm9kZTAwMDAw ODA0KSAxODYgMCBSIChub2RlMDAwMDA4MDUpIDE4OCAwIFIgKG5vZGUwMDAwMDgwNikgMTkxIDAg UiAobm9kZTAwMDAwODA3KSAxOTMgMCBSIChub2RlMDAwMDA4MDgpIDE5NSAwIFIgKG5vZGUwMDAw MDgwOSkgMTk4IDAgUiAobm9kZTAwMDAwODEwKSAyMDEgMCBSIChub2RlMDAwMDA4MTEpIDIwMyAw IFIgKG5vZGUwMDAwMDgxMikgMjA1IDAgUiAobm9kZTAwMDAwODEzKSAyMDggMCBSIChub2RlMDAw MDA4MTQpIDIxMCAwIFIgKG5vZGUwMDAwMDgxNSkgMjEyIDAgUiAobm9kZTAwMDAwODE2KSAyMTUg MCBSIChub2RlMDAwMDA4MTcpIDIxNyAwIFIgKG5vZGUwMDAwMDgxOCkgMjE5IDAgUiAobm9kZTAw MDAwODE5KSAyMjIgMCBSIChub2RlMDAwMDA4MjApIDIyNCAwIFIgKG5vZGUwMDAwMDgyMSkgMjI2 IDAgUiAobm9kZTAwMDAwODIyKSAyMjkgMCBSIChub2RlMDAwMDA4MjMpIDIzMiAwIFIgKG5vZGUw MDAwMDgyNSkgMjMzIDAgUiAobm9kZTAwMDAwODI2KSAyMzQgMCBSIChub2RlMDAwMDA4MjcpIDIz NiAwIFIgKG5vZGUwMDAwMDgyOCkgMjM4IDAgUiAobm9kZTAwMDAwODMwKSAyMzkgMCBSIChub2Rl MDAwMDA4MzEpIDI0MCAwIFIgKG5vZGUwMDAwMDgzMikgMjQzIDAgUiAobm9kZTAwMDAwODMzKSAy NDYgMCBSIChub2RlMDAwMDA4MzQpIDI0OCAwIFIgKG5vZGUwMDAwMDgzNSkgMjUwIDAgUiAobm9k ZTAwMDAwODM2KSAyNTMgMCBSIChub2RlMDAwMDA4MzcpIDI1NiAwIFIgKG5vZGUwMDAwMDgzOCkg MjU4IDAgUiAobm9kZTAwMDAwODM5KSAyNjAgMCBSIChub2RlMDAwMDA4NDApIDI2MyAwIFIgKG5v ZGUwMDAwMDg0MSkgMjY1IDAgUiAobm9kZTAwMDAwODQyKSAyNjcgMCBSIChub2RlMDAwMDA4NDMp IDI3MCAwIFIgKG5vZGUwMDAwMDg0NCkgMjczIDAgUiAobm9kZTAwMDAwODQ1KSAyNzUgMCBSIChu b2RlMDAwMDA4NDYpIDI3NyAwIFIgKG5vZGUwMDAwMDg0NykgMjgwIDAgUiAobm9kZTAwMDAwODQ4 KSAyODIgMCBSIChub2RlMDAwMDA4NDkpIDI4NCAwIFIgKG5vZGUwMDAwMDg1MCkgMjg3IDAgUiAo bm9kZTAwMDAwODUxKSAyODkgMCBSIChub2RlMDAwMDA4NTIpIDI5MSAwIFIgKG5vZGUwMDAwMDg1 MykgMjk0IDAgUiAobm9kZTAwMDAwODU0KSAyOTYgMCBSIChub2RlMDAwMDA4NTUpIDI5OCAwIFIg KG5vZGUwMDAwMDg1NikgMzAxIDAgUiAobm9kZTAwMDAwODU3KSAzMDUgMCBSIChub2RlMDAwMDA4 NTgpIDMwNCAwIFIgKG5vZGUwMDAwMDg1OSkgMzA2IDAgUiAobm9kZTAwMDAwODYwKSAzMDkgMCBS IChub2RlMDAwMDA4NjEpIDMwOCAwIFIgKG5vZGUwMDAwMDg2MikgMzEwIDAgUiAobm9kZTAwMDAw ODYzKSAzMTMgMCBSIChub2RlMDAwMDA4NjQpIDMxNSAwIFIgKG5vZGUwMDAwMDg2NSkgMzE3IDAg UiAobm9kZTAwMDAwODY2KSAzMjAgMCBSIChub2RlMDAwMDA4NjcpIDMyMiAwIFIgKG5vZGUwMDAw MDg2OCkgMzI0IDAgUiAobm9kZTAwMDAwODY5KSAzMjcgMCBSIChub2RlMDAwMDA4NzApIDMyOSAw IFIgKG5vZGUwMDAwMDg3MSkgMzMxIDAgUiAobm9kZTAwMDAwODcyKSAzMzQgMCBSIChub2RlMDAw MDA4NzMpIDMzNiAwIFIgKG5vZGUwMDAwMDg3NCkgMzM4IDAgUiAobm9kZTAwMDAwODc1KSAzNDEg MCBSIChub2RlMDAwMDA4NzYpIDM0MyAwIFIgKG5vZGUwMDAwMDg3NykgMzQ1IDAgUiAobm9kZTAw MDAwODc4KSAzNDggMCBSIChub2RlMDAwMDA4NzkpIDM1MCAwIFIgKG5vZGUwMDAwMDg4MCkgMzUy IDAgUiAobm9kZTAwMDAwODgxKSAzNTUgMCBSIChub2RlMDAwMDA4ODIpIDM1NyAwIFIgKG5vZGUw MDAwMDg4MykgMzU5IDAgUiAobm9kZTAwMDAwODg0KSAzNjIgMCBSIChub2RlMDAwMDA4ODUpIDM2 NCAwIFIgKG5vZGUwMDAwMDg4NikgMzY2IDAgUiAobm9kZTAwMDAwODg3KSAzNjkgMCBSIChub2Rl MDAwMDA4ODgpIDM3MSAwIFIgKG5vZGUwMDAwMDg4OSkgMzczIDAgUiAobm9kZTAwMDAwODkwKSAz NzYgMCBSIChub2RlMDAwMDA4OTEpIDM3OCAwIFIgKG5vZGUwMDAwMDg5MikgMzgwIDAgUiAobm9k ZTAwMDAwODkzKSAzODMgMCBSIChub2RlMDAwMDA4OTUpIDM4NCAwIFIgKG5vZGUwMDAwMDg5Nikg Mzg2IDAgUiAobm9kZTAwMDAwODk3KSAzODggMCBSIChub2RlMDAwMDA4OTkpIDM4OSAwIFIgKG5v ZGUwMDAwMDkwMCkgMzkyIDAgUiAobm9kZTAwMDAwOTAxKSAzOTQgMCBSIChub2RlMDAwMDA5MDIp IDM5NiAwIFIgKG5vZGUwMDAwMDkwMykgMzk5IDAgUiAobm9kZTAwMDAwOTA0KSA0MDEgMCBSIChu b2RlMDAwMDA5MDUpIDQwMyAwIFIgKG5vZGUwMDAwMDkwNikgNDA2IDAgUiAobm9kZTAwMDAwOTA4 KSA0MDcgMCBSIChub2RlMDAwMDA5MDkpIDQwOSAwIFIgKG5vZGUwMDAwMDkxMCkgNDExIDAgUiAo bm9kZTAwMDAwOTEyKSA0MTIgMCBSIChub2RlMDAwMDA5MTMpIDQxNSAwIFIgKG5vZGUwMDAwMDkx NCkgNDE3IDAgUiAobm9kZTAwMDAwOTE1KSA0MTkgMCBSIChub2RlMDAwMDA5MTYpIDQyMiAwIFIg KG5vZGUwMDAwMDkxNykgNDI0IDAgUiAobm9kZTAwMDAwOTE4KSA0MjYgMCBSIChub2RlMDAwMDA5 MTkpIDQyOSAwIFIgKG5vZGUwMDAwMDkyMCkgNDMxIDAgUiAobm9kZTAwMDAwOTIxKSA0MzMgMCBS IChub2RlMDAwMDA5MjIpIDQzNiAwIFIgKG5vZGUwMDAwMDkyMykgNDM4IDAgUiAobm9kZTAwMDAw OTI0KSA0NDAgMCBSIChub2RlMDAwMDA5MjUpIDQ0MyAwIFIgKG5vZGUwMDAwMDkyNykgNDQ0IDAg UiAobm9kZTAwMDAwOTI4KSA0NDYgMCBSIChub2RlMDAwMDA5MjkpIDQ0OCAwIFIgKG5vZGUwMDAw MDkzMSkgNDQ5IDAgUiAobm9kZTAwMDAwOTMyKSA0NTIgMCBSIChub2RlMDAwMDA5MzQpIDQ1MyAw IFIgKG5vZGUwMDAwMDkzNSkgNDU1IDAgUiAobm9kZTAwMDAwOTM2KSA0NTcgMCBSIChub2RlMDAw MDA5MzgpIDQ1OCAwIFIgKG5vZGUwMDAwMDkzOSkgNDYxIDAgUiAobm9kZTAwMDAwOTQxKSA0NjIg MCBSIChub2RlMDAwMDA5NDIpIDQ2NCAwIFIgKG5vZGUwMDAwMDk0MykgNDY2IDAgUiAobm9kZTAw MDAwOTQ1KSA0NjcgMCBSIChub2RlMDAwMDA5NDYpIDQ3MCAwIFIgKG5vZGUwMDAwMDk0OCkgNDcx IDAgUiAobm9kZTAwMDAwOTQ5KSA0NzMgMCBSIChub2RlMDAwMDA5NTApIDQ3NSAwIFIgKG5vZGUw MDAwMDk1MikgNDc2IDAgUiAobm9kZTAwMDAwOTUzKSA0NzkgMCBSIChub2RlMDAwMDA5NTUpIDQ4 MCAwIFIgKG5vZGUwMDAwMDk1NikgNDgyIDAgUiAobm9kZTAwMDAwOTU3KSA0ODQgMCBSIChub2Rl MDAwMDA5NTkpIDQ4NSAwIFIgKG5vZGUwMDAwMDk2MCkgNDg4IDAgUiAobm9kZTAwMDAwOTYyKSA0 ODkgMCBSIChub2RlMDAwMDA5NjMpIDQ5MSAwIFIgKG5vZGUwMDAwMDk2NCkgNDkzIDAgUiAobm9k ZTAwMDAwOTY2KSA0OTQgMCBSIChub2RlMDAwMDA5NjcpIDQ5NyAwIFIgKG5vZGUwMDAwMDk2OSkg NDk4IDAgUiAobm9kZTAwMDAwOTcwKSA1MDAgMCBSIChub2RlMDAwMDA5NzEpIDUwMiAwIFIgKG5v ZGUwMDAwMDk3MykgNTAzIDAgUiAobm9kZTAwMDAwOTc0KSA1MDYgMCBSIChub2RlMDAwMDA5NzYp IDUwNyAwIFIgKG5vZGUwMDAwMDk3NykgNTA5IDAgUiAobm9kZTAwMDAwOTc4KSA1MTEgMCBSIChu b2RlMDAwMDA5ODApIDUxMiAwIFIgKG5vZGUwMDAwMDk4MSkgNTE1IDAgUiAobm9kZTAwMDAwOTgy KSA1MTcgMCBSIChub2RlMDAwMDA5ODMpIDUxOSAwIFIgKG5vZGUwMDAwMDk4NCkgNTIyIDAgUiAo bm9kZTAwMDAwOTg2KSA1MjMgMCBSIChub2RlMDAwMDA5ODcpIDUyNSAwIFIgKG5vZGUwMDAwMDk4 OCkgNTI3IDAgUiAobm9kZTAwMDAwOTkwKSA1MjggMCBSIChub2RlMDAwMDA5OTEpIDUzMSAwIFIg KG5vZGUwMDAwMDk5MykgNTMyIDAgUiAobm9kZTAwMDAwOTk0KSA1MzQgMCBSIChub2RlMDAwMDA5 OTUpIDUzNiAwIFIgKG5vZGUwMDAwMDk5NykgNTM3IDAgUiAobm9kZTAwMDAwOTk4KSA1NDAgMCBS IChub2RlMDAwMDEwMDApIDU0MSAwIFIgKG5vZGUwMDAwMTAwMSkgNTQzIDAgUiAobm9kZTAwMDAx MDAyKSA1NDUgMCBSIChub2RlMDAwMDEwMDQpIDU0NiAwIFIgKG5vZGUwMDAwMTAwNSkgNTQ5IDAg UiAobm9kZTAwMDAxMDA3KSA1NTAgMCBSIChub2RlMDAwMDEwMDgpIDU1MiAwIFIgKG5vZGUwMDAw MTAwOSkgNTU0IDAgUiAobm9kZTAwMDAxMDExKSA1NTUgMCBSIChub2RlMDAwMDEwMTIpIDU1OCAw IFIgKG5vZGUwMDAwMTAxNCkgNTU5IDAgUiAobm9kZTAwMDAxMDE1KSA1NjEgMCBSIChub2RlMDAw MDEwMTYpIDU2MyAwIFIgKG5vZGUwMDAwMTAxOCkgNTY0IDAgUiAobm9kZTAwMDAxMDE5KSA1Njcg MCBSIChub2RlMDAwMDEwMjEpIDU2OCAwIFIgKG5vZGUwMDAwMTAyMikgNTcwIDAgUiAobm9kZTAw MDAxMDIzKSA1NzIgMCBSIChub2RlMDAwMDEwMjUpIDU3MyAwIFIgKG5vZGUwMDAwMTAyNikgNTc2 IDAgUiAobm9kZTAwMDAxMDI4KSA1NzcgMCBSIChub2RlMDAwMDEwMjkpIDU3OSAwIFIgKG5vZGUw MDAwMTAzMCkgNTgxIDAgUiAobm9kZTAwMDAxMDMyKSA1ODIgMCBSIChub2RlMDAwMDEwMzMpIDU4 NSAwIFIgKG5vZGUwMDAwMTAzNSkgNTg2IDAgUiAobm9kZTAwMDAxMDM2KSA1ODggMCBSIChub2Rl MDAwMDEwMzcpIDU5MCAwIFIgKG5vZGUwMDAwMTAzOSkgNTkxIDAgUiAobm9kZTAwMDAxMDQwKSA1 OTQgMCBSIChub2RlMDAwMDEwNDIpIDU5NSAwIFIgKG5vZGUwMDAwMTA0MykgNTk3IDAgUiAobm9k ZTAwMDAxMDQ0KSA1OTkgMCBSIChub2RlMDAwMDEwNDYpIDYwMCAwIFIgKG5vZGUwMDAwMTA0Nykg NjAzIDAgUiAobm9kZTAwMDAxMDQ5KSA2MDQgMCBSIChub2RlMDAwMDEwNTApIDYwNiAwIFIgKG5v ZGUwMDAwMTA1MSkgNjA4IDAgUiAobm9kZTAwMDAxMDUzKSA2MDkgMCBSIChub2RlMDAwMDEwNTQp IDYxMiAwIFIgKG5vZGUwMDAwMTA1NikgNjEzIDAgUiAobm9kZTAwMDAxMDU3KSA2MTUgMCBSIChu b2RlMDAwMDEwNTgpIDYxNyAwIFIgKG5vZGUwMDAwMTA2MCkgNjE4IDAgUiAobm9kZTAwMDAxMDYx KSA2MjEgMCBSIChub2RlMDAwMDEwNjMpIDYyMiAwIFIgKG5vZGUwMDAwMTA2NCkgNjI0IDAgUiAo bm9kZTAwMDAxMDY1KSA2MjYgMCBSIChub2RlMDAwMDEwNjcpIDYyNyAwIFIgKG5vZGUwMDAwMTA2 OCkgNjMwIDAgUiAobm9kZTAwMDAxMDcwKSA2MzEgMCBSIChub2RlMDAwMDEwNzEpIDYzMyAwIFIg KG5vZGUwMDAwMTA3MikgNjM1IDAgUiAobm9kZTAwMDAxMDc0KSA2MzYgMCBSIChub2RlMDAwMDEw NzUpIDYzOSAwIFIgKG5vZGUwMDAwMTA3NykgNjQwIDAgUiAobm9kZTAwMDAxMDc4KSA2NDIgMCBS IChub2RlMDAwMDEwNzkpIDY0NCAwIFIgKG5vZGUwMDAwMTA4MSkgNjQ1IDAgUiAobm9kZTAwMDAx MDgyKSA2NDggMCBSIChub2RlMDAwMDEwODQpIDY0OSAwIFIgKG5vZGUwMDAwMTA4NSkgNjUxIDAg UiAobm9kZTAwMDAxMDg2KSA2NTMgMCBSIChub2RlMDAwMDEwODgpIDY1NCAwIFIgKG5vZGUwMDAw MTA4OSkgNjU3IDAgUiAobm9kZTAwMDAxMDkwKSA2NjAgMCBSIChub2RlMDAwMDEwOTEpIDY2MiAw IFIgKG5vZGUwMDAwMTA5MikgNjY0IDAgUiAobm9kZTAwMDAxMDkzKSA2NjcgMCBSIChub2RlMDAw MDEwOTQpIDY3MCAwIFIgKG5vZGUwMDAwMTA5NSkgNjcyIDAgUiAobm9kZTAwMDAxMDk2KSA2NzQg MCBSIChub2RlMDAwMDEwOTcpIDY3NyAwIFIgKG5vZGUwMDAwMTA5OCkgNjc5IDAgUiAobm9kZTAw MDAxMDk5KSA2ODEgMCBSIChub2RlMDAwMDExMDApIDY4NCAwIFIgKG5vZGUwMDAwMTEwMSkgNjg2 IDAgUiAobm9kZTAwMDAxMTAyKSA2ODggMCBSIChub2RlMDAwMDExMDMpIDY5MSAwIFIgKG5vZGUw MDAwMTEwNCkgNjkzIDAgUiAobm9kZTAwMDAxMTA1KSA2OTUgMCBSIChub2RlMDAwMDExMDYpIDY5 OCAwIFIgKG5vZGUwMDAwMTEwNykgNzAwIDAgUiAobm9kZTAwMDAxMTA4KSA3MDIgMCBSIChub2Rl MDAwMDExMDkpIDcwNSAwIFIgKG5vZGUwMDAwMTExMCkgNzA4IDAgUiAobm9kZTAwMDAxMTExKSA3 MTAgMCBSIChub2RlMDAwMDExMTIpIDcxMiAwIFIgKG5vZGUwMDAwMTExMykgNzE1IDAgUiAobm9k ZTAwMDAxMTE0KSA3MTkgMCBSIChub2RlMDAwMDExMTUpIDcxOCAwIFIgKG5vZGUwMDAwMTExNikg NzIwIDAgUiAobm9kZTAwMDAxMTE3KSA3MjMgMCBSIChub2RlMDAwMDExMTgpIDcyMiAwIFIgKG5v ZGUwMDAwMTExOSkgNzI0IDAgUiAobm9kZTAwMDAxMTIwKSA3MjcgMCBSIChub2RlMDAwMDExMjEp IDcyOSAwIFIgKG5vZGUwMDAwMTEyMikgNzMxIDAgUiAobm9kZTAwMDAxMTIzKSA3MzQgMCBSIChu b2RlMDAwMDExMjQpIDczNiAwIFIgKG5vZGUwMDAwMTEyNSkgNzM4IDAgUiAobm9kZTAwMDAxMTI2 KSA3NDEgMCBSIChub2RlMDAwMDExMjcpIDc0MyAwIFIgKG5vZGUwMDAwMTEyOCkgNzQ1IDAgUiAo bm9kZTAwMDAxMTI5KSA3NDggMCBSIChub2RlMDAwMDExMzApIDc1MCAwIFIgKG5vZGUwMDAwMTEz MSkgNzUyIDAgUiAobm9kZTAwMDAxMTMyKSA3NTUgMCBSIChub2RlMDAwMDExMzMpIDc1NyAwIFIg KG5vZGUwMDAwMTEzNCkgNzU5IDAgUiAobm9kZTAwMDAxMTM1KSA3NjIgMCBSIChub2RlMDAwMDEx MzYpIDc2NSAwIFIgKG5vZGUwMDAwMTEzNykgNzY3IDAgUiAobm9kZTAwMDAxMTM4KSA3NjkgMCBS IChub2RlMDAwMDExMzkpIDc3MiAwIFIgKG5vZGUwMDAwMTE0MCkgNzc1IDAgUiAobm9kZTAwMDAx MTQxKSA3NzcgMCBSIChub2RlMDAwMDExNDIpIDc3OSAwIFIgKG5vZGUwMDAwMTE0MykgNzgyIDAg UiAobm9kZTAwMDAxMTQ1KSAzNCAwIFIgKG5vZGUwMDAwMTE0OSkgNDUgMCBSIChub2RlMDAwMDEx NTApIDQ4IDAgUiAobm9kZTAwMDAxMTUxKSA1NSAwIFIgKG5vZGUwMDAwMTE1MikgNjIgMCBSIChu b2RlMDAwMDExNTUpIDY5IDAgUiAobm9kZTAwMDAxMTU2KSA4MCAwIFIgKG5vZGUwMDAwMTE1OSkg ODcgMCBSIChub2RlMDAwMDExNjApIDk4IDAgUiAobm9kZTAwMDAxMTYxKSAxMDEgMCBSIChub2Rl MDAwMDExNjIpIDEwOCAwIFIgKG5vZGUwMDAwMTE2MykgMTE1IDAgUiAobm9kZTAwMDAxMTY0KSAx MTggMCBSIChub2RlMDAwMDExNjUpIDEyNSAwIFIgKG5vZGUwMDAwMTE2NikgMTI4IDAgUiAobm9k ZTAwMDAxMTY3KSAxMzUgMCBSIChub2RlMDAwMDExNjgpIDE0MiAwIFIgKG5vZGUwMDAwMTE2OSkg MTQ5IDAgUiAobm9kZTAwMDAxMTcwKSAxNTYgMCBSIChub2RlMDAwMDExNzQpIDE2OCAwIFIgKG5v ZGUwMDAwMTE3NSkgMTc1IDAgUiAobm9kZTAwMDAxMTc2KSAxODIgMCBSIChub2RlMDAwMDExNzcp IDE4OSAwIFIgKG5vZGUwMDAwMTE3OCkgMTk2IDAgUiAobm9kZTAwMDAxMTc5KSAxOTkgMCBSIChu b2RlMDAwMDExODApIDIwNiAwIFIgKG5vZGUwMDAwMTE4MSkgMjEzIDAgUiAobm9kZTAwMDAxMTgy KSAyMjAgMCBSIChub2RlMDAwMDExODMpIDIyNyAwIFIgKG5vZGUwMDAwMTE4NikgMjMwIDAgUiAo bm9kZTAwMDAxMTg3KSAyNDEgMCBSIChub2RlMDAwMDExODgpIDI0NCAwIFIgKG5vZGUwMDAwMTE4 OSkgMjUxIDAgUiAobm9kZTAwMDAxMTkwKSAyNTQgMCBSIChub2RlMDAwMDExOTEpIDI2MSAwIFIg KG5vZGUwMDAwMTE5MikgMjY4IDAgUiAobm9kZTAwMDAxMTkzKSAyNzEgMCBSIChub2RlMDAwMDEx OTQpIDI3OCAwIFIgKG5vZGUwMDAwMTE5NSkgMjg1IDAgUiAobm9kZTAwMDAxMTk2KSAyOTIgMCBS IChub2RlMDAwMDExOTcpIDI5OSAwIFIgKG5vZGUwMDAwMTIwMSkgMzExIDAgUiAobm9kZTAwMDAx MjAyKSAzMTggMCBSIChub2RlMDAwMDEyMDMpIDMyNSAwIFIgKG5vZGUwMDAwMTIwNCkgMzMyIDAg UiAobm9kZTAwMDAxMjA1KSAzMzkgMCBSIChub2RlMDAwMDEyMDYpIDM0NiAwIFIgKG5vZGUwMDAw MTIwNykgMzUzIDAgUiAobm9kZTAwMDAxMjA4KSAzNjAgMCBSIChub2RlMDAwMDEyMDkpIDM2NyAw IFIgKG5vZGUwMDAwMTIxMCkgMzc0IDAgUiAobm9kZTAwMDAxMjEzKSAzODEgMCBSIChub2RlMDAw MDEyMTQpIDM5MCAwIFIgKG5vZGUwMDAwMTIxNSkgMzk3IDAgUiAobm9kZTAwMDAxMjE4KSA0MDQg MCBSIChub2RlMDAwMDEyMTkpIDQxMyAwIFIgKG5vZGUwMDAwMTIyMCkgNDIwIDAgUiAobm9kZTAw MDAxMjIxKSA0MjcgMCBSIChub2RlMDAwMDEyMjIpIDQzNCAwIFIgKG5vZGUwMDAwMTIyNSkgNDQx IDAgUiAobm9kZTAwMDAxMjI2KSA0NTAgMCBSIChub2RlMDAwMDEyMjcpIDQ1OSAwIFIgKG5vZGUw MDAwMTIyOCkgNDY4IDAgUiAobm9kZTAwMDAxMjI5KSA0NzcgMCBSIChub2RlMDAwMDEyMzApIDQ4 NiAwIFIgKG5vZGUwMDAwMTIzMSkgNDkwIDAgUiAobm9kZTAwMDAxMjMyKSA0OTUgMCBSIChub2Rl MDAwMDEyMzMpIDQ5OSAwIFIgKG5vZGUwMDAwMTIzNCkgNTA0IDAgUiAobm9kZTAwMDAxMjM1KSA1 MDggMCBSIChub2RlMDAwMDEyMzYpIDUxMyAwIFIgKG5vZGUwMDAwMTIzNykgNTE2IDAgUiAobm9k ZTAwMDAxMjQwKSA1MjAgMCBSIChub2RlMDAwMDEyNDEpIDUyNCAwIFIgKG5vZGUwMDAwMTI0Mikg NTI5IDAgUiAobm9kZTAwMDAxMjQzKSA1MzMgMCBSIChub2RlMDAwMDEyNDQpIDUzOCAwIFIgKG5v ZGUwMDAwMTI0NSkgNTQyIDAgUiAobm9kZTAwMDAxMjQ2KSA1NDcgMCBSIChub2RlMDAwMDEyNDcp IDU1MSAwIFIgKG5vZGUwMDAwMTI0OCkgNTU2IDAgUiAobm9kZTAwMDAxMjQ5KSA1NjAgMCBSIChu b2RlMDAwMDEyNTApIDU2NSAwIFIgKG5vZGUwMDAwMTI1MSkgNTY5IDAgUiAobm9kZTAwMDAxMjUy KSA1NzQgMCBSIChub2RlMDAwMDEyNTMpIDU3OCAwIFIgKG5vZGUwMDAwMTI1NCkgNTgzIDAgUiAo bm9kZTAwMDAxMjU1KSA1ODcgMCBSIChub2RlMDAwMDEyNTYpIDU5MiAwIFIgKG5vZGUwMDAwMTI1 NykgNTk2IDAgUiAobm9kZTAwMDAxMjU4KSA2MDEgMCBSIChub2RlMDAwMDEyNTkpIDYwNSAwIFIg KG5vZGUwMDAwMTI2MCkgNjEwIDAgUiAobm9kZTAwMDAxMjYxKSA2MTQgMCBSIChub2RlMDAwMDEy NjIpIDYxOSAwIFIgKG5vZGUwMDAwMTI2MykgNjIzIDAgUiAobm9kZTAwMDAxMjY0KSA2MjggMCBS IChub2RlMDAwMDEyNjUpIDYzMiAwIFIgKG5vZGUwMDAwMTI2NikgNjM3IDAgUiAobm9kZTAwMDAx MjY3KSA2NDEgMCBSIChub2RlMDAwMDEyNjgpIDY0NiAwIFIgKG5vZGUwMDAwMTI2OSkgNjUwIDAg UiAobm9kZTAwMDAxMjcwKSA2NTUgMCBSIChub2RlMDAwMDEyNzEpIDY1NiAwIFIgKG5vZGUwMDAw MTI3MikgNjU4IDAgUiAobm9kZTAwMDAxMjczKSA2NjEgMCBSIChub2RlMDAwMDEyNzQpIDY2NSAw IFIgKG5vZGUwMDAwMTI3NSkgNjY2IDAgUiAobm9kZTAwMDAxMjc2KSA2NjggMCBSIChub2RlMDAw MDEyNzcpIDY3MSAwIFIgKG5vZGUwMDAwMTI3OCkgNjc1IDAgUiAobm9kZTAwMDAxMjc5KSA2Nzgg MCBSIChub2RlMDAwMDEyODApIDY4MiAwIFIgKG5vZGUwMDAwMTI4MSkgNjg1IDAgUiAobm9kZTAw MDAxMjgyKSA2ODkgMCBSIChub2RlMDAwMDEyODMpIDY5MiAwIFIgKG5vZGUwMDAwMTI4NCkgNjk2 IDAgUiAobm9kZTAwMDAxMjg1KSA2OTkgMCBSIChub2RlMDAwMDEyODYpIDcwMyAwIFIgKG5vZGUw MDAwMTI4NykgNzA0IDAgUiAobm9kZTAwMDAxMjg4KSA3MDYgMCBSIChub2RlMDAwMDEyODkpIDcw OSAwIFIgKG5vZGUwMDAwMTI5MCkgNzEzIDAgUiAobm9kZTAwMDAxMjkxKSA3MTQgMCBSIChub2Rl MDAwMDEyOTMpIDcxNyAwIFIgKG5vZGUwMDAwMTI5NSkgNzIxIDAgUiAobm9kZTAwMDAxMjk3KSA3 MjUgMCBSIChub2RlMDAwMDEyOTgpIDcyOCAwIFIgKG5vZGUwMDAwMTI5OSkgNzMyIDAgUiAobm9k ZTAwMDAxMzAwKSA3MzUgMCBSIChub2RlMDAwMDEzMDEpIDczOSAwIFIgKG5vZGUwMDAwMTMwMikg NzQyIDAgUiAobm9kZTAwMDAxMzAzKSA3NDYgMCBSIChub2RlMDAwMDEzMDQpIDc0OSAwIFIgKG5v ZGUwMDAwMTMwNSkgNzUzIDAgUiAobm9kZTAwMDAxMzA2KSA3NTYgMCBSIChub2RlMDAwMDEzMDcp IDc2MCAwIFIgKG5vZGUwMDAwMTMwOCkgNzYxIDAgUiAobm9kZTAwMDAxMzA5KSA3NjMgMCBSIChu b2RlMDAwMDEzMTApIDc2NiAwIFIgKG5vZGUwMDAwMTMxMSkgNzcwIDAgUiAobm9kZTAwMDAxMzEy KSA3NzEgMCBSIChub2RlMDAwMDEzMTMpIDc3MyAwIFIgKG5vZGUwMDAwMTMxNCkgNzc2IDAgUiAo bm9kZTAwMDAxMzE1KSA3ODAgMCBSIChub2RlMDAwMDEzMTYpIDc4MSAwIFIgKG5vZGUwMDAwMTMx OSkgNzgzIDAgUiAobm9kZTAwMDAxMzIwKSA3ODUgMCBSIChub2RlMDAwMDEzMjEpIDc4NiAwIFIg KG5vZGUwMDAwMTMyMikgNzg3IDAgUiAobm9kZTAwMDAxMzIzKSA3ODggMCBSIChub2RlMDAwMDEz MjQpIDc4OSAwIFIgKG5vZGUwMDAwMTMyNSkgNzkxIDAgUiAobm9kZTAwMDAxMzI2KSA3OTIgMCBS IChub2RlMDAwMDEzMjcpIDc5MyAwIFIgKG5vZGUwMDAwMTMyOCkgNzk0IDAgUiAobm9kZTAwMDAx MzMwKSA3OTUgMCBSIChub2RlMDAwMDEzMzEpIDc5NiAwIFIgKG5vZGUwMDAwMTMzMikgNzk3IDAg UiAobm9kZTAwMDAxMzMzKSA3OTggMCBSIChub2RlMDAwMDEzMzQpIDc5OSAwIFIgKG5vZGUwMDAw MTMzNSkgODAwIDAgUiAobm9kZTAwMDAxMzM2KSA4MDEgMCBSIChub2RlMDAwMDEzMzcpIDgwMiAw IFIgKG5vZGUwMDAwMTMzOSkgODAzIDAgUiAobm9kZTAwMDAxMzQxKSA4MDQgMCBSIChub2RlMDAw MDEzNDIpIDgwNSAwIFIgKG5vZGUwMDAwMTM0MykgODA2IDAgUiAobm9kZTAwMDAxMzQ0KSA4MDcg MCBSIChub2RlMDAwMDEzNDUpIDgwOCAwIFIgKG5vZGUwMDAwMTM0NikgODA5IDAgUiAobm9kZTAw MDAxMzQ4KSA4MTAgMCBSIChub2RlMDAwMDEzNTApIDgxMSAwIFIgKG5vZGUwMDAwMTM1MSkgODEy IDAgUiAobm9kZTAwMDAxMzUyKSA4MTMgMCBSIChub2RlMDAwMDEzNTMpIDgxNCAwIFIgKG5vZGUw MDAwMTM1NCkgODE1IDAgUiAobm9kZTAwMDAxMzU1KSA4MTYgMCBSIChub2RlMDAwMDEzNTcpIDgx NyAwIFIgKG5vZGUwMDAwMTM1OSkgODE4IDAgUiAobm9kZTAwMDAxMzYwKSA4MTkgMCBSIChub2Rl MDAwMDEzNjEpIDgyMCAwIFIgKG5vZGUwMDAwMTM2MikgODIxIDAgUiAobm9kZTAwMDAxMzYzKSA4 MjIgMCBSIChub2RlMDAwMDEzNjQpIDgyMyAwIFIgKG5vZGUwMDAwMTM2NikgODI0IDAgUiAobm9k ZTAwMDAxMzY4KSA4MjUgMCBSIChub2RlMDAwMDEzNjkpIDgyNiAwIFIgKG5vZGUwMDAwMTM3MCkg ODI3IDAgUiAobm9kZTAwMDAxMzcxKSA4MjggMCBSIChub2RlMDAwMDEzNzIpIDgyOSAwIFIgKG5v ZGUwMDAwMTM3MykgODMwIDAgUiAobm9kZTAwMDAxMzc1KSA4MzEgMCBSIChub2RlMDAwMDEzNzcp IDgzMiAwIFIgKG5vZGUwMDAwMTM3OCkgODMzIDAgUiAobm9kZTAwMDAxMzc5KSA4MzQgMCBSIChu b2RlMDAwMDEzODApIDgzNSAwIFIgKG5vZGUwMDAwMTM4MSkgODM2IDAgUiAobm9kZTAwMDAxMzgy KSA4MzcgMCBSIChub2RlMDAwMDEzODQpIDgzOCAwIFIgKG5vZGUwMDAwMTM4NykgODM5IDAgUiAo bm9kZTAwMDAxMzg4KSA4NDAgMCBSIChub2RlMDAwMDEzOTEpIDg0MSAwIFIgKG5vZGUwMDAwMTM5 MykgODQyIDAgUiAobm9kZTAwMDAxMzk0KSA4NDMgMCBSIChub2RlMDAwMDEzOTUpIDg0NCAwIFIg KG5vZGUwMDAwMTM5NikgODQ1IDAgUiAobm9kZTAwMDAxMzk3KSA4NDYgMCBSIChub2RlMDAwMDEz OTgpIDg0NyAwIFIgKG5vZGUwMDAwMTQwMikgODQ4IDAgUiAobm9kZTAwMDAxNDA0KSA4NDkgMCBS IChub2RlMDAwMDE0MDUpIDg1MCAwIFIgKG5vZGUwMDAwMTQwNikgODUxIDAgUiAobm9kZTAwMDAx NDA3KSA4NTIgMCBSIChub2RlMDAwMDE0MDgpIDg1MyAwIFIgKG5vZGUwMDAwMTQwOSkgODU0IDAg UiAobm9kZTAwMDAxNDEwKSA4NTUgMCBSIChub2RlMDAwMDE0MTEpIDg1NiAwIFIgKG5vZGUwMDAw MTQxMykgODU3IDAgUiAobm9kZTAwMDAxNDE1KSA4NTggMCBSIChub2RlMDAwMDE0MTYpIDg1OSAw IFIgKG5vZGUwMDAwMTQxNykgODYwIDAgUiAobm9kZTAwMDAxNDE4KSA4NjEgMCBSIChub2RlMDAw MDE0MTkpIDg2MiAwIFIgKG5vZGUwMDAwMTQyMCkgODYzIDAgUiAobm9kZTAwMDAxNDIxKSA4NjQg MCBSIChub2RlMDAwMDE0MjIpIDg2NSAwIFIgKG5vZGUwMDAwMTQyNCkgODY2IDAgUiAobm9kZTAw MDAxNDI2KSA4NjcgMCBSIChub2RlMDAwMDE0MjcpIDg2OCAwIFIgKG5vZGUwMDAwMTQyOCkgODY5 IDAgUiAobm9kZTAwMDAxNDI5KSA4NzAgMCBSIChub2RlMDAwMDE0MzApIDg3MSAwIFIgKG5vZGUw MDAwMTQzMSkgODcyIDAgUiAobm9kZTAwMDAxNDMzKSA4NzMgMCBSIChub2RlMDAwMDE0MzUpIDg3 NCAwIFIgKG5vZGUwMDAwMTQzNikgODc1IDAgUiAobm9kZTAwMDAxNDM3KSA4NzYgMCBSIChub2Rl MDAwMDE0MzgpIDg3NyAwIFIgKG5vZGUwMDAwMTQzOSkgODc4IDAgUiAobm9kZTAwMDAxNDQwKSA4 NzkgMCBSIChub2RlMDAwMDE0NDIpIDg4MCAwIFIgKG5vZGUwMDAwMTQ0NCkgODgxIDAgUiAobm9k ZTAwMDAxNDQ1KSA4ODIgMCBSIChub2RlMDAwMDE0NDYpIDg4MyAwIFIgKG5vZGUwMDAwMTQ0Nykg ODg0IDAgUiAobm9kZTAwMDAxNDQ4KSA4ODYgMCBSIChub2RlMDAwMDE0NTApIDg4NyAwIFIgKG5v ZGUwMDAwMTQ1MikgODg4IDAgUiAobm9kZTAwMDAxNDUzKSA4ODkgMCBSIChub2RlMDAwMDE0NTQp IDg5MCAwIFIgKG5vZGUwMDAwMTQ1NSkgODkxIDAgUiAobm9kZTAwMDAxNDU2KSA4OTIgMCBSIChu b2RlMDAwMDE0NTcpIDg5MyAwIFIgKG5vZGUwMDAwMTQ1OSkgODk0IDAgUiAobm9kZTAwMDAxNDYx KSA4OTUgMCBSIChub2RlMDAwMDE0NjIpIDg5NiAwIFIgKG5vZGUwMDAwMTQ2MykgODk3IDAgUiAo bm9kZTAwMDAxNDY0KSA4OTggMCBSIChub2RlMDAwMDE0NjUpIDg5OSAwIFIgKG5vZGUwMDAwMTQ2 NikgOTAwIDAgUiAobm9kZTAwMDAxNDY4KSA5MDEgMCBSIChub2RlMDAwMDE0NzApIDkwMiAwIFIg KG5vZGUwMDAwMTQ3MSkgOTAzIDAgUiAobm9kZTAwMDAxNDcyKSA5MDQgMCBSIChub2RlMDAwMDE0 NzMpIDkwNSAwIFIgKG5vZGUwMDAwMTQ3NCkgOTA3IDAgUiAobm9kZTAwMDAxNDc2KSA5MDggMCBS IChub2RlMDAwMDE0NzgpIDkwOSAwIFIgKG5vZGUwMDAwMTQ3OSkgOTEwIDAgUiAobm9kZTAwMDAx NDgwKSA5MTEgMCBSIChub2RlMDAwMDE0ODEpIDkxMiAwIFIgKG5vZGUwMDAwMTQ4MikgOTE0IDAg UiAobm9kZTAwMDAxNDg0KSA5MTUgMCBSIChub2RlMDAwMDE0ODcpIDkxNiAwIFIgKG5vZGUwMDAw MTQ4OCkgOTE3IDAgUiAobm9kZTAwMDAxNDkxKSA5MTggMCBSIChub2RlMDAwMDE0OTMpIDkxOSAw IFIgKG5vZGUwMDAwMTQ5NCkgOTIwIDAgUiAobm9kZTAwMDAxNDk1KSA5MjEgMCBSIChub2RlMDAw MDE0OTYpIDkyMiAwIFIgKG5vZGUwMDAwMTQ5NykgOTIzIDAgUiAobm9kZTAwMDAxNDk4KSA5MjQg MCBSIChub2RlMDAwMDE1MDApIDkyNSAwIFIgKG5vZGUwMDAwMTUwMikgOTI2IDAgUiAobm9kZTAw MDAxNTAzKSA5MjcgMCBSIChub2RlMDAwMDE1MDQpIDkyOCAwIFIgKG5vZGUwMDAwMTUwNSkgOTI5 IDAgUiAobm9kZTAwMDAxNTA2KSA5MzAgMCBSIChub2RlMDAwMDE1MDcpIDkzMSAwIFIgKG5vZGUw MDAwMTUwOSkgOTMyIDAgUiAobm9kZTAwMDAxNTExKSA5MzMgMCBSIChub2RlMDAwMDE1MTIpIDkz NCAwIFIgKG5vZGUwMDAwMTUxMykgOTM1IDAgUiAobm9kZTAwMDAxNTE0KSA5MzYgMCBSIChub2Rl MDAwMDE1MTUpIDkzNyAwIFIgKG5vZGUwMDAwMTUxNikgOTM4IDAgUiAobm9kZTAwMDAxNTE4KSA5 MzkgMCBSIChub2RlMDAwMDE1MjApIDk0MCAwIFIgKG5vZGUwMDAwMTUyMSkgOTQxIDAgUiAobm9k ZTAwMDAxNTIyKSA5NDIgMCBSIChub2RlMDAwMDE1MjMpIDk0MyAwIFIgKG5vZGUwMDAwMTUyNCkg OTQ0IDAgUiAobm9kZTAwMDAxNTI1KSA5NDUgMCBSIChub2RlMDAwMDE1MjcpIDk0NiAwIFIgKG5v ZGUwMDAwMTUyOSkgOTQ3IDAgUiAobm9kZTAwMDAxNTMwKSA5NDggMCBSIChub2RlMDAwMDE1MzEp IDk0OSAwIFIgKG5vZGUwMDAwMTUzMikgOTUwIDAgUiAobm9kZTAwMDAxNTMzKSA5NTEgMCBSIChu b2RlMDAwMDE1MzQpIDk1MiAwIFIgKG5vZGUwMDAwMTUzNikgOTUzIDAgUiAobm9kZTAwMDAxNTM4 KSA5NTQgMCBSIChub2RlMDAwMDE1MzkpIDk1NSAwIFIgKG5vZGUwMDAwMTU0MCkgOTU2IDAgUiAo bm9kZTAwMDAxNTQxKSA5NTcgMCBSIChub2RlMDAwMDE1NDIpIDk1OCAwIFIgKG5vZGUwMDAwMTU0 MykgOTU5IDAgUiAobm9kZTAwMDAxNTQ1KSA5NjAgMCBSIChub2RlMDAwMDE1NDgpIDk2MSAwIFIg KG5vZGUwMDAwMTU0OSkgOTYyIDAgUiAobm9kZTAwMDAxNTUyKSA5NjMgMCBSIChub2RlMDAwMDE1 NTQpIDk2NCAwIFIgKG5vZGUwMDAwMTU1NSkgOTY1IDAgUiAobm9kZTAwMDAxNTU2KSA5NjYgMCBS IChub2RlMDAwMDE1NTcpIDk2NyAwIFIgKG5vZGUwMDAwMTU1OCkgOTY4IDAgUiAobm9kZTAwMDAx NTU5KSA5NjkgMCBSIChub2RlMDAwMDE1NjEpIDk3MCAwIFIgKG5vZGUwMDAwMTU2MykgOTcxIDAg UiAobm9kZTAwMDAxNTY0KSA5NzIgMCBSIChub2RlMDAwMDE1NjUpIDk3MyAwIFIgKG5vZGUwMDAw MTU2NikgOTc0IDAgUiAobm9kZTAwMDAxNTY3KSA5NzUgMCBSIChub2RlMDAwMDE1NjgpIDk3NiAw IFIgKG5vZGUwMDAwMTU3MCkgOTc3IDAgUiAobm9kZTAwMDAxNTczKSA5NzggMCBSIChub2RlMDAw MDE1NzQpIDk3OSAwIFIgKG5vZGUwMDAwMTU3NykgOTgwIDAgUiAobm9kZTAwMDAxNTc5KSA5ODEg MCBSIChub2RlMDAwMDE1ODApIDk4MiAwIFIgKG5vZGUwMDAwMTU4MSkgOTgzIDAgUiAobm9kZTAw MDAxNTgyKSA5ODQgMCBSIChub2RlMDAwMDE1ODQpIDk4NSAwIFIgKG5vZGUwMDAwMTU4NSkgOTg2 IDAgUiAobm9kZTAwMDAxNTg2KSA5ODcgMCBSIChub2RlMDAwMDE1ODcpIDk4OCAwIFIgKG5vZGUw MDAwMTU4OSkgOTg5IDAgUiAobm9kZTAwMDAxNTkyKSA5OTAgMCBSIChub2RlMDAwMDE1OTMpIDk5 MSAwIFIgKG5vZGUwMDAwMTU5NikgOTkyIDAgUiAobm9kZTAwMDAxNTk4KSA5OTMgMCBSIChub2Rl MDAwMDE1OTkpIDk5NCAwIFIgKG5vZGUwMDAwMTYwMCkgOTk1IDAgUiAobm9kZTAwMDAxNjAxKSA5 OTYgMCBSIChub2RlMDAwMDE2MDIpIDk5NyAwIFIgKG5vZGUwMDAwMTYwMykgOTk4IDAgUiAobm9k ZTAwMDAxNjA1KSA5OTkgMCBSIChub2RlMDAwMDE2MDgpIDEwMDAgMCBSIChub2RlMDAwMDE2MDkp IDEwMDEgMCBSIChub2RlMDAwMDE2MTIpIDEwMDIgMCBSIChub2RlMDAwMDE2MTQpIDEwMDMgMCBS IChub2RlMDAwMDE2MTUpIDEwMDQgMCBSIChub2RlMDAwMDE2MTYpIDEwMDUgMCBSIChub2RlMDAw MDE2MTcpIDEwMDYgMCBSIChub2RlMDAwMDE2MTgpIDEwMDcgMCBSIChub2RlMDAwMDE2MTkpIDEw MDggMCBSIChub2RlMDAwMDE2MjEpIDEwMDkgMCBSIChub2RlMDAwMDE2MjMpIDEwMTAgMCBSIChu b2RlMDAwMDE2MjQpIDEwMTEgMCBSIChub2RlMDAwMDE2MjUpIDEwMTIgMCBSIChub2RlMDAwMDE2 MjYpIDEwMTMgMCBSIChub2RlMDAwMDE2MjcpIDEwMTQgMCBSIChub2RlMDAwMDE2MjgpIDEwMTUg MCBSIChub2RlMDAwMDE2MzApIDEwMTYgMCBSIChub2RlMDAwMDE2MzIpIDEwMTcgMCBSIChub2Rl MDAwMDE2MzMpIDEwMTggMCBSIChub2RlMDAwMDE2MzQpIDEwMTkgMCBSIChub2RlMDAwMDE2MzUp IDEwMjAgMCBSIChub2RlMDAwMDE2MzYpIDEwMjEgMCBSIChub2RlMDAwMDE2MzcpIDEwMjIgMCBS IChub2RlMDAwMDE2MzkpIDEwMjMgMCBSIChub2RlMDAwMDE2NDEpIDEwMjQgMCBSIChub2RlMDAw MDE2NDIpIDEwMjUgMCBSIChub2RlMDAwMDE2NDMpIDEwMjYgMCBSIChub2RlMDAwMDE2NDQpIDEw MjcgMCBSIChub2RlMDAwMDE2NDUpIDEwMjggMCBSIChub2RlMDAwMDE2NDYpIDEwMjkgMCBSIChu b2RlMDAwMDE2NDgpIDEwMzAgMCBSIChub2RlMDAwMDE2NTEpIDEwMzEgMCBSIChub2RlMDAwMDE2 NTIpIDEwMzIgMCBSIChub2RlMDAwMDE2NTUpIDEwMzMgMCBSIChub2RlMDAwMDE2NTcpIDEwMzQg MCBSIChub2RlMDAwMDE2NTgpIDEwMzUgMCBSIChub2RlMDAwMDE2NTkpIDEwMzYgMCBSIChub2Rl MDAwMDE2NjApIDEwMzcgMCBSIChub2RlMDAwMDE2NjEpIDEwMzggMCBSIChub2RlMDAwMDE2NjIp IDEwMzkgMCBSIChub2RlMDAwMDE2NjQpIDEwNDAgMCBSIChub2RlMDAwMDE2NjYpIDEwNDEgMCBS IChub2RlMDAwMDE2NjcpIDEwNDIgMCBSIChub2RlMDAwMDE2NjgpIDEwNDMgMCBSIChub2RlMDAw MDE2NjkpIDEwNDQgMCBSIChub2RlMDAwMDE2NzApIDEwNDUgMCBSIChub2RlMDAwMDE2NzEpIDEw NDYgMCBSIChub2RlMDAwMDE2NzUpIDEwNDcgMCBSIChub2RlMDAwMDE2NzcpIDEwNDggMCBSIChu b2RlMDAwMDE2NzgpIDEwNDkgMCBSIChub2RlMDAwMDE2NzkpIDEwNTAgMCBSIChub2RlMDAwMDE2 ODApIDEwNTEgMCBSIChub2RlMDAwMDE2ODEpIDEwNTIgMCBSIChub2RlMDAwMDE2ODIpIDEwNTMg MCBSIChub2RlMDAwMDE2ODMpIDEwNTQgMCBSIChub2RlMDAwMDE2ODQpIDEwNTUgMCBSIChub2Rl MDAwMDE2ODUpIDEwNTYgMCBSIChub2RlMDAwMDE2ODYpIDEwNTcgMCBSIChub2RlMDAwMDE2ODgp IDEwNTggMCBSIChub2RlMDAwMDE2OTApIDEwNTkgMCBSIChub2RlMDAwMDE2OTEpIDEwNjAgMCBS IChub2RlMDAwMDE2OTIpIDEwNjEgMCBSIChub2RlMDAwMDE2OTMpIDEwNjIgMCBSIChub2RlMDAw MDE2OTQpIDEwNjMgMCBSIChub2RlMDAwMDE2OTUpIDEwNjQgMCBSIChub2RlMDAwMDE2OTcpIDEw NjUgMCBSIChub2RlMDAwMDE2OTkpIDEwNjYgMCBSIChub2RlMDAwMDE3MDApIDEwNjcgMCBSIChu b2RlMDAwMDE3MDEpIDEwNjggMCBSIChub2RlMDAwMDE3MDIpIDEwNjkgMCBSIChub2RlMDAwMDE3 MDMpIDEwNzAgMCBSIChub2RlMDAwMDE3MDQpIDEwNzEgMCBSIChub2RlMDAwMDE3MDYpIDEwNzIg MCBSIChub2RlMDAwMDE3MDgpIDEwNzMgMCBSIChub2RlMDAwMDE3MDkpIDEwNzQgMCBSIChub2Rl MDAwMDE3MTApIDEwNzUgMCBSIChub2RlMDAwMDE3MTEpIDEwNzYgMCBSIChub2RlMDAwMDE3MTIp IDEwNzggMCBSIChub2RlMDAwMDE3MTQpIDEwNzkgMCBSIChub2RlMDAwMDE3MTYpIDEwODAgMCBS IChub2RlMDAwMDE3MTcpIDEwODEgMCBSIChub2RlMDAwMDE3MTgpIDEwODIgMCBSIChub2RlMDAw MDE3MTkpIDEwODMgMCBSIChub2RlMDAwMDE3MjIpIDEwODQgMCBSIChub2RlMDAwMDE3MjUpIDEw ODUgMCBSIChub2RlMDAwMDE3MjYpIDEwODYgMCBSIChub2RlMDAwMDE3MjkpIDEwODcgMCBSIChu b2RlMDAwMDE3MzEpIDEwODggMCBSIChub2RlMDAwMDE3MzIpIDEwODkgMCBSIChub2RlMDAwMDE3 MzMpIDEwOTAgMCBSIChub2RlMDAwMDE3MzQpIDEwOTEgMCBSIChub2RlMDAwMDE3MzUpIDEwOTIg MCBSIChub2RlMDAwMDE3MzYpIDEwOTMgMCBSIChub2RlMDAwMDE3MzgpIDEwOTQgMCBSIChub2Rl MDAwMDE3NDApIDEwOTUgMCBSIChub2RlMDAwMDE3NDEpIDEwOTYgMCBSIChub2RlMDAwMDE3NDIp IDEwOTcgMCBSIChub2RlMDAwMDE3NDMpIDEwOTggMCBSIChub2RlMDAwMDE3NDQpIDEwOTkgMCBS IChub2RlMDAwMDE3NDUpIDExMDAgMCBSIChub2RlMDAwMDE3NDcpIDExMDEgMCBSIChub2RlMDAw MDE3NDkpIDExMDIgMCBSIChub2RlMDAwMDE3NTApIDExMDMgMCBSIChub2RlMDAwMDE3NTEpIDEx MDQgMCBSIChub2RlMDAwMDE3NTIpIDExMDUgMCBSIChub2RlMDAwMDE3NTMpIDExMDYgMCBSIChu b2RlMDAwMDE3NTQpIDExMDcgMCBSIChub2RlMDAwMDE3NTYpIDExMDggMCBSIChub2RlMDAwMDE3 NTgpIDExMDkgMCBSIChub2RlMDAwMDE3NTkpIDExMTAgMCBSIChub2RlMDAwMDE3NjApIDExMTEg MCBSIChub2RlMDAwMDE3NjEpIDExMTIgMCBSIChub2RlMDAwMDE3NjIpIDExMTQgMCBSIChub2Rl MDAwMDE3NjQpIDExMTUgMCBSIChub2RlMDAwMDE3NjYpIDExMTYgMCBSIChub2RlMDAwMDE3Njcp IDExMTcgMCBSIChub2RlMDAwMDE3NjgpIDExMTggMCBSIChub2RlMDAwMDE3NjkpIDExMTkgMCBS IChub2RlMDAwMDE3NzApIDExMjEgMCBSIChub2RlMDAwMDE3NzIpIDExMjIgMCBSIChub2RlMDAw MDE3NzQpIDExMjMgMCBSIChub2RlMDAwMDE3NzUpIDExMjQgMCBSIChub2RlMDAwMDE3NzYpIDEx MjUgMCBSIChub2RlMDAwMDE3NzcpIDExMjYgMCBSIChub2RlMDAwMDE3NzgpIDExMjcgMCBSIChu b2RlMDAwMDE3NzkpIDExMjggMCBSIChub2RlMDAwMDE3ODEpIDExMjkgMCBSIChub2RlMDAwMDE3 ODQpIDExMzAgMCBSIChub2RlMDAwMDE3ODUpIDExMzEgMCBSIChub2RlMDAwMDE3ODgpIDExMzIg MCBSIChub2RlMDAwMDE3OTApIDExMzMgMCBSIChub2RlMDAwMDE3OTEpIDExMzQgMCBSIChub2Rl MDAwMDE3OTIpIDExMzUgMCBSIChub2RlMDAwMDE3OTMpIDExMzYgMCBSIChub2RlMDAwMDE3OTQp IDExMzcgMCBSIChub2RlMDAwMDE3OTUpIDExMzggMCBSIChub2RlMDAwMDE3OTcpIDExMzkgMCBS IChub2RlMDAwMDE3OTkpIDExNDAgMCBSIChub2RlMDAwMDE4MDApIDExNDEgMCBSIChub2RlMDAw MDE4MDEpIDExNDIgMCBSIChub2RlMDAwMDE4MDIpIDExNDMgMCBSIChub2RlMDAwMDE4MDMpIDEx NDQgMCBSIChub2RlMDAwMDE4MDQpIDExNDUgMCBSIChub2RlMDAwMDE4MDYpIDExNDYgMCBSIChu b2RlMDAwMDE4MDkpIDExNDcgMCBSIChub2RlMDAwMDE4MTApIDExNDggMCBSIChub2RlMDAwMDE4 MTMpIDExNDkgMCBSIChub2RlMDAwMDE4MTUpIDExNTAgMCBSIChub2RlMDAwMDE4MTYpIDExNTEg MCBSIChub2RlMDAwMDE4MTcpIDExNTIgMCBSIChub2RlMDAwMDE4MTgpIDExNTMgMCBSIChub2Rl MDAwMDE4MjApIDExNTQgMCBSIChub2RlMDAwMDE4MjEpIDExNTUgMCBSIChub2RlMDAwMDE4MjIp IDExNTYgMCBSIChub2RlMDAwMDE4MjMpIDExNTcgMCBSIChub2RlMDAwMDE4MjUpIDExNTggMCBS IChub2RlMDAwMDE4MjgpIDExNTkgMCBSIChub2RlMDAwMDE4MjkpIDExNjAgMCBSIChub2RlMDAw MDE4MzIpIDExNjEgMCBSIChub2RlMDAwMDE4MzQpIDExNjIgMCBSIChub2RlMDAwMDE4MzUpIDEx NjMgMCBSIChub2RlMDAwMDE4MzYpIDExNjQgMCBSIChub2RlMDAwMDE4MzcpIDExNjUgMCBSIChu b2RlMDAwMDE4MzgpIDExNjYgMCBSIChub2RlMDAwMDE4MzkpIDExNjcgMCBSIChub2RlMDAwMDE4 NDEpIDExNjggMCBSIChub2RlMDAwMDE4NDMpIDExNjkgMCBSIChub2RlMDAwMDE4NDQpIDExNzAg MCBSIChub2RlMDAwMDE4NDUpIDExNzEgMCBSIChub2RlMDAwMDE4NDYpIDExNzIgMCBSIChub2Rl MDAwMDE4NDcpIDExNzMgMCBSIChub2RlMDAwMDE4NDgpIDExNzQgMCBSIChub2RlMDAwMDE4NTAp IDExNzUgMCBSIChub2RlMDAwMDE4NTMpIDExNzYgMCBSIChub2RlMDAwMDE4NTQpIDExNzcgMCBS IChub2RlMDAwMDE4NTcpIDExNzggMCBSIChub2RlMDAwMDE4NTkpIDExNzkgMCBSIChub2RlMDAw MDE4NjApIDExODAgMCBSIChub2RlMDAwMDE4NjEpIDExODEgMCBSIChub2RlMDAwMDE4NjIpIDEx ODIgMCBSIChub2RlMDAwMDE4NjMpIDExODMgMCBSIChub2RlMDAwMDE4NjQpIDExODQgMCBSIChu b2RlMDAwMDE4NjYpIDExODUgMCBSIChub2RlMDAwMDE4NjkpIDExODYgMCBSIChub2RlMDAwMDE4 NzApIDExODcgMCBSIChub2RlMDAwMDE4NzMpIDExODggMCBSIChub2RlMDAwMDE4NzUpIDExODkg MCBSIChub2RlMDAwMDE4NzYpIDExOTAgMCBSIChub2RlMDAwMDE4NzcpIDExOTEgMCBSIChub2Rl MDAwMDE4NzgpIDExOTIgMCBSIChub2RlMDAwMDE4NzkpIDExOTMgMCBSIChub2RlMDAwMDE4ODAp IDExOTQgMCBSIChub2RlMDAwMDE4ODIpIDExOTUgMCBSIChub2RlMDAwMDE4ODUpIDExOTYgMCBS IChub2RlMDAwMDE4ODYpIDExOTcgMCBSIChub2RlMDAwMDE4ODkpIDExOTggMCBSIChub2RlMDAw MDE4OTEpIDExOTkgMCBSIChub2RlMDAwMDE4OTIpIDEyMDAgMCBSIChub2RlMDAwMDE4OTMpIDEy MDEgMCBSIChub2RlMDAwMDE4OTQpIDEyMDIgMCBSIChub2RlMDAwMDE4OTUpIDEyMDMgMCBSIChu b2RlMDAwMDE4OTYpIDEyMDQgMCBSIChub2RlMDAwMDE4OTgpIDEyMDUgMCBSIChub2RlMDAwMDE5 MDApIDEyMDYgMCBSIChub2RlMDAwMDE5MDEpIDEyMDcgMCBSIChub2RlMDAwMDE5MDIpIDEyMDgg MCBSIChub2RlMDAwMDE5MDMpIDEyMDkgMCBSIChub2RlMDAwMDE5MDQpIDEyMTAgMCBSIChub2Rl MDAwMDE5MDUpIDEyMTEgMCBSIChub2RlMDAwMDE5MDkpIDEyMTIgMCBSIChub2RlMDAwMDE5MTEp IDEyMTMgMCBSIChub2RlMDAwMDE5MTIpIDEyMTQgMCBSIChub2RlMDAwMDE5MTMpIDEyMTUgMCBS IChub2RlMDAwMDE5MTQpIDEyMTYgMCBSIChub2RlMDAwMDE5MTUpIDEyMTcgMCBSIChub2RlMDAw MDE5MTYpIDEyMTggMCBSIChub2RlMDAwMDE5MTcpIDEyMTkgMCBSIChub2RlMDAwMDE5MTgpIDEy MjAgMCBSIChub2RlMDAwMDE5MjApIDEyMjEgMCBSIChub2RlMDAwMDE5MjMpIDEyMjIgMCBSIChu b2RlMDAwMDE5MjQpIDEyMjMgMCBSIChub2RlMDAwMDE5MjcpIDEyMjQgMCBSIChub2RlMDAwMDE5 MjkpIDEyMjUgMCBSIChub2RlMDAwMDE5MzApIDEyMjYgMCBSIChub2RlMDAwMDE5MzEpIDEyMjcg MCBSIChub2RlMDAwMDE5MzIpIDEyMjggMCBSIChub2RlMDAwMDE5MzMpIDEyMjkgMCBSIChub2Rl MDAwMDE5MzQpIDEyMzAgMCBSIChub2RlMDAwMDE5MzYpIDEyMzEgMCBSIChub2RlMDAwMDE5Mzgp IDEyMzIgMCBSIChub2RlMDAwMDE5MzkpIDEyMzMgMCBSIChub2RlMDAwMDE5NDApIDEyMzQgMCBS IChub2RlMDAwMDE5NDEpIDEyMzUgMCBSIChub2RlMDAwMDE5NDIpIDEyMzYgMCBSIChub2RlMDAw MDE5NDMpIDEyMzcgMCBSIChub2RlMDAwMDE5NDUpIDEyMzggMCBSIChub2RlMDAwMDE5NDcpIDEy MzkgMCBSIChub2RlMDAwMDE5NDgpIDEyNDAgMCBSIChub2RlMDAwMDE5NDkpIDEyNDEgMCBSIChu b2RlMDAwMDE5NTApIDEyNDIgMCBSIChub2RlMDAwMDE5NTEpIDEyNDMgMCBSIChub2RlMDAwMDE5 NTIpIDEyNDQgMCBSIChub2RlMDAwMDE5NTQpIDEyNDUgMCBSIChub2RlMDAwMDE5NTcpIDEyNDYg MCBSIChub2RlMDAwMDE5NTgpIDEyNDcgMCBSIChub2RlMDAwMDE5NjEpIDEyNDggMCBSIChub2Rl MDAwMDE5NjMpIDEyNDkgMCBSIChub2RlMDAwMDE5NjQpIDEyNTAgMCBSIChub2RlMDAwMDE5NjUp IDEyNTEgMCBSIChub2RlMDAwMDE5NjYpIDEyNTIgMCBSIChub2RlMDAwMDE5NjcpIDEyNTMgMCBS IChub2RlMDAwMDE5NjgpIDEyNTQgMCBSIChub2RlMDAwMDE5NzApIDEyNTUgMCBSIChub2RlMDAw MDE5NzIpIDEyNTYgMCBSIChub2RlMDAwMDE5NzMpIDEyNTcgMCBSIChub2RlMDAwMDE5NzQpIDEy NTggMCBSIChub2RlMDAwMDE5NzUpIDEyNTkgMCBSIChub2RlMDAwMDE5NzYpIDEyNjAgMCBSIChu b2RlMDAwMDE5NzcpIDEyNjEgMCBSIChub2RlMDAwMDE5NzkpIDEyNjIgMCBSIChub2RlMDAwMDE5 ODEpIDEyNjMgMCBSIChub2RlMDAwMDE5ODIpIDEyNjQgMCBSIChub2RlMDAwMDE5ODMpIDEyNjUg MCBSIChub2RlMDAwMDE5ODQpIDEyNjYgMCBSIChub2RlMDAwMDE5ODUpIDEyNjcgMCBSIChub2Rl MDAwMDE5ODYpIDEyNjggMCBSIChub2RlMDAwMDE5ODgpIDEyNjkgMCBSIChub2RlMDAwMDE5OTAp IDEyNzAgMCBSIChub2RlMDAwMDE5OTEpIDEyNzEgMCBSIChub2RlMDAwMDE5OTIpIDEyNzIgMCBS IChub2RlMDAwMDE5OTMpIDEyNzMgMCBSIChub2RlMDAwMDE5OTQpIDEyNzUgMCBSIChub2RlMDAw MDE5OTYpIDEyNzYgMCBSIChub2RlMDAwMDE5OTgpIDEyNzcgMCBSIChub2RlMDAwMDE5OTkpIDEy NzggMCBSIChub2RlMDAwMDIwMDApIDEyNzkgMCBSIChub2RlMDAwMDIwMDEpIDEyODAgMCBSIChu b2RlMDAwMDIwMDIpIDEyODEgMCBSIChub2RlMDAwMDIwMDMpIDEyODIgMCBSIChub2RlMDAwMDIw MDUpIDEyODMgMCBSIChub2RlMDAwMDIwMDgpIDEyODQgMCBSIChub2RlMDAwMDIwMDkpIDEyODUg MCBSIChub2RlMDAwMDIwMTIpIDEyODYgMCBSIChub2RlMDAwMDIwMTQpIDEyODcgMCBSIChub2Rl MDAwMDIwMTUpIDEyODggMCBSIChub2RlMDAwMDIwMTYpIDEyODkgMCBSIChub2RlMDAwMDIwMTcp IDEyOTAgMCBSIChub2RlMDAwMDIwMTkpIDEyOTEgMCBSIChub2RlMDAwMDIwMjApIDEyOTIgMCBS IChub2RlMDAwMDIwMjEpIDEyOTMgMCBSIChub2RlMDAwMDIwMjIpIDEyOTQgMCBSIChub2RlMDAw MDIwMjQpIDEyOTUgMCBSIChub2RlMDAwMDIwMjYpIDEyOTYgMCBSIChub2RlMDAwMDIwMjcpIDEy OTcgMCBSIChub2RlMDAwMDIwMjgpIDEyOTggMCBSIChub2RlMDAwMDIwMjkpIDEyOTkgMCBSIChu b2RlMDAwMDIwMzApIDEzMDAgMCBSIChub2RlMDAwMDIwMzEpIDEzMDEgMCBSIChub2RlMDAwMDIw MzMpIDEzMDIgMCBSIChub2RlMDAwMDIwMzUpIDEzMDMgMCBSIChub2RlMDAwMDIwMzYpIDEzMDQg MCBSIChub2RlMDAwMDIwMzcpIDEzMDUgMCBSIChub2RlMDAwMDIwMzgpIDEzMDYgMCBSIChub2Rl MDAwMDIwMzkpIDEzMDcgMCBSIChub2RlMDAwMDIwNDApIDEzMDggMCBSIChub2RlMDAwMDIwNDIp IDEzMDkgMCBSIChub2RlMDAwMDIwNDUpIDEzMTAgMCBSIChub2RlMDAwMDIwNDYpIDEzMTEgMCBS IChub2RlMDAwMDIwNDkpIDEzMTIgMCBSIChub2RlMDAwMDIwNTEpIDEzMTMgMCBSIChub2RlMDAw MDIwNTIpIDEzMTQgMCBSIChub2RlMDAwMDIwNTMpIDEzMTUgMCBSIChub2RlMDAwMDIwNTQpIDEz MTYgMCBSIChub2RlMDAwMDIwNTUpIDEzMTcgMCBSIChub2RlMDAwMDIwNTYpIDEzMTggMCBSIChu b2RlMDAwMDIwNTgpIDEzMTkgMCBSIChub2RlMDAwMDIwNjEpIDEzMjAgMCBSIChub2RlMDAwMDIw NjIpIDEzMjEgMCBSIChub2RlMDAwMDIwNjUpIDEzMjIgMCBSIChub2RlMDAwMDIwNjcpIDEzMjMg MCBSIChub2RlMDAwMDIwNjgpIDEzMjQgMCBSIChub2RlMDAwMDIwNjkpIDEzMjUgMCBSIChub2Rl MDAwMDIwNzApIDEzMjYgMCBSIChub2RlMDAwMDIwNzEpIDEzMjcgMCBSIChub2RlMDAwMDIwNzIp IDEzMjggMCBSIChub2RlMDAwMDIwNzQpIDEzMjkgMCBSIChub2RlMDAwMDIwNzYpIDEzMzAgMCBS IChub2RlMDAwMDIwNzcpIDEzMzEgMCBSIChub2RlMDAwMDIwNzgpIDEzMzIgMCBSIChub2RlMDAw MDIwNzkpIDEzMzMgMCBSIChub2RlMDAwMDIwODApIDEzMzQgMCBSIChub2RlMDAwMDIwODEpIDEz MzUgMCBSIChub2RlMDAwMDIwODMpIDEzMzYgMCBSIChub2RlMDAwMDIwODUpIDEzMzcgMCBSIChu b2RlMDAwMDIwODYpIDEzMzggMCBSIChub2RlMDAwMDIwODcpIDEzMzkgMCBSIChub2RlMDAwMDIw ODgpIDEzNDAgMCBSIChub2RlMDAwMDIwODkpIDEzNDEgMCBSIChub2RlMDAwMDIwOTApIDEzNDIg MCBSIChub2RlMDAwMDIwOTIpIDEzNDMgMCBSIChub2RlMDAwMDIwOTQpIDEzNDQgMCBSIChub2Rl MDAwMDIwOTUpIDEzNDUgMCBSIChub2RlMDAwMDIwOTYpIDEzNDYgMCBSIChub2RlMDAwMDIwOTcp IDEzNDcgMCBSIChub2RlMDAwMDIwOTgpIDEzNDggMCBSIChub2RlMDAwMDIwOTkpIDEzNDkgMCBS IChub2RlMDAwMDIxMDEpIDEzNTAgMCBSIChub2RlMDAwMDIxMDMpIDEzNTEgMCBSIChub2RlMDAw MDIxMDQpIDEzNTIgMCBSIChub2RlMDAwMDIxMDUpIDEzNTMgMCBSIChub2RlMDAwMDIxMDYpIDEz NTQgMCBSIChub2RlMDAwMDIxMDcpIDEzNTUgMCBSIChub2RlMDAwMDIxMDgpIDEzNTYgMCBSIChu b2RlMDAwMDIxMTIpIDEzNTcgMCBSIChub2RlMDAwMDIxMTQpIDEzNTggMCBSIChub2RlMDAwMDIx MTUpIDEzNTkgMCBSIChub2RlMDAwMDIxMTYpIDEzNjAgMCBSIChub2RlMDAwMDIxMTcpIDEzNjEg MCBSIChub2RlMDAwMDIxMTgpIDEzNjIgMCBSIChub2RlMDAwMDIxMTkpIDEzNjMgMCBSIChub2Rl MDAwMDIxMjApIDEzNjQgMCBSIChub2RlMDAwMDIxMjEpIDEzNjUgMCBSIChub2RlMDAwMDIxMjIp IDEzNjYgMCBSIChub2RlMDAwMDIxMjMpIDEzNjcgMCBSIChub2RlMDAwMDIxMjQpIDEzNjggMCBS IChub2RlMDAwMDIxMjUpIDEzNjkgMCBSIChub2RlMDAwMDIxMjcpIDEzNzAgMCBSIChub2RlMDAw MDIxMjkpIDEzNzEgMCBSIChub2RlMDAwMDIxMzApIDEzNzIgMCBSIChub2RlMDAwMDIxMzEpIDEz NzMgMCBSIChub2RlMDAwMDIxMzIpIDEzNzQgMCBSIChub2RlMDAwMDIxMzMpIDEzNzUgMCBSIChu b2RlMDAwMDIxMzQpIDEzNzYgMCBSIChub2RlMDAwMDIxMzYpIDEzNzcgMCBSIChub2RlMDAwMDIx MzgpIDEzNzggMCBSIChub2RlMDAwMDIxMzkpIDEzNzkgMCBSIChub2RlMDAwMDIxNDApIDEzODAg MCBSIChub2RlMDAwMDIxNDEpIDEzODEgMCBSIChub2RlMDAwMDIxNDIpIDEzODIgMCBSIChub2Rl MDAwMDIxNDMpIDEzODMgMCBSIChub2RlMDAwMDIxNDUpIDEzODQgMCBSIChub2RlMDAwMDIxNDcp IDEzODUgMCBSIChub2RlMDAwMDIxNDgpIDEzODYgMCBSIChub2RlMDAwMDIxNDkpIDEzODcgMCBS IChub2RlMDAwMDIxNTApIDEzODggMCBSIChub2RlMDAwMDIxNTEpIDEzODkgMCBSIChub2RlMDAw MDIxNTIpIDEzOTAgMCBSIChub2RlMDAwMDIxNTQpIDEzOTEgMCBSIChub2RlMDAwMDIxNTcpIDEz OTIgMCBSIChub2RlMDAwMDIxNTgpIDEzOTMgMCBSIChub2RlMDAwMDIxNjEpIDEzOTQgMCBSIChu b2RlMDAwMDIxNjMpIDEzOTUgMCBSIChub2RlMDAwMDIxNjQpIDEzOTYgMCBSIChub2RlMDAwMDIx NjUpIDEzOTcgMCBSIChub2RlMDAwMDIxNjYpIDEzOTggMCBSIChub2RlMDAwMDIxNjcpIDEzOTkg MCBSIChub2RlMDAwMDIxNjgpIDE0MDAgMCBSIChub2RlMDAwMDIxNzApIDE0MDEgMCBSIChub2Rl MDAwMDIxNzIpIDE0MDIgMCBSIChub2RlMDAwMDIxNzMpIDE0MDMgMCBSIChub2RlMDAwMDIxNzQp IDE0MDQgMCBSIChub2RlMDAwMDIxNzUpIDE0MDUgMCBSIChub2RlMDAwMDIxNzYpIDE0MDYgMCBS IChub2RlMDAwMDIxNzcpIDE0MDcgMCBSIChub2RlMDAwMDIxNzkpIDE0MDggMCBSIChub2RlMDAw MDIxODIpIDE0MDkgMCBSIChub2RlMDAwMDIxODMpIDE0MTAgMCBSIChub2RlMDAwMDIxODYpIDE0 MTEgMCBSIChub2RlMDAwMDIxODgpIDE0MTIgMCBSIChub2RlMDAwMDIxODkpIDE0MTMgMCBSIChu b2RlMDAwMDIxOTApIDE0MTQgMCBSIChub2RlMDAwMDIxOTEpIDE0MTUgMCBSIChub2RlMDAwMDIx OTIpIDE0MTYgMCBSIChub2RlMDAwMDIxOTMpIDE0MTcgMCBSIChub2RlMDAwMDIxOTUpIDE0MTgg MCBSIChub2RlMDAwMDIxOTcpIDE0MTkgMCBSIChub2RlMDAwMDIxOTgpIDE0MjAgMCBSIChub2Rl MDAwMDIxOTkpIDE0MjEgMCBSIChub2RlMDAwMDIyMDApIDE0MjIgMCBSIChub2RlMDAwMDIyMDEp IDE0MjMgMCBSIChub2RlMDAwMDIyMDIpIDE0MjQgMCBSIChub2RlMDAwMDIyMDQpIDE0MjUgMCBS IChub2RlMDAwMDIyMDYpIDE0MjYgMCBSIChub2RlMDAwMDIyMDcpIDE0MjcgMCBSIChub2RlMDAw MDIyMDgpIDE0MjggMCBSIChub2RlMDAwMDIyMDkpIDE0MjkgMCBSIChub2RlMDAwMDIyMTApIDE0 MzAgMCBSIChub2RlMDAwMDIyMTEpIDE0MzEgMCBSIChub2RlMDAwMDIyMTMpIDE0MzIgMCBSIChu b2RlMDAwMDIyMTUpIDE0MzMgMCBSIChub2RlMDAwMDIyMTYpIDE0MzQgMCBSIChub2RlMDAwMDIy MTcpIDE0MzUgMCBSIChub2RlMDAwMDIyMTgpIDE0MzYgMCBSIChub2RlMDAwMDIyMTkpIDE0Mzcg MCBSIChub2RlMDAwMDIyMjApIDE0MzggMCBSIChub2RlMDAwMDIyMjIpIDE0MzkgMCBSIChub2Rl MDAwMDIyMjQpIDE0NDAgMCBSIChub2RlMDAwMDIyMjUpIDE0NDEgMCBSIChub2RlMDAwMDIyMjYp IDE0NDIgMCBSIChub2RlMDAwMDIyMjcpIDE0NDMgMCBSIChub2RlMDAwMDIyMjgpIDE0NDQgMCBS IChub2RlMDAwMDIyMjkpIDE0NDUgMCBSIChub2RlMDAwMDIyMzEpIDE0NDYgMCBSIChub2RlMDAw MDIyMzMpIDE0NDcgMCBSIChub2RlMDAwMDIyMzQpIDE0NDggMCBSIChub2RlMDAwMDIyMzUpIDE0 NDkgMCBSIChub2RlMDAwMDIyMzYpIDE0NTAgMCBSIChub2RlMDAwMDIyMzcpIDE0NTIgMCBSIChu b2RlMDAwMDIyMzkpIDE0NTMgMCBSIChub2RlMDAwMDIyNDIpIDE0NTQgMCBSIChub2RlMDAwMDIy NDMpIDE0NTUgMCBSIChub2RlMDAwMDIyNDYpIDE0NTYgMCBSIChub2RlMDAwMDIyNDcpIDE0NTcg MCBSIChub2RlMDAwMDIyNDgpIDE0NTggMCBSIChub2RlMDAwMDIyNDkpIDE0NTkgMCBSIChub2Rl MDAwMDIyNTEpIDE0NjAgMCBSIChub2RlMDAwMDIyNTIpIDE0NjEgMCBSIChub2RlMDAwMDIyNTQp IDE0NjIgMCBSIChub2RlMDAwMDIyNTUpIDE0NjMgMCBSIChub2RlMDAwMDIyNTcpIDE0NjQgMCBS IChub2RlMDAwMDIyNTgpIDE0NjUgMCBSIChub2RlMDAwMDIyNTkpIDE0NjYgMCBSIChub2RlMDAw MDIyNjApIDE0NjcgMCBSIChub2RlMDAwMDIyNjEpIDE0NjggMCBSIChub2RlMDAwMDIyNjIpIDE0 NjkgMCBSIChub2RlMDAwMDIyNjMpIDE0NzAgMCBSXT4+CmVuZG9iagoxNDc2IDAgb2JqCjw8L0tp ZHMgWzE0NzUgMCBSXT4+CmVuZG9iagozMiAwIG9iago8PC9UeXBlIC9TdHJ1Y3RUcmVlUm9vdAov SyAzMyAwIFIKL1BhcmVudFRyZWVOZXh0S2V5IDMKL1BhcmVudFRyZWUgMTQ3NCAwIFIKL0lEVHJl ZSAxNDc2IDAgUj4+CmVuZG9iagoxNDc3IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cKL1BhZ2VzIDMw IDAgUgovRGVzdHMgMzEgMCBSCi9NYXJrSW5mbyA8PC9UeXBlIC9NYXJrSW5mbwovTWFya2VkIHRy dWU+PgovU3RydWN0VHJlZVJvb3QgMzIgMCBSPj4KZW5kb2JqCjE0NzggMCBvYmoKPDwvTGVuZ3Ro MSAyMDY0MAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDE1MTkxPj4gc3RyZWFtCnicvXwJ eFvFtfDMvdpl2ZJX2ZYtybLlTbY2S7YSL9o3W7IlS7KkYIgsyZItyXZsx7INYWkLhNCWlLJDW6CU spTihKUOpZBCKG1JX2kLLaXQNdAWSFeWV0js/1zZgUD52r73ve+/c+/MmTkzZ2bOnDnnzNWCMEKo DCIaUg2PKjWf7XzvCoRwL5TunljIztAuYlVC/hbIO+O52BxJJ2+C/AnIXxBfWpTcPDVgQIjYDQTq JxMLcWN1ux4hxsWAV00mY4uITtRDfg3yosm5VO6Wxc8wIH8cIfr+VHZl0v77n7+AEM+JkHgoncgt u1l3VSOkuAbqsNLJWOIPXx86DXg+tNenoUBwmvMJhDTUeBrTucXlyScYVP4ojGk+OxuPvRx89VyE igKAfzQXW55j3cF8GaGuLshLcsnF2Gc6Xjof8oAvNc/Eckk8Qj+MkP0GCj83u7C4mUZJyK8X8vPJ uT9978KfQR7GyHhybn527tsbr/wVIQ/0T9LgfgQfRHSY/6PEAWjx6a0Uv4xGiFLIUyhAUhHC6Kxr bmV+ARmRBK0w0AbkOQoyJ0H4S8NQi7yNPkj1fnYb4jBxmJ7Ax9H/9qIokfAUwTrPQSpEfMizoBct 0qEdyIpiaArlALeIVjY3C/13vI+JowyaRfNoeXNz83cfFz48u7Mv+iIiYD518AjJ61EZQlAbbZ6E 57UNM+ABt/GtzZ+SICXoQeohNgZ6kRyJ0D50A4xxH/oljKMKtaDf4X7IP4ieRb9CQyiKjiE3uhc7 0AHkRQaUw32oEf8Y6ZENfRE9Bi1WYMzPIjv6HJJCq0c2n4AyPboXraO3ERvVoT4UBiqfRjduHkO3 oj+gtzZv23wN+HEp1Hh+87dIiS4GLIFqUBPQnEZzuINY3Lwc9UN/N6BH0C9x5WY/qkBdqBe4lEJp 4N8M+hTgvoWeRz/DIphNB1JBP3Y0hq5En0fXozX0HSzG5+Mv0Nib6c1pFIIRTEO7q2E2z6Lfo79i AX4cP70p2nwQVoFAMtSDzAX8LegL6DZ0OzUT9DSEE+gkHsVjpIzs2uRtajbfg/olwDUjGkTnQIsc ugBmcgN6Cj0D4VfQawvW4yCewxfjA/hpwkyW0Zh07ybsHpADOYyyDw3D+BdgpAfRtcDDu9B9EJ5E PwHOs7GMMBEXE2+SAtJI89GXNi/avH/zsc0fworQUTHwfxDCEEjPMtqProDxXo0eRk+gF2Ct/oJO Yybm4yoYw4P4Zfw6gQgB0QrUvk/OkgfI+2mIdgvtZXo//fKNOzdObKY2r918ZvO/YfYEYgLvW1A3 hB7oYwD50CiKoATwOlOQjxvR/egQOgK8ex69iF5Gp9EGrod5dmMzjuJV/GV8DB/H7xAEwSfE0Gcr cTnxJQhHiePE82QNWUe2kGryXPI68kvkXbTP0xP0PfRr6IcYrzP3b8Q3EhtLGxdsPLo5uHn95tc2 j8JopDAaak2dyAWz9aEArOAkWi3w+gAlSzCeB9BDEB6GUX0TPYqOw9h+g94EmTsFfGAX+CAETqiw AffifhinBVuxCw/iYRyA9RnDYRzD03gfvhB/Ct8C4Qv4NpjHgxCO4G/iZ/Cz+GcQTuA3ILxD0Akm ISRkhJwwEoMQxiDEiDiRJqaIHPEZCHcS9xMPEuskIvtJOxmDsEYeJZ8nf0b+ivwHrYa2SDuf9m3a cdqLtBO0v9HepvPpKnqQHmIIGQbGEuMOxgPMDPM+5ovoMPD46zCns684WiGuI95FFxIO2GffBU31 fcIJK7EPP4DvAE59BeS2C8JLEIwQ1BA4ED4BPGyDcEbH0fOp9CIF5xOLaSoF07NIIWbnFlZBa6GZ WHayUBufpRe3ckIAQFYwaWyWNzXKGqQScX2dqLamWlhVWVFeVirglxTzirgcNovJoNNIAiOFTWbf LVmT716jyWVOZweVl8WgIHZWwe41CRTZP1xnTbK7UE3y4ZpGqDn5kZrGrZrG92tivqQX9XYoJDaZ ZO0HVplkHUd9YYA/Y5VFJGsnC7CnAB8swDyApVJoILEJ01bJGt4tsa3Zl9IHbLutQO6IkbIcHQoQ NOAslyK8hiyxfWkhJFQN21qNzGpbq5ZZCziyyRZLrI34wjZrrVQa6VCsYUtcNrGGZOa1kvbt5lQ7 CVT1h6HvDsUUNX50ZVFClrhy3YgmdlNQ7JzwGhmLrBG7qT4E7WtVMuta1eorwg+yZyDbp89CrhFN 9ljygB1Yc6VzK7ubysU+DbnBUQmQJS6NhNfwpZGtQRTGvjWLpMxGleyelqyxZWZZ+sD0buA58ocP 1xhrbLKYNbKGRsKHq43VhUyH4ojwwp1SYMqRDlOHiUp3SoUXbqW//+RW+Y+Pcgv1jv0a0kH/+3zB VE8yFwxzTRIvdCKDsfZQUbIHHYj3QDW4IhhmObXGtuw+wN8BrdboTXyZ5MBbCBZKdvKND5fEtksY Tfy3EAVSy/m+RAB+G15HzYrBdcQeCR/C+LORdbx56Tqy1h0Bi0Wedy6gWyhxmLJCa8i0KqCgTQpQ m0Jih1HbqXWTHJAccCUOSOySNCw4ramQAiJ5IKKE6YyGpyAOhKVrxkjt+2AyEtkBdNopOrQCnQMR oDC9TWG6QAEInIZKCsUgsEg+EvaF1y621q4ZrRFgCcjP0ZHw2lHgYiQCtTreHymk+6aE22PuhDF3 tAGg3KIyCjSAROTAga2cTLp29MCB2gPUPtjKr2P00QLjdsE6KhAAUVnHF48UUBfLpLVUgUwqk8Kw IlboSgXidWZ515H6X3NYczaHtTBaTYHDXf9HHNb9JxzW/0cc7v54DvfAmLspDhv+/3F4x1kcBrWk +zfBj85Hd2E5/hR4ArcTt5PD74eD/xzARv0vAx1D+CwjwHiTmWINsv7EHmOPcSo4Ma4HwlNFixDe 4n27WLYVSpgld56xLV/zbpacV9L7FhawCvkv9+0qpD8fvdO4sfvU53k3cRSQZb9viwjwDRD9evBn SfATLA8S2EVnrOOQUYRoTBeJOHSaiySJGjaD6cKomsV+XWr3C9vbvW/2ek73evlv93r4p3vRQO/p Xv6bEKlVWoFU0AyPlL60/t679MF3H1onf3GqCXocwZ8lHEQx9CQxclAfiWvoqJpGX8f3PyD9ZIgi eoL/KlJ6TqpVZdIK6Qh+Z4NNFF8MLV/a/AN+HPxBLpIby+htXC6vqqqG1UZUF/GelC5/tjAez2mv LWl9FQ1Q7WlyXZdeqwFDypDherNFqTSbVEIqMSuVFqBI2/wloaSnYSz9RiEiyeFSgsAESaNOMgR3 e2SP4DYkxXcd+gJ0UE0NTggTHejFpQbD5Z7O9n38p9QqrMUy/ExiY+ckPf3uEvCzdPMkeYi+G7zL enS1seFr+PWiV8rJp9BP0SuIVCMd3cAjh1iMW+vpxbdW8oj9pesE6wEJZ3/NOsE8JBErj795kv/2 STRwcgDmYVkx9qC6IrmwqVzOahLJ+U00Oa+Ko0OogtBhZh1A9BKAuNXFOoTLIGLXMnSYFEDUDlch 2r4uwXvG0XhjqaCrmZA1kIyK8qpKbSnlbDAJaUOzXMDv1muJfTPS/nvuGZA2GNd+d1Gyf+/Gr5+6 aP+u8zebwOVT//1zuHjjtWv+9rv9G/Sdf33y9NNrGw898Dh2YuKR05RfA2cksol+LqpEs8bqpfLL ygl5ub6cKDo9wfp1A/mPCeavZeW/5q3jmcNlE+Xr+EKjgFdEEjRWBZ3FLBLCmhLkOlY9VFTEq64S PoqXgftfweNoW95A0LaXuHegtMrgeevkKfxWe7tahWBilRWC8sqqCqmuH+sEXXJZA4Opa9ISE9g/ d/r4ilvYUjPaiGeL6BE6+70hTxtNVM/QR8kvqjR1fNE3qbH3wdifoSdQLVo3DjWV4iyawVNlZIK4 ruTtkrfLafQSRnlFSVM5rZ1VDnsGC6s5XMzlkCSqIYXVgmohl4PpjHJGppheUX5HjRFJa4vI/YJH q79JsODYhmB160TK4yf4b78Jq1vTd1xYA/tl4KQApoIFpYZSAwXxv8f/HpPOr3mqsPYiGp/VxOTB KrM5RVx6CanD7CJYWhofIkQtL7+X33tmafd0s7COmjqTwWzuxwXxJ7BUo++uIqV9eAYzbp29Iqhs b9f8+Yq7f/TbjcvwM7u96prZU7+pwhfgxN3X3Jzonme/+sDzN92x8ezG+Z2Roo0/UpyJbP6VXKJP w8nyWmOvq3oXk2A2Vja2Mg3MQeY0c5q1wjyfdXf1dxq5VVKhsAqRCtzA5wmriLIi4q1WYwNPepSN 2WxlWdk6XjCW1NKV+1t5/Ew9PXOrHMu/RSBwrnlYjxQE+5BaBfIPLBp/5bmtLQCMUY731by8D9jF P32GVwaKUzXC78H2g3nrK7Uava6rubDoMPGP8gDASkrMkbShoBZ++tDAp/d3j7/ME/KJW9c/Nz4T 6NSJW1686sav2pr9u3fkNp7feOP8uLTp6/Pfms34rsBEzY7rzs/N+xTnMG94+K6ZmK/T0No9ddtj G790tdWoKA6ZNl8jL6JfhBTov4zNl9ViHau8AiOitYpe3lBewS1il1TV8EtKFkpra2tqAaLRwQXC GmN9E/uO2lqiprrmDmOFVMCnEW838eiZhodvrVirICooyelErSA5nR0FyRl/s8CV3ppjNad7gQ/7 lMI3+CcxxZbLizvb6aCRkMBAMUigBS0lKPAJuCQEWZKLGkmWRCqW1kvrpDQGU84S0UFTNELEkLJ1 WFRLkxGgWECkCmqj7ZJL8DZr+U3AUDmws7usIE3MYiyTUjytqsfAVhkoD4qvPz6iWfjaxhs3fqqS yyJI4kV8n0Qm4ntpjRUb+4J3DO0LON0bT/11ojfR3vGNS565BpPzAySbxaXjX1bWFx9h0+8XVbf5 HYfiL2+8UCYeqe+grNNXNv+MryDvA81fhXRGEdHGYgraqrjVoCvK24q5bXR6cbWw+knpqdkzSuIk /wNDQKlQxJA1nLEGxNlm4VM2harf2KmwfdFkVCrt5m6SN2BVdJoGlKfWzMoOi6lTYd+2j/vAPhaj RnSjUfN0Lb6Ltc5ar3mo9h8sup5VKi2pbWxpLJPWVrXISssITifsAYLolMkaWYzA4yIsWicYD8l5 xa1loOnJQ/ImkHDKWm6Mw1r28k9Sj8BgoPQYrFJLdQPJrq8T10nqpHU0Bq2ppoklJxsY3ZhdDRG9 juhGzFpONz6j22GZ0Dgeb4SF6tYL+M1yaQOjQkDf0oLNOqmkiiYoJ2ALMGSgTNWev9z8p2N3bbxu U29cMGc1zxMtuOrb+Jx9F46EvvDK6aezkvOuBqd+55f212vf+/NKkWGRvGrOyJKf85WNsRs33jiv V7yDeiM3CBrhCvJBWBUjMuEi4+Rr8vfkBLPZziCKZDdxbjLczbmbexfvUfb32c8on1G9xH5J9aL6 DfZJVckYS6FuqxKJy8VIW1KCS1yaTr1BrSjhIEY5q1zbxOzs13NZ/X1cE9NkaOZzlaY2o3qlVdl2 fxvRtk4gI8cibK61NphpVuM6gQ9ZzJTBfPM0tTl6XwXJP917QokGKNWxpVqhaEk5Ljx5nNoVlO4o sHln/4CspagKM4kmnpwhL5XjYpocMftp9aiisaoeVVaVyfn1uLmFLEJyjFFxCX2AVY8EzeX1lN4t aF0MD6V8t4zrJYV12DOOgdMFywr7prFb37Sll6iygiY6I4tVlL0q1OquYBSKm7cSHSYGFwYP9jar zCsb6HPn4LLyhoy2s5PTVFHXobrvq0/Ymli81qr6JklTzw5rHzmk3+UPXYj3EW3yzsieXe0ityET 600FJ1ssNbXKIgOrp5K3s9F+44W2T23M7qhsLq7taq6Wh/vMEv3KOHGS2mNK8FgGyftRA5Khu42u K6vuYB0T/FTwU+FvBa/WM3VcGzfEnWZPc6YqpipX2Suc1YrVSm4Lq0rI5PCrhESVsIzJ4dF5Wpjm 58twmUnElRFmmVi4ThAPNPGtYmqdmhq3HJtSA7U8J8fBYTwOUi8wbNu+gpqChamtk3JKES6t48tR sRQijqC+TI5KJDx5weDxC6ymtD4q7OIGuRLLC5ofGExtge6qbT52Ia2MWH2oUyXTgT8hkernv3Df 59O+zh0iw8DKl275C2Z8V0Hef4lHalB1qnSVFU9/5fq/WJuDgmX7ZW//5Ifg+QFn1MCZk/Ql1IF2 oF8Ycze03N3yTMv3FL9TvKlgoFznBZ1Xdt7ceW/71zofaf9m5w/aj3d+p+el9l90Pt9TTLYPtRIy FvdF2ghHxD0oqJdUjdSJ6q+WasDE0apoDc0apayKpHftoJV2CHCXtoO5o7+5WcptoClLm41VuAqE /eHebusX23AbxcDencDA8ZOUDSj423xKwilFDzJeaiiYAMQveETbSYGdQp2hRaFTdMuRoQUifXuX HPe07pCjgvMArATXifIdQJWfcZq6Qc1v6fgKsnxbQEtws67AVkLXVaot1W97WBTLic6+lqZabVGp 2N8RbeA3McCNJiQ2biWXceUXmD2trt33/OT0NxZ2X2m+8NPXXkMeklQ04f6+ToKUVhTVFNGLiSnD ys5TPzR1YUJKqHayz++r6cDM+36Ou0/ddU4rvu8TmV99+bZToHNaNv9Ankveg8qQCNypnxvHp1jT RbOl2YrzmSus1aJ9gotK95XvqzhV/HYJL8iaZO0WHKM9Xfoc7VX2b0tYfSw2p0pIsjkEm0MywCiS mHSQDJEoXlfGvJpxO4NgmHjcOuEGYa7j/5CDOZTsislf8CnWi+u3ZHe81PDmyW3pPbmtV06fUStw b4twW3Etolc01cjLSwuapBYJ63G1kF5MylGlQAQwhohWwiisQsGH29IjW5oc5Fpajym+V4GZ3eI4 8J4ppcS8m5h47vSlnMc+MXWwT9b6my8/+oM/Pf61XkkxvpNbq17oIO958oE/PDeTLLroBSw68j3c 6Erq/Ql12AU+Sgsobj7Ishzljd3dHMxiV3NagRlycgCJ5L9slA6Imn4pI6V0eVmlUHCtUMvFYrqh vo7JYMibOGS9pAW3rBM0I7u4TqpkKoGBR/Amala+OQ7W7Phb4wZ+4XDUW3BqKYtGcQamJ+QfE275 ad2UUZLptF3dZ2wwtXs7MaUe67C2QrblwbdMW+69t93/i/CVqoa6tjpBsbxhqLbkvX/0XXL6dRHd Nkt8wvLF3I/sO6VdMkVNRd1gi+mk5fSFewbYcGRF+g0z+QTosjLkRCE0hp41xlxmp+VK8xWWe2rp 9BZ6N9tSYzFYpslsz53ldwrZpjJ+p1PRXkOrlDfUEvIhvknDhjzZGmL7NJpWIqR1iluHWx9vJVsd w9qxGkk1k+g3FI+NySuHfAflt8oJOWWWiiJ0rV4S6eyzNVeCn/tjY3HvkVErv1JVebDy1kpa5Tre PBQJK4+fHj8JogT38edOg0QV/FvKpTsOfFt6aXyJkifl6W3DtbWtC4+BMlwUE0vPOLvNnZi6KdNS uu3WAGYnrpAVnF1gbnPDliWSUHnaluUZIOQFZw22uH7bT6Z2Mfm9b63e+Wyg63NN/obKCWGRUtWc fOQe15qvIlhWdF8pR/CtW6tNdefZO3swPuf6jS89eMdR7aC5qLOqxbbnrabe2J6JprKlc1kbfzcu BCxwqsUkgYvpA0Y90XzT7r0/tpG+NvGOrvnH2RNiSQmnTnnzFx+91NVos+4sKhWIW5oiifJ6Vf68 P42rnatPEIMgraUgra/QF5EKPWystFXif1RhdlVNFVHD4ivFKkI2IBKv4/eMOxso6VVJGmsGRPUS WfuASCmRnVG6rbL29lZZjYBkNKto/IoS1NxfwVQpxfWcRpmyuoZSsBp+c7uSRlKro1EXHDNwJHoL Cra39wMFS21wtH3cBJEeR4WNDm5xpVBe2ViPq4RNVc31uOASbOvU7rPOof14AFcJ9N1n7P6Hz6nb BaV+bV0Pt4KnuKR6NzGgDk/evlOiHtoYHtOYot6ru4IbDhF35wx5tEdHEo28JlY98/RNzobe/c69 G+lpI0ckKtoxg6+NLc8JNsrmeopElP2CPU8UAxe5qAmNG+WyopKBIlGTpFEmkQgl/JEqkfBqkUQM 5xFRE+taAomYTY2c5oKXJeFeS28WS17ml1C7XK6kXFaQ2sLZGxzrwlG1wBD+W6C81KrSD7a0jixM rXnbnFDTPjPpu3oV7X197YreizM97BIVt0LTfr9NxCK6Yxs1dH1/XwH7noCj24tfNlW30orFxYa6 IibrtGZ+B0tEnbRoIBeb9D2oB/3YuGRvDEuWKi6ruLPitcZ3G5k0iVwil+ol3dJIeUSVkkyrbqzg SBsaDKXlDbKKclmDsWG0VKour1CrKlTlarVK1iAFn0xevyUuJai+ViRiIH0rKRf1dDdzKtSAJ+tk KqJZU7e7+eLmo81k845uSu645Wplj4T74lFQg5Tw7DBQ1vnECfA++c+NHysY5SpDn1JJvTHqPV3V OwBa8c2TpwRbpVDOZPFr2mv4vZAWGPi+guw6i2/AUkFT4UALnnxFMS7BcOKihKd7qxBTPiTkabv7 VB1lIkE05VQwGSSuqK/o2IFvm9v/7Z1HPnvQt2GRCUQc9sb3tfWuDamIqRklX3PICUIkrBWW0Nmn vvFmraSoqogUiZiDh/R/WV9h1ogIXFTMLSvCN2x81gaGqB5431SQpgvgJOY2SioQaUGiKkljpaS0 6EXaDq6o6GCpgEbSoHJVJacapOhBQamSpFHyIyzIz4df3GwLTvfZwqLv1pwRlbZxM7e8r1hafflj TLL33A2RiG0YJX9krm5jMKSNvUXl7/nGtMyCTMAJjdFF3oW86F2jSF/dJSEEkq8WE8Otw70Efyff I/aSA90dFlHrY/g9cHKN4M+LUC+s4lADbQcSeSWNjTtELRJZ94Bop0Tm2iHySGRFEvoITOnqEour ttvoclqM3fqOxtpyOq3I5i0r0dj6qzT9YnFVCdPr6d3Z2sIZobYNV9ao7Lyq49kOwtmxjh1Gnt2o 71aarjI+ayScRij5hp1W1uxS0gtcGVYW9M3Sm0vjQupEeAZ4taB9eiljSh1nTwpKDR+8JNr27rZO HYJOPD4OR1xwGwoK/SwfDmSnDlMJCMjHaZ6tUwnzo0VnSqTempbmjoqKYmfzYTqdiB8cSvVJKtzd 58Vv04sH/Bt9Y90VTVmTsUlvOGdDd15XuTTTt9Shi2wYaphldWME3d1Jo8uEPCun+PKozS43DTb2 f9J960bMoWXViFj6UXx/rNPfXt29gXwBsqamyHopFt60Y8KiP/3y0A5cQ50yuzZ/A7b8HtBeQlSN rjYqvsN+hU1cx7+x8lb+vZVvceiVqJxWVRXkBPj0HSyhtppglmpZ3OoKazWXDg7cw7Ul1hIu5lI+ XG3Ntvtcaii4cODBFXS4AlXxmopwiRxVkRVyLGADVMYEqBgJ5biSBhGfUypH5QyIPnijWtDx4zXA XlRRTsgakA5RhrS0YJsJWXfX6ae/g2mnvnt0420c2ZG47aq5lZuubiKux2Ubp154euNFXPM8/mLX rl8d3jj+X1+9D2t6KW3NLvguh1AR0qJjxoierZdeV31j0z1NX2k+0fxWM4vTRG92N5F3NmJbI25g 8S08kfbFxk6LSPNLmVAiKKjz2iIuh6R38jtbtR1iQRGHTtTXsvplzFomEW/lajXFdCv4K4SRo6tv 7lQKjvIxn9Jfui6KPQXrR72VAP7A6dkgOMsLeV/uts4VjS0kk2yhyzGzESJaMyFHjCaWHG8fK6gz xZ7CS4ktLwOMHP6wcqPEc1vFUQwEf2ZL8HAsZc/e+KUp9+rGE+dqm7TcstLz6MfodLMmet6Bp//8 UE+rUW+e3RAsWn52dP3hXYoN9ul7GVYXeXSoHc4UYmxlMy43S3peP/7djUeKK3o2jiQ7WTJKS7CB xYfAM2xF+41Dx+pxdwMWt2JKibWCArBQCoAroQ2AJbia3yCuJ9sbGxtAnbWW15VJLq7DkjpVHVF3 bR2/uYoJ2/3iGlzTXtbcuOU8PHg/TLtNeXy8sKGPjVMs9Jw4fnLP+PZLuA+zEJ/Zsx/yEbaZsv3S krKk285Bd4WUfU5vk5ojLTUsV2l0TNKYN2qN6ia5p1I2OTK+USZlqUfwk/EgnSYtb2OXCTn8OyKJ vs7WHvue3o2+kIWQUvKV3jxJfA/kS400mDRKy1AZriRaeQZeumiKt8JdKdpfxGllqUTqHxmxCFqs 4889ADBoMqmxpKFNKKr+kbFWJK0Rw9wpHGQrKFy7tJSHOCwYL49Do4u1mlImXdvG1ZTU4D/XbNYQ NXaWSYNUzbi5q2Ed/93IR81zJbeWHC0hS+yoC86+wLil54TjJ06C7YT9uXRsfI9we5MKPtB7fTVv CGvefGUcA3QSoJOFohrhm69gfk3fSQC2trSopVUi5QvgzNTKqscSQUM9YrbQ65GUL67HZ8691Fmr TFtZtS2h1DHkfR+6W1smO/NOQYw/WAumDE9Lq5rtlw+OaQbmzl+8dUV3EauUzxAyxeUN/XvtIwc+ 9fyhq3pvKC4qpdfgJrxzvm9u1NzmbTKaL9s1d7CFw934Y0yfCO04x+lYvGnpuhZBEXkEJLMa1mUn 7TYwTWPGNrYA1zYQ5YShvoFh5Eo5DmZ/CdfIkXIbjfVS1EAoy2uFRoGiHFzY4y/VfLfmpb5jQv7p Y8cB5P8UIjRweum5GuF3awaOF14Rg2cBolYhI7ffNhVe3lIvbAWywpSp4z4ldgT7OMET2ht1DTWV XYv6pbaqHJ3OFtr69vDo5E3O00eHmm0NTZX19h1ThiRxLsmgc7jlBscNNN7b1O6CLUY+T16PdmK+ 8cjvmZiGaBhVoErcSigJVZ0+LA03hGVLlZfTLqc/LHq47inGq82ldqazxMl3VNH0um6ZjsNicHSM KhaHo6usqGhlgOFiVLVWtLR2yyCGR9+t43TLKgylnFZDqQ6qXcf4CuNhxk8ZtCplqYwBT7esu1vX Kquq4DBYmh24pJTcIeILdpKIUafUkDUikUpN1nK6GZwK2k6BwLWTqrtTwKhVG2txbZ+6V/mdl74z Tm1V5ZJSWNiyA1W9p8B7K8RUQWcnk97Obx+HFBJw3npZBR/uGIsJIJN/jLq3iiinjvpYBoPjRp3D qraOXGc8OXyWJ7d1mqNeuZwxx91lJJTo8ItynU7UvrNO3SbHZm249l7M0jo6N+J1VWJ5aaPAUnVb XbG4a+MFfVf7H4/uULjJ60W4rL4s3Gnxdbora0rBp6Mpm9/ZmPN2EiIRQQhLy0yS7trdDe911HPK ipgiEbehH49i2ZgEnCk4AmwYyWfA5irh5HW7cSZajZmcKmFLW6vCzbbWuhWh2rRiP2e/4gbFEcXP FMVOBW5u5yjaOWwOl2soFVYLOWz2aKlC0a5gc4XVgGMpm4jSClIpKkOMhiarqFjFVJ3Bqdjl6OJy XK4RUx/yUgewn44f42+vABoYOH1sgPKdqSyTTrnJTIhYwPFjx7Z5WyatKLxvrayqxQWXWIkL7GVi SsrfPxaXFpxlYGiTCN+pEXZyeK89SvIaRWJc1tpasvGU/7qFnomdHTWpyp4LGLSNow1aDX6JvF6M WTx5cV3d6X8QXFYPp0ZIEGIxvbP11GMvPNHT16IFw6dg13CIB91KppL6NJ36vu9uNpNx5tuz2xdJ EHS4tr5XS75fzPxXX32FDUSnkXQ6iegkE0FjkqRaAsBhMs+m8n9Gn7ZNn8tmfYQ+jSQYcCHGh+mz /hV9GA2DTmMwYO+RbASNaQX6ABR9DH3y4+iz/2f06dv0eRzOP9MHV5e5xZD/kD6MhsmgMZkkYgJ9 aAzsgmIAirlcin0foc/8Z/qc/5Q+lyJLP0O/pOij9OkkyWKyWFsM/4A+91/Rh9GwmDQWi4ZYtCIE jekMiiYA/KKif6IPFc/Q/wBT9L+jLyjmfYQ+g6SxWWz2FsP/Q/owGjaLxmbTEJtWjKAxg0mJNwCl FH36h+jT6Gz2GfofYHj/lj794+iXlRR/hD6TTufAtbWgH2CK/w19yqBxYL/SSxA0ZhboA1BeUvJP 9Bn/Y/owWw6bfjZ9FmOLfgX/Y+hz4doSmA8wJf+GPpcNzRiIy+AjaLxFH4BKPh9tbdWPpf8Bhv+v 6MNsuZwP0Wdv068qFXyEPovOKIJrS2A+wAj+Df0iDjQDfcMoRdCYVaAPgPD/hD7Mtoj7YfrMLfrU d6u2fh/Be2pj98Zu3k3/9DuDc+hPU28tti4C/c8v4h40Au1eIgygVxEqhed38PTBE6HwkJr+qY0B feU/oX322P5/XeRn0OB2qoSxqyFtgTm2AKyn5gdjb6HwANMAbmIYtsYI+S7atiaH+myyDqUBX302 bcDLEPWrBmoV4FgKi3MdtCBAPvloJ0jvHxhPQqWzv6FNfUWZlsjOpLZh98IWTP1K5tOxubks9FYJ G1QxMZVNgKCbqVWMxxTxBUV8RZGIKRJJRXJGkVxQTE4pJucVabj3KqYSiqkFxdSiIruoyC0ocouK maxiDu5FxfysYiGjWFhSLM4rlqZik4rYQgyeRUVsVTGRhDsHD4ApxcS8YgJ6gb5SqbP6iy1RfSYW JhSJlVlFcmKvIpktDGGWGkVyUZHcWxjLVFYxOUsNaXIvPCuKVEyRSihSWUVqIa9I7V1VpJYU6Vi+ MGIgtj3q1PbAp3NxRSaWU2Sgr0wypshMKTIZRSYL94wiA/UzC2lFJq/ITiiyKUU2U5hqdu8sPCuK 7JIil5xX5CaTilwK7rQil1HkZs6wYkIxk4B7gWLKzIxiZmVGMZtTzC5sc2jPXsV8TjE/Q7FqfnZS MQ/5PNzAtdgexcLEnGIhCXdasZAqsDKrWADaC3ADa6HCPMVdmOMicGQxpVjMKBZnKW4vLir2ZhQw 8aUpxdLeGUU+llTkZxXLsykFMHJ17xmpEFKRFz0LEuOnwEQqvjg0aliKj3k1yZmsJZRJpIPqhCYa CnlHx0KqCducLTm2nI66snMB+5w1YO8ZMqUXzJaxUMqijWaS0z0Z06rL4/RHx2zmzGp02q8OaV2r E2mzYzAT9Y1o092DuajDP2UaTWRsWm8mFBie8k+ac/GJuHUxMa31DDuXPVq7z+OK5tyzySn74OjU 8kjC1jMy4Y/mk+r47HC2KxRc0UFZOudaDiZDmtlBs2V5zqPJZ9wrsyN2zfK0yxzVJmEAwz5Dwjnm UMdXZzPhULB7aCq7ZyRjsCbTKWfIHrJ4sumZsDmqGs0YJoPW5WHbzKwr6cvn4tqUI6INeWPLeU/c HrKPrWSmhoIL+clA3m2b8a/ERkOR5J5Q3Lw8m3fY5hYDOY/Zo9alnP5MyBvyr4zMpPb40qaJmG25 3T2tyg6Pmnv86oX8xExi2jRm6B6bMYSD6cRc0JFNe9RzOpMqq/RMZXKuFd/stLYr4rEuWsKOoDWS S2StgTltVB2fsGtNTutUesSlicB6LEx7tameWLZn2W2x603p2aW4L+Lx2+0zk6r8lNsZUSdmzFmb 3bvsCy/aAg6L3TXq0tkcqgWXxh0bGjNNJ7UJlW0svWpLp9sduS63VZNIRTPq/MRqNuTK2tVelWoy Yvd5R7R+fWxK1eVf9u8dSmeCNvtCty8Xd0WdC9rhLp8vap/Le602lzPscVmnPBmXTZUfHp1bdVhd mtDY3NSIdUETzqdnRxxR3ZgNhCU4uzpoXx5N2uP6eNaQD2YjGe+qfS4eBlImuy4Sji5PaRbi4dxc zuxTeYZsptjESnbekgtqPCvBVMwRddlXvXrTsi3n0c5O2qZTo9FcZDGoDaUTVjPIrckXtWVmEuHg lDXlsU4s+6aiWtvYSHpo0Lpsz4RsvoDD6sl7Nf5c0uIOmrUqnXcmaI/mDd3uVZvDbfIEHIFU2J9d zDmn812eVGLRmtH5TdrZhZgm5Y6P+a3BlDoLaxyJ+jP2cLSrO7bqcSUc/qw1mw3HrcGpyExIZTN7 lmL5nhHnWI/TPmZfGs7mncMrsCdy8XxCZbAlpmf1pmmbxzMd1wdWTc7BfNweDSTSI9Ozw85p88xK Lh+w2iLppNkQiPlnHfaUIZcMhKYCjmW9dzpiHbPoso5MKG/RZjzDq6YZ63JwJmZyDZvDEe1wTpWO pe3DiUy8K7Ycsfh9PZ6EOjXjsyWHfFm/KpYLRqLOoDWWyfSEg96cdyqRHLbmrd6Z1OpwzudO5ObS YbUP1k6dc1sXlocckTFbzhVz2P05q0q3OmFVT45mdAvembhyOGubM+/p0g5nzN2JUfOUa7lraXDK HXNnIyG7JhOImL2qhNYXGvGpHJZUPhF3LhvG7FHtUMY/kbAZ2r1qT3Y0nF6IqAxR3/TctG9lMeZP dQVjY55uzcxcJpaPZxJW35DTb/CZl6PJ5GrPkk+7oJkMZ+dtKrd9bDrRbVantH6N1+Kzq0aj/h6r HeR40Orak0x1zcZTEatDYx91aCLd4VF7MKjeOxJQRbTusL0nkl4YDloTTtNKSDUSXuzxjKl6IOf2 rkZc5lw6n8zOLSanF3Nmh8cRXzXY3ZnQmG/anE0EE1OTo4mYy5ZXefLLKte0rss7l3Y7Qol2/3Q2 EBj1q02jqnDM0bXo0XblEz5VPupwZwP5YH5serndZbctBfypKW8mlQoF0hqzY1EVDEQt8ZR5cnjV 7J60ubpHx/LLMb9pbt4cSjpM9j1e23IuEY4EE7mIMxBaTI4GfEt+p3rZHzTkvaBbE2pvzh/w7DVZ 0uGhYLon5DA7PSZbJJn3Bfx2fzC2GkpGlz12i98QMof3BoJBg8ozlQ4FTHNm91Re7wmqVv0Wt840 lpgatqbTYduiYyRg6/Lk4kMef8aXmIp6RzJZTWRledVhUiftanuP1aIeTGTNkcBqNB/LdmUS8yFd wOZz26dMWfeKOz68qsuPhEG/WtPRkdyCNWl35UbMibw9FzdZU6G0KeSbc9rV0zZH1uu1mUNxVZc2 mNItTPqyzrAGdOhyfN4bdK2u5GatMZV7b0i9PDOmXlyNTCVU1sCC3efIj5gsc4PhlfSwV5vwRadN M6OBdCiR9U54/aZhs8O8FFKr2wMw2JDFFYioQmr/Sl4/Mu1dnHAqByc0cbMzZ+4xh0Nh80x6yu0H S7mcsbicyzNuc2QmuhLVxnKejNniGjM7uiZjOZ95MhddiC9HNcPT/vyY1T4ZXQ7m3FPu6ZGg1xSx ucKJaE8uNJPp9q34FsJTc4O+bMIadwbb7Xl/HmhEYxqX3TMdWQ7lMpOBseWMw7KgGlq1dXs1hoBH G3Tbwr65qN1mjqlUdlPKNpK0+E0Ty8HsSiq1ZNWanb6pTPtYOjubMHsX/GNdOdOKZ9Vhzjg9jpDG b8kvmoMqb0yz4PZqF1X2Mc+qbdkT9ObzyyNT2exQOrhkARlIZuzz0bTKb1mdHoyuml0eU8hsMxnS Fk1UGwwZuqPZ9HRco1uOOk0p8/KyO5nLj9kd/uVR0+yk2efWJ/3Z+VFn3Gf393igD6fdEor4/L7J sGauy5rLzo7OGnIOVU8smlfPRGyL4UTYNTOo6VoaHu0ZGh3tSXumDS7QaSPJlEcTmor7nKHldGIm 2mVdVamj+ag9rglGLKn06KDGMxzIz6rtWvuid3R2dDk9a0nO+Keiubk90dSi2erzZ7zWhN9jyrj9 MyZtMhW0hRx5z3Bo1h31LWdtWk8W+lnx5AzTVksW1PDcTCLUpTOlojN2h1pvyXuT0cDEoFUTWZ30 RdvDJpB1y+LiyJTBCb5MPBmwr8bD7uUhXyhjW40PJnILKwmLymEOGKbsWtvQhMqt9aa8bmtqbt47 1qUeHbMNhfML0ZgjoY7PZXuSztSUfaxLF3d40kH7YiYStFmjmrjdZItGosv5XHQ1PW1ZTls9K+6M 0+IDnZd3e51qy4Qv67aaonqrxpaLTXn0kWlPl20sFY47zaYVs2qvI5V3RvM6fTjsz4T99mzSp9O6 nUEV+AMB27Svy2FftDq0s1lz3qVL+ryTPt+CxZPvcifDJpdP1bMYNau9lrR7j9kayQyHdTlTcGIw 4uuKmoKJQZd/oWtMo9M7nLagZ9WzCPZk70S+R22dDlmHA55gIOWxeVZT/uEpsJfqzLLFFPRbp2dz E87UTDQAM1udnQpMz6qiKz6vbWF2KJHtmvKb0tNj+XjY7lPnRoLufNwfXIC1m/eMJVyR8OzEYD4V juQz1slQCGzo8qLVHByOZheHIk5DwGy2px3OhfSILT4XSfeM2VPpPSs2Q8oTDk0kzDbgo9kWsGen h0eDUXPAq7IHM5oRbajLkcrqkuG51Jh9cSkZTKTj+QWNyWIIxmbci8Flmy2aTqx4V9QrcY1pIWEy ZGJjGqfbN2sOzGSnk+ZEatKxvDwxnU8kwuCDmUzqgCahHvVn5k1h34jPEVyFmaajeVfeHlqOWvMG bzQfNNscPkPQHLT4TK6A1+zN+zPxxUTSNGTSpvwTK0HV4FhXJDKTXrWEvQ6fNTRjDXissdSs1qxK tE9odEMxU8TpMXsn/Y6Ia9jq1iTT6W7XtEFpXp1LWJYj3ui0WesCMQmsLM6spAwro9YetXklsmqD 9YqrMnMWZyYanepxgB+bi+R7hsd89gVLfm7BZzHMJCw9q44ZszZq1SXtM7ORhNlj8Vq95pBFFXLm 45q41aMeW5lxRQLu9ER41hIJpdTBUZXXDUbVHoiqhgPxkUl7yuUIe3We1eiw17qw12ZOz8ctGYNH O5dPjKY1cZN73r4yO5+cSWSHfHlHXGOL+EKJnK0nMgN7wW9PZcdGAh69ye9ejgRsy4NBr23C35WP mzIrw4HZPYExVdRtSu+J+2eXQ1bvQiJrcpsD2ZWIA04hvqjJFs5OR1L+WEAbj0VCHt/KtGkwETDr vb5Ij9kXWbJo0qNupyfuWAWJ9tlTntHEisne44g5XF3xUftMYqZr1TG2rLflZ1XevEkVBu0DPvHi YDCun7SYlxwBz5J9zDHi15rsJn8G1KnH6g+6rEnV4t6Y06c1B116c8rg9ZoSi3ZnOuWzuuzB1dB0 0mlzuKaj+eFQfsm6al9MZLOLpnBmccIaHPVYIwsB0A/BnrnpRH5ucSyb0sesrtWoNjRnGzVYo9Ow T2dsFnvepHdrM6GJ5S5tXJPyR6zmPQFnXD0Ma21zdIWDo1GNKeCJxsxzq/aAPz6Z8w35ZlyWlVx2 JjK6YAe5j0QdC7qJ0Z7UYKjLGfP1dPsd2UWvfzYadi53BdTB+ZGVOXUgqIYzyWy3OzvbZR/TTSS1 s3qXPRGMjEa0o8v+ZVd+Vp/wD+cSmrjGvzLbN/b79kt3ZO9ih58qM1/+kv23N52SSDvWXnnidunr D9z76QtMOziKq/5+mf+PD7zw3peXLtxlannhs3/OPLiv5qb6XeKVq96Nv5P924sPBpv+vveaI9Xq jk/uZbQp+0XGr2u/uPuK997pOPbs+aeld7Df4d28+unAC6d+p7+553xl8Q3/lf/tqQ36E3/sfnHn 5KObnDsedl31xu0Xru+54r5vrB4dL3k8a2x7/RbUVsm9q9XBS+2+6u/XBY4RUt1jT//yLw89m+ep T/xjMvlbKetzFefNXBH9/U2/vvTE/LXCN964bWP955pfeE413erp6L+79tSOGx/uLXpd/Z6ueVfp 77/1pcwXpPftP5aMvvu6fPDRhz7/5QsmSr58w5/1Q75vfHXf9ROtv3v3ibRp/QefUb/2w6q165VV rEse+uO1r+1qnln7XhWq/I7sCv3Pv/+9Jy8895J36/R1V5w4+az9F8alwPppxhuLl7d++dt/+MQi bZTR9OhqTeYnbbsP3jPzt4MP3NWyQUbGOr7D58jvNlX+YVNz/svv+u5V9F9q7ah+9uRbv/Wpl7yL 79yU2/fyqZLw2z/NPn/9xe8Eul687pLPGiVF+udCpSnDNa21s298P3HbxKP//eTRT4k/tTt77h4b b6Bm11Vyh/OVd67h+2m35D0n9r34/LnHz7lV8PDu9K6bjzaMDtZen4so5LdkPv9d46G//PeG9G/3 Tx1YM+zSyXd2f0F+0453i+/+R07891v/Vnh3RH13kUSYRr1hot7g+lESpdBelEUxNH/m7f1mkvq/ ln++1pG6fR01txtL2D8M4JIAHni2FX8pgI0mHn4PSKsKsaQQ8wsxor6NRhUdZOKDDPwX0zBBvcv6 MwFjQEcJ6r8G1vAmWgPocYIF/d8P0P0AEehLBPVQ0EUEgodKWegqgK8C+GKCDikLMdEslMxCySyU zEIJDZ0HuRHo4bwCxWHIUb0OF3IqyA1ATlXIKaE3JeSUhZyYYB3GLOMj+BXswf6HSsRP7CkWP4oH sQdNIDFWH75sWPwYvhNJEA9fVYg/YSyW8H4p4b0o4V0l4V0k4T2Gr0QjgMgWYmwsHuG9MMKzjPAG Rng7RnjfxDtRCyBIY3kL71stvPUW3ldbeBe08JZaeB0t0PoQcgP6q4X4GqPEzXvHzfuum3eDm3ep m7fq5k26eVI3b0LEaxTxakW8dXzhwyVXlxwsQWwAHzzIu/oglL31gFopNq3jvz+kFbcr9OJ1fMXh gAKSTx4O3Cs2VeBLUCsNw4wuRq0ElV6ArIV0BasK6TJWFfD5w8pWaLZwuP+LkOw53H8C2JFBnQXk 9GHtCSjtORw4V2xiY+02TQ2ysqi043D/5wHddljxA7FJgJtRJ26C4kakLaBlSFuo3rCdMg4H5FCd /iAMdLN1HePD4o396wR+WPye0i9+u3OdBiVvda6zIPlN6zpx72Hxy0pIjFXiXyjPFf+83y0+BhSe DJwQP67Mih9RFBrcbX2Uoo7uwip8k5Er/ory8+I7lFeIb+8voG/VFuhdFygk17ZC4cPiK4DMQuc6 Dh0Wz2upHrjiDFCcVgyK41B8k7FE3KnoFo8qvyn2KefFw1s9uayFxKl8pDCdvxt5pjqxSVkn7uv/ gXinFWZyWGygmh8Wd211ruksTE/dPyRuh+nRHha3BdTiBugSGzvEwRTzPGaQ2c3UMVVMObOJWc+s Y5azSll8VjGriMVhsVgMFo0FcssqX9/8tbGd2trlDD6VUB91YUQrwHyCiomt94QEZhEgWtSv89fw ZyqXBoQDpf0Cg936MdHu7bj94666tesGR8Nr99RF1jQUsFkXGVzTUX82cQT/Hr9isx7Br1JJBPJS /Hubv1AutUYiwsG1oZHwOn7VNrUOiKnYmpFCvgoFa8YYVBhcCxXooFYosh5BASoBOoQetVJ0QGT1 hWpXbFVTAhWoZqUSqtoJpCxUUxInCtV+QFU7tL/VZj3U2lqoQu9E+wtV9tM7qSrA8K2Rq6Cp9ZBS WajFWcOqwrhVnLUCoboCIa0WqvRrqSqHNFqocEirKaCVH6AVW2j/FtpfQO/6AN25hb51C30roD+W x/+LK2n+z+o9sOvmS26h/v1jt8yWhGf32pVLaeHaxRMSyaFLbt7+WxD57ol4mkpjybWbZUnr2iUy q+TQrls+Bn0Lhd4lsx5Ct9gC4UO3GJPWw7uMuwp/GvLAZZ/ZY/tQX1e839eez3wMsc9QxPZQfV1m +xi0jUJfRvVlo/qyUX1dZrys0Bc1N9vUqHnhY67FvXvPXVg4d+sTauqdOYEY6AJQgQyc3jZvBJRz AU8iDqKDHeEiFtShQ45NfaCGuAIuKkJFYi7iQeCC/SyGWiUQmIVPa2hgWwUAi1AZ0KiDwET1ELig gcSlXLAYEoClSFrPRTLUAHAfaoR++1E/YAcgUL9YNALWgkwAjyMrYM9F5wL2PAhctBvtBmwMAhdd AkYJoU9A4KJL0SdhnPvRZQBfAQFsJDoA8OfQQYCp/43ios9DoKNr0DUwi2vRtTCL6yDQ0fUQELoJ 3QB1boaA0C0QuOg29AWAv4JuB/hOCAjdhb4K8N3obqBwD7oHKNwLgYu+BoGJDqH7oM4RdBhKvoke AfhRCEz0LQh09Bh6DFo9jh6HVt9GRwH7FHoCan4HAh39DD0NJb9BL0DJ79FvAf4DBC76E/ojwH+G QEd/gcBFf0d/Bd6+jd4E+B0IdFyL/hsWtA6LEBcrcD3AnbgDYBVWAqzBaoB7wDwhvAMbALaBDUbY ge0AZ7AT4CyYazq+AOeg5Bt4H5QcwesAfxPDLPC38KMAP44fA/jH+CjAP8E/Afg5/BziEhr8PAiO ltAKuEQX0SXmEjpCB7Ce0APcTXQD3EP0AGwgDADvIHYAvJPYCXAv0QtwH9EHcD/RD7CRGABqdgJW n7yTcICwfpUEnpN3kXcBfA95N8BfI+8F+D7qV8fkYfLrAD9MPgDwj8hvAPwT8scAv0Q+B/AfyZcR l34b+RpC9NvptyP65mbhX+jQ/wNvZ3DgCmVuZHN0cmVhbQplbmRvYmoKMTQ3OSAwIG9iago8PC9U eXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1RpbWVzLVJvbWFuCi9GbGFncyA2Ci9Bc2Nl bnQgNzUwCi9EZXNjZW50IDI1MAovU3RlbVYgMTA4Ljg4NjcxOQovQ2FwSGVpZ2h0IDY2MS42MjEw OQovSXRhbGljQW5nbGUgMAovRm9udEJCb3ggWy0yMDMuMTI1IC00MjguMjIyNjYgMTcwMC4xOTUz IDEyNzEuNDg0MzhdCi9Gb250RmlsZTIgMTQ3OCAwIFI+PgplbmRvYmoKMTQ4MCAwIG9iago8PC9U eXBlIC9Gb250Ci9Gb250RGVzY3JpcHRvciAxNDc5IDAgUgovQmFzZUZvbnQgL1RpbWVzLVJvbWFu Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovQ0lEU3lzdGVt SW5mbyA8PC9SZWdpc3RyeSAoQWRvYmUpCi9PcmRlcmluZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50 IDA+PgovVyBbMCBbNzIyLjE2Nzk3IDAgMCAyNTBdIDE2IFszMzMuMDA3ODEgMjUwIDI3Ny44MzIw M10gMTkgMjQgNTAwIDI5IFsyNzcuODMyMDNdIDM5IFs3MjIuMTY3OTddIDY4IDcwIDQ0My44NDc2 NiA3MSBbNTAwIDQ0My44NDc2NiAzMzMuMDA3ODEgNTAwIDUwMCAyNzcuODMyMDMgMCA1MDAgMjc3 LjgzMjAzIDc3Ny44MzIwMyAwIDUwMCA1MDAgMCAzMzMuMDA3ODEgMzg5LjE2MDE2IDI3Ny44MzIw MyAwIDAgMCA1MDAgNTAwXV0KL0RXIDA+PgplbmRvYmoKMTQ4MSAwIG9iago8PC9GaWx0ZXIgL0Zs YXRlRGVjb2RlCi9MZW5ndGggMzA2Pj4gc3RyZWFtCnicXZHbasMwDIbv/RS67C5KDm3SXoRADyvk YgeW9QFSW+kMi2Mc9yJvP1vqOpghMd8v/bKQkkNzbIz2kLy7UbbooddGOZzGm5MIF7xqI7IclJb+ TvSXQ2dFEsztPHkcGtOPoqoAko8QnbybYbFT4wWfRPLmFDptrrA4H9rA7c3abxzQeEhFXYPCPlR6 6exrNyAkZFs2KsS1n5fB85fxOVuEnDjjbuSocLKdRNeZK4oqDaeG6hROLdCof/GCXZdefnWOslch O03ztI6UbYlWBdORaUeUb4jWa6JwRSozeuVer/yt/mgmSyktK/mVI3uZ1gcusWLxmahgQ7knschZ 5CbLE4sFi9zPJmdxzyLX3GzvbXEjcQ5xX48hy5tzYb60VBpsHKk2+Ni7HW10xe8H+TmcNQplbmRz dHJlYW0KZW5kb2JqCjQgMCBvYmoKPDwvVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTAKL0Jhc2VG b250IC9UaW1lcy1Sb21hbgovRW5jb2RpbmcgL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cyBb MTQ4MCAwIFJdCi9Ub1VuaWNvZGUgMTQ4MSAwIFI+PgplbmRvYmoKMTQ4MiAwIG9iago8PC9MZW5n dGgxIDIyOTgwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggMTUzNjM+PiBzdHJlYW0KeJzd vAl4m8W1Nz7zal9sS963WJvlRZaj3UvixNoX25It2VqJIbJkS7Isr4plu0ADJdAklEBZL6VshVy2 FMcJwQHK0rKWcEshQNsLbW8JlPLVtOWytAXb//NKJgRK8/Trc3uf7/m/o3nPmeWd+c2ZM2fOvLKF MEKoCG5UpOztV6gPuNarEMIdkLtzaGZsnHod0wbpmyBtj6TCkxQ55RZIn4L0+ZHZtPD7z/3bzxAi diJEE49EZyL6imQLQoxLoFw5MhxOIxpRA+mjkK4emYylLO1Dv4H0iwjR342NzY88fEHgCEK8Piiu jEdTc/uv7xxHSD6GEIcZHw5H3xl+OATl5fB8SxwyCsc4doRa05CujafSc6nvU9+H9A2A4ejYRCT8 n4438xHKfwQw7kiF5yaZq+wTCG3pgfrC1HA63JU6CPi2QPuF28fDqWH0DvVHCPXcB+WVkxMz6fWv of2QfpasPzk9PFn3/n1Qt+cdhFivTE5PTD6x9tafEPI9jhCFCp/fEo8gGvT9CLEPnrg8R/EbqI8o hDRikjeCvCEKOuOanJ+eQXokRLfS0Rqk2TsoRiHCt/TCRFDup8XJ3iHiz+oTPyR+SNuDX0b/7IU3 EHBhnieBliMepJnQy2akRjrUgSwoASVpNIduXV/P9t+MVBslYZRE07mS9Tf/NkCr+O91DGOphiiA WE65H1UitP4axDfJuBZaX6WlkGjt+fVfUFQAsjkX4dKiUXQJ9P8ioDwBEr4TLSEjtkD+k6CtIig5 F50HWmrBAZQHrUbQH7EfjaBD6A9oP8FGKaSH2s1IA+1VIy96BolQYn0NOdAs2oeuQHdBmRtdsf7i +q+hNxX0NoEuRQdwDfCH0HH0Bh5bfwYJkBGNo3vRa3j7+l1ZqVUiE7UJUGxFZtSFnNByCJ2HotDi 7eh76Kd4fv3S9WdghAzoTwnSi6CD6BiM4BOswfMUI+VGKDFCeAm9gvOxcb1//cj6c9BPA2qHtoLo cghXohvQHehBtILWsAK78aH15Pr0+oNICn3F0UXom+h69F30I/QX3ISbCTUxQdxPri6kgEC27QM0 NwGeJ9EvMBtzsQ+P43l8FH9MBCnH1ifXbwaNlMKst8PIfoB+iJ5DP0W/g5psXI2NOIWfIQ5RiihX U26mzdK+vy5ZfwfwmZAHzYCE9qL7of7P0BvoTfQx+jOMoRxXYgFWYi3W4W4cgnAQ309QiD3EQeIQ sUJhUr5LeYrKXXtz/ZfrH4FU6lBTVq9MIEEL6oExkxKchnA9yOoH6AmYq+dAYq+g1yG8hd7DVFyE S6GnKuhHhGtxI7ZB6IZxBfA0vh3Cr/DvCBgUQRBHKQ7KVVRE3UPT0ubXxeva9VYI/wFjoIDky0BK OrQNbc/O3A6QZjyr2d9Ae9BlINcr0C0wi0fRU4DgD+hP6H30AfoEfYopmIYZgIAHEpLgBpgVJW6B 0Ir12AFIunEPzJMX+wFRCJ+Ho3g3vgp/Gz8I4VH8Q/wM/g3+HX4ff5JFSSM4MGsOwk30ExcQ10NY Il6m1FPep9ZQm6h66i+op2iVtFZaiHYt7V46i/HA6u/XDq0dXaeu96xfsX7z+svr7yI2KkQa5IJV MARjmIAxpNFudABdDeF6CLeALP8dNPkY6NHjMMfPQHgewgn0nyDVX8HsnYLwf0DHVmCMf4bxsUHG uUDOaGV2RtvxdmyG0fVDCOAR0I1JnMEXQLgC34hvAcnfge8CzToKYzwz/AT/GsLb+B0Y9Qf4Exh3 MaGA0JMd8znE14ndEPYQ14GGHCKegvAxpYSipngp51DmKTdQ7qLcTXme8i7M4wh1H/Vm6qPUn9IQ TUCz0yK0edpltO/Q7qedoL1M+x29ln6IcYBxNeN3MCs+mJv2L5mfItCwW9EjKE7MEkfBItSA/RtF 9+M0+ivBhFFlcBHM9TxITwGrfhBfiHiEkrgGy2GOvkfrplwPOnEt2IpWWLFvwNpyoKtg5byGrPhJ wofeQZvAkhWtr6Dy9XdpaVoaJrcbbYJYDk8Wbdi5FYjvrhnBFkLZ2g/WX6XAjoguBvsgy4bP7Dwt E4unERaiTDQdJylsv+Q+hyYmZxbAxqLx8NhItjY+Y2/IpWB/xKBamKKvr5PWSsQioaBmU3VVZUV5 WWlJcVEhn1eQn8flsFlMBp1GpRAYyS0S607hYt3ORWqdxG5vJtOSMGSEz8jYuSiELOsX6ywKd2ar Cb9YUw81R75UU5+rqT9dE/OEHaijWS60SISLL5glwmUccgeA/5ZZEhQurmR5Z5a/MsvnAS8SwQNC S3ncLFzEO4WWRetsfJ9lpxmaO64nd89mOUwe7KccsuFFZApfEC8HQtawLFZKzJbFCok5W0aRWsLR xT53wGKuEomCzfJFbIpIhhaRxLhY0LTxOPmcEKp6AtB3szxB4kf7uVFJdP+yHg3tJLnwjsAiJRxc JHaSffCbFssk5sWyhbfKP09+xlkuP6NwkZBaw8P7rCCa/fZccieZCl8Oqe5+ITRL7AkGFvGeYA5E FntuFMMSC5mzc1S4yJIYJfF9oztB5sgTWKrUV1okYXNwEfUFlir0FdlEs/x4+YVbRSCU482GZgNJ t4rKL8zR334jl//S45xsvSd/DbTbc1oumOxJ4gCYi8JIthMJYG0jb8NtaF+kDarBFcQwysQiy7Rz H28LPLVIk/Ikwn0fIpgoycrvv5gT3sihS3kfIpIlp/O0RkD5Br+M6uXdy4jVFziM8RXBZby+ZxmZ Nx1HLEQ571wobiDVIWGGpyHRKIcMmQg4mVxoBdRWct6E+4T7HNF9QqswDhNOlWYpFAzvCypgOP2B BNwHAqJFfbDqNDscDG6BdprIdqjZdvYFoYXRjRZGsy1AA6tQSS7vBhHV9QXcgcXd5qpFvTkIIgH9 ebwvsPg4SDEYhFrNp5ECvSBRvoF5M2BulgGjyLXSD21AE8F9+3IpiWjx8X37qvaR6yCXXsboyxn6 jYxllG0AVGUZ7+7LFu2WiKrIDIlIIgJYQTN0pQT1+mx6l5Hq7BJWnylhDaBVZyWs/R+SsO4fkXDL PyTh1q+WcBtgbiUl3P6/J+EtX5Dw1rNLuONMCW8DtB1ZCW//H5Jw5z8iYf0/JGHDV0vYCJgNpIRN /3sSNp8h4Y1zwtmDGy1kw2vgqZHh+BfCB18O4JH8U4Gyg/IqdZD6V9oU7S36G4wFxuuM15nzzMdZ L7LH2T/nXAThL9wn8mpzIT/v//3wmX/xYvkbtPMKOj7E/OxZFt1+yXNZ+vP+g8a1zZ8+mr+VvQPq sk77I+TZAtHz4bxHetwGfTWNLgB3g8oQUBCbRhVQKEQli84QYFTBZC0Tm4+IYn3lTU2uDzqcqx0u 3kcdTt5qB+rsWO0go0qp4Yv49RCltN8988mdtPhfb3iG8otP66C/ED6X6Ca6oR+BHlYVrqShCipt GWuOiMajZJOneG8jhfMFlbJIVCIK4T+tFRDdK6TH9L31N/Eq3oY4qE5fRCiZnLyyskqaklPBzfvz xrMfOFddlmHz26jTuaJSbscaNfhRdIm4Tve9Ybt9mIw/G85xZIuXwPF6L203Kka79NyD3GPcp7mv cD/m0iiGQjwIFdioGD+HalEBHgS+CHgJ4sKdio8hDmY/cIB7C5fgLuMf6wsKqBRKcT6tiPsYOOP5 Bcs4eYyySMXU0hLFiZODIJMTg6izs7Cs/cPBlU/xh01NKiUabFW36PjaOomYQWfopBp+cammRLT3 poBEUaEVtRO0Wvs1q0jlzVBKevR8dqn2V59MTfaRR27AgSgvAfIalNKX7uVhBh+XlYpgHjEDVVuR sAyXLWOxnlvD5TJeLqARpeCVL2OpvqDQpq/aJKoW6jkiLhIKANzJyhcqea9XPnmicvZk+Qq/sL0d da4+2bk62A5pSDJovMqf4Q4SLx5sRa0tug3Eks/ky8AlInVLq4YikmBb5IZdXxvrahC0mf943RXv pC5aexZLbhhUqHZ8ekiBh/a/dPvOf+9utLzywlOPRV/62tqrfHVqzU2OqHl9hfJD0L8adLm+gMmu YldxKEX6YlFBAa+AHAr7/mJcbCumFRUWLePIA3welbgC1MarL6vKKyouhFoOcg5qmIvMx5kvMinM ZRw4Uv7tQv4yETkirCGH+ipvbduT5c4PVgb5MBHls4rybSfKcwNeWSH1FvhZxWD5SnbIlTBkPJgd o0ZNDrqeDEUiiohRWkblFyNSrZrNW7r+anHPXjoQmu763jPE1YHVZ5rfuwaXrh395Ot3v2Y/Mh2O 7KtrLOJyiB+tfXKQsT299rOfrf0u6oERU9ffpO6l2hAdOfV8gkIRFFJpVAJjQSEsRbRM7Fgi6DQg +gIblUPQqRRMQUw6jcmASevgnSzrKATgs5++3v5pOYPXxKN18KgMkuASFi7BOure1SJi5ZOvUW2/ WVtcWzpFcF3kOgcloYlol6F61ICe0jfEC+YKLqm9tvZgLa213lbvr4/Vz9bTOIjWUIWCYnpDFSco QRW4Ypk454GS5gI4YwKn19XUiPl5fAWHECvqELOB0tBQR9PnV4ny8iqk+qryKlFFhVSgl1aJ6m+p w+fVTdQdqKPULROxo7JiwTYYVHRJZmtUzJ4o/3S1g/fR4OCJ8sptK+WVMAGKym2rHZXlG1wuC1bO id93/v4EyV+wMri6MgiLHfOyE4QGNbqWVnIdwezoRHzJZiwR00v4paCQ2QS5qrLaiUUBaftWcZB6 k7r+4Y/P1dx/vkirLb3sflP8yT/vbO9ffU9LKREGKL8KCYpo2rXI09+u37JWR3zj+6s99x9Y4xkU N/x0zQeCA8ulXX+T8g7lObBEemRAz+rTjs5E540ld2+/u5NWKimpr97emFcvqa+tq2/c3tjZjfeq v6O8F9+jvGf7PZ3H8QMNDykf2v5Q55MNzytfaig3MG7S4/ZtVEFhPlVUkI/zu/I5hYVSKYPjUOm2 cQwGsYynwiqVSdZeIKbIeDK8W3aljJAtE2F9vomp11eLJ/Q/0f9KT9EvE0OHTUbFiY8GT77BW+V9 MDi1eupFUmhT5TkxdoDCr3SubOh55QvAwGewM7e4a1tbWvl0Br0EJCbH0uw6JxMCXIM3zKi2RaOG s+mGTMugskQMcs/SOh3G/91ULvJsT2yrW5sh30w5h1ptTCY3n+/UbO3/5e3f35Uuy+cWFQs6HJs1 58jKOd6koXPg2/j4rprCOtxU3OSYMllO3u659hx/o4DLY+XzG8u2dFqNs/tM5mNrvFIBq7jJWl2o q9nqlZQmpyhs0GcJrCIZ2I08sImX6O1eprd4b8mxsqeLny55tuyt4g+LWaLi2vKmTSPMkeKRkkzx 9cVMngQLJDWSrZLqTXmCgmoWRVAkQayBIgZFWlPBoesPgAkHq6FnSfPzZDV6ARYsEzsPS2sVJz4g LTno6wqIEuTYmRVfOyZvTXgwp461ZRv2ghReBQG6qVEXlmTNRT1DAua+XoePFNYOJPzOSWOvsrHb f+jltf9+1nNh622bNnceqLX+8vnb3gmXrL5NvW11RVHetPb+U2trK3ptmvqGvpmlJtewbP2/KKOg f1JUh67Xe+tKmoSNtRQfPyQMiXwSX+2ocFT0SMlDwqeKnxP+VcItrvaJzpGMiA4W07giXMeorCpl 5vHup2EarZTHA00rdQg4dXWEmEZjEwZ9pegPVbgKBHCsoUg/IcZiUq0a6km1WoGxVz5X+cEb7dsU GyqVUyfFIIgAPqQmTQ2SyoRyO289qTM6WJtZVSrUqFs/UxtCp0UaCXHVD7q31G9qJSoqRef13XCR u12sroteaut76q+Y9cZmynMXRnSuQuEAS1LcUlz808seX/u0tqRNsl9bhSuffxU3gzRgNVLNoAH5 qAkt6buaeYpGooRWUlRS7ETnIB8jmOfjBRuDshFmgjvCSzQmZAuNN6N/a7xT/KD4Gd7T4tfEb4vf bfxY/EljFa8Sl0pqKndLqiWCGuEyztfXSQTV5JsXqqS0trqEimn0/FJ+JaIP8Bn5Aw0NEo7ka6Wy qmpYjEea2fomUlTNchAVSKpj9S1QE95nelJG6klZO+9FxPsQXICsvmRX3WkfoKQYVAcVkiusLKsn IlhnZSX5mKHbWGCENRHqStWXFEsTa8rf3u7urN/acS4+rrTeF71wi7IncN0v/bPl+P2Koevd19zc dxXhxxUN5dtxximlqj8Z0avoCj5fclnHps1rvyDt2GawYxHQo0rYFcQoo+8sLZZiWbkXebGPEswL lgcq4hUPF3IKYdMF425jsdn5NTVSgpHvKOOIGWJxJatqhSUuKML3F/2hiCgCnXmgViRm6ytJOdRK QA6rp0Blpj5Y2TDjG9oCq4hcN7znSBFUklssDLm0RFRKrp3TGlLLl2aNOaNo8yeHh5eUtfmM1Y8Y oo7r7fr6LYrzLnAnrl/7M6EktK6+rdRvET/EtNFzbVO66q+F7m6u0m+6aVv9e5g29sCVB2/Bl8F+ Ww1DrqZdAvteRt/6NBsz2SxOObuCs4VNQw28BqIOUVpRTcPWWoqE1lBWVSisknKxiDYpFDDo9IZ6 NlheMLrDelZJQU1BjUTGpBwndqJGxaekdwej+hQ8PHB/O0gneIV3wX+U87PWoYnX8ZlpaN2OdXyJ TqPTkkah9LRN3TAWfE2JJDvjourO1tnZZu9bC3fbtqqszbUl6palpW2J1WdUtM0O4sZQz4Ed902c 027VN4u7mRX5W3aufRxa3T+qZKgQFSnW/JSXYVa5qAoNIC/6i/5gQVV+NXcTp4neipyCqprq6k1V TaWtPOcebZ61wdfg7xpumG24tOlS+eWte9uuaTjY9D3tPa33tB3VHm/9M+N9baFGqCwvcNgFNVRr malzO8VSV0/ZcksZ7izDijJcAN7milVsoUi3KFlb+ppZ0mZGgbSvwMvwelvqBYSMLiy6EtSjx9rT 4qc/vrMFt/gNh2wSsazqogED9/FbZYuwn/l9iidfHVz5APat2dVyF6/85GC5M7dVlb+R9dj4Gyq0 CpmgRCsX/LL81MogXKSYyXKIhe3nK7ZVvpBbWuhMU0xkVYtMiMg9rq6lVVeXtU6tus04u7GVlolK JORWl11sktxOWFaDNVnlLM7tdbDJhYprvM4t27rcLZnLdk937e+Nry0K8yuOOkIdVcrr7fHdv37M PifC+Qcbmh7ceUBQVFQjEotrCoaq9kw5r349vXhl/D78IsFoD1128b4LL7vo02F7ofgcna6yUCSt GczPLytvsvsWyvNlN01cfqy6IFUf3/a4rY6gVVXXC8RUgkIQgo7vPNtdX62Yoh4DvQaPLmv/GtDj +oUSTomQ4JRyyghWKauMXkevryitKCutK61vLG0sC5WGyhKlibJ4Xbz+30r/rezu0rvLjpceLyvl MQUlVfWU0vpKSVHZ6YVAldQwt0r4rTUlLRJRpQQin02hCxqoeUw4O2CBI4/RUF9awq6qlPHAzw4f k7HEEhmVQm6XskbYLjvI5d+RPRl2wKIY/NwQtjc1NSFeR8fJ7OaZXR9TGwskZ/lyh4vcctBls3N7 SC5H1KaTG/Dlnfv9szcqWtcErQ355TbdVEPrWpGKobBSi7apmOrVx3v69965Vmxp4qpUnDoT/qNV 0jlUuPq6qY6j2vCFCRa4dBywDTF9G69EUEXkcXmt3Jrqllq+hBx2maSmakpSxudRSqo7mVjBxEw9 gUvo1VVsml7IwRwxrwZGfrS0TMbnkfZgkwJG3XEKnC/SSQB1HczqLgyXd5K0A4VnrHxKznE9belF Xxs0GgYHDcbBUEtxjWw73gsDKqfJBgeNRoifOFiFVVYitL2Zo/70o+wgcrPfDbO/Gd2ln/tm+Wts opRZWVcqL21uFDQK66WNdfXy+uYWaUtdi7yl2Sq11lnl1uYR6UjdsHy4eZ9kb+018muan6n4bUX1 dXXX1RMN5Q31dZUV5Rw2sxgxapiIX1xTSJcLN1FQTc1mdjmnglLUUARVKA0HanCNkt3QKMtOuFKh OLG22tHBe3WKX9Z+khw0+UKgrKMT7OEqmWSeaQZzo8bAZrkSWG0FGBzNjemGTAqjJDfXLc2ydrwb U8uKW434wU6pcfst+HJuaeGaWN7IF/2wWWxdK1flNZmpRYaGPPWnV2BaWSNXUExXKJj5ldtvW/0V n0NRqYjCIrZEgYvU71g2szYkB7MfRwVoQN9AZ3AxglWQT5C6X9CS1f0WCbu1Jh/ucLAsYKKCfDap 5UdZbNBxcq552bl+m5xnGJ4T5pg2iLbxTj7JO6lSnjHKM4ZxibztTLCfWMyy/OyJHtDQL6Y8g0x4 SP/YcdFx8UPqhzTUe0X3iu9V36uhLogWxAvqBc1+0X7xfvV+zY2iG8U3qm/UcBv5jaJGcaO6UWM1 WI2jolHxqHpUw2GJWGKWmqWhtuS1lNryrKWmrX7+U9ynSl7hvlLyylZOSBQSh9QhDZXHEggJkVLa rDa2bMcGjVJMRVQQgWlrLU1SwwInWVIjbJF0bC8qbm7Z3tHSLK3m0KisYpNwC97iKCgeETbiRkd5 eQGDRTcZ1SqRkG0hjyYVVdWyOjuSCqXEohQrpEqpXnpAequUJl3GtfpKu7xZ1mpHLcIWYrEFK1qU LfqWAy23ttBaoPiYnS3eLqNRSRmbSRmfmoUz4tQsCPs0cyprU8CqdJLvngbf5uVO9VlzsmFdyjq2 5czLaRMDm8IUuWG0fr7wSrIOOlh4TUtuUz7T5Jxhcf4mQ9RWIt5swJdolMHU18x14vwtuoHI2J2b t6xVtskVRt0uWLuils1yS+dYXdtaqYrBr3IQIf1mpvpqk9S0RdRtq92679rVVVs9XaVi1lvwH/sC 4aKccVIx6q34j65QLG/DWBE5Kw+7egNqRI/oF4qEOK80r4xSR6mv4FSXVpeR5t2fHywNlo3kj5WO lV2XTxr4+0rvK3uk9JGy50qfKyvnlnLLCNLSE/Wlksq/MfNZeycRg42nUhgNG/adSc9a+EZGYyOf ctrON31u55tkihOfknZ+LfcChdyis9MC85Eze08+edrGT31h9Zf8HRvPyOVgMPJNRnyJ6vodl1z1 uZEPlpNWnigj7TzYQiXIsyv8zXvX+JYGxudm3lmfkxxIjIKa4bz0XPa8XgG+7qze1oilFCmjkUW9 p+xd6lv0t9h/oX5E/4jNgCNi6Xz+PG+2eLaU7meP5id4lAAKUP10Sgm4vQVSJqeSUVlJ4/gKcaGe Rp6RqoMVuELPIR3e6irY8lYGeR+RqviZu0t6InDhwUKkUaPsORDpqJ87JuBkFDVjxjPPY8o6+o9n 1/6Km0sl8ch2w3lxSdltxL24Zu31F19Y+zkWvPKab8+Jt996YU/wJP6AfGO7FqKS48sD2/+E/sLi SsmmJtE5XO8mb83TFU9XPSt6RfjWprdq3hS+K/pgUwF9E2Zsqq9sr7RXBiqHaSObRmoupd3EuW7T dTVcOFk38zZT+JL8ms1bawslNaVbJY2tNc27JY3kl880Sj2/Uby5rryQw6Tl0QeqGaX0vAExZ3Nz vp+CKfoD2RNyRM9WlonrZYV6PuZ/tiGQB2byBLCS9Y1XQCL8ss/OzFnt2HCNp8iXD7rTy0uDP1eS jWVZTGTfNJSQDhkoB/F0fYl+yAiCWv0Po7JZjy+TNdgnb3vlrTsGuhuaMGZY3Ksveq9237D403Tl Wn7NeWstDIWBSiOP0JdZRVve/+Ov1v5TVak8tI/v7qDJSAsshfNBBCywEF2u75fwtnAP8o7xnua9 ynub9xGPSeNigYAnJIQsigTVCD+zjlWzNYKHJBWlJRR+FaVKWMGhUcqK9TzwiB35YBGFAja/UswW V4E1A5noWTvFu8UviilikeLEYNY9envDS8gK5gy58Do2zoewXjrxFxZM1nn43BBJt24mCPCG9hh2 D3QO29oN5xU19m8NrP5SxZB1dBDNpMm5zRt1uzpcC8Pnrl0womFmvR84NxPkW6x2tAW9qZeVFFY2 +zjXcY/Kn5a/Lf9QzszjE/LGQmnzCOfZ/Kfrn254uvHVRvaVIKhl/Jsj7Uf0umXMekC0+RbyZQFO HKk8oi+FHH2/qEjKJqgCaRGDKt3M2cLYsqWSx2VQxARbKmboK2oqj1TXiOxV222/Z2DGxahpd9OV TZSmDn1bTTuuEbWLkfhNMRZffCtvkfc470UeldexVXECTgaDH5yq3LbCW6ks55Gp2Q9mIflB7q1h +9QZB0w4ZFf+vhJWItqgOdNfpAFXXp19GaHAOdc/925340WhOHsAF+Css0+KWIFzx08J1rbX3OHr 7WooVd0wp9UdvNbw7cKKEkazdtMlAbOpZpN7Mq7su/POxv5tkiIWg1/BU+Egbrl63raltb6kvGur xXJu5lBTSdHaz+IX9shra6X1LWpF367pp/glXAZRJaS8nfUA1t8ibqaxUA2K6gWcalxiK+Fz9FjE QZNMFl1fLeI7KjhCfbGoxMZZBpvD1TNEzDzZJgRFNeRWKVB8Wvls5Qmww5XbXiivPDX7OiSfRJ0r QDpPkLknssKaVZACKSJfm7aSg88eO8u+8EZPxxdVNegUgz3aH/0or3hzQ0uVqlYd+Lq9JU7xtleI VdqRXWsHQ6s3NG1qbleXD+gGq7R7iRvIUZTBKvol5X60FRA+yCziCFmiNjqVKqSK8BaLyCb2cX15 ofpQQ5Qbzdsjvrvi7soTFScqeUV8cXGxrVAoEvLFFHqRSCQUi/l0Cl2tVSsUDJGYr1UL1QqGVmsr pFDooqKiYvG1ijsUhEJWKOaL1VCTcS3/Tj7BlxUyFAxhMYNfJKJoFWK6mstGeRXVFHZNVSWXQ8ft DVLwZOu2bqln58rp0q256vQqTlXdNs7WbR2gbid5r2Zd2A03toN0ZLedLN/gyNzL8jc3DfKYHR2M zbSmwXLeZR0dkJXfxGOepJ1kMJ9kQFnu3sFggibToOTJ0w4w+QH1Ihd1Pib93DMdYQblDEcYjB7U 2ziMloiqNY5uwYho7S/COimBbOWJhhG1qg0H6io2i36KlZyqsrWiJnUJt6qgrcwgNGk0awcVTPU5 dd+U4atV5TS1ms0qKrtFu9teXsMj1GoGu7hxbW2tmc9nKRQEr5JfVyYrc0v6m8+tEhYTity3gzyI iywG47O/it24KJCi0hD5p7TZv4T6LJ/+9/+iFdFoVBqVQqNREI3CoNFoiEqlnPns/9RFIDaJ9wt/ v0vipX2O9zRMxtnw0ql0wEunIDqFQafR/1V4KYjDYn4JL9kTnX4a6D+Elw4YaRR6Fi+LDk/TsnjP NiX/JF4um3V2vKdhMs+Gl0Fj0Kh0BhUxqGzQfFJB/jV489jsr8LLOA30NF7WWdphAEY6lbGBF1SM nsV7tin5J/Hmg+FC1C/jZXyO97RYz4qXSWfSaQwmFTGpXCaDCXhp/wq8VFTA5XwJL43EyzwN9DRM 9lnaYQJGBo25gZfJJBUanV2F/km8PC73K/AyvwIv52x4WQwW4GVREYvKZTFZiPGvwsvPz/sqvKzT QE+L9Wx4WYCRSWNl8eazWICXQeI9mwr9k3gLC/K/ZCfJlcL6Crzcs+FlM9lMOotNQ2xaAZvFRkwG /V+Bl4aKeAVfwktKhjQaG0BPizXvLO2wOUwOk87m0BGHzuOwORt4z6by/yTeYh7vfwQvi8M6Ey+L +S/CW1LI/yq8nNNAT6tB/lna4XBZXBaDw6UjLr2Qy+Fu4D2byv+TeEtJvF/Yh0i8nM/xnhZrwVnx srls+pl4WYx/BV46Kisq/Cq83NOC/YfwcvPYeWwGN4+B8hhFedw8xCbdkrMu0X8Sb3lR0ZfwMr+I 97Qa8M6Kl5PHYZ6Bl/Ovwkv+rVzu/77yx9Y2r23O3/o3/z91iN5OvkXIXQT6v7+Ie1AInvveZ2kw mJdAlJyRbv57z1IPfHF3+KqL5iPfI/7vXQBIS51BEsq3kAyoFuhmGGM15CsgLSLac3g+4+n3IBHJ k+MEmpUlPCOlbEJaeE70pbbL/jfH8v/HK6ujpBYfQueBcu8Bv4WA5cZDFrAe77BeASGf+V8r5L9t UKNj47ENvmsmx5P/PXl5eHJyDFoshfXRMJQYi8K63U72EAnLIzPyyLw8GpZHh+XD4/LhGflIQj4y LY/DZ5c8EZUnZuSJtHwsLU/NyFNp+fiYfBI+afn0hHwmKZ+Zlaen5bOJ8Ig8PBOGmJaHF+RDw/BJ QQQ2Jh+alg9BL9BXLHZGf+FZss/ozJA8Oj8hHx7aJR8ey0KYIFEMp+XDu7JYEmPykQkS0sguiPPy WFgei8pjY/LYTEYe27Ugj83K4+FMFjE0toE6tgF8NBWRJ8MpeRL6Sg6H5cmEPJmUJ8fgMy5PQv3k TFyezMjHhuRjMflYMjvUsV0TEOflY7Py1PC0PDUyLE/F4BOXp5Ly1PhnohiSj0fhM0MKZXxcPj4/ Lp9IySdmNiQ0tUs+nZJPj5Oimp4YkU9DOgMfkFp4Sj4zNCmfGYZPXD4Ty4pyTD4Dbc/AB0QLFaZJ 6cIY0yCRdEyeTsrTE6S002n5rqQcBj6bkM/uGpdnwsPyzIR8biImB0Eu7PpMK8h/8UU/xm60FXlI NuI2THUn4v3RlFE3ovWM+AKJyEByUhe0TToGJuOasNJnHkmlU0GtZ5db5esdUBosffPuJlMqNGKy W4eiC5m4wdTWZbCleyxz2qbgfFrtTSnVEY/L2h0Yi/bZ023dfqvV0+8NRH2ZeafS6O6bjwYNandy aMDTm7CrXJbRiWHLqC4WHI9mogZrb8DU5Yp63RMjsRAU6Hr6VJYx/6jO67bFJ3sSDmdIPRk1LLja esbd2t5EsC8Ud405PL54RJ3uccUmZk2a8OjwnHvC4/POdc9PBkyaqDNqmukJ+VT9Xb6udmi/25Ns 7/OYdDaf3ds3ZPfM+8e95qDdbe43uFx9VpfB059JdSVV00PGthmzxjobtkWHolqPOdLfZrcOeEaH vBNNPaNdbYZYNG73xZNOu2HcM590B62eKUMik+xdmPQP+RyKHntI3WWb6A3ZQqZhpTU2rMwM94yG xi3WqMZuast0zbsn4/aZgCWZ7vePdcUiKV/SajQqItYuqzUVGTb5Q33dprnZEf+MyrEQjY8o28Z9 iWTK1G+xDcUsEbclNBdVB9UDqZgmorH229SeTP941BqyT832LUxM9ia98z1j7eM9Gm9b33ho2mqL jlrd0fYedWTGFIsMeMfSYwPGLq/TG1f1pDLqkaTFabO6UgP93sjImHaXcy7YFXQr7QOBOYPbbPH1 OtI9IbXV7hwwxkxqg9tkcE44k8oJV6LdaTMEU4GAMd5lMkx4BqxTNo1O61eFYt3jvuiAxTjgCbRl RizGVq8qMhfsn4O5nuvpXdCp7eOWdNwU6RvxqkYNsYmeoTGXLRibMxnVjoWelEXVl/IO9I0aNQaj Idq94O7v9bT1BdXOGWsqORadS4eiaqUrmJkZ7R13dzncBsOQ0ZWKmpw+e3/AbjboRs3eObtlbsLu sllHo2qX1WvLRGwBhylkmJjvTTmsxvkJt3XU22/yOpVmT9tIT8YzZXKHhobHLX3ulNc2lHJao6r2 pN3X5gvGgxaLVpcIxSdmI35rwuQxOnsX3F2uQNec2a2NDluTpl4L1InrpqLJuN8Vy4SDanc6MjrX 0wdCsPZru3oWusa8Nme3M6E1BUc9sfBAOmr2pHvn1Em3ac6p6zV2tQwYI2ZLZiIzYm+fHFK6NM4F Z5MpEZy3+I12kz3Y5Uo5U36j2zaw0NZjGLdEuhLe7gG3NmNKBUfCRusu91zGO6KcSHvHdxlHlCrX iCpiGPG1hYLepMFjiaYcA1Zbj9nbZBt3NkVsTnfY73WHVG2T3QFtxDSaifvVziH7XFvA6ku3mq3W THhhsn9AqZp1BSZa+lSOGVPY1e1S+lIRa/t4V3xmqmdeFepWJv1W24Tb3q+bi9ot4b7YhNmocfZH A+3zIZVryqF0+cOqLp3Lqp0asKeng5bJYfeAbxjW4YjHPeMJpwxKlaY9HjK445EBi8VgnPOZUuno sNkRGxkPqtw2z4Q1aQ36B7pSRqt33p/yGD0qQ18wHjNYlF2KngXLWHTB6RvKONvsqVDAPp62+ROe roGxsMk7lpxy2D260JzW7FswWuyjk9MOu67VlXLoIn5lt8vstBjsk+kRZXQquuAZs/kNXRHzpKnL G/KNDEQnouOTiojJOOJQzsy5Yu1zfQsqhSvk89rHukaHB+Z63da0ui+h9Yb8yl09Nmd7JDaRDquj YW98QuFbcC0ElJmE19gW71d6Z73mtM6gDk0GzC5jdE4V7jW71BFvRD1gS+4Kx5RTEx6j2ZbxjPd6 x0Yj486hftVMtzsVGhowJac8GqPSb5lU9StdA/1WXdxv0g0Y+9v7uy2+Vq/fBzrg8BkNFme/Mt0V Mk8OhYwGm9k4122yJ4aHkl2Tzv60YyATtTjmnRrXuKHJ3W8FWRnjfQvRhF8ZMvaNZlQutcHhjAdd w/M+U593ciFoGstY3bqo1RpSGPrj9qjPF+gf9S2Eva7Q8FA81a+MOG3zzlR3wmrsGk1rnONjmgFv 1N+r1hqiqsho35wxbVG72w0ZY8pumZky+HQxs3/S5FSpHFGLct7rsU5HYL0H7JFZTzyW6rVYZuY0 EUPI0j7u9jqmbPNzu8KZGNgjR9jjy7S7zCG/z6RbMKgn23wmQ8yT0M1E1PFJ+7huujcRGvOp2nsH MsYez7gyPqyaSwT6fZkhtW4mnBkJDCfahm3umT6D29BksEcVXeqJwLDaO9IXGEs6PM5kyORShtSG uGXeOWmYa8uY4r7kkCYd8fsmp7oSKnXYo+r39Fvmu+bT4y7LnC5gtai82ljcpwkmhq1t02GzyuAJ TM64EqqMZXwSNhJHJmxUmcMDrniXOuYO2cZGffb0fNjjijpTRrXTbrQH+qPjvaaYIWRzm/oC7f6o X9sejgedYCF39fuVvT2J2OyQJzTuVHlTxoTH1JfI+K0ejy1s1i44x5IzxpS7O5yYNDrNE2GrLeO3 GLsGQrGxNvd8PAX97+pPOm29/b5UaMHdaxoP24L2zExPJjRhhjkdmA8u2Bfa1SF1eyySiLUHB+bC hpgqFlWn3f02y2iXwevuMbernGPRpNGT7LOOOrosJg90nwn3xZ3uSCqqGZh3jRmbVHGrzREIJbWa gFvrsqeUE32pmV2RcV+Xyd5u7BkwjITivi6XPz1v93r7zOPO4chAUGeyj0WCsehMxGZ097u9wX6j VhGMRTLefuuuoDfmmptXKqIDHmdw3hAJuj0TphjM0YAh2p+JmcJ+pdo5FjEa4pkeZ0ppC1raps1m nTlsdPp61NqUG+RpGB1LRMct6j6vd9rS7w4aY3NzwVGbMZByNRlj1tlIBmSnUTZFNTPa6IABVkFG 7VK3af0Zz5hr1G11mZKzfRan0Rh3jFgTY86wQRt2uudipox3Fvyi0W6bwQIurNcxGhl1OmdMUY3F akmNzfVaPHFz3DMaTsG8JlzevgFHPBhTwpqMTPR7Dd1BVXzUDDYvZLJ6nQPa8SFDV8zktigC812T vaNuVXguqDKbVMahgaR2LqM1WjNpl8Mw09Znd41FDbpYn3IuE4p5F4Iah9sciKesbue4ddzpNJpV CsdoZqTXEOyxxmYsfSajxQh2JpjRJY0Z5YzbPrdr2DMZN6XG7XaLsR/srr1/Ljg3lEqrAol0f1TT bjbaI8Yhg07nHg12eea1vqDbYB7WaPuDybS6227YZVSOmUzqLldYY+kOJtq7u+3ppFM1sxA2zHSb oSnnnDHR7QYnPub2+33JyYjbMRIxBs0wd6PDfoPTFgAFiHn9PRZ3m2NUl+zTuKZMKp0zOBcbtWuM 4FXM9QcSXRPD5omJ8IJjwOJNLsy5M0NOe2hXxD0XcnoNdttoctgZy/gN9kxywG2c6Q945nrcIWVv whK19xunIqmJ4UjSpx7yKE12tXI4GtOae8YcE1G/e3golTRH3NoZh7+1x+X2dgcDoUSv1RXoMbkj 4X6lMjIenHWPqnTd6i510Biciiy0OYwxxy6TPzkcGu9qssYcaVPMmAwZjAt+vzXePefuCS209Y+o utKm/tgMaLPDMJruDts89m5j26xdE2lyjyrtZu9Yoi8eNIS8Y1qDYcIajrcNh9zW7mAmY+qBVWue b5/r9Wa0YXWbxTDqUpqMVmtPQqlzZ9wDwUQ8lbC2z5osTqXJkMxYRmdah4yTDqPGkQnO6wb8mqjC HptQRMy6ab+va9IwpkpE3Y6MdaBNF/R7WywB52zE05Uemc9E+vozfmfMPdenaVObkuP2cNw7HDb5 Ml0xXyvYliZYQwtuW2guZPZ2D/nbrFaTI95jU7Y5F9xGsyfS0pty7Rpye2ajo+0LQ+rMpFvjmTaM w55sSBodqjm72aMNmWci3dFANOqLTfQG5rUL3Yb2mQF/Wht1t40OGdoC8HxbZCDa0uPP9JsyvrE+ OBuYrO3TUU3EZrB5R+0D7ZGoITpuHncveJNKCxhDX3g86JoL6LqiqcyQyxAZMMSsCo/aO+9OaV0g p4Fef1vUohpLmwIOc0g5Nx5JOYMRf5vfmppJemLRCZe5TRVJOaKBUeWu4fmIagh01GrzTPoXzD09 6jZbtzHoDFgibYZErClq1E2H5n0KY7zdYnAbk053sCkw7m3vSijBg+5KwCZqHlGmZ53jzhnz+ERT JBOMGOwOS3jAGA6Nulq6Db5kdCaacPhUuwxGryro8WZCCfesZXwiHRxwOg3quUl3wDodnNN6g2aL MjLa1edPBZM9dofaDHPtT7jdZuXcnCke9IeUbQqveiZitzktIX9b+3hiLNbrnbFYUwZfcKFrdGgs Pt9tyDgGbG3KsHtm2GuYGR6yghH0gm8+Fx1229Om7v6YyqJpazUl0z0Ba1DZpxnrCvp1aZvRNeO1 hULBzLS1W+3Y9v2lB6R3vXvg+G+uukpw8E9zLwj/i2f/0aYba/LZ5XOH9WUvvfhx9MdXNlnu+6H1 z1efXLn77lPed5e2Nj4ckN371A9aim544/VHt3h3vPpsyV8v1P9k88MvZsoG93gE096Puq+g/6qF ffePvzsgbtLRJ2ukXbtcV9/cPjJadPieJx7QPH+hYt/WKzk3+EpozR+/urL7tsMnbn+x6ZlLi28e OfjRa7/UyS7cfNudF9B/fc2xUZ1Apvz9bz78bWf9hRc8UNvIfuKJ2566997Le7+vH2Rc+ItYoVdU 8ehfm60fLow/eiNN8cvd01c2TCyPfHrs1YuuuF3/duEdhO3QR2s7H1R4e45/vPLGyp8nVGtXPV96 fOtvhJeUvdD2de3PI0fkfSbfjx/yb/rVe8/H13964tBtuvfuHhOf3PbN1mPcPdclv/bEC9ef+0Jk 26Np3/vFncPn/iXz6rZW3tP3XNvqve141eKphbB222t/qotcfOk375p/ruYX58kvyV9PUB6cUXM9 37uO3uNyfStZ+w1vhZQoe/aCb1ge/vnAnz58e+w7eO+m9773XuC3u777cVhz/tHDT8hbzdrLm+pd t1i/Mfzty4fMfgdvj/Slh9sqhmJc5msvn/+L/id+/3PPzGzVf8W8+fl+y27bvwf0fP89qptW37iI N7Pnvx/8Vn7/rqPt37ryklcqpeO/CLz5E52/98DcFZEAcc23zC9tu+yyI1cn/s/KTQ2mwye5rbdd /aYw934Xo0JEQZjKQkT2mzEjmkBjKIpOfx+7Pkf+ftffXstoa9MyUkGsb3rgSvqVDKJkmdi/ZBMU LxP7gBQtE3uBFC4T3wTCXyYuA8JbJi4FUrBM7AGSv0xcAiRvmfgGEO4ycTEQzjJxERD2MrEbCGuZ +DoQ5jJxIRDGMnEBEPoycT4Q2jLxNSDUZWIBCGWZmAdCLBNzQHAuhSClL7EJfuXAP3FgoQwLW/GV QXxlLT5gUBA7YfQ88m+FiSEY/S1EBNLrRBTuf8jeX8zW+AkxDPfHiDDc78/eczUPZO8TxAjce4Hv JWLQiiBbW0DEljBTb+AQWnwCTaE8/GT2fm/2ztAXT+WdmMp7aCrv4FTe7qm8rVN5LVN5Bjb+KWqF 8sPZ+3D2XqfntObd1Zo325onaSWr/BYFIbsre6/O3sv0xcG8U8G8J4J5twTzdgbzfMG82mCeoRTv Qw1Q/o3s/eLsfSF7j2fvnuxdlr3z9fyGvJ815N3ckPedhryhhry2hryHcQE6CmVsff7RvDeP5tUf zas5mne0Ku8h/GNUgPOXChDrOP4xhtKaqnHBMv7L0o5yIB/kyPtLOzYB+cPSDimQ95Z21AkMFfht tIMJ8sFvoR3YB/Q36FYqmX4DJwmSvo6T2fQvkAxLgf5sSfYwPP5ajryaIyeXZCEgLy7JGoC8sCQT A3k+R55dktUAeWrJIQTyxJKjDsjjS47NQB5bciiAPLzkGAKyvOQ4BeTBHDmy1DwGZGmp+SLBI3gR NRP3Qve7l3ZUQO7Xl3ZUA7lgaUcLkPOXdrQJDM04g27NYkxvjGEG0jcCnQJKjm0SXZEtn0BXZMvH cTKbTgEly0dxMiuLBNJnn4vBmEkaWZJ1QTfnLsnkQIJLDhWQwJLDIzDkYS9yZBsbQI4swn7kyD7U t9R8L1TrXWo+BfidG/h7lppfEBhYuBspMPmUA0mzte1L0puhtmpjVhQbs9G8MYImQE7SRqTPzko9 kmU7lQJCsp4kNw/iJdnVQERLMhsQ4ZKsEcim3ASU5yRfuuQgx1JESvcRzEPN2ec5+mLo/687BIK/ 7KgV/PnWU4KPIX5wnFSCJcGfZOT/w5cJ/ig7JXhPphasyFSC38vYgreaJYLXrniYRIJehhrCEsHL Mr7gJUeh4AXpKcGToG8/2nGz4HHZkOAxUJD79ctUrC8QHJJpBfc5uIJ7HWOCux1kXpHgJnjmRsfV gmvguW/JxgT7pLn8i/WVgotASTLQznRztWCyeRnfeEww0awTpBTALgmSUgB3TDAqvVoQly4zAW7k imUC6zmCcwBLyCEXeB1kmi1g0GUCCiEj7dRMzrBN52zYVM6wTeas1kTOhp2bM1fn5uzbeTlTdu4R m8CmgOaOCUwOsWAb9HTvkqCDBLskaHdku9c0L5NCU95KCk0nkDc3CAQOtsB7mOFnbGHoGFrGZkYd Q8TYxKhmFDMLmTxmPpPLZDOZTDqTyiSYiFm8vP5rfS25FxTTeSShU8k7lSDvRO51MoGZBOoylBP7 EJP4JsRLIV4C8WKIuyFeCPF8iAsQ5yDOQty3/usj5NPHiX3E+Ud5OfZ8YmEjc4G4dIO7lJjb4OaI 2Sy3DJTsE+jhLkT+2ssi/lZ56WxneWfhdn671fwVt50b96bPr/K/98BX1T2DxZsWr+vuDyzesym4 qCaZ9U3B7sVG8uekjhMthNZiPk7oSBIMHMfTRIvFQ+bjaXMQqvVkq6FbCR1UQztIAtUoYnQrWQ3d ShFnq+0lqx2+4laL+fCtt2ar0G5AV2SrXEG7IVvl3lxLMugAWtKTBKrR2UiWrSajs8lqoBTZejiJ 9NCYXp+tVVGAk2QtnKwoyDZWmu1PKoUqDilZ5XCTFCocljZli+s/L24WZYuTueJkrg/8ebki97go Vy6C8qb/l65h4//tE0f2/3rvHeTPge2UWIYh7lzcPxsvX9w9JBQe3vvrjd8Jq9s5FImTNDy8+GvJ sHlxr8QsPLz/jq8ovoMs3i8xH0Z3WAYCh+/QD5uX9uv3Z39F7Ijr9p6rvtDX3tN99dz+FY3dTjbW Q/bluuoriq8ii11kX1eRfV1F9uXSu7J9WRL9xpkzrl3pdI75ajHMoA2/D2e/gKSj8/FuRMfx019J YsSBcgpiIxqiAs+EOjRIsYCHwOcgLuIKOCgPAgflQ6CiAgiM7DeXVPA1+cBXoyJoYxMEBqqBwAF7 LijkICEEDhIhUQ0HSZAY+G0IzBLajrZDaScE8lcd9FBqQgbgB5EZSs9F50LpeRA4aCfaCaVhCBx0 ERpC5K8CXgz8HvQNwPlNdCnweyEgdADtA/4qdCXw34bAyf7SIw1dg66BUVyLroVRXAeBlv31R4Ru RDdAne9AQOgmCBx0G/ou8Hei24E/CAGhu9C/A383uhtauAfdAy3cC4GD7oPAQIfRIahzHC1BzsPo IeAfgcBAP4BAQ4+iR+Gpx9Bj8NQT6HEofQr9EGo+DYGGXkPPQM5/oZ9Bzm/Rb4B/BwIHvYd+B/wf INDQHyFw0H+jP4FsP0IfAP8xBBquQn+GCd0EziIHy3EN8Jthn+dgJez6CKuxCvg2rAF+C24H3oK3 Am/DVuCTmPwxnjE8Bu2cj1OQ8yC+AHKO42XgH8YwCvwD/Ajwj+FHgX8JPw78y+Tv6uKT+CTiEGr8 CiiOhtDwwRcmtAIOmE0d8C1EC/CtRCvwbUQb8O1EO/BbiC3AbyW2At9BdAC/jdgG/HZiO/B6ohNa sxIw+5SDhA2U9d8pIHPKXZS7gL+Hcjfw91HuBf4Q5RDwS5TvA3+McgT4n1IeBP5lykvAv045Cfzv KG8gDu02yrsI0W6n3Y5o6+vZX+pF/x/T7nQGCmVuZHN0cmVhbQplbmRvYmoKMTQ4MyAwIG9iago8 PC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1RpbWVzLUJvbGQKL0ZsYWdzIDYKL0Fz Y2VudCA3NTAKL0Rlc2NlbnQgMjUwCi9TdGVtViAxNjguOTQ1MzEKL0NhcEhlaWdodCA2NzUuNzgx MjUKL0l0YWxpY0FuZ2xlIDAKL0ZvbnRCQm94IFstMjI3LjUzOTA2IC00MDcuMjI2NTYgMTc3OC44 MDg2IDEyOTQuOTIxODhdCi9Gb250RmlsZTIgMTQ4MiAwIFI+PgplbmRvYmoKMTQ4NCAwIG9iago8 PC9UeXBlIC9Gb250Ci9Gb250RGVzY3JpcHRvciAxNDgzIDAgUgovQmFzZUZvbnQgL1RpbWVzLUJv bGQKL1N1YnR5cGUgL0NJREZvbnRUeXBlMgovQ0lEVG9HSURNYXAgL0lkZW50aXR5Ci9DSURTeXN0 ZW1JbmZvIDw8L1JlZ2lzdHJ5IChBZG9iZSkKL09yZGVyaW5nIChJZGVudGl0eSkKL1N1cHBsZW1l bnQgMD4+Ci9XIFswIFs3NzcuODMyMDMgMCAwIDI1MF0gMTYgWzMzMy4wMDc4MSAyNTBdIDIwIDI0 IDUwMCAzMSBbNTY5LjgyNDIyXSA0MCBbNjY2Ljk5MjE5XSA2OCBbNTAwIDU1Ni4xNTIzNCA0NDMu ODQ3NjYgNTU2LjE1MjM0IDQ0My44NDc2NiAzMzMuMDA3ODEgNTAwIDU1Ni4xNTIzNCAyNzcuODMy MDMgMCA1NTYuMTUyMzQgMjc3LjgzMjAzIDgzMy4wMDc4MSA1NTYuMTUyMzQgNTAwIDU1Ni4xNTIz NCAwIDQ0My44NDc2NiAzODkuMTYwMTYgMzMzLjAwNzgxIDAgMCAwIDUwMF0gMTcyIFsyNTBdXQov RFcgMD4+CmVuZG9iagoxNDg1IDAgb2JqCjw8L0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAz MDM+PiBzdHJlYW0KeJxdkctugzAQRff+Ci/TRYRNIMkCISWkkVj0odJ8ALGH1FIxlnEW/H3NDE2l WgLpzOtezSRVfaqtCTx594NqIPDOWO1hHO5eAb/CzVgmU66NCgvhX/WtY0lsbqYxQF/bbmBFwXny EbNj8BNfHfRwhSeWvHkN3tgbX12qJnJzd+4berCBC1aWXEMXJ7207rXtgSfYtq51zJswrWPPX8Xn 5ICnyJLcqEHD6FoFvrU3YIWIr+TFOb6SgdX/8lvqunbqq/VYvYnVQqSinEnukTY50ZmoQkopl1Eu PyLt9kiHCukgUHOZnv9qPaxJgWVSkuaJVDIK5iQmMZhRMKO52yX4jJST5e2RjFBfviM/6eKANOcF zId6bFfdvY+LxWviRuddGguPg7vBzV3z9wPjYprNCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iago8 PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL1RpbWVzLUJvbGQKL0VuY29k aW5nIC9JZGVudGl0eS1ICi9EZXNjZW5kYW50Rm9udHMgWzE0ODQgMCBSXQovVG9Vbmljb2RlIDE0 ODUgMCBSPj4KZW5kb2JqCjE0ODYgMCBvYmoKPDwvTGVuZ3RoMSA2NDA1MgovRmlsdGVyIC9GbGF0 ZURlY29kZQovTGVuZ3RoIDI5MjQ4Pj4gc3RyZWFtCnicrH0HYBzVtfbcmV1Jq67VqqxWOzuzvUkr rXqzLVuWi9yr5C4XudNsOsQQ4gAGQwIJHUIImPISMCVgbJJAwEn8EoJ4eSFxYkJCCpAQwiMQDNjr /7tTVrtHkMf/IMpBM2dXU+53znfKvTMWmCAI5fiPRWhYNnzGyHuld88XBNYtCNt/s3bHttMsSs6/ BOH0anxr+rrtw2eI50r52F+D/YvWnbNTEafkzcP+MezLI+t3rJvkjLVg/wT2G0Y2DO+8xG1dKQhn xLX9MzZuz1lyWzP2V+AcOzZuO39k+cXDOYJw1k9wvp9v2jC8/tiKZ5Zh/yv4fusmKGxzTu0ThN/f hH3/pu07z/vwb/6T2H8Kf9+/5ewdO6X6S/9TEF614PPztp2+brjmffZHQThzFPvf3z583hniBVZc z6sXYV/ZvmHn8Kuzhr6O/dsEoey3pw1v38DmWR8RhHfP45+fcfqOnakbhHOwf5O2f9aGM95ccF0N 9g9g/4Yzzjr9jPiXJwQF4T3cs+VPAh87oQLnrvgZ5NeQP0HeFoRKfFJph/gguN/KqZAlkI0QnKvy SsgtkP+A4F4qn4f8DvIPQajCMavKIF5IE6QPshgyAjkXcgXkZsgDkEMQnLvqZchbkFOCUF0KUSFJ yBTIIsgGCO6r+nII7q36fshByE8hwK7675CUIDhLIAqkETIZshCyHnI25MuQGyH3QZ6EYNydv4W8 CQEmNcUQD6QB0gtZAFkH2QnZDbkBci8EY1lzBPIbyN8gsBVXEUSGJCCTILBB11rIDsiXIMDMBTtw PQGBrbiOQv4K+UgQagshbkg9ZCIE2NQOQ86CXAb5GuQeyOOQH0OAU+0bkA8FwV0AqYXUQSZA5kJg 2+4zIV+EXA+5G/JdyI8gv4K8DvkA5g4/kF0Q2LbcA5kDWQ05A3Ip5DrItyCPQQ5DXoK8BjkuCB4b BHbliUHga57ZkFWQ0yGXQL4KuQvyKOQ5yC8hf4G8D7PMgzghUUgXZBYEPqacBtkFge8o34TArpVn If8N+TMEfqzmQuDLagTSCRmAwBfV7ZAvQK6F3Al5GPJDyC8gsGn1PUHwwk+9ME5vGNIBmQlZDoFN e4GTFzh5gZMXOHmBkxc4eYGTFzh5gZMPOPmAkw84+YCTDzj5gJMPOPmAkw84+YCTDzj5gJMPOPmA kw84+YGTHzj5gZMfOPmBkx84+YGTHzj5gZMfOPmBkx84+YGTHzj5gVMAOAWAUwA4BYBTADgFgFMA OAWAUwA4BYBTADgFgFMAOAWAUwA4BYFTEDgFgVMQOAWBUxA4BYFTEDgFgVMQOAWBUxA4BYFTEDgF gVMIOIWAUwg4hYBTCDiFgFMIOIWAUwg4hYBTCDiFgFMIOIWAUwg4hYFTGDiFgVO4DQL+CIM/whjr MPgjDP4Igz/C4I8w+CMM/giDP8LgD/yJEAF/RMAfEfBHBPwRgS9GMF4RjFcE4xXBuSN3QB6CPA15 EfIq5J+CEAWfRcFdUfBAFDwQBQ9EwQNR8EAUPBAFD0TBA1HwQBQ8EAUPRMEDUWAVxX3HcN8x3HcM 9x3Dfcdw3zHcdwz3HcN9x3DuGO47hvuO4b5juO8Y7juG+47jvuO47zhuIg77jMM+47DPOOwzDvuM wz7jsM847DMO+4zDPuOwzzjssw72WQf7rIN91sE+62CfdbDPum2QiyHXQL4B2Q95BvJfEMSKuncF od4KqYSEIO2QGRDEofqtEMSO+r0QjFc9xqse41WP8arHeNVjvBIYr0QFBFyfANcnMF4JjFcCtp2A bSdgJwnYSQLnTuDcie9DXoD8HvI/CIsipBzihyBWNfRDlkI2Qc6H7IHcCvk25HuQn0NegSDONCLO NAKrRpy7EeduhJ00wk4aYSeNsJNG2Ekj7KQRdtIIO2mEnTTCThphJwgPQhJ2koSdJGEnSdhJEnEm iTiTRJxJIs4kEWeSiDNJxJkk4kwScSaJOJNEnGlCnGlCnGnCgZoQZ5oQZ5oQZ5oQZ5oQZ5oQZ5oQ Z5oQZ5oQZ5oQZ5oQZ5oQZ5oRZ5phX82wr2aMVzPGqxn21Qz7aoZ9NcO+mmFfzbCvZthXM+yrGXGm GXGmBXGmBXGmBXGmBXGmBbbdgjjTgjjTgjjTgjjTgjjTgjjTgjjTgjjTgjjTgjjTijjTijjTijjT ijjTijjTijjTCv5qBX+1gr9awV+t4K9W8Fcr+KsV/NUK/moDf7WBv9rAX23grzbwVxswbgPGbeCv NvBXG/irDfzVBv5qA3+1wSfawF/t4K928Fc7+Ksd/NUO/mqHP7bDH9vhj+3gr3bwVzv4qx381Q7+ agd/tYO/OsBfHeCvDvBXB/irA/zVAf7qAH91gL86wF8d4K8O8FcH+KsD/NUB/uoAf3WCvzrBX53g r07wVyf4qxP81Qn+6oRddsIuO8FfneCvTvBXJ/irE/zVCT/ugh93wY+74Mdd8OMu+HEX/LgLftwF P+6CH3fBj7vgx13w4y74cRf8uAt+3A0/7oYfd8OPu+HH3fDjbvhxN/y4G37cDT/uhh93w4+74cfd 8ONu+HE3/LgHftwDP+6BH/fAj3vgxz3w4x74cQ/8uAd+3ANf6oEv9cCPe+DHPfDjHvjxBPjxBPjx BPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxBPjxRPjxRPjxROR3E8G5E6dDhiBb IBdCrobcDnkQ8gMIcsyJf4C8IwiTJIgDEoC0QqZBBiGbIRdAroIg55z0HQj8fxL8fxL8fxL8vxf+ 3wv/74X/98L/e+H/vfD/Xvh/L/y/F/7fC//vhf/3wv974f+98P9e/O1knHcyrnky7ncy7ncy7ncy rnkyzjsZ552M807GeSfjvJNx3sk472ScdzL+dgrOOwXnnYLzTsF5p+C8U3DeKTjvFJx3Cs47Beed gvNOwXmn4LxTcN4p4J0+8E4feKcPvNMH3ukD7/SBd/rAO33gnT7wTh94pw+80wfe6QPv9IF3+sA7 +KowFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbwzFbzTD97pB+/0g3f6 wTv94J1+8E4/eKcfvNMP3ukH7/SDd/rBO/3gnX7wTj94Zxp4Zxp4Zxp4Zxp4Zxp4Zxp4Zxp4Zxp4 Zxp4Zxp4Zxp4Zxp4Zxp4Zxp4Zxp4Zzp4Zzp4Zzp4Zzp4Z/oCXhJBwDvTwTvTwTvTwTvTwTvTwTvT wTvTwTvTwTszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwDszwTsz wTszwTszwTszwTszwTszwTszwTszwTszwTszwTszwTszwTszwTszwTsD4J0B8M4AeGcAvDMA3hkA 7wyAdwbAOwPgnQHwzgB4ZwC8MwDeGQDvDIB3ZoF3ZoF3ZoF3ZoF3ZoF3ZoF3ZoF3ZoF3ZoF3ZoF3 ZoF3ZoF3ZoF3ZoF3ZoF3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3ZoN3 ZoN35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oB35oJ35oJ35oJ3 5oJ35oJ35oJ35oJ35oJ35oJ35oJ35oJ35oJ35oJ35oJ35oJ35oF35oF35oF35oF35oF35oF35oF3 5oF35oF35oF35oF35oF35oF35oF35oF35oN35oN35sMP58MP58MP54N35oN35oN35oN35oN35oN3 5oN35oN35oN35oN3FoB3FsCHF4B3FoB3FoB3FsCHF4B3FoB3FoB3FoB3FoB3FoB3FoB3FoB3FoB3 FsL/F4J3FoJ3FoJ3FoJ3FoJ3FsL/F8L/F8L/F8L/F8L/F8L/F8L/F8L/F8L/F8H/F8H/F8H/F8H/ F8H/F8H/F8H/F8H/F8H/F8H/F8H/F8H/F8H/F8H/F8H/F8P/F8P/F8P/F8P/F8OpF8P/F8P/F8P/ F8P/F8P/F8P/F8P/F8P/F8P/F8P/8TVhCfx/Cfx/Cfx/Cfx/Cfx/Cfx/Cfx/Cfx/Cfx/Cfx/Cfx/ Cfx/Cfx/Cfx/Cfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/Kfx/ EP4/CP8fhP8Pwv8H4f+D8P9B+P8g/H8Q/j8I/x+E/w/C/wfh/4Pw/0H4/xD8fwj+PwT/H4L/D8H/ h+D/Q/D/Ifj/EPx/CP4/BP8fgv8Pwf+H4P9D8P9l8P9l8P9l8P9l8P9l8P9l8P9l8P9lsOllwGkZ cFoGnJYBp2XAaRlwWgaclgOn5cBpOXBaDpyWA6flwGk5cFoOnJYDp+XAaTlwWg6clgOn5cBpOXBa AZxWAKcVwGkFcFoBnFYAgBXAaQVwWgGcVgCnFcBpBXBaAZxWAKcVwAkuJ6wETiuB00rgtBI4rQRO K4HTSuC0EjitBE4rgdNK4LQSOK0ETiuB00rgtAo4rQJOq4DTKuC0CjitAk6rgNMq4LQKOK0CTquA 0yrgtAo4rQJOq4DTauC0GjitBk6rgdNq4LQaOK0GTquB02rgtBo4rQZOq4HTauC0GjitBk5rgNMa 4LQGOK0BTmuA0xrgtAY4rQFOa4DTGuC0BjitAU5rgNMa4LQGOA0Dp2HgNAychoHTMHAaBk7DwGkY PD0Mnh4GTw+Dp4fB08Pg6WHw9DB4ei14ei14ei14ei14ei14ei14ei04by34Yy34Yy34Yy34Yy34 Yy34Yy34Yy34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yx34Yz34 Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34Yz34YwP4YwP4YwP4YwP4YwP4 YwP+dgPOuwHXvAF8uQHXvAHn3YC/3QC73ADb2gD72ACMR2AfI7CtEdjlCMZ6BOM1gnseQXwZQYwY Ac+PgKtHwLcjuOcR8O0IuHoEfLsR97wR170R596Iv98Iu94Iu94Iu94Iu94Iu94Iu94Iu94Iu94I rDYiTmzEtW+EnWyEnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyCnWyC nWyGnWyGnWyGnWzGtW+GnWyGnWyGnWyGnWyGnWxGjNqMcduMe9+McduMc2/GuG3BuG3BuG3BtW/B ubfg3Ftw7i34+y249y3w6S3AbAuufwtsfAvsZQti5Bbc/xYcYwvGbwuuYSvi81bEuq2IdVuB+1bg vhVjsBVjsBV+shV+shU2txU2txVxdiuOsRXH2IqYtRXXsQ3XsQ0YbIOPbsN9bMN9bEOM34YYvw3x chtsZxvGcRt8bRuOsQ3H2Ia4tw33sg1+vg1jsQ15wnbE3O2wv+3gmO3w1+2w/e2I99sRO7fDjraD K7ZjPLcj19iOMdkOG94Ontr+M60HKgqXWQPG1letQWPrOmvI2LreGja2vmaNGFs3WKPG1o3WmLF1 kzVubN1qrTO27rLWG1uPWBPG1qPWBmPrZ9ZGfYtdam0yti6zthhbu61txtbl1g5j60prl7F1lbVH 35JGrRNOGf/jHd3/dZsJisB2XZKpUKnCSxU+qvBTRYAqglQRooowVUSoIkoVMaqIU0UdVdRTRYIq GqiikSqSVNFEFc1U0UIVrVTRRhXtVNFBFZ1U0UUV3VTRQxUTqGIiVUyiil6qmEwVU6iijyqmUkU/ VUyjiulUMYMqZlLFAFXMoorZVDGHKuZSxTyqmE8VC6hiIVUsoorFVLGEKpZSxSBVDFHFMqpYThUr qGIlVayiitVUsYYqhqliLVWso4r1VLGBKkaoYiNVbKKKzVSxhSq2UsU2qthOFadRxelUcQZVnEkV Z1HFDqrYSRVnU8U5VHEuVZxHFedTxQVUcSFVXEQVF1PFF6jiOao4TBU/poojVPEiVbxEFceo4g9U 8XuqeJUq/kQVf6SKP1PFa1TxBlW8ThV/pYq/UcXfqeJNqniLKv5BFf9DFf+kineo4l2q+BdVvEcV H1LFB1TxEVWcIApFTzfMHATf2E//5C6q+BZV3EsPOi5DeZwqXqGKB6nifqJQxx30Maq4jyp+RBW/ Nu82X1d4ZVPhML7xsKmQjW+sNxVhQzGOC+8xv5E0FN81Fd3Gn5SYin5dIT1Nj/EAVRw0/2Secfvj Mra/UMVxqvgBVXyTKr5NFOw687TLjEvPoX/yH1RxiKI/7krvpIpxt/8sVfySXhgN4owGcaWcKhxU UUsVbqqopgqnOR7rjQt731ScpisC/0kv/RS9Usr8Ck2/FAqDQnNLheaWHzGqEOmfjKsbnshWfGIJ ooxLuX9IFeNu+hmq+ClV/IQqnqeKn1PFC1TxM6r4BVX8twnPebriOEVD+C+q+A1V/JYqjlJEaQki UqIRxwXEh+g3fk0V9CziuAs7QL/xMlXQSxdpcGe0WmC0WmA0gWQ0gWQ062Djso59VDFKFW9TBb0X 4SRV/I4qUkThtdNv/IoqnqSKR6jiUar4HlU8RRXfp65HIySTqcJDFdTnGM30Gc30GaVmlksVhVRR RBVlVCFQBSUaRomGSVRhoQorVeRRhY0q8qmigCqKqaKEKqg5MBoiGA0RrIIqKqmiiipozGBOqqih ChdV0MjEaGRitC3EKL0zbyaHM1/WHk0dGe0QMdohYjSKM9ohYrRDxGiHiNEOEaMdIkb7P4z2fxjt 7jDa3WG0uyPS3g1rzRqMtqw9GmoZDbWsK+v73Vl7tIHDaAOH0QYOow0cRtszjOYHbGrWOfuz9mhj htHGDKONGUbbLoy2XRhtuzDadmG07cJo24XRpgqjTRW2JOtGlmbt0XYKo+0URtspjLZTGG2nMNpO YbQVwmgrhNFWCKPpP6OtEEZbIYy2QhhthTDaCmG0FcJoK4TRVgijrRBGWyGMtkIYbYUw2gphtBXC aCuE0VYIo60QRlshjHY+GO18MNr5YLTzIVLWFSnripR1Rcq6wt1EIdHgJ9HgJ9HgJ9HgJ9HgJ9Ew LdEwLdFoKNHgJ9HgJ9HILlF2lig7S7SBzUrHRxCioBMLjHa0Ge1oM9pIZ+PImPaaGe2tMtpbZbQb 7V2jdSy+mN4jH4vax1en98jHZdrHN6T3yMcx7eM703vk4xrt4wfSe+Tj6drHj6X3yK3Q0leh0CoU WoUmbSoNq+q4sEonXhideGF0BoTREpzR+ozR+ozR+ozRLJ/RziGj1RejFRz7b6oY1wqg3UdGs3xG ays2roKjtRWjlROjFRyj5QejPSxGe5yMdkEZbXoy2uNktKvDaI+T0ZYmo01PRnucjPY4GW1pMtr0 ZLQ+Y7Q/yWi7idHuI6P9SUbbkYy2Ixkt+hit8dgpSuu0thJpbSXSVFakZClSshRpKitSnxOpz4nU 50TqcyJNdkWa7Iq0ChTHdRpoOizSdFik3WkLpRyZhjmZhjmZUqZMw5xMw5xMazyZxj2Zxj2Zxj2Z VoEyDYQyZUuZsqVM2VKmdaJM60SZBkKZhgSZVpIyrSRlWknKtJKUaSUp00pSpjmNTHMamUYbmeY0 Mq0kZVpJytRfZOovMq01ZVpryjRTkGmmINMCU6YFpky9UqZeKVOvlKlXytQrZeqVMvVKmXqlTL1S pl4pU6+UqVfK1Ctl6pUyLVJlGoBlmjnJNHOSaQYn09pVprWrTBM2mSZsMq1gZVrByrSClWkFK9Om okybijKtcWVa48o0LZRp0ifTSlemyZVMK12ZLkGQ6RIEmdbCMq2FZVoLy7QWlmktLNNaWKazFzKd vZBptSzTalmmabJM02SZ1swyrZllWjPLtGaWac0s05pZpo1JmTYmZZqPy7SDLNO6W6Z1t0zrbpnW 3TKtu2Vad8u07pZp3S3TulumdbdM626Z1t0yrbtlWnfLtO6Wad0t07pbpnW3TOtumdbdMq27ZVp3 y3QiSqaFuEwLcZkW4jItxGU6GSDTyQB5F1VcQhWXUsUXqeIyqvgSVeymii9TxeVUcQVVXEkVe6ji Kqq4mir2UsU1VHEtVXyFKr5KFddRxfVU8TWq+DpV3EAVN1LFTVRxM1XQmVyZzijLtKci30MVdG5I pssHZDoZLtM5Z5lOmMrfoQq6nkCmE3AyXeggP0wVdIGB/F2qoOsa5Ceogs7ZyXQGSqbTSTKdcJLp /JJMJ/blcSk+nY+V6Togma4DkukcpkznDmU66yvTSV6ZTtDKtIkg0xaBTFsEMm0RyLRFINMGgEwb ADJtAMi0ASDT1UYyXVwk0xU6Ml3DI9OSWKbTLDKtkWVSI0vCVEmUrEKmZsM4Df9O4bjvZGqYhbZN LKRtIgqzpcxZflHYnrXPJJrCSzSFl2gKL9FcWqK5tERTZ2nc6l3quWxcn5ImcYwmcYxGGEa5n1Fm Z5SVGaVHRumR3UIVt1PFHVTxDaqgBMoogTLKhoyuamJ0ZRSjtMQoLTG6RodRfmB0iQejhMEoYTBK GGzcYgO65oPRpYWMUgqjlMIopTC6UIDRxXaMei6jnivSDohIOyAi7YCItAMi0g6ISDsgIu2AiLQD ItIOiEg7ICLtgIi0AyLSDohIOyAi7YCItAMi0g6ISDsgIu2AiLQDItIOiEg7ICLtgIi0AyJSyhEp 5YiUHURaA4u0BhZpDSzSklek9atIKzqRVnQirehEWtGJtKITaQEn0gJOpAWcSAs4kRZwIi2+RFp8 ibT4EmklJdJKSqSVlEgrKZFWUiKtpERaSYm0cBJpnSTSOkmkdZJI6ySR1kkiLYtEWvSItOgRadEj 0qJHHDf7SIsekRY9Ig1JIq1gRFrBiLSCEWnBItKCRaRhTaTliEjLEZEGPpFWDiKtHEQaGkVaKIg0 8Ik0zok0zol0WbFIF02JtFAQaWgUaSQUaeUg0spBpJWDSPMPkVYO4rilezSaijSFF2ltIdLaQqTr zkS67kyk1YdIw7xIiw1x3AJBWmyIB6mCFhsiLTZEWmyItNgQaTIh0mRCpJOLIs0uRJpdiDR3EGnu INLcQaS5g0hzB5GWIyKd0xTpnKZICxaRFiwiLVhEWrCINDkX6ZymSEsakZY0Ip1+FOn0o0hnG0U6 2yjS2UaRVkEirYJEOh8p0vlIkc5HinQ+UqTzkSKdjxTpfKRI5yNF+oiFSCcoRZoGijQNFMelgbSA E2kBJ9KHMMT3qYKWeCKdBhXpNKhIp0FFOg0q0mlQkU6DiqeIQqLZp0RTSYnmhRLNCyWaF0o0L5Ro XijRvFCieaFE80KJ5oUSzQslmhdKdGZMojNjEp0Zk+jMmERnxiQ6MybRmTGJzoxJdGZMojNjEp0Z k+iclUTnrCQ6ZyXROSuJzkhJdL5JovNNEp1vkuh8k0TnmyQ63yTR1FqiqbVEU2uJTi9JNNeW6PSS RKeXJDq9JNH0XKLTSxKdXpLo9JJEp5ckOr0k0ekliU4vSXR6SaKdCYl2JiQ6vSTR6SWJTi9JdHpJ osWIRIsRiRYjEi1GJFqMSHR6SaLViUSrE4lWJxKtTiRanUh0ekmi00sSnV6S6PSSRCsciVY4Eq1w JDq9JNHpJYlOL0m0KJJoUSTRokiiRZFEiyKJFkUSLYokOr0k0SpJotNLEi2bJFp7SLRukPTKgr+4 1lDQxFmmvS35Vqqg+bpM83WZNqrkcWehSa9Mk16Z5qcyzbVlmlvKNLeUaeYo08xRplmfTLM+mWZs Ms3YZLqCTKYryGS6gkymnSuZ5nQyzelkuqRMpkmeTJM8mSZ5Mk3hZJrCyTSFk2kKJ9MUTqYpnExT OJmmcDJdmCTTnE6mOZ1MczqZ5mMyzccU2tpTaGtPGfekHG3tKbS1p9DkSqGtPYW29hTa2lNoPqbQ 1p5C8zGF5mMKzccUmo8pNB9TaLal0GxLIdnWJz8XSGcIFNquU2i7TqFrehS6pkeh+ZFC8yOF5kcK zY8UOg+h0HkIhWZQCp2HUGhKpdCUSqEplUJTKoWmVApNqRTavlRoBqXQDEqhGZRCMyiFZlAKzaAU mkEpNINSaAal0IRJoQmTQhMmhSZMCk2YFJowKTRhUmjCpNCESaEJk0ITJoUmTApNmBSaMCnjniam CZNCEyaF5kcKzaAUmjApNGFSaMKk0IRJoQmTQhMmhSZMCk2YFJowKTRhUmjCpNCESaGpjEJTGYWm MgpNZRSayig0lVFoB1ihHWCFroNRaMNXoetgFLoORhn3QDZtCSu0JazQlrBCW8IKbQkrNC1TaEtY oetgFLoORqHrYBTaRVZoF1mhXWSFzoUqND1UaFtZoW1lha6DUeg6GIU2nhXaeFZo41mhPWKF9ogV mnMqdHWJQleXKLRprIx7OQVNUxWapiq0aazQHrFCe8QK7e8qNNVVaKqr0P6uQvu7Kk1lVJrKqDRz UWmiotJERaVpiFqcGePVkqw9miuotDOj0o6ISjsiKk0BVBrxVRqcVRqLVRp6VdqJUGkcVWlkUSkL qpQFVcqCKq0SVVrhqZT0VEp6KiU9lZKeSklPpaSn0mkvlbKgShlMpfykUn5SKT+plJ9Uyk8qZR8v zXq9tPvnpeh7aQL40bgnzqlzMToBw+j0CqPuJ5HF5R+3qoauoZGEXsmatSZGEoaJRmRWiWWtopkq RbL2N5D9n5D918n+EbL/Rta+JMwYd02bP0aTm3VV2et85pIznE72/4vsv0P2f0H2/0n2F5L9HeQO Fo+73rPpqArnSb6s/QVSTtaoP5S9L5xFPt+ftc8YjZuMWi6jAYzRAMboIkwvLb68lJW8pCD4NC98 zKqwvLQC9I57QQFdPMpuIwqRrjkSx32D8pxI6USkOZRIqUCk1yHS3EWki5BEmkSIdHkpo2dhdH6K jZufouWSSAOSOO6JfJoyMZoyeWkd5237dMAyL42PXjpz4aUzF15aVXvpLXlpBegd/uTLYSK1/SBJ 3cVfN7+8JvMvAll/H2BZe2LWnpS1l7UCMZCVOQRKs/bKs/YcWXtVWXvVWXuurL0rsoaaNjYi72U1 K+iEEBSZe3R6SMk6lUKngqDI3KMTQ1BkXhpNm6DI3KPn9mad20snqqDI3KPTVlBk7tHmCBSZe7Q1 AEX229+y346W/Wq07PeiZb8ULfsFaNlvP8t+9Vn2W82yXzaW/aqt7PdsZb/WKfMe6OPgmZ/RZ8Ez P6MPgmd+Rp8Cz/yMPgKe+Rl9/ju77c7/xwTjf+ICcYHlbva88H/9Hz8Sj6SFgkU4A7+rhVLs5wmK 4BWiQqfQIywWhoTlwkphtXCBRhT8k5AQxye9wlLjk2Fc3B8/7mfsSsf9LyrsFc4VbhduxH8fxL6a OhOXcptQY7lLUNP3aD1346adfPvc9Ts38d87tp22k39w+hk7LsBVC6cNbxtJ34mYviu+58eGKFRq 2jACgwVhXtK+yJj1AP8HnA4IOfMGH2bsmqED7NTuA0Kf+0khR5BWr6o7ILC4okzd3LefrcGOGIci qmJLiiv9+6VA/4JB35CyR9kzY/0epV/ZNLx+vyWg/cYHG/YMJZT9wsLBzfjvokF1/6QhV3pzw9BQ J45j4cexaMfZM4QjbDGOsEU7Ag5wEl+yxgeU/VJw3uD8wf2X9Ln2T+obcqmqMnX/0/MG9z/d51KH hvCtnPSV4vfFm6uNa87FNedEsZGnH2Xh4P5Jrv3C0J49+p5P3X/Jnj2uPbgPY/+A8DRRMIEqJhkK jAQ/ohSYeoBdMk/76BKf6uIKn+pTcZ1DfTi3LT6wcHAqrlQdquPIdKR/dqV/7maFbKdoxU+ruFR8 VvybdLv0ruU71i/l+HJ+nftQXqEtz3Y0f532c6v+U3BN4aaiDcUzS6aVVpT12Bvst5VPd8xz/KLi O5U7q2ZX/cPpcZ507awN175Z+6b7NU+1UomfZfi5Ez+PKY+pj3of893vvzrQEjgU/GHolnBe+CuR ayOvRN+LvRJ/rO7p+pcSCxqeaxxJhprEZntLc6vS+pphY5D93tV3rS7pfo858zRz+9al+u9fbj3t rQ+fPXEw79K8J7Cbk7Z+URhJ3WAZsd4N38oVpgGSBMCF5JXCDkchfL/0SXxs5f+cI7Ys2paEz23H hEPY5VZsiR3CbxFHtsQaGsvL1LKAWqaOWIQTOyTXiT+nbsgtPv7OWTkR/gbxQWm7dLZ1mVAm+ASX cFDglyjF+MEPCPZR/dQ1ow2NzBsMSbjDLpasdDOpmPnUcRqp0Flp8VRVDldWeSyVztTlzirJU1m1 pqpSxq603RlkZxY6q6udhalrg87sPe6EedJ28bB2LQWCfvNC4uPOLC7j56muWl1V7Rk7cLXTWa0f Crlq6nSp0XJYcAvbD2EYcoQKDEVvldCKzX7IEsgI5BzIlyE3QPZBHof8CPISpGBlr1X4Mzbeg4gr cUXC1MEDgivhehIjVTRhyFCUcEWJYJswhGt15OTmiBWOyiqZVThyfLj0oNjSbG+bwJqSlVLjlLK+ joZG59LyUs+s5NYtS4c61wZLyy03VVwV+Ubq+DWXvXfB5EcrKp29029m8568nzV9ZfUaPjLslsz7 qdDuCPdjFf6KjQ+1y8PNdWBjBmQIshlyPuRKyM2Q+yGctI5Ajmo3J2Rf/tj9GDeo309za1srDDsY qmeAAPdQVWmvcIi5QMEbZLf02ad0NiZrljhK1QHcz9DQhJXBUkfqDseVkTuZbe8l7180+dFKh7N3 2k2pB5+8P/Wzr6xdUcN940V2m/QhGLxfmIPrqAHS3oRx+l5++l5+PQdhijVCb5m94yAu0NyS01t1 6a1uYwsXHNBG2sO08c+16jiUMO16EyzX+K3dzUQWMH5rf1NlHbMy8U6Wl1tsySvIdUpSaUnq9ady c4sKJhcWW3OKc752fW5JrqU0f1JRcV7uU6m/lpblMmdOYV5eoZXlueyuObVl0rIzRUuJY1ZhiZRX KE38TU5JrrXElrDlFuYfP15QkJeXsHFNzm8mSkU2scI6y1EiijuYp7CsEP/niG9PfV+qY7MQaUsw QsUYnTKIxP1hAuMXyW+Pjd1ON2tjb+fVeH5bYrdYUn/PrS6WcvP6S0tFVuUtL7RZS3NPPldiF6Wa XHthgc0KDG5h2y1NYoJjD+bI1eK7xhfeYA9wb1L5QMCGDzuqqhxST1WNXM62Oyu3lFdWlm+xIzlk d516R4qxJfDWbx8UcjTigE3ma7CBW87sdcEmBdikAJsUYJMCbFKATQqwSUHgScqTkCOQo5A3IB9A itK2aeO2YBNyuW1Kx3C4NlzlNMhSyEbIuZDLITdC7oU8Afkx5FeQ1yDvQ4q4HyNcI8RLuKiGxoBm yLp7sru2Lx3atn1wcNvdc9avnTdv7Vr+tudT11os1puEco2Hioxxt2qDDRNp0+1FA2B3ZchVG82x imc4gy45arW6kv6IO6+i0NrbHAjX5jls4OHnT70Cni7G0apY/gGhOsHvDL9BrSWj3AM5o+e8q/GT BJ+QwE8S+EkCP0ngJwn8JIGfJPCTBH6SwE+SyU8S+EniBMDZwAY2sJlsYMPI2zDyNoy8DSNvw8jb MPI2jLxN4AN7BHIUUrASV4RoAmZBNHEeM8e/kI9/IR//Q4JdC1MWhIbCUs4kjF9vGzamQZZCNkLO hVwOuRFyL+QJyI8hvzL59C/Y+JdGWJzYwZT2piT4RZS8Ylkp3y4rFcWRHZdcsmPnJZfsfOrll596 6ne/s+xKvX38g9Q/WNkHx1npR2vYOtbCmtm61G2p5/FzK/cXC6zvQ2secsLpBxFAarUgVosRzsEI 53D3wVUrguVd3Ft+QkdVu8dqfo/V/B6fxN8x3L8Hf6HwkJcGXCeVijLDbFRN28XK2LlFRVZPyKuw SEFFQXnlnUMN4fDJB8LhhqF9lkZR9Lmr/bZ5kuSTP/qRO+zH/8Ju6UXtVdeC9EdYRJPw60O4qhw4 jcHn+UAw30QwHwjmA8F8IJgPBPOBYD4QzAeC+UAwHwjmA8F8DUEFdxvHtccT+nYC2wljuyWNqcDv V9AxhRPD+S0xPZcICJKRVUSwpaEbAboRoBsBuhGgGwG6EaAbAboRoBsBuhGgGzHRjQDdiIauNkgT WWubgPDh8yIu5uYYw2m4DwMvq6YrVXBqZvktTU+73W1s2QXDE3f4cooC9X65uHzS99bteyX17aX1 F7IjlpCqBpEpyNWxut5Ha2ubWf/Xt+5ujueVT4lP8KvlE2a8dNtzqUPz68+J1cWDUok02+PjEefx U69IxzHisLqDQkJwmlzlBFc5Ta5yYrydGG8nxtuJ8XZivJ0YbyfG24nxdmK8nRhvJ7jKCa5yglx4 lHIKCS0O2Y0tpE4JDU070LSbaNpxdDuObsfR7Ti6HUe34+h2HN2Oo9txdDuObsdg6owA/DSrzTFy vKY0ijkcxRwdRf4Pzvg0FHNKeSg3sCsBdiXArgTYlQC7EmBXAuxKgF0JsCsBdiXArsTErgTYleie aWYvesxvSrbyFAA/Lc1tHD4d0fTn+K4knn3p8cM3/T3mKfvlinO/vnGZK75ogVIxZ805yxc9XFkb +P0Vt72wTtyv3H/BQ6+c3S+HRq7YNnRhmVWy9nblS5bCTTNXn7fJ7+o5/3t7Nl/B/50c+Mdb1kJs tQs3HBIajYzngNBYyo3XgvEowHiwUT1RzR/ln3Cv1e03ro1YGHth2H+c2/+ooBMvzzVqTd+X+ChK +ijyArdAO4dUyrmRvasfWx3Vz8W9yYbfjfid5OxQZmMGD7SoWshsMyJDlZ5+gC2MweHpR4xVGOwh HkztZiUNXl9oZ6rOWeu2Smxfsb0kp8RiGSkua6qsLnHUilJersu9yDcJfMKeF/edXJZq8kT86n2K PDUcz7OKP3MWi4yViq7Kk3k+udJWkhfx19znCfr9/GXriDei5S3Uzm8fEGK42QpIDNcu49rlhD6C mn1WwD4rTPusgH1WwD4rYJ8VsM8K2GcF7LMC9lkh8OhwBHIUwtmmQosCfJzldBzjFojxPjY+fh+C hUpgBl6aSLjEamwd1BoJkuYvPPrYzZhih+XaYbl2WK4dlmuH5dphuXZYrh2Wa4fl2mG5dtNy7bBc u265Bp9YiPEa5lqm5zUaibPdk89oeuiNVOrIfX+M1hb8cvmX773jvGXfscvOSBP7sKEhWZ/qkoqr q/752A+OL++ticz+5q6L7lkW72TvqO5QKMCrJx7ZpRNaZPez9gNCIKHHmgBGoXqUGxwfayOyC4js +j8dyDsR50C+DLkBsg/yOORHkJcgRmQXENkFM7L/n/P8gwjg1YKgjXKONsocM46Ta5Qn++AqbAfT mFVwzCp0zFwC/2eiOGYl2LJp3lGh1Z8GUp8+GzOQkoAUz1b4VdmEEj1nd4yBFDLjgY8nBIKGFY8c Irv2iyNrLty1fnhXZeuX5tzx8kv3Hv47W8U8wxPOmZO44zDbfeGt151zwU3X3dTf/9aDj/+VdTAr W8Rurw1NEplNTp3iMeCFU29Jb8IvvMLcQzzuIcHjd1SO+6/EWFQmhHG8YCisXGE1B0XifTD8oQtD UQq6RUoJBxeN5FA10watrjCy6Fzx7Lzi8rJpjipJYlemLJLf51UZy0dqIH7d7covcFQXlxbnleRb Yok6rz8/37KsVna6vIUhlRPTC7CzlJ5BCgm27YDQwHGDNODa63DtdQmeqBmWVghLK4SlFcLSCmFp hbC0QlhaISytEJZWCEsrhKUVmpZWCEsD2a40uwyfLXbpFmXmXXYMUghXdhBWWCeENDusy7C+kMGx auKg4E9/g2sb0zYZ5cMf1YdfBpAVxCajn5NNVhs2ya/k46yzPHPbrIh5HZARL9mO3aedvvuKbVuv yL9sZONll23c+EV1eO3vvvPAq2s2bNj2x+9+99VtbHDLly7ZsunSXeytdV/YtX7NxRenzm+4fu2t P/7JV7Z+rSHyja33jP7XvSPf4JO2RtZSDX6J6/zi1NFxAh2nic6nz1t4ZlGoocGzlkJtrANptJ4U PKYNeWBDHtiQBzbkgQ15YEMe2JAHNuSBDXlgQx7YkMe0IQ9syKPZEI8FhVmcYvQYNPwQWZGdc/y8 2JKMOCAJXu1aSoCkw0TSASQdQNIBJB1A0gEkHUDSASQdQNIBJB1A0mEi6QCSDj0OmE6olRSCloy2 8V5GuQZehQakNLP1i6CSX+577u3UN1O/Wdlz7tz6Ow5bLxsZPu8L64YvEVdM7fv7dx7/W+pw6kTq /tTG2uAkSbS5mcCOXcTJ5ubrBVGvgaVdmmf+5POtgvX8o3BUZ2v76HiGPohxs2mVTgWPwXqF/Onz vtcg7/P6X6+QS1Ahl2gVMsuokMs+tlo2f4vPG2VzKmTWz6IwwnZbRqRNoFgXRuWQ1mfPTbtshd5l UDNrqey9fdKlsqrKJ3Z5VNWTsS06Qz5/EDlOkM0NYisQ8AcwwqdSyGd+ZbkLZ25gGJ9GI81rzKiH AnxsWlHi9EOWQEYg50C+DLkBsg/yOORHkJcgf4H8C6KNjRUbFRDxTG6rcSEAW9UwrtF+DIxrgHEN MK4BxjXAuAYY1wDjGmBcA4xrgHENMK4BxjXAuEbDuAZXWX7sIAamRijXuEfEGfQtyTiX3vXSdaqh Qxaa9q98bhH5GT28Sq6ozAhgYa4I6x7I4fBovJlv8Cb+QKsc+JZ7VM8TOSd7R/W8t4Hnu6oU0xNe HtOqGKmFQ2ou0bCb2M2/uva6nsbYGuZuC5Wyy8taw8Hm1NuzYonelcMpy5LhyQ2xGakPJkWj3eWi INrVUMTjDp1IyPjtiQQ9b73lCfKtkMwJYhFQ3gGU81CmJ5mPZ+wWjAo3qyCst8isoIvAjEUmMxYB kyJgUgRMioBJETApAiZFwKQImBQBkyJgUqRlShb8Dmpja9FZ1oJjWcxjWXAsC45lwbEsOJYFx7Lg WBYcyyLwXvwRyFFIgeG7ttGDyHnTx0xXJs1p5LwcF28GcnausOtA5cMUcjWg7FrZw+HxajmHWZw4 R3l3/oBQagTUWu2EuUK+FroCerCKsRZzozzduvCloUzHL60C/+rvnrrl+idff/GaKy/aefxIapLP F1+oqrPjfi/7xX//rm/Kts3LFjSed9re1aedvurCZauGVn/0ltbV2O2J+AL33D73nGDo6m3Lb2io 5X1rYc6pP1oWWJ6BX44cgj3mCDGzD18JT6yEJ1bCEyvhiZXwxEp4YiU8sRKeWAlPrIQnVprxpRLx pTKjD2/kaGMjV88V9RmKMZvXq+fCYziQDeHPyZMd7rPt2JgOGYRsgpwHuQJyE+Q+CP5G+Ank15DX IcchvOK38RRQw7QecJTzeGWFU5fDqct1a2nHxnTIIGQT5DzIFRDeVLwPAp/Hkctx5HLNWsKlPEob lbsTDO4EgzvB4E4wuBMM7gSDO8HgTjC4EwzuBIM7zbjnBFU5s+qfyhZO2CHet/cZbbZ030UD2isg LPI5ibvy/d6AbFEikx25lvKvDD/80tFHOs/rdK1yeGKJSYseWPV+6vus//3JV1oudVX629feX5BQ V9WWDKxOnfzNb1InVbV4SkSW28JtzWwlK2VFbL3CK6O1p05Yzoa3FgpxNvOQNs1l13zV/7nMXuh1 fqXWCbAbxu/H7/q0Z8kcfTnDHBSuUDIURVxRlEGSY2nKuLwT3067oMT7g0aPQMPdBtxtJu424G4D 7jbgbgPuNuBuA+424G7DxdmAuw24611XHt0LE7p9Vozqlbpei+g5VBW2qxJmNQmXllk6A80ti7Fs d+6SkkKZgW+QnatMlP/157+cTDRW3FEXCMS67aXddYFQ7I6XP2DhxfMHfnW/Y/VeSTr297eOihJ3 45As7VbCAV/qB6l/7P7TkjnTLNyHJ4NnO4BkD1vGOzEWEDDHMYSoqGpbQEHL6PSIq8UOjsSo3n9N 8rvB7w7j98Q0QqV8dEvHc9+YYqxX+SRIjY99abo3w1F36h7t1H4Mj3Zi/J0YfyfG34nxd2L8nRh/ J8bfiVM7Mf5OjL8THu2ERzu1KMw7O2bk48Qa03OpGDwxBk+MwRNj8MQYPDEGT4zBE2PwxBg8MQZP jCGXiiGXipm5VAyjEsMlcYuT3n1SSAgi/uvXOqy56S6S3pVpRXRt8hEkmTn9wltLapmq1xqfoDmY 8AdisydNGqgLBOukTq+PR9CTb7Ict9/nqvX7XakPRQePqH7VJOuALxJ6szkcn31t6qGW1mjdzIMD 0YapvtTUu2bHIx0n/PxfwF4B5FcA+XZmPYSRzdH6Y4fAsVbQKt9yA3m989iuhSXujZZjer+MW3M7 fgd4F07rwGGE8bszjb/ReR+DO5crcvXYFwLFJrVD56Ydr3hULy5KuTOUmu16Po2i6IagAE3FNAQF hqDAEBQYggJDUGAICgxBgSEouAYFhqDAEBQYggJDUDRDKMPR/KP6ZYdwjlYNuJhe5WdnOGJmEC37 N1CJq0LRoN+bKvf6Qwl14sRZMb9XOtvr83mj8sk/sLxav+J2ef21qeN7Vb8vEPAFFD2eRkKpFAIw x6hmRjIYTSWDyRnu1FRg03fqD5brLc8KnWzfIaEF2Li0SioMbHg9wOMJAx56tacjwIetNKFv86l9 e0KLxC2IxC2IxC2IxC2IxC2IxC2IxC2IxC2IxC2IxC2IxC1mJG5BJG7RKj1+pO5PZlw/V/gzFGNz LXodWKIBXGJ0cv2633EgYwAyZgIZA5AxABkDkDEAGQOQMQAZA5AxnDwGIGMAMgYgYwAypgEpYwSS JkMnwdBJk6GTOF4Sx0vieEkcL4njJXG8JI6XxPGSOF4Sx0tqDM0Nrd2sSNvBB+3gg3bwQTv4oB18 0A4+aAcftIMP2sEH7eCDdjMytyMyt2uROdCSlXLFWJkRiRUjEldp4Vk3m+zALd19XHbXBNj+Gqca LSq0d/zmjNS7qcfZlA/7rpyZ76tNeLzR5qo8a2DP0KMvvflcx/nffktRg7WqGqhN/a3aVZHvbWBL WDl+Rjyemqr2DVc0hiaV589dkjp57I+pd/lr+oW18PUtfEaeNevRulDz8GZshdMzRKWaRVk0iyo0 fNxiMKfZK28u5Zjz7zVo3+sw/H+SgXCf9p0DwvRP5oEarqjJUMS4IpahqOOKuo+ljo+ZOtYU3VzR bfai+b9Enk0u44lFMaogkw6a+JUbyTZns1bIlFF+R2lqMJqAYzQummCr4zTGX6RDuMrOndLVEJ32 28xY/eK8WOtAHXulr6OxbvDHdf5AtLW6tDsenfXC/HjzjMaUulcJRDxjodsTCSupu9kKb1DTqicu NEso/kZI4ftAuRgoe4Wzef/FonmgiUMVH6GqjEF1coUzQzE262Qo8rgiT1fkjOPpqnStog8lhskg 0PHRzhyNMumG2bHY7JPfTPiD8dmvvjpQHwzWiasR4OoGXt3rDvPbMiOY3x/xnLiQW+921BnX474S vH/ZoC0c4ijyeMQ7pLU8F4EmqGl4VcuXmwTxSQTbkYRO+2P9RsOaiqg1jSnGejD63IV+48ywobJR vU8eR/DQeCMO3oiDN+LgjTh4Iw7eiIM34uCNOHgjDt6IgzfiJm/EwRtxPaNXxw2RvrConvXofZoq mYE1+C+eGoqp1DsDcV+oTqxL+H3xmZf+8NerHljkq3T7q715FktOTuUXV+y5yGI3B/DkpX/+aayu PND4t35fuT2/1p+vtrnmLr/1IT6u02EvfFynsxk6KxRoUaaeh+eP4YSCDE6oNThBGeU9C3zL7JmE 4Nohs2cSQs4fQs4fQs4fQs4fQs4fQs4fQs4fEnjn+AjkKOQNyAcQXn/xpaX1WjekCVdUb1RiB4SZ n8wpRir/bxijhyt6dMX/lnPoSwT4jeUK1drpuVH5DLLQkzt+ceanpaU6XbSN/vssQoOXZfRZNA2T WfkYW4S0BT+hXHYLp4uu1ANeXyihTJo0K+rzsiVdUc4X3yysbIyjBAh5/Ynu4tTFS+/6D/sEfL5G cZfYRkITvzDtNBBHWBlLNZQwiGMzuxHHVwO+kJraY38q9QM55AsUO4u/N+Pss/P5utoO2MPpsIew cL3uN9zPcjWviuAWHbhFR4KjZjHy3GgakVo+vLUZAIxLFwq4oiADkbECTS+yeUHBvY5vcUIOjuqT NyEeYkbNtqVbc5B/RzGq9Ioc9fuD3hNXJvz+2KyLL57JuZY9C86pm3Wf6GDXD8ShSD3hC30c2xRi FJ7BKPQKHx0QJif0ieXJpRxeSEKPDi0J3WAKNM8oGuW3w7uHLUKRZrlumGeBZhxtpdwyeU8+AKqI ajruSVPSY2fhA2HJGCrDVscUDq5wZIydESFz9WV0Ds399BZUgTZ+jlI+tHzL7Bu5jW/xyzC/z0c4 ZIS9FmMi3LRjVp5eiBYz7TPd/CvQG/ChAtonLDfhAG+Jm35V3Fh/t6JG2kprq3rjSJFf64wmp8Uq flQSj0fjxUfsuom/jiS4t9Jd2hb1KnfXNxaxN8Wz/IpPDbpPnOUOc+NF/Ftx8pkoDiVOPHE3N20N uGvcQdXH3x4hqKfetlwJzLqEt3UmK9KYrCmDyfR4YUX90oQ9VeO1hIZeE267J43GuLA4zrTHkU2c K+IZiszAmdnCHVO0cUWbrsjT6IjXjmJGhKk15sw5DbUJteNoKKnlLCAcEyWSnDQ16DCwdB9BzI4w jC1pmtlaH5vxIdwk0lXuXNTV1BF2rKoPONnx0LTWxuiUfzT4fbGOQldjY5Xr5JtGMsI9BsmIKlbE TtwiVfp0pXKizF1ZUC99XRCFmaheLkP1wlfELdb9p0TvuJYIH2qLULSOUAmiQwmiQwmiQwmiQwmi QwmiQwmiQ4nAezVHIEe1JSz6TLteDpqzWRXmbFYFapwK1DgVqHEqUONUoMapQI1TgRqnAjVOBWqc CtQ4FWaNU4Eap0KfES3NXBE3LhEYmyrmpZZRJhQi3Bci3Bci3Bci3Bci3Bci3Bci3Bci3Bci3Bci 3Bea4b4Q4V6fgE0vhOBlix0Rz26WLXZEYzvKFjvKFjvKFjvKFjvKFjvKFjuuz46yxY6yhU/BwjtL BbPHJzBtiZ027WW3XJYa/fvfUi+w+rf+zhpO/vG+Z5657/4fPCMuSL2V+iZbg+jjYCtTd54sZOzV Vxk79adX+dy5iPPqvYA8cP/zvM4sh9/wTDoHFaclpuf4wqiGoRUYWk0MrcDQCgytwNAKDK3A0AoM rcDQKvBZ9SOQoxCzD1ql+WHhMZ3ceR7hy4okHj7knvErsLXUXoSvB7UL8oyl9ummEW+tVRmJCW+p ObWFPEZHrZys7hsXl79/6Pbbbr8NkRWUVOVFpX5p/yBKefbCP098+N5DFnuqYefZO3aeuFD188jq 8+qR9aknnjiYeoGP4czUh5rVx4Q2duCA0J7Q1+fxLgnvKUq6ByQweglz9BIYvQRGL4HRS2D0Ehi9 BEYvgdFLCJyfjkCOQvjoJbQb1Wd3JcGmkXmpsaWva2oxPeIzVP28V9bB0fAk9CnpzNpgDJWxxaMf A1M5hsObXk0aNx3n/5wn8zsuFOLGHXu1uTLdfvgUiTOhlyefvR8ANg2KLZpXwbd8UeRhWtmeXusF ozGXxrW1thmOx+t4duTBF1n7n/7C2lL/9Z7TVbS1+4LJ8VsDnqUlTv8Fk9tfbBm4P7+ybk39k3cf fu6eu597Tkyyqb9leWxj6qbU+6k3Uw+Km6urEoGY2zNl8vSGGtfy+FVM+t0rzJI68corqRS3ry74 6COaj05iObzDksMDObw0nPZS2+fipTZttoLHxyKNcx1a3/cgDNshhLWR52wwOe2xKkdezbANo/U7 ZhutXNE65sITtatV0y481vfl7qu7ru7GfPrLpZ17oiBq53aWZsxams4tfXLWrT8jkCuzqrEsOxQM SfVIxNnlL1y9d8+Vv+zrbIh2pvZ7/eF6tbMT9ZWP7bv5xuYps/d+oSZSfkRtR3J9ZmMiR3q6a/bE 3RZXatuG9RtGTpyVTrKvqQ15vW5f3dcW77hHKQnXpn7mCfoC03MszDfUjBu+9tQvLE2Ww8IUEbba Z6zZ68uoXdv4mj3uuW3w3DZ4bhs8tw2e2wbPbYPntsFz2+C5bfDcNnhum+m5bfDctozVPTzjNFfs fR6rACfgynhNVitM0MZ/KsddSvBHOT6JsQNcEdAVvZ/L0j9OAL2CXbuAXtxegd7AL8DxCnC8Ahyv AMcrwPEKcLwCHK8AxyvA8QpwvALhNcj7EKOBX8BnHlGl6nGkmRfynDiaQRzNJnE0gziaQRzNII5m EEcziKMZxNEM4mjGGDSDOJpBHM3a5LIXI9CcXnBTpzc66+BHdWajsw7Hq8Px6nC8OhyvDserw/Hq cLw6HK8Ox6vD8eqE1yHHeQNspbb2THsIRGs7V5ltgGbzKZd0Z9Gjr1EyWot8CYwnvc6XTbb6Q9GI VBSIddcUFvhu3HzpN9et/toL3z/5vbYLZou13rjXUhz2t7iLi9WL5p5/45k773xw/4cvTr/GV+dr bHvd3hBeEqvsn3XB6rlrih3uO79686jb466saXwx3xeaGa1Itp43PGuw1FF17zX3/dRrzCycCaZq FI6CX2Em0VGeNfMIBjnGV3Tx372SsAahja3s5Q+nYONMbKw2Nb83N+40Ny7RNpAvHDP9Ro+JspZR 8GPKxrF5ic7XifiyVlUbBeeYnQa5Ijg2AVirUVBQO6TZ1+LL7+qNhRJ8wqtB6wA0NJbrS5AaWlvK 9XWAVeXGtCy4RS0zkvIxQlLfFj11Pp+YL/qD0oagnxWIwWBYFvNTf7hFmz84+YI2f3BL6g9S8UAk 4PeUspkBVQ2kHrcrzO+LDDALzz3MCQReqfacesWyF+Oc5O+SL+Xzrlo8iGFLXwFSaqynNucJYqW8 88r3Q8Z+5mqF/70vNm49w7g5gARXJGibxWyxJLT8zyCDKjhvFZy3Cs5bBeetgvNWwXmr4LxVcN4q OG8VnLfKJIMqkEGVxnRjCyJ024pxQGgHNt0zG9eb1RfzPV7aXRcM1j3PW62ximrfxbOuvaxlTkt0 8ssN/kC8s/jobw7/zWI3264nj52+IdrT9+2nxTZPRK94Tj76z3/+8+fAQcQYHwYOnWzggNCV0B/o 6sp4RqNVX5/UCm5vBbe3gttbwe2t4PZWcHsruL0V3N4Kbm8Ft7fiZltxs63m+iRe4rQa65MSQqvZ aysGmMVmr60YzF4MZi8GsxeD2YvB7MVg9mIwezGYvRjMXgxmLwbPFYPnirV5lGLe0zvG1zwUCxVa fuXFGSo0Ihub+ynjqJZlwJzkimSGws0V7oyQP+Zb/KLdQpl2SP6YTr4+r6cFeX4687PYqL6gi08p dGZ0IKpcjOTqUrHWRAsVMGNDIl9g679tq5Lr3E7bs2tvr49F2tmUSm8wWHiNVFY+raradvTp3Ern gKPcclNhKKRUsb62SKxuL4BcopTZXSf3SS7FF5RDbq96otrjsDvF/SfnOEvLvdJfvKoclIM+Bagv Aern8j4Ru/cg0OlBxcTbLHG+QvBzQRt2w2uHY/pv/hREfoI/K9kzZgFxWEDctIA4LCAOC4jDAuKw gDgsIA4LiMMC4gLPw49AjkLegHzAOxYr9ecnAsd4Xt1jrEYrwyduDZJ4eu30QaHB0B4ErZvfTBrX os/9TqHPr/ybuYbM1TuaooMrOuhcA2+s6T1afoFIdHUrGtWnOMtHdY7mZaVX+76eGPJLNL+bNKZ2 JnGK0EJmul/iYunpGZ2sbUbETK9xy04r29gzsYDPeyIQSsbL8//4Zn5FQ2vUf8LriyRSz7AV8WjY m3q32R+fFDklnKib2hBsTv3LG47WswUWu6gGOHN7g6kfsN6QqoYCvqA3NS8Vk7yKGuIdLjac+oYc Cish1etl7AXO77NgYRfCwprZloMITg7NwurhVYaF1cLCamFhtbCwWlhYLSysFhZWCwurhYXVwsJq YWG1sLBaWFitaWG1sLBazcJ4SOMDXAyEFZxB7zPVakmRRes91WppjWZtQVhb0LS2IKwtCGsLwtqC sLYgrC0IawvC2oIC9/0jkKOQNyAfQPTefjCjo9967NPPTkW4IvLvpg3H5q+o+YxNVY219nOEqqye mvnkT4D0CRiJHi6qYGXS5NmxWG8q0BtNzPxq6tGy7nggVPfnrkhjr/rORxHYyIyaO2bFYt2lqW9r c1yIJ242S+zgsUXrzM9hjyjhqKzFmSdTPxS0Z9z3So3AvkqYMDY3o7do+RqM8vR64bEnvA9poSjX mHXn66fEdxsarRk2XJbBkeL0+9x+rzv1T0806mFFbq/ffd9xxeX2BWutX60Nqm6XN/s6Jh/k16D1 UwtKzX4cnwsau5axDOIQj9TGCgA9D+DXwsiSCnOQxd33yT5VZoVKNKqk3nV7ffJ9lpBa61aDtR+e Xhv0uWs9Ajv1VspteSV1PV8XKBzS3qjAtNXGrEJtsbzyUUnq+nPO4drLT71muVx6DElPC9vEq099 xTCvj1pLddooT3BTMWqu//NbA/T1vXr3X1/HzelI4efTnrPkeWlb2saNkFjwyXVyI1c06nUyf2WJ lM7ibObqQRuyJhuyJhuyJhuyJhuyJhuyJhuyJhuyJhuyJhuyJpuZNdng+DathCrCufReEU9x3Wa3 xA3ndJtFjxtFihtFihtFihtFihtFihtFihtFihs34kaR4kaR4jY6BWP5FzPrDp5yVY0t0K+sos8T ZsyNh6S+to1Ntzxy+pJdR/MWPDPy9Sf+eazznAmn7ZzztMcdfPnb+x9rnNYQDt9e689hB+1lmwb7 BndPf2HmnH2773iwpDR3x2mLEoGuBY8+lOqSQ36/V1ub2HfqLctlVlyg0MDOOcTXKRhPptm158SN tYkSqmLJrIolcJkELpPAZRK4TAKXSeAyCVwmCbwDfARyVHuoRJ9zto3y9Jg/UxIxytJIBvoN2vO2 5urFJH1SYswCMieaMycb0k9+BtNPZQlm3izAAgRYgAALEGABAixAgAUIsABB4O8c+THkV+aTZn/B xr+0J810Vsgxcc8B7jkm7jnAPQe45wD3HOCeA9xzgHsOcM/B5ecA9xzgbj5zVqKFV37/FcbTZ7xb o89NcA41FjHCHCRengoVDoFXRllLIsbmiirE2/buf3TPVQ8//J32+7YcYYWpv/9o823J8sonQsH6 voryvmQ4dJPsuuqRa6567NGrr35MvLR/Zup/fnI49dbMgXmuaj4nYRGUsN/vqOBxcw38vw7+H+fr kh245pC5LtkBT3fA0x3wdAc83QFPd8DTHfB0BzzdAU93wNMdpqc74OmOjHXJxlzdGILGZFABLYk0 SKPavJOkj3cZxrvMHO8yjHcZxrsM412G8S7DeJdhvMsw3mU4WRnGuwzjXaaNN8MZyowpPq35wZsL BXyFsNlcKMDxCnC8AhyvAMcrwPEKcLwCHI+/5qAAxyvA8QqE1yHHtU4IX7HDg670Gesx+H7WorhQ BhPwp3LMRzaFlmZtTfL1QcTAYNAVqm24cui2Zw9dP+X81nKlN+AJpX5539HUK0z59aybpTUW1dMw cDAQ8DTOX3jguq9/LxAodLaEPHPvYZWjo6xKe0JzEEjfAl/3w9c7D8Hn9GftD8GF9LfC6LlMTPNF vQvPnwOoMPKcWMa6uZg2K2j0zz/9kySGnQRgJwHNx2qzPN7oOYyZx7iFCZlP7DuBdFk6ZrqBDL/a XCMb5y2KetN762FN9aY11QP9eqBfD/TrgX490K8H+vVAvx6XUg/064F+vWZNpbig+nTWzqfWtSec OWWLOkRVmb5pvhch81E56fqKsu7HNn/vFCv96ca7u1qWNkVCz8uuusZ4UDmx/5Er9zzy8FV7H6yQ FwwsZEU/eYGVz5jGdnki3EE/uln1e4PsmT37n9h71WOPa+9FAorLJJ6v+oSXx1aT65zCV5+5089u GoRZ8LHTDu70SyxKPpdHBvULcBnLfVRz6FUMvWoOvYqhVzH0KoZexdCrGHoVQ69i6FVctYqhVzH0 qj5vxzsS/sx1+tqACxovBlTNcZgj79Fbz2YOt4zaYf0vN/8p9RbzvvELVpnYVHJyg3hVyf0X7n6c 3fWV2y8O1robqhqbWe7Rl5n9lPB4e/Cyc796NWfApzAMXVYPcokv82IoX8va+NP1xZon5BtZUHHG GvRGY6lFKCGMy6f1x2L9mmdVpVd2ji/TXNow8ZnsqlL9Cf0SrQsyPqs27aulOWtmxc3MR8XKpFsi sUjo5Fn8vw/cHamLhu/4+V/O2Frvt1/ZeOZatjYSiwdT+671+/iLN3x+cV0QW33f/VayxROuXn1a B9KB0MnbYV27U2dadkt3gPLa2Fn8+XQLj824kybcXNyMDP/nN7PoVbKeD/Bt3mvjYxw3Zk08OFuT 5m1N5sxaZgVcQFtnYwpjwbyNjz/PXLzGTKyRC1jTDxMapijwBV18KhemKMAUBZiiAFMUYIoCPy1M UYApCsZTvPw9UAb3u+AiLriICy7igou44CIuuIgLLuKCi7jgIi64iMt0ERdcxKVllR5cl54LxHA7 Y7lAeiFJOilsDjLz6YX0w/s9LDtTTFfnTJx52b59l33x3ntZQ623/T+vPGtzk891hvtrF/V8bc2h 904cnH39gMt9YzicnGqX8u66dNe3vrVr190n664+Oz5zdrzBkyi54p7zp03+4AdPn+zonF7h8PnC /N90EdbzmhoRo4NV6p3SVs0WHOmeaSz9DgpeK1hH9Xe0xYxnNflKkoQ2B1vEe3Ha3fLFNj6tq1qd ni/ros9BjMFqvIErlzbTND/L02o4fh3JrNmxkJlF6MvkDMRDQDwExENAPATEQ0A8BMRDQDyECwgB 8RAQD2m8z/P/UBofvpqLr+Yz61+9/dbQ2JbF/Z/wahw9uctWN71V3ocwcJNLnnHt7Bu/k0jGw+HU vxJqpMO3ZcPGW33dUTWR+lcolOjbqydrleWprr7ep/alulS4sFYU33n2hXtGUmv4Aw48qcNQ7AMW 86xr4L0hYeNB/EfRuCyUrkBDmh1rb/7RRtPHR9OXMd7lXFGuD6+kPVKrvxZAX9FhTjHyyQJ9BiD7 AdnsZ1eb1Mx1A2J+aNKEcKB3UuhJ1hsK+BInjofD0ShrfDYSC4dZwOWxPLWtPTG4JBI8UaT6+T0h xF4a8Pl8lXyK/I3U2dIt2r1Fhev0N9kJZn0ioD4RzPrk0z9fzHHmr1vVm19yIs1GH1OF6qxuN97a YQ4Mrw0944ZhvOe2lKkZI3FVuLcn5J/UG2YlsrfjP684cwu89Sz3dRelzh9uDIfFEB+LrR31Q4Oh 0EcHd30JTlrPnfTyfeILnog2HozTluUm+GY3m3eI+5KWC/Gn9d0a5tWleg3PV/PmjeqvEKw2+Fbr T7mFGl7J6v0pN8bMjTFzY8zcGDM3xsyNMXNjzNwCz66OQI5CzBKY96f4Afwam7UbW3wlh3b0dnzY bh69HUdvx9HbcfR2HL0dR2/H0dtx9HaBP1NwBHIU8gbkAwjPtxuPHRS60sedwDFxmLOoxgNsY3Zr lBpjPNHMFc26wlzqd5DP1AsO7YprjC1z0oqfS9fwmfJPqLzK9LfkNZnv4ihmJYyRtifbr9Y8GQon ZjdEliQjoR+4ZKaqnniUlQTDw+UFkbXJr7ILl8T4Ay3/Ew+HQqlfsV2po+EGvS7jaV9l+cmmd4q9 VbLs9Xbni6K1Jb4rtZ7PncuqK1TI+oD+QaDfA/RdwkxeYVZpmBem2bhQ63wJH+PUeem0jzo16TgR VxZ9Dww3RkJsJu6nE4SWOAnegftWWPbq18xTVd1pQcTac+ivIUudy5Yf0l6N1qB5Tq7xppFDwhRs jV2HvjK0XFsz/Vln9tuMNLTNqGXMt0Y1pHO2g0IPHw6D3Z/k1Tw+n4LP56fHrImPWVOGhXVyRWeG YhJXTMpQFHNFcYYNGuw6phjgigFdUVxqPsjHJ+bc6ck5fcllXDPXNlyBvpCnx9jSgyt/cGSqtso3 M7Rwk+1hZeYTkTQMZaw21V/ymBWuNHuXjjZNmLnU3hPx+nbFPH1ddQOuQHfU24BIFEj0Oez9TeHw zWqFGFnV1b+8MnratEvPLZ0Q9fvODwfFur3rLjkjtYa/2y082c32zRlY2tJ88iiPTr5A2C1eqoR9 vqpAPNozYWL3fU/pTaiGZoPJdkmPCV2si/dxcuD/3EL4uz0VzULiabtuz8gy4kY3kSPYoGUZxfhW gzZIFeknb5wathVZq1aNFadjyBkrTscUxhxewce0mrLtY0zRwhUtmQ11/kqBsLlaIgxeC5upSBgm F0YqEsa9h5GKhJGKhJGKhJGKhHGVYaQiYaQiYS1EFePSwulUhKchlRlLW+PavHtGKiLy3sJ4bMen IsYi2KZ3kIpEE4k1Y7lIovvlSf5oJ1KRkduQivj7H2+NRJCKcBADamV5n5mJhFQ5yp+nMTORqMyx RrRehip1h/RI5qpWY03fZ+glVqef1tPX9mlMYQNT2MAUNjCFDUxhA1PYwBQ2MIUNTGEDU9jAFDaT KWxgCpvGFFKpOdc/tqr139TMn09bseJzaStmtw0Zbxga1bE4csvhH9188+HnxHtTx954PXWM+V9/ nQV2PHvjjYcP33jTD9myl1Jvs9KXXmIlqbeB1GRUfJeh4gsLzeyyQ0itzZVy3syKL4lRTmKUkxjl JEY5iVFOYpSTGOUkRjmJUU5ilJPmKCcxyknthpOlY6utklnPxvLcv2BU/4b+DiTNQuKwkLhpIZ9+ npZbiPfj5snGsDQWX41rMNnoaqxPePKlynjLFZ9grBJKjRVMfPKCfcaXROrLNHjxT58SyOBt3a0F /ZVuoSwDWP92MBhIpKaFI01Ty8unNkXCN8muvntWH2HFp4Qfb3mkm7Ve9cije/bsf+iU4PeHFD8q PEsxp2RHxXB/f+rt5w+nBvrFh6664uH9V+7ZD7uYA7u4VusENLOv632mci3DDAqNfE71M73HTc+c 9WxbX6HOK65G4+0ghcZa1ULjaRDzrVj6c2pj+BqvdhmD01hYMaYwHv0Yw3dsFunz6XlVmtNNn/Hl B3VGMsZT1Epj4slmPH/tT+jP+ASMFyHoT6I0NGa+gouV8YLDb3QkM1sDpO48sf+qqx5++KqrHxJ3 THhk6+HUKVbyn6vu7nfJN4aDjVPK+exBONWfCISD7MdXPPjwlVc8/MiJB9m1/QOpwz9nJf39wxUO rz+sfPQObMevIIRrzxzyZ6EQwWPCF/gCloL0cyQlGsJaBX3MbBD+f3tnRkilj1NyR8wVPPo6W945 U/8X5xnrnuWKFjaL16EnzwqFI7EH+4YbQuE/uWpX//zcodPa1KrtsTnf2bx3rBDlhVeF44Fzd07v CHT0nH4ev+9HTr1hqcJ9TxJb9CWefC1Tb+nY+ytM3qvQOiHGDGoCXpOA1yTgNQl4TQJek4DXJOA1 CXhNAl6TgNckTK9JwGsSmrnplZzGksVgyWKTJT/9eqaClXrq2aL51WT6lODY4BvPpI0p2rmiPSPj mcAVE/SyIgl/0JvxE7TSQ1txaoFfWeBXFviVBX5lgV9Z4FcW+JUFfmWBX1ngVxbhNcj7/LEufcWp RXuRBl9y0a4VB8ajo59+BavhpwXw0wJt4GRt4Y42FRSAiwXMqaAAvDQALw3ASwPw0gC8NAAvDcBL AxibALw0AC8NCK9DjmtvwdIL6biZ2emrgwyvj+N4cRwvjuPFcbw4jhfH8eI4XhzHi+N4cRwvrsXw NrpQ1Xzc0VxFn/UIfE7Wy/S1BsMjaiBSXVoUvXvdlks2Xtz2s5de/N7sOy0FE2SvqvjkuMfRct78 VTvOeXb06f9+rOPqLb5kmS8w/ZF4sN1b1tq7pH9a9zWXf+m6WCiZPLsl0eSzN8YWTprYarFevvfy uyqcVVWNsPHBU29Z1lr4kqbvHYSv+TTfzk2vJOUVlWw8PZxrrOLL05Z+mpY17oEvw/E1Q+JJfM4x 072rjEL9s6LNFxd4Rs2X4HLGRFw1e+WOsScU9C6N9vhwmil6zEcnpXMb66LR1NbFG5en5NpQY9fa 26ee/Y2Qo+yBaLB58ZmBUNwrrfcGfL7UI3dv2hJ2q41VIf/ATN+a9R42B7jIz7fEIsmhn/Jnh0+9 iWz4NgS4j/Q3+Ea1SGo3mNKudZHMWMhHM3dUX2xdpXlpY9YM+dgaXaPgHBfuxhTG6wPGfNZYlGrE P+kzx7+xKlYypkkco3qbW3+Z7f9r7dvDHCeufOVuKTN0szBDNzDQw/S8+oUEaku2HgM0dKu7/ZDd drfd7ccNMPJDtmxLsmRLtszdhIHwDq8NN7ubhP2AZLJZYAkQQgibQDa5ezck4ULC5W74IMsm++3N RxK4BBZueMzMPbLdAxmS/Wu7fFo/l0qu0qmjU1WnTpW2fKi96s+J/YHpst7ItWcy+/Bpj1ppqJ+/ YWrf5LnPT46f78W7FtODN0QOHz59kZqa+fN9Yx7jE80by5479+yb3L/nkiNruydcY8RimP3qQ57v uv2bnbOupp459jP0LqiBSc8lrgWgZ0qaOr7aCAZrPa/TIdDNQ6Cbh0A3D4FuHgLdPAS6eQh08xDo 5iHQzUOgm4eAC0PAhaFNL7EhGDQMdb1OTwHWDG16gY0C90c37WCjoKVHQUuPgpYeBS09Clp6FLT0 KGjpUcRdtPoU0AtArwC9A+QqG7eXPPaS68s4iIz1V/WMdlFvbspl7yTpzidBG3iiV+HwiU/d8B+0 Tpw4O+Xmtq9vF91cY+nuBzT+bPelCB92Hz3pRIfT/nLXLyx4p6c9O/hJSpjwoJ49F0aZSd7jn572 Lpx29NGzvCROnjXY7YGOT03vPuIMXDc+MzXuzjwcmWL37OZcK9JvoNZ+DLV2wGP0fIVn+r7Cvb2i uhyeAQ7PbHJ4Bjg8AxyeAQ7PAIdngMMzwOEZ4PAM4nbUnwJ6AegVoHdcF7lLe94osy/11k3NHu+B jvQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYgQkYmRTIkZAIka6EnE2/G5vx8Kx 42gf5D3b3191pp+ra6G68I/7v/QV6X9g9Pxgoezj3S0BTz2+kejWbuX29shzi4H2N3fddzzV5tYe k8/2lsp2Xy/zEXfhLa4T8Vj/LSFjJyzP39K/ZODgoaHp6f3T2/7tpHMnpiY9w8zkGdu3n7f7wP2H hqen9s9s+9PDO/Cl2f0+z8nj4/upn//J1NT+c0/xvH90YnLXJDXwwp6pvfvHp3bsQzH0yFc8j0zu mvIePTiQHp+Z3rV/7+TugSMjbhQ81WtwkzeAfAiem3orheb6K4U2+187X/rP8f102bnpB4E+63K+ 57vQ84dwvUF7Z7sSOQcVPrcpkXMgkXMgkXMgkXMgkXMgkXMgkXMgkXOI2396CugFoFeA3gFyJdLt RLEvuR6gcwjbs39v67nnUpDbwvFY19a59Mf7cH030P/AoaJv1fwj490Td3n4YAJstu8E6k5Zb24G Mw+08NFdHY5riONDkjPZfSfqkBMMVVOem86hOK//6G92TTMXjHoWj373lAPn0cGnGS/r2/pPT5/O MbOMBx2fotidR3/uuWxo8txZ8Ud+avZc7v2bJ/bu3zu9a2KvJ+Lxj3fNj3v3P/fcnn1T+6bGJ/Yd ff7ovRNwfu/+PZNvu/s4wDj3ZpAh0hPp7Zcy0d9LureDQ7dGJ6BGJzZrdAJqdAJqdAJqdAJqdAJq dAJqdAJqdAJxW+qngF4AegXonX6X0V3oRLzU24CA6M+Eunq9K59jIJ9jIJ9jIJ9jIJ9jIJ9jIJ9j IJ9jIJ9jIJ9jIJ9jxyeT+/I5BnI31pXP8X6b0PNMJvr7o07083K7Wd4/bhf5yPT6B3aRPzTy6olE rz1w89vS9w7+YJ/Uj5oxRjx/uNnYfH/PwBge8s1MHaXJiampF+45enu3+TiT6zYfp3pGp5Z8k/z/ m5kiuGMIDMW6Q0/PxQPPHG9AXhhwPcOhAQEF4bb4/wi64WSo1ynPWO/dB56u1RDt7wDWWxP1uOvF 3R1ub+6guOmV6NnWu5/NQbh7nDnOwY/MP32wwneTYW4TgvXGQRj0rzDoX2HQv8Kgf4VB/wqD/hUG /SsM+lcYFBaD/hUG4yAMxkHY5jgIg0Jh3XGQu8niaG+d1bb/vM3+3AHzh7zRNqew9pze36/tA83u udnzBrB9r2/hyBe5A2edP3Dh0X3uvI8QHDhzOXDeeTf7Nujp6S+fN3U+MTZ7/sAFdIqanr53Zoqm zgm5b3X0IMjHth7dCv8/++733v3u1kMfec/hEvo0Im9+QZ/ePHrSJ6SDuIGtEP8FoM9Buh/306mA 4bvnHjj+EuhpwCgc3e+PAj0MdH8vHnmmT0+56T+Up/z7+Rw7CnFJoBWgHNAC0MeBFvvfnwBy8w0C 8UAnA+0BCgOl+8cLgG7tX3dRP58BoA2gSL/sX/j947HX+umuQxaRg1CnMvIt5BqkANrgFajdx48d hf9ZaAZWEBV5GM4HoX/7G2gN+a7ZucfZoe5/902jA11J2tE99s5B3x3E/r7uFNz9EHZ6rkX+tv8+ UuT4L5z4N9B9o55nM8WxY9/58LH3BsnLPLeDYHYQ7INSDCCD066t7UO/65YKLdS0Uh+HGz18IyRx pHq9BlcNIsif/DSn1AoIcuqL7q/kJSLfIPIOUZCIQpEoakSxQcgKIZtEGT4WoRQIpUEoTaLWJNQG oTYJrUbU4dMkTJ1oVImGTTRNwlYkmZAaElCTkDpErqgCwdEkcvD7kEup9KGcJNvNrVABauSIgqMT xZzVzV13C1BsEkWrWwylRsi6WxrZAnKIkkSUCkSpRpQaLaJkdYiSTZSlVrew8Ev9Apf6Za6oeaIq qUQVMqsWJaJaNoiqQlRr8NGIKlxQbZSJaouo5YhaiahVu7dZs3Qgh6jZhFo0CVUuEmoJPmUgfZMJ kkFoOUIruOzQNEJzNEJX+4wxLMJUCVNzOWTqMmG24AOcgmsauTrRKMKnDNQgGqUuC2tEQ9WIBnyA pYbLUri7JvCiWSWausvfZssg4G5thbAtjWhJRaKtlwjgW8faFIEd7r/bkM8jF7hdOARpR1Ky5qey JT+11Ixa66VIOlnKBJYspihbfFHQ6hXK4dmk18ZztqF4LZ328zGtQ/pjiWYmkRJjmsEXk0KSEebT hrVsBaSKIi00bZFpaZGEoGSkMBxXrXA4qocLtXKkWCuExSa/otVDlprEpSDn5IP1NhlgGmGHagZj +XLYWDDMWkGbFfCKFJCkUDuop4SCbpqrmrQyX8p1fLwdyfmSZJvPxPPRxQZD4r52lLOXGDkeosgi XhOXhWZu2VvxWwtSRHDU8IJWCan0hp5Sa5TYMMyUXFKd+VpATeUVG487xiLpaBSvBNsmE6PbBdtL N4LVEGdQ5dRGxGxWgq1cp8zjkZJm4ly9IJNOMR0Q+cqakivykhSbVZRojLRStHe1Ugw7ar0itjOG tsA26+p82QiwqhHTE3WjaBgptcmoLVXQNjoFWaZZJ1QOU8tqns34GrloqJrKl3SVrIYczgorlCaK 1SbjbWY2yvO1THujSZXNKhushPBO0hdJBOzQer0kFmZNIyBTXHIej6XnlRCbSRlqtCwxhUwmMV8P BzIZ1a/XmBje8Pub1nLMtsxA25YERV/RhE40YqzI8xwfDtJ0zDRUpr6osG1/U2diNV+hWdbxYtO3 4M/EBUOleM0fS69QXFPM0LVZzSy3Iwq9TguaZPqZaKomxLWAE81IYqUZYZRihFkos4F2LeTN1hjG UPQ11q4vqPmM4q3WeUNLBdpk1gkWCmyGlXFW4NKiV07Ltj9nsGTIpFc66w6TJXlOw8OCucxYSrBU MJs+PLIhNlqGFIjPe1eSOTFhMy0z0ApxyY5fSUfbjZy/wgXXWZtcbDfskhlKS6E4yI4TX2bUAE6R 8XgYT3OteHFRLVYiTGMx1Y5WdFO0C1wzDoJZ8dF+0QoVkimOC+bairJY5TQvG+mYVN725XzpDc6i veGYzXhVv9OKkjhjk14mEfNW+WBynjRpRk5rtYxZEnmNCVsVgTcYw2/ZFDwzPEdafhW3s4KyiLej nRwbjgQ7sVYpEl03qazTcOz4ij9WLVErbbyOm6TXMbOOsFQy1UXOT7Y0krNJSiym+ITpDyeCPB0N tOUmrfJcpuzjZzWd1U1ajnGVBpnm5XhO1QsBK8xzIFflrJqI1nMxdkPP5lVJ9WZ9alL1KREpIiYa VM2uFpJRbiUZM5nEWoUxuGaBnvdGg+Wwv5BfNaVG3nLWVBPXTMkp1+pl28jhq4qOzytqYq2akdI1 KiaU2QqDN7RcO5Y0faSpc3FZ9GXwSCMTs+uM6pg+0DPLiaDhKy41QgE7n01ofGojWMsZ0QyeZGMr dDXWNOuas9jmY7qm5qSang3kaqlYtRbhm3ZWWitFrLRmJnDdVI3SUsHIskEqHIt0RCOhlfxSwdKT AScmcD5rOWzoTlYL8UypHljKpKT8Rs6yMuKKs+FNzFusSGqBQj1NWbmiGCdDVhSeci3RisvLVEKO 4n51tVJTZotisZBTE96sV9rIxUBms07T0p2FErPCWkYiVGkk/LpqRPImU7EbZgcX4lkrldZpnM37 hdSsLipVO5SA0jrLSioVKKeK+TzltDSWX67OSoackbOdAN7S6gxXr6tyOJFp8/FsUc0EaqRQEvGi CTrVEQw24dN9arlEFdcMSSGzYcVWskKnzAgRzS8GjJCwWjWbTq0us96GXInoHX+TZPVFnhb8s0Uh KSasirFWr9QVNluv2BnNKtVzjE8KKnKdKdrekLSs6YJPMpp2XmppTtOueX3WrKzigp9LlkklvahG pFYtqkimr21JVLihs/DM19XMKmuklBw1W9Sb1Tq7zGRDKwU1m2oqdWZ+Q4yEFc1MtxqySUuJisKG Fx2HLDhOparkjJCdogpSzsl71yXRiOSWKibbqeSyasjmOBJXdZ310pKaKHaUjhm2khXDu7JSkhTD 8ql8hhJTGzUprPpiDcNn8FUpoHKm2Wr4y9aGWrbVLOh91lkrpwOpsq5qbV7H/ZxYiC6a61yjHS/F aH9MrsTji8KS107qTDRJd6K5mreQNNhGst0RglVfIhl1IolyUpTSJYMBuVOydn5FsnNKUfUVN8wM 3lFCxbKVE1drkphtGFa16o8pdWBntUAut3im6QvTemhl1arXo3VmlWZbTkViWElVV2yWtuMLkRU5 ptWVDdvORVqJJI1n8VoxqqUWo+slPEvLDSkB2lVO+pqayjlGxdbj/Kwss37crjlULNvmtAaTn6/R dTxbz6ebXi7tZxrJrMZUFri8wHmdNOs3Famcj8tePqc6Ub2u0XJaXNUrVGy9xmcC0UgzorSblWqL VBb0eKY0n7dzpFUJVBhJbxe0pLMSjzh5YyHT9KkMiEgr0lmvZKkw6NQO6AmKSSxm9UCk4udslnRK JZ8YWKlF2ZUFO1prK8lAWTUCorI6Tzq66SX9VYlPB7x2J+zl41TVjNfaq9VyqCkLtlHUIoqJe62g 6bWtjEEmpU5MhrS0V6VlM7RC+1q4Pe9PJRyvHOFbuFyk80bUTNFpzpS9La6SFlNClbeTHSdMazi3 UioXjRbDZzSfnFFzhmP7wksRUekERato5a2lupCI1MO2ljHFCh6Oy4q/wFJ4RlgFOU3TpFzzN2KJ Spxd6xR8VZ5PsxmRyVMr64t+1ilEhARf1cx6BK7nyXiGzhoVik8X+Di0UZxAqREoVzHHhwU50wop 61QhssbEZCEkpwpmTrc6Mldi+LgR0mNkq5CrhGNm0I4GSAXYypFsDZ6TTCaU3AjjukbjSZ1SmVTb Muc70aTgOEbIlHPaPPSB2qQtlDKUT0ywKZxcLVHRQAIe8iLeaJVFK50is2lfrREJ0iQ7723Y8Khs NB2BVESlUsQTDC9lF2udaJwJWXHRG2FIP3T/QnzG1BLwVNvpuFeI50NCjtdExkfhuTYv5HQ6L87W SJYUrdkKHm+VQzlRqpC0NN+IG+G8zTTFoMyStJcRzDCXkyJeUs76OC3LC0bSyqejZFTDvcJ63dKV oCPIXjGfKoRiqSUtXlmt2WnVn2iUJXiQKK6y6nCVpJ+LBXXoM7cL9AYlVFVfpMCLCWhLbVIO81Qx I5IGHmcXGSWSFDPQH803rIUmXQ/xLCP5cuvelsV549CuBqREpmFnnCxt0lbElFQmQ8ZL83wzb3rz 2qouJDveLF0hm+xaTVwstYsaR5LpLMWqTpXXLTqqzdPxZNAI5VW+SZdFtsPzVCJIF5ZCWiFZ9Qpl 0MRBil6ppDnOpqtmxMT5YJXmk0kqIpXMaDDubeaodmzVyPjy9Vk7UuHxUp30Kx3KqszTthby+vEw E41aszxbJ2VWqwXXrQgeTJOCXKPMmLetZARGJmfDciDaIH0NJtFJi7asaeqs6Y0nl9tKpRoOF1k9 Fgz7rWDET2pGPhIxeVLkaM5M0mmmotm+kg8PdlpytFoTa36ar2yElCTjOAWfnsmF/dE41WqYhVDU X/XGuJhIruohW4qV1HixukrncJn1hX1CuMalq0yuQ4qKuaCypjfc0HQtv1qZzQlWxE6uh/LJaMhW QT2VNK8SDLbiZjEfCpi4kxEjQofl8RqtWro2T3byLcdOl1nZj0eDIu3Ygm0GmtCXijJyJ8SThmPw LAn9OQH6gksVMZmi5kMKqcg+KiTYkpIzF4VkxOF9VjUXzNE8a4R5eb0VsqxIg50P2a2ygxe9Kp5q zQpJVsvbC4YkKi3ZzkKrUKKUBKdzuk3H01m/rRWqgXS1k6+wIi5viMFUJdtc1TuJSrlVjBfyOcbi HTtJW/KSz1rrWBEaGJbbEOVWucVQNW80F4d+RK6dUNUSbpq4EAu3C2wxHLOqekZMrWdiyWqWzFsB cd1sKivVgLpkMGtxU5SWaqGVhUqIiprhHEtV2FnbwGsaG2d9mdJFh55+7oUrmKt+snHxA+f84xue cx+49tLXpSN//ZP2C7e88cvbnz77wKdL7V+/eFrpH666ZObJvdvvujsReGcXOnfSY098svDw/eLw J/Anf/Tx6Nv8Ra//MHD4pU+Jj8y0ze3O2SPex/Bnv3q6b/vhly/4p+fee+uvvvVo+52bbv7Lf/2L i+P3XnrsidtPPXPfbbtO+sUvRstvf//O79/Zqo7+tD354hNPv3chs+uk2Qdr+/9+6nO3qDs/2/6d ffejr33mtVs+PUwcu/i2p7B86e3vbDuYezj43H3H3jas1sDXJurY18S5Wx9Yau4+csbLj/zLrRdy hyatL6d+ubFnxycmeeFryfSFW76+/tpvjxTPvPzukbPPe2vHG68/9dar/zMy+YDyvdezqd89dvOr 7ONnzP4PdPzAjv960pVzL/8qeP2Nz/3vswsPX/gvPz9b3pr66U35Uv7BY+POT+9E8L/7yWLgn78x 9okfXrz82A/vuercO+Rfv/XmFf92x+HffO7QFQ/d9e8GejgzVfvBp+5Cgvln9773q2fOHH5O3fOD p7/3+R/f9St7R4V7+f/c46z85d2vXnLwH7gr3v3B1NUjL21r/Pff7vzevw+m3rz8pNXhF9/6/uE3 t1z5u4t/ce+he7/068nM0TelO28aPvWB+3dGhvf+LPz+sXZj3y+fyb2zdf3g/337kSe+bb/8yWff fSJzff35b9/y0Opdq5cgV1z+zb8ol+++4/n7L/p68RvvnJ5Zuf3V16eu+6tnv31B+Woh/0hx+tXg t/yrt/csQqe5Vh7Ufcu364i7hhSREmIhNURCTGSwZ/g5+pmul9hH/h5DEBx5vPsSvAHc467j7IIn AYjIAYRE9iJnQLKt+JMIhlyOhJGLEOJ4zMeQ+d9LgzwJPxSHRB++bOAjlw0iwd+/7PGue/oW13Vp 99KfKjsWu5aynsnCtZ39CL5s8Xz/uDXM407fu5O97oaCgLd27WxD3dXGELYPIycjJ48Pu7towfdT 3OWEyKmuKymyzXWCBH5tB7zT3T4UOcfdDwjZ5TrcIOPI+GnDyG7XvozsQfbsGkb2QSGHofD7Id85 ZA7OXgxhGLkEuQTOCnD/w8iliFvey5DL4OzlEIaRg8hBOCtBGEYOuW81QK6CMIxcg1wN5bweuRbw Dd3FMbcgNwK+DbkV8O0QhpE/g4Ahn0E+A3dxB3IH3MV/g4Ahn+169/151w3jzu5yubsQ10fwbggI cg+EYeSLyBfhqi8hX4KrDkMYRr4MYQtyX9c59m+R+yHmAeQBSPNV5KuQ5kHkQcAPIQ8B/hri+gx/ HXkEcf0HH4WrvtE1kD+GPAZpvol8E9L8nbv6ASr5W5DyOxAw5MfI30PMi8hPIObnyEuAfwHBXb79 r4j7GsFXENdj6lcQ8yrya+D268hrgH8LAfMUkTegimWPDLjpKSHDnk96LIi50nPl9mHPIc+h8WHP VZ6rAF/tuRrwpzyfAnyN5xrA13quBXyd5zrA13uuB3yD5wbAN3puBHyT5ybAn/a4i0xv9dyMDA98 0XMbCM59A19ChgfZgftBvPhBDvDc4AHA4UGo08HIoAg4ORgFnB5cB/zMYAbwu4PPIgiKDb6HDKEf Qz8GeAu6BZ63EXQrMoyOoqMQfzp6OrIVPRs9A2LG0DGIGUd3IhhKoCBL6HnoeduH0fPR88eH0WWU hJgAGoA0q2gQ8Bq6hgyiCTQBv5xBk4D/C5qFaz+OfhzOXopeCtdehl4G116OXg5pFPQgpKmiFUhT Q2uQRkVVSKOhGqT5JKpD/DXolRB/HXotpL8ZvR7wLegtgG9FbwV8G3pbd099kDf0r9E7AH8F/Qrg v0H/Bq69D70X8IMocAl9CH0I8P9CHwb8M/R5wG+g/wz4XfRNwO+h70G+76PvQ75H0SMQcww9hiDu /BgyjHkweH6xU7ABwKdip24fxrZh28aHse3YdsCnYacBHsFGAI9io4BPx04HfAZ2BuAzsTMB78B2 AD4LOwvw2djZgMewMcA7sZ2Az8HOAbwL2wV4HBsHvBvbDXgPtgfwXmwv4H3YPsD7sf2AJ7AJBMMm sUkozxQ2BXgam4azM9gMnD0XOxdKi2M4nD0PIwDPYucD9mJewBRGQUoaoyGlD/MB9mN+wAzGAGYx FjCHcYB5jAd8ADsA+ALsAsAXYhcCvgi7CPAcNveBtf//AzglIq4KZW5kc3RyZWFtCmVuZG9iagox NDg3IDAgb2JqCjw8L1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250TmFtZSAvQ291cmllcgovRmxh Z3MgNwovQXNjZW50IDc1My45MDYyNQovRGVzY2VudCAyNDYuMDkzNzUKL1N0ZW1WIDE4Mi4xMjg5 MQovQ2FwSGVpZ2h0IDU4Ni45MTQwNgovSXRhbGljQW5nbGUgMAovRm9udEJCb3ggWy02NTQuNzg1 MTYgLTQwOS4xNzk2OSAxMDYyLjk4ODI4IDEwODkuMzU1NDddCi9Gb250RmlsZTIgMTQ4NiAwIFI+ PgplbmRvYmoKMTQ4OCAwIG9iago8PC9UeXBlIC9Gb250Ci9Gb250RGVzY3JpcHRvciAxNDg3IDAg UgovQmFzZUZvbnQgL0NvdXJpZXIKL1N1YnR5cGUgL0NJREZvbnRUeXBlMgovQ0lEVG9HSURNYXAg L0lkZW50aXR5Ci9DSURTeXN0ZW1JbmZvIDw8L1JlZ2lzdHJ5IChBZG9iZSkKL09yZGVyaW5nIChJ ZGVudGl0eSkKL1N1cHBsZW1lbnQgMD4+Ci9XIFswIDkzIDYwMC4wOTc2Nl0KL0RXIDA+PgplbmRv YmoKMTQ4OSAwIG9iago8PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggMzAxPj4gc3RyZWFt CnicXZHLboMwEEX3/gov00WEeaVdIKQUGolFHyrtBxB7SC0VYxmz4O9rZkgi1ZJtHc9c39FMVDV1 Y7Tn0YcbZQue99ooB9M4Own8DBdtWJxwpaXfCE85dJZFQdwuk4ehMf3IioLz6DNEJ+8Wvjuq8QwP LHp3Cpw2F777rtrA7WztLwxgPBesLLmCPvz02tm3bgAeoWzfqBDXftkHzT3ja7HAE+SYqpGjgsl2 ElxnLsAKEVbJi1NYJQOj/sUPpDr38qdzmJ2GbCESUSLlRAlSIpDSGil9QcqfkTKK5RTLEiLy3H7P r1730o6YJmpyeSTPE1K8PVZknZH1E15ZTBWQPK3IjORZdi1kvQ7xVgF5rg1YB3XrrpydC43FaWJH 115qA7eB29GuqnX/AewtmuwKZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjw8L1R5cGUgL0ZvbnQK L1N1YnR5cGUgL1R5cGUwCi9CYXNlRm9udCAvQ291cmllcgovRW5jb2RpbmcgL0lkZW50aXR5LUgK L0Rlc2NlbmRhbnRGb250cyBbMTQ4OCAwIFJdCi9Ub1VuaWNvZGUgMTQ4OSAwIFI+PgplbmRvYmoK MTQ5MCAwIG9iago8PC9MZW5ndGgxIDE3NzAwCi9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGgg MTIyNTA+PiBzdHJlYW0KeJzdfAt4W8WV8MyVZNmW7fhtxy9ZVvyS5ViSJVvKU1dvyZJsvR+NIXpZ b8m2ZEt2gQZKoCQQQqHAUsqrNAVCimMCOIVSaHmWsKU8W7a0bAktZRto2RQoJfZ/rmQgdLv79f+X b7/9/ns0c87MnHtmzjlzZubqWkYYIVQHGR0Jxm1DoiuNq+8ihLdB7W5/JpGiX1uqhfKNUNYFkr5p 4j3iQSifhHIwMJ/t/N7T//RzhAgdQoyuqWAmIN8YH0GImYB2wVTIl0UMogPK1P1tU9PhpFrm/w2U VxAqeTucWJjSNb1VhdCGgwhVPRcJJvOX7a9fQ6hjN8h7KhLyBd8KPeiFdjfcPxKBitpE+b8jtKkP ypsiyWxewiZYQBphTLsT6YBPkN7cD7Juh/blpC8/XXpH+QmEuu+GcmcylPUZkodgfN1QV7sj5UuG 0Fv0HyMkrYD2lul0Jrv2ZbQfypT8zunZ0HTPe3eDLlLQr+yl6dn09KOrb/4JIUUnQjQ6fH5HPIQY oP9DxD644/Iixq+hCaIWyqiUyggqQxiddU0vzGaQHHWibAlahXL5LhqIxDePAxftHkaE6v3se4gf ET9i7MUvoP/Xi5JEg1QBfqZsWYuqoUxALz4UQCEURXE0jbJra4Wei3VhqEuhzNra2hufh8/rUrxg zG2Q2JCaafegFoTWXoH0BpVWvWtnGEnEWX1m7VWaEAYzWExwiVEMXYyE6DkYzQmw5HfQMlJgNdQ/ BrOSAy3noHNhNqqxG1WC1AD6I3ahKXQEvYv2E+UoieTAPYiGQV4bcqAnEQdF11aRHs2jfegAugPa LOjA2nNrr0NvQugtjS5BV+IOoI+g4+g1nFh7ErGRAjQ9jF7BO9buAL5m6ElJH4BRbEUqZEAmkOxF 56IgSLwNfRv9DC+sXbL2JGjIhP4ESALjOoTuBw3+iofxAk1BuwFaFADPo5dwFVas2dbuXXsa+ulD MpDlQZcDHETXo9vRA+gUWsVD2IKPrMXXZtceQN3QVwRdiL6GrkPfQj9Gf8EDeJAQEWniHiqK0BAA JdsJo7kRxvMYehWX4wrsxCm8gI/hDwgP7f616bWbwL/dSAQ9HkY/QD9CT6Ofod8DZzluwwqcxE8S R2h1tKtpNzHmGd9b4669BeNTIivKgIUuQ/cA/8/Ra+gN9AH6EHRoxi2YjQVYjCV4DHsBDuF7CBqx lzhEHCFO0Upp36I9Tq9YfWPtV2vvg1V60ADYWAISVUiNjKAzZcFZgOvAVj9Aj4KvngaLvYR+CfAm egfTcR1uhJ5aoR8O3oT7sRZgDPRy41l8G8Cv8e8JUIogiGM0Pe0qOqLvZYgZC2tda+K1UYB/Bh1o YPkmsJIEbUc7Cp7bBdaMwFyeRV9Fe9GlYNcD6Gbw4jH0OIzgXfQn9B46jf6KPsY0zMBMGEE1WIiL +8ArAjwCMIrlWA8jGcNG8JMDu2BEXnwuDuI9+Cr8dfwAwMP4R/hJ/Bv8e/we/mthlAyCBV7TExbC RpxPXAewTLxA66W9R++gD9Dl9FfpJxktjFGGl/ENxuGSMuZ9Z/6wemT12Bp9zbh2YO2mtRfW3kbl EKnDyAxR4Acd0qBDFu1BV6KrAa4DuBls+V2YyffDPHoEfPwkwDMAJ9C/gFV/Dd47CfBvMMdOgY4f gn7lYOMiUB5tKXhUhndgFWhnA3DjKZgb0ziHzwc4gG/AN4Plb8d3wMw6BjqeDT/FrwP8Fr8FWp/G fwW964khAGNB5y8RXyH2AOwlroUZcoR4HOADWgNNRHPQvkRboF1Pu4N2J+0Z2tvgxyn6PvpN9Ifp P2MgBpuhYwQYC4xLGd9k3MM4wXiB8fuSTSVHmFcyr2b+HrziBN/I/mb5qYMZdgt6CEWIeeIYrAgd sM7F0D04iz4iSkGrHK4DXy+A9YYg6ifxBaiaEBDXYD746NuMMdp1MCe+AWvFKETsaxBbenQVRM4r SIMfI5zoLdQOK1nd2inUvPY2I8vIgnPHUDukZrizbn2dOwXp7VUFrIXQtvqDtZdpsPOhi2B94BXg k/WckQtHsgh3olwwG6EwbLNZqiE9nVmEFRqlfImpAjc+aw8olpqBgKmFafLenu5N3C5OJ7ujva21 ZWNzU2NDfV1tTfWGqsoKVnlZKbOEQacRGPHVXM3uzqWe3Uv0Hq5ON0iVuT6o8J1VsXupE6o0n+dZ 6txdYOv8PKccOKf+hlNe5JR/yomrO7ehbYP8TjW3c+lZFbdzBXstbqCvUHE9nUunCrSpQB8s0JVA czhwQ6e6OaLqXMK7O9VLmvnIPvVuFYg7Lqd2yUE+OA/2TRYleAkpfedHmgFRHOqlFq5KvbSRqyq0 0brVvuDShMWtVrVyOJ5B/hJWBrj+JcRVLG0YWL+duq8TWK1u6HuQH6XGj/ZXBLnB/Sty5N9NUb5d 7iWaz7NE7Kb6qBlYauKqlpoW32z+rPgJpb78rMYlolvjC+3TgGn264rF3VTJdzmUxmydIJbY63Ev 4b2e4iAKYy9qEeKqqZrdsc6lMq6CG9kX2w02R1b3cou8Rc31qTxLaMK9vFG+sVAY5B9vvmArB4xy fJAcJCm8ldN8QRH/7qvF+ucfYRX4Hnsd8Jj1U7tgqieuHoa51BkodMKFsUqpLCRF+wJSYIPLg0HL 6FKZcve+6i1w1xKju5rbue/PCBzFPfWHz9f41mtKuqv/jCiScuenMwLa1+kV1MsfW0FlE+6jGB/w rOC1vStI1X4clSHauedAcx81HaIquBsK/Xyo4HGA4vE7NTBqDeW3zn2d+/TBfZ2azgg4nN5dwNAQ 2ucZAnVs7ijkdjdnSe5p/ZQMeTxbQM4AJYdekLPPAxJi6xJiBQkg4Aww8fljYKKeCbfFvbRH1bok V3nAJDB/HplwLz0CVvR4gGvw05ECPj/avD7mzTDmQR4QQ0UpNpABIjz79hVLXM7SI/v2te6j4qBY XsHobyvk6xUrqCAApsoK3jNRaNrD5bRSFVwOlwPD8qigKwFMr0/cu4KE/7WFRWdbeBhGKypYWPwF WVjyj1h45B+y8Ojft7AUxjxKWVj2P2fhLZ+z8Nb/2sLbzrbwdhjttoKFd3xBFt75j1hY/g9ZmPz7 FlbAmEnKwsr/OQurzrLw+nPC/w74CH2ELwT4EH9I/JF2Be1d2rv0yylg8BjfKNlOAZPBjHy2b1/0 nnH/uRu2/RnXFJ4F0W0XP13Av7AdUqxu/vjhqq3lu4C37NN9njqzo5IqeI6iTrKkvI1RwoZtnM5k 01A5g86m0YiWshImG6ONpWUrxOZ7OeGJ5oEB8+ltpjPbzNXvbzNVn9mGdm47s41KQsFwDaemF1I3 4/dP/vU7jMhH1z9Je/XjHpAuXnuD9hbtacSCHZVET8mz+p3RnTc03Lnjzp2MRm5Db9uO/spebu+m nt7+Hf07x/Blom8KDuO7BHftuGvncXxf3/cF39/x/Z2P9T0jeL6vmWTeKMey7XR2bRWds6EKVxmq WLW13d1Mll4o2c4iyS5etRALhUqebEMXjVfNw3t4B3kEb4XwyauUpXJ5W1da/lP5r+U0+QrhP6pU DJ14f/LF16rPVJ+enDlz8rmaWtnQTDOVg27bTzSf2nkKCvNDk80tzwIBn8mdQgGc7CY3jY6M1pQw SxrqG4f5uFsi7uF2UQU27sAN9SXcrh6JeGRYBOelGuAQjYw2ATO3q7ent4B7JBj/+0Azx7ojur1n NUM9LZn8o9rS0oqqGtPwVtuvbvveXLapqqKunr1Nv3n4S7xmliNO7rR/HR+f66jtwQP1A/oZpfrF 26zf+JKrn11RXVZV09+0ZadGMb9Pqbp/tbqRXVY/oGmrlXRsdXAb4zO0cvA5b+1faTHwRTc8N10n d/Q0DHT2b6I5a7ydXo6T69wU64xxHmr4fufj9U93fsStqG9zcr7EneIcqmdUcHAPs6W1sbSy+h4G ZjAaq6vB6o16Nqunh+hiMMoJUt7CebcVt64Qgfv76uTpLtxFmbivlzLxqer3J1uebjn9mmz70Lp5 i6YdmqyVyeBDWXVmkjIsaiyYr5eyn0TcWzRr7bBo9BMTEhIxGuYSV/1gbEtv+yixsYVz7sT1F1pk XaKe4CXaicc/wmWvbaY9fUFAYq7ttJdx60fq63926SOrH29qkHL3i1txyzMvw3M8DW2GmRkAa7TA c2QXysl3NtZ3Y16zAzmwk+ap9DS7N0Y2PljLqq2rratq5WjLysurOjq6CWaVvonVxezqailrPVXW taEO31P3bh1RB5rft4nTVS5voRTfxAXFz5wExWdOnyqq/InOEDGgMq5+mppKLXhY1NgE0MCB7Cw9 N9V0b8agPbNu81+PhpYFm6qYZ95ncrZdp5P3bhk693xL9LrVD+HxQmye2Eq/gvgRZsTO0c5I2r7s vXOwVd5+4/bedzAjcd/BQzfjS+E5ZWjVRXsBtK1ArcgOz6t/kR/a0FrVVtHOGigZRSZ2a0dbW3vr QONotWmvuFLT5+xzGUJ9832XDFzCv3z0Muk1fYcGvi2+a/Qu6THx8dEPme+Ja4c7Bc0b9Dp2B13T pNy5g6bu6aVtubkJ72zCQ014QxNuOqXpUtO6twjKtkwMlnUPMjd0T2xwMB2OkV42wSvprDsIZjNq jCOukkd2wyOwizyi5XbxWi+0kxWP3MJbgsh1OYcee3ny1GmI0Pkzzebq5hcnm03FoGx+bbKmtklW s27aM1AJxj11/q+aT56ahKuGmlrQDqlWdt7Q9pZni6GLKDOPrEcsUTA5VeBQ0dwzMirpKcy9Uclm XAjhxiZOA5cK6kLccosx39SBhwtOqy9GNYSzt77DYdqy3WAZyV26Z9awfzyyutRZtfGY3rutVXCd LrLn9R/q8hxcdahv4IHdV7Lr6jo4XV0dG/yte2dMV/8yu3Qwcjd+jmDKvJdetO+CSy/8OKSr7fqS RNJSy+numKyqamoe0DkXm6t4N6Yvv79tQ7I3sv0RbQ/BaG3rZXfRCRpBsLd986mx3rahGfr9sM5z EKKrYH3vQ4/IFxtYDZ0Eq5HVRJQ1ljWV9JT0bmzc2NTY09jb39jf5G30NkUbo02RnkjvPzX+U9Od jXc2HW883tRYXcpuaO2lNfa2cOuaYDEfRR19WzfRuR2lW7k1ox0NI1xOCxdSTTmthN1HryxFnWzM 1lcy+3obG8pbW3jVNbDy3s8r6+Ly6LQVYvdRXv/QidPbqLDYVtg/tm3beWpyZ23BSRgcNjAwgKq3 bXuRomWTQgGenEGTozuwpEbc0yvh1OygooVaUpsaOJJCdXGFKNZwpBI+iS/fud81f8PQ6Cp7tK+q WSuZ6RtdrRMyhzT0uu3CUtGZR4y2y76zWq8eqBAKWT1K/EcNd6e/9swvlT0sIbUzguWIMsalsGO1 obBcWt3AbiUqK6pHKzraRjbVcCm1m7gdrTPcpppqWkPbzlI8VIpL5QRuKGlrLWfIO1mY1VXdAZof a2zi1VQfJ3aj9iHQettJ2GZOgdYwXScLcxfUrX4Rg5611ERb3zdoIzAh1/UtqPXlSQU5OUkqJr0j 9R28HfgyUKiZwZucVCgg/VVfVtuqIbw7Blmij98vKFH0/hh4fzO6Q57/WvMr5URjaUtPI79xsJ/d 39nb3d/Ty+8dHOke6RnhjwxqujU9Gr5mcKp7qifEDw3u41626Rr+NYNPbvzdxrZre67tJfqa+3p7 4PmfVV5aj5gdpaimvqO2hN/ZTkMdHZvLm1kbaXV9dcBC67uyA3cIyvv6eQWHC4aGTqye2bat+uWZ mibZi5TS1LGhadtOODqcoYqlBTd/zssYyALVANG2AcOWuu5uqKQxG4q+HhnkyfAeTG+qH1XgB3Z2 K3bcjC+vaKxd7eL313B+NNilWW0WVg6o6HVkX6Xo4wOY0dRfwa4vGRoqrWrZceuZX9ewaEIhUVtX zh3CdaK31JvLhEXv01WwTvahfvSQfLGuE1c2VjbRemi9G1ltjW1NVMC4qjyNnqapqkRjounaKipk 7m68u+mhxoeanm58uqm5orGiiaBih+ht5Lb8h8ApzCBuF0QNncbsW4+Y0pJCzPQz+/traJ9GzsBn kTPAGzrxMRU5qzCR1vcTKnxgKtUUJ9Jjj30aNTOfs2fDfxI1zGINhrAZUOCLhdftuviqz8LG00zF DdFERQ7MLkGp6GqD72uHV2vUfczPAsfUWwwcsBgNDcL54unCWW8j7Krzcm0/7qZ1M/vL6Hc1vU1/ s+TN8r/Q3y95v5w5VT/VuFC1UD1fP99Y4iqPVUWraW7kprtKaA2wwW7oLmW1MFtaGCxnLa6VM6gz RZtnI94oZ1Fba1srLCKnJqvfPzX52cZKre1w4claNCxCDfWI24Uk9M+Weli26wYx88lnMG0N/fNT qx/hwUZuJLCDPDfCbbqVOIw7Vn/53LOrv8Dsl15x7j3x2zef3et5EZ+mTsqrXjqlXyVE06PyC+pb uO0DnC9VONodHU9sfKL1Kc5LnW+2v9nxRufbnNPtG0raMbO9t0XWomtxt4QYU+1THZcwbmRd235t RwWcygarN9NquFUdm7duquV2NG7l9o92DO7h9lNfpjFovTX9XZt7mmtZpYzKEnsbs7Gk0t7F2jxY 5aJhmvxKmCpgCnm5oKmrl1crr8E1n4TY6cnCojp5apJaXk6BRWqonU9GLaqF2YGLUTZDHVzXtz7q YIo/mySw6hTWIKJwSm2gtjiYHMQTvQ1yvwIMdeafFYJBOb6U16ebvvWlN2+3j/UNYMxUW84857ja cv3Sz7Itq1Ud566OMIdIOkM+WCa6VMPZ8t4ff736L8IWwZF9NZZtDB61vsITAUE9EcjQFvSGnNdQ 2zLoZF1bcYz/BP+3/D/zSytrCH5/bffgFOupqid6n+h7ov/l/vKDsKit4N/cK7tXLlnBZfdxNt9M HTZx9N6We+WNUCO3ceq6ywk6u7uOSe/ezNrC3LKlpbqCSesiyru7mPKNHS33tnVwdK07tH9gYuZF aGDPwMEB2sA2ubRDhjs4si7U9QYcWi+6pXqp+pHq56rp1du2Dp2As8fk6ZMt209Vn2pprqZK86fn oXj6VHMLZd+Zs452TbLqlj+0wMxE67i4sNUNw2FBVDjMDuHi4QIMTT0TDNdwC0e8hvomeHAoHCeo HWAIFw9+XCyWddzuHDf0NQqvz4slh75Bfr12YwNzUNx+sVul7Gi3TEcEE9/5Tr9tO7eujFmzEZ59 PHjk6gXtltHehmbDVrX6nNyRgYa61Z9HLjDyN23q7h0RDU3MzT5e01DBJFo7ab+lniA5a28SNzHK UAcKytmsNtygbahhyTGHhaZLy0rkbZwa/UZWp7ye06BlrUAMVsiZnNJKXjuCpg5qc2MPfdzyVMsJ WJdatj/b3HJy/pdQfAyO+IB2nqBqTxSMNT9EGaROAjNtlFJ+uIFbU9/0uacjSQ2ntU8yNGkU//jH lfWb+0ZahZtE7q/oRiI0h2xjl1A8Nbd6yHvm+oH2QZmo2S6ZbBVfRlxPPdFWQ9pVxmR+8ib0v3Ex 4LhMRwwGjXrpymBARqchVE7Jpn1BsktoqAQewBklRdms0tIvQHYJSGegknXZJeuyK8rKvjjZTDoC KzBLIGPQEaosL/8CZDNBeglirstmrsuuomTTvyDZpXTqLXkps5RyKEIbWKwvQHYpSGei0nXZlAtL QHZ1RcUXJ7uMjsB7ZaVlRdk1lZVfgOwykF6KytZlU9ODCbJrq6qo6fnFyC5nIPBeeVk5NVkQqtuw 4QuQXV6QXc4qgQMGYpWzirLrq6u/ENllAGfLLgXZDTU1X4BsVkE2q6KEeu1Wwaooym6kZJf892WX A5wtuwzip6m29guQXVGQXVHJhKMPqqyopCYiQs11dV+IbBbA38qmvp8s/q1KVWJ18+rmqq3/4a9A 3CUy6rvL4vXfXur/P7jo1PfWcNGuKLz9pfDm9fohegZxCBn1TAPlTBF/QkP7IOBPbUlrR2LiLuCh LO5G54Ij9kK4EbCzViM1xNpbZS+B0LPfFlOvS+nBRCq8ThsyRZr666TLfdPTCfBQI/iyzx9NBGFl 3EF5LODjBzL8wAI/6OMH4WkzxQ9l+FNR/tQsPwKfOX40yI9m+NEsP5HlJzP8ZJafSvCn4ZPlz6b5 mTg/M8/PzvLno74pvi/jg5Tl+xb5/hB8kpCADPP9s3w/9AJ9hcNn9eebp/oMZvz84EKaH/LP8UOJ whDS1ChCWX5orjCWaII/laaGNDUHaYEf9vHDQX44wQ9ncvzw3CI/PM+P+HKFEYOw9VGH1wceSwb4 cV+SH4e+4iEfPx7lx+P8eAI+KX4c+OOZCD+e4yf8/ESYn4gXVE3MpSEt8BPz/GRolp+cCvGTYfhE +Mk4P5n6xBR+fioInwxllFSKn1pI8dNJfjqzbqGZOf5skj+bokw1m57iz0I5Bx+wmm+Gn/FP8zMh +ET4mXDBlAl+BmRn4AOmBYZZyrqgYxYskg3zs3F+Nk1ZO5vlz8X5oPh8lD8/l+LnfCF+Ls3Pp8N8 MOTi3CezopnKfoItaCuyUmTAQs6MRSO2YFIhmRJbp5zuaMAen5Z4tNN6+3Rk2CdwqqaS2aRHbJ2z CJ3jdgGpnliwDCiT3imlTuMPLuYipFJqILVZozovHvAsZEWOpEAUsJo1Y+5EcEKXlY65NBqrzeEO OnMLJoHCMrEQ9JAiS9xvt45HdUKzOpYOqWOSsCcVzAVJzbhbaTAHHZb0VNgLDRLjhFCdcMUkDos2 Mm2M6k1e0XSQXDRLjSmLeDzqmfBGzAm91RkJiLJGczg9rxz2xUJ5S9rqdOTHFqbdyuGgKajMGL1O oc3gNMhA/pg1LpuwKiVap84x4ddZF1wph8qjs6hspNk8oTGTVlsuaYgLZ/0KaUY1rJn3aYP+oNiq CtikOo3dGvM70gPGmEFKhoMRnTMSN+nIlHUhbvForDNkNBcfX5x2+Z36IaPOKzJo0+NerVcZEmjC IUEuZIx5U2pNcFinlOYMC/CQoMu41fGszZUwhANJZ1yjUAwFNAaNJhkIKV3eiTFlfn7KlRHqF4OR KYE05YzGk0qbWusPqwMWtTcfFHlE9mR4ODCssWlF1pwtFdR4dTPzE4vp6fG4Y8GYkKWMww7pRMo7 q9EGYxpLUGYUBTLKcMDuSGQTdoXBYXJEhMZkTjQVV5u0GnPSbnMEphLiOVPeY/BYBDq7O09aVGrn uD5r9Io0OpNdEVaKSIuSNKVNcUHaHJWZtKQn6XYrIgYlmbbaNTPaYYnYJfSGx1LOoF2tsFvd0tyU WjHqEAbyHlsefJ03ji9KRLqUOhtRBiamHMIYGU4b/Qmz1hPOKxUi/aIxqRZOJB32iZhimFSQwbFF i23cKp3wiEwZTTKeCOaz3qBIYPbkMrHxlMWgt5CkX2FOBpUmp87m1qlISUzlyOvU+bTOrNXEgiKz xqHNBbRuvdJLphfGk3qNYiFt0cQcNqXDJFBZpVPGnHVGafH6Qyn1hCXp0PqTJk1QKIvrnFKnJ+JR q8WSqDeSng+4NFGlVWEaX7QYzG5DXmURB0OauHJcDTwRyUwwHnGZwzmfR2TJBmJ54wQYQWMTG4yL hoRDaxozRcVKT8wa9tmzQZU1O54XxS3KvEkyrjCM2BUBlTqXzk3pZNN+gXnYtGgaUEY9C2qXQqfU eQzmpCnpUli09kWpkUypA4aoY8xuEeeUSc+UT6GZs+RzjilBOutIzSmmBELzlDBATjmlXo8jTlrV waTertEaVY4Bbco0ENCaLD6Xw+IVSqfH3OKAMpaLuEQmvy4vdWuc2VGVRpPzLU7b7ALhvNmdHpkQ 6jNKn3nMLHAmAxpZyhDJzBgXhN4xQdyl0aYtOpskH9SpfRPhtEoxbLIF3bIFr9A8oxeYXT6hQWLW iGfsuuysRz0dstidIYjDKaslY/UlSYFwWBbxkpZIwK5Wk4q8U5nMBkMqfXgq5RFatNa0Jq7xuOyG pELjWHAlrQqrkJzwRMKkWmAYMi6qE8FFk9OfM0l1Sa9bl8pqXVGrwZ7wKR2J+IxeZ5V482KVc1Gh 1sWmZ/U6yag5qZcEXIIxs8qkJnXT2SlBcCa4aE1oXaQhoJpWGhxe55Q9mA6mpocCSsWUXpDJm8Oy /MSicMjsdTp0CUMsZM+PWzRZ0URU7PC6BHNGrUkWCKezPlHQ54ikh5yL5kW3IBd1KKQRm8Ax71Bl JaTIO+1WmRXBvNA3rjKLAo6AyK6Nz/nCgpm0VaHS5qypcUciFkiZ/DZhZsyS9PrtyviMdVghcKmn hTaB2W7TSCIupcSusMlsY2rnqMPlhDmgdypItckmyBq8qmm/V0FqVYr8mFIXDfnjhmmTLau354Jq /YJp2JwiByw2DdhKEZlYDEZdAq9iIpYTmkWk3hTxmEMLTuWEY3rRo0zkNBZJUKPxDpG2iC7odLpt Meeiz2H2hvyRpE0QMGkXTMmxqEZhiGWHTanEsN0RdI2LxGRQGIhN5BVZtcgiI3OKpE6dmSGdkrDK Na00CYX6oFqw4LBqZgMQ725dYN4aCSfH1epMfjhAetWylMWhn9Eu5Od8uTCsR3qf1ZmTmVVel1Mp WSRF01Knkgxbo5JMQBSZ1qUks+NRb8IplI3bcwqjNSWIhIT5qNvmzPlFkowvN+UORaUhrSUzQVrI AVIXHDKI0u6QyDE14U7E9VZT3Ks0C7wiMqJeME2TeWlOGXHG/cPZgMs5PWOICkU+q9BmtakXDAvZ lFmdl7g1aqFDHI44hz3RkEY661MJSat7OmOOCnPq1DRsJPqcTyFU+ezmiEEUtni1iZhTl13wWc1B U1IhMukUOrctmBpXhkmv1qKccMtcQZdY5ot4TLBCztlcgnFjNDzvt3pTJqEjqYhalRPRnEtjtWp9 KvGiKRHPKJKWMV90WmFSpX0abc6lVhjs3nBCalmIJKH/OVvcpB23OZPeRcu4MuXTenS5jDHnTavA p/YFz6JuUSbyimThQDQs89jzPjIsDAdFWYtNq44ZSIfFqJIJTYlgXGGNT2hieoNaaYXuc76JiMkS SAaH7QvmhGJAGNFo9W5vXDzstojNuqQgPZHMzAVSToNSJ1MY7eSUN+I0mF3ZBZ3DMaFKmUIBu0ei 1CUCnnAwE9AqLDaLw2NTiIc84UDOYdPMeRxhc35BMBS0W02eBTLgsVjTyjD4yE4Gbbmw0ucSiEyJ gIKM5IympEDrUUtnVSqJyqcwOY0icdIC9iRjiWgwpRZNOByzapvFowjn856YVuFOmgcUYc18IAe2 GxYMBIcz4qCdhCjIicwiqdiVsybMMYvGrIzPT6hNCkVEP6WJJkw+UuwzWfJhZc4xD+ei2JiWVMMR 1qGPBWImU0YZHFZr1MlEflxtjagi1pgvCX6Nmh0Tdn3EExZATAbSNgc55hFGYipY87xKjcNkF6f8 pCGstKiH3AuG6fGYRejLe4QqpVDht8fF+ZxYocllzXoyI53QmRNBUhKeEORz3rBj0TOst6jckaTG YkppUiaTQiUc0sdyU+Okx6gJZ9QTSoVaAeuMJyeJK3KCjEWXnwtZpyPKZEqnUytssO7qbHlP3p/M Ct3RrC04LFMpdAGFn5RILDGPwbogdnospCo0LLZ54lnRmI6cUwgSSqXIYPYNq8c8UdnYmC4bNwkz iz4yM6YCUaa8IjpmgUN82OJyOePTAYt+KqDwqMB3sZCLNGndMAHCDpdRbZHqY5L4xLB5RimUmDz5 cEw3rIBTRd7mjhrSIVU67VvU29WO+GLekvObdN65gCXvNTlInTYWD5nCORepy8XtFkXG5rbmjRav YDyqDupsiplAMh0KxJ0iv1Wg1IkEoWBYrDIm9OmgyxLyJ+OqgEWc0btGjWaLY8zj9kbHNWa3UWkJ +GwCQSDlmbfEhJIxkUHkUXhmAotSvSKsn1O64iFvyjCgCeuzyrAi7iUViy6XJjKWtxi9i1LblNCQ VdrCGZjNejKWHfNprboxhXReNxwYsMQEOpUjEZ2IeEivIyEmybTGF5GGvBbNmCeXUxohalULsvy4 Iyf2iaRqMmYWKBUajTEqkFhyFrsnGklGNbJ5pdokUJLxnDqWGfUrpvWKYX3OsyCxu4aDQ7pweiig ksy6nIZpMiGMBi36nMYulXhcjhG12zQfsBqyUwu5wIQt5zKFLfmJYalIGU/pfBFHyKd05gxh5yis LQMQQ4sWrTfvVTnG/C6pRqPUR4xagdS0aFGorIGR8aR5zm+xzgdjskW/KDdtGbbOkinYk8m4Qi/M 61RWsVeVCYwF3cGgM5wedy+IF8dIWcbuyoqDFmnMT0rdcL80YA+OGF05mzLnTEzAs4FSI5sNDge0 pNYR09llgSAZTKlSlkVHXKCGxdDpS3nMebfEEEzm/GYyYCfDmiGryLFgSYrNYCf7uEsaVAsTWaVb r/IK8qlA0uQJuKQuTTITt4aDabNKKgwk9UF3TDAXWggI/TBHNVrrtGtRZTSKpNoxhcfkVgekZDQ8 EFRIZr0LziFFRKYmLYq4yeIZcKccMkNUACdoQxQ2UdWUIDtvSpkyqlR6IJDzBEidXu2zK3zemHlk jHTGg5lgVO8UzpEKh9BjdeS8Ucu8OpXOeuwmEynKT1vcmllPXuzwqNSCQMww4Up64kadXqQCX7ui FotKkM8rIx6XVyAdcogyAZ3WpPa6pLJUNBEed2TUmiTp9CwaYv5EZGGMzOntWqnAZ8mEHGQm5NfA IuiAs3k+GLLossoxW1ioHpaOKuNZo1vjEUwMJwwelySrVZgzDq3X68nNasZE+u3fW76v+463rzz+ m6uuYh/6U/7Zzn+t1v24/YaOqvLm/FF50/PPfRD8ycEB9d0/0nx49Yun7rzzpOPt5a39D7p5hx// wUjd9a/98uEtjl0vP9Xw0QXyn25+8Llc0+ReK3vW8f7YgZJfj5Tf+ZNv2bsGJCXTHd2GOfPVN8mm YnVH73r0vuFnLhjat/Ug63pnA2Pwg5dP7bn16Inbnht48pL6m6YOvf/KryS8Czbf+p3zS16/5v6Y hM0T/OE3f/7dzt4Lzr9vU3/5o4/e+vjhw5ePf08+ybzg1XCtg7Px4Y8GNX9eTD18A2PoV3tmD/al V6Y+vv/lCw/cJv9t7e2E9sj7q7sfGHIYj39w6rVTH6aFq1c903h86286L256VvoV8S8C9/InlM6f fN/V/ut3noms/ezEkVsl79yZ6Hpx+9dG76/Ye238y48+e905zwa2P5x1vle/M3TOX3Ivbx+tfuKu b4w6bj3eunRy0Sfe/sqfegIXXfK1Oxae7nj1XP7FVWtR2gMZUYX129eWGM3mK+KbvurY2E00PXX+ V9UP/sL+pz//NvFNfFn7O99+x/27uW994Bs+79jRR/mjKvHlA73mmzVfDX39cr/Kpa/e2/38g9KN /nBF6SsvnPeq7dE//MKamW/917Cjqsql3qP9rlte47pLeOOZ1y6szuz99weuqLLNHZNdcfDil1q6 U6+63/ipxDV+Zf5AwE1cc4Xq+e2XXnrv1dF/O3Vjn/LoixWjt179Rmfxe0OMahENYXoZIgo/XlOg NEqgIPr0XcJanvp93H+8VtDWgRUkhNQ7cN/BkoNMomGF2L+sZdevEPsA1a0QlwGqXSG+BqhmhbgU UPUKcQmgDSvEXkBVK8TFgCpXiK8CqlghLgLEWiEuBFS+QuwBVLZCfAVQ6QpxASDmCnE+oJIV4jxA jBXiy4DoK8QiINoKsQCIWCHygHCxhKAkb9Cyf63HP9XjTh7uHMUHPfjgJnwlOUTsBu2rIa8m/KD9 zUQAymtEEPJ3C/lzBY6fEiHIf0j4IL+nkBc5ryzkaWIK8nGgx4kwSGEXuNlEeBmXykkWIcYn0Ayq xI8V8sOFnCmvn6k8MVP5/ZnKQzOVe2Yqt85UjsxUkuX4Z2gU2o8W8lAh75GzRivvGK2cH63kjlIs v0MeqDYU8rZC3iSv91Se9FQ+6qm82VO521Pp9FRu8lSSjXgf6oP2rxbyiwr5YiGPFHJrIecV8hp5 TV/lz/sqb+qr/GZfpb+vUtpX+SDegI5BW7m86ljlG8cqe49VdhyrPNZa+X38E7QBVy1vQGXH8U8w tHa0ptgr+C/Lu5oBnS6i95Z3tQN6d3lXN6B3lnf1sMmN+LdoVynYB7+JdmEn4N+gW+hU+TUcJyj8 SxwvlF9FPNwN+OfLvAfh9leK6OUienGZ5wX03DKvD9Czy7wuQM8U0VPLvA5Ajy/rOwE9uqzvAfTI sn4zoB8u64cAPbis9wNaWdafBPRAEd27PJgAtLw8eCH7IbyEBonD0P2e5V0bofYry7vaAJ2/vGsE 0HnLu6RschDn0C2FMWbXdchA+QbAM4Ap3abRgUJ7Gh0otKdwvFBOAqbaYzhesEUUyQv3hUFnCgeW eQbo5pxlHh+QZ1kvBORe1lvZZCV2IH1BmB3pCyO0IX3hponlwcPANr48eBLGb1ofv3F58Fk2WYbH 0BCm7tKj7gK3brn7JuAWrntlaN0bg+saDMDIKdyP5AWv9CJeodNuGCHFxy36oWuZdzUgzjJPC6hz mdcPqL3ogOai5RuX9ZQudZR1H8LVaLBwP0teD/1/tIvN/suuTewPbznJ/gDS6ePUJFhm/4m3grvl Tew/8k6y3+GJ2Kd4QvYfeOXsNwe57FcOPEiNBL0AHJ0N7Bd4Nezn9bXsZ7tPsh+D+fbjXTexH+H5 2T+ECXKPfIWO5RvYR3hi9t36CvZhfYJ9p56qq2PfCPfcoL+afQ3cdwUvwd7XXay/SN7CvhAmSQ7k zA62sacHV/AN97PTgxJ2cgjIZXa8GwZ3PzvWfTU70r1SCsMNHFghsJzF/hKMxavnsx16qlzOZpbw 2DSCR61TmeLCNltcw2aKC9t0cdVKF9ewc4rL1TnF9e3c4lJ2zr1atnYIxN3PVuq72Nuhp8PL7G3U YJfZMn2h++HBFcpoglsoo0nY/ME+NltfznYcZbqYW5gSppi5mdnD5DDbmW3M+tLa0urSqtKK0vLS 0tKSUnopUYpK61fWXpdvovaC+pJqCpXQqZxOUDlR/DqZwKUEMpDNxD5USnwN0iWQLoZ0EaQ9kC6A dB6kRUh5SPOQ9q29fi9193FiH3HeseoieR6xuF65SFyyTl1C5NepPDFfoFYAU30CPmpA1K8slvAV zY3zO5t31u6okWlUfyfbvZ4PfHY1/2c3/D3es0jcvnTtmM29dFe7Z0lEEWvtnrGlfupnXMeJEUKs Vh0nJBTyuI/jWWJEbaXq8azKA2zGAhu6hZAAG9pFIWCjdaFbKDZ0C62rwHYZxXb0wC1q1dFbbimw MK5HBwosBxjXF1gOFyXxoAOQJKcQsJWUI16BjVdSTrHBpCjw4TiSgzC5vMC1cQOOU1w4vnFDQVhj ob/ubmDRd1MsRwe6geFo90Chufez5kFOoTlebI4X+8CftQ8Vb+cU2znQPvC/6Qop/m/vuHf/65fd Tv0MbzdXHYK0e2n/fKR5aY+/s/PoZa+v/z6vZ7c/EKGwL7T0OjekWrqMq+o8uv/2v9N8O9W8n6s6 im5X291Hb5eHVMv75fsLv96713yb8arP9XXZp30Zb/s7wm6jhBmpvsxX/Z3mq6hmM9XXVVRfV1F9 meXmQl/qqE2ROeuay2aLxN83Qwatn/uo90cEKkHn4T2oBEfWj3wE1LOgnYbKC388w4ITI/XHKNQL e+oVMquGhSpQBZuFKgFYqAqAjjYAMAtvLulw1qwBug3VgYx2ACbqAGDBes6uZaFOABbiIE4HC3FR F9DbESxLaAfaAa07AahfrsihVYlIoCeRClrPQedA67kALLQb7YZWHwALXYj8iPo17kVA70VfhXF+ DV0C9GUACF2J9gF9FToI9NcBWIVfWDPQNega0OIb6BugxbUAjMKvrhG6AV0PPN8EQOhGABa6FX0L 6O+g24A+BIDQHei7QN+J7gQJd6G7QMJhABa6G4CJjqIjwHMcLUPNg+j7QD8EwEQ/AGCgh9HDcNcP 0Q/hrkfRI9D6OPoRcD4BwECvoCeh5l/Rz6Hmd+g3QL8FwELvoN8D/S4AA/0RgIX+Hf0JbPs+Og30 BwAM3Io+BIe2w2GRhfm4A+jNsM+zsAB2fYRFWAi0FA8DvQXLgFbjrUBrsQboONYBncAJkHMeTkLN A/h8qDmOV4B+EIMW+Af4IaB/iB8G+nn8CNAvUP+3Ar+IX0QsQoRfgokzTAzXwFmYELNZsGxKgB4h RoAeJUaBlhJSoGWEDOgtxBagtxJbgd5GbAN6O7Ed6B3EDqDlxE6QpiHA+7RDhBYm63dpYHPaHbQ7 gL6LdifQd9MOA32EdgToZdr3gL6fdi/QP6M9APQLtOeB/iXtRaB/T3sNsRi30t5GiHEb4zbEWFsr /D8M9H8AB7UbdwplbmRzdHJlYW0KZW5kb2JqCjE0OTEgMCBvYmoKPDwvVHlwZSAvRm9udERlc2Ny aXB0b3IKL0ZvbnROYW1lIC9UaW1lcy1Cb2xkCi9GbGFncyA2Ci9Bc2NlbnQgNzUwCi9EZXNjZW50 IDI1MAovU3RlbVYgMTY4Ljk0NTMxCi9DYXBIZWlnaHQgNjc1Ljc4MTI1Ci9JdGFsaWNBbmdsZSAw Ci9Gb250QkJveCBbLTIyNy41MzkwNiAtNDA3LjIyNjU2IDE3NzguODA4NiAxMjk0LjkyMTg4XQov Rm9udEZpbGUyIDE0OTAgMCBSPj4KZW5kb2JqCjE0OTIgMCBvYmoKPDwvVHlwZSAvRm9udAovRm9u dERlc2NyaXB0b3IgMTQ5MSAwIFIKL0Jhc2VGb250IC9UaW1lcy1Cb2xkCi9TdWJ0eXBlIC9DSURG b250VHlwZTIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovQ0lEU3lzdGVtSW5mbyA8PC9SZWdpc3Ry eSAoQWRvYmUpCi9PcmRlcmluZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50IDA+PgovVyBbMCBbNzc3 LjgzMjAzIDAgMCAyNTBdIDY4IFs1MDAgMCA0NDMuODQ3NjYgMCA0NDMuODQ3NjYgMCA1MDAgNTU2 LjE1MjM0IDI3Ny44MzIwMyAwIDU1Ni4xNTIzNCAwIDAgNTU2LjE1MjM0IDUwMCA1NTYuMTUyMzQg MCAwIDM4OS4xNjAxNiAzMzMuMDA3ODFdXQovRFcgMD4+CmVuZG9iagoxNDkzIDAgb2JqCjw8L0Zp bHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCAyODE+PiBzdHJlYW0KeJxdkc1OhTAQhfd9illeFzf8 gwtCcsVrwsKfiD4AtAM2kdKUsuDtLR28JjaB5mPmnCmnQd08NkpaCN7MzFu0MEglDC7zajhCj6NU LIpBSG4P8m8+dZoFTtxui8WpUcPMyhIgeHfVxZoNThcx93jHglcj0Eg1wumzbh23q9bfOKGyELKq AoGDc3ru9Es3IQRedm6Eq0u7nZ3mr+Nj0wix54hOw2eBi+44mk6NyMrQrQrKJ7cqhkr8q2ek6gf+ 1RnfnbjuMIzDaqc09ZRHRDlRQnRPlBFdiR78lMMv+XW/HSa9+La0pu7Ca7PIU0aj8yt9pGFZ4bci OXzJaf+RPfBbSnw1xgXkb8Uns2ciFd4uTs96V+3PDwWHj9cKZW5kc3RyZWFtCmVuZG9iago3IDAg b2JqCjw8L1R5cGUgL0ZvbnQKL1N1YnR5cGUgL1R5cGUwCi9CYXNlRm9udCAvVGltZXMtQm9sZAov RW5jb2RpbmcgL0lkZW50aXR5LUgKL0Rlc2NlbmRhbnRGb250cyBbMTQ5MiAwIFJdCi9Ub1VuaWNv ZGUgMTQ5MyAwIFI+PgplbmRvYmoKMTQ5NCAwIG9iago8PC9MZW5ndGgxIDIwNjY0Ci9GaWx0ZXIg L0ZsYXRlRGVjb2RlCi9MZW5ndGggMTQ4NzQ+PiBzdHJlYW0KeJzNvAl8W8W1MD73XsnabEu2Y1uW 40iyvFuOdllKnFiStduWrdWSqElkyZJsyUtsxZINgUBZiqFgGgKU0qZ0YS2NcVNwWJpAs9ASthIo S6DwCBTymra8FmiBWP9zrxNI6fv3x/e9ft/vu6O558zMmXNnzpxz5syVbIQhhMrgRkPyPq9MeUNs 5SGEsA6o3To0nR6nzTNlUL4dyvboWGQSv5wohfJJKKejMxnRqwt3JxDC+xGiO+Ox6ahBsbINIQZJ L48PRzKIjq+D8jEor41PJsZuCfO+C+X3IL+USM/Gn8DLf4UQ7ycICVqSsbEca13NDEItLwO/J5PD kdjvr19/A7RnoL82CRWll/JeBdbfh3JdciyT21KP/gTlQzCmremJaOTA0DILIe5BaF8ai+QmmUvs YoSUdVAWjQ1nIpIfcrugbEaoNDAeGRvGPi1QI2Qmx9s0OTGdyafRtVA+RNJPTg1PSi76cBrKMF/m c5NTE5OPr7zzAUK9+xAiaPB5Cn8U0WH+j+Lz0OO6VYi9jvpxkBL0IW8s8oYwdN41OTs1jYxIhDIF aAXKbBWRFCFsTx9QEfvoYfLp5/fBH8Yfpm/HnkX/uxfJiYBcCOu8FeAaxIMyDZ4iRToUQcNoBKXR JMrk89SzpUgOtVGUgNpxNJXP59/+cvrHGZ276LdADiMx3Y9qiFuQAKH8K5DfJvMKzIseRRUry/kX CJA6+vhsXr00KINc6D2kRQ+izTC269FRpEY0TIJ2ojshWTAVCqML0QPoU0yOlaMY9kug2gz030Lf QWsBetFhjEBdqA3JYD73o7fwg/k3UDvqQGNoAk0Bv2dQJZIgOzqG/pq/P/8USOGH+RMIh5585IO0 Jf9o/mNUBzLpQh4UA7lMoKvR86gGRtKFrOgJ9BJ6F72HFWMN2M3YPsRApcBtAF2OTqBT2Jb89TCi BniiHtnQIEh6Fi2gRfRztB/a30PFyIDM6Gbg8iz6GBNgNVgbPpJ/AqSZB04CVIuaUQtaD/03AKUD uZEfRj4D6Sq0G/0A0iMYhpnxBoJH/JJWQ2uhN+fn8m/k30QBWKsJinI3pDtAWvvRC+htlMdYWCEm xMSQWjEdpsfM2Bj2Ixzh8zQe3Z0/mH8B9ECHnCCBAXQ3uhf9BKT/GDoAEnoF1uZTDMETaRgb42PV mAxTY0YsjN2GncQ+waX4Zvxr+BghJmqJnxCP0tvz2vyF+eX8U/nn8+/lPwKp4sCbDjPjoyZYERXI cCM8qQeFQDZxNIrm0Y3odhjrg+jXsDLPoVfR79AZGG8D1gwrPIBFsRS2DZvCcthF2A5sH/Y+9l+4 Bbfhu/Cb8d8RH9MQrYrWTbuS9jL9Svr1K5tWTuRL8r58JH95/qr8Qn5X/q78vfm9+cfyf4NVoYN8 myApkBJWZyOsD5m6YTR9MJ4wpEGQYYq0AZSDdbsYXYO+iXbBan0P/QjS/TDKh2CMr8MY30YnYTVP QTqN/goS5mKlIJ9WGLMeM4GEbZgPpBSDcd+G3Y7dhy3B2PdhT0A6gb2N/RX7FG/B3bgXvwj/Bn4j fhv+CP4EoSa6iUuIy4kbiAXiNuI+4h3aT2i/ph2jvUcP06P0FP0i+i/pbxewCm5dWbcSX7l65ccr J1Y+zhfnTfn+/NH8i/lPwbZLwXIbQdLtyIQsMKMRkPEU6EQWXYSuhHQ1+gbM6hqQ+i7QkttAT+6F ee1Dh9BhsA0y/Qq05kVYh5PoP8m5QVrVAYQVYWWQKigdMIAW2LA+zI8FsEFsCxbHRrBxbBq7BNuJ XYldj+3CdmN3YPdgy9ij2GHsKexF7CVYuz9D+gT7FGaP42vwcpyPN+FqfBMeAznsxvfgd+L3QNqP /wI/gB/EX8Bfxt/FT0P6mGASxUQDYSe8xIVEjBghLiLuJu4nXiVWaHRIElqcdjntRtoi7TDtXdof 6UL6HZDuo79e0FCgLthccCukOwreK3iPgRhxxg2MXYzXGafRn7E6WL8/oAr0DSyLTq66IMKM9uLP 4cPoLew0Voz24degErSINaOn8McJPupHKZxAPdhukFc1JqVnEE7vRjWQ+eDrys76udOQT62YwNdB 28pj+ZeIdWC3OZD3+VcS7QUuCLsK5TAboccLQOe+Q3eAJ5GDDyDTOf9PzyaSGYSJUDaWSZIQtuUM 4u/qmJicnoNVR+ORdPxzL3/OK2MUxgcE7BAjDEqFXLa+Tdra0tzU2FBfJ6kVi4TratZWC6r4lRXl a8pKS3jc4qJCDpvFZBTQaQSOIalFYt0qWmzYukhrkNjtbWRZEoGKyHkVWxdFUGX9R5pF0VaKTPSP lAagjH+J0rBKaficEuOJOlBHm1RkkYgWnzZLRMtY2B0E/JtmSUi0eJrCeymc1kAViqAgFkMPkYWf NIsWsa0iy6J1Jjlv2WoGfvs3PfKntew2KdrPe2fTIxyS8yLqiuxI8gGQFJZFgcRsWaySmKk2ot4S iS32u4MWc7VYHGqTLmJdUcnQIpKYFrmtZ7tTnBcZXYsFXcBaNEJOAF0rekB6cP66ZR4a2tpaGJPE Il8LLhKREPmIktbFSol5sXLuJP+L4jnMct3ZxnegcRGvt0aG560gmmvtq8WtZClyHZS6vSLgiV8Z Ci5iVwJjETlccuirkxiWWMiaraOiRZbEJEnOj24FmQvmF5FnVrwkEBj2w2YhsIjmfUGJeLGzWhKK mNc+sAbNe2Z/VmUQVf1jS5t0P/+SjWIQ2f42Y5uRhBvF/EtW4e+/vlr/m4Mciu7QmwC7PZ9LDSMH InHALBZFUREMICiBqejI27AOzUd1QAZXCAMhjCyyurbO8zaQMqXX8ySi+Q/B7LZKTv/hH2siZ2sK 6nkfIhIlF/tzhYH2c/hia+tiSwusOazPMCwTDG0zVaFpk84sVksmeaLFahAV6gc5RkIbZCB3sZhc smuXDWgICos73cHVsggNVS8hg6w1tIhvJVsOnmsp95MtO8+1fN59qwS0cR9lgOWLzIbPP1xeRZkl uWERq/gXzcNU+zJSSruXEas/+ACGXR9axvJXLiNzzX6IJoktF0KzilT3ETPMHwpqKVS0iAHTSEVW kLsVpB0SzYvmHbF5kVWUBIWm1VMQGobnQzKYujc4AndfULxoCFV/jg6HQhuAj5bkQ6P4zIeAw+hZ DqMUB2BwBojapd2wyA39QXdwcae5etFgDsGign0cBLEeBD0IhYBK9/lIAe4Y4Z8dsx7GrGsBZMMq Fy/wABah+fnVEmjhwfn56nnS0FfLyxj6coXhbMUyohiALSxjO/uppp0ScTVZIRFLxDCskBketRHs 55yCLqOOfy3hTedLeDOMdhMl4c5/k4QNX0XCxq8kYdN/L+EuGLOJlLD5/56ELf8gYeu/lrDtfAnb YbQ2SsKOf5OEnV9Fwt1fScI9/72Ee2HMPaSEXf/3JNx3noSpnV7yL1PP2fQ4psC+i9dDpPUpsY3Y R+v9dyc6G9JsQX/BvoJ9jB3MbuY7ZGKNscbYVva3OX2QnircUVT+RYwy80hwfgu340OshDonox8+ 1rGThK9477Semfrs1sJ32Co4QbA+j2lwOLEhOnk+JuBUsc7ALXBhDBdis2gunOHCmLzjp188fQR1 nn79jEIuKRGXNELW0N8/+umP6eFP7jxKHPtMTT6dvnI1zsV4ENtxwQu0omVUIltGbJlcUaZth9TQ vhlTKSsYBZDok5tGuYyLeMXRTpeztO7l67auLOtauy3i4R6jZ8p/3y1D6+CcI8m/STxHn4JzdS2a NlzArmSsu0tEaEUYk2AUCzABraKwgltRXrW2GWshWmgNnIbCuuI6bntxO9dWE6wI1ATWXVF1N+1O 7sOCn4sF7BuE9DU38ItuL8AKDnNrsdpdJVjJYW41Vl0nkR17advpweOQYZ6dpxVybBBtG6wjh12q UTc2SGrJYePlaypAdriktkHDKytVKUvLsX2Wps1OH7dyk98l7dDETA341OL+T655/KGDH998j/ib nuc/wb5p3SzR3bP16aWVYLxrE1698urKrz/9FUT4cqxzJf8iKTsWRMlhiHzXoksMrYxiolRH09F1 pSPcArSWqC7j0mhEGYGKCVpp2c1wYjhVSiMIWnENdxk7YqguJZCgprqQqGmi8SaJK4ibiH0EtNew 19XIjrXyOjDZYGtHK+8g6jzT0fnhaQZ9/frWQd6OQ3wmXlJaqcd4x3gHeQcVcjSIDcIatWObMY16 dcpUsRgrX1NZUVkuZo1MVWEMGqFvLW+uaKC9fe0jK4dYxWrxxJnNMqIjRNzLW8uUVtIIuqxR0PTp 1ZLN5XoeB5chLH8U5rcA8xOjlIHLKHm39KNSQgAhdLGYy17Gxn9WRhcKlrEpgxBBvIAzkKFYvJOL cREXjti1BtE6sZBxtMIhqZWdmHmDf/q4YNOxYwI+7/i2juODgAv4JaV61Cl48vSxTmh8Emb4JDmd RlLvvpgMWQQFLF9TwMDESm27ihDra3Zt3fzm/IXxwZ42bduGwBX33LG4N7syicm2zyg0PzjDVdRc P2j++OOJ+I7N9T2VF/l2vnjZdR8Or9zXFVmZhXm9kX+buI0+A+ffSw3rWAK+wC4ICUI1twpurWE0 VPJ4Yi6XVWkQiKttlcvYbwyNQroIx3DWibaihuZCXrMCmvpBARcUmKK28GjzmqNbQC9VSlDHwdPH T/KOD34xP2qKpw8Ndp6eIefPF0CFTPA62UTOtYGcmhBbByamhQkzSNWlJn7+vLnQXr6GUSCpbWzQ 1BpUbZsbawRN4sGrn55m/Ljv+pDbMbWhpWvz1GJuecdWvn3r/gc+vc3a8mhni76pfs3Bb/38OqKt Xua92Rvp7hMMb9x20+UXfk/K0d44cvyuPbZWDXiSNxCiMUAeOCpC3zNwBoqwdgLD2BiOL2MhQ01p URFRwKIRNCadxmKdKkUcNhsrwgsRnU4AxRuGRg6TQRQW0tgEjc5mFTYZisSiQnUhXojxZGwf+/vs RTaNbecWy47NnBjkt3Zgxwc3CQ7xBa2dHaizg5RIZceZShIBHdhx6BC/dQfvEADQcbJuPb+Vx+yg rHsQK2NhKkLFkBDiMnE7zvnBmYNE5dc/vE57nX/l7/4VVgccqfVnjhIXfXbl0ZVjmJq00/zvYb3f AU9ZjSYNZXzWzTy8sEjMZLKYh4tgGpxC0OGfgeOsXsYuNtThJ8qL6IdLDByxhT3D/jp7AcZPZ9cA +QL/+/xFPsGvWSs7BjM4oZfx+C/BTGBVT5yGVT7d2XGGms0ZBp0neJ0asbaCWtk60F2GmFFRWVFC LWSDRq1VLWU3XvhAHr2BFeJmx5mPzE+lj+xb/PvUbqfy08OP3XLrqzR86Hffre3asXLm7e/cusUu N4LXR235N2il9AlUjqQoZNjAwlkEu6UKryIaq+pr6yVaIYtzoqamorxCLKWX31BXdJXgZsERwUuC dwV0wbdKsdIjTW0VjKPi9W2yE8dPH+K9dGbwGOU9SeUkx76JcqOUDyVVsZHSRUikE8XAmTLI7YA8 JSNKHXllqB57WrZWtLa8nlfj3txUrqtuUxnw+fBdK/q6DS2RvrmVF49dNLjwCsbF/ktia40MeHb1 aIUbxcprL9xzpd5DF0hsK3+5nFu88YJfvb1ywDaRx5RYEebuAf86CnqppvvBzwYNmirMjtmYs9it GP1d7CMMzuSH0YsgEBuLyWKhwgLsMJPWycJYTI6BLubB3osXcNjkQlFmxztOTfNQZweszczrpCMd JCeqAk9VwJCUibFR/O6VP9/+db32AYL72Qe0beoktvOT+8jdFbTnGbCOIiRA7Wje0FHRwNfWy0ZK r9Lu1v5Yy6A3crR6oUb2SgO9SNpGrKspIwQFBTfU0wU3qIvIGgWLrOPV8o4oCHCbhjW27zdhTXrW EUNtf+3W2udq36yl1z6MdaNKbHypXa8DP3Lmo8Ez4EdmTvOPnyG9PZmpPY5EKvWrtoDO+QrK0eNk ofHsSiFtu6ahkdIy0oXAApZXkItGqR6+3Nq61eDaohIlLpq2XBZRuDLule2P/9S8TvvaT256Maa/ uqfO8MmLd7xNDNvdA1Nj27yBbnnis//cM/S13K2bjYkbdlyE3f64jm1TX5C87cTum3cEFB0s7+bx 7T/720O3kTpamn+LeIt4ABUjHfq1YWcnu4+9hZ2pzzTsYe9lP8tm/qLyGdVrlZ9U0iqrGml1nCZu Y9XGJnvRgGCgeqRkOycrmKn+TuW32+9t4rXJrA3ixkZ7dbWsopgmIvjVMA0Zv1gmE5VW2/nVlfy6 aj5xga2Uwa63aTgGILaJ6ls4/Gpetb16A5th0G3Qk/IkN9SZ9XAHKc4co2y2c+YMvxMkzPwruJ0Z Xiu5t4IF6EvObbAzT8pAd2Z4h0hxk/ImjYGg5FtRptUg0j+D4Dsx4qzUleS+1V5ZjFEG3q4tYKyi +L3sMvXE9oSiKX7Z184k9z180FVfUSI5eaOwqJrHLq0tZ8t5rd5bemVBAa2Sr90Vdl9HrKlav/L3 9y9W2DGM+/aVK++c/sv6taYx7oo4rk1IS4urqzibyoVz81azYJhWJ/FMzX2LjEjUoKsRkHwzihk6 W/iN4naxTTwgTogLCiTtle3iV5torAoJwTCIxbXr6m0NHIGhuYUsFPq4BRgq2Fqws+BPBfkCekFr i+zES4PbTq/uWryXwMGBrE5Q+1rn6WOrGlh6bota9WidX8QgpEqS8qgsOOvufr788vR2l6aph8Vl MeiiivFoUNAYMs126KOGsRvHD+DFz72wzWbqbddW8Ku4nEJGSdnJp3ablb2RYMO8JnT7Dyi9epsW od9CfXfwB8MtNppNjG/Ce3Frs1UxiA80j+Hx5pdKWGwFS8lSCRQCpUDVwGlRtChbVO2FulJdma5a J9ysCNLi7S+XllWXGZrFLS0OkYTdUCrSEHpDmcAgEhZoykq/DY5SVCoRiYQQBDiEqIktMTBIaltD /fo6vF7PERmbhCJeRvRtUV5EiGzFhnwH1mEUmdgm42r0xntp8MyMDHY73moQt+k0/6+nZ87Jr7UT USHdIQjpYKcjNU6/auek3r0so8h4x+QKas8brANZlmnPhbTlCLSujBJ1K6YhVY5YDXI/lzdl+e3n RA+LBBtx0+zUVnaZampmFBtu5q+9gMClTS3BxOQlJ6vDXE6le12bWxXySYUKDtupvXAqfNmDDz/y SBdWc3qikS9deXseP1hZXIO52WtYdYJ2JquU/9kvIyv3l3CLo3JxThWuEPcVGRU59QXXXvvaHz4g vQCpiwFiCTFRPeozNBnWtdXQxaWleBUuKWRU1dtqOYYa8ZZ12DrmXm6ei3Pr6eWG+sYG0lphXxp8 +mwQRekd6fggbtr05AkBVEHkRG1LIAJ0VgNpjNV4V6Vs/0Lp8NsFtfZrtQ/cdObWpeUTW3asnHi/ oKBUdIHT0djW0WtO35g+QGxWvPd808nQyh+ff/nCwOXviYTaks66rp4mm+Syjq3fvQMR+aMrF9IY YFMciPNdaNFwccX6BpfOoesZaEo0zarv7mTSzYKWclWFa7ZlvuVK1ZXqq8y3Nt6kutn8kOoh88uN J5peMJ1qLIWDvhovcbmqNDoJR7KgwTQODb1KSpc0M6okVu4GkajByTTsbMAayi0Lzu87cady19of r8XXbuN1ibrwLtzQpuzvg1372Onjg38dhN0BICWWp6mdgQyVSIU7ffAQYJtkcDTAtpFeq5QySUpB Shsa12MS9efmqalb1ZT12OpOIVGVS8hYk1Sh1W1FiFH7Bm1Vp0C2ePUOqXLLtLrpxo0qyXe4/f31 m745sWOlm7/eN+nt/68jie+UnpwvKHj/hfUGnkRRKR67oSOx8senrhy6J6y8FJvF6FmtdeW9cd2G M6d05cUq7oYNvfImc3/nH8sbOlXejnVzgcveNWUEDfybXuAoS8WCIrawudGUufwnIu03gu3r6kkv V5k/RZOBH+hA7xp2MzjNdRqOrk233saxybZzliuWK9lMzCAR1zm3CooKNVgZo1jftr5KIKmTsYQa hMnWt9nasDZRqaBKUFykL+zoEJHf4zPETAcHaerLGB2I3SSsb+JUCXgsgVmA18HxIC64SvBtwT2C hwW/Frwv+JuADYeGzWyMV4fUyIx8KIYy6Aq0C/0QopXNm2TH1lOnN3LTGdy2A/aW50CRT1MB7xk4 zV1NX0/FuMcPXc2njnXHD67uOrB0vBOHMJ6AchXgeI+tRimUtTM0pK1XFmhXz+TkkWh1Ozpf6WE5 y866YSpwY1RiG+mFG6y7U/e9SmM3N3/tx1vs/uKaa4g1RdXaalnboDYc13mbxEmcEJVs+pFCqajW 0q4p05asX4O3c7nCz/bjbJ0md1V/v9gQWgkW0XllJolV+E1N0Ght+24EUzK4jJrSI18bXPAug9Vr 86fwbnoOzv7r0Q8NW1/h/I2DawUDgoTgwyoah0MTiE/C0anaUQqnYjgNV7JbDfX13FJwt1DqhLjI sJ5gizkOLmP1AFYv5BAyOCKrCR8RIzLUQflHxLsEkyBkbLnsS0dl8LCbSA8BIu48PQgOFiR/nI89 J4MoiolTm/oxGelXeMdkq0dnMs5dlVcjSPcf9vJzEkVf7HAqbSGj+CKcUFs2vL4+uGcNo3RNofBr kraYZiCqC2GH+/v1erdbf4NWqMKOMXmM5jWEllbFKjmzv7vGWVFRNLqhZpfKZ7HR8VVCfT+pz6TM rgB9FoPEkhXsCj7ewG+oaqg2V90p2FdVwGfz+XVswlAl7hVgAoGDSyO4IKwKdjGXS4mNlBfsiVUi ga2ifh2HqAV50Yg1hJqwggeOEzPEVcTNxA+I10BufyeKCKKWDYfyf5Lc6t5E7UukcpaU4szzJEa6 XWwbGtz2hcQofcT+WWDaooLi/2IxO8y3pu5aebmCXlrBWjdY1xbWDY7ovQu6ajUxVdvCbVvVr0+f d1c4+OXFyY6aeW24txPkoSDtm9iLNmC44W44X9QX1rcpC7WlG9o2aoNtSVaiYjfvpYq/if5WV9xe Ya+wV/orZsq3VxRUsTBDrVgCZl9cpMaKdVLK6msrOevUCFvfJr1Zeqf0QSkhPWv5usINN2+4cwO+ gTJ/df0aBlPMchQyNiA2yca2rr6RUwk+gC2oJn3AsOAKwaMCGth9B9h9LcKG0ZXoEfQE+g9ERx0b ZSCmbV+y+YP8c4KFcJN8i9N5hrT8wX80/UOrpv8lu+et+u9tqrLVdwKNXzZ+Av+Xpl+MMRQPcejs 9aad13/zYjr98o0bLrUaLwhfUMGp1qwVt/VovpZoH2hZFydowtLO2xQauxK/vqmytaS+FNcy11Sv XEnQH+/Y5HD6XCsfrXxcVlpmrtPUXKQdNFikd4cwJYfHrCz9ZWTk5Z9TVv82cQRWrBitQwZDG2tN wdqyguqiq2jXcI4wX8Jfor3CeoXDEUiKGaUSBqfCt5fAiHW+77Mxtki4+tpk8PQX7/AqK8rXfBG7 oMrzoh/wd/hJz8KdP38/++KPf/6HlZ8WVVl2xv2FlZ27Yr3EXpnn8KtP/+6mxdeefvOzp9bpsYaP 98mrlStPnv4u+cY0vBImTsIom5AePWK4rJy7VtOIlFxNk6VpO/dX6NecXzewmdUbePqS2TIah0bj afWESMhgI4Km1/KEXJGIMjdVfTlj1UW1StZyEJw5imUGAx8T8Q38fv5W/iR/J/9NPoO/kSA2NNHq wAzNRD+xlZgkdhIL4LxOEmyCR7A3bgATBH0ZJA0Qk0HIs+0M9bLvNOW9zloheX3xym/VZxGgCWcX mgr/GJXn3hVRUmukYiHy1R86T3LUm9A7re0V79HL1RujDff7zTSz+sLhLZcu/fyoTCuvK6nU9q0g 7A1F446pIXapqv3iZtGFKwtEY4C4pPSCwvoKLZtWxXueFpb2XXL5x+//YU311ZuGK5oraFrss2as 8J3r2qrWT00EVpZrSZ9WSr4bBVnXo8sNbg8XqytsE/sKY4WXMm8q+lHhzwrfKmQx8aJanHx7DbCw 3lZPmiHOf9oh9JYyyM24kFGP2DvLsfLGJpznQz8CY3sNfQrGRgaJlOPCeIfgVE8Z1mmIEkmRzfC+ JDDQpylV6epRWUP6LuJzaZHCkmEQEVHCYZSG9ZuVm3YG9ddMsYKawUCHvlNX1coto3NYjZe0rguW Y/UvvN3aUKFlFjEFK7vxe20X9ys2XrhmDb+AeXy8Z+W9TTBvcf5t/AOIehXoBcNaFkfAXdPUzNFx dKBldlAZSxO7TsLmtNRUPYxdivgYw8AzvLTm3TUfrSHW3CGukZQw0MPYR0gBDQLDK23vt/29jWi7 Q0yTtHDqJI0iNodRzPA2kq/lymB/FFfdYagUi3fyMb5NJfIWk/UlBkwsRncY5GLxAQWmsJLvJWde Ag9+WsD/kLp/doY3c3yQf17Nyhnq4AsZjFCw6b1BARxWvsDIBj310qGs8tyrSlJuq0Gjinop20iJ EdROiJ2NICmdk7i03Is71Jvb63uU1tuu0ObK+Hz2Rll7WUKv1zTqYmL10k7tRUVVAqYW09FumTO1 NQ+t36JdsMdvWl9RvnKUfvmUubnOYtvZkt148S2tghJEyfgUPkM7CPvlYcOEuQrTERqWjfuNwtuq 76kuMLCa2LBVkvtkIYdmoxElXJwgcG4xh11yZwlWIirFoUzgxYNsm4Eu5hR8vm/itU0EDy/AK/AG XIsH8Diewa/Ab8J/hH+KQ6MN/2LbnOGtH+Tzvrx1UveZY/wzzA7GOTdPKSOpik/OyOBE98Xh7tyW CiE6ac6ruqkiIAL/b0IQcdGa25LDljmP073rvitK2SWVzJoLGtouaB9MdvRfa7bjrbZmReDqld/6 Vxo6W+zVZYUxA7md9m1a/baIB/lrLAaDPJd9cZE4/dz1FX45ufoTHESj08hXv+SvKMl+NBqgbJI3 cR4Z8T/gXUDxLjjHm8Nk/jPvgnPXV+VdAHzp0G2VN/SjeBeyWP8+3gyKNwP6UeIpYrP/mTfj3PVV eTOAbwF0o5G/Syb70UFEqJjkTTuPjPY/4M2keDPP8eZyOP/Mm3nu+qq8mcCXAd1WeUO/ggJAeYWF /z7eLIo36xzvkqKif+bNOnd9Vd4s4MuEbnRSHcl+DAagpSTv8/WY/j/gzaZ4s8/xLisu/mfe7HPX V+XNRkw2E7E5FG8O9KN4r+Fy/y28WWwW8C4gVZ3kzWQCWs7j/TNvzrnrq/LmIBaHhTiFFO9C6Efx riB5n29/Bf97vNkc9vm8WSxAK0tK/pl34bnrq/IuROxCNiosongXQT+KN7+09N/Cm1PIAd4M0kRX eZM2jZHsyN/IF/HOTJ2ZKnyHifD6f+gYLNCTvwtYvXD0v3bh/7iapPlIIIOV5Y9CfuNs/j3UtUEe pZGj+3/8gjFSf31AfBOpSZyEq/Uwp2lUieuR9hztORzqFUCrBZow1bcG+tUgMbSLqd9fBNFFsBCL ZOQKOysP9ZN/xcF8Dpie/6tTA8kqlh5PnMWd06s4+VcR10UmJ9PwxArw5IahkXQMPGOAXIFoRBqd lkZnpbGINDYsHR6XDk9L4yPS+JQ0CZ/t0pGYdGRaOpKRpjPSsWnpWEY6npZOwicjnZqQTqek0zPS zJR0ZiQSl0amI5Az0sicdGgYPmOQAU1Ih6akQ/AUeFYicd7zIjPkM2PTQ9LY7IR0eGi7dDhNDWGC HMVwRjq8nRrLSFoanyCHFN8OeVaaiEgTMWkiLU1MZ6WJ7XPSxIw0GclSIwZmZ0edODvw0bGoNBUZ k6bgWanhiDQ1Ik2lpKk0fMalKaBPTSelqaw0PSRNJ6TpFDXV9PYJyLPS9Ix0bHhKOhYflo4l4JOU jqWkY+PnRDEkHY/BZ5oUyvi4dHx2XDoxJp2YPiuhbdulU2PSqXFSVFMTcekUlLPwAalFtkmnhyal 08PwSUqnE5Qo09Jp4D0NHxAtEEyR0oU5ZkAimYQ0k5JmJkhpZzLS7SkpTHxmRDqzfVyajQxLsxPS 3ERCCoKc235OK/jkzYa1oY3IQypcOBfS9Zs1upDdOR4JhnJORXh7sMszbk25tQO2yXTclwlE7Ips LDypDvoz7qBXHbG4J9w2W3jEqLJ4vbOJmCXhynblAq1dI/5JtzFsdqb8Wuuca8gVSMyZBkwBR8Ay OpDUGf1eh6cvlbH1jiSGLcqsO+6f9KT90fDQiMMWNjnC1qAlHPGoNQNz+qgnkDUOjwSS8DBN16wu 5R7VZU2KtKrXGMo4ramAJadXG9PyKWsy0+pM690Wd8zmU7jmukwar9neNRYamfY5RtyO/jn1kFmh 8XqzKWX3rCNn8qYHerwB60Ag1+fw6mR2f7rda5bn3KloIJryROJGecwzG1J2jybm+tITZp9FFwr5 XaZh88Sktz3ssib9srAqoxsIOtzGMV2wxzhhcaRcZqM/1e7PWibiKrnJNeeY7TJZ+gNdCdOwP+y1 2DXbuuXZlFsZVodUyaxxLDNhGZ/c7sglVL2jfs24Ted0ziY9PZ6Q2+IxDtgTaYvfYtoWHusdsPnS w73j0fGAJTFrsqQyw3J1nyvntFo8/la3yRLzKo2hoVG5xxVMdXnklgGj19TnT032xIOtAxZz74Qx kNX3mnqn+q3RWW8qPB6yZ1JdtozLGpSH7OPuYCyoGQ92JSOugMZmsqunY3J/tMeSccZ9E86ALaa3 DSTHTbMJh19hDJrkWas5lnI45tRz3pRVGbPkbF7/9HajXS3r98Z6+o1GedDi1PYa3aM9Jvdc73gM 5hSWWxUWfa8/3WvpCnl8/rS/q6vX4Vb4zSZFxhPymLxRc2JKGUzE3appZcCj9gRszvFo0qkeGIna zVa9YziYzoUtFrfFphly+2Mjpqw/7bJHZ31m/axHmbabfROxYZ9V7UklgnZFLBq3paNGuXMypOyL +gacGm8ulwgpE3q3eVLlCaQCVosJeDhtMZNxwmN0hO0e47a+RGDClVPMhQb8Vq/f1Wqdy6UsFn9g 2KyJusdTcxaTRh2S+7c7lRMRL8ggNpYIdI3ElFa52ut2J4LRLDx7IDdkymW9pvHckEvlzA6Zon5T 0mHs63LoveaJoDvrj1vkmqAxm/RZEpaIxeSx9Bk9rQGVfCg0kJaPePUJiz+t9w44HcOjmUg4Z9xu dIf1sWAq4ktEo72WmDIc1Oi9HnXYZE1b7LZENOYP9FtT+oh7XB0ZHnD6YS0yw2O9ZrPV1GVJOqZC du9Y2JzuDihCqoDCbzQPZPVxk1PVN+eedHb1zpgCod7AbLTXZJ5IhpXJ6fioPNibTWgd4+oesIuM 0ZpNuFLpgGncZLbl1LoeZW+y3+SYtjmzqj5r0jI8mu7pnXN3WWfls32zqbQzFxo3Koz6fnd2zOFR B8xBkzaacDgsydRULOdJD/kzavOAPOlVuLwehToZ9mWsHl80MRR0qIxzGtPYiMPVrwiH3O7errgq 4fUHdbY+S8AL9m2M2zJakz1s602ENb2KCWPIHlCGcuHu/kAsbFJMOh2zCWdX2u1zu3VuT87U2z/i HrGP63tCA/Eh/7g7bbJbIwFfyOT0RceN5pjVlc71WuxRhbFLrowFotPdxoTD6J2We7MJYzznGTKN ecbio8kxiyVkCY0HWqM5hatP4ZCbErFps9vlN6ozPV2zuUzA7fZ451I9/oBbZg1O6zw594RRkTLb 7Dp3v9uvtMndmajN2j5kNnrNSXnS5dMP9/vdKZvJ5PN75dP9HuuM0aKeCXQFrKYx/dyo2+S0m3VK tz2mCKZc3TGVcWpY5Y5blRm9NRHIxoJWncnv2R7w6q1Bo7vPZA4Eu73W9rB/0uK09k5ZraG5gTnn QLc12+u0GQciwYkuk3V7zJL0T7nHJ2JDcy5VXyK73Wl19zvNAXe/KiyzGhVutyUZ6zE6HCZv2Beb Tc31Gv3AS+frTsa64h610Z4K2MwJxZQ5pZ+wyU1z4fHpvrjDmB3wGi0m87TGYs6FzYncdJd/Ohb3 6bu7uhx9br9O3ZecDgVm9ab+bG7aaPXM+iyeWVNworvLptgW8uT6fRajPzJqjXhT/rmAcVrXZ9en JhM5myPokkUDaVWPadIYzuVM8VS03ZOLDsC00g6zOuqbnW4NyUNTQznFTNxscvSNJnImt3vANhLu GfCZrD3yRCqeS4PfsOTMWV1v3+i24T43GLVX3uryTvb3jLrMJmM0HJ915nqUmQFL0JXw5wJjAwGj LzZmtJoGLP7IQG9XdNxi71JatkcCxkAkpTCHVeFst9GZMin1Jn+gNxdwThgj41G9a9SfDvgCEU/a sz02MDHtsmanPLNWm3XUBHWh1gGzLhezZybDcstMPGh1muxGp8cS8ntTAZUp6Xa7ZgOwr2Xl3qBn Mm6bjI+kenWWsWm/dXTCFPemMu4BTdA6Oqm1mLPbHGMTEWswZAYfpRsYdXmG7aFZkzHRFR7PbnPO JZNdo7Gu4blJtcUb1thsap1JaVUPu90jXmMwEEw5QkZPEvZzxaw1nTKHB2KO4axjzm23bou5nV1W kzxnHs2NDyl0ppApNtJvdUS8Yx6vLQv7sTEc6g8aIz6VaSI8FkgYzUmrJeDU2GPpubDZOOEwabQD ObXPNK4D40/oTCZ3yG4J6Pv9oZG+sWlvKGfqCsmto05TVuaRpzN2S8wRM023G7usaavPNRazGz2x dM4RtuT8cdB5pU/hN8mt+gGf2hHNhdWwb+fMs5rRaG7CP+ybDHhzCVnImIiZwPE7TGm1N+FpHx4L pD1dmaw1Z/SGbAG5NxEwWXLpaNg3YbGZstZ+//iQJZ229CddJo/CFOj3hf0wlpQnCz4u4eyLjOts 7lxY4Uu7ejyqUMA4Pu2z2UKqfrljIJB0dxlzmuxAOqnuslpNVrtjwJOWT8eCk9MmV0rr9Vvd3Xad JRA0Kawmk6pvNm2N2SdaYV+PxUyKqEOhyFpTvRG336OwByYUw+PRWdDZeDwZ0g6knD2WdFLfZTfa 47PgmcczvW53LKUccA71pVP+4VFLV8QSUHm6Eklv0ro9brRYY/7QlNNt6XErLfGIxR8NKkLdHvNk OgxOKpL29HjHe+dsJqs+NuCQ+QZcij63q9WTdeYCo5FINGmFPWI6FlVOOow+U09EOZn2yAPtVqMz 2JfLOlzZUDCeNaX7rDGv0ZhxuO0uR1/K1BNMhqd7/SZN3N873K9ye4ZHFGqLv9c6bA27Q3p/1q30 gJlPK8zWZCpiDs95Box2d5fLFkxald3jbq/JH0sNyN3boya31mgLK2HYKp8t5BkYCA1F/c7u4Kxz NqJ06jxjDm1cnhgJ5zI+pcdhNqYmervMnvRwajoYsQVgZA6dNaGZDCc9szG/uz+SjnV7bK5cKJfT eUaNaVsOFlNlTZhU+lmTOeQZ9udk3uCEzT0ahjgrJ/OPt4ejnuhwf0Kt8gxMDhnNE47hOUWPUe5R 93qsdovK090/q5+1pHRKu3nCaFOl9P2e3jmfzRi2m5zyPsWE16LQyyzKUGxYkc0ZBzRT1py71evK BD2pwHRgfFLWN24x92cDRqttImhRBeSWkfDAcM4/bTUlTHF7b2uvPOTvlU8mbMFeX0iuc3qVmZFh ld9oNUYdAVvUHcxa7MO58HjfWK9amXMGrOPTNlsSFFOlt0bGknKb323sG5MHhwZA3ZJZj9tiVNlM gWDIkpZ7cmFvf1DRHVRlRiB2MVtGoz7z7ORIxKeZMKU8jrhbPW2zB8Nxm3+kNzUdGzClneFRtddn 1ZsiXXrr8LglGve4Qj0pk6V73DUBpuzx+ZzqaM7UGs2aTN5UrzfuUbjDlqSmLxXa5g4Yg7705GRo wG0NTUzGIEyf9oGderJGe8Tb644mshNej38oPtar7UtOuByJmMMW1Iz50o6ce8w/YU3F9F5/psef nXQNZAMOTzLd3pt1ZeM+XcjiTo7Hk6AHc71znnGH2ZScVg4EpnXWdK97OGWMG8eymXgyB/oTkNnk YVufvbcnYoGgUW7d1jc72TM0qlBGTRa7ZyQ6ag/CUcSjs8dz05n+hHHWZ/SFrXJLJOLTj1hHE+4Q GKSny63us1i6+20BoyXnlAcU1tYhZa/ZPqoLedNGjcef1XiCLhOE4Nv8bmc24sk6LCm3v0cRHu2d TTusppjSOyEf85gCfnsSogxlINjvD8u9lkQ4mvVH3aYJX2Q00+52h8ei1kC/257pjgZDWpslPOwK QiSviKWswST5vMnesUyfz54Z6bL7/Q6j2qcIOOUmVe9AZGRiwmVPWAIWiCNTvX6HW22JBpw6UyoM 8UGyLzwHsaIx6ux3W0eiJmOvLRntc1jCXofcb+xTyV2erolM0BvyxVQmvzmrDQbtAVtPVjfal3NH w2MmrdUd00XGHcNDXcZNlrv+sMVxcMuD+F1/iv4V7bzgR5t2bLvsx0jJ+eHjIv2hme/kfviZ5nve NbXad1yj6vcue2a9sv1ePHf86N/La0+bfhvZuX/5/qtigz9e9Cz8vv+B9UR/4z0NTz5m2Xndrc7H LDs6HXO/s7qeONB014bffbhXO/bZjXs+WfgDX/311vWi3914FNu9o+AM79ZN/+EM6msTexPz3nHW o+WPv3zhn6yb2VWhnQ+33tP358sN84vrW/P3fSIarNu+8P7Hvzwx8HjVtzfefUNJ/1VFRPqxDfK/ GNw+1wUXP9G+Z3PpB7t/aortv7ZZYr1w9FY2b8v0/aZX8uLlW34v3yQbPXPBjXs//ctjpbs+Ebo3 XLznzNqZLWf+Unjb7Zde2mYXPPDxn1/YqW2965kfPBkdznSvC+h+c3NO+fD3v9P09Zu3W5+xvLvR evHtVd9z7L/tiUjdQw9e9Yua+3566UPG26ZZmc8W3mwp8xagi5dO3LT8DTP3Ls8930I78i3lncqR w+9Pnvwu59IzQ6/9dOcN39n9wVuP/eL7+csLaT+7Z81k+yWPP21MP/VH5s632e/9puq151PXSjcc EQ3te2Htb9/t29PRs+fQB9OOH37acMOv3j3ao7ojMf5QTUq0RxW/6MPvlrz6Ti4re4K5vVSxlL/y j7Vvrf1oX9j//VszZZ/Iv/38xkt3Jz/E3/rP9dfetavF7nnqR/aqJwZclY98sGnvQ4vT1793jf/S Pfc9925Uo6HeJ5HfqRIIo7EQjiqgbEITKI1iSIQcKIMigI+gKPkdQ/4DyDnyf3f887WMrK3k3/ks I2Xro/jN+G4kQ0L8FkPDn1ViYadlj2Wv5YDlWQu988ieI3uPHDjy7BF659E9R/cePXD02aP0TiML ew3tgbwX8gHIz2KvGa6hd3r3ePd6D3if9dI7DXsMew0HDM8a6J037XHtdR1wPeui77lp700Hbnr2 Jlqneo96r/qA+lk1vfOZPc/sfebAM88+Q+/07fHt9R3wPeujd4r2iPaKDoieFdE7m/c0720+0Pxs M70zsyezN3Mg82yG3nl4z+G9hw8cfvYwvfPUnlN7Tx049ewp+kLBAgMvX8avXbIJ1yzj8wDKlvFr AJQu498AULKMXw2At4xfBYC7jF8JoHgZvwJA0TL+dQCFy/jlADjL+GUA2Mv4TgCsZfxSAMxl/BIA jGV8B4CCZfxiAPRl/CIAtGV8DgCxjM8CwJfxHABsGc8CQMv4jIELEMMwxMJwxERMg5GD+7A/oR5U hP2Ouieoe/9DPUVv9hRt6Sn6BZZHo1DzJHX/uqF4tOh3o0W/Hi06OFq0Y7TIWIS9g/qg5XHq/hh1 30ndfYaSvqKb+4qu7StK9BW19hW19BUZK/C1SImKcD51LyLv2FPU/Qbq/k3qnqTuYkOlsuh5ZdFz yqJnlUVPKYuuUxZdoyxqUBYtY0f2cR1cxDqAHQGVK8I+wi4FlRTiw0vNQuEy9ulShgSfLGXEAP62 lGkA8PFSphXAh0sZJYC/LmU6AXywlNkF4M9LmZMATi+dukZoLMH+E53CMSTE3kU+GgnfRiKq/BY6 TJXfWDp8H5C/tnSY7Pzq0uFrAPx2qd4J4KWl+jTJ4zj5ayGgfQHgbQB/g+rx+wA+c7b+V0v1ASEo 8WEko3g+gSRU/RVLmSZgc/nq+C5bylgAXLzU/IjQWI7lzg4oi0QU0xkkosrbz8Kps/WTS4efFj6K TaDD1DPHlw6TQxtdqr8QauOonkkSx5bqp6A2ulQ/BGDLkmyWHE8QtVHjGAAYAOhekpBzbVjK1AKo X8q0AKhbyjwNQLB02AagipzKw1gZkuH3GcqEfwRZvn04IXwLGt+o7xO+LlvG71sSnpCR3YWvSpax wIPCZzJTwqczy9htS8Jjzcs0bEn4q1PLGIAnT1GVR1fBEREAA0d46HCf8FHZSeEjwAt7UPgASGXx FLCFprtlaeGd0HQLcKt/ULi7+aTwJh/1xIW2ZSZwvEFC8b+ijQJfl5AcucKLD58UXlR/n3D61NPC KRHVtG0VTB6meo+v9h4juwF9WvK0MCkbEsZlTwtjq6wuhBkFloSDq+CC1fl5DwMAeheoSK8sILTU dwmNq/SGU8ARRtwJarOx/nvCDfUwmSWhTrL6BA1wVjfvEioObxLKyXkCaS3I0N/CamEtGNm4BDHQ Al5M3rFvU/cWQwdj4V7Gwq2MhXnGwiWMBRtjwcpY2MxY0DIW1jMWpIwFIWNhHWMNs5TJYxYzC5ls JpNZwKQxcbD+Ncv5Nw0tpDtfU8AjAfnVJYZoFM7DyTu++r4Yx5g4chr5+Dxi4t+AfBXkKyBfDnkn 5EsgXwx5DnIO8gzk+fybPyN778fn8Yv38VbRi/G5s5Vz+FVnsavw3Fksh89QGLiqn5HPBLjkRGg/ +Kz8ld9cLPhGcBFbxK6vXkRwD/HJv12uqJjp5HeWbi7RW83/zW3r2XvrFxf/f7lD65cuDI4DxmLw N1xYBSH2GXX/NXUvpe7cnzGE7zNWibu9JO0CRbtA0S5QtAsU7QJJu3COll+zeHO3N7h4b01oUUki +ZpQ92Id+d8l9uMB3Gcx78f9JAgF92MMHAI+sh5jmENA1keRgesKkGQBEgAZvgGdIsmgfgNFFl4l O/wlsmvRYYrsMH4tRXbfKpmIIkO+s2S015CIIhPRXiPJwFJW6ZpxP0mXIQHQ8ftQM0XXzO8Dui8L 8P/0NWz6qpSWEa+pAnV28qmfoDIKFwskpkWG5P+n//SXr9ZFliW2SFhAX6jfVJDfreAIQjvYBAtg Hzv7dR7Uc6CdQGzyhyWAM8kfapBfZgMOqYSDClGhkIOKIHFQMSQa4iJSZchv9WiwuZUAvhaVAY8a SAy0DhIHCZGwlANxlwhwMRKv4yAJqgV8EyL/t9pmtBlaOyFxkAEZoLULGQEfRGZovRBdCK1bIHHQ VrQVWiOQOOgyNAStl0PioCvR12Gc30BXAU7+jyKEbkDzgN+IFgD/FiQO2gWJjm5CN8EsdqPdMIub IdHRLZAQug3dCjTfgYTQ7ZA46A70XcB/jH4AOPkfxBC6G90F+D3oHuBwL7oXONwHiYN+AomBHkD3 I9IHLEHNI+hhwB+FxECPQaKjX6BfQK8D6AD0ehyR/2HuMHoCKI9AoqPfoqNQ8xZ6GWp+j/4D8Pcg cdAf0fuA/wkSHf0ZEgf9BX0Asv0I/RXwjyHRsWr0N1jQGmwt4mBSbB3g67E2wOUY+b/3lJgCcB2m AnwDpgfcgm0E3IZZAU9hdsDTWBr4XIyNQc1D2A6o2Y8tA/4IBrPAHsMeBfwA9gvAf4MdBPwFiBYQ dhxiBw6uxF4ExVHhqhIOrsbVQg6uwTWAa3Et4O14O+A6XAe4HtcDvgHfAPhGfCPgHXgH4JvwTYBv xjcDbsA7gZsVh9Un7sRtCBF3ESBz4m7ibsDvJe4B/CfEfYDfT9wP+BLxU8AfJH4G+PPEQ4C/QPwG 8BPEccDfJ15HHPodxCmE6D+g/wDR83nqP9Sh/w/a93YWCmVuZHN0cmVhbQplbmRvYmoKMTQ5NSAw IG9iago8PC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udE5hbWUgL1RpbWVzLUJvbGRJdGFsaWMK L0ZsYWdzIDcwCi9Bc2NlbnQgNzUwCi9EZXNjZW50IDI1MAovU3RlbVYgMjYwLjI1MzkxCi9DYXBI ZWlnaHQgNjY4Ljk0NTMxCi9JdGFsaWNBbmdsZSAtMTUKL0ZvbnRCQm94IFstMzE5LjMzNTk0IC00 MjUuNzgxMjUgMTYxMS44MTY0MSAxMjc0LjkwMjM0XQovRm9udEZpbGUyIDE0OTQgMCBSPj4KZW5k b2JqCjE0OTYgMCBvYmoKPDwvVHlwZSAvRm9udAovRm9udERlc2NyaXB0b3IgMTQ5NSAwIFIKL0Jh c2VGb250IC9UaW1lcy1Cb2xkSXRhbGljCi9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0NJRFRvR0lE TWFwIC9JZGVudGl0eQovQ0lEU3lzdGVtSW5mbyA8PC9SZWdpc3RyeSAoQWRvYmUpCi9PcmRlcmlu ZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50IDA+PgovVyBbMCBbNzc3LjgzMjAzXSAzIDE1IDI1MCAx OSA2OCA1MDAgNzAgWzQ0My44NDc2NiA1MDAgNDQzLjg0NzY2IDAgNTAwIDU1Ni4xNTIzNCAyNzcu ODMyMDMgMCAwIDI3Ny44MzIwMyAwIDU1Ni4xNTIzNCA1MDAgNTAwIDAgMzg5LjE2MDE2IDM4OS4x NjAxNiAyNzcuODMyMDNdXQovRFcgMD4+CmVuZG9iagoxNDk3IDAgb2JqCjw8L0ZpbHRlciAvRmxh dGVEZWNvZGUKL0xlbmd0aCAyOTI+PiBzdHJlYW0KeJxdkU1vgzAMhu/5FT52h4pvugNC6tgqcdiH xvYDaGK6SCNEIRz49wt210mLFKLntf0m2FHTPrZGe4je3CQ79DBooxzO0+Ikwhkv2ogkBaWlvxJ9 5dhbEYXibp09jq0ZJlFVANF7iM7erbA7qumMdyJ6dQqdNhfYfTZd4G6x9htHNB5iUdegcAhOz719 6UeEiMr2rQpx7dd9qPnL+FgtQkqc8GvkpHC2vUTXmwuKKg6rhuoUVi3QqH/xnKvOg/zqHWVnITuO 07gmOjE1RHlOVCZMHCsb8r06FL9+t+sTNkwe6MjYNy+J8nu2yFg8stiweCCxSIgKdimfWCxYPNBx SK8v4Du3n9yGceugXJwLzaOJUde2fmmDt6HayW5V2/4BC2KVZAplbmRzdHJlYW0KZW5kb2JqCjgg MCBvYmoKPDwvVHlwZSAvRm9udAovU3VidHlwZSAvVHlwZTAKL0Jhc2VGb250IC9UaW1lcy1Cb2xk SXRhbGljCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsxNDk2IDAgUl0K L1RvVW5pY29kZSAxNDk3IDAgUj4+CmVuZG9iagoxNDk4IDAgb2JqCjw8L0xlbmd0aDEgMTQ4MDQK L0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCA5Mjc5Pj4gc3RyZWFtCnictVsJfBRFuv/6nOk5 e3quJJNkejK5J8kkmVwTAhlyKQQkQAgJMJJAgHDJaAC5E0CuACogxwqerNfbVQcXV1TE4LEq6grq uorK6nof8dbVlWTeV50Amazsc3/vvZqu/1R1dX1V9V311aQDFACICCzAuIne/NGf3hgBoHR4t7mh amzj4q9XLcT6AgDunZkLW0LM3fTPAKox2H7NzKWL5eE1Y8xYP4nPfDg7NGfh6L9wMoBwBJ/vmNPS HgI7CADGEjLKnAXLZ0N2/lNYLAOwX9bWunBZ+7Hb0gDStgFo726b1dL6uuHBTmzH2UBRG94Q5wk4 OV8B1pPbFi5etvkmYQbWG3G8xQsWzWzZ/Oa1x5H+pdh+dGHLshD9Lb0VoOAFrMtXtCycldjmx/EK Psfnrw0tal8cqYBlSHoVaQ9dNSsU9/WWuVg/AMAUAc2aqOuBAzV3I+eDLCpF+R7D3ArL6LvUQGt5 luFYLU1mx8CgNHaiLAMFMtzKJ/Y1wQm1lroPb9xC2tggd4qMBoTTFFAkgQ5+VEdADepIH/JHg6hR UAtaRB3oEPWgj/SCAQyIRjAiigqawIQogRQ5C2YwI1rAimhV0AY2RDvYIz9DDMQgxkIcYhw4EB0K xkN85J+QAAmIiZCI6AQZUVbQBa7IT5AESYhucCMmQwpiCqQipiL+CGmQhpgO6YgZkIGYCR5ED+I/ IAuyELMhGzEHchC9kIuYC3mRHyBPwXzIR/SBD7EAChALoSjyPRQpWAzFiCVQgugHP2IpDIt8B8Og DLEMhiMOV3AEjEAsh/LItxCAkYgjFayACsRKqESsgqrIN1ANNYg1cAniJQpeCpcijoJRka9hNIxG rIUxiGNgLOJYBS+DyyJfwTgYh1gH4xHHwwTECYhfwkSYiFgP9YiTYBJiA0xGnAyNkS+gUcEmaEKc AlMQp8I0xGkQjHwOQQUvh8sRp8N0xGZoRmyBGZHPYIaCM2EmYiu0Is6CWYizYU7kU5gDbYhtCs6F uYjzYB7ifJgf+QQWwELEhQpeAVcgLoJFiCEIRT6GK+EqxKsUbId2xMWwGHEJLIl8BEthKeLVsAxx mYLLYTniClgR+RBWwkrEVbAacbWCa2ANYgd0RD6ATuhEXAvrENfBesT1Cl4D10Tehw2wAXEjbETc BJsRNyu4BbZE3oMu6ELcClsRt8F2xO1wLeK1iH+H6+A6xOvhesQdsANxJ+xC3IX4LtwANyDuht2I e2AP4l7Yh7gPfhN5B36j4I2wH3G/ggfgAOJNcHPkb3CzgrfArYi3Kngb3IZ4OxyMnIGD8FvE3yp4 B9yJeKeCd8FdkbfhbrgH8R4F/wt+h/g7BX8Pv4+8BffCfYj3wf2I90MYMazgITgUeRMegAcQ/wCH EQ/Dg4gPwh8R/4h4Gh6ChxCPwMOID8MjiI/Ao4iPIr4BR+Eo4mPwGOIxeBzxcehG7IbjkdfhuIJP wBOIT8JTiE/B04hPI/4V/gR/QnwGnkF8Fp5FfA5OIJ6A5yOvwfPwAuILCr4ILyL+GV5CfAlORv4C JxU8BacQX4aXEV+BVxBfhb9EMCv4GvwV8a8Kvg6vI74BpyOvwGl4E/FNeAvxLQXfhrcRz8CZyMvw N3gH8R0F34W/I/5dwffgvcgpeB8+QPwAPkT8ED5C/EjBj+HjyEn4BD5B/BQ+Q/xMwc/hc8Qe6Im8 BF/AF4hfwleIX8HXiF/DN4jfIP4ZvoVvEb+D7xC/hx8Qf4B/IP4D8UX4EX5E/Al+Qvwn/Iz4M5yN vABnoRexF/oQ+xSMQCTyguLfGcXP63A/xX0Gva6IdzToWb3o9wrQo5Wit5iLlng12tWtkYiyM+QM amtB672qvy3y3i9+ZiojXCTxFhwNcMdxnsPBiQ3230HbiMK+VvSw/0dJPZD/k0SdojOG3JnzHw98 CnX7ONoSyU+ijaANofXdjPefQVs5rOQQ6vzdaNU3oxf5Pdr4Tegv7lRq11A09gK01OujqG4BoN9F Pwno2Reip1yL3mkX+os7cQ8B9GZ5KLflxMejBziCY/2AXuQAerZl6HM70c9di/7nVrTtV+ATygy9 lET5qDI6nq6ib6ESaC99HdOO83kAZ3I/PZ12UbdTvdjrBpzbYfTFnbCNCeNuez3sp8N0BOe5H3en GwACZfWl/pLiosICX35erjcnO8uTmZGelpqS7E5yyc7EhHhHXGyM3Wa1mCWTaDTodVqNoFbxHMvQ FIY24ZjKxkOxKo/D5XI1ZQ/U46LrYSZF/MYVBinqIceQTvFD6glD6onn65eFwRKucVdWEcKHoObD MJjDlCUMZBTKPBZHGuhU3TrPXT03HFvZ2tyMParcohyu+co7MBWF9iGtptJdOUuTnQWHNFosarGE z4YOUTUjKKVA11SXHqJBrc/OCkueMJ1STfK8cGBrMxbcVUgJW8wXWo5EurcNbgLsdq5k7i9RYb4y rFLGleeGAy1h2Cofyuru2nZEhBnNHl2ru7VlGnKuBed4CJiU6rZ6wsdqkpvb5DCLxBVw4B25uk3u chN2VLc1I7qrsNcv3sfbQmXjJle3Iyzhd3XY5Alfgk9csuJ9B9NVHTNXJtWurk1y+NbxjYNbXQSb mppicMJd1W4kiMSq51XgUmK82Vn9axpgQGvzPDLmvBYyz+p5ctfWWcpctylzUB6tbkPBtPxPT3V1 Vbe6q1tbWiv6qVeGA/XKF9RPaVQWiKyrahq4NfAAtrBKS3NVk6uf2bUTGivJxNwtVY5+sZ+/0zxw B29Un2uUyQxGIYGwPFMOw4RGNz5aQmBWCXTNLFGUx9VEYa+6C73CXIrolru+hzDV7O75PPpOy8Ad PkX8Hkixxl3T3NVV45Zrupq7Wo5EOme4ZdHddai2titU3Yyj1jViryORR7Y6wjXbmsJicxtVirwn GlAzobHc4TI1navWnasCqhQqllZZDnIBr1EDX8hlqG90ycioSY1NDuRTIynXY7n/mygSKm4JyniA bYRHs0rOs6dyoOhyEe3ceiQAM7AS7hzf2F+XYYbjAQh4PSiPZtLSfa7FOom0dJ5rOd+92Y2jHFa2 IWtYnXr+Moo2c3VbaZiy/ZvmWf3tYXNlI+Ogm/pLtIMhJY0HLb0sbPdgOd3ThUI46Q6LnjDX2O0o a5JFE3oAIr2J7trxUxrl6q7zWtB/Z2ClRA9Q1d0tbV0DpkSUHtWDQgEFKi91e6EMycjkRk044K7w Ki2t70CYeQcb0GlUHHJTm8cfClCbJ05pfFjEXXpzfeMDNEVXNlc0NWWTnYHBbY7G/Z3CXZycBp3/ 48eHkf80jAvxQ9kGPqfw8+N//qErLvo5zUxgHmOHsfdysdwfeS9/hfLZrxqrOq62q/fg50thi4bR rNe8qK3Dz12KpDj6uikfbY+dbiz7Hhz9+/e9R49eQb6fePJ3X5+9p3eXNqymcMUC5v5Ek44q4Akv VGB5iMeTMcneF99+UYG8XJfJZUpBoPCpf3ZyGEDhN2CBxEorEe6jErC34UH6NYo5RXl7wNuDvdxm H7Xg64qvsRH5W9N3kpUwsmEgP2CkaIY5DpQFG3Ae9JHIxwGtIBZDDAGgvT6vxwPl3rzcTVyOZ9Pq pwTKTbHSzx/9gbXxlh+PqqrIyPtxyh9zr2GcNj9QLTAMq9FqtzOsBUt6v4aNZZvYuewylmMrrmYo Rm/QlzqpeVyzjtFxFMXpGJnJZQIMw3AHeF7gtcx+Cry9+eU+b08u5Q3afV6vN+hRicH3g55NOZ7V 4lPUJrE7L4MqdpldxflFxT7KxTx59vUkKv/TvhMJ9z4uH+h7jirYwXy3tmXRPx/FZeBZGdhHMILT gB52Bgx8jFYs1um0+nTJVqw/EvniIcFUrOd5lepI5J1AuWAs5lWcRi1Q9HaVlmUYncGvqwAmlSli apjJzCJmNaNiDEZDqUbEySMLjRwvUPobOY5R8Qx4yyW/t8fvz8fpm3zeoE+ZvIfMuru7FzPelvye TeLbHo+6O4/yUG7GjUuhfIzPZabYvW/PeGJGb0kBs/ORV97uaznQm0rd2TeFuvM95tKzC+nbeqej 7KZGzrBfcd9CPHjw7H4sMKfOEMyr88+2LkhsTmlObc5cmDfD32HviO1IbE/pyO3I68hfUdzuNzOS JCXF5BpK430pvuJxEDCMTKko1vJ0gaZKQxdqbBksI+8XVcP2M7GaQr13S4ZNjqPi3Fv0CV1xet6M zjFgEPTFZnN5yZZcPsDTvDfYg6v0SH5/j7fHG/T7e01+P5T3lPdIdn+wsr4xYM7IL0qtSW3Kb03d nc/nDytMzZCRA3gFm/Jyg8EUA+VOSi0sKCouzKEKC8CXj6EWr7ImUvjFFKS6k3irxWZPpOwjKGYE PpGalkOlGbDV5ssvYj6beHrnaz//8b4pU6ixXzz9wR0HFrU3mrsWb3tiZCBlac3qhcezsi+d7Jk7 uWPz3tWzd3WObnzp9r1fX8oVbWo4TKkPb132wUi+4IbQ5KPMa5OX7L3KPz3JXGAffcfZO73Lhle1 ZllTk0a80B7aW4569Doq0/MY9xMLTQ5YqNdojn+NY06FyO9QqlPTOYpDbqDIieWVo+1RxPYw01vQ /vr6EJgAlfDzQTRFCk+wwD2FWqmCuYEaiqbX9tuMqMpVjeOaVayKU3Fqv8BSbMV1DB6GxPMauBT1 Ty2oSxlGUI8TFgkdAkOxO3iG6F4vql2QQt56idpdiUbjQwsK9ltOHuVCC3YVu7ibe3v6XnqWyuvt SWW/4NL/+TqXfg+uMC3yLjuFXYa2XAjbAk3gNXuzrCneUkuBd5S1ylufOTtzaaY2HnT6wsTCxMSN eQWWvLyCIn9BRV5RcVFpRoYt75Fifr0tIMUW22BfZrwvvjKeiY/PNo/LoDIyUvZmiwXCbrMN9cNb TjhFJhokhu7pET80KZN+37PJkOPhcLqbDGVl3FNP5eVCkDJQqnMSL1YplQGdKUouPqcTqCgqN9YG FIhxM/Nu/PKy8fUz5kx9bEKyI5jrWzNhw51L2q+kyl/g1alud7Bk0ukqTYr/rVknTwr8/Y/SY3m3 y3Vl/aVjxvsPiMOsduf+1RseKvX7+PgMW26ZJOmLHUeNqeu2O4Y7ejXIrxLk113oTc3ghmWBSTFG jzHVPBzNq5qusTYy85h2apV6uTFkXmpd5TRyYAXavh6OpmiExASDfqNOq0tG35KqLdRWaxu0S7Sc NjkluVT7cLIO4nabRK1rDz/Aq/JcSvyw35NsEokXQT8iftcTzEPeWOh+dqSp3OhElPVTCk8IQ5hE rBexd82e1PTWhqb9w2PD1JyjncEHFh68t+/5kpK2qyY+MHZXYHl922/pswf7Xp97xXJvWjFv6X11 5MQTvVsmn1x69doJBb1rk1Jno85OjnzEjmOvxlNUU0ASGFqIZSxChWO8Y4ajg1EbiP+U0LmKon2v TkxOTtgLtuRkI/Eakl4sNhozxmVMz+jIYOLW84+mk+kT1+HzAtEFkvNyPUEuiciysEBC0eJK7Co3 WjsRLj0g/hFUsQ8XTMfPOzh8WGDGlMkU3DDj3ooMraUsI6M18MT3OzaWr8nKqzdr0yc/EZtfVHDz 3JsocU7rkqKU56Vcqy2h78hn2/clW+0F+hfT/CjFSZF3ucwBKW4ITBkVNyppHtuhDplWOXjJ4na7 GBooaiNtttC0OdlvrkilC+lquoFeQnM0EZiIuzct0ovoDrqTvp7maRolHCfQCeuFR5PNYN9jFGl5 92BR/qAsPXjlgEQV6zSIZeoyVHkUKW60xQMaLvUrtN3M9Cv4eSvgMvv2HXV07J9688OtDZM+Xte0 Z2Tohsq1o9oOlhb65y6tv380b/np8yWThz/7+G2Uc8H81amp1Pu9nW5X6+RxZ9pWrK3PJ3tjY+RD dh27CiORNJgZyGcl0WCRJjqaHR26kKQS9gXslN2u4feJosuVsFdjqxHqhcUC43KZ9YI9jtmgbAla 3DPN5oy49XpFqkSoPbgLKMY9IFssXokeMXhBMamk5EIRXP226jq/LF+/dTPdHLtk7bVvpVH8x30/ UtdQicdOmMxnn+O53998xSfjtBn5dSNGNNN3J6THzF8Wvr53xOmXKR/10GO/S1zXkFASs/22hqLn pUSjEWNKwDCF+ZxPhBhYH2hYylG8WqvbaDboTfpFcVRAqBNCAiMIejCKRtkox+Qac2Oui1HFGGPi jHGUMdZvqkjVF+rH6IP6JXpOHxsXW6rHiGIvb6WslFZt2Gcy6tHz4pZfHuzN9xJnpkjVR0TsDRIm BMVN/Xt/HjpntyJII+VSuXDjdxf7BiTMPK1JaE5dudIpUBOT+/5w+tjpjuQOdcaXR8tnZ3CzNNKq dal7zvqZZ/akPPW6jsTL1r4m9jjKzo3R8N7AggzaR/tMoz2j8yf7FvCzckJ0h2qJqSMm5FrlMQC1 0Z3sM0tJUoE/qSJVKpSqpQZpqcRJBYUFpaJEgSRKi6QOqVO6XuIlqbBDRalU2es1uFw69tGCtD1O EYy5u21qtW4PGw+40XhxkyvvIcqsbHqD9JmslqyXOCe0HRdadLFP8UO41HJqiGYXq4ZoNnv8vYq+ V/q+a7h/lEdTcqx++gZPZqHRPuvGZQePTJ808ZMNzXtL7KWBTdUzbistHr7g6on/NYENnnX2vd/3 U5zt0dicvMzMRdUzqiqfeXAHZZo3Z1WWO/c5V0rTuNGn2paurSlEjShR5GeBWNj7ULG5xtxgZmKO RE4HpmBsE2vNsGRY5xrarCsMy6yhmFCswKnVGynWQlGs0ai3WGxm0SyKG02SxWSSWJNEPYL2QsX5 pYpUU6Gp2tRgWmLiTHGOuFLTw3G63XZRAs4EXl8/twa8eFD8YVN3v+Gr1Gj4uOnFKLseMs2DWqJs YOYLbvy8a2f3Cuq7j+7S6ScuGPPQ5ONH0Z2vm//ozJ0HmctjJjh7PfSqwnFp9ZPqS88eQzf+Ym3d LmLnpQjTuDeV2KUuUAA30Sy3keZVvNqvqkjlC/lqvoFfwnM8CSyMQkDo4DsElmdupgPouWlaZeRR x4lhk6j8vJh7MZrtyaNw2zVjZEFPy341O9TXd5SiuTeffLJv3c8HMVxCfpPRL1dOHcMCaaiKNEOz fibKj+IBodTIBbgOuoNjaQan7C0fPBRqEzl+0Jej16PaiGtDeookVXVoAzlwKrAT0ukcKSc1Wc4u TipOL8wszK5Oqk6vzm7kJycZxIzkDDpDNG+0yC6bvci+zf57++d2jreX2Tfa99jvtJ+2/2RX2e2U fEHciYnxbndKkjPJ6dwouyyy7GJlF/VI7vTcUC7t9bsqUuVCuVpukJfInOzN9ZbKD3t1u7NEx+5U 0WXkLDJKnYj9VwmeilEc5pWEq93BvH/VAXSMQ1VC1W9CCqrqBIEohnHM/HHhybTA33F0l15snVR2 w0rUEvpowtw/zLxyu/2al2fvuoGZ7RqdqujKlLQxExqHxQZiewvpVSPGZUytHD7+7DE2uGrUhOZJ zZN2nrMW5HEsXBdlLRPQWjIscw0rDMRKuP+1lRj/T6xE9ctWguu/iJXgWomR0NCE0RzZC03oUf2B dEHFiFNs9c55tlYniQbUcbzVSMfsNYquvbzNSuK4RLLB42aOm55y5AmSHe5cOHbew1GDJNjv4th1 0+onv7/vmb9NbZj49XXH3+/7c5F/44qWG0uKSjeubD5Av7yn7/PZ865+79k9lDhv9oq3erfVvbxk 2/XB8eNevarrhmlAR97oa2XvwrmSmGVTYLSRAbOTEc1u8zBjNV2VdBW1Uh3Sh8wr4xcnGQwGMS4u xiFo9HqNZqNWZ9FiJtNP9i/TUbqKGu1k7dVapj/2JPu5iOd/rR0DUJ0xESNQrQOIDpcrcfrAURxX PCAWjFiIZKIC0QtyUA2OQpEd7F1zJjW8v3bK3hELjlItRx3BwwsP/u5pJQrdOXJp/Zw7ivwl9Nk7 +96aPXd5RlpfJvfTEgxETytB6CZ3Umtd/Z/7NZL5BF2LBFcE4mL1Rdoa7SQtq1PhiUmrRTUUNBZB 0EhkLRm4FkmyhCyU2a+pSBUKhWqhQVgicILZYi4VHjajcu82GrVGAR1OubJ/n1c+EsicVz5D2YXN myjdOdtjjmnSq/Muf3jS4WORY6kbHp6Ul5XJ7NUIk8rOfsQG7wheyqlwxqbIB6wWT1Z+2BxIEKxc fpzVml/oq/RNt9blN/tWikuytbSsE4udJIjOxsIiO2UosHvYBHC50vcliDKeBFntPrAZ1kOBWCAX MAWe9fYCOyOfE5ksDzMOcw4rH9YxjGWUDZkcy8mpvEeJwoIETORYjnF2f6BNtmW7IpuBYzWJvIsG Nubzkfe587dyIkcRU7tXP12RqbFWFniXV2+/dcLYtIUlS0JVlYE/LW99pjxdI47M97SPWH1gzGV5 8/MXLxlVfckJx4jk56S8GLurbVahXxJsRtfqKZdt9hdV5qd067Ps5vi5U/MrzTqrLmHFtLG7ivwB 5Fln5FNmDXczJMK1gWk6KV7KksrMl5mbzAvMqkSaZRMcMfYElt1oj7fY7fFOvyd+avxKPG5W2J2y s3QcjJObIQQdMgeg18uxdrCIFtnCWELxVDydGLMv3mHU64W9JpsSzZT7MILzBsme4/Mh73zK3kN+ dRo4joplZSpRCc8pjNyiAtaBsygJ5sw+hlmT1LdqmUYc3ZpxpUXjLunI60JvtLUjqaP2aC0b3Nfb mzYrcdQl8erbDdLy9XJ5Ot24jxrZ9zjZKVegD3odNTsW7grMNKqd6kz1KGaUeo2qQ91hXmoXimAU vZxmYmJsDM1wyrEkFo8lsUaDYaNeZ9HrdU36+Xo6VqcnJxKywVbRk+gr6JXKyURD0/1OWF+hI55X JxDd0aHuCKA30tZzZxQfsXSfchhX4rpN3eQXBAM5k3PogPFbTQ4raBBRZxXkgO8CY8zs6xgKJMx/ eM71twvqu47uEsTJc0c/Pr6bDf58ELeXHVuTAhn0X3qvSWtNaGhoKGEqcP0PoDl+g+vnYX7AlUF5 uFE8w7EcvwnbOPYahqFlupQeTU+lZ1IcHIn8LWBVfqxUG9XUfHoVvYW+kWZpmjkSeTegwRYGOJox 0sqvcn6yKAzGiWGgoybnaIwr1N0UWQPjM1PsN72ljz7evZ1OJlPEmHITsxzHPQ7A34Nz0sGfAvPS qCx1qqaUHsYUssXq4UKlpoGdLNRr5lDz6FZmDjtDs4JeoQ5plmqtHB6QrYwkyOo0IaQOCWqtBg8e SJBVq67BUCsFiyhEtaDV8XQKT/HGTAyFaFrNCBqGVxYXryWLMxgNHQa6nBvHTefWcO08x3EhfBwV dWA1aNNQHiwP4jf5xU0TYiiZCTEhNRNUfmOjlN8MENTdqL3KcvtXjBd/T+9P4VCf776a7gTq2ZsW UovJ4pnpZ29DBtzKNJNMNNOHO85XyAUVnqIKcOoYw6FgqEv5Rn4Zz6CA0PsqAlKBHfC8S5eDnx5F T4GpdAdogFGR9ZhQJCqVYBQUYdEDgtITQXEqmlEzRopsNriOQbKS/BekFexWdxOJYSiozJ+iX6Kq Txy/mba92NdKvc3Gnz3OlCu/qJO/zjcLgjDk/TJgWPIrO16Y2Yv+BZwfXOFQWBzL80iIEbAMLI81 NT6k0WhgCBWWu0Cf+3X0eaTJD9DX8Pwg+lqt9hfoq8ifCki+OH1VVEXFq1SsSkXoa1Uq7MdjTcCH dDrdL9BXn3v14D+jryb0dWpCHzdilQYf0uvxqBxNBdl3nn4UF6KSMLiiJgnDS0Jfj0Ug5xa1Fgmg ZfwCfaG/v/Cr6Qv44QQBGcEaicogfUGhbzQa/4W+irwWghdoorkQlTRRgyF9gR9MX401HU5CFMUh uoBj/xr62qjBNIJGw2s0OFHOSFSSF1QawYD0TSbTv9BXk85ahcbFXy6Jmr9GK2g1vFZL6JvQiYFK UGk1BnxIkqSh9FW/in7U/LVIXztAXyIqr0b6WiM+ZDabh+gajo2OmFygi5ZiVNJF0ddpdFqVTqfQ Jyqv1qh0WhHpWyyWX6CPOosX5l9JX4f0dSqdntA365G+oFHrdSI+ZLVah9JXay7Qj+JyVNJHVfRa vV6l1xO/YiEmJWiRvgnp22y2oa8IIX20CbzA8G/oG6LoG7QGvdpgIPStBj0qjlYw6CWchN1u/wX6 aBN4Yf6V9A0GncGgNhgJfRtGKqDRCUaDGR+KiYkZSl/QXqAfpSVRyRhF36g3GtRGI/GLdmKyGj3S tyB9h8MxRJdxbDzgkQtM0VKMSqbBFdFkMIkak4nQjzOJ2M+gNYk2ECEhIWEofa0ejyXkAilailFJ ihpMMkomjSQRvxhPTEpn1EqmGJyELMtDbAXbAHUWL8xRXIhKlsEVs8VkMWstFuIXnRYzMsakt5jj 8PDocrmG6DKhjzqLF+ZfSd9iNVktOquV0JetFiuhb7U48KGUlJQhugx6E6DM8YKYaC5HJfvgis1u ttv0djvxi8l2G4YXZqPdlgg2yMzMHKILYDQDyhwvzOaL0o8bXImNs8XFGuMcxK9kOGLjQLKZHLFJ GITn5OSg+KN6mqyAMscLs/Wi9OOjKgkxCQ4xIYHYfXZCfAJYYqQERypOMD8/f4gugGQHmbzJSHIU F6JS1NuIic44Z6LklInd58mJTrDGWeTEDDw4FRUVwRAuWGIhCcgFZIEXS67BFTkpPkk2JyURuyxM ciWBPd6aJGfhBEtLS4foAo4NKHO8MEdxOSolD664kxOT3ZbkFGS0WJLiTobYRHtKkhcnWFlZ2a8r F1JMIniAXJgTL0o/6h3I9Ex3ZnpMZiaxy5GZGZmQ4I7LTC+GdKitrR2iC+BIIi8M4IU56aL0cwZX sr1p3uw4r5fYzShvjhfktERv1nDIgokTJ/bryoWUmAqFQC7MqRel7xtcyS/wFOQlFBSiOtjHF+YX gNvjKsyrgjyYNm1av65cSK5M8nMrXpgzL0rfP7hS7M/1F8v+UlSH2CmlJX5Iy00uLaqFImhtbUXx RPVMzoYAkAtz9kXpjxhcKRtRMKLMPaKc2GVL+fAR4ClIKx82AYaRcwWotX0T0PBSz97T59SG0VtE x+tB9aCXdOmTFx3x3yb6E1jJ3B6pIWXORt5Z6U9Yzh38HNankm/mdvLX/v//xH5B3gP4D/v8GdLY s1DCemAyfk9in4JG5EsV+xNYORFK6HxF+koiZdVzUELus29CE3s28ga5z8xT+puYNOjEthXsI/AA v42cdMm7Mqh9hOVBWICxy3yMf8m7WSNhEtJzUaGB97JVMIWUWBIjtcLJgTKFm+4TA2Uad5Y/DpQZ fGbCQJlF71g0UObQ+uIHyrziNRtgFlyFT7fAFZizYRQsVt7kngszB9rasbwIW2W0oBzynzCwbEgv OarXWAWvwj7tmGdjS+m/fb7034wjo9P4V3oZvzDLc7TvwT752DsX1yz/Ql8ZKrF0FYQUbME7/aPm YMtIpLgAvyfgvTnQhm3tSm0WfpMxliK2Kr4IbSbyLeYxyrvy/5ICQv3HH8U6P/wozkl+8Vn/jD22 6O+fpTo//yzLKb8ReIMe98L0F+jnT0jORSeoW07cf4J+bqfaefxwsvPAjcXO/TfmO3+D+cYd+c59 e3Kde/dc6tyNec/ObOcNeG/Xjhznjp01TudO70565w7ZOW7H9B30LTuowDvvvEOLZ+QzNJwRz+Se CZypOxM6wweOCtoiMo+6R3VikfgIFTgiiEXwkPiQ/BDT/GDoQfq9D9zO9z+QndCT29Pcw9T9hQq8 Wvdq6FXmm7VW51eH851fYr7lMPXm6Szn6TddzrfeznG+fUwii/vDKwZRIR55RSMWvXxM7TyFDcaT zpPek8xLx2Kd3ZgfX13rfOyY03msw++8dlutc/vWWue2renOrq2Vzi2Yt3Zc4rxpQ5xz84Yc56YN mc6NG1qd12yoc67HHNhQNrxoA3a8dZ3kXNdZ61zbUesMdI6sKursSHeuxkrHmmpnaA0VWDOysiij dVhrbWtTa3Pr4lZeNLqcNmumU8W7nLExmU6WcTnNUqYzK9uY6TGkZxhT0wzJKcYkt0F2GROdBkd8 gj4mNk5vtdn1ktmiN4omnU5v0AkarY5XqXUMy+mAonWisdNIB/hOng4wnQxthHIYB4HUDjxughcr i6ADHoeXIAJqxzC101iqdjJ+tRNK1M46HxWWaqG2viJspvB7YkXY56k9ooYJ4XxPbViom9p4iKKu bcK7YXrzEQrqw+zmIzR+SZVTpjYeoWJJ8wblZWosHaE6N2zf7jhfamryJIRbayc2hkMJTeF8Urg+ oQk8mNoXt7e3ey6SDglk9NYJFYc+Ycmr1i3hT9xVhz79RHntOvypu4oKt8rVbVXt4TXVbeE17irP RUl5LjSRgjIo5sXKDKB9sWdJ9MOLPeemBfDf4XChlQplbmRzdHJlYW0KZW5kb2JqCjE0OTkgMCBv YmoKPDwvVHlwZSAvRm9udERlc2NyaXB0b3IKL0ZvbnROYW1lIC9WZXJkYW5hLUl0YWxpYwovRmxh Z3MgNzYKL0FzY2VudCAxMDA1LjM3MTA5Ci9EZXNjZW50IDIwOS45NjA5NAovU3RlbVYgMjY2LjYw MTU2Ci9DYXBIZWlnaHQgNzI3LjA1MDc4Ci9JdGFsaWNBbmdsZSAtMTMKL0ZvbnRCQm94IFstNDE3 LjQ4MDQ3IC0zMDMuMjIyNjYgMTQ2MC45Mzc1IDEwMDAuNDg4MjhdCi9Gb250RmlsZTIgMTQ5OCAw IFI+PgplbmRvYmoKMTUwMCAwIG9iago8PC9UeXBlIC9Gb250Ci9Gb250RGVzY3JpcHRvciAxNDk5 IDAgUgovQmFzZUZvbnQgL1ZlcmRhbmEtSXRhbGljCi9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0NJ RFRvR0lETWFwIC9JZGVudGl0eQovQ0lEU3lzdGVtSW5mbyA8PC9SZWdpc3RyeSAoQWRvYmUpCi9P cmRlcmluZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50IDA+PgovVyBbMCBbMTAwMCAwIDAgMzUxLjU2 MjVdIDE3IFszNjMuNzY5NTMgNDU0LjEwMTU2XSAyMCAyNyA2MzUuNzQyMTkgMjkgWzQ1NC4xMDE1 Nl0gNTUgWzYxNi4yMTA5NF0gNjggWzYwMC41ODU5NCA2MjMuMDQ2ODggNTIwLjk5NjA5IDYyMy4w NDY4OCA1OTUuNzAzMTMgMzUxLjU2MjUgNjIxLjU4MjAzIDYzMi44MTI1IDI3NC40MTQwNiAwIDAg Mjc0LjQxNDA2IDk3My4xNDQ1MyA2MzIuODEyNSA2MDYuOTMzNTkgNjIzLjA0Njg4IDAgNDI2Ljc1 NzgxIDUyMC45OTYwOSAzOTQuMDQyOTcgNjMyLjgxMjUgNTkwLjgyMDMxIDgxOC4zNTkzOCAwIDU5 MC44MjAzMV1dCi9EVyAwPj4KZW5kb2JqCjE1MDEgMCBvYmoKPDwvRmlsdGVyIC9GbGF0ZURlY29k ZQovTGVuZ3RoIDMwMD4+IHN0cmVhbQp4nF2R3WqEMBCF7/MUc7m9WDSuu7Ygwtbtghf9obYPoMm4 DdQYYrzw7Rsz1kIDCp9zzsxxEpXVpdLKQfRmB1Gjg05paXEcJisQWrwpzXgCUgm3UniLvjEs8uZ6 Hh32le4GlucA0buvjs7OsDvLocU7Fr1aiVbpG+w+y9pzPRnzjT1qBzErCpDY+U7PjXlpeoQo2PaV 9HXl5r33/Ck+ZoOQBOaURgwSR9MItI2+IctjfwrIr/4UDLX8V8/I1Xbiq7FBffDqOE7iYiGeBjpw oowoJXokuie6EJ0DHUh5JOWxDJQ9hATrrPR38haU8yDjCSV4Ct6UEqTU4kRB0iu1p6ynkqYc6eOZ hiXrMGq//PlyQ9taxWSt32i4xrDKZYlK43bTZjCLa3l+AK3tmWEKZW5kc3RyZWFtCmVuZG9iagoy NyAwIG9iago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL1ZlcmRhbmEt SXRhbGljCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsxNTAwIDAgUl0K L1RvVW5pY29kZSAxNTAxIDAgUj4+CmVuZG9iagp4cmVmCjAgMTUwMgowMDAwMDAwMDAwIDY1NTM1 IGYgCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAzMDgxNSAwMDAwMCBuIAowMDAwMDAwMjcwIDAw MDAwIG4gCjAwMDAzNjEzOTMgMDAwMDAgbiAKMDAwMDM3ODA3MiAwMDAwMCBuIAowMDAwNDA4Mzgz IDAwMDAwIG4gCjAwMDA0MjE3OTYgMDAwMDAgbiAKMDAwMDQzNzg3MiAwMDAwMCBuIAowMDAwMDAw MzA3IDAwMDAwIG4gCjAwMDAwMDA1NDYgMDAwMDAgbiAKMDAwMDAwMDc3NyAwMDAwMCBuIAowMDAw MDAwOTMwIDAwMDAwIG4gCjAwMDAwMDEwODIgMDAwMDAgbiAKMDAwMDAwMTIzNSAwMDAwMCBuIAow MDAwMDAxMzg3IDAwMDAwIG4gCjAwMDAwMDE1NDEgMDAwMDAgbiAKMDAwMDAwMTY5NCAwMDAwMCBu IAowMDAwMDMxMTMwIDAwMDAwIG4gCjAwMDAwMTQ3NjkgMDAwMDAgbiAKMDAwMDAxNDkyMiAwMDAw MCBuIAowMDAwMDE1MDc0IDAwMDAwIG4gCjAwMDAwMTUyMjcgMDAwMDAgbiAKMDAwMDAxNTM3OSAw MDAwMCBuIAowMDAwMDE1NTMyIDAwMDAwIG4gCjAwMDAwMTU2ODQgMDAwMDAgbiAKMDAwMDAzMTQz MyAwMDAwMCBuIAowMDAwNDQ4NTMyIDAwMDAwIG4gCjAwMDAwMjkzMDUgMDAwMDAgbiAKMDAwMDAy OTUyMCAwMDAwMCBuIAowMDAwMDMxNjgzIDAwMDAwIG4gCjAwMDAwMzE3NTMgMDAwMDAgbiAKMDAw MDM0NDgxNiAwMDAwMCBuIAowMDAwMzA1MzQ4IDAwMDAwIG4gCjAwMDAzMDM0ODAgMDAwMDAgbiAK MDAwMDAzMzI0MiAwMDAwMCBuIAowMDAwMDMyNzYyIDAwMDAwIG4gCjAwMDAwMzIxNTQgMDAwMDAg biAKMDAwMDAzMjAzNSAwMDAwMCBuIAowMDAwMDMyMjc5IDAwMDAwIG4gCjAwMDAwMzI1MTcgMDAw MDAgbiAKMDAwMDAzMjM5OCAwMDAwMCBuIAowMDAwMDMyNjQzIDAwMDAwIG4gCjAwMDAwMzMwNzIg MDAwMDAgbiAKMDAwMDAzMjk1MyAwMDAwMCBuIAowMDAwMDMzNzU1IDAwMDAwIG4gCjAwMDAwMzM0 NTQgMDAwMDAgbiAKMDAwMDAzMzMzNSAwMDAwMCBuIAowMDAwMDM1MTAxIDAwMDAwIG4gCjAwMDAw MzM5NjAgMDAwMDAgbiAKMDAwMDAzMzg0MSAwMDAwMCBuIAowMDAwMDM0MzgwIDAwMDAwIG4gCjAw MDAwMzQyNjEgMDAwMDAgbiAKMDAwMDAzNDgwMCAwMDAwMCBuIAowMDAwMDM0NjgxIDAwMDAwIG4g CjAwMDAwMzY0NjMgMDAwMDAgbiAKMDAwMDAzNTMyMCAwMDAwMCBuIAowMDAwMDM1MjAxIDAwMDAw IG4gCjAwMDAwMzU3NDEgMDAwMDAgbiAKMDAwMDAzNTYyMSAwMDAwMCBuIAowMDAwMDM2MTYyIDAw MDAwIG4gCjAwMDAwMzYwNDIgMDAwMDAgbiAKMDAwMDAzNzgyNiAwMDAwMCBuIAowMDAwMDM2Njgz IDAwMDAwIG4gCjAwMDAwMzY1NjMgMDAwMDAgbiAKMDAwMDAzNzEwNCAwMDAwMCBuIAowMDAwMDM2 OTg0IDAwMDAwIG4gCjAwMDAwMzc1MjUgMDAwMDAgbiAKMDAwMDAzNzQwNSAwMDAwMCBuIAowMDAw MDM5Njk3IDAwMDAwIG4gCjAwMDAwMzgyODYgMDAwMDAgbiAKMDAwMDAzNzkyNiAwMDAwMCBuIAow MDAwMDM4MDQ2IDAwMDAwIG4gCjAwMDAwMzgxNjYgMDAwMDAgbiAKMDAwMDAzODcyMSAwMDAwMCBu IAowMDAwMDM4NjAxIDAwMDAwIG4gCjAwMDAwMzkzODIgMDAwMDAgbiAKMDAwMDAzOTAyMiAwMDAw MCBuIAowMDAwMDM5MTQyIDAwMDAwIG4gCjAwMDAwMzkyNjIgMDAwMDAgbiAKMDAwMDA0MTA2MCAw MDAwMCBuIAowMDAwMDM5OTE3IDAwMDAwIG4gCjAwMDAwMzk3OTcgMDAwMDAgbiAKMDAwMDA0MDMz OCAwMDAwMCBuIAowMDAwMDQwMjE4IDAwMDAwIG4gCjAwMDAwNDA3NTkgMDAwMDAgbiAKMDAwMDA0 MDYzOSAwMDAwMCBuIAowMDAwMDQyOTMxIDAwMDAwIG4gCjAwMDAwNDE1MjAgMDAwMDAgbiAKMDAw MDA0MTE2MCAwMDAwMCBuIAowMDAwMDQxMjgwIDAwMDAwIG4gCjAwMDAwNDE0MDAgMDAwMDAgbiAK MDAwMDA0MTk1NSAwMDAwMCBuIAowMDAwMDQxODM1IDAwMDAwIG4gCjAwMDAwNDI2MTYgMDAwMDAg biAKMDAwMDA0MjI1NiAwMDAwMCBuIAowMDAwMDQyMzc2IDAwMDAwIG4gCjAwMDAwNDI0OTYgMDAw MDAgbiAKMDAwMDA0MzQ1NCAwMDAwMCBuIAowMDAwMDQzMTUyIDAwMDAwIG4gCjAwMDAwNDMwMzEg MDAwMDAgbiAKMDAwMDA0NDgxOCAwMDAwMCBuIAowMDAwMDQzNjYyIDAwMDAwIG4gCjAwMDAwNDM1 NDAgMDAwMDAgbiAKMDAwMDA0NDA4OCAwMDAwMCBuIAowMDAwMDQzOTY2IDAwMDAwIG4gCjAwMDAw NDQ1MTQgMDAwMDAgbiAKMDAwMDA0NDM5MiAwMDAwMCBuIAowMDAwMDQ2MjAwIDAwMDAwIG4gCjAw MDAwNDUwNDQgMDAwMDAgbiAKMDAwMDA0NDkyMiAwMDAwMCBuIAowMDAwMDQ1NDcwIDAwMDAwIG4g CjAwMDAwNDUzNDggMDAwMDAgbiAKMDAwMDA0NTg5NiAwMDAwMCBuIAowMDAwMDQ1Nzc0IDAwMDAw IG4gCjAwMDAwNDY3MzAgMDAwMDAgbiAKMDAwMDA0NjQyNiAwMDAwMCBuIAowMDAwMDQ2MzA0IDAw MDAwIG4gCjAwMDAwNDgwOTYgMDAwMDAgbiAKMDAwMDA0Njk0MCAwMDAwMCBuIAowMDAwMDQ2ODE4 IDAwMDAwIG4gCjAwMDAwNDczNjYgMDAwMDAgbiAKMDAwMDA0NzI0NCAwMDAwMCBuIAowMDAwMDQ3 NzkyIDAwMDAwIG4gCjAwMDAwNDc2NzAgMDAwMDAgbiAKMDAwMDA0ODYyNiAwMDAwMCBuIAowMDAw MDQ4MzIyIDAwMDAwIG4gCjAwMDAwNDgyMDAgMDAwMDAgbiAKMDAwMDA0OTk5MiAwMDAwMCBuIAow MDAwMDQ4ODM2IDAwMDAwIG4gCjAwMDAwNDg3MTQgMDAwMDAgbiAKMDAwMDA0OTI2MiAwMDAwMCBu IAowMDAwMDQ5MTQwIDAwMDAwIG4gCjAwMDAwNDk2ODggMDAwMDAgbiAKMDAwMDA0OTU2NiAwMDAw MCBuIAowMDAwMDUxMzc0IDAwMDAwIG4gCjAwMDAwNTAyMTggMDAwMDAgbiAKMDAwMDA1MDA5NiAw MDAwMCBuIAowMDAwMDUwNjQ0IDAwMDAwIG4gCjAwMDAwNTA1MjIgMDAwMDAgbiAKMDAwMDA1MTA3 MCAwMDAwMCBuIAowMDAwMDUwOTQ4IDAwMDAwIG4gCjAwMDAwNTI3NTYgMDAwMDAgbiAKMDAwMDA1 MTYwMCAwMDAwMCBuIAowMDAwMDUxNDc4IDAwMDAwIG4gCjAwMDAwNTIwMjYgMDAwMDAgbiAKMDAw MDA1MTkwNCAwMDAwMCBuIAowMDAwMDUyNDUyIDAwMDAwIG4gCjAwMDAwNTIzMzAgMDAwMDAgbiAK MDAwMDA1NDEzOCAwMDAwMCBuIAowMDAwMDUyOTgyIDAwMDAwIG4gCjAwMDAwNTI4NjAgMDAwMDAg biAKMDAwMDA1MzQwOCAwMDAwMCBuIAowMDAwMDUzMjg2IDAwMDAwIG4gCjAwMDAwNTM4MzQgMDAw MDAgbiAKMDAwMDA1MzcxMiAwMDAwMCBuIAowMDAwMDU0NjY4IDAwMDAwIG4gCjAwMDAwNTQzNjQg MDAwMDAgbiAKMDAwMDA1NDI0MiAwMDAwMCBuIAowMDAwMDU1ODY0IDAwMDAwIG4gCjAwMDAwNTUx MjkgMDAwMDAgbiAKMDAwMDA1NDc1NiAwMDAwMCBuIAowMDAwMDU1MDAwIDAwMDAwIG4gCjAwMDAw NTQ4NzggMDAwMDAgbiAKMDAwMDA1NTY4MyAwMDAwMCBuIAowMDAwMDU1MzEwIDAwMDAwIG4gCjAw MDAwNTU1NTQgMDAwMDAgbiAKMDAwMDA1NTQzMiAwMDAwMCBuIAowMDAwMDU3MjM4IDAwMDAwIG4g CjAwMDAwNTYwODIgMDAwMDAgbiAKMDAwMDA1NTk2MCAwMDAwMCBuIAowMDAwMDU2NTA4IDAwMDAw IG4gCjAwMDAwNTYzODYgMDAwMDAgbiAKMDAwMDA1NjkzNCAwMDAwMCBuIAowMDAwMDU2ODEyIDAw MDAwIG4gCjAwMDAwNTg2MjAgMDAwMDAgbiAKMDAwMDA1NzQ2NCAwMDAwMCBuIAowMDAwMDU3MzQy IDAwMDAwIG4gCjAwMDAwNTc4OTAgMDAwMDAgbiAKMDAwMDA1Nzc2OCAwMDAwMCBuIAowMDAwMDU4 MzE2IDAwMDAwIG4gCjAwMDAwNTgxOTQgMDAwMDAgbiAKMDAwMDA2MDAwMiAwMDAwMCBuIAowMDAw MDU4ODQ2IDAwMDAwIG4gCjAwMDAwNTg3MjQgMDAwMDAgbiAKMDAwMDA1OTI3MiAwMDAwMCBuIAow MDAwMDU5MTUwIDAwMDAwIG4gCjAwMDAwNTk2OTggMDAwMDAgbiAKMDAwMDA1OTU3NiAwMDAwMCBu IAowMDAwMDYxMzg0IDAwMDAwIG4gCjAwMDAwNjAyMjggMDAwMDAgbiAKMDAwMDA2MDEwNiAwMDAw MCBuIAowMDAwMDYwNjU0IDAwMDAwIG4gCjAwMDAwNjA1MzIgMDAwMDAgbiAKMDAwMDA2MTA4MCAw MDAwMCBuIAowMDAwMDYwOTU4IDAwMDAwIG4gCjAwMDAwNjE5MTQgMDAwMDAgbiAKMDAwMDA2MTYx MCAwMDAwMCBuIAowMDAwMDYxNDg4IDAwMDAwIG4gCjAwMDAwNjMyODAgMDAwMDAgbiAKMDAwMDA2 MjEyNCAwMDAwMCBuIAowMDAwMDYyMDAyIDAwMDAwIG4gCjAwMDAwNjI1NTAgMDAwMDAgbiAKMDAw MDA2MjQyOCAwMDAwMCBuIAowMDAwMDYyOTc2IDAwMDAwIG4gCjAwMDAwNjI4NTQgMDAwMDAgbiAK MDAwMDA2NDY2MiAwMDAwMCBuIAowMDAwMDYzNTA2IDAwMDAwIG4gCjAwMDAwNjMzODQgMDAwMDAg biAKMDAwMDA2MzkzMiAwMDAwMCBuIAowMDAwMDYzODEwIDAwMDAwIG4gCjAwMDAwNjQzNTggMDAw MDAgbiAKMDAwMDA2NDIzNiAwMDAwMCBuIAowMDAwMDY2MDQ0IDAwMDAwIG4gCjAwMDAwNjQ4ODgg MDAwMDAgbiAKMDAwMDA2NDc2NiAwMDAwMCBuIAowMDAwMDY1MzE0IDAwMDAwIG4gCjAwMDAwNjUx OTIgMDAwMDAgbiAKMDAwMDA2NTc0MCAwMDAwMCBuIAowMDAwMDY1NjE4IDAwMDAwIG4gCjAwMDAw Njc0MjYgMDAwMDAgbiAKMDAwMDA2NjI3MCAwMDAwMCBuIAowMDAwMDY2MTQ4IDAwMDAwIG4gCjAw MDAwNjY2OTYgMDAwMDAgbiAKMDAwMDA2NjU3NCAwMDAwMCBuIAowMDAwMDY3MTIyIDAwMDAwIG4g CjAwMDAwNjcwMDAgMDAwMDAgbiAKMDAwMDA2Nzk1NiAwMDAwMCBuIAowMDAwMDY3NjUyIDAwMDAw IG4gCjAwMDAwNjc1MzAgMDAwMDAgbiAKMDAwMDA2OTg0MiAwMDAwMCBuIAowMDAwMDY4NDEwIDAw MDAwIG4gCjAwMDAwNjgwNDQgMDAwMDAgbiAKMDAwMDA2ODE2NiAwMDAwMCBuIAowMDAwMDY4Mjg4 IDAwMDAwIG4gCjAwMDAwNjg4NTIgMDAwMDAgbiAKMDAwMDA2ODczMCAwMDAwMCBuIAowMDAwMDY5 NTIyIDAwMDAwIG4gCjAwMDAwNjkxNTYgMDAwMDAgbiAKMDAwMDA2OTI3OCAwMDAwMCBuIAowMDAw MDY5NDAwIDAwMDAwIG4gCjAwMDAwNzAzNzIgMDAwMDAgbiAKMDAwMDA3MDA2OCAwMDAwMCBuIAow MDAwMDY5OTQ2IDAwMDAwIG4gCjAwMDAwNzE3MzggMDAwMDAgbiAKMDAwMDA3MDU4MiAwMDAwMCBu IAowMDAwMDcwNDYwIDAwMDAwIG4gCjAwMDAwNzEwMDggMDAwMDAgbiAKMDAwMDA3MDg4NiAwMDAw MCBuIAowMDAwMDcxNDM0IDAwMDAwIG4gCjAwMDAwNzEzMTIgMDAwMDAgbiAKMDAwMDA3MjI2OCAw MDAwMCBuIAowMDAwMDcxOTY0IDAwMDAwIG4gCjAwMDAwNzE4NDIgMDAwMDAgbiAKMDAwMDA3MzYz NiAwMDAwMCBuIAowMDAwMDcyNDc4IDAwMDAwIG4gCjAwMDAwNzIzNTYgMDAwMDAgbiAKMDAwMDA3 MjkwNSAwMDAwMCBuIAowMDAwMDcyNzgyIDAwMDAwIG4gCjAwMDAwNzMzMzIgMDAwMDAgbiAKMDAw MDA3MzIwOSAwMDAwMCBuIAowMDAwMDc1MDIxIDAwMDAwIG4gCjAwMDAwNzM4NjMgMDAwMDAgbiAK MDAwMDA3Mzc0MCAwMDAwMCBuIAowMDAwMDc0MjkwIDAwMDAwIG4gCjAwMDAwNzQxNjcgMDAwMDAg biAKMDAwMDA3NDcxNyAwMDAwMCBuIAowMDAwMDc0NTk0IDAwMDAwIG4gCjAwMDAwNzU1NTIgMDAw MDAgbiAKMDAwMDA3NTI0OCAwMDAwMCBuIAowMDAwMDc1MTI1IDAwMDAwIG4gCjAwMDAwNzY5MjEg MDAwMDAgbiAKMDAwMDA3NTc2MyAwMDAwMCBuIAowMDAwMDc1NjQwIDAwMDAwIG4gCjAwMDAwNzYx OTAgMDAwMDAgbiAKMDAwMDA3NjA2NyAwMDAwMCBuIAowMDAwMDc2NjE3IDAwMDAwIG4gCjAwMDAw NzY0OTQgMDAwMDAgbiAKMDAwMDA3ODMwNiAwMDAwMCBuIAowMDAwMDc3MTQ4IDAwMDAwIG4gCjAw MDAwNzcwMjUgMDAwMDAgbiAKMDAwMDA3NzU3NSAwMDAwMCBuIAowMDAwMDc3NDUyIDAwMDAwIG4g CjAwMDAwNzgwMDIgMDAwMDAgbiAKMDAwMDA3Nzg3OSAwMDAwMCBuIAowMDAwMDc5NjkxIDAwMDAw IG4gCjAwMDAwNzg1MzMgMDAwMDAgbiAKMDAwMDA3ODQxMCAwMDAwMCBuIAowMDAwMDc4OTYwIDAw MDAwIG4gCjAwMDAwNzg4MzcgMDAwMDAgbiAKMDAwMDA3OTM4NyAwMDAwMCBuIAowMDAwMDc5MjY0 IDAwMDAwIG4gCjAwMDAwODEwNzYgMDAwMDAgbiAKMDAwMDA3OTkxOCAwMDAwMCBuIAowMDAwMDc5 Nzk1IDAwMDAwIG4gCjAwMDAwODAzNDUgMDAwMDAgbiAKMDAwMDA4MDIyMiAwMDAwMCBuIAowMDAw MDgwNzcyIDAwMDAwIG4gCjAwMDAwODA2NDkgMDAwMDAgbiAKMDAwMDA4MTYwNyAwMDAwMCBuIAow MDAwMDgxMzAzIDAwMDAwIG4gCjAwMDAwODExODAgMDAwMDAgbiAKMDAwMDA4MjgwNyAwMDAwMCBu IAowMDAwMDgyMDcwIDAwMDAwIG4gCjAwMDAwODE2OTUgMDAwMDAgbiAKMDAwMDA4MTk0MSAwMDAw MCBuIAowMDAwMDgxODE4IDAwMDAwIG4gCjAwMDAwODI2MjYgMDAwMDAgbiAKMDAwMDA4MjI1MSAw MDAwMCBuIAowMDAwMDgyNDk3IDAwMDAwIG4gCjAwMDAwODIzNzQgMDAwMDAgbiAKMDAwMDA4NDE4 NCAwMDAwMCBuIAowMDAwMDgzMDI2IDAwMDAwIG4gCjAwMDAwODI5MDMgMDAwMDAgbiAKMDAwMDA4 MzQ1MyAwMDAwMCBuIAowMDAwMDgzMzMwIDAwMDAwIG4gCjAwMDAwODM4ODAgMDAwMDAgbiAKMDAw MDA4Mzc1NyAwMDAwMCBuIAowMDAwMDg1NTY5IDAwMDAwIG4gCjAwMDAwODQ0MTEgMDAwMDAgbiAK MDAwMDA4NDI4OCAwMDAwMCBuIAowMDAwMDg0ODM4IDAwMDAwIG4gCjAwMDAwODQ3MTUgMDAwMDAg biAKMDAwMDA4NTI2NSAwMDAwMCBuIAowMDAwMDg1MTQyIDAwMDAwIG4gCjAwMDAwODY5NTQgMDAw MDAgbiAKMDAwMDA4NTc5NiAwMDAwMCBuIAowMDAwMDg1NjczIDAwMDAwIG4gCjAwMDAwODYyMjMg MDAwMDAgbiAKMDAwMDA4NjEwMCAwMDAwMCBuIAowMDAwMDg2NjUwIDAwMDAwIG4gCjAwMDAwODY1 MjcgMDAwMDAgbiAKMDAwMDA4ODMzOSAwMDAwMCBuIAowMDAwMDg3MTgxIDAwMDAwIG4gCjAwMDAw ODcwNTggMDAwMDAgbiAKMDAwMDA4NzYwOCAwMDAwMCBuIAowMDAwMDg3NDg1IDAwMDAwIG4gCjAw MDAwODgwMzUgMDAwMDAgbiAKMDAwMDA4NzkxMiAwMDAwMCBuIAowMDAwMDg5NzI0IDAwMDAwIG4g CjAwMDAwODg1NjYgMDAwMDAgbiAKMDAwMDA4ODQ0MyAwMDAwMCBuIAowMDAwMDg4OTkzIDAwMDAw IG4gCjAwMDAwODg4NzAgMDAwMDAgbiAKMDAwMDA4OTQyMCAwMDAwMCBuIAowMDAwMDg5Mjk3IDAw MDAwIG4gCjAwMDAwOTExMDkgMDAwMDAgbiAKMDAwMDA4OTk1MSAwMDAwMCBuIAowMDAwMDg5ODI4 IDAwMDAwIG4gCjAwMDAwOTAzNzggMDAwMDAgbiAKMDAwMDA5MDI1NSAwMDAwMCBuIAowMDAwMDkw ODA1IDAwMDAwIG4gCjAwMDAwOTA2ODIgMDAwMDAgbiAKMDAwMDA5MjQ5NCAwMDAwMCBuIAowMDAw MDkxMzM2IDAwMDAwIG4gCjAwMDAwOTEyMTMgMDAwMDAgbiAKMDAwMDA5MTc2MyAwMDAwMCBuIAow MDAwMDkxNjQwIDAwMDAwIG4gCjAwMDAwOTIxOTAgMDAwMDAgbiAKMDAwMDA5MjA2NyAwMDAwMCBu IAowMDAwMDkzODc5IDAwMDAwIG4gCjAwMDAwOTI3MjEgMDAwMDAgbiAKMDAwMDA5MjU5OCAwMDAw MCBuIAowMDAwMDkzMTQ4IDAwMDAwIG4gCjAwMDAwOTMwMjUgMDAwMDAgbiAKMDAwMDA5MzU3NSAw MDAwMCBuIAowMDAwMDkzNDUyIDAwMDAwIG4gCjAwMDAwOTUyNjQgMDAwMDAgbiAKMDAwMDA5NDEw NiAwMDAwMCBuIAowMDAwMDkzOTgzIDAwMDAwIG4gCjAwMDAwOTQ1MzMgMDAwMDAgbiAKMDAwMDA5 NDQxMCAwMDAwMCBuIAowMDAwMDk0OTYwIDAwMDAwIG4gCjAwMDAwOTQ4MzcgMDAwMDAgbiAKMDAw MDA5NjY0OSAwMDAwMCBuIAowMDAwMDk1NDkxIDAwMDAwIG4gCjAwMDAwOTUzNjggMDAwMDAgbiAK MDAwMDA5NTkxOCAwMDAwMCBuIAowMDAwMDk1Nzk1IDAwMDAwIG4gCjAwMDAwOTYzNDUgMDAwMDAg biAKMDAwMDA5NjIyMiAwMDAwMCBuIAowMDAwMDk4Mjk2IDAwMDAwIG4gCjAwMDAwOTY5OTkgMDAw MDAgbiAKMDAwMDA5Njc1MyAwMDAwMCBuIAowMDAwMDk2ODc2IDAwMDAwIG4gCjAwMDAwOTc0MzQg MDAwMDAgbiAKMDAwMDA5NzMxMSAwMDAwMCBuIAowMDAwMDk3OTg0IDAwMDAwIG4gCjAwMDAwOTc3 MzggMDAwMDAgbiAKMDAwMDA5Nzg2MSAwMDAwMCBuIAowMDAwMDk5NjgxIDAwMDAwIG4gCjAwMDAw OTg1MjMgMDAwMDAgbiAKMDAwMDA5ODQwMCAwMDAwMCBuIAowMDAwMDk4OTUwIDAwMDAwIG4gCjAw MDAwOTg4MjcgMDAwMDAgbiAKMDAwMDA5OTM3NyAwMDAwMCBuIAowMDAwMDk5MjU0IDAwMDAwIG4g CjAwMDAxMDEwNjYgMDAwMDAgbiAKMDAwMDA5OTkwOCAwMDAwMCBuIAowMDAwMDk5Nzg1IDAwMDAw IG4gCjAwMDAxMDAzMzUgMDAwMDAgbiAKMDAwMDEwMDIxMiAwMDAwMCBuIAowMDAwMTAwNzYyIDAw MDAwIG4gCjAwMDAxMDA2MzkgMDAwMDAgbiAKMDAwMDEwMjcxMyAwMDAwMCBuIAowMDAwMTAxNDE2 IDAwMDAwIG4gCjAwMDAxMDExNzAgMDAwMDAgbiAKMDAwMDEwMTI5MyAwMDAwMCBuIAowMDAwMTAx ODUxIDAwMDAwIG4gCjAwMDAxMDE3MjggMDAwMDAgbiAKMDAwMDEwMjQwMSAwMDAwMCBuIAowMDAw MTAyMTU1IDAwMDAwIG4gCjAwMDAxMDIyNzggMDAwMDAgbiAKMDAwMDEwNDA5OCAwMDAwMCBuIAow MDAwMTAyOTQwIDAwMDAwIG4gCjAwMDAxMDI4MTcgMDAwMDAgbiAKMDAwMDEwMzM2NyAwMDAwMCBu IAowMDAwMTAzMjQ0IDAwMDAwIG4gCjAwMDAxMDM3OTQgMDAwMDAgbiAKMDAwMDEwMzY3MSAwMDAw MCBuIAowMDAwMTA1NDgzIDAwMDAwIG4gCjAwMDAxMDQzMjUgMDAwMDAgbiAKMDAwMDEwNDIwMiAw MDAwMCBuIAowMDAwMTA0NzUyIDAwMDAwIG4gCjAwMDAxMDQ2MjkgMDAwMDAgbiAKMDAwMDEwNTE3 OSAwMDAwMCBuIAowMDAwMTA1MDU2IDAwMDAwIG4gCjAwMDAxMDY4NjggMDAwMDAgbiAKMDAwMDEw NTcxMCAwMDAwMCBuIAowMDAwMTA1NTg3IDAwMDAwIG4gCjAwMDAxMDYxMzcgMDAwMDAgbiAKMDAw MDEwNjAxNCAwMDAwMCBuIAowMDAwMTA2NTY0IDAwMDAwIG4gCjAwMDAxMDY0NDEgMDAwMDAgbiAK MDAwMDEwODI1MyAwMDAwMCBuIAowMDAwMTA3MDk1IDAwMDAwIG4gCjAwMDAxMDY5NzIgMDAwMDAg biAKMDAwMDEwNzUyMiAwMDAwMCBuIAowMDAwMTA3Mzk5IDAwMDAwIG4gCjAwMDAxMDc5NDkgMDAw MDAgbiAKMDAwMDEwNzgyNiAwMDAwMCBuIAowMDAwMTA5OTAwIDAwMDAwIG4gCjAwMDAxMDg2MDMg MDAwMDAgbiAKMDAwMDEwODM1NyAwMDAwMCBuIAowMDAwMTA4NDgwIDAwMDAwIG4gCjAwMDAxMDkw MzggMDAwMDAgbiAKMDAwMDEwODkxNSAwMDAwMCBuIAowMDAwMTA5NTg4IDAwMDAwIG4gCjAwMDAx MDkzNDIgMDAwMDAgbiAKMDAwMDEwOTQ2NSAwMDAwMCBuIAowMDAwMTExNTQ3IDAwMDAwIG4gCjAw MDAxMTAyNTAgMDAwMDAgbiAKMDAwMDExMDAwNCAwMDAwMCBuIAowMDAwMTEwMTI3IDAwMDAwIG4g CjAwMDAxMTA2ODUgMDAwMDAgbiAKMDAwMDExMDU2MiAwMDAwMCBuIAowMDAwMTExMjM1IDAwMDAw IG4gCjAwMDAxMTA5ODkgMDAwMDAgbiAKMDAwMDExMTExMiAwMDAwMCBuIAowMDAwMTEzMTk0IDAw MDAwIG4gCjAwMDAxMTE4OTcgMDAwMDAgbiAKMDAwMDExMTY1MSAwMDAwMCBuIAowMDAwMTExNzc0 IDAwMDAwIG4gCjAwMDAxMTIzMzIgMDAwMDAgbiAKMDAwMDExMjIwOSAwMDAwMCBuIAowMDAwMTEy ODgyIDAwMDAwIG4gCjAwMDAxMTI2MzYgMDAwMDAgbiAKMDAwMDExMjc1OSAwMDAwMCBuIAowMDAw MTE0ODQxIDAwMDAwIG4gCjAwMDAxMTM1NDQgMDAwMDAgbiAKMDAwMDExMzI5OCAwMDAwMCBuIAow MDAwMTEzNDIxIDAwMDAwIG4gCjAwMDAxMTM5NzkgMDAwMDAgbiAKMDAwMDExMzg1NiAwMDAwMCBu IAowMDAwMTE0NTI5IDAwMDAwIG4gCjAwMDAxMTQyODMgMDAwMDAgbiAKMDAwMDExNDQwNiAwMDAw MCBuIAowMDAwMTE2NDg4IDAwMDAwIG4gCjAwMDAxMTUxOTEgMDAwMDAgbiAKMDAwMDExNDk0NSAw MDAwMCBuIAowMDAwMTE1MDY4IDAwMDAwIG4gCjAwMDAxMTU2MjYgMDAwMDAgbiAKMDAwMDExNTUw MyAwMDAwMCBuIAowMDAwMTE2MTc2IDAwMDAwIG4gCjAwMDAxMTU5MzAgMDAwMDAgbiAKMDAwMDEx NjA1MyAwMDAwMCBuIAowMDAwMTE4MTM1IDAwMDAwIG4gCjAwMDAxMTY4MzggMDAwMDAgbiAKMDAw MDExNjU5MiAwMDAwMCBuIAowMDAwMTE2NzE1IDAwMDAwIG4gCjAwMDAxMTcyNzMgMDAwMDAgbiAK MDAwMDExNzE1MCAwMDAwMCBuIAowMDAwMTE3ODIzIDAwMDAwIG4gCjAwMDAxMTc1NzcgMDAwMDAg biAKMDAwMDExNzcwMCAwMDAwMCBuIAowMDAwMTE5NzgyIDAwMDAwIG4gCjAwMDAxMTg0ODUgMDAw MDAgbiAKMDAwMDExODIzOSAwMDAwMCBuIAowMDAwMTE4MzYyIDAwMDAwIG4gCjAwMDAxMTg5MjAg MDAwMDAgbiAKMDAwMDExODc5NyAwMDAwMCBuIAowMDAwMTE5NDcwIDAwMDAwIG4gCjAwMDAxMTky MjQgMDAwMDAgbiAKMDAwMDExOTM0NyAwMDAwMCBuIAowMDAwMTIxNDI5IDAwMDAwIG4gCjAwMDAx MjAxMzIgMDAwMDAgbiAKMDAwMDExOTg4NiAwMDAwMCBuIAowMDAwMTIwMDA5IDAwMDAwIG4gCjAw MDAxMjA1NjcgMDAwMDAgbiAKMDAwMDEyMDQ0NCAwMDAwMCBuIAowMDAwMTIxMTE3IDAwMDAwIG4g CjAwMDAxMjA4NzEgMDAwMDAgbiAKMDAwMDEyMDk5NCAwMDAwMCBuIAowMDAwMTIyODE0IDAwMDAw IG4gCjAwMDAxMjE2NTYgMDAwMDAgbiAKMDAwMDEyMTUzMyAwMDAwMCBuIAowMDAwMTIyMDgzIDAw MDAwIG4gCjAwMDAxMjE5NjAgMDAwMDAgbiAKMDAwMDEyMjUxMCAwMDAwMCBuIAowMDAwMTIyMzg3 IDAwMDAwIG4gCjAwMDAxMjQ0NjEgMDAwMDAgbiAKMDAwMDEyMzE2NCAwMDAwMCBuIAowMDAwMTIy OTE4IDAwMDAwIG4gCjAwMDAxMjMwNDEgMDAwMDAgbiAKMDAwMDEyMzU5OSAwMDAwMCBuIAowMDAw MTIzNDc2IDAwMDAwIG4gCjAwMDAxMjQxNDkgMDAwMDAgbiAKMDAwMDEyMzkwMyAwMDAwMCBuIAow MDAwMTI0MDI2IDAwMDAwIG4gCjAwMDAxMjYxMDggMDAwMDAgbiAKMDAwMDEyNDgxMSAwMDAwMCBu IAowMDAwMTI0NTY1IDAwMDAwIG4gCjAwMDAxMjQ2ODggMDAwMDAgbiAKMDAwMDEyNTI0NiAwMDAw MCBuIAowMDAwMTI1MTIzIDAwMDAwIG4gCjAwMDAxMjU3OTYgMDAwMDAgbiAKMDAwMDEyNTU1MCAw MDAwMCBuIAowMDAwMTI1NjczIDAwMDAwIG4gCjAwMDAxMjc3NTUgMDAwMDAgbiAKMDAwMDEyNjQ1 OCAwMDAwMCBuIAowMDAwMTI2MjEyIDAwMDAwIG4gCjAwMDAxMjYzMzUgMDAwMDAgbiAKMDAwMDEy Njg5MyAwMDAwMCBuIAowMDAwMTI2NzcwIDAwMDAwIG4gCjAwMDAxMjc0NDMgMDAwMDAgbiAKMDAw MDEyNzE5NyAwMDAwMCBuIAowMDAwMTI3MzIwIDAwMDAwIG4gCjAwMDAxMjk0MDIgMDAwMDAgbiAK MDAwMDEyODEwNSAwMDAwMCBuIAowMDAwMTI3ODU5IDAwMDAwIG4gCjAwMDAxMjc5ODIgMDAwMDAg biAKMDAwMDEyODU0MCAwMDAwMCBuIAowMDAwMTI4NDE3IDAwMDAwIG4gCjAwMDAxMjkwOTAgMDAw MDAgbiAKMDAwMDEyODg0NCAwMDAwMCBuIAowMDAwMTI4OTY3IDAwMDAwIG4gCjAwMDAxMzEwNDkg MDAwMDAgbiAKMDAwMDEyOTc1MiAwMDAwMCBuIAowMDAwMTI5NTA2IDAwMDAwIG4gCjAwMDAxMjk2 MjkgMDAwMDAgbiAKMDAwMDEzMDE4NyAwMDAwMCBuIAowMDAwMTMwMDY0IDAwMDAwIG4gCjAwMDAx MzA3MzcgMDAwMDAgbiAKMDAwMDEzMDQ5MSAwMDAwMCBuIAowMDAwMTMwNjE0IDAwMDAwIG4gCjAw MDAxMzI2OTYgMDAwMDAgbiAKMDAwMDEzMTM5OSAwMDAwMCBuIAowMDAwMTMxMTUzIDAwMDAwIG4g CjAwMDAxMzEyNzYgMDAwMDAgbiAKMDAwMDEzMTgzNCAwMDAwMCBuIAowMDAwMTMxNzExIDAwMDAw IG4gCjAwMDAxMzIzODQgMDAwMDAgbiAKMDAwMDEzMjEzOCAwMDAwMCBuIAowMDAwMTMyMjYxIDAw MDAwIG4gCjAwMDAxMzQzNDMgMDAwMDAgbiAKMDAwMDEzMzA0NiAwMDAwMCBuIAowMDAwMTMyODAw IDAwMDAwIG4gCjAwMDAxMzI5MjMgMDAwMDAgbiAKMDAwMDEzMzQ4MSAwMDAwMCBuIAowMDAwMTMz MzU4IDAwMDAwIG4gCjAwMDAxMzQwMzEgMDAwMDAgbiAKMDAwMDEzMzc4NSAwMDAwMCBuIAowMDAw MTMzOTA4IDAwMDAwIG4gCjAwMDAxMzU5OTAgMDAwMDAgbiAKMDAwMDEzNDY5MyAwMDAwMCBuIAow MDAwMTM0NDQ3IDAwMDAwIG4gCjAwMDAxMzQ1NzAgMDAwMDAgbiAKMDAwMDEzNTEyOCAwMDAwMCBu IAowMDAwMTM1MDA1IDAwMDAwIG4gCjAwMDAxMzU2NzggMDAwMDAgbiAKMDAwMDEzNTQzMiAwMDAw MCBuIAowMDAwMTM1NTU1IDAwMDAwIG4gCjAwMDAxMzc2MzcgMDAwMDAgbiAKMDAwMDEzNjM0MCAw MDAwMCBuIAowMDAwMTM2MDk0IDAwMDAwIG4gCjAwMDAxMzYyMTcgMDAwMDAgbiAKMDAwMDEzNjc3 NSAwMDAwMCBuIAowMDAwMTM2NjUyIDAwMDAwIG4gCjAwMDAxMzczMjUgMDAwMDAgbiAKMDAwMDEz NzA3OSAwMDAwMCBuIAowMDAwMTM3MjAyIDAwMDAwIG4gCjAwMDAxMzkyODQgMDAwMDAgbiAKMDAw MDEzNzk4NyAwMDAwMCBuIAowMDAwMTM3NzQxIDAwMDAwIG4gCjAwMDAxMzc4NjQgMDAwMDAgbiAK MDAwMDEzODQyMiAwMDAwMCBuIAowMDAwMTM4Mjk5IDAwMDAwIG4gCjAwMDAxMzg5NzIgMDAwMDAg biAKMDAwMDEzODcyNiAwMDAwMCBuIAowMDAwMTM4ODQ5IDAwMDAwIG4gCjAwMDAxNDA5MzEgMDAw MDAgbiAKMDAwMDEzOTYzNCAwMDAwMCBuIAowMDAwMTM5Mzg4IDAwMDAwIG4gCjAwMDAxMzk1MTEg MDAwMDAgbiAKMDAwMDE0MDA2OSAwMDAwMCBuIAowMDAwMTM5OTQ2IDAwMDAwIG4gCjAwMDAxNDA2 MTkgMDAwMDAgbiAKMDAwMDE0MDM3MyAwMDAwMCBuIAowMDAwMTQwNDk2IDAwMDAwIG4gCjAwMDAx NDI1NzggMDAwMDAgbiAKMDAwMDE0MTI4MSAwMDAwMCBuIAowMDAwMTQxMDM1IDAwMDAwIG4gCjAw MDAxNDExNTggMDAwMDAgbiAKMDAwMDE0MTcxNiAwMDAwMCBuIAowMDAwMTQxNTkzIDAwMDAwIG4g CjAwMDAxNDIyNjYgMDAwMDAgbiAKMDAwMDE0MjAyMCAwMDAwMCBuIAowMDAwMTQyMTQzIDAwMDAw IG4gCjAwMDAxNDQyMjUgMDAwMDAgbiAKMDAwMDE0MjkyOCAwMDAwMCBuIAowMDAwMTQyNjgyIDAw MDAwIG4gCjAwMDAxNDI4MDUgMDAwMDAgbiAKMDAwMDE0MzM2MyAwMDAwMCBuIAowMDAwMTQzMjQw IDAwMDAwIG4gCjAwMDAxNDM5MTMgMDAwMDAgbiAKMDAwMDE0MzY2NyAwMDAwMCBuIAowMDAwMTQz NzkwIDAwMDAwIG4gCjAwMDAxNDU4NzIgMDAwMDAgbiAKMDAwMDE0NDU3NSAwMDAwMCBuIAowMDAw MTQ0MzI5IDAwMDAwIG4gCjAwMDAxNDQ0NTIgMDAwMDAgbiAKMDAwMDE0NTAxMCAwMDAwMCBuIAow MDAwMTQ0ODg3IDAwMDAwIG4gCjAwMDAxNDU1NjAgMDAwMDAgbiAKMDAwMDE0NTMxNCAwMDAwMCBu IAowMDAwMTQ1NDM3IDAwMDAwIG4gCjAwMDAxNDc1MTkgMDAwMDAgbiAKMDAwMDE0NjIyMiAwMDAw MCBuIAowMDAwMTQ1OTc2IDAwMDAwIG4gCjAwMDAxNDYwOTkgMDAwMDAgbiAKMDAwMDE0NjY1NyAw MDAwMCBuIAowMDAwMTQ2NTM0IDAwMDAwIG4gCjAwMDAxNDcyMDcgMDAwMDAgbiAKMDAwMDE0Njk2 MSAwMDAwMCBuIAowMDAwMTQ3MDg0IDAwMDAwIG4gCjAwMDAxNDgwNTAgMDAwMDAgbiAKMDAwMDE0 Nzc0NiAwMDAwMCBuIAowMDAwMTQ3NjIzIDAwMDAwIG4gCjAwMDAxNDk0MTkgMDAwMDAgbiAKMDAw MDE0ODI2MSAwMDAwMCBuIAowMDAwMTQ4MTM4IDAwMDAwIG4gCjAwMDAxNDg2ODggMDAwMDAgbiAK MDAwMDE0ODU2NSAwMDAwMCBuIAowMDAwMTQ5MTE1IDAwMDAwIG4gCjAwMDAxNDg5OTIgMDAwMDAg biAKMDAwMDE0OTk1MCAwMDAwMCBuIAowMDAwMTQ5NjQ2IDAwMDAwIG4gCjAwMDAxNDk1MjMgMDAw MDAgbiAKMDAwMDE1MTMxOSAwMDAwMCBuIAowMDAwMTUwMTYxIDAwMDAwIG4gCjAwMDAxNTAwMzgg MDAwMDAgbiAKMDAwMDE1MDU4OCAwMDAwMCBuIAowMDAwMTUwNDY1IDAwMDAwIG4gCjAwMDAxNTEw MTUgMDAwMDAgbiAKMDAwMDE1MDg5MiAwMDAwMCBuIAowMDAwMTUyNzA0IDAwMDAwIG4gCjAwMDAx NTE1NDYgMDAwMDAgbiAKMDAwMDE1MTQyMyAwMDAwMCBuIAowMDAwMTUxOTczIDAwMDAwIG4gCjAw MDAxNTE4NTAgMDAwMDAgbiAKMDAwMDE1MjQwMCAwMDAwMCBuIAowMDAwMTUyMjc3IDAwMDAwIG4g CjAwMDAxNTQwODkgMDAwMDAgbiAKMDAwMDE1MjkzMSAwMDAwMCBuIAowMDAwMTUyODA4IDAwMDAw IG4gCjAwMDAxNTMzNTggMDAwMDAgbiAKMDAwMDE1MzIzNSAwMDAwMCBuIAowMDAwMTUzNzg1IDAw MDAwIG4gCjAwMDAxNTM2NjIgMDAwMDAgbiAKMDAwMDE1NTQ3NCAwMDAwMCBuIAowMDAwMTU0MzE2 IDAwMDAwIG4gCjAwMDAxNTQxOTMgMDAwMDAgbiAKMDAwMDE1NDc0MyAwMDAwMCBuIAowMDAwMTU0 NjIwIDAwMDAwIG4gCjAwMDAxNTUxNzAgMDAwMDAgbiAKMDAwMDE1NTA0NyAwMDAwMCBuIAowMDAw MTU2ODU5IDAwMDAwIG4gCjAwMDAxNTU3MDEgMDAwMDAgbiAKMDAwMDE1NTU3OCAwMDAwMCBuIAow MDAwMTU2MTI4IDAwMDAwIG4gCjAwMDAxNTYwMDUgMDAwMDAgbiAKMDAwMDE1NjU1NSAwMDAwMCBu IAowMDAwMTU2NDMyIDAwMDAwIG4gCjAwMDAxNTczOTAgMDAwMDAgbiAKMDAwMDE1NzA4NiAwMDAw MCBuIAowMDAwMTU2OTYzIDAwMDAwIG4gCjAwMDAxNTg3NTkgMDAwMDAgbiAKMDAwMDE1NzYwMSAw MDAwMCBuIAowMDAwMTU3NDc4IDAwMDAwIG4gCjAwMDAxNTgwMjggMDAwMDAgbiAKMDAwMDE1Nzkw NSAwMDAwMCBuIAowMDAwMTU4NDU1IDAwMDAwIG4gCjAwMDAxNTgzMzIgMDAwMDAgbiAKMDAwMDE1 OTI5MCAwMDAwMCBuIAowMDAwMTU4OTg2IDAwMDAwIG4gCjAwMDAxNTg4NjMgMDAwMDAgbiAKMDAw MDE2MDQ5MCAwMDAwMCBuIAowMDAwMTU5NzUzIDAwMDAwIG4gCjAwMDAxNTkzNzggMDAwMDAgbiAK MDAwMDE1OTYyNCAwMDAwMCBuIAowMDAwMTU5NTAxIDAwMDAwIG4gCjAwMDAxNjAzMDkgMDAwMDAg biAKMDAwMDE1OTkzNCAwMDAwMCBuIAowMDAwMTYwMTgwIDAwMDAwIG4gCjAwMDAxNjAwNTcgMDAw MDAgbiAKMDAwMDE2MTg2NyAwMDAwMCBuIAowMDAwMTYwNzA5IDAwMDAwIG4gCjAwMDAxNjA1ODYg MDAwMDAgbiAKMDAwMDE2MTEzNiAwMDAwMCBuIAowMDAwMTYxMDEzIDAwMDAwIG4gCjAwMDAxNjE1 NjMgMDAwMDAgbiAKMDAwMDE2MTQ0MCAwMDAwMCBuIAowMDAwMTYzMjUyIDAwMDAwIG4gCjAwMDAx NjIwOTQgMDAwMDAgbiAKMDAwMDE2MTk3MSAwMDAwMCBuIAowMDAwMTYyNTIxIDAwMDAwIG4gCjAw MDAxNjIzOTggMDAwMDAgbiAKMDAwMDE2Mjk0OCAwMDAwMCBuIAowMDAwMTYyODI1IDAwMDAwIG4g CjAwMDAxNjQ2MzcgMDAwMDAgbiAKMDAwMDE2MzQ3OSAwMDAwMCBuIAowMDAwMTYzMzU2IDAwMDAw IG4gCjAwMDAxNjM5MDYgMDAwMDAgbiAKMDAwMDE2Mzc4MyAwMDAwMCBuIAowMDAwMTY0MzMzIDAw MDAwIG4gCjAwMDAxNjQyMTAgMDAwMDAgbiAKMDAwMDE2NjAyMiAwMDAwMCBuIAowMDAwMTY0ODY0 IDAwMDAwIG4gCjAwMDAxNjQ3NDEgMDAwMDAgbiAKMDAwMDE2NTI5MSAwMDAwMCBuIAowMDAwMTY1 MTY4IDAwMDAwIG4gCjAwMDAxNjU3MTggMDAwMDAgbiAKMDAwMDE2NTU5NSAwMDAwMCBuIAowMDAw MTY3NDA3IDAwMDAwIG4gCjAwMDAxNjYyNDkgMDAwMDAgbiAKMDAwMDE2NjEyNiAwMDAwMCBuIAow MDAwMTY2Njc2IDAwMDAwIG4gCjAwMDAxNjY1NTMgMDAwMDAgbiAKMDAwMDE2NzEwMyAwMDAwMCBu IAowMDAwMTY2OTgwIDAwMDAwIG4gCjAwMDAxNjc5MzggMDAwMDAgbiAKMDAwMDE2NzYzNCAwMDAw MCBuIAowMDAwMTY3NTExIDAwMDAwIG4gCjAwMDAxNjkzMDcgMDAwMDAgbiAKMDAwMDE2ODE0OSAw MDAwMCBuIAowMDAwMTY4MDI2IDAwMDAwIG4gCjAwMDAxNjg1NzYgMDAwMDAgbiAKMDAwMDE2ODQ1 MyAwMDAwMCBuIAowMDAwMTY5MDAzIDAwMDAwIG4gCjAwMDAxNjg4ODAgMDAwMDAgbiAKMDAwMDE2 OTgzOCAwMDAwMCBuIAowMDAwMTY5NTM0IDAwMDAwIG4gCjAwMDAxNjk0MTEgMDAwMDAgbiAKMDAw MDE3MTIwNyAwMDAwMCBuIAowMDAwMTcwMDQ5IDAwMDAwIG4gCjAwMDAxNjk5MjYgMDAwMDAgbiAK MDAwMDE3MDQ3NiAwMDAwMCBuIAowMDAwMTcwMzUzIDAwMDAwIG4gCjAwMDAxNzA5MDMgMDAwMDAg biAKMDAwMDE3MDc4MCAwMDAwMCBuIAowMDAwMTcxNzM4IDAwMDAwIG4gCjAwMDAxNzE0MzQgMDAw MDAgbiAKMDAwMDE3MTMxMSAwMDAwMCBuIAowMDAwMTczNjI0IDAwMDAwIG4gCjAwMDAxNzIxOTIg MDAwMDAgbiAKMDAwMDE3MTgyNiAwMDAwMCBuIAowMDAwMTcxOTQ4IDAwMDAwIG4gCjAwMDAxNzIw NzAgMDAwMDAgbiAKMDAwMDE3MjYzNCAwMDAwMCBuIAowMDAwMTcyNTEyIDAwMDAwIG4gCjAwMDAx NzMzMDQgMDAwMDAgbiAKMDAwMDE3MjkzOCAwMDAwMCBuIAowMDAwMTczMDYwIDAwMDAwIG4gCjAw MDAxNzMxODIgMDAwMDAgbiAKMDAwMDE3NTI2OCAwMDAwMCBuIAowMDAwMTc0MDk0IDAwMDAwIG4g CjAwMDAxNzM3MjggMDAwMDAgbiAKMDAwMDE3Mzg1MCAwMDAwMCBuIAowMDAwMTczOTcyIDAwMDAw IG4gCjAwMDAxNzQ1MzcgMDAwMDAgbiAKMDAwMDE3NDQxNCAwMDAwMCBuIAowMDAwMTc0OTY0IDAw MDAwIG4gCjAwMDAxNzQ4NDEgMDAwMDAgbiAKMDAwMDE3NjY1MyAwMDAwMCBuIAowMDAwMTc1NDk1 IDAwMDAwIG4gCjAwMDAxNzUzNzIgMDAwMDAgbiAKMDAwMDE3NTkyMiAwMDAwMCBuIAowMDAwMTc1 Nzk5IDAwMDAwIG4gCjAwMDAxNzYzNDkgMDAwMDAgbiAKMDAwMDE3NjIyNiAwMDAwMCBuIAowMDAw MTc4MDM4IDAwMDAwIG4gCjAwMDAxNzY4ODAgMDAwMDAgbiAKMDAwMDE3Njc1NyAwMDAwMCBuIAow MDAwMTc3MzA3IDAwMDAwIG4gCjAwMDAxNzcxODQgMDAwMDAgbiAKMDAwMDE3NzczNCAwMDAwMCBu IAowMDAwMTc3NjExIDAwMDAwIG4gCjAwMDAxNzk0MjMgMDAwMDAgbiAKMDAwMDE3ODI2NSAwMDAw MCBuIAowMDAwMTc4MTQyIDAwMDAwIG4gCjAwMDAxNzg2OTIgMDAwMDAgbiAKMDAwMDE3ODU2OSAw MDAwMCBuIAowMDAwMTc5MTE5IDAwMDAwIG4gCjAwMDAxNzg5OTYgMDAwMDAgbiAKMDAwMDE4MDgw OCAwMDAwMCBuIAowMDAwMTc5NjUwIDAwMDAwIG4gCjAwMDAxNzk1MjcgMDAwMDAgbiAKMDAwMDE4 MDA3NyAwMDAwMCBuIAowMDAwMTc5OTU0IDAwMDAwIG4gCjAwMDAxODA1MDQgMDAwMDAgbiAKMDAw MDE4MDM4MSAwMDAwMCBuIAowMDAwMTgyMTkzIDAwMDAwIG4gCjAwMDAxODEwMzUgMDAwMDAgbiAK MDAwMDE4MDkxMiAwMDAwMCBuIAowMDAwMTgxNDYyIDAwMDAwIG4gCjAwMDAxODEzMzkgMDAwMDAg biAKMDAwMDE4MTg4OSAwMDAwMCBuIAowMDAwMTgxNzY2IDAwMDAwIG4gCjAwMDAxODI3MjQgMDAw MDAgbiAKMDAwMDE4MjQyMCAwMDAwMCBuIAowMDAwMTgyMjk3IDAwMDAwIG4gCjAwMDAxODQwOTMg MDAwMDAgbiAKMDAwMDE4MjkzNSAwMDAwMCBuIAowMDAwMTgyODEyIDAwMDAwIG4gCjAwMDAxODMz NjIgMDAwMDAgbiAKMDAwMDE4MzIzOSAwMDAwMCBuIAowMDAwMTgzNzg5IDAwMDAwIG4gCjAwMDAx ODM2NjYgMDAwMDAgbiAKMDAwMDE4NTc0MCAwMDAwMCBuIAowMDAwMTg0NDQzIDAwMDAwIG4gCjAw MDAxODQxOTcgMDAwMDAgbiAKMDAwMDE4NDMyMCAwMDAwMCBuIAowMDAwMTg0ODc4IDAwMDAwIG4g CjAwMDAxODQ3NTUgMDAwMDAgbiAKMDAwMDE4NTQyOCAwMDAwMCBuIAowMDAwMTg1MTgyIDAwMDAw IG4gCjAwMDAxODUzMDUgMDAwMDAgbiAKMDAwMDE4NzM4NyAwMDAwMCBuIAowMDAwMTg2MDkwIDAw MDAwIG4gCjAwMDAxODU4NDQgMDAwMDAgbiAKMDAwMDE4NTk2NyAwMDAwMCBuIAowMDAwMTg2NTI1 IDAwMDAwIG4gCjAwMDAxODY0MDIgMDAwMDAgbiAKMDAwMDE4NzA3NSAwMDAwMCBuIAowMDAwMTg2 ODI5IDAwMDAwIG4gCjAwMDAxODY5NTIgMDAwMDAgbiAKMDAwMDE4ODc3MiAwMDAwMCBuIAowMDAw MTg3NjE0IDAwMDAwIG4gCjAwMDAxODc0OTEgMDAwMDAgbiAKMDAwMDE4ODA0MSAwMDAwMCBuIAow MDAwMTg3OTE4IDAwMDAwIG4gCjAwMDAxODg0NjggMDAwMDAgbiAKMDAwMDE4ODM0NSAwMDAwMCBu IAowMDAwMTkwMTU3IDAwMDAwIG4gCjAwMDAxODg5OTkgMDAwMDAgbiAKMDAwMDE4ODg3NiAwMDAw MCBuIAowMDAwMTg5NDI2IDAwMDAwIG4gCjAwMDAxODkzMDMgMDAwMDAgbiAKMDAwMDE4OTg1MyAw MDAwMCBuIAowMDAwMTg5NzMwIDAwMDAwIG4gCjAwMDAxOTE1NDIgMDAwMDAgbiAKMDAwMDE5MDM4 NCAwMDAwMCBuIAowMDAwMTkwMjYxIDAwMDAwIG4gCjAwMDAxOTA4MTEgMDAwMDAgbiAKMDAwMDE5 MDY4OCAwMDAwMCBuIAowMDAwMTkxMjM4IDAwMDAwIG4gCjAwMDAxOTExMTUgMDAwMDAgbiAKMDAw MDE5MjkyNyAwMDAwMCBuIAowMDAwMTkxNzY5IDAwMDAwIG4gCjAwMDAxOTE2NDYgMDAwMDAgbiAK MDAwMDE5MjE5NiAwMDAwMCBuIAowMDAwMTkyMDczIDAwMDAwIG4gCjAwMDAxOTI2MjMgMDAwMDAg biAKMDAwMDE5MjUwMCAwMDAwMCBuIAowMDAwMTk0MzEyIDAwMDAwIG4gCjAwMDAxOTMxNTQgMDAw MDAgbiAKMDAwMDE5MzAzMSAwMDAwMCBuIAowMDAwMTkzNTgxIDAwMDAwIG4gCjAwMDAxOTM0NTgg MDAwMDAgbiAKMDAwMDE5NDAwOCAwMDAwMCBuIAowMDAwMTkzODg1IDAwMDAwIG4gCjAwMDAxOTU2 OTcgMDAwMDAgbiAKMDAwMDE5NDUzOSAwMDAwMCBuIAowMDAwMTk0NDE2IDAwMDAwIG4gCjAwMDAx OTQ5NjYgMDAwMDAgbiAKMDAwMDE5NDg0MyAwMDAwMCBuIAowMDAwMTk1MzkzIDAwMDAwIG4gCjAw MDAxOTUyNzAgMDAwMDAgbiAKMDAwMDE5NzA4MiAwMDAwMCBuIAowMDAwMTk1OTI0IDAwMDAwIG4g CjAwMDAxOTU4MDEgMDAwMDAgbiAKMDAwMDE5NjM1MSAwMDAwMCBuIAowMDAwMTk2MjI4IDAwMDAw IG4gCjAwMDAxOTY3NzggMDAwMDAgbiAKMDAwMDE5NjY1NSAwMDAwMCBuIAowMDAwMTk3NjEzIDAw MDAwIG4gCjAwMDAxOTczMDkgMDAwMDAgbiAKMDAwMDE5NzE4NiAwMDAwMCBuIAowMDAwMTk4OTgy IDAwMDAwIG4gCjAwMDAxOTc4MjQgMDAwMDAgbiAKMDAwMDE5NzcwMSAwMDAwMCBuIAowMDAwMTk4 MjUxIDAwMDAwIG4gCjAwMDAxOTgxMjggMDAwMDAgbiAKMDAwMDE5ODY3OCAwMDAwMCBuIAowMDAw MTk4NTU1IDAwMDAwIG4gCjAwMDAyMDAzNjcgMDAwMDAgbiAKMDAwMDE5OTIwOSAwMDAwMCBuIAow MDAwMTk5MDg2IDAwMDAwIG4gCjAwMDAxOTk2MzYgMDAwMDAgbiAKMDAwMDE5OTUxMyAwMDAwMCBu IAowMDAwMjAwMDYzIDAwMDAwIG4gCjAwMDAxOTk5NDAgMDAwMDAgbiAKMDAwMDIwMTc1MiAwMDAw MCBuIAowMDAwMjAwNTk0IDAwMDAwIG4gCjAwMDAyMDA0NzEgMDAwMDAgbiAKMDAwMDIwMTAyMSAw MDAwMCBuIAowMDAwMjAwODk4IDAwMDAwIG4gCjAwMDAyMDE0NDggMDAwMDAgbiAKMDAwMDIwMTMy NSAwMDAwMCBuIAowMDAwMjAzMTM3IDAwMDAwIG4gCjAwMDAyMDE5NzkgMDAwMDAgbiAKMDAwMDIw MTg1NiAwMDAwMCBuIAowMDAwMjAyNDA2IDAwMDAwIG4gCjAwMDAyMDIyODMgMDAwMDAgbiAKMDAw MDIwMjgzMyAwMDAwMCBuIAowMDAwMjAyNzEwIDAwMDAwIG4gCjAwMDAyMDQ1MjIgMDAwMDAgbiAK MDAwMDIwMzM2NCAwMDAwMCBuIAowMDAwMjAzMjQxIDAwMDAwIG4gCjAwMDAyMDM3OTEgMDAwMDAg biAKMDAwMDIwMzY2OCAwMDAwMCBuIAowMDAwMjA0MjE4IDAwMDAwIG4gCjAwMDAyMDQwOTUgMDAw MDAgbiAKMDAwMDIwNTkwNyAwMDAwMCBuIAowMDAwMjA0NzQ5IDAwMDAwIG4gCjAwMDAyMDQ2MjYg MDAwMDAgbiAKMDAwMDIwNTE3NiAwMDAwMCBuIAowMDAwMjA1MDUzIDAwMDAwIG4gCjAwMDAyMDU2 MDMgMDAwMDAgbiAKMDAwMDIwNTQ4MCAwMDAwMCBuIAowMDAwMjA2NDM4IDAwMDAwIG4gCjAwMDAy MDYxMzQgMDAwMDAgbiAKMDAwMDIwNjAxMSAwMDAwMCBuIAowMDAwMjA3ODA3IDAwMDAwIG4gCjAw MDAyMDY2NDkgMDAwMDAgbiAKMDAwMDIwNjUyNiAwMDAwMCBuIAowMDAwMjA3MDc2IDAwMDAwIG4g CjAwMDAyMDY5NTMgMDAwMDAgbiAKMDAwMDIwNzUwMyAwMDAwMCBuIAowMDAwMjA3MzgwIDAwMDAw IG4gCjAwMDAyMDkxOTIgMDAwMDAgbiAKMDAwMDIwODAzNCAwMDAwMCBuIAowMDAwMjA3OTExIDAw MDAwIG4gCjAwMDAyMDg0NjEgMDAwMDAgbiAKMDAwMDIwODMzOCAwMDAwMCBuIAowMDAwMjA4ODg4 IDAwMDAwIG4gCjAwMDAyMDg3NjUgMDAwMDAgbiAKMDAwMDIwOTcyMyAwMDAwMCBuIAowMDAwMjA5 NDE5IDAwMDAwIG4gCjAwMDAyMDkyOTYgMDAwMDAgbiAKMDAwMDIxMDkyNSAwMDAwMCBuIAowMDAw MjEwMTg3IDAwMDAwIG4gCjAwMDAyMDk4MTEgMDAwMDAgbiAKMDAwMDIxMDA1NyAwMDAwMCBuIAow MDAwMjA5OTM0IDAwMDAwIG4gCjAwMDAyMTA3NDQgMDAwMDAgbiAKMDAwMDIxMDM2OCAwMDAwMCBu IAowMDAwMjEwNjE0IDAwMDAwIG4gCjAwMDAyMTA0OTEgMDAwMDAgbiAKMDAwMDIxMTQ0OCAwMDAw MCBuIAowMDAwMjExMTQ0IDAwMDAwIG4gCjAwMDAyMTEwMjEgMDAwMDAgbiAKMDAwMDIxMjgxNyAw MDAwMCBuIAowMDAwMjExNjU5IDAwMDAwIG4gCjAwMDAyMTE1MzYgMDAwMDAgbiAKMDAwMDIxMjA4 NiAwMDAwMCBuIAowMDAwMjExOTYzIDAwMDAwIG4gCjAwMDAyMTI1MTMgMDAwMDAgbiAKMDAwMDIx MjM5MCAwMDAwMCBuIAowMDAwMjEzMzUyIDAwMDAwIG4gCjAwMDAyMTMwNDYgMDAwMDAgbiAKMDAw MDIxMjkyMSAwMDAwMCBuIAowMDAwMjE0NzM4IDAwMDAwIG4gCjAwMDAyMTM1NjYgMDAwMDAgbiAK MDAwMDIxMzQ0MSAwMDAwMCBuIAowMDAwMjEzOTk4IDAwMDAwIG4gCjAwMDAyMTM4NzMgMDAwMDAg biAKMDAwMDIxNDQzMSAwMDAwMCBuIAowMDAwMjE0MzA1IDAwMDAwIG4gCjAwMDAyMTYxNDUgMDAw MDAgbiAKMDAwMDIxNDk3MiAwMDAwMCBuIAowMDAwMjE0ODQ2IDAwMDAwIG4gCjAwMDAyMTU0MDUg MDAwMDAgbiAKMDAwMDIxNTI3OSAwMDAwMCBuIAowMDAwMjE1ODM4IDAwMDAwIG4gCjAwMDAyMTU3 MTIgMDAwMDAgbiAKMDAwMDIxNzU1MiAwMDAwMCBuIAowMDAwMjE2Mzc5IDAwMDAwIG4gCjAwMDAy MTYyNTMgMDAwMDAgbiAKMDAwMDIxNjgxMiAwMDAwMCBuIAowMDAwMjE2Njg2IDAwMDAwIG4gCjAw MDAyMTcyNDUgMDAwMDAgbiAKMDAwMDIxNzExOSAwMDAwMCBuIAowMDAwMjE4OTU5IDAwMDAwIG4g CjAwMDAyMTc3ODYgMDAwMDAgbiAKMDAwMDIxNzY2MCAwMDAwMCBuIAowMDAwMjE4MjE5IDAwMDAw IG4gCjAwMDAyMTgwOTMgMDAwMDAgbiAKMDAwMDIxODY1MiAwMDAwMCBuIAowMDAwMjE4NTI2IDAw MDAwIG4gCjAwMDAyMTk1MDAgMDAwMDAgbiAKMDAwMDIxOTE5MyAwMDAwMCBuIAowMDAwMjE5MDY3 IDAwMDAwIG4gCjAwMDAyMjA4ODkgMDAwMDAgbiAKMDAwMDIxOTcxNiAwMDAwMCBuIAowMDAwMjE5 NTkwIDAwMDAwIG4gCjAwMDAyMjAxNDkgMDAwMDAgbiAKMDAwMDIyMDAyMyAwMDAwMCBuIAowMDAw MjIwNTgyIDAwMDAwIG4gCjAwMDAyMjA0NTYgMDAwMDAgbiAKMDAwMDIyMjI5NiAwMDAwMCBuIAow MDAwMjIxMTIzIDAwMDAwIG4gCjAwMDAyMjA5OTcgMDAwMDAgbiAKMDAwMDIyMTU1NiAwMDAwMCBu IAowMDAwMjIxNDMwIDAwMDAwIG4gCjAwMDAyMjE5ODkgMDAwMDAgbiAKMDAwMDIyMTg2MyAwMDAw MCBuIAowMDAwMjI0MjQzIDAwMDAwIG4gCjAwMDAyMjI3ODIgMDAwMDAgbiAKMDAwMDIyMjQwNCAw MDAwMCBuIAowMDAwMjIyNTMwIDAwMDAwIG4gCjAwMDAyMjI2NTYgMDAwMDAgbiAKMDAwMDIyMzIz MyAwMDAwMCBuIAowMDAwMjIzMTA3IDAwMDAwIG4gCjAwMDAyMjM5MTggMDAwMDAgbiAKMDAwMDIy MzU0MCAwMDAwMCBuIAowMDAwMjIzNjY2IDAwMDAwIG4gCjAwMDAyMjM3OTIgMDAwMDAgbiAKMDAw MDIyNTY1MCAwMDAwMCBuIAowMDAwMjI0NDc3IDAwMDAwIG4gCjAwMDAyMjQzNTEgMDAwMDAgbiAK MDAwMDIyNDkxMCAwMDAwMCBuIAowMDAwMjI0Nzg0IDAwMDAwIG4gCjAwMDAyMjUzNDMgMDAwMDAg biAKMDAwMDIyNTIxNyAwMDAwMCBuIAowMDAwMjI3MDU3IDAwMDAwIG4gCjAwMDAyMjU4ODQgMDAw MDAgbiAKMDAwMDIyNTc1OCAwMDAwMCBuIAowMDAwMjI2MzE3IDAwMDAwIG4gCjAwMDAyMjYxOTEg MDAwMDAgbiAKMDAwMDIyNjc1MCAwMDAwMCBuIAowMDAwMjI2NjI0IDAwMDAwIG4gCjAwMDAyMjg0 NjQgMDAwMDAgbiAKMDAwMDIyNzI5MSAwMDAwMCBuIAowMDAwMjI3MTY1IDAwMDAwIG4gCjAwMDAy Mjc3MjQgMDAwMDAgbiAKMDAwMDIyNzU5OCAwMDAwMCBuIAowMDAwMjI4MTU3IDAwMDAwIG4gCjAw MDAyMjgwMzEgMDAwMDAgbiAKMDAwMDIyOTQzOCAwMDAwMCBuIAowMDAwMjI4Njk4IDAwMDAwIG4g CjAwMDAyMjg1NzIgMDAwMDAgbiAKMDAwMDIyOTEzMSAwMDAwMCBuIAowMDAwMjI5MDA1IDAwMDAw IG4gCjAwMDAyMjk5NzAgMDAwMDAgbiAKMDAwMDIyOTY2MyAwMDAwMCBuIAowMDAwMjI5NTM3IDAw MDAwIG4gCjAwMDAyMzEzNTkgMDAwMDAgbiAKMDAwMDIzMDE4NiAwMDAwMCBuIAowMDAwMjMwMDYw IDAwMDAwIG4gCjAwMDAyMzA2MTkgMDAwMDAgbiAKMDAwMDIzMDQ5MyAwMDAwMCBuIAowMDAwMjMx MDUyIDAwMDAwIG4gCjAwMDAyMzA5MjYgMDAwMDAgbiAKMDAwMDIzMjc2NiAwMDAwMCBuIAowMDAw MjMxNTkzIDAwMDAwIG4gCjAwMDAyMzE0NjcgMDAwMDAgbiAKMDAwMDIzMjAyNiAwMDAwMCBuIAow MDAwMjMxOTAwIDAwMDAwIG4gCjAwMDAyMzI0NTkgMDAwMDAgbiAKMDAwMDIzMjMzMyAwMDAwMCBu IAowMDAwMjM0MTczIDAwMDAwIG4gCjAwMDAyMzMwMDAgMDAwMDAgbiAKMDAwMDIzMjg3NCAwMDAw MCBuIAowMDAwMjMzNDMzIDAwMDAwIG4gCjAwMDAyMzMzMDcgMDAwMDAgbiAKMDAwMDIzMzg2NiAw MDAwMCBuIAowMDAwMjMzNzQwIDAwMDAwIG4gCjAwMDAyMzU1ODAgMDAwMDAgbiAKMDAwMDIzNDQw NyAwMDAwMCBuIAowMDAwMjM0MjgxIDAwMDAwIG4gCjAwMDAyMzQ4NDAgMDAwMDAgbiAKMDAwMDIz NDcxNCAwMDAwMCBuIAowMDAwMjM1MjczIDAwMDAwIG4gCjAwMDAyMzUxNDcgMDAwMDAgbiAKMDAw MDIzNjk4NyAwMDAwMCBuIAowMDAwMjM1ODE0IDAwMDAwIG4gCjAwMDAyMzU2ODggMDAwMDAgbiAK MDAwMDIzNjI0NyAwMDAwMCBuIAowMDAwMjM2MTIxIDAwMDAwIG4gCjAwMDAyMzY2ODAgMDAwMDAg biAKMDAwMDIzNjU1NCAwMDAwMCBuIAowMDAwMjM4Mzk0IDAwMDAwIG4gCjAwMDAyMzcyMjEgMDAw MDAgbiAKMDAwMDIzNzA5NSAwMDAwMCBuIAowMDAwMjM3NjU0IDAwMDAwIG4gCjAwMDAyMzc1Mjgg MDAwMDAgbiAKMDAwMDIzODA4NyAwMDAwMCBuIAowMDAwMjM3OTYxIDAwMDAwIG4gCjAwMDAyMzg5 MzUgMDAwMDAgbiAKMDAwMDIzODYyOCAwMDAwMCBuIAowMDAwMjM4NTAyIDAwMDAwIG4gCjAwMDAy NDAzMjQgMDAwMDAgbiAKMDAwMDIzOTE1MSAwMDAwMCBuIAowMDAwMjM5MDI1IDAwMDAwIG4gCjAw MDAyMzk1ODQgMDAwMDAgbiAKMDAwMDIzOTQ1OCAwMDAwMCBuIAowMDAwMjQwMDE3IDAwMDAwIG4g CjAwMDAyMzk4OTEgMDAwMDAgbiAKMDAwMDI0MTczMSAwMDAwMCBuIAowMDAwMjQwNTU4IDAwMDAw IG4gCjAwMDAyNDA0MzIgMDAwMDAgbiAKMDAwMDI0MDk5MSAwMDAwMCBuIAowMDAwMjQwODY1IDAw MDAwIG4gCjAwMDAyNDE0MjQgMDAwMDAgbiAKMDAwMDI0MTI5OCAwMDAwMCBuIAowMDAwMjQyMjcy IDAwMDAwIG4gCjAwMDAyNDE5NjUgMDAwMDAgbiAKMDAwMDI0MTgzOSAwMDAwMCBuIAowMDAwMjQz NTAyIDAwMDAwIG4gCjAwMDAyNDI3NDcgMDAwMDAgbiAKMDAwMDI0MjM2MiAwMDAwMCBuIAowMDAw MjQyNjE0IDAwMDAwIG4gCjAwMDAyNDI0ODggMDAwMDAgbiAKMDAwMDI0MzMxNyAwMDAwMCBuIAow MDAwMjQyOTMyIDAwMDAwIG4gCjAwMDAyNDMxODQgMDAwMDAgbiAKMDAwMDI0MzA1OCAwMDAwMCBu IAowMDAwMjQ0MDM0IDAwMDAwIG4gCjAwMDAyNDM3MjcgMDAwMDAgbiAKMDAwMDI0MzYwMSAwMDAw MCBuIAowMDAwMjQ1NDIzIDAwMDAwIG4gCjAwMDAyNDQyNTAgMDAwMDAgbiAKMDAwMDI0NDEyNCAw MDAwMCBuIAowMDAwMjQ0NjgzIDAwMDAwIG4gCjAwMDAyNDQ1NTcgMDAwMDAgbiAKMDAwMDI0NTEx NiAwMDAwMCBuIAowMDAwMjQ0OTkwIDAwMDAwIG4gCjAwMDAyNDY4MzAgMDAwMDAgbiAKMDAwMDI0 NTY1NyAwMDAwMCBuIAowMDAwMjQ1NTMxIDAwMDAwIG4gCjAwMDAyNDYwOTAgMDAwMDAgbiAKMDAw MDI0NTk2NCAwMDAwMCBuIAowMDAwMjQ2NTIzIDAwMDAwIG4gCjAwMDAyNDYzOTcgMDAwMDAgbiAK MDAwMDI0NzM3MSAwMDAwMCBuIAowMDAwMjQ3MDY0IDAwMDAwIG4gCjAwMDAyNDY5MzggMDAwMDAg biAKMDAwMDI0ODc2MCAwMDAwMCBuIAowMDAwMjQ3NTg3IDAwMDAwIG4gCjAwMDAyNDc0NjEgMDAw MDAgbiAKMDAwMDI0ODAyMCAwMDAwMCBuIAowMDAwMjQ3ODk0IDAwMDAwIG4gCjAwMDAyNDg0NTMg MDAwMDAgbiAKMDAwMDI0ODMyNyAwMDAwMCBuIAowMDAwMjQ5MzAxIDAwMDAwIG4gCjAwMDAyNDg5 OTQgMDAwMDAgbiAKMDAwMDI0ODg2OCAwMDAwMCBuIAowMDAwMjUwNjkwIDAwMDAwIG4gCjAwMDAy NDk1MTcgMDAwMDAgbiAKMDAwMDI0OTM5MSAwMDAwMCBuIAowMDAwMjQ5OTUwIDAwMDAwIG4gCjAw MDAyNDk4MjQgMDAwMDAgbiAKMDAwMDI1MDM4MyAwMDAwMCBuIAowMDAwMjUwMjU3IDAwMDAwIG4g CjAwMDAyNTEyMzEgMDAwMDAgbiAKMDAwMDI1MDkyNCAwMDAwMCBuIAowMDAwMjUwNzk4IDAwMDAw IG4gCjAwMDAyNTI2MjAgMDAwMDAgbiAKMDAwMDI1MTQ0NyAwMDAwMCBuIAowMDAwMjUxMzIxIDAw MDAwIG4gCjAwMDAyNTE4ODAgMDAwMDAgbiAKMDAwMDI1MTc1NCAwMDAwMCBuIAowMDAwMjUyMzEz IDAwMDAwIG4gCjAwMDAyNTIxODcgMDAwMDAgbiAKMDAwMDI1NDAyNyAwMDAwMCBuIAowMDAwMjUy ODU0IDAwMDAwIG4gCjAwMDAyNTI3MjggMDAwMDAgbiAKMDAwMDI1MzI4NyAwMDAwMCBuIAowMDAw MjUzMTYxIDAwMDAwIG4gCjAwMDAyNTM3MjAgMDAwMDAgbiAKMDAwMDI1MzU5NCAwMDAwMCBuIAow MDAwMjU1NzA0IDAwMDAwIG4gCjAwMDAyNTQ1MTMgMDAwMDAgbiAKMDAwMDI1NDEzNSAwMDAwMCBu IAowMDAwMjU0MjYxIDAwMDAwIG4gCjAwMDAyNTQzODcgMDAwMDAgbiAKMDAwMDI1NDk2NCAwMDAw MCBuIAowMDAwMjU0ODM4IDAwMDAwIG4gCjAwMDAyNTUzOTcgMDAwMDAgbiAKMDAwMDI1NTI3MSAw MDAwMCBuIAowMDAwMjU2MjQ1IDAwMDAwIG4gCjAwMDAyNTU5MzggMDAwMDAgbiAKMDAwMDI1NTgx MiAwMDAwMCBuIAowMDAwMjU3NjM0IDAwMDAwIG4gCjAwMDAyNTY0NjEgMDAwMDAgbiAKMDAwMDI1 NjMzNSAwMDAwMCBuIAowMDAwMjU2ODk0IDAwMDAwIG4gCjAwMDAyNTY3NjggMDAwMDAgbiAKMDAw MDI1NzMyNyAwMDAwMCBuIAowMDAwMjU3MjAxIDAwMDAwIG4gCjAwMDAyNTkwNDEgMDAwMDAgbiAK MDAwMDI1Nzg2OCAwMDAwMCBuIAowMDAwMjU3NzQyIDAwMDAwIG4gCjAwMDAyNTgzMDEgMDAwMDAg biAKMDAwMDI1ODE3NSAwMDAwMCBuIAowMDAwMjU4NzM0IDAwMDAwIG4gCjAwMDAyNTg2MDggMDAw MDAgbiAKMDAwMDI2MDQ0OCAwMDAwMCBuIAowMDAwMjU5Mjc1IDAwMDAwIG4gCjAwMDAyNTkxNDkg MDAwMDAgbiAKMDAwMDI1OTcwOCAwMDAwMCBuIAowMDAwMjU5NTgyIDAwMDAwIG4gCjAwMDAyNjAx NDEgMDAwMDAgbiAKMDAwMDI2MDAxNSAwMDAwMCBuIAowMDAwMjYwOTg5IDAwMDAwIG4gCjAwMDAy NjA2ODIgMDAwMDAgbiAKMDAwMDI2MDU1NiAwMDAwMCBuIAowMDAwMjYyMzc4IDAwMDAwIG4gCjAw MDAyNjEyMDUgMDAwMDAgbiAKMDAwMDI2MTA3OSAwMDAwMCBuIAowMDAwMjYxNjM4IDAwMDAwIG4g CjAwMDAyNjE1MTIgMDAwMDAgbiAKMDAwMDI2MjA3MSAwMDAwMCBuIAowMDAwMjYxOTQ1IDAwMDAw IG4gCjAwMDAyNjM3ODUgMDAwMDAgbiAKMDAwMDI2MjYxMiAwMDAwMCBuIAowMDAwMjYyNDg2IDAw MDAwIG4gCjAwMDAyNjMwNDUgMDAwMDAgbiAKMDAwMDI2MjkxOSAwMDAwMCBuIAowMDAwMjYzNDc4 IDAwMDAwIG4gCjAwMDAyNjMzNTIgMDAwMDAgbiAKMDAwMDI2NTE5MiAwMDAwMCBuIAowMDAwMjY0 MDE5IDAwMDAwIG4gCjAwMDAyNjM4OTMgMDAwMDAgbiAKMDAwMDI2NDQ1MiAwMDAwMCBuIAowMDAw MjY0MzI2IDAwMDAwIG4gCjAwMDAyNjQ4ODUgMDAwMDAgbiAKMDAwMDI2NDc1OSAwMDAwMCBuIAow MDAwMjY2NTk5IDAwMDAwIG4gCjAwMDAyNjU0MjYgMDAwMDAgbiAKMDAwMDI2NTMwMCAwMDAwMCBu IAowMDAwMjY1ODU5IDAwMDAwIG4gCjAwMDAyNjU3MzMgMDAwMDAgbiAKMDAwMDI2NjI5MiAwMDAw MCBuIAowMDAwMjY2MTY2IDAwMDAwIG4gCjAwMDAyNjgwMDYgMDAwMDAgbiAKMDAwMDI2NjgzMyAw MDAwMCBuIAowMDAwMjY2NzA3IDAwMDAwIG4gCjAwMDAyNjcyNjYgMDAwMDAgbiAKMDAwMDI2NzE0 MCAwMDAwMCBuIAowMDAwMjY3Njk5IDAwMDAwIG4gCjAwMDAyNjc1NzMgMDAwMDAgbiAKMDAwMDI2 ODU0NyAwMDAwMCBuIAowMDAwMjY4MjQwIDAwMDAwIG4gCjAwMDAyNjgxMTQgMDAwMDAgbiAKMDAw MDI2OTc3NyAwMDAwMCBuIAowMDAwMjY5MDIyIDAwMDAwIG4gCjAwMDAyNjg2MzcgMDAwMDAgbiAK MDAwMDI2ODg4OSAwMDAwMCBuIAowMDAwMjY4NzYzIDAwMDAwIG4gCjAwMDAyNjk1OTIgMDAwMDAg biAKMDAwMDI2OTIwNyAwMDAwMCBuIAowMDAwMjY5NDU5IDAwMDAwIG4gCjAwMDAyNjkzMzMgMDAw MDAgbiAKMDAwMDI3MTE3NSAwMDAwMCBuIAowMDAwMjcwMDAyIDAwMDAwIG4gCjAwMDAyNjk4NzYg MDAwMDAgbiAKMDAwMDI3MDQzNSAwMDAwMCBuIAowMDAwMjcwMzA5IDAwMDAwIG4gCjAwMDAyNzA4 NjggMDAwMDAgbiAKMDAwMDI3MDc0MiAwMDAwMCBuIAowMDAwMjcyNTgyIDAwMDAwIG4gCjAwMDAy NzE0MDkgMDAwMDAgbiAKMDAwMDI3MTI4MyAwMDAwMCBuIAowMDAwMjcxODQyIDAwMDAwIG4gCjAw MDAyNzE3MTYgMDAwMDAgbiAKMDAwMDI3MjI3NSAwMDAwMCBuIAowMDAwMjcyMTQ5IDAwMDAwIG4g CjAwMDAyNzMxMjMgMDAwMDAgbiAKMDAwMDI3MjgxNiAwMDAwMCBuIAowMDAwMjcyNjkwIDAwMDAw IG4gCjAwMDAyNzQ1MTIgMDAwMDAgbiAKMDAwMDI3MzMzOSAwMDAwMCBuIAowMDAwMjczMjEzIDAw MDAwIG4gCjAwMDAyNzM3NzIgMDAwMDAgbiAKMDAwMDI3MzY0NiAwMDAwMCBuIAowMDAwMjc0MjA1 IDAwMDAwIG4gCjAwMDAyNzQwNzkgMDAwMDAgbiAKMDAwMDI3NTA1MyAwMDAwMCBuIAowMDAwMjc0 NzQ2IDAwMDAwIG4gCjAwMDAyNzQ2MjAgMDAwMDAgbiAKMDAwMDI3NjQ0MiAwMDAwMCBuIAowMDAw Mjc1MjY5IDAwMDAwIG4gCjAwMDAyNzUxNDMgMDAwMDAgbiAKMDAwMDI3NTcwMiAwMDAwMCBuIAow MDAwMjc1NTc2IDAwMDAwIG4gCjAwMDAyNzYxMzUgMDAwMDAgbiAKMDAwMDI3NjAwOSAwMDAwMCBu IAowMDAwMjc3ODQ5IDAwMDAwIG4gCjAwMDAyNzY2NzYgMDAwMDAgbiAKMDAwMDI3NjU1MCAwMDAw MCBuIAowMDAwMjc3MTA5IDAwMDAwIG4gCjAwMDAyNzY5ODMgMDAwMDAgbiAKMDAwMDI3NzU0MiAw MDAwMCBuIAowMDAwMjc3NDE2IDAwMDAwIG4gCjAwMDAyNzkyNTYgMDAwMDAgbiAKMDAwMDI3ODA4 MyAwMDAwMCBuIAowMDAwMjc3OTU3IDAwMDAwIG4gCjAwMDAyNzg1MTYgMDAwMDAgbiAKMDAwMDI3 ODM5MCAwMDAwMCBuIAowMDAwMjc4OTQ5IDAwMDAwIG4gCjAwMDAyNzg4MjMgMDAwMDAgbiAKMDAw MDI4MDY2MyAwMDAwMCBuIAowMDAwMjc5NDkwIDAwMDAwIG4gCjAwMDAyNzkzNjQgMDAwMDAgbiAK MDAwMDI3OTkyMyAwMDAwMCBuIAowMDAwMjc5Nzk3IDAwMDAwIG4gCjAwMDAyODAzNTYgMDAwMDAg biAKMDAwMDI4MDIzMCAwMDAwMCBuIAowMDAwMjgyMDcwIDAwMDAwIG4gCjAwMDAyODA4OTcgMDAw MDAgbiAKMDAwMDI4MDc3MSAwMDAwMCBuIAowMDAwMjgxMzMwIDAwMDAwIG4gCjAwMDAyODEyMDQg MDAwMDAgbiAKMDAwMDI4MTc2MyAwMDAwMCBuIAowMDAwMjgxNjM3IDAwMDAwIG4gCjAwMDAyODQy ODcgMDAwMDAgbiAKMDAwMDI4MjgwOCAwMDAwMCBuIAowMDAwMjgyMTc4IDAwMDAwIG4gCjAwMDAy ODIzMDQgMDAwMDAgbiAKMDAwMDI4MjQzMCAwMDAwMCBuIAowMDAwMjgyNTU2IDAwMDAwIG4gCjAw MDAyODI2ODIgMDAwMDAgbiAKMDAwMDI4MzI3NyAwMDAwMCBuIAowMDAwMjgzMTUxIDAwMDAwIG4g CjAwMDAyODM5NjIgMDAwMDAgbiAKMDAwMDI4MzU4NCAwMDAwMCBuIAowMDAwMjgzNzEwIDAwMDAw IG4gCjAwMDAyODM4MzYgMDAwMDAgbiAKMDAwMDI4NTY5NCAwMDAwMCBuIAowMDAwMjg0NTIxIDAw MDAwIG4gCjAwMDAyODQzOTUgMDAwMDAgbiAKMDAwMDI4NDk1NCAwMDAwMCBuIAowMDAwMjg0ODI4 IDAwMDAwIG4gCjAwMDAyODUzODcgMDAwMDAgbiAKMDAwMDI4NTI2MSAwMDAwMCBuIAowMDAwMjg3 MTAxIDAwMDAwIG4gCjAwMDAyODU5MjggMDAwMDAgbiAKMDAwMDI4NTgwMiAwMDAwMCBuIAowMDAw Mjg2MzYxIDAwMDAwIG4gCjAwMDAyODYyMzUgMDAwMDAgbiAKMDAwMDI4Njc5NCAwMDAwMCBuIAow MDAwMjg2NjY4IDAwMDAwIG4gCjAwMDAyODg1MDggMDAwMDAgbiAKMDAwMDI4NzMzNSAwMDAwMCBu IAowMDAwMjg3MjA5IDAwMDAwIG4gCjAwMDAyODc3NjggMDAwMDAgbiAKMDAwMDI4NzY0MiAwMDAw MCBuIAowMDAwMjg4MjAxIDAwMDAwIG4gCjAwMDAyODgwNzUgMDAwMDAgbiAKMDAwMDI4OTA0OSAw MDAwMCBuIAowMDAwMjg4NzQyIDAwMDAwIG4gCjAwMDAyODg2MTYgMDAwMDAgbiAKMDAwMDI5MDQz OCAwMDAwMCBuIAowMDAwMjg5MjY1IDAwMDAwIG4gCjAwMDAyODkxMzkgMDAwMDAgbiAKMDAwMDI4 OTY5OCAwMDAwMCBuIAowMDAwMjg5NTcyIDAwMDAwIG4gCjAwMDAyOTAxMzEgMDAwMDAgbiAKMDAw MDI5MDAwNSAwMDAwMCBuIAowMDAwMjkxODQ1IDAwMDAwIG4gCjAwMDAyOTA2NzIgMDAwMDAgbiAK MDAwMDI5MDU0NiAwMDAwMCBuIAowMDAwMjkxMTA1IDAwMDAwIG4gCjAwMDAyOTA5NzkgMDAwMDAg biAKMDAwMDI5MTUzOCAwMDAwMCBuIAowMDAwMjkxNDEyIDAwMDAwIG4gCjAwMDAyOTIzODYgMDAw MDAgbiAKMDAwMDI5MjA3OSAwMDAwMCBuIAowMDAwMjkxOTUzIDAwMDAwIG4gCjAwMDAyOTM3NzUg MDAwMDAgbiAKMDAwMDI5MjYwMiAwMDAwMCBuIAowMDAwMjkyNDc2IDAwMDAwIG4gCjAwMDAyOTMw MzUgMDAwMDAgbiAKMDAwMDI5MjkwOSAwMDAwMCBuIAowMDAwMjkzNDY4IDAwMDAwIG4gCjAwMDAy OTMzNDIgMDAwMDAgbiAKMDAwMDI5NTE4MiAwMDAwMCBuIAowMDAwMjk0MDA5IDAwMDAwIG4gCjAw MDAyOTM4ODMgMDAwMDAgbiAKMDAwMDI5NDQ0MiAwMDAwMCBuIAowMDAwMjk0MzE2IDAwMDAwIG4g CjAwMDAyOTQ4NzUgMDAwMDAgbiAKMDAwMDI5NDc0OSAwMDAwMCBuIAowMDAwMjk2NTg5IDAwMDAw IG4gCjAwMDAyOTU0MTYgMDAwMDAgbiAKMDAwMDI5NTI5MCAwMDAwMCBuIAowMDAwMjk1ODQ5IDAw MDAwIG4gCjAwMDAyOTU3MjMgMDAwMDAgbiAKMDAwMDI5NjI4MiAwMDAwMCBuIAowMDAwMjk2MTU2 IDAwMDAwIG4gCjAwMDAyOTc5OTYgMDAwMDAgbiAKMDAwMDI5NjgyMyAwMDAwMCBuIAowMDAwMjk2 Njk3IDAwMDAwIG4gCjAwMDAyOTcyNTYgMDAwMDAgbiAKMDAwMDI5NzEzMCAwMDAwMCBuIAowMDAw Mjk3Njg5IDAwMDAwIG4gCjAwMDAyOTc1NjMgMDAwMDAgbiAKMDAwMDI5OTQwMyAwMDAwMCBuIAow MDAwMjk4MjMwIDAwMDAwIG4gCjAwMDAyOTgxMDQgMDAwMDAgbiAKMDAwMDI5ODY2MyAwMDAwMCBu IAowMDAwMjk4NTM3IDAwMDAwIG4gCjAwMDAyOTkwOTYgMDAwMDAgbiAKMDAwMDI5ODk3MCAwMDAw MCBuIAowMDAwMzAwODEwIDAwMDAwIG4gCjAwMDAyOTk2MzcgMDAwMDAgbiAKMDAwMDI5OTUxMSAw MDAwMCBuIAowMDAwMzAwMDcwIDAwMDAwIG4gCjAwMDAyOTk5NDQgMDAwMDAgbiAKMDAwMDMwMDUw MyAwMDAwMCBuIAowMDAwMzAwMzc3IDAwMDAwIG4gCjAwMDAzMDEzNTEgMDAwMDAgbiAKMDAwMDMw MTA0NCAwMDAwMCBuIAowMDAwMzAwOTE4IDAwMDAwIG4gCjAwMDAzMDE3NDMgMDAwMDAgbiAKMDAw MDMwMTU2NyAwMDAwMCBuIAowMDAwMzAxNDQxIDAwMDAwIG4gCjAwMDAzMDI0MzMgMDAwMDAgbiAK MDAwMDMwMTk1NyAwMDAwMCBuIAowMDAwMzAxODMzIDAwMDAwIG4gCjAwMDAzMDIyNTcgMDAwMDAg biAKMDAwMDMwMjEzMyAwMDAwMCBuIAowMDAwMzAzMzkwIDAwMDAwIG4gCjAwMDAzMDMxNjEgMDAw MDAgbiAKMDAwMDMwMjUzMiAwMDAwMCBuIAowMDAwMzAyNjU2IDAwMDAwIG4gCjAwMDAzMDI5MDQg MDAwMDAgbiAKMDAwMDMwMjc4MCAwMDAwMCBuIAowMDAwMzAzMDM3IDAwMDAwIG4gCjAwMDAzMDU0 NTQgMDAwMDAgbiAKMDAwMDMwODI1OCAwMDAwMCBuIAowMDAwMzEwODQ1IDAwMDAwIG4gCjAwMDAz MTA5MTkgMDAwMDAgbiAKMDAwMDMxMTIyOCAwMDAwMCBuIAowMDAwMzQ0Nzc3IDAwMDAwIG4gCjAw MDAzNDQ5MjcgMDAwMDAgbiAKMDAwMDM0NTA1OCAwMDAwMCBuIAowMDAwMzYwMzM5IDAwMDAwIG4g CjAwMDAzNjA1NjcgMDAwMDAgbiAKMDAwMDM2MTAxNCAwMDAwMCBuIAowMDAwMzYxNTMzIDAwMDAw IG4gCjAwMDAzNzY5ODYgMDAwMDAgbiAKMDAwMDM3NzIxNCAwMDAwMCBuIAowMDAwMzc3Njk2IDAw MDAwIG4gCjAwMDAzNzgyMTEgMDAwMDAgbiAKMDAwMDQwNzU0OSAwMDAwMCBuIAowMDAwNDA3Nzg3 IDAwMDAwIG4gCjAwMDA0MDgwMDkgMDAwMDAgbiAKMDAwMDQwODUxOSAwMDAwMCBuIAowMDAwNDIw ODU5IDAwMDAwIG4gCjAwMDA0MjEwODcgMDAwMDAgbiAKMDAwMDQyMTQ0MiAwMDAwMCBuIAowMDAw NDIxOTM1IDAwMDAwIG4gCjAwMDA0MzY4OTkgMDAwMDAgbiAKMDAwMDQzNzEzNyAwMDAwMCBuIAow MDAwNDM3NTA3IDAwMDAwIG4gCjAwMDA0MzgwMTcgMDAwMDAgbiAKMDAwMDQ0NzM4NSAwMDAwMCBu IAowMDAwNDQ3NjMzIDAwMDAwIG4gCjAwMDA0NDgxNTkgMDAwMDAgbiAKdHJhaWxlcgo8PC9TaXpl IDE1MDIKL1Jvb3QgMTQ3NyAwIFIKL0luZm8gMSAwIFI+PgpzdGFydHhyZWYKNDQ4Njc2CiUlRU9G --000000000000b0483805b7b19b35--