From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bosmailout01.eigbox.net (bosmailout01.eigbox.net [66.96.189.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E756A3B29D for ; Sat, 5 Mar 2022 01:38:59 -0500 (EST) Received: from bosmailscan06.eigbox.net ([10.20.15.6]) by bosmailout01.eigbox.net with esmtp (Exim) id 1nQO4B-0008UG-FM for starlink@lists.bufferbloat.net; Sat, 05 Mar 2022 01:38:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alum.mit.edu; s=dkim; h=Sender:Content-Type:MIME-Version:Message-ID:Date: Subject:In-Reply-To:References:Cc:To:From:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=s7Cp6hrtJwCWCt0ZtEout7dJk8Enl6CcXnQrGmpmOtc=; b=WIGvL+n/LaU848jUSCgSVmWGjo G5e27LM3/gpyYTphmN5HnCtrJ+ZNUBRrQvB5O/KlHgbd8WqsG20l49aeR6RWSdlTENdDohjxjXj20 qqH7/wnOc4P8gBgOT52Ev3zJiM2G1RUeUigbVuq1UUXEismd6ty8lrFeRwGEm6qy98siA5/M+OK3+ etjc9SUUelRvKXvo0neL2HK9dNHdFfgR9gaoSAxDa1Dd1cs9rnRBY95CR4V43VY/B0nclnuuSF4FM /FFTMD9zq045kmnZhDDVuy8BAzs/iX8ENC/KO3HuwgbywcKoGJYIKndQl/pwAiPLs74SVubTF0l4e TRcHKWOg==; Received: from [10.115.3.33] (helo=bosimpout13) by bosmailscan06.eigbox.net with esmtp (Exim) id 1nQO4B-0002gM-63 for starlink@lists.bufferbloat.net; Sat, 05 Mar 2022 01:38:59 -0500 Received: from bosauthsmtp19.yourhostingaccount.com ([10.20.18.19]) by bosimpout13 with id 2Wev270040QhFXN01Weyr8; Sat, 05 Mar 2022 01:38:59 -0500 X-Authority-Analysis: v=2.3 cv=RNUo47q+ c=1 sm=1 tr=0 a=9UqFsMnAB6EOkiq4MrOclQ==:117 a=nIEF4cAZMyOU5h9mcfI6lg==:17 a=o8Y5sQTvuykA:10 a=6ulraYUaiNAA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=kurRqvosAAAA:8 a=qNp_YjjoAAAA:8 a=f_5UQKgSG4CrVKe0PZEA:9 a=CjuIK1q_8ugA:10 a=SSmOFEACAAAA:8 a=Gogu_4olRadJK6wT_v0A:9 a=Q4Xrx7XnqQH7K4h_:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=kbxRQ_lfPIoQnHsAj2-A:22 a=GPpaJ-c28cifDO-wfJs0:22 Received: from c-67-180-86-211.hsd1.ca.comcast.net ([67.180.86.211]:53114 helo=SRA6) by bosauthsmtp19.eigbox.net with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim) id 1nQO47-0003L5-Ch; Sat, 05 Mar 2022 01:38:55 -0500 Reply-To: From: "Dick Roy" To: "'Ulrich Speidel'" , "'David Lang'" Cc: References: <1646351242.121623495@apps.rackspace.com> <2b2f1808-8cf7-6eae-3157-a5fc554a2424@auckland.ac.nz> <03e73122-63c3-497b-82c6-b7b7f23b627a@Spark> <3ooo342q-s937-qq3-492q-723np793qoo@ynat.uz> <7ee92a7f-ae58-5090-8ee0-32df8ec29c2b@auckland.ac.nz> <712r509p-7on6-5657-3172-n9140n9097@ynat.uz> <2a03ec91-d938-1c85-ae0d-1cd23536f497@auckland.ac.nz> In-Reply-To: <2a03ec91-d938-1c85-ae0d-1cd23536f497@auckland.ac.nz> Date: Fri, 4 Mar 2022 22:38:50 -0800 Organization: SRA Message-ID: <2DA12D3D736443699EBFD93FDC9325A2@SRA6> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0321_01D83018.A1995AC0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdgwJf30X1StTJBwTyKL4T45zPCTyQAM//lg X-MimeOLE: Produced By Microsoft MimeOLE X-EN-UserInfo: f809475445fb8041985048e338e1a001:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: dickroy@intellicommunications.com Sender: "Dick Roy" X-EN-OrigIP: 67.180.86.211 X-EN-OrigHost: c-67-180-86-211.hsd1.ca.comcast.net Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6 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: Sat, 05 Mar 2022 06:39:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0321_01D83018.A1995AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf Of Ulrich Speidel Sent: Friday, March 4, 2022 4:14 PM To: David Lang Cc: starlink@lists.bufferbloat.net Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6 True, but Starlink is designed as a high bandwidth, low latency (OK, we won't mention their bufferbloat issues again here), and (currently) low user density service. Bandwidth-wise, good old Shannon and Hartley are agnostic about whether you divide your channel between 1 or a million users. [RR] But they are assuming a "single" channel in the time domain. When you can take advantage of other dimensions (eg. space) to create more channels, (aka SDMA) the capacity goes up! But in real communication systems that need to manage handovers and joining and departing customers, there is a certain amount of overhead involved in managing these, and the protocols used for this generally have a significant footprint in them that reflects the kind of situation their designer had in mind. E.g., since GSM, burst frames have been designed to reflect the designer's expectation as to how many end users a base station would service. I'd be very surprised if this was any different for Starlink. [RR] When you have more dimensions to work with/in (aka SDMA), the problems you note get easier to solve! Just watch the early 60's TV episode of Maverick about the farmers and the poker game and you will see how it can be done! WARNING: it's in black and white so don't try to adjust your viewing screen/TV set :^)))) Remember, Starlink's launch and initial target market was the American rural and underserved suburban populace. Pretty much all of them already had a low bandwidth service, it was high bandwidth service they needed. So I'd expect Starlink to be designed around a rather constrained number of Dishy clients per satellite. And yes I think it'd be a good idea to use mesh networks etc. in order to distribute Starlink resource to more people there. But I guess that this is already happening with other types of connectivity over there, too. On 5/03/2022 7:14 am, David Lang wrote: > On Fri, 4 Mar 2022, Ulrich Speidel wrote: > >> In terms of Starlink - I really think that it's a red herring, at >> least for now. As I said, if Starlink can't muster anywhere near >> enough satellite capacity to serve all of a small town in Montana >> that's surrounded by gateways close by, then it's not going to be >> replacing the Internet as we know it in a country 60% larger in area >> and 40 x larger in population. At best it might be able to provide >> some backup in a relatively small number of places. > > It depends on what you set as your requirements. If you are talking > about everyone streaming video, you are correct, but if you talk about > less bandwidth intensive uses, a little bandwidth goes a long ways. > > There's also FAR more of a difference between nothing and low > bandwidth than between low and high bandwidth. > > Telephone audio is an 64Mb stream, without compression, email and text > chat are very low bandwidth. > > 20 years ago, you could have an office of 100 employees living on a > 1.5Mb Internet connection and have people very happy. A single dishy > is 100x this. > > I agree that Starlink is not a full replacement for hard-wired > Internet, and it never will be. But the ability to get that much > bandwidth into an area that doesn't have wired Internet wihtout > requiring special crews to come in and set up the infrastructure (like > you would for geostationary dishes) is a huge step forward for > disaster relief. > > With capabilities like this now available, we (the tech community) > need to look at options to be able to extend this connectivity from a > point source across a wider area (ways to do mesh and have it not > collapse, understanding channnel allocations, sane directional antenna > uses, etc) including how to provide power. > > And also take a careful look at the bandwith that apps are using and > find ones that are sane to use. Since (almost) everyone has phones as > endpoints now, having the ability to put a voip app on the phones and > have them able to call and text chat freely within the connectivity > bubble without any need to use the external bandwith, but be able to > connect out in a fairly transparent manner (think how long distance > calls were something significant 40-50 years ago, but were still using > the same equipment and basic process). Can such apps indicate to the > user if they are talking to someone really local (say sharing the same > wifi), or more remote, so that they can > > How can such apps be made available to the people with phones? (Apple > makes it really hard to side-load apps for example), How can the > services get bundled (raspverry pi or live CD linux images that > provide these services and the app images to download for example). > What can be done with OpenWRT builds to make turnkey conversions of > APs into bandwidth-efficient mesh nodes. This includes how a bit of > wire can go a long way towards making a wifi system work better. > > How can we bundle lessons for techies on the ground to teach them what > to do (and what not to do) in setting these things up? > > David Lang > -- **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink ------=_NextPart_000_0321_01D83018.A1995AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-----
From: Starlink [mailto:starlink-bounces@lists.bufferbloat.net] On Behalf = Of Ulrich Speidel
Sent: Friday, March 4, 2022 4:14 PM
To: David Lang
Cc: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue = 6

 

True, but Starlink is designed as a high bandwidth, low latency = (OK, we

won't mention their bufferbloat issues again here), and = (currently) low

user density service.

 

Bandwidth-wise, good old Shannon and Hartley are agnostic about = whether

you divide your channel between 1 or a million users. =

[RR] But = they are assuming a “single” channel in the time domain.  When = you can take advantage of other dimensions (eg. space) to create more channels, = (aka SDMA) the capacity goes up!

But in real

communication systems that need to manage handovers and joining = and

departing customers, there is a certain amount of overhead = involved in

managing these, and the protocols used for this generally have a =

significant footprint in them that reflects the kind of = situation their

designer had in mind. E.g., since GSM, burst frames have been = designed

to reflect the designer's expectation as to how many end users a = base

station would service. I'd be very surprised if this was any = different

for Starlink.

[RR] When you have more dimensions to work with/in (aka SDMA), the problems you = note get easier to solve!  Just watch the early 60’s TV episode of = Maverick about the farmers and the poker game and you will see how it can be done! = WARNING: it’s in black and white so don’t try to adjust your viewing screen/TV = set :^))))

 

