From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C17653B2A4 for ; Thu, 20 Oct 2022 15:32:07 -0400 (EDT) Received: by mail-lj1-x231.google.com with SMTP id bs14so750789ljb.9 for ; Thu, 20 Oct 2022 12:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lpB+RarUc8cyRXPqDXzEbpLUu22HTjo2vKlgmfg/b+g=; b=VGblF3V5qeLYbCui6ReP0+esAWqdmoBlHK8HZrPLsbCpT/AxDGDxegi9qG//ozvLZv 8QqWFdEdZTKICJRo7/n2AakvGFtNMAOR8QG8n6IA/g1SNf4ggWo7BvV5tigpoINzdauT ctnhdUWQLi5pT9zH1fAZ659iE2oULaAeaNqtE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lpB+RarUc8cyRXPqDXzEbpLUu22HTjo2vKlgmfg/b+g=; b=EifXoNBDTRGpLUVmYn5ox6+afQL+eJSnQYz2Fs7kV0GfYCF35ah6GHhnLfX9YeI6Hj 6NexybBrJuUMDR7JgSsy4jQkwEqcvQ8JTC/m2dM+Aeq0poYo01eoyXjE2qLtTwoKCDEZ REIv1w5nPVyRW+6Tbl04XMbSa2vZlB5pIa45+3qa7sD7fHOI+okoWTsdg6j2mg/SjOzF h0sqyxLzySyqyuaVWjlIJImGDQ2rt1Y66rldcxgjO0et02bE6fl7CkaOrUkWoToaw5Gy 7DuMhwVJ3d3NbiU4pV/ehRz/BD93APDsbgIQLG7cgySxM32JcJsBQYrn7KnScrFh+DYG rahA== X-Gm-Message-State: ACrzQf35jIgpsoOSVSBlLL0PwQ/Iqbqb6eyreQbMsClG/rFWk/mUq/yf T3c9OLLPuSL9tCSsRSoPaNfXPYlWd1LxqrvL5d7S6xamp+nvLN39PzxDKhtpRNGamqjg9T0w767 o84kprBNrzen2zaINLSJzdRaibZG2NL7L X-Google-Smtp-Source: AMsMyM5FTj7IfLMQEgy7ZfnLNL/bFp2SO0JxzX3kVtqILYXsutrlgkqeQTvtgV5M86lbZ6eWRVKYh1wOV1UeWN8tJ2E= X-Received: by 2002:a2e:a884:0:b0:25d:d8a2:d18c with SMTP id m4-20020a2ea884000000b0025dd8a2d18cmr5062569ljq.305.1666294326191; Thu, 20 Oct 2022 12:32:06 -0700 (PDT) MIME-Version: 1.0 References: <938D9D45-DADA-4291-BD8A-84E4257CEE49@apple.com> <9989D2F5-3A6A-454E-ABB8-71A29F3AAC0D@gmx.de> <4BE88889-45A9-41E4-91F6-4910530A6B4C@apple.com> In-Reply-To: From: Bob McMahon Date: Thu, 20 Oct 2022 12:31:54 -0700 Message-ID: To: Dave Taht Cc: Stuart Cheshire , Rpm , Make-Wifi-fast , Cake List , bloat Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006f89c205eb7c61a7" Subject: Re: [Rpm] [Make-wifi-fast] The most wonderful video ever about bufferbloat X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2022 19:32:08 -0000 --0000000000006f89c205eb7c61a7 Content-Type: multipart/alternative; boundary="00000000000067e53605eb7c6114" --00000000000067e53605eb7c6114 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The demo is nice but a way to measure this with full statistics can be actionable by engineers. I did add support for tcp write time with histograms, where setting TCP_NOTSENT_LOWAT, can give a sense of the network responsiveness as the writes will await the select() indicating the pipeline has drained. Nobody really uses this much. Also, there is a suggestion for the server to generate branches so-to-speak by sending an event back to the client, e.g. move the video pointer, but how does the test tool decide when to create the user events that need to be sent back? How long does it wait between events, etc? Bob On Thu, Oct 20, 2022 at 12:12 PM Dave Taht wrote: > On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-fast > wrote: > > > > Intel has a good analogous video on this with their CPU video here goin= g > over branches and failed predictions. And to Stuart's point, the longer > pipelines make the forks worse in the amount of in-process bytes that nee= d > to be thrown away. Interactivity, in my opinion, suggests shrinking the > pipeline because, with networks, there is no quick way to throw away stal= e > data rather every forwarding device continues forward with invalid data. > That's bad for the network too, spending resources on something that's no > longer valid. We in the test & measurement community never measure this. > > One of my all time favorite demos was of stuart's remote desktop > scenario, where he moved the mouse and the window moved with it. > > > There have been a few requests that iperf 2 measure the "bytes thrown > away" per a fork (user moves a video pointer, etc.) I haven't come up wit= h > a good test yet. I'm still trying to get basic awareness about existing > latency, OWD and responsiveness metrics. I do think measuring the amount = of > resources spent on stale data is sorta like food waste, few really pay > attention to it. > > > > Bob > > > > FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested. > > > > --tcp-write-prefetch n[kmKM] > > Set TCP_NOTSENT_LOWAT on the socket and use event based writes per > select() on the socket. > > > > > > On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire via Make-wifi-fast < > make-wifi-fast@lists.bufferbloat.net> wrote: > >> > >> On 20 Oct 2022, at 02:36, Sebastian Moeller wrote: > >> > >> > Hi Stuart, > >> > > >> > [SM] That seems to be somewhat optimistic. We have been there before= , > short of mandating actually-working oracle schedulers on all end-points, > intermediate hops will see queues some more and some less transient. So w= e > can strive to minimize queue build-up sure, but can not avoid queues and > long queues completely so we need methods to deal with them gracefully. > >> > Also not many applications are actually helped all that much by > letting information get stale in their own buffers as compared to an > on-path queue. Think an on-line reaction-time gated game, the need is to > distribute current world state to all participating clients ASAP. > >> > >> I=E2=80=99m afraid you are wrong about this. If an on-line game wants = low > delay, the only answer is for it to avoid generating position updates > faster than the network carry them. One packet giving the current game > player position is better than a backlog of ten previous stale ones waiti= ng > to go out. Sending packets faster than the network can carry them does no= t > get them to the destination faster; it gets them there slower. The same > applies to frames in a screen sharing application. Sending the current > state of the screen *now* is better than having a backlog of ten previous > stale frames sitting in buffers somewhere on their way to the destination= . > Stale data is not inevitable. Applications don=E2=80=99t need to have sta= le data if > they avoid generating stale data in the first place. > >> > >> Please watch this video, which explains it better than I can in a > written email: > >> > >> > >> > >> Stuart Cheshire > >> > >> _______________________________________________ > >> Make-wifi-fast mailing list > >> Make-wifi-fast@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of > it._______________________________________________ > > Make-wifi-fast mailing list > > Make-wifi-fast@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > > > -- > This song goes out to all the folk that thought Stadia would work: > > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698136666= 5607352320-FXtz > Dave T=C3=A4ht CEO, TekLibre, LLC > --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --00000000000067e53605eb7c6114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The demo is nice but a way to measure this with full stati= stics can be actionable by engineers. I did add support for tcp write time = with histograms, where setting TCP_NOTSENT_LOWAT, can give a sense of the n= etwork responsiveness as the writes will await the select() indicating=C2= =A0the pipeline has drained. Nobody really uses this much.

