From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 5333F3B2A4 for ; Wed, 5 Jun 2024 15:17:33 -0400 (EDT) Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-7024791a950so906499b3a.0 for ; Wed, 05 Jun 2024 12:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1717615052; x=1718219852; darn=lists.bufferbloat.net; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=AhFl2hj5komrdfA9H2yp4A8gvZSLV0AZVJT4FgSjaNg=; b=AXVaVCEx6rv28vDQ9OwPJumOCjGwi94cvRZx4QKGZ+dyslRT5VVQJ6Urns70bVdGpu uOL0yTLBMmacmfM5P9uojflQ6AGt7fxQMMui9bjfxVEOpWGuDavnhZ2W2ZPBK/c9s6Zj Hhh3c3R6JfuiQK4IauW6l52Qj4hEgclCyZp6o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717615052; x=1718219852; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AhFl2hj5komrdfA9H2yp4A8gvZSLV0AZVJT4FgSjaNg=; b=tHF1YBy9zp3twyh5f7EQDaTC0jBLwSECCuC+HVuLQQyMhepJnEnW/QAr0jPDFCWPsu pKjcN1FZgjvC7ZOJUI22dQGPIpNPlKaAVrkaMqFtantZig8E7tPNKsJH/UmmHO2agZR/ /lYHD+Tv1IW6ve6F7k+2ucCFV+I85ckFJMpKR59DVaICyXKSJm1xjy+a9WTHwRaIwWeQ MCUYgRoZbMscB8Fh7yCdJMRk4l+qJ9kprajdPgGc+nj2qMXIktaHlWV7abPLvPheyQWO 5W26s+RkY7vbysVhztJrMZaNuvShQBULFjzkZNA1mjvje11EnWhUMAjRbqfvi/kOWve9 eKUg== X-Forwarded-Encrypted: i=1; AJvYcCX6ac9L8V344KBR/gxWK66OqIqezn8jx8KFW7N2AeSUq5AsoP1Nd2iz2LIN4hiqWcBqKA8zu5QcE8BG78EpzsdGdZy79YYoHxoUDkRLTxc= X-Gm-Message-State: AOJu0YwPyZAtTTDrZu4LU3LfzuH0RZ2WRlfig46Yz1AwdR3JQ0+e/7Iq a6z7Kou2d0kpxzTbh68eOcPe7jMjfHLkFsPXhYafQMUW4k/HBI0Hvm21uSit6g== X-Google-Smtp-Source: AGHT+IEFOR+OwIL1dQcKcp2p24fAYnhlGSV5rMSNwpdxFad/5k7VdOGIgIF6rU3KWzixtGOuHHBz8Q== X-Received: by 2002:a05:6a21:9988:b0:1b2:b18e:7851 with SMTP id adf61e73a8af0-1b2c57437d2mr556365637.30.1717615051719; Wed, 05 Jun 2024 12:17:31 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-192-210.hawaiiantel.net. [72.253.192.210]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-6c35a4b9694sm8199575a12.78.2024.06.05.12.17.30 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jun 2024 12:17:31 -0700 (PDT) From: Eugene Y Chang Message-Id: <2BA9EBCE-5E3B-4A04-933F-D460A5002ED1@ieee.org> Content-Type: multipart/signed; boundary="Apple-Mail=_B8546A02-1F6F-466A-B6EB-E36B6A591F9C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Wed, 5 Jun 2024 09:17:24 -1000 In-Reply-To: <97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com> Cc: Eugene Y Chang , Dave Taht via Starlink To: Alexandre Petrescu References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> <6qop2p3o-351p-788q-q1q2-86sosnq3rn21@ynat.uz> <3FF32F52-4A93-496B-85FF-00020FA4A48B@gmx.de> <08F6942E-CC08-4956-B92E-CBEC091D86E4@ieee.org> <2F510BD5-2D7E-4A6A-A3DE-C529D14F6FBC@apple.com> <1078E544-F61B-4289-BCA1-BCDD9FA77481@ieee.org> <97d6e6f0-d153-42fd-b6c1-b64fb429dfca@gmail.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem 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: Wed, 05 Jun 2024 19:17:33 -0000 --Apple-Mail=_B8546A02-1F6F-466A-B6EB-E36B6A591F9C Content-Type: multipart/alternative; boundary="Apple-Mail=_986B9E5D-3F97-4E77-B553-F7E0805FFDF3" --Apple-Mail=_986B9E5D-3F97-4E77-B553-F7E0805FFDF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alex, Thanks for the reminder about telepresence and conversation (telephone) = over a network. Even non-technical users can appreciate this. Has anyone = tried to establish a quantitive measure for this as a benchmark? If we = have this benchmark, we can relate our other measures (e.g., latency, = buffering, etc.) to these =E2=80=9Ccommon sense=E2=80=9D human measures. While the measures and technical issues make sense to us (the networking = engineers), they are too abstract to win support from non-technical = users. We need to show how the technical issues manifest in human = observable behavior. I wish for a way for normal people to relate to issues that drive us. Gene ---------------------------------------------- Eugene Chang eugene.chang@ieee.org o 781-799-0233 > On Jun 5, 2024, at 1:36 AM, Alexandre Petrescu via Starlink = wrote: >=20 >=20 > Le 04/06/2024 =C3=A0 22:58, Eugene Y Chang via Starlink a =C3=A9crit : >> For automobiles, the sensation of speed comes from engine noise and = the G-force at the seat-of-your-pants. >>=20 >> I think of it as mostly the second derivative of the motion (aka = acceleration). >>=20 >> For snappiness of a network action, it is the time interval from = activation to completion. This perception can be enhanced by giving = quick feedback (response) while many things are still in motion (still = incomplete). >>=20 >> We do need to agree on what makes a network snappy and how that is = measured. > I think a part of qualifying a communications network as 'snappy' is = to hold a 1-to-1 long-range audio conversation that acts as much as = possible as an in-person conversation to a person nearby. Landline = phones still excel at that and should be the benchmark. >=20 > A 'tele-presence' over satcom linking several persons each speaking in = high density bursts might need a 1ms RTT latency. >=20 > Alex >=20 >>=20 >>=20 >>=20 >> Gene >> ---------------------------------------------- >> Eugene Chang >> eugene.chang@ieee.org >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink = > = wrote: >>>=20 >>> Good examples Stuart, it is quite interesting that as humanity we = have not come up with aggregate term what would fairly collapse the = dimensions to one single metric that would describe the snappy feeling = we intuitively seek for but can not quite verbalize. Vehicles have the = same issues, we have top speed (F1 at 360mph feels fast compared to = Starship at 16000mph), we have acceleration (Hot-rod going 0 to 60 mph = in 5 seconds feels high but pales in comparison to Tesla going 0 to 60 = mph in 2 sec), we have horse powers (tractor plowing field with 300hp = feels great but seems small compared to 1000hp of Hot-rod) then also = there is torque (tractor with 1450 Nm of torque wins a Tesla having = 900Nm on wheel while at completely different torque curve). >>>=20 >>> Capacity has the same issue as literally the truck from your example = shipping magnetic tapes for "raw carry capacity" but it does not feel = responsive, snappy, good to handle in the "traffic" of Internet. We have = jitter, that could be compared to how a vehicle does in repeatability of = track laps? We have packet loss on how the car handles on curves and = does it slip off the track or on accelerations spin the wheels? Download = is speed forward, upload is almost like speed at reverse gear usually = far worse. Latency is like a lap track as such, depends on the track, = use-case specific tests "What time did it do on N=C3=BCrburgring?" or = "How fast does it go from 0 to 60Mbps? Less than 200ms?". Horse power = feels much like raw capacity of the HW / radio channel and techniques = available beam forming, frequencies etc. what was discussed here related = to Starlink and even collectively across different technologies. Speed = is then instead of how much specific combination of modem and = base-station combo can achieve at certain configuration? Torque feels = like ability to maintain that performance, closest we get is loaded = performance in context of bufferbloat? >>>=20 >>> Watching videos on Netflix require different performance = characteristics than downloading a big update to Fortnite. One has = certain acceleration need to have snappy user experience but focus is = more on connection stability at certain bitrate. On the other hand = Fortnite update you want to be delivered at brute force speeds without = ruining others user experience. >>>=20 >>> Maybe we can not find that aggregate property or metric, but just = need to be rigorous on making sure we accurately characterize each = dimension and standardize them so the confusion and play with words, = specially with marketing, get stabilized. Each needs to have = standardized benchmarks much like 3D rendering benchmarks and PC perf = tests are done? All that said, as I failed to come up with a perfect = term, "varying performance ISP links" feels like the right thing to say? = Now we have obfuscated to be able to throw any of the dimensions = underneath. Only thing left for us to do is then to provide those = dimensions like a nutrient labels. We are getting there? Nothing new = under the sun also to some extend. >>>=20 >>> Just as a funny side note on the tractor marketing: >>>=20 >>> =E2=80=9DTorque gives you the feeling of responsiveness and that the = machine does the right things,=E2=80=9D Tapani Katila encapsulates his = view. =E2=80=9CThe torque is directly linked to the feeling of having = power available in the entire range of the power curve, resulting in = more meaningful work.=E2=80=9D from = https://www.agcopower.com/power-is-important-but-torque-is-crucial/ = >>>=20 >>> Seems like some other people are also trying to figure out what = dimensions to showcase to customers? >>>=20 >>> Thank you for the thought provoking examples! >>>=20 >>> Is bufferbloat property of a vehicle or characteristic of the road = design? Is it a question of ICE vs EV -or- roundabout vs crossing with = traffic lights? Feels more like a roundabout, no? Is this the problem = behind the objections? >>>=20 >>> - Sauli >>>=20 >>> On Tue, Jun 4, 2024 at 9:19=E2=80=AFPM Stuart Cheshire via Starlink = > = wrote: >>> On May 7, 2024, at 18:48, Dave Taht via Starlink = > = wrote: >>>=20 >>> > This was a wonderful post, rich! >>>=20 >>> = > >>>=20 >>> I agree. Thanks for writing this Rich. >>>=20 >>> One minor change I will request. Any time you write words like = =E2=80=9Cspeed=E2=80=9D or =E2=80=9Cfast=E2=80=9D, pause and consider = whether it would be more accurate to use some other term like = =E2=80=9Ccapacity=E2=80=9D, =E2=80=9Cbandwidth=E2=80=9D, or = =E2=80=9Cthroughput=E2=80=9D. Part of what keeps us in this mess is that = people equate network capacity with =E2=80=9Cspeed=E2=80=9D, as if those = terms were synonyms. We can=E2=80=99t change how people think overnight, = but at least we can avoid further reinforcing that wrong thinking. >>>=20 >>> If someone has 200 Mb/s Internet service and it feels slow, then = they might upgrade to 400 Mb/s Internet service and expect everything to = be uniformly twice as fast. We here know that doubling the network = capacity may make large downloads faster, but everything else is most = likely unchanged, and can be even worse. >>>=20 >>> People never make this mistake in other contexts. If someone = commutes to work in their 20-foot RV feels that it=E2=80=99s too slow, = then upgrading to a 40-foot RV will not get them to work faster. A = 40-foot RV is *bigger* than a 20-foot RV, but it=E2=80=99s probably not = *faster*. If you are moving a vast amount of cargo that requires = multiple trips, then a larger truck will let you complete that task in = fewer trips. But for most daily driving, a bigger truck will not get to = your destination any quicker. >>>=20 >>> Some simple edits: >>>=20 >>> Instead of =E2=80=9Cvarying speed ISP links=E2=80=9D how about = =E2=80=9Cvarying capacity ISP links=E2=80=9D? >>>=20 >>> Instead of =E2=80=9Cthey profit if you decide your network is too = slow and you upgrade to a faster device/plan=E2=80=9D how about =E2=80=9Ct= hey profit if you decide your network is too slow and you upgrade to a = higher throughput device/plan=E2=80=9D? >>>=20 >>> Stuart Cheshire >>>=20 >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net = >>> https://lists.bufferbloat.net/listinfo/starlink = >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists.bufferbloat.net = >>> https://lists.bufferbloat.net/listinfo/starlink = >>=20 >>=20 >>=20 >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net = >> https://lists.bufferbloat.net/listinfo/starlink = > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink = --Apple-Mail=_986B9E5D-3F97-4E77-B553-F7E0805FFDF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alex,
Thanks for the reminder about = telepresence and conversation (telephone) over a network. Even = non-technical users can appreciate this. Has anyone tried to establish a = quantitive measure for this as a benchmark? If we have this benchmark, = we can relate our other measures (e.g., latency, buffering, etc.) to = these =E2=80=9Ccommon sense=E2=80=9D human measures.

