From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 79A1A3CB37 for ; Wed, 31 Aug 2022 02:26:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1661927172; bh=YNYRwB1uTsLwpdRdcbOwdrm2Aux/dOa10uBG6gR49hw=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=RJ2/4zyOMGeePpW674kRXgdSjdUVIpQyQMPI3riREJiAsoJhMZdUDZIsVIqdQdnWb ms4xgoKXBk9yF9DhZM6g23D+TnLF/teEnWnXjgDoRBfkXhtJtycwpMfNvElxxXDPPo 1eAnSNXMzrv3BVftwFquBcOvX+go9+r07j45dkZc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([77.10.137.3]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQMyZ-1opSlR2bFh-00MH2F; Wed, 31 Aug 2022 08:26:12 +0200 Date: Wed, 31 Aug 2022 08:26:09 +0200 From: Sebastian Moeller To: Ulrich Speidel , Ulrich Speidel via Starlink , starlink@lists.bufferbloat.net User-Agent: K-9 Mail for Android In-Reply-To: <15982a40-2b34-7ed1-bfa3-bced03fc3839@auckland.ac.nz> References: <1661878433.14064713@apps.rackspace.com> <6p5n9262-3745-pq31-5636-1rnon987o255@ynat.uz> <20220830220710.GA2653@sunf10.rd.bbc.co.uk> <15982a40-2b34-7ed1-bfa3-bced03fc3839@auckland.ac.nz> Message-ID: <9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:nfUZ0wr4hPn9GNe+EcTLexVj9iRDJ1MdFFvXyYNOjVBnBSUru9N ODsnxahEW0I5uXEG9WNRSMZqlP7Ed3Mor0Xalzgo6feansJzlgpxFT03JhYFrOeMkkPZ0SJ 3+WWB965rD8rwKcdVJkb/OWSSnZF+7o99mihJqgBlcmmIIkc2O9LlUlWB6VA9pJtSWYO09/ Ba6ppiTJwubyFPAv/jjVg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Ybbk53q9lgA=:4p788hgAN42dQCn0uV29kP YDpSVEZGjwGoSHXPreCVAwwu0Y7jPGQvVFakAP/dmdz06saS7LNfmGEjAjWjJgLAcBN8H5jdy kObhpPXziZlZexOTmO09rcL5/OK2FbTQl3+lUGJgkpx4GrqGLl4bOH2bYPZvNCCkiKFvmiaZC 8ZFfLD0WBBYMl0+VGqoYj3cz/d6vBc3UlMGT83aZSX18g6Irjm8J1RbcWKHC535glRuWqG/NC ZUaIxDSQirS0Wbrir7SV69uuvLTGb5ALxDcFgRIywm85ej0xbzRvlTDdfILi5KnFVyo/FRMqi rzvyQ4DzJXD6MvaTnlP/fRoWlahkrZq123sAI3Qe0umxW/0xzDwK7u6RSUVX2luM+RWO3ba29 RdVMsjewOEBqWMbMXHiPCnS+/zxonLzlyX0yKo6SgBGLJm5xtPfJNUPMHLWq/HNv6w5EFKeHR riw4TEP2FYt7l22Bb0zFCACns8QK3rw/CI6UXXVzl3p+/Y2o8bH/2E8umlL5stSlNm2C7lVDc nWy3EopXecppLjei3ujtljElQ/5TE0tN8XKMAJXqqwsGCK3WGBZXe+b3CfQGqNbjirALtP3s9 aI92AS5QnPc9q4OKg8iCstGp4PLfmJ6rRNL3U/bPt+rOLii2hhx7U3lMm85kvXMRgLPg8QIHS mUoZiGW4pqO+Bu8SGxs6kBRTHw/nxJ0nDDvPrlIooX19co5m3rWXIE3dbb/RtgestXdxIIbtb 7X191aAgPi+D7snlHNG9pHPEqHcV4m3iMqdrxg6BiefLBEfY9Ms3UYo2NQSbl0xvlr76jIJKs +MTMxAcFOq9ORrBRMyLg3h4UdNe4Eg57rMWD1tSDbEctOOqT8cSOZ/D0HzRcgDjUxRZ2fHJl/ JRTkfes0/IoZD5ccNGfIwqhVi15s4nRb53w8ln6zvz7OJUk41k/JXPkticnra19jpHvKjqzWk tVj4JqMJW4oiN7hhwtG3ZZDPLkESzov2O2PtR73s2iF5bVk4IqHRwasLe8GECWo+dKCYYX5op a4LvkW4etAevUEXWcoxdOYG65XsmVCINgn31k5Dk4oL0KFW/O0VD4w9rfiD7d9EathJi5FI0j QIhaPod0LBcgIanIPJAMVYvsVji7JEHzDBRJ8F6hr5kcVkHXcn3zeDb/ReQ2ssAX+1BgUn5Q7 uAb68APF7MRWiUED/tL6bLzNYY Subject: Re: [Starlink] Starlink "beam spread" 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: Wed, 31 Aug 2022 06:26:17 -0000 Hi Ulrich, On 31 August 2022 00:50:35 CEST, Ulrich Speidel via Starlink wrote: >There's another aspect here that is often overlooked when looking purely = at the data rate that you can get from your fibre/cable/wifi/satellite, and= this is where the data comes from=2E > >A large percentage of Internet content these days comes from content deli= very networks (CDNs)=2E These innately work on the assumption that it's the= core of the Internet that presents a bottleneck, and that the aggregate ba= ndwidth of all last mile connections is high in comparison=2E A second assu= mption is that a large share of the content that gets requested gets reques= ted many times, and many times by users in the same corner(s) of the Intern= et=2E The conclusion is that therefore content is best served from a locati= on close to the end user, so as to keep RTTs low and - importantly - keep t= he load of long distance bottleneck links=2E > >Now it's fairly clear that large numbers of fibres to end users make for = the best kind of network between CDN and end user=2E Local WiFi hotspots wi= th limited range allow frequency re-use, as do ground based cellular networ= ks, so they're OK, too, in that respect=2E=C2=A0 But anything that needs to= project RF energy over a longer distance to get directly to the end user h= asn't got nature on its side=2E > >This is, IMHO, Starlink's biggest design flaw at the moment: Going direct= to end user site rather providing a bridge to a local ISP may be circumven= ting the lack of last mile infrastructure in the US, but it also makes incr= edibly inefficient use of spectrum and satellite resource=2E If every viral= cat video that a thousand Starlink users in Iowa are just dying to see lit= erally has to go to space a thousand times and back again rather than once,= you arguably have a problem=2E Why? Internet access service is predominantly a service to transpo= rt any packets the users send and request when they do so=2E Caching conten= t closer to the users or multicast tricks are basically optimizations that = (occasionally) help decrease costs/increase margins for the operator, but I= MHO they are exactly that, optimizations=2E So if they can not be used, no = harm is done=2E Since caching is not perfect, such optimisations really are= no way to safely increase the oversubscription rate either=2E Mind you I a= m not saying such measures are useless, but in IAS I consider them to be op= tional=2E Ideas about caching in space seem a bit pie-in-the-sky (pun inten= ded) since at 4ms delay this would only help if operating CDNs in space wou= ld be cheaper than on earth at the base station or if the ground to satelli= te capacity was smaller then the aggregate satellite to end user capacity (= both per satellite), no?=20 Regards P=2E P=2ES=2E: I think the same applies to GSM/LTE/5G basestations, as far as I= can see 'edge' servuces (storage or compute) are interesting options for I= SPs to offer higher ARPU products than commodity IAS, and not things requir= ed for a functional internet=2E Again nothing bad about offering such servi= ces, just they are optional=2E > >And yes, small neighbourhood networks of the type Mike described could pu= t a significant dent into that problem=2E But do Starlink actually see Mike= supplying 100 people as helpful, or do they see it as 99 customers they ca= n no longer sell a dishy to? Given how they push their services into the ma= rket, I suspect it might be the latter=2E > >On 31/08/2022 10:07 am, Brandon Butterworth via Starlink wrote: >> On Tue Aug 30, 2022 at 02:01:49PM -0700, David Lang via Starlink wrote: >> > You are absolutly correct that people who can get fiber (and probably= even >> > most DSL) are far better using that than Starlink, and >> > last-few-hundred-meters wireless can be better (like DSL, it depends = on the >> > exact service available) >> =2E=2E=2E >> > People who can get that sort of service are not the target users for >> > Starlink=2E >>=20 >> But unless Starlink turn them away some will still take the >> service despite better options=2E >>=20 >> I do UK FWA and FTTP in rural areas and know others in the >> industry=2E Some have reported being turned down as the >> odd customer is waiting for Starlink (instead of taking a >> government GBP4k+ subsidy giving them free fibre/FWA install) >>=20 >> There's no telling some people=2E >>=20 >> brandon >> _______________________________________________ >> Starlink mailing list >> Starlink@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/starlink > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E