From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc35.google.com (mail-oo1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 5FD723CBF0 for ; Mon, 6 May 2024 20:43:40 -0400 (EDT) Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5ad2da2196aso1821639eaf.2 for ; Mon, 06 May 2024 17:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1715042619; x=1715647419; 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=+LIzOTE8T2gALmUTBTPp5gcMOKrcH/Zp1GsNmtX0muA=; b=IaHSjVuMQCyFgBIXQloVctVSvHvSF/KmLeDlb1NN3mgV1HitYOs4sAONaSsl47N3LS HbdMIL18Yr4/RzoOY9oJV8VLGA9L1udJnrO9Ddx7k6890n7OOdQux7nNHp7UePvPrqDd aUAb3sO7iVgu+Xs//e0nPvwFn+BE/vKlEYMnI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715042619; x=1715647419; 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=+LIzOTE8T2gALmUTBTPp5gcMOKrcH/Zp1GsNmtX0muA=; b=ePYGVMjc1TdvQAfgIWOg0ynVl975CWNyOKNgZDbO6oM6Bt9DT9n1Kbue/F5Av6EK1g Pz29r36SeTS9KdNr3CVBpzeon68al11xaVOP3ca6TPB9BuKqkiGeUhTumKsWur2fztnu qhBvm41Sswlpi8x+sIFDh3l9qia/0DEjLBGrbNdKUJbmOhSiEMLiRmp6EcIGJY9gqNbk dcGueijC7oGECAUnQqPQSpt94TxsQNz6LI9MDEaMKiQy3p93Wk6yv2lzXlAvv1DJBS3q 9XX0ffYY0BsH8DLhUSF0R3SifoTZFvbbfpWcss7Ou82QmSjtantKpeWx2tAbQgZiIHr2 RflQ== X-Forwarded-Encrypted: i=1; AJvYcCU4UzyNwE15KeT3jp6ZvJcwNnR777iJ6/yCc583elOW9KIrJc0DNKd+NFuexXaGofxf9H43ifg//xkAVKC+wPdQ5/XWjCbwYJt5DuB77C8= X-Gm-Message-State: AOJu0Ywf++wvTsHmOUW4kuXJb3fV8/pW+1mT02DXNtIhYJc+kqoeeHkg y1JPEAWlSMyx+gfina5uwmJEmQ63zQPax2B9D5uB9XWvfl5YbU5Yu/1MgVD8JA== X-Google-Smtp-Source: AGHT+IHQ4G6MRtQ7vGz2BsrrNsgA4YrDpwZ5KHku1BrXjETfWXqHCR4a6l67HVb9uyAXfPARm00Dhg== X-Received: by 2002:a05:6359:4123:b0:183:ea4b:620 with SMTP id kh35-20020a056359412300b00183ea4b0620mr15655584rwc.28.1715042618889; Mon, 06 May 2024 17:43:38 -0700 (PDT) Received: from smtpclient.apple (dhcp-72-253-194-45.hawaiiantel.net. [72.253.194.45]) by smtp.gmail.com with ESMTPSA id p11-20020a635b0b000000b005e2b0671987sm8658582pgb.51.2024.05.06.17.43.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 May 2024 17:43:38 -0700 (PDT) From: Eugene Y Chang Message-Id: <78E8C67D-02F5-44A5-955E-D588FD17E834@ieee.org> Content-Type: multipart/signed; boundary="Apple-Mail=_66F3B656-FC72-4F41-9CF0-7F70FF50A8A9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Mon, 6 May 2024 14:43:36 -1000 In-Reply-To: Cc: Eugene Y Chang , Dave Taht via Starlink To: Dave Collier-Brown 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> 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: Tue, 07 May 2024 00:43:40 -0000 --Apple-Mail=_66F3B656-FC72-4F41-9CF0-7F70FF50A8A9 Content-Type: multipart/alternative; boundary="Apple-Mail=_0D828AC7-B0C8-494F-8D1F-A653CCD790C9" --Apple-Mail=_0D828AC7-B0C8-494F-8D1F-A653CCD790C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dave, We just can=E2=80=99t represent that we have the total solution. We need to show the problem can be reduced. We need to show that latency is a significant negative phenomena. Take out one contributor and sic the users to the next contributor. If we expect to solve the whole problem in one step, we end up where we = are and effectively say the problem is too complex to solve. Gene ---------------------------------------------- Eugene Chang IEEE Life Senior Member IEEE Communications Society & Signal Processing Society, Hawaii Chapter Chair IEEE Life Member Affinity Group Hawaii Chair IEEE Entrepreneurship, Mentor eugene.chang@ieee.org m 781-799-0233 (in Honolulu) > On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink = wrote: >=20 > I think that gamer experience doing simple (over-simple) tests with = CAKE is a booby-trap. This discussion suggests that the real performance = of their link is horrid, and that they turn off CAKE to get what they = think is full performance... but isn't. >=20 > = https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gamin= g_and_bufferbloat/#:~:text=3DIf%20there's%20any%20chance%20that,out%20any%= 20intermittent%20latency%20spikes = . > (I used to work for World Gaming, and follow the game commentators = more that I do now) >=20 > --dave >=20 >=20 > On 2024-05-06 07:25, Rich Brown via Starlink wrote: >> Hi Gene, >>=20 >> I've been vacillating on whether to send this note, but have decided = to pull the trigger. I apologize in advance for the "Debbie Downer" = nature of this message. I also apologize for any errors, omissions, or = over-simplifications of the "birth of bufferbloat" story and its fixes. = Corrections welcome. >>=20 >> Rich >> ------ >>=20 >> If we are going to take a shot at opening people's eyes to = bufferbloat, we should know some of the "objections" we'll run up = against. Even though there's terrific technical data to back it up, = people seem especially resistant to thinking that bufferbloat might = affect their network, even when they're seeing problems that sound = exactly like bufferbloat symptoms. But first, some history: >>=20 >> The very idea of bufferbloat is simply unbelievable. Jim Gettys in = 2011 [1] couldn't believe it, and he's a smart networking guy,. At the = time, it seemed incredible (that is "not credible" =3D=3D impossible) = that something could induce 1.2 seconds of latency into his home network = connection. He called in favors from technical contacts at his ISP and = at Bell Labs who went over everything with a fine-toothed comb. It was = all exactly as spec'd. But he still had the latency. >>=20 >> This led Jim and Dave T=C3=A4ht to start the investigation into the = phenomenon known today as "bufferbloat" - the undesirable latency that = comes from a router or other network equipment buffering too much data. = Over several years, a group of smart people made huge improvements: = fq_codel was released 14 May 2012 [3]; it was incorporated into the = Linux kernel shortly afterward. CAKE came in 2015, and the fixes that = minimize bufferbloat in Wi-Fi arrived in 2018. In 2021 cake-autorate [4] = arrived to handle varying speed ISP links. All these techniques work = great: in 2014, my 7mbps DSL link was quite usable. And when the = pandemic hit, fq_codel on my OpenWrt router allowed me to use that same = 7mbps DSL line for two simultaneous zoom calls. >>=20 >> As one of the authors of [2], I am part of the team that has tried = over the years to explain bufferbloat and how to fix it. We've spoken = with vendors. We've spent untold hours responding to posts on assorted = boards and forums with the the bufferbloat story. >>=20 >> With these technical fixes in hand, we cockily set about to tell the = world about how to fix bufferbloat. Our efforts have been met with = skepticism at best, or stony silence. What are the objections? >>=20 >> - This is just the ordinary behavior: I would expect things to be = slower when there's more traffic (Willfully ignoring orders of magnitude = increase in delay.) >> - Besides, I'm the only one using the internet. (Except when my phone = uploads photos. Or my computer kicks off some automated process. Or I = browse the web. Or ...) >> - It only happens some of the time. (Exactly. That's probably when = something's uploading photos, or your computer is doing stuff in the = background.) >> - Those bufferbloat tests you hear about are bogus. They artificially = add load, which isn't a realistic test. (...and if you actually are = downloading a file?) >> - Bufferbloat only happens when the network is 100% loaded. (True. = But when you open a web page, your browser briefly uses 100% of the = link. Is this enough to cause momentary lag?) >> - It's OK. I just tell my kids/spouse not to use the internet when = I'm gaming. (Huh?) >> - I have gigabit service from my ISP. (That helps, but if you're = complaining about "slowness" you still need to rule out bufferbloat in = your router.) >> - I can't believe that router manufacturers would ever allow such a = thing to happen in their gear. (See the Jim Gettys story above.) >> - I mean... wouldn't router vendors want to provide the best for = their customers? (No - implementing this (new-ish) code requires = engineering effort. They're selling plenty of routers with decade-old = software. The Boss says, "would we sell more if they made these changes? = Probably not.") >> - Why would my ISP provision/sell me a router that gave crappy = service? They're a big company, they must know about this stuff. (Maybe. = We have reached out to all the vendors. But remember they profit if you = decide your network is too slow and you upgrade to a faster = device/plan.) >> - But couldn't I just tweak the QoS on my router? (Maybe. But see = [5]) >> - Besides, I just spent $300 on a "gaming router". Obviously, I = bought the most expensive/best possible solution on the market (But I = still have lag...) >> - You're telling me that a bunch of pointy-headed academics are = smarter than commercial router developers - who sold me that $300 = router? (I can't believe it.) >> - And then you say that I should throw away that gaming router and = install some "open source firmware"? (What the heck is that? And why = should I believe you?) >> - What if it doesn't solve the problem? Who will give me support? And = how will I get back to a vendor-supported system? (Valid point - the = first valid point) >> - Aren't there any commercial solutions I can just buy? (Not at the = moment. IQrouter was a shining light here - available from Amazon, = simple setup, worked a treat - but they have gone out of business. And = of course, for the skeptic, this is proof that the "fq_codel-stuff" = isn't really a solution - it seems just like snake oil.) >>=20 >> So... All these hurdles make it hard to convince people that = bufferbloat could be the problem, or that they can fix for themselves. >>=20 >> A couple of us have reached out to Consumer Reports, wondering if = they would like a story about how vendors would prefer to sell you a = new, faster router (or new faster ISP plan) than fix your bufferbloat. = This kind of story seemed to be straight up their alley, but we never = heard back after an initial contact. Maybe they deserve another call... >>=20 >> The recent latency results from Starlink give me a modicum of hope. = They're a major player. They (and their customers) can point to an order = of magnitude reduction in latency over other solutions. It still = requires enough "regular customers" to tell their current ISP that they = are switching to Starlink (and spend $600 to purchase a Dishy plus = $100/month) to provide a market incentive. >>=20 >> Despite all this doom and gloom, I remain hopeful that things will = get better. We know the technology exists for people to take control of = their network and solve the problem for themselves. We can continue to = respond on forums where people express their dismay at the crummy = performance and suggest a solution. We can hope that a major vendor will = twig to this effect and bring out a mass-market solution. >>=20 >> I think your suggestion of speaking to eSports people is intriguing. = They're highly motivated to make their personal networks better. And = actually solving the problem would have a network effect of bringing in = others with the same problem. >>=20 >> Good luck, and thanks for thinking about this. >>=20 >> Rich Brown >>=20 >> [1] = https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat.p= df = [2] = https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Buffer= bloat/ = >> [3] = https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html= = >> [4] https://github.com/lynxthecat/cake-autorate = >> [5] = https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#wh= at-s-wrong-with-simply-configuring-qos = >>=20 >>> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink = > = wrote: >>>=20 >>> Of course. For the gamers, the focus is managing latency. They have = control of everything else. >>>=20 >>> With our high latency and wide range of values, the eSports teams = train on campus. It will be interesting to see how much improvements = there can be for teams to be able to training from their homes. >>>=20 >>> Gene >>> ---------------------------------------------- >>> Eugene Chang >>> IEEE Life Senior Member >>> IEEE Communications Society & Signal Processing Society, >>> Hawaii Chapter Chair >>> IEEE Life Member Affinity Group Hawaii Chair >>> IEEE Entrepreneurship, Mentor >>> eugene.chang@ieee.org >>> m 781-799-0233 (in Honolulu) >>=20 >>=20 >>=20 >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net = >> https://lists.bufferbloat.net/listinfo/starlink = > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dave.collier-brown@indexexchange.com = | -- Mark = Twain >=20 > CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, = including any and all attachments, contains confidential information = intended only for the person(s) to whom it is addressed. Any = dissemination, distribution, copying or disclosure is strictly = prohibited and is not a waiver of confidentiality. If you have received = this telecommunication in error, please notify the sender immediately by = return electronic mail and delete the message from your inbox and = deleted items folders. This telecommunication does not constitute an = express or implied agreement to conduct transactions by electronic = means, nor does it constitute a contract offer, a contract amendment or = an acceptance of a contract offer. Contract terms contained in this = telecommunication are subject to legal review and the completion of = formal documentation and are not binding until same is confirmed in = writing and has been signed by an authorized signatory. >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink --Apple-Mail=_0D828AC7-B0C8-494F-8D1F-A653CCD790C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dave,
We just can=E2=80=99t represent that we = have the total solution.
We need to show the = problem can be reduced.
We need to show that = latency is a significant negative phenomena. 
Take out one contributor and sic the users to the next = contributor.

If = we expect to solve the whole problem in one step, we end up where we are = and effectively say the problem is too complex to solve.


Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE = Communications Society & Signal Processing Society,    
    Hawaii Chapter Chair
IEEE Life Member = Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in = Honolulu)