Remember, Starlink's launch and initial target market was the = American

rural and underserved suburban populace. Pretty much all of them already

had a low bandwidth service, it was high bandwidth service they = needed.

So I'd expect Starlink to be designed around a rather = constrained number

of Dishy clients per satellite.

 

And yes I think it'd be a good idea to use mesh networks etc. in = order

to distribute Starlink resource to more people there. But I = guess that

this is already happening with other types of connectivity over = there, too.

 

On 5/03/2022 7:14 am, David Lang = wrote:

> On Fri, 4 Mar 2022, Ulrich Speidel = wrote:

> 

>> In terms of Starlink - I really think that it's a red = herring, at

>> least for now. As I said, if Starlink can't muster = anywhere near

>> enough satellite capacity to serve all of a small town = in Montana =

>> that's surrounded by gateways close by, then it's not = going to be

>> replacing the Internet as we know it in a country 60% = larger in area

>> and 40 x larger in population. At best it might be able = to provide

>> some backup in a relatively small number of = places.

> 

> It depends on what you set as your requirements. If you are talking

> about everyone streaming video, you are correct, but if you = talk about

> less bandwidth intensive uses, a little bandwidth goes a = long ways.

> 

> There's also FAR more of a difference between nothing and = low

> bandwidth than between low and high = bandwidth.

