From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8EBD93B29D for ; Sat, 13 Jun 2020 01:43:18 -0400 (EDT) Received: from dlang-laptop.LAN (dlang-laptop.LAN [10.2.0.162]) by mail.lang.hm (Postfix) with ESMTP id 51D1CBAB1B; Fri, 12 Jun 2020 22:43:17 -0700 (PDT) Date: Fri, 12 Jun 2020 22:43:17 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang-laptop To: Michael Richardson cc: David Lang , "David P. Reed" , Jonathan Morton , bloat In-Reply-To: <12673.1591976376@localhost> Message-ID: References: <1591891396.41838464@apps.rackspace.com> <1591901205.85717618@apps.rackspace.com> <1591902977.45963161@apps.rackspace.com> <12673.1591976376@localhost> User-Agent: Alpine 2.21.1 (DEB 209 2017-03-23) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Subject: Re: [Bloat] FW: [Dewayne-Net] Ajit Pai caves to SpaceX but is still skeptical of Musk's latency claims X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 05:43:18 -0000 On Fri, 12 Jun 2020, Michael Richardson wrote: > David Lang wrote: > > my point is that the if the satellite links are not the bottleneck, no > > queuing will happen there. > > It's a mesh of satellites. > > If you build it into a DODAG (RFC6550 would work well), then you will either > a bottleneck at the top of tree (where the downlink to the DC is), or you > will have significant under utilitization at the edges, which might encourage > them to buffer. > > Now, the satellites are always moving, so which satellite is next to the DC > will change, and this quite possibly could be exploited such that it's > always a different buffer that you bloat, so the accumulated backlog that > David P spoke about in his message might get to drain. > > But, the right way to use this mesh is, in my opinion, to have a lot of > downlinks, and ideally, to do as much e2e connection as possible. > Don't connect *to* the Internet, *become* an Internet. > That is, routing in the satellite mesh, not just creation of circuits to DCs. realistically, the vast majority of the people who have the mobile endpoints are going to be talking to standard websites and services, and those are going to be on the Internet, not on starlink nodes. 'normal' traffic is highly asymmetric, but the radio links do not seem to be, so you can have a lot of mobile units talking to the Internet on a smallish number of downlinks without having a bottleneck in the 'upstream' direction from the mobile units. it's the replies that are far more likely to be a problem (the 'downlink' direction as far as the user is concerned), but they don't have to do anything super special there, if they just turn on fq_codel on the uplink routers between the Internet and the satellites, it will do a good job of managing that link. Is it possible to saturate that and run into grief? sure. It's possible to oversubscribe any service. But it's also possible to run a service without oversubscribing it. > Anything less, and it's just a faster Iridium. > > > I expect the queuing to happen at the internet-satellite gateways, which is > > much more conventional software and if they do something sane at the gateways > > it will address the problem for pretty much everyone. They don't have to > > implement anything special on the satellites. > > > and if he is promising good latency, but there isn't good latency, it isn't > > going to be swept under the rug the way incumbant ISPs were able to. > > I would expect to use SDN to create virtual satellites which appear to be > "stationary", and then do routing on top of that. I expect that it will be more dynamic than that. given that there could be mobile stations anywhere, creating virtual satellites is going to be a poor choice for many locations. I expect it will be something along the lines of each satellite has a ongoing broadcast of how busy it is and the ground stations send based on this. do I expect them to get it right immediately? no. but SpaceX has a need for good communication in odd areas (like their recovery ships and their spacecraft), so when they do run into grief, I expect them to fix the problem fairly quickly, not pretend it isn't there. Remember, Musk already sacked the starlink leadership once for being to stuck in 'the way satellites are always built' so if it doesn't work well under load and they can't fix it, he will find people who can. David Lang