From nobody Thu Feb 3 23:38:05 2022 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 63EF03A0AC2 for ; Thu, 3 Feb 2022 23:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, 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_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=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 GJezX2XMqiQv for ; Thu, 3 Feb 2022 23:37:56 -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 A78E63A0AC1 for ; Thu, 3 Feb 2022 23:37:56 -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 2147UqmY052359; Thu, 3 Feb 2022 23:37:44 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=Wujp9aQrqfgFq9RQ4BsClinlcZ8asonMov3fU10AnDg=; b=pVj66I6OvwtJiVmsw70wexk3RmLHnst7O4nkgIBi1L5fgjWKOSJy1Ke1EKE2CczCwRB7 Vh6SknmCV9YIY3cKsmBh5w0UCS/hlM8c8+wRYj0VLCFbEFZ0e//e6emn/hoxtRnnC4Vg EB8idOYr8x8ObAPERbXmwlsvfZdMezVvLPKclMfUvM9gaRuJNji7KL2jN/36ubfa1xf9 /5Sg0j1ETDoSIHKOn5Q3UCwOxJ5weD3UxNhnb0pWVlrCafK44Kpw27ctPkUNC/PY53Kf jdFheptK2hRcx3TNnVApZw2BXEiieH8oFk+6Xic8eitaaL6bQrogtB/vHJXfbO7tLNNn 2A== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3e0r284kk2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 03 Feb 2022 23:37:44 -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-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R6R00CWTRUV1Q30@rn-mailsvcp-mta-lapp01.rno.apple.com>; Thu, 03 Feb 2022 23:37:43 -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.12.20210903 64bit (built Sep 3 2021)) id <0R6R00L00RTGWU00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 03 Feb 2022 23:37:43 -0800 (PST) X-Va-A: X-Va-T-CD: 5b1df986fc1cf28f03a98c189e99a4df X-Va-E-CD: d27b0bf1ec5e225c315eb75773194505 X-Va-R-CD: 7f6ba7ce084ea0aad2ff4f136dfa7fc9 X-Va-CD: 0 X-Va-ID: 06c807e5-bc5d-4a66-916c-e7c6d6dc49bf X-V-A: X-V-T-CD: 5b1df986fc1cf28f03a98c189e99a4df X-V-E-CD: d27b0bf1ec5e225c315eb75773194505 X-V-R-CD: 7f6ba7ce084ea0aad2ff4f136dfa7fc9 X-V-CD: 0 X-V-ID: ad8addac-e818-4c0b-8a4a-c52a7b9ae143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-04_02:2022-02-03, 2022-02-04 signatures=0 Received: from smtpclient.apple (unknown [17.234.108.119]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R6R00C6IRUU9Z00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 03 Feb 2022 23:37:43 -0800 (PST) From: Vidhi Goel Message-id: <2FB9199D-4D31-418B-81DE-2E2D4358DEF6@apple.com> Content-type: multipart/signed; boundary="Apple-Mail=_BBEB9370-BBAF-4437-AFCD-7AAA518F2B27"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\)) Date: Thu, 03 Feb 2022 23:37:42 -0800 In-reply-to: Cc: tcpm@ietf.org, =?utf-8?Q?Ilpo_J=C3=A4rvinen?= , Mirja Kuehlewind , Richard Scheffenegger To: Bob Briscoe References: <164389942954.13556.7754569279919863072@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.100.0.2.11) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.816 definitions=2022-02-04_02:2022-02-03, 2022-02-04 signatures=0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-accurate-ecn-16.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, 04 Feb 2022 07:38:03 -0000 --Apple-Mail=_BBEB9370-BBAF-4437-AFCD-7AAA518F2B27 Content-Type: multipart/alternative; boundary="Apple-Mail=_98DD90BE-B568-4CC3-B475-76D897915AFB" --Apple-Mail=_98DD90BE-B568-4CC3-B475-76D897915AFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Bob and authors, I have read the draft a few times and will send my extensive review at a = later point. But right now, I want to ask some critical things that an = implementation could benefit from. The draft says, If a TCP client has set the SYN to Not-ECT, but receives feedback that the IP-ECN field on the SYN arrived with a different codepoint, it can detect such middlebox interference and send Not-ECT for the rest of the connection 1. On the forward path from client to server, the client will revert to = Not-ECT when it sees for example, that it sent a Non-ECT SYN but = received ACE encoding other than 0 1 0. What does the client do in the = last ACK of the 3WHS - a. does it stay in AccECN mode and still send AccECN encoding based on = the IP code point of SYN-ACK (Table 4)? This would mean that client = won=E2=80=99t participate in ECN on the sender half of the connection = and only provide AccECN feedback to the server as a receiver. b. does it disable AccECN mode and set ACE=3D 0 0 0 so that a server = in AccECN mode can disable ECN based on Table4? While writing this, I realized that the intention is probably a. Could = you confirm? Also, when the sender sets Not-ECT in its data packets, it = should also disable acting upon any ACE feedback as we could still = receive false ACE feedback from the server if the network, lets say, = changed 00 (not ECT) to 01(ECT1). If you agree, we should add some text = around this. Based on the current text, the sender will always respond = to the ACE feedback even if it sends Not-ECT. TBH, this is a complicated scenario, where sender said to the network - = I don=E2=80=99t trust you so I can=E2=80=99t use ECN. Feel free to drop = my packets. And the network mangles the IP to ECT1 and then set CE (when = congested) which would be feedback=E2=80=99ed from the receiver. Now, = the packet wasn=E2=80=99t dropped which it should have been. So, is it = better to just ignore this feedback because sender doesn=E2=80=99t trust = the network or just act on it and reduce cwnd in order to reduce = congestion in the network somewhere. 2. On the reverse path from server to client, if a server sends a = Not-ECT SYN-ACK and receives ACE handshake encoding on last ACK other = than 0 1 0, there is no text like above that says server should send = Not-ECT for the rest of the connection (or at least I didn=E2=80=99t = find it). I think the server should also do same as client as the two = paths could be different. One could make it more complicated by saying, = if both client and server decide to not use ECN on their corresponding = sender half, then ECN should be disabled but let=E2=80=99s talk about = that later. 3. In general, not setting the ECT (ECT0 or ECT1) code point on an = outgoing packet is different from supporting AccECN right as in the host = can still provide AccECN feedback on the receive path. =E2=80=A6. To be continued if more questions come to my mind. Thanks, Vidhi > On Feb 3, 2022, at 7:24 AM, Bob Briscoe wrote: >=20 > tcpm folks, >=20 > This rev to accurate-ecn is the first of two. The second will = hopefully follow on its heels in the next couple of days. >=20 > Diffs between this first rev (-16) and -15: >=20 > 1. switches round two fairly large sections, so I've deferred other = changes to a second rev so the diffs won't be masked by the switch round = of sections. > Suggested by Ilpo to match the order in which the tests in these = sections will be executed: > * Test for mangling the IP-ECN field (now 3.2.2.3), > * Then test for zeroing the ACE field (now 3.2.2.4). >=20 > 2. Ilpo suggested some clarifications in "3.2.3.2.5. Consistency = between AccECN Feedback Fields", which is about the receiver of feedback = ensuring consistency between the mandatory 3-bit ACE field and the = optional 24-bit counters. In brief (paraphrasing) it previously only = said "MUST consider both fields", when it is now clearer that it = actually meant "MUST reconcile both fields", so that there is always a = consistent baseline for subsequent ACKs. >=20 > 3. A minor point is added in an appendix about the details that the = pseudocode doesn't cover. >=20 >=20 >=20 > Bob >=20 > PS. #2 & #3 were added to the XML ages ago (Jul '21), so you will have = seen them in the HTML. However, prob due to my clumsiness, the posted = TXT didn't include them whereas the posted XML did (ironic for a section = about consistency). In turn, inconsistency was only possible because I = am having to manually post the TXT for this draft, due to an unresolved = issue with v3 RFC XML tables. >=20 >=20 > On 03/02/2022 14:43, 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. >>=20 >> Title : More Accurate ECN Feedback in TCP >> Authors : Bob Briscoe >> Mirja K=C3=BChlewind >> Richard Scheffenegger >> Filename : draft-ietf-tcpm-accurate-ecn-16.txt >> Pages : 60 >> Date : 2022-02-03 >>=20 >> Abstract: >> Explicit Congestion Notification (ECN) is a mechanism where = network >> nodes can mark IP packets instead of dropping them to indicate >> incipient congestion to the end-points. Receivers with an ECN- >> capable transport protocol feed back this information to the = sender. >> ECN was originally specified for TCP in such a way that only one >> feedback signal can be transmitted per Round-Trip Time (RTT). = Recent >> new TCP mechanisms like Congestion Exposure (ConEx), Data Center = TCP >> (DCTCP) or Low Latency Low Loss Scalable Throughput (L4S) need = more >> accurate ECN feedback information whenever more than one marking = is >> received in one RTT. This document specifies a scheme to provide >> more than one feedback signal per RTT in the TCP header. Given = TCP >> header space is scarce, it allocates a reserved header bit = previously >> assigned to the ECN-Nonce. It also overloads the two existing ECN >> flags in the TCP header. The resulting extra space is exploited = to >> feed back the IP-ECN field received during the 3-way handshake as >> well. Supplementary feedback information can optionally be = provided >> in a new TCP option, which is never used on the TCP SYN. The >> document also specifies the treatment of this updated TCP wire >> protocol by middleboxes. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/ >>=20 >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-16 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accurate-ecn-16 >>=20 >>=20 >> Internet-Drafts are also available by rsync at = rsync.ietf.org::internet-drafts >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_98DD90BE-B568-4CC3-B475-76D897915AFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Bob and authors,