> 

> Telephone audio is an 64Mb stream, without compression, = email and text

> chat are very low bandwidth.

> 

> 20 years ago, you could have an office of 100 employees = living on a

> 1.5Mb Internet connection and have people very happy. A = single dishy

> is 100x this.

> 

> I agree that Starlink is not a full replacement for = hard-wired

> Internet, and it never will be. But the ability to get that = much

> bandwidth into an area that doesn't have wired Internet = wihtout

> requiring special crews to come in and set up the = infrastructure (like

> you would for geostationary dishes) is a huge step forward = for

> disaster relief.

> 

> With capabilities like this now available, we (the tech = community)

> need to look at options to be able to extend this = connectivity from a

> point source across a wider area (ways to do mesh and have = it not

> collapse, understanding channnel allocations, sane = directional antenna

> uses, etc) including how to provide = power.

> 

> And also take a careful look at the bandwith that apps are = using and

> find ones that are sane to use. Since (almost) everyone has = phones as

> endpoints now, having the ability to put a voip app on the = phones and

> have them able to call and text chat freely within the connectivity

> bubble without any need to use the external bandwith, but = be able to

> connect out in a fairly transparent manner (think how long distance

> calls were something significant 40-50 years ago, but were = still using

> the same equipment and basic process). Can such apps = indicate to the

> user if they are talking to someone really local (say = sharing the same

> wifi), or more remote, so that they = can

> 

> How can such apps be made available to the people with = phones? (Apple

> makes it really hard to side-load apps for example), How = can the

> services get bundled (raspverry pi or live CD linux images = that

> provide these services and the app images to download for example).

> What can be done with OpenWRT builds to make turnkey = conversions of

> APs into bandwidth-efficient mesh nodes. This includes how = a bit of

> wire can go a long way towards making a wifi system work = better.

> 

> How can we bundle lessons for techies on the ground to = teach them what

> to do (and what not to do) in setting these things = up?

> 

> David Lang

> 

--

****************************************************************<= o:p>

Dr. Ulrich Speidel

 

School of Computer = Science

 

Room 303S.594 (City Campus)

 

The University of Auckland=

u.speidel@auckland.ac.nz

http://www.cs.auckland.ac.nz/~ulrich/

****************************************************************<= o:p>

 

 

 

_______________________________________________=

Starlink mailing list

Starlink@lists.bufferbloat.net

https://lists.bufferbloat.net/listinfo/starlink=

------=_NextPart_000_0321_01D83018.A1995AC0--