From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 196B23B29E for ; Mon, 26 Sep 2022 16:54:21 -0400 (EDT) Received: by mail-pg1-x52e.google.com with SMTP id u69so7644044pgd.2 for ; Mon, 26 Sep 2022 13:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date; bh=+kckK9B8w+Brn7Q6l/aPZPbN/0VbJvueXz3ohtsnB4I=; b=fFotEzBUGHBab9+MqAZ9zlehCMKHnBqhQnYiQhTnL/5/c6nO4hGNN/K+UGZwQief8h K7R434ukbzBFAuZ0j/QbL2IbQ7y87cLjAH6bi1qDYs/CSqSzxvHhXvcOTxBO7M7zHPwx h7GygIf1gSbT98ZletmET69Ps39iac7NmZ+2w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date; bh=+kckK9B8w+Brn7Q6l/aPZPbN/0VbJvueXz3ohtsnB4I=; b=yA58hSisb2Y8tVcFdOupv5MSHCvS8ifv31dgGyR/ONevpphppHmCJmaFYTBlPCxNvj ZEnz+a+aBFeLers2l7yD+SU0PQdM+rDuyxp6L9AZWeyWikRR2LUO9sw8X5o5aBeUukB/ 5Qrn5DBxGbplVJIKsY3FLvQatYp32V9hLn0p9RLuweGgkZwHDNgP2NjCxsJjUcUjEHpW TBo1ep3QH//D9AMKGSnYT5aXKsTyFKERXdg2fph7Uw1EByCHH1DevH8Eg0ZxJzd0m4Zf oFD5lTYg4Ot/sL9EpJ4KvCtSvbLJIKvK4hJ9p7LBUVAOyyNGBrxzUdAF4k75Geyr5WFm TRGA== X-Gm-Message-State: ACrzQf0M3i4EHrSw0Y+U5zT5ObzfEI4XUmqe1RlmPjBoTB+RQCybaval 9TcyQUxeS/gdTJgOOYJzkzaNHw== X-Google-Smtp-Source: AMsMyM7IEX6Jv/opnUeUoPKB+R40Gcd+RESENW+ms+ocjhERyeH9JvzXJEs9MhTCWDexskzyQKJ0jQ== X-Received: by 2002:a05:6a00:1410:b0:528:5a5a:d846 with SMTP id l16-20020a056a00141000b005285a5ad846mr25968350pfu.9.1664225659370; Mon, 26 Sep 2022 13:54:19 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-196-65.hawaiiantel.net. [72.253.196.65]) by smtp.gmail.com with ESMTPSA id w7-20020a170902e88700b0017824e7065fsm11693521plg.180.2022.09.26.13.54.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Sep 2022 13:54:18 -0700 (PDT) From: Eugene Y Chang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F70016FF-53EE-4FBA-8203-3F97A22F528A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Date: Mon, 26 Sep 2022 10:54:17 -1000 In-Reply-To: <498p2p23-on1q-op89-p518-1874r3r6rpo@ynat.uz> Cc: Eugene Chang , Bruce Perens , Dave Taht via Starlink To: David Lang References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> <39E525B8-D356-4F76-82FF-F1F0B3183908@ieee.org> <498p2p23-on1q-op89-p518-1874r3r6rpo@ynat.uz> X-Mailer: Apple Mail (2.3696.120.41.1.1) Subject: Re: [Starlink] It's still the starlink latency... X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2022 20:54:21 -0000 --Apple-Mail=_F70016FF-53EE-4FBA-8203-3F97A22F528A Content-Type: multipart/alternative; boundary="Apple-Mail=_0EED75B4-B782-472F-8524-674F18ABCA9E" --Apple-Mail=_0EED75B4-B782-472F-8524-674F18ABCA9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ok, we are getting into the details. I agree. Every node in the path has to implement this to be effective. In fact, every node in the path has to have the same prioritization or = the scheme becomes ineffective. Gene ---------------------------------------------- Eugene Chang IEEE Senior Life Member eugene.chang@ieee.org 781-799-0233 (in Honolulu) > On Sep 26, 2022, at 10:48 AM, David Lang wrote: >=20 > software updates can do far more than just improve recovery. >=20 > In practice, large data transfers are less sensitive to latency than = smaller data transfers (i.e. downloading a CD image vs a video = conference), software can ensure better fairness in preventing a bulk = transfer from hurting the more latency sensitive transfers. >=20 > (the example below is not completely accurate, but I think it gets the = point across) >=20 > When buffers become excessivly large, you have the situation where a = video call is going to generate a small amount of data at a regular = interval, but a bulk data transfer is able to dump a huge amount of data = into the buffer instantly. >=20 > If you just do FIFO, then you get a small chunk of video call, then = several seconds worth of CD transfer, followed by the next small chunk = of the video call. >=20 > But the software can prevent the one app from hogging so much of the = connection and let the chunk of video call in sooner, avoiding the = impact to the real time traffic. Historically this has required the = admin classify all traffic and configure equipment to implement = different treatment based on the classification (and this requires trust = in the classification process), the bufferbloat team has developed = options (fq_codel and cake) that can ensure fairness between = applications/servers with little or no configuration, and no trust in = other systems to properly classify their traffic. >=20 > The one thing that Cake needs to work really well is to be able to = know what the data rate available is. With Starlink, this changes = frequently and cake integrated into the starlink dish/router software = would be far better than anything that can be done externally as the = rate changes can be fed directly into the settings (currently they are = only indirectly detected) >=20 > David Lang >=20 >=20 > On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote: >=20 >> You already know this. Bufferbloat is a symptom and not the cause. = Bufferbloat grows when there are (1) periods of low or no bandwidth or = (2) periods of insufficient bandwidth (aka network congestion). >>=20 >> If I understand this correctly, just a software update cannot make = bufferbloat go away. It might improve the speed of recovery (e.g. throw = away all time sensitive UDP messages). >>=20 >> Gene >> ---------------------------------------------- >> Eugene Chang >> IEEE Senior Life Member >> eugene.chang@ieee.org >> 781-799-0233 (in Honolulu) >>=20 >>=20 >>=20 >>> On Sep 26, 2022, at 10:04 AM, Bruce Perens wrote: >>>=20 >>> Please help to explain. Here's a draft to start with: >>>=20 >>> Starlink Performance Not Sufficient for Military Applications, Say = Scientists >>>=20 >>> The problem is not availability: Starlink works where nothing but = another satellite network would. It's not bandwidth, although others = have questions about sustaining bandwidth as the customer base grows. = It's latency and jitter. As load increases, latency, the time it takes = for a packet to get through, increases more than it should. The = scientists who have fought bufferbloat, a major cause of latency on the = internet, know why. SpaceX needs to upgrade their system to use the = scientist's Open Source modifications to Linux to fight bufferbloat, and = thus reduce latency. This is mostly just using a newer version, but = there are some tunable parameters. Jitter is a change in the speed of = getting a packet through the network during a connection, which is = inevitable in satellite networks, but will be improved by making use of = the bufferbloat-fighting software, and probably with the addition of = more satellites. >>>=20 >>> We've done all of the work, SpaceX just needs to adopt it by = upgrading their software, said scientist Dave Taht. Jim Gettys, Taht's = collaborator and creator of the X Window System, chimed in: >>> Open Source luminary Bruce Perens said: sometimes Starlink's latency = and jitter make it inadequate to remote-control my ham radio station. = But the military is experimenting with remote-control of vehicles on the = battlefield and other applications that can be demonstrated, but won't = happen at scale without adoption of bufferbloat-fighting strategies. >>>=20 >>> On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang = >> wrote: >>> The key issue is most people don=E2=80=99t understand why latency = matters. They don=E2=80=99t see it or feel it=E2=80=99s impact. >>>=20 >>> First, we have to help people see the symptoms of latency and how it = impacts something they care about. >>> - gamers care but most people may think it is frivolous. >>> - musicians care but that is mostly for a hobby. >>> - business should care because of productivity but they don=E2=80=99t = know how to =E2=80=9Csee=E2=80=9D the impact. >>>=20 >>> Second, there needs to be a =E2=80=9COMG, I have been seeing the = action of latency all this time and never knew it! I was being = shafted.=E2=80=9D Once you have this awakening, you can get all the = press you want for free. >>>=20 >>> Most of the time when business apps are developed, =E2=80=9Cwe=E2=80=9D= hide the impact of poor performance (aka latency) or they hide from the = discussion because the developers don=E2=80=99t have a way to fix the = latency. Maybe businesses don=E2=80=99t care because any employees = affected are just considered poor performers. (In bad economic times, = the poor performers are just laid off.) For employees, if they happen to = be at a location with bad latency, they don=E2=80=99t know that latency = is hurting them. Unfair but most people don=E2=80=99t know the issue is = latency. >>>=20 >>> Talking and explaining why latency is bad is not as effective as = showing why latency is bad. Showing has to be with something that has a = person impact. >>>=20 >>> Gene >>> ----------------------------------- >>> Eugene Chang >>> eugene.chang@alum.mit.edu = > >>> +1-781-799-0233 (in Honolulu) >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink = >> wrote: >>>>=20 >>>> If you want to get attention, you can get it for free. I can place = articles with various press if there is something interesting to say. = Did this all through the evangelism of Open Source. All we need to do is = write, sign, and publish a statement. What they actually write is less = relevant if they publish a link to our statement. >>>>=20 >>>> Right now I am concerned that the Starlink latency and jitter is = going to be a problem even for remote controlling my ham station. The US = Military is interested in doing much more, which they have demonstrated, = but I don't see happening at scale without some technical work on the = network. Being able to say this isn't ready for the government's = application would be an attention-getter. >>>>=20 >>>> Thanks >>>>=20 >>>> Bruce >>>>=20 >>>> On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink = >> wrote: >>>> These days, if you want attention, you gotta buy it. A 50k half = page >>>> ad in the wapo or NYT riffing off of It's the latency, Stupid!", >>>> signed by the kinds of luminaries we got for the fcc wifi fight, = would >>>> go a long way towards shifting the tide. >>>>=20 >>>> On Mon, Sep 26, 2022 at 8:29 AM Dave Taht >> wrote: >>>>>=20 >>>>> On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason >>>>> = >> wrote: >>>>>>=20 >>>>>> The awareness & understanding of latency & impact on QoE is = nearly unknown among reporters. IMO maybe there should be some kind of = background briefings for reporters - maybe like a simple YouTube video = explainer that is short & high level & visual? Otherwise reporters will = just continue to focus on what they know... >>>>>=20 >>>>> That's a great idea. I have visions of crashing the washington >>>>> correspondents dinner, but perhaps >>>>> there is some set of gatherings journalists regularly attend? >>>>>=20 >>>>>>=20 >>>>>> =EF=BB=BFOn 9/21/22, 14:35, "Starlink on behalf of Dave Taht via = Starlink" = > on behalf of = starlink@lists.bufferbloat.net = >> wrote: >>>>>>=20 >>>>>> I still find it remarkable that reporters are still missing = the >>>>>> meaning of the huge latencies for starlink, under load. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> FQ World Domination pending: = https://blog.cerowrt.org/post/state_of_fq_codel/ = > >>>>> Dave T=C3=A4ht CEO, TekLibre, LLC >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> FQ World Domination pending: = https://blog.cerowrt.org/post/state_of_fq_codel/ = > >>>> Dave T=C3=A4ht CEO, TekLibre, LLC >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net = = > >>>> https://lists.bufferbloat.net/listinfo/starlink = = > >>>>=20 >>>>=20 >>>> -- >>>> Bruce Perens K6BP >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists.bufferbloat.net = = > >>>> https://lists.bufferbloat.net/listinfo/starlink = = > >>>=20 >>>=20 >>>=20 >>> -- >>> Bruce Perens K6BP --Apple-Mail=_0EED75B4-B782-472F-8524-674F18ABCA9E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ok, = we are getting into the details. I agree.