I = have read the draft a few times and will send my extensive review at a = later point. But right now, I want to ask some critical things that an = implementation could benefit from.

The draft says,
If a TCP client has set the = SYN to Not-ECT, but
   receives feedback that the IP-ECN field on the = SYN arrived with a
   = different codepoint, it can detect such middlebox interference = and
   send Not-ECT for the rest of the = connection

1. On the forward = path from client to server, the client will revert to Not-ECT when it = sees for example, that it sent a Non-ECT SYN but received ACE encoding = other than 0 1 0. What = does the client do in the last ACK of the 3WHS = -
 a. does it stay in AccECN mode and still send AccECN = encoding based on the IP code point of SYN-ACK (Table 4)? This = would mean that client won=E2=80=99t participate in ECN on the sender = half of the connection and only provide AccECN feedback to the = server as a receiver.
 b. =  does it disable AccECN mode and set ACE=3D 0 0 0 so that a server = in AccECN mode can disable ECN based on = Table4?

While writing this, I realized that the intention = is probably a. Could you confirm? Also, when the sender sets = Not-ECT in its data packets, it should also disable acting upon any ACE = feedback as we could still receive false ACE feedback from the server = if the network, lets say, changed 00 (not ECT) to 01(ECT1). If you = agree, we should add some text around this. Based on the current text, = the sender will always respond to the ACE feedback even if it sends = Not-ECT.

TBH, this is a complicated scenario, where sender = said to the network - I don=E2=80=99t trust you so I can=E2=80=99t use = ECN. Feel free to drop my packets. And the network mangles the IP = to ECT1 and then set CE (when congested) which would be = feedback=E2=80=99ed from the receiver. Now, the packet wasn=E2=80=99t = dropped which it should have been. So, is it better to just ignore this = feedback because sender doesn=E2=80=99t trust the network or just act on = it and reduce cwnd in order to reduce congestion in the network = somewhere.

2. On the reverse path from server to client, = if a server sends a Not-ECT SYN-ACK and receives ACE handshake encoding = on last ACK other than 0 1 0, there is no text like above that says = server should send Not-ECT for the rest of the connection (or at = least I didn=E2=80=99t find it). I think the server should also do = same as client as the two paths could be different. One could make = it more complicated by saying, if both client and server decide to not = use ECN on their corresponding sender half, then ECN should be disabled = but let=E2=80=99s talk about that later.

3. In general, not setting the ECT (ECT0 or ECT1) code = point on an outgoing packet is different from supporting AccECN right as = in the host can still provide AccECN feedback on the receive = path.
=E2=80=A6.

To = be continued if more questions come to my mind.


Thanks,
Vidhi

On Feb 3, 2022, at 7:24 AM, Bob Briscoe <ietf@bobbriscoe.net>= wrote:

