From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1.bemta32.messagelabs.com (mail1.bemta32.messagelabs.com [195.245.230.65]) (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 99EB73CB37 for ; Wed, 31 Aug 2022 05:25:44 -0400 (EDT) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRWlGSWpSXmKPExsXSsnPBFl0xTf5 kg2V7dS2WXLS1WLt4C6vFg2+TmR2YPX7/fsjo8eFjnMf2i2eYApijWDPzkvIrElgzLt7bx1hw Qrii8VBEA2OrQBcjJ4eQwE5GiWP7AiHs5YwSs97ldjFyAdmnGSXefD3CBOE0MEocvjKLHaSKR UBV4mLrdVYQm03AQGLiz39sXYwcHCIC6hLLmuVBwswCxRKfG+Ywg9jCAnoSN9uXs4CU8AqYSz QdVYEYOZlZYu2uViaIuKDE3x3CEK1aEjf+vQQLMwtISyz/xwFicgpYSVyYkjWBkX8WQv0sJPW zEOoXMDKvYrRKKspMzyjJTczM0TU0MNA1NDTVNdA1MjTVS6zSTdRLLdUtTy0u0TXUSywv1kst LtYrrsxNzknRy0st2cQIDOGUYobrOxgn9v3UO8QoycGkJMpby82fLMSXlJ9SmZFYnBFfVJqTW nyIUYaDQ0mC95cKUE6wKDU9tSItMwcYTzBpCQ4eJRHeaJA0b3FBYm5xZjpE6hSjopQ470xxoI QASCKjNA+uDRbDlxhlpYR5GRkYGIR4ClKLcjNLUOVfMYpzMCoJ88qqAU3hycwrgZv+CmgxE9D ih0u4QRaXJCKkpBqYZvwL4XdN7Ot8cFSNbd2l/eL/++7oHvbhC05KMbmdZeffIKCWKSAZoZr1 w6b00/sSs2Ox0Tc1Ey/c2W5w82Xqry88xrNM93xesXwe49Zp+5c0tH/ac6JQmOveyeuPb2aJC i68nOab9CG58GTVjy5GmQ+l0mkb7H8m6T/3etjxepYbb6pJxoUXXFOuhp7YVXw0n2nxXRvuDb d15e7oJGxzVDFUXnR9+oyGN903LpV8zMpZJXboQoijpeEi18ClBh79qX4W73TF5JsrItZemao cnz11T5uqXWPDO7PTdXsWf3y+0anwH5/Q70mnn5+b38jb+vHruZQt1qm7W8tTD8gc5ii4wqw1 W2alE0NdquFZJZbijERDLeai4kQAIuA1mFwDAAA= X-Env-Sender: brandon@rd.bbc.co.uk X-Msg-Ref: server-15.tower-581.messagelabs.com!1661937942!2180!1 X-Originating-IP: [132.185.160.180] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.87.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14437 invoked from network); 31 Aug 2022 09:25:42 -0000 Received: from mailout1.cwwtf.bbc.co.uk (HELO mailout1.cwwtf.bbc.co.uk) (132.185.160.180) by server-15.tower-581.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 31 Aug 2022 09:25:42 -0000 Received: from gateb.lh.bbc.co.uk (gateb.kw.bbc.co.uk [132.185.132.11]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id 27V9Pgvn009872; Wed, 31 Aug 2022 10:25:42 +0100 (BST) Received: from mailhub1.rd.bbc.co.uk ([172.29.120.129]) by gateb.lh.bbc.co.uk (8.15.1+Sun/8.13.6) with ESMTP id 27V9PgRx019661; Wed, 31 Aug 2022 10:25:42 +0100 (BST) Received: from sunf10.rd.bbc.co.uk ([132.185.128.110]:37943) by mailhub1.rd.bbc.co.uk with esmtp (Exim 4.92) (envelope-from ) id 1oTJyf-0007GC-Vx; Wed, 31 Aug 2022 10:25:42 +0100 Received: (from brandon@localhost) by sunf10.rd.bbc.co.uk (8.9.3+Sun/8.9.3) id KAA10551; Wed, 31 Aug 2022 10:25:41 +0100 (BST) Date: Wed, 31 Aug 2022 10:25:41 +0100 From: Brandon Butterworth To: Sebastian Moeller Cc: Ulrich Speidel , Ulrich Speidel via Starlink Message-ID: <20220831092541.GA9165@sunf10.rd.bbc.co.uk> 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> <9CE05D69-FC37-4C97-9D8D-D46B2DF6DE16@gmx.de> <2321be3b-957f-2d1f-c335-119c8e76efe5@auckland.ac.nz> <23E930C0-23A5-4ACC-BAB7-D057CD2D8572@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23E930C0-23A5-4ACC-BAB7-D057CD2D8572@gmx.de> 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 09:25:44 -0000 On Wed Aug 31, 2022 at 09:49:50AM +0200, Sebastian Moeller via Starlink wrote: > +1: I agree with that assessment. What could work (pie-in-the-sky) is if > the base station control the CDN nodes, they could try to slot requests > and try to see whether concurrent transfers of the same content could > not be synchronized and the unicast silently converted into multicast > between base station and dishy. Access to a good enough aggregation point is hard With DSL aggregation, via PPP/L2TP to a few central gateways flattening any cdn/multicast down to unicast for a large part of the network, limited how far into the network we could embed our CDN. Mobile has similar aggregation issues hence eMBMS, we did some work in 3GPP to extend that to provide a single shared service between operators so only one set of spectrum was used. It still didn't create enough capacity vs the demand to make it to deployment yet. With Starlink capacity being multiplexed per Dishy and uplink and downlink capacity equal on each satellite there doesn't appear to be any sharing gain to be had there warranting a CDN in space. We explored the same situation with the Avanti geo stationary satellite the last time satellite internet was popular. Options for Starlink growth are probably not disimilar to 5G - more MIMO and spectral efficiency. If that gives a satellite more capacity to Dishys than to ground stations a CDN could be included to make use of it, probably a single shared CDN (though carrier CDNs didn't go well in DSL days and as with mobile edge compute the opportunity to charge for it may limit take up). I'm assuming there is no scope for shared capacity to all Dishys permitting something similar to eMBMS, is that true? Do satellite to satellite links change the balance to make a CDN more likely with the opportunity to upload from less busy regions, or through cache to cache traffic (content is often geo limited so satellites could hold some content pools above a certain geo areas allowing cdn storage re use)? > But I have no intuition whether that kind of synchronicity is realistic > for everyting but a few events like a soccer world cup final, a cricket > test match I suspect that may be the case. Such GEO limited content complicates matters. We made our CDN available as a VM which some operators have deployed on their own hardware (a sort of carrier CDN light) so in theory it could sit on a Starlink satellite but how many CDNs could they support, just Netflix? brandon