While the measures and = technical issues make sense to us (the networking engineers), they = are too abstract to win support from non-technical users. We need to = show how the technical issues manifest in human observable = behavior.

I = wish for a way for normal people to relate to issues that drive = us.

Gene
-------------------------------------------= ---
Eugene Chang
eugene.chang@ieee.org
o 781-799-0233




On Jun 5, 2024, at 1:36 AM, Alexandre Petrescu via Starlink = <starlink@lists.bufferbloat.net> wrote:


Le 04/06/2024 =C3=A0 22:58, Eugene Y = Chang via Starlink a =C3=A9crit :
For automobiles, the = sensation of speed comes from engine noise and the G-force at the = seat-of-your-pants.

I think of it as mostly the second derivative of the motion = (aka acceleration).

For snappiness of a network action, it is the time interval = from activation to completion. This perception can be enhanced by giving = quick feedback (response) while many things are still in motion (still = incomplete).

We = do need to agree on what makes a network snappy and how that is = measured.

I think a part of qualifying a = communications network as 'snappy' is to hold a 1-to-1 long-range audio = conversation that acts as much as possible as an in-person conversation = to a person nearby.  Landline phones still excel at that and should = be the benchmark.

A 'tele-presence' over satcom linking several persons = each speaking in high density bursts might need a 1ms RTT latency. 

Alex




Gene
----------------------------------------------
Eugene Chang
eugene.chang@ieee.org






On Jun 4, 2024, at 10:06 AM, Sauli Kiviranta via Starlink = <starlink@lists.bufferbloat.net> = wrote:

Good examples Stuart, it is quite interesting = that as humanity we have not come up with aggregate term what would = fairly collapse the dimensions to one single metric that would describe = the snappy feeling we intuitively seek for but can not quite verbalize. = Vehicles have the same issues, we have top speed (F1 at 360mph feels = fast compared to Starship at 16000mph), we have acceleration (Hot-rod = going 0 to 60 mph in 5 seconds feels high but pales in comparison to = Tesla going 0 to 60 mph in 2 sec), we have horse powers (tractor plowing = field with 300hp feels great but seems small compared to 1000hp of = Hot-rod) then also there is torque (tractor with 1450 Nm of torque wins = a Tesla having 900Nm on wheel while at completely different torque = curve).

Capacity has the same issue as = literally the truck from your example shipping magnetic tapes for "raw = carry capacity" but it does not feel responsive, snappy, good to handle = in the "traffic" of Internet. We have jitter, that could be compared to = how a vehicle does in repeatability of track laps? We have packet loss = on how the car handles on curves and does it slip off the track or on = accelerations spin the wheels? Download is speed forward, upload is = almost like speed at reverse gear usually far worse. Latency is like a = lap track as such, depends on the track, use-case specific tests "What = time did it do on N=C3=BCrburgring?" or "How fast does it go from 0 = to 60Mbps? Less than 200ms?". Horse power feels much like raw capacity = of the HW / radio channel and techniques available beam forming, = frequencies etc. what was discussed here related to Starlink and even = collectively across different technologies. Speed is then instead of how = much specific combination of modem and base-station combo can achieve at = certain configuration? Torque feels like ability to maintain that = performance, closest we get is loaded performance in context of = bufferbloat? 

Watching videos on = Netflix require different performance characteristics than downloading a = big update to Fortnite. One has certain acceleration need to have snappy = user experience but focus is more on connection stability at certain = bitrate. On the other hand Fortnite update you want to be delivered at = brute force speeds without ruining others user experience.

Maybe we can not find = that aggregate property or metric, but just need to be rigorous on = making sure we accurately characterize each dimension and standardize = them so the confusion and play with words, specially with marketing, get = stabilized. Each needs to have standardized benchmarks much like 3D = rendering benchmarks and PC perf tests are done? All that said, as I = failed to come up with a perfect term, "varying performance ISP links" = feels like the right thing to say? Now we have obfuscated to be able to = throw any of the dimensions underneath. Only thing left for us to do is = then to provide those dimensions like a nutrient labels. We are getting = there? Nothing new under the sun also to some extend.

Just as a funny side note on the = tractor marketing:

=E2=80=9DTorque gives = you the feeling of responsiveness and that the machine does the right = things,=E2=80=9D Tapani Katila encapsulates his view. =E2=80=9CThe = torque is directly linked to the feeling of having power available in = the entire range of the power curve, resulting in more meaningful = work.=E2=80=9D from https://www.agcopower.com/power-is-important-but-= torque-is-crucial/

Seems like some other people are also trying to figure out = what dimensions to showcase to customers?

Thank you for the thought provoking = examples!

Is = bufferbloat property of a vehicle or characteristic of the road design? = Is it a question of ICE vs EV -or- roundabout vs crossing with traffic = lights? Feels more like a roundabout, no? Is this the problem behind the = objections?

- = Sauli