On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink = <starlink@lists.bufferbloat.net> wrote:

I think that gamer experience doing simple = (over-simple) tests with CAKE is a booby-trap. This discussion suggests = that the real performance of their link is horrid, and that they turn = off CAKE to get what they think is full performance... but isn't.

https://www.reddit.com/r/HomeNe= tworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=3DIf= %20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spik= es.

 (I used to work for World Gaming, and follow the = game commentators more that I do now)

--dave


On 2024-05-06 07:25, Rich Brown via = Starlink wrote:
Hi Gene,

I've been vacillating on whether to send this note, but = have decided to pull the trigger. I apologize in advance for the "Debbie = Downer" nature of this message. I also apologize for any errors, = omissions, or over-simplifications of the "birth of bufferbloat" story and its fixes. Corrections welcome.

Rich
------

If we are going to take a shot at opening people's eyes = to bufferbloat, we should know some of the "objections" we'll run up = against. Even though there's terrific technical data to back it up, = people seem especially resistant to thinking that bufferbloat might affect their network, even when they're seeing = problems that sound exactly like bufferbloat symptoms. But first, some = history:

The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 = [1] couldn't believe it, and he's a smart networking guy,. At the time, = it seemed incredible (that is "not credible" =3D=3D impossible) = that something could induce 1.2 seconds of latency into his home network connection. He called in favors from technical = contacts at his ISP and at Bell Labs who went over everything with = a fine-toothed comb. It was all exactly as spec'd. But he still had the = latency. 

This led Jim and Dave T=C3=A4ht to start the investigation into the = phenomenon known today as "bufferbloat" - the undesirable latency that = comes from a router or other network equipment buffering too much = data. Over several years, a group of smart people made huge improvements: fq_codel was released 14 May 2012 [3]; it was = incorporated into the Linux kernel shortly afterward. CAKE came in = 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 2018. = In 2021 cake-autorate [4] arrived to handle varying speed ISP links. All these techniques work great: in 2014, my 7mbps DSL link = was quite usable. And when the pandemic hit, fq_codel on my OpenWrt = router allowed me to use that same 7mbps DSL line for two = simultaneous zoom calls. 

As one of the authors of [2], I am part of the team that = has tried over the years to explain bufferbloat and how to fix it. We've = spoken with vendors. We've spent untold hours responding to posts on = assorted boards and forums with the the bufferbloat story. 

With these technical fixes in hand, we cockily set about = to tell the world about how to fix bufferbloat. Our efforts have been = met with skepticism at best, or stony silence. What are the = objections? 

- This is just the ordinary behavior: I would expect = things to be slower when there's more traffic (Willfully ignoring orders = of magnitude increase in delay.)
- Besides, I'm the only one using the internet. (Except = when my phone uploads photos. Or my computer kicks off some automated = process. Or I browse the web. Or ...)
- It only happens some of the time. (Exactly. That's = probably when something's uploading photos, or your computer is doing = stuff in the background.)
- Those bufferbloat tests you hear about are bogus. They = artificially add load, which isn't a realistic test. (...and if you = actually are downloading a file?)
- Bufferbloat only happens when the network is 100% = loaded. (True. But when you open a web page, your browser briefly uses = 100% of the link. Is this enough to cause momentary lag?)
- It's OK. I just tell my kids/spouse not to use the = internet when I'm gaming. (Huh?)
- I have gigabit service from my ISP. (That helps, but = if you're complaining about "slowness" you still need to rule out = bufferbloat in your router.)
- I can't believe that router manufacturers would ever = allow such a thing to happen in their gear. (See the Jim Gettys story = above.)
- I mean... wouldn't router vendors want to provide the = best for their customers? (No - implementing this (new-ish) code = requires engineering effort. They're selling plenty of routers with = decade-old software. The Boss says, "would we sell more if they made these changes? Probably not.")
- Why would my ISP provision/sell me a router that gave = crappy service? They're a big company, they must know about this stuff. = (Maybe. We have reached out to all the vendors. But remember they profit = if you decide your network is too slow and you upgrade to a faster device/plan.)
- But couldn't I just tweak the QoS on my router? = (Maybe. But see [5])
- Besides, I just spent $300 on a "gaming router". = Obviously, I bought the most expensive/best possible solution on the = market (But I still have lag...)
- You're telling me that a bunch of pointy-headed = academics are smarter than commercial router developers - who sold me = that $300 router? (I can't believe it.)
- And then you say that I should throw away that gaming = router and install some "open source firmware"? (What the heck is that? = And why should I believe you?) 
- What if it doesn't solve the problem? Who will give me = support? And how will I get back to a vendor-supported system? (Valid = point - the first valid point)
- Aren't there any commercial solutions I can just buy? = (Not at the moment. IQrouter was a shining light here - available from = Amazon, simple setup, worked a treat - but they have gone out of = business. And of course, for the skeptic, this is proof that the "fq_codel-stuff" isn't really a solution - it seems just like = snake oil.)

So... All these hurdles make it hard to convince people = that bufferbloat could be the problem, or that they can fix for = themselves.

A couple of us have reached out to Consumer Reports, = wondering if they would like a story about how vendors would prefer to = sell you a new, faster router (or new faster ISP plan) than fix your = bufferbloat. This kind of story seemed to be straight up their alley, but we never heard back after an initial contact. Maybe = they deserve another call...

The recent latency results from Starlink give me a = modicum of hope. They're a major player. They (and their customers) can = point to an order of magnitude reduction in latency over other = solutions. It still requires enough "regular customers" to tell their current ISP that they are switching to Starlink (and spend = $600 to purchase a Dishy plus $100/month) to provide a market = incentive.

Despite all this doom and gloom, I remain hopeful that = things will get better. We know the technology exists for people to take = control of their network and solve the problem for themselves. We can = continue to respond on forums where people express their dismay at the crummy performance and suggest a solution. We can = hope that a major vendor will twig to this effect and bring out a = mass-market solution.

I think your suggestion of speaking to eSports people is = intriguing. They're highly motivated to make their personal networks = better. And actually solving the problem would have a network effect of = bringing in others with the same problem. 

Good luck, and thanks for thinking about this.

Rich Brown

[1] https://courses.cs.washington.edu/courses/cse550/= 21au/papers/bufferbloat.pdf
[2] https://www.bufferbloat.net/projects/bloat/wiki/W= hat_can_I_do_about_Bufferbloat/
[3] https://lists.bufferbloat.net/pipermail/cerowrt-d= evel/2012-May/000233.html
[4] https://github.com/lynxthecat/cake-autorate
[5] https://www.bufferbloat.net/projects/bloat/wiki/M= ore_about_Bufferbloat/#what-s-wrong-with-simply-configuring-qos

On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink = <starlink@lists.bufferbloat.net> = wrote:

Of course. For the gamers, the focus is managing latency. They have = control of everything else.

With our high latency and wide range of values, the = eSports teams train on campus. It will be interesting to see how much = improvements there can be for teams to be able to training from their = homes.

Gene
----------------------------------------------
Eugene Chang
IEEE Life Senior Member
IEEE Communications Society & Signal Processing = Society,    
    Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii Chair
IEEE Entrepreneurship, Mentor
eugene.chang@ieee.org
m 781-799-0233 (in Honolulu)


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

--=20
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@in=
dexexchange.com |              -- Mark Twain

CONFIDENTIALITY NOTICE AND = DISCLAIMER : This telecommunication, including any and = all attachments, contains confidential information intended only for the = person(s) to whom it is addressed. Any dissemination, distribution, copying or = disclosure is strictly prohibited and is not a waiver of = confidentiality. If you have received this telecommunication in error, = please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This = telecommunication does not constitute an express or implied agreement to = conduct transactions by electronic means, nor does it constitute a = contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication = are subject to legal review and the completion of formal documentation = and are not binding until same is confirmed in writing and has been = signed by an authorized signatory.

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

= --Apple-Mail=_0D828AC7-B0C8-494F-8D1F-A653CCD790C9-- --Apple-Mail=_66F3B656-FC72-4F41-9CF0-7F70FF50A8A9 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/8FiYdKmAFAmY5eTgACgkQv0/8FiYd KmC7uw/8Dj8ahJUO31iJ/2QctjummrPtwcB9ZHZU61nUerPosorBg4YlW38IP1sR ap/3oMZXEhUrO3B6NRrM8PISkiWbQ+qeBcf647wbw1WEghCtMWIZukevP6tLH+7w kgGWCmffw6tAOze2dBVduTg8jsSVaTP3dPMzCwHb0xFvn+rrevA2ZioqGwF2IOVP O7pLkD4p3acLsP6fH0FjltKdhfdWs6MBhxl9H2jWqzc/WQ6fq6AyAH9GqfuFOTGX fBEnpIqKuYeW08FI7DyLXabVHRvQQ7BjTYBNFsGMQG71u/hzCg7hNBX+sheWH6aP CP2r8qtqiLX2WQjRnkAE8F99GFrfEW+Zq1zsVOTzSYsfffzDnh1m5zHYxpKQogyd EILNbfWPy7Le737UXqzMTxT+bz9MeFS7j/21INghpX5lsHfDWG24LjLr6dXg9MUm BjLh2evBvvYl2s/y1qGA2yuFuKhc+YbwsgRCbJqEKch111YvxEVjqrwixorxQyYm QX8Df9AbOrmnTmHpp7P53uYjGirCS3n8n+qmiBLWC80cqRNhNtZnQDgNaGDxrotm WXNfQGRk2AsmqIkpwO26BRydFWX7LN4dy+S5S5ajjJSRA7uyTpIeL+BrolD3tbiI yCtskofWlnDIXnPjCyh2wIKHfOhDvDf7OD9YniQu6Do+L6I24+4= =QN32 -----END PGP SIGNATURE----- --Apple-Mail=_66F3B656-FC72-4F41-9CF0-7F70FF50A8A9--