Every node in the path has to implement = this to be effective.
In fact, every node in the = path has to have the same prioritization or the scheme becomes = ineffective.

Gene
----------------------------------------------
Eugene Chang
IEEE Senior Life = Member
eugene.chang@ieee.org
781-799-0233 (in = Honolulu)



On Sep 26, 2022, at 10:48 AM, David Lang <david@lang.hm> = wrote:

software updates can do far more than just improve = recovery.

In practice, = large data transfers are less sensitive to latency than smaller data = transfers (i.e. downloading a CD image vs a video conference), software = can ensure better fairness in preventing a bulk transfer from hurting = the more latency sensitive transfers.

(the example below is not completely accurate, but I think it = gets the point across)

When buffers become excessivly large, you have the situation = where a video call is going to generate a small amount of data at a = regular interval, but a bulk data transfer is able to dump a huge amount = of data into the buffer instantly.

If you just do FIFO, then you get a small chunk of video = call, then several seconds worth of CD transfer, followed by the next = small chunk of the video call.

But the software can prevent the one app from hogging so much = of the connection and let the chunk of video call in sooner, avoiding = the impact to the real time traffic. Historically this has required the = admin classify all traffic and configure equipment to implement = different treatment based on the classification (and this requires trust = in the classification process), the bufferbloat team has developed = options (fq_codel and cake) that can ensure fairness between = applications/servers with little or no configuration, and no trust in = other systems to properly classify their traffic.

