From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.onholyground.com (mail.onholyground.com [204.130.133.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1757A3CB37 for ; Thu, 4 Nov 2021 21:27:13 -0400 (EDT) Received: from smtpclient.apple (castleinthewoods.onholyground.com [204.130.133.5]) (authenticated bits=0) by mail.onholyground.com (8.14.9/8.14.4) with ESMTP id 1A51R6RT027488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 4 Nov 2021 20:27:07 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Darrell Budic In-Reply-To: <4ea38008-0e62-1cad-165a-a8aad232ebd6@cs.auckland.ac.nz> Date: Thu, 4 Nov 2021 20:27:06 -0500 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <5F050284-7760-4595-AC01-2A9695409D7F@onholyground.com> References: <7907F9D1-9511-4254-BD8F-701888EB6778@onholyground.com> <4ea38008-0e62-1cad-165a-a8aad232ebd6@cs.auckland.ac.nz> To: Ulrich Speidel X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.onholyground.com [204.130.133.20]); Thu, 04 Nov 2021 20:27:07 -0500 (CDT) X-Spam-Checked: This message probably not SPAM (-2.909) X-Spam-Tests: ALL_TRUSTED,BAYES_00,LONG_TERM_PRICE,SO_PUB_URIBL_NS_40,TXREP X-Scanned-By: MIMEDefang 2.84 Subject: Re: [Starlink] Starlink tidbits from NANOG 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: Fri, 05 Nov 2021 01:27:13 -0000 > On Nov 4, 2021, at 7:34 PM, Ulrich Speidel = wrote: >=20 > Thanks for that Darrell - that's really interesting! A few comments on = that front: >=20 > On 5/11/2021 4:26 am, Darrell Budic wrote: >> I was at NANOG in Minneapolis, and got a chance to ask a couple = question of a Starlink Network Engineer who=E2=80=99s attending. I was = already talking to him about Starlink=E2=80=99s network efforts (see = below) but it was nice to meet in person. Don=E2=80=99t quote me on any = of this, but here=E2=80=99s a few tidbits this list may appreciate: >>=20 >> - Starlink is expanding their own network operations, and is = connecting to more IXPs. They were already on SIX in Seattle, have = connected to DECIX NY, and are in the process of connecting to ChIX in = Chicago. As I run ChIX, I had a good excuse to talk to them about other = things. :) IXPs and their own networks are in the works for Europe and = other areas as well. > Makes sense. >> - They have been obtaining more v4 addresses, but I don=E2=80=99t = know if they have enough to not do CGNAT. I don't think they do yet, but = it seems like it may be a long term target. >> - v6 is deliberately not fully functional, but they know some of use = are using it and it will eventually be fully activated. May be waiting = on the regional connectivity, so will be intersting to see if changes = for some areas and not others as they roll it out. >=20 > So I guess we need to distinguish between: >=20 > - IPv4 addresses for any CGNAT they might run > - IPv4 addresses as static addresses for (some of?) their customers > - IPv6 addresses as customer addresses > - IPv6 addresses to support geographic routing as discussed in earlier = posts (subnet maps to cell / satellite) >=20 > There are quite a number of feasible configurations in this. E.g., = they could be running a CGNAT setup with a v4 pool on the Internet side, = use v6 to tunnel route from there to the satellite the end customer = connects to, and then map that customer back to a (private) IPv4 address = in a NAT on the satellite. One aspect that hasn't really been mentioned = much here is that of PDU size on the link between end customer and = satellite. Keeping Dishy and its successors small and cheap creates an = incentive to operate at marginal SNR, and this favours smaller PDUs over = larger ones as the probability of PDU checksum errors increases with PDU = size. But having lots of small PDUs means having lots of headers, and as = IPv4 addresses are leaner than IPv6 ones, this saves bandwidth here. = Probably not a biggie though. =E2=80=9Cv6 deliberately non functional=E2=80=9D as in they havn=E2=80=99t= enabled radvd, not that they=E2=80=99ve broken it, btw. I=E2=80=99m = thinking they=E2=80=99ll move to enable v6 fully, and continue to CGNAT = the v4 for non-commercial customers. If they can enable routing or = tunnels for commercial customers, the customers could likely bring their = own v4 ranges. Effectively what I=E2=80=99m doing right now with some = simple tunnels... >> - New ground stations with more capacity are coming (and will be = upgrades).=20 > Any word on where? At the moment, most of the world can see Starlink = satellites, but most Starlink satellites can't see a ground station. I got the impression it will be new stations to increase density, = especially at lower latitudes, but also would be ongoing upgrades for = existing POPs to allow the new satellites to take full advantage of = their upgrades as well. >> They are using waves back to regional DCs now, but will be moving to = dark fiber over the next year or two > If that means "radio" waves, then this goes a long way to explaining = why there's already limited capacity even near the US-Canada border. >> - the new satellites have more than 2 lasers, and there is enough = capacity on them to do routing. no details on how or what protocols, = alas > Any word on when we can expect to see routing in action? Sounded like they expected to start testing after another launch or two = (three?) of the upgraded sats, so 4 months maybe? Doesn=E2=80=99t seem = like a set schedule as they will like test once they have enough = capacity, then move to enable as they go. >> - new birds also have 2-3x more ku bandwidth than first gen > Hm. Sounds cool, but with 3 billion or so underserved on the planet & = typical annual growth rates, that's still just a drop in the bucket. >> - new dishes are in the works, v4 coming with lower power use, more = capacity, not round any more > Trayee? Squary? Just joking ;-) Haha, Rectangly apparently. More in line with the size of their phased = array antennas and also to lower cost. I imagine it will look a lot like = some of the existing IPTV panel receivers. >> - larger dishes coming for commercial apps > That's good news, as this will allow Starlink to be used in places = where direct-to-site crashes into regulatory hurdles. If we can get the = big CDN providers to come up with small (virtual?) appliances that can = be put at the remote end of such links by local ISPs, then that'll also = help to preserve space segment capacity. Sounds like they have some regional =E2=80=9Csuper pops=E2=80=9D where = they can locate todays standard CDN cache services, but they want to try = and peer as much as possible for it, both public and private. But = emphasis on public up front, especially as they are still trying to get = a good handle on the kind of traffic people are pushing over them. >=20 > --=20 > **************************************************************** > Dr. Ulrich Speidel >=20 > School of Computer Science >=20 > Room 303S.594 (City Campus) > Ph: (+64-9)-373-7599 ext. 85282 >=20 > The University of Auckland > ulrich@cs.auckland.ac.nz > http://www.cs.auckland.ac.nz/~ulrich/ > **************************************************************** >=20 >=20 >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink