From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bosmailout07.eigbox.net (bosmailout07.eigbox.net [66.96.184.7]) (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 9F8803B29E for ; Sat, 5 Mar 2022 13:26:59 -0500 (EST) Received: from bosmailscan06.eigbox.net ([10.20.15.6]) by bosmailout07.eigbox.net with esmtp (Exim) id 1nQZ7L-0005JV-7Z for starlink@lists.bufferbloat.net; Sat, 05 Mar 2022 13:26: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=oXADC2CafJkaG4MslFPWUR2kr5+W53802wifg2f5pWM=; b=kpaixFTTWGL9nJhSBRob6RQPnz +DvXKIZlHPEMjBK/LazUYbulrhEdLMa6HQSvwiKxqPM97jy4/p+GHccHlgfmlRBf2ud1vo3zoP93K ORGLXWzBWiqrR66/4e0+alBUbFlG6jDFG1p6ifwt7mYgn6TDvkPOmrOq2dJaKTuO32sHSbtW2iHTU 2d80laWJkfso/usLXWDTdbLsAvdqDQ5VC/zrJQohBf26E17JBUoO8STmztP0fAEEQuE9ndaQDigI+ dJFVOsJPu3rENSVd4pwMdifK9pD9NluL7mH26RyLHVFVXq2cUcOfBVsrvWba+EWPv1IFqc1d5kEZg qsI434xw==; Received: from [10.115.3.33] (helo=bosimpout13) by bosmailscan06.eigbox.net with esmtp (Exim) id 1nQZ7K-0001yp-VD for starlink@lists.bufferbloat.net; Sat, 05 Mar 2022 13:26:58 -0500 Received: from bosauthsmtp19.yourhostingaccount.com ([10.20.18.19]) by bosimpout13 with id 2iSv270010QhFXN01iSyhW; Sat, 05 Mar 2022 13:26:58 -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=NywPRAflErp4bMVd3I8A:9 a=CjuIK1q_8ugA:10 a=SSmOFEACAAAA:8 a=AhWKgLLftkn3kYOqx6oA:9 a=zWd1nficHMr9fghf: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]:51697 helo=SRA6) by bosauthsmtp19.eigbox.net with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim) id 1nQZ7H-0004Wv-1T; Sat, 05 Mar 2022 13:26: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> <2DA12D3D736443699EBFD93FDC9325A2@SRA6> In-Reply-To: Date: Sat, 5 Mar 2022 10:26:50 -0800 Organization: SRA Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0374_01D8307B.897868B0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AdgwdWwUnN1zm1iIR3iRJBHrDFMqwAARuA5Q 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 18:26:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0374_01D8307B.897868B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: Ulrich Speidel [mailto:u.speidel@auckland.ac.nz] Sent: Saturday, March 5, 2022 1:43 AM To: dickroy@alum.mit.edu; 'David Lang' Cc: starlink@lists.bufferbloat.net Subject: Re: [Starlink] Starlink Digest, Vol 12, Issue 6 On 5/03/2022 7:38 pm, Dick Roy wrote: -----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! Taken as read - but it's beside the point. Shannon-Hartley allows you to do what was proposed - turning a channel that supplies a small number of users with a lot of capacity each into one that supplies a large number of users with a little capacity each, and of course if you add diversity (space, polarisation, ...) then this applies even more so. But the point is that each communication system is designed around an expectation of how many users will access it, and that you can't simply take an existing technology and somehow assume that it will work with a larger number of users just because it's theoretically possible. Basically, you can't simply throw more dishys at the problem if you need to serve more users. [RR] Actually, to a certain extent it depends on how the "dishys are/could be connected" and how the satellites overhead are "configured", but that's a story for another day and related to the point about the Maverick show ))). That said, I agree that systems have to be and are designed/optimized to handle a specified load (really a range of loads) and can not be expected to perform as well outside that range, and I agree that anyone who thinks that Shannon can be simply be ignored (as was tried in the past by a very famous corporation we all know all too well) is simply delusional. As the saying goes, "you can not make chicken salad out of chicken feathers!" -- **************************************************************** 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/ **************************************************************** ------=_NextPart_000_0374_01D8307B.897868B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: = Ulrich Speidel [mailto:u.speidel@auckland.ac.nz]
Sent: Saturday, March 5, = 2022 1:43 AM
To: dickroy@alum.mit.edu; = 'David Lang'
Cc: = starlink@lists.bufferbloat.net
Subject: Re: [Starlink] = Starlink Digest, Vol 12, Issue 6

 

On 5/03/2022 7:38 pm, Dick Roy = wrote:

 

 

-----Original Message-----
From: Starlink [mailto:starlink-bo= unces@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!

Taken as read - but it's beside the point. Shannon-Hartley allows you to do = what was proposed - turning a channel that supplies a small number of users with = a lot of capacity each into one that supplies a large number of users with a = little capacity each, and of course if you add diversity (space, polarisation, = ...) then this applies even more so. But the point is that each communication = system is designed around an expectation of how many users will access it, and = that you can't simply take an existing technology and somehow assume that it = will work with a larger number of users just because it's theoretically = possible. Basically, you can't simply throw more dishys at the problem if you need = to serve more users.

[RR] Actually, to a certain extent it depends on how = the “dishys are/could be connected” and how the satellites overhead are = “configured”, but that’s a story for another day and related to the point about = the Maverick show ))).  That said, I agree that systems have to be and are = designed/optimized to handle a specified load (really a range of loads) and can not be = expected to perform as well outside that range, and I agree that anyone who thinks = that Shannon can be simply be ignored (as was tried in the past by a very famous = corporation we all know all too well) is simply delusional. As the saying goes, = “you can not make chicken salad out of chicken = feathers!”



-- 
**********************************************=
******************
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/
**********************************************=
******************
 
 
 
------=_NextPart_000_0374_01D8307B.897868B0--