The one thing = that Cake needs to work really well is to be able to know what the data = rate available is. With Starlink, this changes frequently and cake = integrated into the starlink dish/router software would be far better = than anything that can be done externally as the rate changes can be fed = directly into the settings (currently they are only indirectly = detected)

David = Lang


On Mon, 26 = Sep 2022, Eugene Y Chang via Starlink wrote:

You = already know this. Bufferbloat is a symptom and not the cause. = Bufferbloat grows when there are (1) periods of low or no bandwidth or = (2) periods of insufficient bandwidth (aka network congestion).

If I understand this correctly, just a = software update cannot make bufferbloat go away. It might improve the = speed of recovery (e.g. throw away all time sensitive UDP messages).

Gene
----------------------------------------------
Eugene Chang
IEEE Senior Life Member
eugene.chang@ieee.org
781-799-0233 (in = Honolulu)



On Sep 26, 2022, at = 10:04 AM, Bruce Perens <bruce@perens.com> wrote:

Please help to explain. Here's a draft to start with:

Starlink Performance Not Sufficient for = Military Applications, Say Scientists

The = problem is not availability: Starlink works where nothing but another = satellite network would. It's not bandwidth, although others have = questions about sustaining bandwidth as the customer base grows. It's = latency and jitter. As load increases, latency, the time it takes for a = packet to get through, increases more than it should. The scientists who = have fought bufferbloat, a major cause of latency on the internet, know = why. SpaceX needs to upgrade their system to use the scientist's Open = Source modifications to Linux to fight bufferbloat, and thus reduce = latency. This is mostly just using a newer version, but there are some = tunable parameters. Jitter is a change in the speed of getting a packet = through the network during a connection, which is inevitable in = satellite networks, but will be improved by making use of the = bufferbloat-fighting software, and probably with the addition of more = satellites.