Also, the= re is a suggestion for the server to generate branches so-to-speak by sendi= ng an event back to the client, e.g. move the video pointer, but how does t= he test tool decide when to create the user events that need=C2=A0to be sen= t back? How long does it wait between events, etc?

Bob

On Thu, Oct 20= , 2022 at 12:12 PM Dave Taht <dav= e.taht@gmail.com> wrote:
On Thu, Oct 20, 2022 at 12:04 PM Bob McMahon via Make-wifi-= fast
<make-wifi-fast@lists.bufferbloat.net> wrote:
>
> Intel has a good analogous video on this with their CPU video here goi= ng over branches and failed predictions. And to Stuart's point, the lon= ger pipelines make the forks worse in the amount of in-process bytes that n= eed to be thrown away. Interactivity, in my opinion, suggests shrinking the= pipeline because, with networks, there is no quick way to throw away stale= data rather every forwarding device continues forward with invalid data. T= hat's bad for the network too, spending resources on something that'= ;s no longer valid. We in the test & measurement community never measur= e this.

One of my all time favorite demos was of stuart's remote desktop
scenario, where he moved the mouse and the window moved with it.

> There have been a few requests that iperf 2 measure the "bytes th= rown away" per a fork (user moves a video pointer, etc.) I haven't= come up with a good test yet. I'm still trying to get basic awareness = about existing latency, OWD and responsiveness metrics. I do think measurin= g the amount of resources spent on stale data is sorta like food waste, few= really pay attention to it.
>
> Bob
>
> FYI, iperf 2 supports TCP_NOTSENT_LOWAT for those interested.
>
> --tcp-write-prefetch n[kmKM]
> Set TCP_NOTSENT_LOWAT on the socket and use event based writes per sel= ect() on the socket.
>
>
> On Thu, Oct 20, 2022 at 11:32 AM Stuart Cheshire via Make-wifi-fast &l= t;make-wifi-fast@lists.bufferbloat.net> wrote:
>>
>> On 20 Oct 2022, at 02:36, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>> > Hi Stuart,
>> >
>> > [SM] That seems to be somewhat optimistic. We have been there= before, short of mandating actually-working oracle schedulers on all end-p= oints, intermediate hops will see queues some more and some less transient.= So we can strive to minimize queue build-up sure, but can not avoid queues= and long queues completely so we need methods to deal with them gracefully= .
>> > Also not many applications are actually helped all that much = by letting information get stale in their own buffers as compared to an on-= path queue. Think an on-line reaction-time gated game, the need is to distr= ibute current world state to all participating clients ASAP.
>>
>> I=E2=80=99m afraid you are wrong about this. If an on-line game wa= nts low delay, the only answer is for it to avoid generating position updat= es faster than the network carry them. One packet giving the current game p= layer position is better than a backlog of ten previous stale ones waiting = to go out. Sending packets faster than the network can carry them does not = get them to the destination faster; it gets them there slower. The same app= lies to frames in a screen sharing application. Sending the current state o= f the screen *now* is better than having a backlog of ten previous stale fr= ames sitting in buffers somewhere on their way to the destination. Stale da= ta is not inevitable. Applications don=E2=80=99t need to have stale data if= they avoid generating stale data in the first place.
>>
>> Please watch this video, which explains it better than I can in a = written email:
>>
>> <https://developer.apple= .com/videos/play/wwdc2015/719/?time=3D892>
>>
>> Stuart Cheshire
>>
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo= /make-wifi-fast
>
>
> This electronic communication and the information and any files transm= itted with it, or attached to it, are confidential and are intended solely = for the use of the individual or entity to whom it is addressed and may con= tain information that is confidential, legally privileged, protected by pri= vacy laws, or otherwise restricted from disclosure to anyone else. If you a= re not the intended recipient or the person responsible for delivering the = e-mail to the intended recipient, you are hereby notified that any use, cop= ying, distributing, dissemination, forwarding, printing, or copying of this= e-mail is strictly prohibited. If you received this e-mail in error, pleas= e return the e-mail to the sender, delete it from your computer, and destro= y any printed copy of it._______________________________________________ > Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/ma= ke-wifi-fast



