From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (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 F162B3B29D for ; Fri, 4 Mar 2022 19:14:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1646439265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5NcYHrLnyPOmzDVfWZmZ9c08Td5VNE6wlcA552TQRew=; b=RdLiqv3ZhzddY1Wxm+B1OBbMWq+wCwHziG5mVTZWEdSwDhKnMkY9p7fR9CVbNRlMwl4+xz n1u1jke41+ok0LLIQ33aKlEjka95+eI7b9uZSM5ZYmWUrGh8TOsQblSZLIvLTaxQVBUWSQ tN5IrveY04IR/WqnKaLDWiyb6SW65ak= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2174.outbound.protection.outlook.com [104.47.71.174]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-92-JiPQbgORNr2hlqF9BAl13A-1; Sat, 05 Mar 2022 11:14:22 +1100 X-MC-Unique: JiPQbgORNr2hlqF9BAl13A-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by MEAPR01MB2614.ausprd01.prod.outlook.com (2603:10c6:201:5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.17; Sat, 5 Mar 2022 00:14:21 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::c189:5c25:c4bc:24e4]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::c189:5c25:c4bc:24e4%7]) with mapi id 15.20.5038.019; Sat, 5 Mar 2022 00:14:21 +0000 Message-ID: <2a03ec91-d938-1c85-ae0d-1cd23536f497@auckland.ac.nz> Date: Sat, 5 Mar 2022 13:14:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 To: David Lang Cc: Mike Puchol , starlink@lists.bufferbloat.net 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> From: Ulrich Speidel In-Reply-To: <712r509p-7on6-5657-3172-n9140n9097@ynat.uz> X-ClientProxiedBy: SY6PR01CA0021.ausprd01.prod.outlook.com (2603:10c6:10:eb::8) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b82834a-c91b-4900-17db-08d9fe3d189e X-MS-TrafficTypeDiagnostic: MEAPR01MB2614:EE_ X-MS-Exchange-AtpMessageProperties: SA|SL X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: fOcesXo5e19SMZtUlICm9ZskLFgqINjWTFrz+s1+HSanSgLq8/zCgI3Bwo34xNgVWhwQ5mTZwKgd1NZVUmbfckuCzMaJpf6TXWHLgUCbvG1BMr6wW0GRqDUUTEhjDWSMSRQtMmTEjNDFtvnT97QgpE/zZm8nNoHoEnQdefg6FT3systlHoPnieFc1vpGc9P7tXfByDd8mCqblfive17cRCgw/oUHoFTYPkfsQH26AaFIh7tNMyobDJJV6rXhB9biOV8WDJVkHLxZ1guhk1GJQmydEBi9rwkb4LQN7TDkFyVnOiyufgXFDHmU0RARoFJIOiYhsi9msI7iBf/q/K47O+hkFPNmD4DYjjp0iXA1Ot2ahdHZJHRHegnwuAwOevWNbiefxzvL/zR0plNa9DbNl1m5M0COy9Ulepwo3b8x/CidFdQCQyffLIOr3sZcE11oMhZZQm6sWXj+T0xu1A8jLzN6SP6SW+VpcYTUSSAlTplaqzLRToMQc330Waq8FLfi5u3dPZrAhrGgtVW5+xa59TJ3ouMMD41FM9wtqQxRRYzvgsExUlA3GgQHienLF35ylQpZLdXD/+hfFFe4Y7j/HbPcBPPRWDrTUMkuk4At8oY+MFlaXNRVywE6waU2z7bgwTTx94zMxwqH5hsCNLdMefo1Bii4POt+nexp+AD1w2g3Zt4Em5c+VJ6yrhSrrKPRWSwIkiTSqT37jvLBAviwPtn9UvjMGRiZyo2EAKR7mYLSRQPfVkMCehMshnrn5uOza8tIDkO6DRASS7RK8wUHAX4Oufd0E/fDkHTtwtQn08ixjJ6mVj0cqkChCrtUbMLs X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(508600001)(6486002)(966005)(6512007)(53546011)(36756003)(86362001)(6506007)(66556008)(66476007)(66946007)(38100700002)(8676002)(5660300002)(31686004)(8936002)(66574015)(83380400001)(316002)(786003)(186003)(2616005)(31696002)(2906002)(6916009)(4326008)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?R0VvMG9JTE1qa3FmdlBiZlpUUjlCbmVNajVBczJadmhwOTdaRkowNEphREpw?= =?utf-8?B?OEJVSEJESjVleTc2d2t2dGdEOFZPckpIdHpWRGlWNGUwamxnbnV3VGtTbUhM?= =?utf-8?B?dTNNVk9jd0x6VGZSTTFlMFlrSU5CblNnYnVRV1hlUDJERGUxSEppbjF1Qmdi?= =?utf-8?B?VC9scU9TQU1FK0t5QUJXcEFCazdHUUtzYUVvdjNUN0E1Nk1tY3FxaU5XTUl2?= =?utf-8?B?am02ZVIrMlZSQ1o1U2M0aWE5cVV3SWxSWXNzS1J2c09zZmliVm9icDRuT1RN?= =?utf-8?B?TGFmNStVdTFoZXlTbUh0bzFkRHY3QVFuQS9aTGVZY1NQUHJUR1dHek92YXBV?= =?utf-8?B?djh1VzdwVFREVnJDd1FSQ0JlVEdtR0VRcDZ1N1RLc2JqWFgwRW5EVE9odVZ6?= =?utf-8?B?VlcxWklqWkoxeUEyUnV6YUJyK0xCZEZhTXF4QnR1UnJlSVp0Qk1jSTVUTHFm?= =?utf-8?B?UnArR05XdDVySURNdHBKejhDV2lLd3hXRTRBM1NsZmFjODlzR3QwbmRpM25F?= =?utf-8?B?ZmRkZzE0OHVpSXZ2cjduSURIYWxJU252WWNVZlRHZGFoWkdYVW5YVHJGM3J1?= =?utf-8?B?dU52MXJLZFlJOGVRdTRsdStXVVFKbjVRUTJiL3cwWjM3bVVvWHlHaDNhUi83?= =?utf-8?B?ZEt6czBuN0xMU29kSGQrSFp0RVBsOWxBaS9PUjRCdGRHOFRTdTlFM284NmQw?= =?utf-8?B?ck9EZjVMTVJpT3M2dHRaM0ErVUI0WmhXeDNKdFdvNlZsOHZrY1lFL1E4LzVE?= =?utf-8?B?MnZ2eXdiQXlsRExSZ0tMQ3pEL21ZTzZTRnQvdXdBeHFYZTZqRExRNHU4TTFF?= =?utf-8?B?T1dZRHJzSThnaEQvU01OL09hR3dxeFNHcnhjVlpGaHJrU1dpNm1Qbmx5K3dO?= =?utf-8?B?V3lQeGRWZkxKbGw3SFdVQUo3WXV4SFAyMERQaENZaHk3T0lGTEt4UGpvVGk4?= =?utf-8?B?aUxla0tpQjZlR0VNdGhzNkhuTDI0dUtHaVJZVS9tbTJ6NnVVMUxNU3phdUVI?= =?utf-8?B?L0RxUDRtVFIrUWI3dG1lRUxDTDg4N0dVSEduQ3BLR2Y3MGVYbkpHc3M1YXdh?= =?utf-8?B?MkdEdFI2RVN4ZFhLQnhvNUl5eEc3Um5hWVV5aFFKSndBMGdMenNFY2FWUE1h?= =?utf-8?B?MnVSZkk3RThwd0lHK2o2U2FtK3RZRVpyUU9kV1NSdkphcU1pSWNtSEI4d1hG?= =?utf-8?B?VzU5UDBoQWVldnRJTjgzeUdjdno4MUJQZm40Q21jMUF0UHo3c2xlbjZmRUtz?= =?utf-8?B?UUVJRmtWVDVjeUhMVWZEdER2czN6L3NhMFh1OEdhck5zYStOYlBzVC9kYzBo?= =?utf-8?B?NUIrUHdLYzRRN0dZbytuWWFOSTNKUFphUmZTSmMreDZLdVlOc0tYdFJDdWJB?= =?utf-8?B?TUc3ZGxOMzJoaVJTdndMV0xxODIzOVRQb1IwU1lVM2diQUNaWFJkTWRielMy?= =?utf-8?B?SnJEa0xHN05may9DdDFrSFJZVWZ1cXFaZWRuYWJJV2wvL0t1K3ZpSjZxaHVN?= =?utf-8?B?VkQxRklvNWp5elpxVnhkUm8xUVdVaE04Wk9kS3pURDFTQnJUcVgrZXBpWm9x?= =?utf-8?B?REJEdVBlQ0ZpakwzMzRaZ09vWnlVRUJPVGtSbmlDTlpxcGFRbGdiSkZLcEgw?= =?utf-8?B?K01McnhIU1pxOGxrcktYaCtxVS9YM0ZLeTgwNU1jcG1DbWRXVkp6cHhMME5F?= =?utf-8?B?WUpXV1RRUXBkRC9sM21ZT1EvTWd0RnJFektSRGpURWdxR3Nna0xaNVJ1d0d5?= =?utf-8?B?VGxLSDdUMnZHWW1BWUE5Wm9TKzl5a0thRHBDN3BBMTF1SUp1SkE4K3o3UzJw?= =?utf-8?B?ek1TbDZWcG9UY0RRUTltR281OEJWU3BTQVk2SVk1ZWpkUk9pVzk2Y1hCa28v?= =?utf-8?B?SUNYb1hYamEwMTZjbnZ4OU4vQnFKMlhwb0RmQWRpYmpLSlIyTkU1cGFkVXpY?= =?utf-8?B?VFFnd2Q5Mm9QVnpOU1plaTJoakxlOUFGS2VyeHVNdzR2RnRxaWxTQnFCTnBa?= =?utf-8?B?MUE1dDd0bHEzWGtqYWI3c1NFUllNcmo0enJlYTNmSkpPSWJDWm1raVA0Wi9q?= =?utf-8?B?VFBXcmEzN3dOZklCY1lBSTBMSHBIaVNlSlFmYXFFM2F0N1VXYjM5blFlUTJo?= =?utf-8?B?QzFZaDNISFdQZ28xckNndzZLZUhIeGFUU2libmNmN0ZSelY1U21GMkpYcFpu?= =?utf-8?B?YzVicXpRVlM5TGUybjA0Q3IxdHg0UEhyZVdHY1FtTmVjWXdYNFJidE9pd2VE?= =?utf-8?B?SmZ1eTlqcDlvMVI0MEMzZWRPWHpNQzVaVi9kMm5MczFvUGRTVlJ4a3dWWFU5?= =?utf-8?B?MkF1QnU4WkVkenlZSGs3M0psaDVERHQwZGE1YkVicXdIWjlSRWl5UT09?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 4b82834a-c91b-4900-17db-08d9fe3d189e X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Mar 2022 00:14:21.0203 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zSdtGE3qrdEgIS1A0iVlx4pVtoXNyJIpNBsmnTVEeeuOfRGHO9XJ23V2WYTFOR5QM2ZPL90D7xk678Awk0Nx5uqRWHBJcQI9rWnNWi+o01Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MEAPR01MB2614 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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 00:14:28 -0000 True, but Starlink is designed as a high bandwidth, low latency (OK, we=20 won't mention their bufferbloat issues again here), and (currently) low=20 user density service. Bandwidth-wise, good old Shannon and Hartley are agnostic about whether=20 you divide your channel between 1 or a million users. But in real=20 communication systems that need to manage handovers and joining and=20 departing customers, there is a certain amount of overhead involved in=20 managing these, and the protocols used for this generally have a=20 significant footprint in them that reflects the kind of situation their=20 designer had in mind. E.g., since GSM, burst frames have been designed=20 to reflect the designer's expectation as to how many end users a base=20 station would service. I'd be very surprised if this was any different=20 for Starlink. Remember, Starlink's launch and initial target market was the American=20 rural and underserved suburban populace. Pretty much all of them already=20 had a low bandwidth service, it was high bandwidth service they needed.=20 So I'd expect Starlink to be designed around a rather constrained number=20 of Dishy clients per satellite. And yes I think it'd be a good idea to use mesh networks etc. in order=20 to distribute Starlink resource to more people there. But I guess that=20 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=20 >> least for now. As I said, if Starlink can't muster anywhere near=20 >> enough satellite capacity to serve all of a small town in Montana=20 >> that's surrounded by gateways close by, then it's not going to be=20 >> replacing the Internet as we know it in a country 60% larger in area=20 >> and 40 x larger in population. At best it might be able to provide=20 >> some backup in a relatively small number of places. > > It depends on what you set as your requirements. If you are talking=20 > about everyone streaming video, you are correct, but if you talk about=20 > less bandwidth intensive uses, a little bandwidth goes a long ways. > > There's also FAR more of a difference between nothing and low=20 > bandwidth than between low and high bandwidth. > > Telephone audio is an 64Mb stream, without compression, email and text=20 > chat are very low bandwidth. > > 20 years ago, you could have an office of 100 employees living on a=20 > 1.5Mb Internet connection and have people very happy. A single dishy=20 > is 100x this. > > I agree that Starlink is not a full replacement for hard-wired=20 > Internet, and it never will be. But the ability to get that much=20 > bandwidth into an area that doesn't have wired Internet wihtout=20 > requiring special crews to come in and set up the infrastructure (like=20 > you would for geostationary dishes) is a huge step forward for=20 > disaster relief. > > With capabilities like this now available, we (the tech community)=20 > need to look at options to be able to extend this connectivity from a=20 > point source across a wider area (ways to do mesh and have it not=20 > collapse, understanding channnel allocations, sane directional antenna=20 > uses, etc) including how to provide power. > > And also take a careful look at the bandwith that apps are using and=20 > find ones that are sane to use. Since (almost) everyone has phones as=20 > endpoints now, having the ability to put a voip app on the phones and=20 > have them able to call and text chat freely within the connectivity=20 > bubble without any need to use the external bandwith, but be able to=20 > connect out in a fairly transparent manner (think how long distance=20 > calls were something significant 40-50 years ago, but were still using=20 > the same equipment and basic process). Can such apps indicate to the=20 > user if they are talking to someone really local (say sharing the same=20 > wifi), or more remote, so that they can > > How can such apps be made available to the people with phones? (Apple=20 > makes it really hard to side-load apps for example), How can the=20 > services get bundled (raspverry pi or live CD linux images that=20 > provide these services and the app images to download for example).=20 > What can be done with OpenWRT builds to make turnkey conversions of=20 > APs into bandwidth-efficient mesh nodes. This includes how a bit of=20 > 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=20 > to do (and what not to do) in setting these things up? > > David Lang > --=20 **************************************************************** 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/ ****************************************************************