We've done all of the work, = SpaceX just needs to adopt it by upgrading their software, said = scientist Dave Taht. Jim Gettys, Taht's collaborator and creator of the = X Window System, chimed in: <fill in here please>
Open= Source luminary Bruce Perens said: sometimes Starlink's latency and = jitter make it inadequate to remote-control my ham radio station. But = the military is experimenting with remote-control of vehicles on the = battlefield and other applications that can be demonstrated, but won't = happen at scale without adoption of bufferbloat-fighting strategies.

On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang = <eugene.chang@alum.mit.edu<mailto:eugene.chang@alum.mit.edu>> wrote:
The key issue is most people don=E2=80=99t understand why = latency matters. They don=E2=80=99t see it or feel it=E2=80=99s = impact.

First, we have to help people see = the symptoms of latency and how it impacts something they care about.
- gamers care but most people may think it is frivolous.
- musicians care but that is mostly for a hobby.
- business should care because of productivity but they = don=E2=80=99t know how to =E2=80=9Csee=E2=80=9D the impact.

Second, there needs to be a =E2=80=9COMG, I = have been seeing the action of latency all this time and never knew it! = I was being shafted.=E2=80=9D Once you have this awakening, you can get = all the press you want for free.

Most of = the time when business apps are developed, =E2=80=9Cwe=E2=80=9D hide the = impact of poor performance (aka latency) or they hide from the = discussion because the developers don=E2=80=99t have a way to fix the = latency. Maybe businesses don=E2=80=99t care because any employees = affected are just considered poor performers. (In bad economic times, = the poor performers are just laid off.) For employees, if they happen to = be at a location with bad latency, they don=E2=80=99t know that latency = is hurting them. Unfair but most people don=E2=80=99t know the issue is = latency.

Talking and explaining why latency = is bad is not as effective as showing why latency is bad. Showing has to = be with something that has a person impact.

Gene
-----------------------------------
Eugene Chang
eugene.chang@alum.mit.edu <mailto:eugene.chang@alum.mit.edu>
+1-781-799-0233 (in Honolulu)





On Sep 26, 2022, at 6:32 AM, Bruce Perens via = Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:

If you want to get attention, you can get it = for free. I can place articles with various press if there is something = interesting to say. Did this all through the evangelism of Open Source. = All we need to do is write, sign, and publish a statement. What they = actually write is less relevant if they publish a link to our = statement.