On Tue, Jun 4, 2024 at 9:19=E2=80=AFPM = Stuart Cheshire via Starlink <starlink@lists.bufferbloat.net> = wrote:
On May 7, 2024, at 18:48, Dave Taht via Starlink = <starlink@lists.bufferbloat.net> = wrote:

> This was a wonderful post, = rich!

<https://randomneuronsfiring.com/all-the-reasons-t= hat-bufferbloat-isnt-a-problem/>

I = agree. Thanks for writing this Rich.

One = minor change I will request. Any time you write words like =E2=80=9Cspeed=E2= =80=9D or =E2=80=9Cfast=E2=80=9D, pause and consider whether it would be = more accurate to use some other term like =E2=80=9Ccapacity=E2=80=9D, = =E2=80=9Cbandwidth=E2=80=9D, or =E2=80=9Cthroughput=E2=80=9D. Part of = what keeps us in this mess is that people equate network capacity with = =E2=80=9Cspeed=E2=80=9D, as if those terms were synonyms. We can=E2=80=99t= change how people think overnight, but at least we can avoid further = reinforcing that wrong thinking.

If someone = has 200 Mb/s Internet service and it feels slow, then they might upgrade = to 400 Mb/s Internet service and expect everything to be uniformly twice = as fast. We here know that doubling the network capacity may make large = downloads faster, but everything else is most likely unchanged, and can = be even worse.

People never make this = mistake in other contexts. If someone commutes to work in their 20-foot = RV feels that it=E2=80=99s too slow, then upgrading to a 40-foot RV will = not get them to work faster. A 40-foot RV is *bigger* than a 20-foot RV, = but it=E2=80=99s probably not *faster*. If you are moving a vast amount = of cargo that requires multiple trips, then a larger truck will let you = complete that task in fewer trips. But for most daily driving, a bigger = truck will not get to your destination any quicker.

Some simple edits:

Instead of = =E2=80=9Cvarying speed ISP links=E2=80=9D how about =E2=80=9Cvarying = capacity ISP links=E2=80=9D?

Instead of = =E2=80=9Cthey profit if you decide your network is too slow and you = upgrade to a faster device/plan=E2=80=9D how about =E2=80=9Cthey profit = if you decide your network is too slow and you upgrade to a higher = throughput device/plan=E2=80=9D?

Stuart = Cheshire

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink
____________________________________________= ___
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.buf= ferbloat.net/listinfo/starlink


_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.=
net
https://lists.buf=
ferbloat.net/listinfo/starlink
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

= --Apple-Mail=_986B9E5D-3F97-4E77-B553-F7E0805FFDF3-- --Apple-Mail=_B8546A02-1F6F-466A-B6EB-E36B6A591F9C 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/8FiYdKmAFAmZgucQACgkQv0/8FiYd KmBvLRAAg2sTG36hI7fpndzPP71CWDk9W5suMK4forCmbQzyBnoJ+PY+Df4L4Rwv T2b7/IzYBTF39uy8pUQowqmE9qxHSpv4SYEdTlo9UiSEEmNPbLpzXjjo2/2Sb7yz FKVR9YP5eRaqUARrOLJdgfojyL7dUUeoKcPanC8IdHaxbYPWQCG4cJRmcT9GyDr1 QjCZWXvtzbG6/QRYkhlsSH1SmnEsvpeTn8i0mK5nmpclR06OwSWTL9bABTlp405M fg4IiZO0DM+/BzUrNp79Ch8RskBQLuya8Dja7lrz6x7vsCJj5MFw7uOiMJGYMFwi eaVUmLJlSv2S9yxlxSIk0DMVh+Qd3+1gSZ3Y8X7RLKgF0Z6SizRWkMlVL4KCPNUx cl1U1PZAL4TFPnmfIbxtmvXDOGQtAdPZmmJvjuaVGwEPitjgRehy20dKRlIRzqCR u4o2GNxsZdq60cKTp7K5kgVN2NwF8drcF8MgtTKa9sH9aQeOSk/biKa9Gn1zggsQ aLuOqxCXFiBIIbBLU313Ul50GCt4ev8XhuxTA7qQwGTk0xGY5wR43tHJR+xrkOyN oRRJecaknuUFtSk2TjUBQo5oRwbP0/K2Cq6tJ9rdN3anv1S1F2po2CAOewx16SRu aMFEC9/ZZ8QzOQ7wLjot3swVrBVvVZfK8zX1synUaRNkmKKv7Zc= =lXem -----END PGP SIGNATURE----- --Apple-Mail=_B8546A02-1F6F-466A-B6EB-E36B6A591F9C--