tcpm folks,

This rev to = accurate-ecn is the first of two. The second will hopefully follow on = its heels in the next couple of days.

Diffs = between this first rev (-16) and -15:

1.  switches round two fairly large sections, so I've = deferred other changes to a second rev so the diffs won't be masked by = the switch round of sections.
Suggested by Ilpo to match = the order in which the tests in these sections will be executed:
* Test for mangling the IP-ECN field (now 3.2.2.3),
* Then test for zeroing the ACE field (now 3.2.2.4).

2. Ilpo suggested some clarifications in = "3.2.3.2.5.  Consistency between AccECN Feedback Fields", which is = about the receiver of feedback ensuring consistency between the = mandatory 3-bit ACE field and the optional 24-bit counters. In brief = (paraphrasing) it previously only said "MUST consider both fields", when = it is now clearer that it actually meant "MUST reconcile both fields", = so that there is always a consistent baseline for subsequent ACKs.

3. A minor point is added in an appendix about = the details that the pseudocode doesn't cover.



Bob

PS. #2 & #3 were added to the XML ages ago (Jul '21), so = you will have seen them in the HTML. However, prob due to my clumsiness, = the posted TXT didn't include them whereas the posted XML did (ironic = for a section about consistency). In turn, inconsistency was only = possible because I am having to manually post the TXT for this draft, = due to an unresolved issue with v3 RFC XML tables.


On 03/02/2022 14:43, 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 =           : More = Accurate ECN Feedback in TCP
=         Authors =         : Bob Briscoe
=             &n= bsp;           &nbs= p; Mirja K=C3=BChlewind
=             &n= bsp;           &nbs= p; Richard Scheffenegger
Filename =        : = draft-ietf-tcpm-accurate-ecn-16.txt
Pages =           : 60
= Date =            : = 2022-02-03

Abstract:
=    Explicit Congestion Notification (ECN) is a mechanism = where network
   nodes can mark IP packets = instead of dropping them to indicate
=    incipient congestion to the end-points. =  Receivers with an ECN-
   capable = transport protocol feed back this information to the sender.
   ECN was originally specified for TCP in = such a way that only one
   feedback = signal can be transmitted per Round-Trip Time (RTT).  Recent
   new TCP mechanisms like Congestion = Exposure (ConEx), Data Center TCP
=    (DCTCP) or Low Latency Low Loss Scalable Throughput = (L4S) need more
   accurate ECN feedback = information whenever more than one marking is
=    received in one RTT.  This document specifies a = scheme to provide
   more than one = feedback signal per RTT in the TCP header.  Given TCP
=    header space is scarce, it allocates a reserved header = bit previously
   assigned to the = ECN-Nonce.  It also overloads the two existing ECN
=    flags in the TCP header.  The resulting extra = space is exploited to
   feed back the = IP-ECN field received during the 3-way handshake as
=    well.  Supplementary feedback information can = optionally be provided
   in a new TCP = option, which is never used on the TCP SYN.  The