--
This song goes out to all the folk that thought Stadia would work:
https://www.= linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXt= z
Dave T=C3=A4ht CEO, TekLibre, LLC

This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --00000000000067e53605eb7c6114-- --0000000000006f89c205eb7c61a7 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIQagYJKoZIhvcNAQcCoIIQWzCCEFcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg3BMIIFDTCCA/WgAwIBAgIQeEqpED+lv77edQixNJMdADANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA5MTYwMDAwMDBaFw0yODA5MTYwMDAwMDBaMFsxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhHbG9iYWxTaWduIEdDQyBS MyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA vbCmXCcsbZ/a0fRIQMBxp4gJnnyeneFYpEtNydrZZ+GeKSMdHiDgXD1UnRSIudKo+moQ6YlCOu4t rVWO/EiXfYnK7zeop26ry1RpKtogB7/O115zultAz64ydQYLe+a1e/czkALg3sgTcOOcFZTXk38e aqsXsipoX1vsNurqPtnC27TWsA7pk4uKXscFjkeUE8JZu9BDKaswZygxBOPBQBwrA5+20Wxlk6k1 e6EKaaNaNZUy30q3ArEf30ZDpXyfCtiXnupjSK8WU2cK4qsEtj09JS4+mhi0CTCrCnXAzum3tgcH cHRg0prcSzzEUDQWoFxyuqwiwhHu3sPQNmFOMwIDAQABo4IB2jCCAdYwDgYDVR0PAQH/BAQDAgGG MGAGA1UdJQRZMFcGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYKKwYBBAGCNwoDBAYJ KwYBBAGCNxUGBgorBgEEAYI3CgMMBggrBgEFBQcDBwYIKwYBBQUHAxEwEgYDVR0TAQH/BAgwBgEB /wIBADAdBgNVHQ4EFgQUljPR5lgXWzR1ioFWZNW+SN6hj88wHwYDVR0jBBgwFoAUj/BLf6guRSSu TVD6Y5qL3uLdG7wwegYIKwYBBQUHAQEEbjBsMC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC5nbG9i YWxzaWduLmNvbS9yb290cjMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5j b20vY2FjZXJ0L3Jvb3QtcjMuY3J0MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ2xvYmFs c2lnbi5jb20vcm9vdC1yMy5jcmwwWgYDVR0gBFMwUTALBgkrBgEEAaAyASgwQgYKKwYBBAGgMgEo CjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAN BgkqhkiG9w0BAQsFAAOCAQEAdAXk/XCnDeAOd9nNEUvWPxblOQ/5o/q6OIeTYvoEvUUi2qHUOtbf jBGdTptFsXXe4RgjVF9b6DuizgYfy+cILmvi5hfk3Iq8MAZsgtW+A/otQsJvK2wRatLE61RbzkX8 9/OXEZ1zT7t/q2RiJqzpvV8NChxIj+P7WTtepPm9AIj0Keue+gS2qvzAZAY34ZZeRHgA7g5O4TPJ /oTd+4rgiU++wLDlcZYd/slFkaT3xg4qWDepEMjT4T1qFOQIL+ijUArYS4owpPg9NISTKa1qqKWJ jFoyms0d0GwOniIIbBvhI2MJ7BSY9MYtWVT5jJO3tsVHwj4cp92CSFuGwunFMzCCA18wggJHoAMC AQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9v dCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5 MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENB IC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0E XyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+J J5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8u nPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTv riBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGj QjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5N UPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigH M8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmU Y/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V 14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcy a5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/ XzCCBUkwggQxoAMCAQICDDGs4Qlq5OZK9mcDzTANBgkqhkiG9w0BAQsFADBbMQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTExMC8GA1UEAxMoR2xvYmFsU2lnbiBHQ0MgUjMg UGVyc29uYWxTaWduIDIgQ0EgMjAyMDAeFw0yMjA5MTAxMzMzNDFaFw0yNTA5MTAxMzMzNDFaMIGM MQswCQYDVQQGEwJJTjESMBAGA1UECBMJS2FybmF0YWthMRIwEAYDVQQHEwlCYW5nYWxvcmUxFjAU BgNVBAoTDUJyb2FkY29tIEluYy4xFDASBgNVBAMTC0JvYiBNY01haG9uMScwJQYJKoZIhvcNAQkB Fhhib2IubWNtYWhvbkBicm9hZGNvbS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDBfX3nsBFRdO26im8lhOadVadRmV/YWK+U9OoGlTE+2MDsjJwO5p/Q6iaTUropqMRH1E+EIuhe /OU6a3/btrqzARE77RaVSdz5swXt7M4ciN+z44nIEx36UQIlFLsBFa3is/J/QLFhTUFFf0wLJsUO wyja+KvygH/E5TyfeXf5T2Y2wjGZx8jQXZMDmNpfANlEBYDfzCNYcAIQNox8FuPpEpuxWvv7jvxV X5dfkSef9T/DbsDM0PeTVMVyYIQoRSMBIGxVkaqp0MJglvQ2mU4CXcoOGgm6XC8LoLoEvYojXFKC fRgCOT5xeMR10UPSBQIljKwt7fPhpYVY+jTtOclpAgMBAAGjggHZMIIB1TAOBgNVHQ8BAf8EBAMC BaAwgaMGCCsGAQUFBwEBBIGWMIGTME4GCCsGAQUFBzAChkJodHRwOi8vc2VjdXJlLmdsb2JhbHNp Z24uY29tL2NhY2VydC9nc2djY3IzcGVyc29uYWxzaWduMmNhMjAyMC5jcnQwQQYIKwYBBQUHMAGG NWh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2dzZ2NjcjNwZXJzb25hbHNpZ24yY2EyMDIwME0G A1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxz aWduLmNvbS9yZXBvc2l0b3J5LzAJBgNVHRMEAjAAMEkGA1UdHwRCMEAwPqA8oDqGOGh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NnY2NyM3BlcnNvbmFsc2lnbjJjYTIwMjAuY3JsMCMGA1UdEQQc MBqBGGJvYi5tY21haG9uQGJyb2FkY29tLmNvbTATBgNVHSUEDDAKBggrBgEFBQcDBDAfBgNVHSME GDAWgBSWM9HmWBdbNHWKgVZk1b5I3qGPzzAdBgNVHQ4EFgQUpG/4RP1YQA/iXGens9pIRe7CQxMw DQYJKoZIhvcNAQELBQADggEBACfWLy4qJyCnOa3sl4LEDAMU/gmJ6LbclGE5iR4KanAmlAt92gzN 5lSy/iE+wsRrXiHI7YKFgXX1kVK/RqMiPRrw4hq2j8nxoSi/VFiyS3CsfVMGkbY7HBTlBvla/tH+ +2nJprlXbJyz1GdvoJAeam5RvTWotcCGAjZmMa3U3zMkszgXN849xe3dUK1DauUGiInXEwEdXDcA /0CVjL3EEMj+kNWcLhrSZKwFtxggUyMW3XWRaAeAL9wOtEaXYqlgbtnV0n9FuoV2TNm3h7Mh7rjV I2zM+IZ3DE+XFK7dcPwte33u75QyySNJ3UMZqi25CO85yl8Bmo7aWRm99N7HGnkxggJtMIICaQIB ATBrMFsxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMTEwLwYDVQQDEyhH bG9iYWxTaWduIEdDQyBSMyBQZXJzb25hbFNpZ24gMiBDQSAyMDIwAgwxrOEJauTmSvZnA80wDQYJ YIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICUYlOZbxeuvb7K120u2e4Xi4zyS3zaw6QMB rg+wJMB8MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIyMTAyMDE5 MzIwNlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFlAwQCATAN BgkqhkiG9w0BAQEFAASCAQCoY8w4OJpC2aPW1lxOwmsuGqHPKgPu4Ai4ZakK4zuxglGApj95xOyd mEbWJKlp33PH8N1Scm3uzc+X8QVqLkTUx+GGZynxUkzogEfGZZpQsPQug2oO9lrKuobpaXKUbpxv bkHyD5avRFn/ofYCm0ZMEmGmUKi4hSgvzQPsIZnv0JwV0WDRxl4DRa3CeWYejSIRfpIbuLrqOPXj l/yhiTgAVCnoQ51YY2J4pChCEuoLHHEOvCtbEWdVykMDNc+kKBzhQeoXpbQ6kxRPFGz8+KjoaB3q MFCgMQA9wspOFKoa4vUC0lTvYowmUz13VRKE4CM2C47XOxZ2kad2GWpXkC3Q --0000000000006f89c205eb7c61a7--