From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00559701.pphosted.com (mx0a-00559701.pphosted.com [205.220.164.59]) (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 EFBE93B29E for ; Sat, 5 Mar 2022 10:25:12 -0500 (EST) Received: from pps.filterd (m0210274.ppops.net [127.0.0.1]) by mx0a-00559701.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 225CTIgC003725; Sat, 5 Mar 2022 15:25:06 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2047.outbound.protection.outlook.com [104.47.66.47]) by mx0a-00559701.pphosted.com (PPS) with ESMTPS id 3em0s9rbne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 05 Mar 2022 15:25:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fUtzc6HD0BblhkXj8a2H08iqGBMumBzB0A/Tee00e4o+K3KP9pbVFdG+3HedAyz9vG1FkJ3ak7ROaz0sggHqZhFRr2acdisCWbFqeT/CyoUo4FdnzJSS6U6t7GZRjQDz3BViaaIxa4uL/a0IRnQh9DTTaH4+OiItn06EDg7LIbwsFfEByuTKcRNQXIQT91wXep7d/OSF3Jfg4qdZBTTN+gSONIc+ytVgA/s3A8SHJVxyWpiUs4JfFmnr6X3VOnBHMaZ4cVDbe06nLRh6vePqEn2qkFbn2Novpv/0B054X42drg/scmRLJ0d65Ne70TYLhRuJcif0YsVq7yodVHBJ4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jmUs0iYx+gzhfmsUd0hRpgaViTiE1pIv1O6eanaWvNw=; b=ZasBLfn+Sn9Atb8LXqnS8xFPDDjG8UcbedfDSr96IQP8faTwXwkKmX5yQmRUIUJSsDrjng6Dur6fLQ9VX5+jgQp7lwnmQtDPSgd3TeNhhAM+44fAJ9V+l3FhoYPDwQS4RsmTQsRUWREEv9LCe/1bqihlGLgbpVq3ZJJw9TrckUdGWnjFl4D5xttfQ0lACnBL09d4KYf4yfxMNTfewfNNgM9M9ELFfY2+NOtTzyi7YDhqygeZzCcEha5OvZxGofgobKh/2FehB6L50WeITuQ4J2Z0UBbuMwu2YzbGf4H+Fq4x6rsPyxf4tEdQ8p/veT4NN4i0XRNse/AkhiC5AowJUg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=csudh.edu; dmarc=pass action=none header.from=csudh.edu; dkim=pass header.d=csudh.edu; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=csudh0.onmicrosoft.com; s=selector2-csudh0-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jmUs0iYx+gzhfmsUd0hRpgaViTiE1pIv1O6eanaWvNw=; b=AEmuByj2/jcKCP57BMTiONriPtJg0S/mkzrW4jZaSG2iW1LI1UlLI3twgeSIcQRoDk3rYvfZ8rZVXh3pNMMkRoedvJXru96rCYpfPinsIs44DvuWk/ZfY1I1+p5V+JJGg4fPkSD7kMwa4CRAnh3KIKrUn3zDj6T8YJP6R1LXKbs= Received: from BYAPR03MB3863.namprd03.prod.outlook.com (2603:10b6:a03:6a::30) by BN9PR03MB5963.namprd03.prod.outlook.com (2603:10b6:408:134::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.14; Sat, 5 Mar 2022 15:25:03 +0000 Received: from BYAPR03MB3863.namprd03.prod.outlook.com ([fe80::3d8d:c96c:e59d:2154]) by BYAPR03MB3863.namprd03.prod.outlook.com ([fe80::3d8d:c96c:e59d:2154%5]) with mapi id 15.20.5038.016; Sat, 5 Mar 2022 15:25:03 +0000 From: Larry Press To: Ulrich Speidel , David Lang CC: "starlink@lists.bufferbloat.net" Thread-Topic: [Starlink] Starlink Digest, Vol 12, Issue 6 Thread-Index: AQHYL1kLaUiYXQQE0E2ywxHUB1/xOayurGOAgAAf3ICAABxyAIAAEXQAgACOjQCAAGSFgIAAM4iO Date: Sat, 5 Mar 2022 15:25:02 +0000 Message-ID: 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> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: df39c12a-e22e-285e-ff65-a7212321045c x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b58f763-d076-43a4-993c-08d9febc51df x-ms-traffictypediagnostic: BN9PR03MB5963:EE_ 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: BKNSLpkESSxWnObJDT6/oGeXiPkPn9fycCIInGEmS3484VGoTK/pcPVW7uNUAPeRbP/VFcsJQPSjt7aIz0qNgJOJw0oIbapOaHIZGBYuirVGZJx5wqwhJlrEtgLnwWze6tLl2AVlJqOoe0D0pUTS8X7XCgkK8yv+yrF8cx13RU/5WsD9KHF65i771Y430RTvRmNeaH03geydZpzekaDblk4NzzrtfqSbANAVLtCzhVInmtzZEb3wELUn7tNdl1g6AETqt6BkuCDplcrcZblQ9v7Mj8VvDuM6XZD8WZYytbBXxw1oQ5CQ8M+PG53iuneUum79y9cfzSpDPs7QHQHGDNQVe8EbrsLrO9pIR4Bp/6e0769ii2YH6+73gDxxLv9Rh/kvnQENdRxtTqqVJifztM8S7+NN8j0ajBirDBAo8zFm3YiOUPOy8HrST2p+Qzodn6Jng3s43oqQ6+gnT2M+tvRCf5qG37pSHEMTrhmrZTSVqo9m81MAo9UX0lB8jtLyIkTGE7ZIj/HYQKMzFeRBulHxSbt6G11RqnfSlMJHPvRk30T0fMjvTPrVymMtkAwLCiCQ4vnjDY1cGBLbeI4AakXaknT/FkCtJPAydXwcoUJ5qKpiOFr29UO6oDMN5CeWmoFAvfxQSkzXrhy/i5R4B12U/CfrUXjfzlvmo1pXD8KqFjI1GplHR3ALnHsQpKesB2OJUoSPiQCXcs6Wn18nyR0hFMILGlXVcyvjZUuugyAp2EK3pbMUqr9tmsZKjTE53+R+Jm56ArU0IgKYNizYj1XgmfxkAOCF5gDOQR/jht0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR03MB3863.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(55016003)(2906002)(508600001)(9686003)(786003)(316002)(166002)(186003)(71200400001)(75432002)(38100700002)(66574015)(38070700005)(110136005)(5660300002)(4326008)(76116006)(53546011)(122000001)(19627405001)(7696005)(6506007)(966005)(66476007)(83380400001)(64756008)(66446008)(8676002)(66946007)(86362001)(52536014)(66556008)(8936002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?WusMm612Jg2YSpMYOfmD0vFT6VeuyHKdHho0VE8sJRwca2Dp9GtFkzBDBG?= =?iso-8859-1?Q?z//tVDl5n1xYntjR7dKnY8cdB39EWHDz0AWMHZRipKGtF2iwOxclwUnCqz?= =?iso-8859-1?Q?l++lkXg8sTvbIuX8Hxq8M8XW2nBBlCag71RH4F3b9zTvALkL6htpFzZRQd?= =?iso-8859-1?Q?53rXSxzZz49/FoIFqgLUevM/Pda9e8N9ihfJ5y+/9vGDsvqxD4oxEL63pj?= =?iso-8859-1?Q?SLYP5421GDfBdCVjHNQ6+OsglYQci4puKw29iO3g+DRU7330C2YSvboAlr?= =?iso-8859-1?Q?v+pJwb4xejKWi59VF1jtTNSiTWG4Njy2BKs4zbKXxzyWGPkrhawLsILjpb?= =?iso-8859-1?Q?nR7kivrlLcMO1AsyXFUBjWmMC2X7EzHcfGvwKHPmk6a0PXX73IZ7ml9OHX?= =?iso-8859-1?Q?QfxQHEszPaQ85N28FGfaBybY7F+M2Ea6oulh7sD5hkkUD+b73x5/upzPta?= =?iso-8859-1?Q?1rYi4S1iLgYeg/5VNqKQCaHBVtb+x/ZYdOYz28KmaJ4ybXV/0+zinc36IK?= =?iso-8859-1?Q?WkLlCIjePAl03tQbvfCOe1oCcw9EseMCCsWDslb943Cd6Crd7+pG/qKihB?= =?iso-8859-1?Q?EroOe05JBgyEXMqzzI5Fch3WAYsk3mtQ4lNC/KsmdJv2gsCuYoQxZbYJen?= =?iso-8859-1?Q?SGC54LRDcYW5WPqSp+cHn+0uXSn/w0gl+lKVLCauW2vt8rkCY2C/OwbSo7?= =?iso-8859-1?Q?vUixGNed6ZnfDCxB05r1GOsi9AqnVGP+BGxCMy1pUKl7cwyuwsQjowPCai?= =?iso-8859-1?Q?JFGeODhI73uOwagJxRdTWUmOijj3pt/BVTNE6hqLw5yX9a7LnFK+lj6Qii?= =?iso-8859-1?Q?nKK/hury3iGsucXPa1b5HvJ7LFL/k4eotGqjYsz5KDVCl1vfpz6eFA8JmO?= =?iso-8859-1?Q?RDL9dPrCiBKsKmMh/zXSS95kFfTcByhWMXaJ56xCRO1CWB0TjV3mIGAmrE?= =?iso-8859-1?Q?m4bo8P93U+iBMCuUbPzPVhCOTsbsB0/DBXQJnR1bowgXjo2at5Xrl4LcIE?= =?iso-8859-1?Q?IDnc3YcetdEtCQm1ZyFXXaY9BdCIZO0oHNFgbBfQ2yK0RA+yxCGwIi4YcZ?= =?iso-8859-1?Q?EO4yoaPyX9uCPx9fGpAyT1jOFAszTkQzUwIkiW2Xdge6FQbyUIFDHsIC+4?= =?iso-8859-1?Q?WTpEzjPEv6p77vYgyYqeRChNAxtbBAutRlPmhpIqHXPekjJa67QdIMUMbC?= =?iso-8859-1?Q?yRFVmBl5okS3oC6Sr3VCTssApxxxeuSmbXEAL4+T7pFqvVAF2ZPAace7ot?= =?iso-8859-1?Q?qq+OTVhrTxmEZgDEQPQbFzQEKHJlviby6UUR4gL1CUR/xbQJcfVM4XJciJ?= =?iso-8859-1?Q?yYSxmupSU3J0swyQhVKVtTe7TkUmho+PX8H7OwM8fL0aYNBdP7QdGL54Pg?= =?iso-8859-1?Q?D9REEiR+xsz847a3qrvUOwg42+eLczV7UwPx0Cwd0SCwQIISPt17Ax5h8A?= =?iso-8859-1?Q?LhbVIWuo7whCtES6kL4YZjVgWlzIG5FkRFfjqwi7ORZYM1BVGIK4gO1G8O?= =?iso-8859-1?Q?iHqnybV/mWDIa1MYFyhNSAUq2J0POzs2enjcpJcVGxRHTWWYJvWiFneOCh?= =?iso-8859-1?Q?m1Rxkl86LmtVU/5qaFwjygJqxt+SFR0tnSwOFCRzijmVJdlUzedj8jsfa5?= =?iso-8859-1?Q?yyTqx7SH6KbbiozKhO4JOla66vg5PRAEuiezgU2e1BD7FcKa/sScRO2Ukt?= =?iso-8859-1?Q?vUjSV8Ny/DQf+bE1qsfW1TEDY9DWD+5dtCR5v8WM23S0Tcl9wc7DqWhosl?= =?iso-8859-1?Q?IyLQ=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BYAPR03MB3863776265643B78B2778337C2069BYAPR03MB3863namp_" MIME-Version: 1.0 X-OriginatorOrg: csudh.edu X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR03MB3863.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b58f763-d076-43a4-993c-08d9febc51df X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2022 15:25:02.9457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 1a66a727-7389-4727-a8cb-f249ac8e7ff8 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: shSFIVMDehPZiZpylYXYft98tYSsNUPxuo8Di9mOuU9yiT62+MHimWkYoNf6F5As2/f1gBVUhPPw0LdsD+x4Sg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR03MB5963 X-Proofpoint-ORIG-GUID: VsXSG60p3DencLmqhourGgMI7CXLBST- X-Proofpoint-GUID: VsXSG60p3DencLmqhourGgMI7CXLBST- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.64.514 definitions=2022-03-05_05,2022-03-04_01,2022-02-23_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 suspectscore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2203050087 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 15:25:13 -0000 --_000_BYAPR03MB3863776265643B78B2778337C2069BYAPR03MB3863namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > But that's exactly the situation that would make it a party to the confli= ct and its user a target. How many terminals do you think they have and who -- which class of person = -- do you think has them? I understand the users would be targets, but it will be difficult to locate= terminals in the hands of a few people who are able to move around a 233,0= 00 square mile country. Furthermore, the terminals will not be transmitting= continuously, and they can be a distance from the people using them. The benefits of being able to communicate seem to outweigh the risk of dete= ction and destruction. Furthermore, finding and destroying a terminal would= cost Russia a lot and the Ukrainians would still have n-1 terminals. ________________________________ From: Starlink 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. 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. 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 https://urldefense.com/v3/__http://www.cs.auckland.ac.nz/*ulrich/__;fg!!P7n= kOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaR= bKLFMR0TZ1A7RFMULV$ **************************************************************** _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://urldefense.com/v3/__https://lists.bufferbloat.net/listinfo/starlink= __;!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQ= mBrxlEaRbKLFMR0TZ1A-oFbS8W$ --_000_BYAPR03MB3863776265643B78B2778337C2069BYAPR03MB3863namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> But that's exactly the situation that would make it a party to the conflic= t and its user a target.
a 233,000 square mile country. Furthermore, the terminals will not be transm= itting continuously, and they can be a distance from the people using them.=  

The benefits of being able to communicate seem to outweigh = the risk of detection and destruction. Furthermore, finding and destroying a terminal would cost Russia a lot and= the Ukrainians would still have n-1 terminals.
From: Starlink <starlink= -bounces@lists.bufferbloat.net> on behalf of Ulrich Speidel <u.speide= l@auckland.ac.nz>
Sent: Friday, March 4, 2022 4:14 PM
To: David Lang <david@lang.hm>
Cc: starlink@lists.bufferbloat.net <starlink@lists.bufferbloat.ne= t>
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. 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.

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 <= br> >> 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 ar= ea
>> 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 <= br> > 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 <= br> > 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 <= br> > 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 <= br> > 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
https://urldefense.com/v3/__http://www.cs.a= uckland.ac.nz/*ulrich/__;fg!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZFz3zZe-9hdDlsCjcS= c6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A7RFMULV$
****************************************************************



_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://urldefense.com/v3/__https:/= /lists.bufferbloat.net/listinfo/starlink__;!!P7nkOOY!phUrdzfjr6YUdNCfv4tjZF= z3zZe-9hdDlsCjcSc6gmEZDF7mfjlgKK1uZU2tMQmBrxlEaRbKLFMR0TZ1A-oFbS8W$
--_000_BYAPR03MB3863776265643B78B2778337C2069BYAPR03MB3863namp_--