Right now I am concerned that = the Starlink latency and jitter is going to be a problem even for remote = controlling my ham station. The US Military is interested in doing much = more, which they have demonstrated, but I don't see happening at scale = without some technical work on the network. Being able to say this isn't = ready for the government's application would be an attention-getter.

   Thanks

   Bruce

On Mon, = Sep 26, 2022 at 9:21 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bufferbloat.net>> wrote:
These days, if you want attention, you gotta buy it. A 50k = half page
ad in the wapo or NYT riffing off of It's the = latency, Stupid!",
signed by the kinds of luminaries we = got for the fcc wifi fight, would
go a long way towards = shifting the tide.

On Mon, Sep 26, 2022 at = 8:29 AM Dave Taht <dave.taht@gmail.com <mailto:dave.taht@gmail.com>> wrote:

On Mon, = Sep 26, 2022 at 8:20 AM Livingood, Jason
<Jason_Livingood@comcast.com <mailto:Jason_Livingood@comcast.com>> wrote:

The = awareness & understanding of latency & impact on QoE is nearly = unknown among reporters. IMO maybe there should be some kind of = background briefings for reporters - maybe like a simple YouTube video = explainer that is short & high level & visual? Otherwise = reporters will just continue to focus on what they know...

That's a great idea. I have = visions of crashing the washington
correspondents dinner, = but perhaps
there is some set of gatherings journalists = regularly attend?


=EF=BB=BFOn 9/21/22, 14:35, "Starlink on = behalf of Dave Taht via Starlink" <starlink-bounces@lists.bufferbloat.net <mailto:starlink-bounces@lists.bufferbloat.net> on = behalf of starlink@lists.bufferbloat.net <mailto:starlink@lists.bufferbloat.net>> wrote:

   I still find it remarkable = that reporters are still missing the
   meaning of the huge latencies for starlink, = under load.




--
FQ World Domination = pending: https://blog.cerowrt.org/post/state_of_fq_codel/<https://blog.cerowrt.org/post/state_of_fq_codel/>
Dave T=C3=A4ht CEO, TekLibre, LLC



--FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/<https://blog.cerowrt.org/post/state_of_fq_codel/>
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>


--
Bruce Perens = K6BP
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net <mailto:Starlink@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/starlink <https://lists.bufferbloat.net/listinfo/starlink>



--Bruce Perens = K6BP

= --Apple-Mail=_0EED75B4-B782-472F-8524-674F18ABCA9E-- --Apple-Mail=_F70016FF-53EE-4FBA-8203-3F97A22F528A 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----- iQIzBAEBCAAdFiEERPTGiBqcibajhTSsv0/8FiYdKmAFAmMyEXkACgkQv0/8FiYd KmCxuw//fXKTW/VSR7TwB3imBA0+gSrus77K0x3UoNtgjTGdb+Ywr6U4JyTjLiHt 0L+MP+Dmo8bNL5EI+XcFGy1r+bT73Qs1oSg04EUQZBDXOSb8o8hfIg661Vk+UPmr u/60IsAcTSwrhzVjsN0nx76DpFaZfAblqxsLgYQ8kKx/F0W6+Z2EXb8QQfN56Kyf TjE1U3QBaGp/zYtlTmCxKUmGh9ADFfkCTQM5dvFvkuTXc2KMAbOLI7Y8A7i+vllj 3Ds2UXKcxbUX29Fqam16pT6aBEL/p1Aoj/o4j9GyD4/uLUzb9hQWm9rEzanM5uQB NLmf/quJwIL/P3lUOoaWGKT8HNFJ+XeTHg/HTATZq/s5e27ebzYU6sxa1WKTBgJr mlOCyC0BOJTLs/VqT0HCMomn977n4WeKx9HU2gMxhyS5dD+1C0m2AUDXTmzpC/9C TR5pAEG3xAP1TjrBJ/8iJwKPSz2XgJBf8vlyo4aFK15/C9VV3ANtuhD41/tAvxLE F5pvqh/XWPAID5LTC8z83hohaf413pM5F6WMRUJ2umDSPIalNGt3F5QUDI6vGMfD By9MYAxvPfrxEZZbjpBSfAXNoEZsHeogPrY9Onz4CiZkfAuh5ixDwfTNQKdazpXT OniVJw14kmwcrPjKp/yLm9eVChdVXJsoThdPrG2K3+QbVk/nyqY= =SlrC -----END PGP SIGNATURE----- --Apple-Mail=_F70016FF-53EE-4FBA-8203-3F97A22F528A--