=    document also specifies the treatment of this updated = TCP wire
   protocol by middleboxes.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/<= /a>

There is also an htmlized version = available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-= ecn-16

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-accurate-ec= n-16


Internet-Drafts are = also available by rsync at rsync.ietf.org::internet-drafts


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

--
_______________________________________________________________= _
Bob Briscoe =             &n= bsp;           &nbs= p;     http://bobbriscoe.net/

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

= --Apple-Mail=_98DD90BE-B568-4CC3-B475-76D897915AFB-- --Apple-Mail=_BBEB9370-BBAF-4437-AFCD-7AAA518F2B27 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDVcw ggXiMIIDyqADAgECAhBIRH/zqK+DO6/W9YJc1Ij1MA0GCSqGSIb3DQEBCwUAMIGBMQswCQYDVQQG EwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcGA1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UE CgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMMI0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9u IENBIEczMB4XDTIxMDgwNjA0NDIzNFoXDTIyMDgwNjA0NDIzNFowHzEdMBsGA1UEAwwUdmlkaGlf Z29lbEBhcHBsZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCyCTxZl7BN64Ez Q9MA7Fo/fJ29Jcm9uMrdTLiLZE16acSK8CoQGWPnd9c6cfg//wYSmD/gxWnVX8ulJWL56sf7Ja7+ jrT3cW7cdxht6eQJRvr0YltTioq231Fc+CODDEr1dv036LdAp9aFC8pUjeHcutAus9K1Fy2Jv2/m YqMpLOJBWAjbsKQZj4GOQWQFuSsWgMWzR7u1lajgXh/Dbhth0Bsq/Jxw00pWii+C/R72jTmt6/iR 5lp4FUqRKb5Z57hgyvfBHLvdA6vM14wQJbn2ZCTQP+Q+VLv7WnTyqrtQgye7Qco9hF/88IUMt8Jl bl0ROolRHu5bc8EhBHRnJfwjAgMBAAGjggG1MIIBsTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQYMBaA FL6XqaqEv4C/EFN9CTL54S4yG893MH4GCCsGAQUFBwEBBHIwcDA7BggrBgEFBQcwAoYvaHR0cDov L2NhY2VydC5hY3RhbGlzLml0L2NlcnRzL2FjdGFsaXMtYXV0Y2xpZzMwMQYIKwYBBQUHMAGGJWh0 dHA6Ly9vY3NwMDkuYWN0YWxpcy5pdC9WQS9BVVRIQ0wtRzMwHwYDVR0RBBgwFoEUdmlkaGlfZ29l bEBhcHBsZS5jb20wRwYDVR0gBEAwPjA8BgYrgR8BGAEwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93 d3cuYWN0YWxpcy5pdC9hcmVhLWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDBIBgNVHR8EQTA/MD2gO6A5hjdodHRwOi8vY3JsMDkuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FV VEhDTC1HMy9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSHc41CjY3YDZgFNJpaO4JkntF1KDAOBgNVHQ8B Af8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBAEVW9QtVl+A/wpyAwwilVcnOQf/kq97xUOZONxoX oitcWXdzfnCoZi92auE3hm4tM0+Z41IMesXa/+oFCW6gWcyxGiD+ee3hmGIQnqo6Ku6cGOUpQHu7 lhhlJD5nlsDMn5m6aJYpcMRSKKwZJkic5u3aU+SHKWGPBlChKHazgTCVlkWJ6S5lOHUHFZQb7DyY iCD5zG3eiakaKEKLnpae/wiZXKX27+dtcso6SN1eF01KT4r8XQQXvhCmD8XqsscrRBrUUwVOAEDw Wva83W9fkqsZXl/Y5H2w6smFoqsO1LVeawqEED/LoMedHIuOmFKna1teEs5RR8M7yK+IrgvrFIFR J/DdX71w33CnyAVYzC/G0OZz4I6J9bf73E2iTocmjcZ+LCHauVZzojvXF4kL6VPLIVR296QAs0Yu NM+79lmxdU0iDjsi7YOxepN3cwyNFXB2HI6hnlC9vcH9r2mbietUBIUIGPnWyO+n/bE8R2i+ONQY 86LJnUzDrh8RhxBIVwV+8O0uWxWRfFlH1f7L73AbvU7oFjdzCg51mA9BbeE35jnz4tAZqWmqCjBu O2Jh5BJkqhGpdUpwdAYdmCrDB3P1nLeOMHpRMGaer7q7WEE6jhMCHoztskzv3MBwX94y+mxl5022 FA9WewUWk+A+bPzH+DYoGaPm9j3f2M5Cxl5uMIIHbTCCBVWgAwIBAgIQFxA+3j2KHLXKBlGT58pD azANBgkqhkiG9w0BAQsFADBrMQswCQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0 aW9uIFJvb3QgQ0EwHhcNMjAwNzA2MDg0NTQ3WhcNMzAwOTIyMTEyMjAyWjCBgTELMAkGA1UEBhMC SVQxEDAOBgNVBAgMB0JlcmdhbW8xGTAXBgNVBAcMEFBvbnRlIFNhbiBQaWV0cm8xFzAVBgNVBAoM DkFjdGFsaXMgUy5wLkEuMSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlvbiBD QSBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAO3mh5ahwaS27cJCVfc/Dw8iYF8T 4KZDiIZJkXkcGy8aUA/cRgHu9ro6hsxRYe/ED4AIcSlarRh82HqtFSVQs4ZwikQW1V/icCIS91C2 IVAGa1YlKfedqgweqky+bBniUvRevVT0keZOqRTcO5hw007dL6FhYNmlZBt5IaJs1V6IniRjokOH R++qWgrUGy5LefY6ACs9gZ8Bi0OMK9PZ37pibeQCsdmMRytl4Ej7JVWeM/BtNIIprHwO1LY0/8In pGOmdG+5LC6xHLzg53B0HvVUqzUQNePUhNwJZFmmTP46FXovxmH4/SuY5IkXop0eJqjN+dxRHHiz ngYUk1EaTHUOcLFy4vQ0kxgbjb+GsNg6M2/6gZZIRk78JPdpotIwHnBNtkp9wPVH61NqdcP7kbPk yLXkNMTtAfydpmNnGqqHLEvUrK4iBpUPG9C09KOjm9OyhrT2uf5SLzJsee9g79r/rw4hAgcsZtR3 YI6fCbROJncmD+hgbHCck+9TWcNc1x5xZMgm8UXmoPamkkfceAlVV49QQ5jUTgqneTQHyF1F2ExX mf47pEIoJMVxloRIXywQuB2uqcIs8/X6tfsMDynFmhfT/0mTrgQ6xt9DIsgmWuuhvZhLReWS7oeK xnyqscuGeTMXnLs7fjGZq0inyhnlznhA/4rl+WdNjNaO4jEvAgMBAAGjggH0MIIB8DAPBgNVHRMB Af8EBTADAQH/MB8GA1UdIwQYMBaAFFLYiDrIn3hm7YnzezhwlMkCAjbQMEEGCCsGAQUFBwEBBDUw MzAxBggrBgEFBQcwAYYlaHR0cDovL29jc3AwNS5hY3RhbGlzLml0L1ZBL0FVVEgtUk9PVDBFBgNV HSAEPjA8MDoGBFUdIAAwMjAwBggrBgEFBQcCARYkaHR0cHM6Ly93d3cuYWN0YWxpcy5pdC9hcmVh LWRvd25sb2FkMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDCB4wYDVR0fBIHbMIHYMIGW oIGToIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5NjcsYyUz ZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUu YWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMB0GA1UdDgQWBBS+l6mq hL+AvxBTfQky+eEuMhvPdzAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcNAQELBQADggIBACab5xtZ DXSzEgPp51X3hICFzULDO2EcV8em5hLfSCKxZR9amCnjcODVfMbaKfdUZXtevMIIZmHgkz9dBan7 ijGbJXjZCPP29zwZGSyCjpfadg5s9hnNCN1r3DGwIHfyLgbcfffDyV/2wW+XTGbhldnazZsX892q +srRmC8XnX4ygg+eWL/AkHDenvbFuTlJvUyd5I7e1nb3dYXMObPu24ZTQ9/K1hSQbs7pqecaptTU joIDpBUpSp4Us+h1I4MAWonemKYoPS9f0y65JrRCKcfsKSI+1kwPSanDDMiydKzeo46XrS0hlA5N zQjqUJ7UsuGvPtDvknqc0v03nNXBnUjejYtvwO3sEDXdUW5m9kjNqlQZXzdHumZJVqPUGKTWcn9H f3d7qbCmmxPXjQoNUuHg56fLCanZWkEO4SP1GAgIA7SyJu/yffv0ts7sBFrSTD3L2mCAXM3Y8Bfb lvvDSf2bvySm/fPe9brmuzrCXsTxUQc1+/z5ydvzV3E3cLnUoSXP6XfXNyEVO6sPkcUSnISHM798 xLkCTB5EkjPCjPE2zs4v9L9JVOkkskvW6RnWWccdfR3fELNHL/kep8re6IbbYs8Hn5GM0Ohs8CMD PYEox+QX/6/SnOfyaqqSilBonMQBstsymBBgdEKO+tTHHCMnJQVvZn7jRQ20wXgxMrvNMYIDhTCC A4ECAQEwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYDVQQHDBBQb250 ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwjQWN0YWxpcyBD bGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwDQYJYIZIAWUDBAIB BQCgggG/MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMDIwNDA3 Mzc0MlowLwYJKoZIhvcNAQkEMSIEIFOrAOKUqrfvzYuvseiME5+g9qCo2+Z8sMCBmXnnlxgsMIGn BgkrBgEEAYI3EAQxgZkwgZYwgYExCzAJBgNVBAYTAklUMRAwDgYDVQQIDAdCZXJnYW1vMRkwFwYD VQQHDBBQb250ZSBTYW4gUGlldHJvMRcwFQYDVQQKDA5BY3RhbGlzIFMucC5BLjEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzMCEEhEf/Oor4M7r9b1glzUiPUwgakG CyqGSIb3DQEJEAILMYGZoIGWMIGBMQswCQYDVQQGEwJJVDEQMA4GA1UECAwHQmVyZ2FtbzEZMBcG A1UEBwwQUG9udGUgU2FuIFBpZXRybzEXMBUGA1UECgwOQWN0YWxpcyBTLnAuQS4xLDAqBgNVBAMM I0FjdGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEczAhBIRH/zqK+DO6/W9YJc1Ij1MA0G CSqGSIb3DQEBCwUABIIBAE0Zv15ThDhUXXed7LzNxgLApgZK14Tqv+spybUvn5MJMEHYSoRC4wpT DWvPGjRm8NJZGACooHcEuuIFKXYidcmon+GV0WWbektnEGyCEZluPVsCk1SkSqDe2GOpYDFXiAhW 2vpDWOE8fUi+HtfOidjIOXIX+2mGf3a+PHyUNxm0zeI4Gfoq9u0wTDROwwqWfwtQZ2a27QVmuhe6 Nf6Y1LeNJKThuK5Dw2Jwa806S946ylwDLc69stq2rNhJ/BtZAnY96NphoaQMwwHicr5OSSi9byqB ObxTATAhQoS4sZcB3lzyBA+0Scodmot5F2Jyl+x03f3eNjXpos8diSF5iUYAAAAAAAA= --Apple-Mail=_BBEB9370-BBAF-4437-AFCD-7AAA518F2B27--