From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.21.117]) (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 8F2343B2A4 for ; Sun, 16 Apr 2023 18:42:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681684931; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jp+PolWcAbSdqfPogmLrRuFVvR8ybzzrNM6AO4hNrUU=; b=NMdhI3PMhZOCkRGrIonatxYAri//a2Pv47k631iiYJX1xfLEkj6duhLeQ6szqhgxq0UZyM 4iaYRAG98s0b/OMeMa/U6M60hjIPvHMXpQCe/DgiABX+dR0gXHClz5v83u1W5pzieolBRn ZHqLM1QQ0H0h3OObIwD7uL491h9mK3A= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2234.outbound.protection.outlook.com [104.47.71.234]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-59-IEf8VsX9MVS35_5tUp1DLQ-1; Mon, 17 Apr 2023 08:42:08 +1000 X-MC-Unique: IEf8VsX9MVS35_5tUp1DLQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SY4PR01MB6171.ausprd01.prod.outlook.com (2603:10c6:10:10d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Sun, 16 Apr 2023 22:42:07 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::8ab6:3d14:f4e:6fa2%7]) with mapi id 15.20.6298.045; Sun, 16 Apr 2023 22:42:07 +0000 Message-ID: Date: Mon, 17 Apr 2023 10:42:02 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: David Lang CC: starlink@lists.bufferbloat.net References: <83qps6or-4574-n64r-6r95-71sp695q58p4@ynat.uz> From: Ulrich Speidel In-Reply-To: <83qps6or-4574-n64r-6r95-71sp695q58p4@ynat.uz> X-ClientProxiedBy: SYCPR01CA0017.ausprd01.prod.outlook.com (2603:10c6:10:31::29) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SY4PR01MB6171:EE_ X-MS-Office365-Filtering-Correlation-Id: cff201fc-ab93-4296-d3eb-08db3ecbceb9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: SpacgBIwEcc/ukQFukajED1mUy/t5brNiw+vRLvRc74pMCsFd3rKz4YFhOUReOT8HnZqqUBwr+kGEVL/QY93WzIWVlLGFPkKV/FX7SjOHlCa8XyI/m6Fb8LqbKcTh1v6LMErYdwhHXc4EFWZ0TOI80KPlBgqdfpiduWw/A3owDg7s8i7tx2gXTt9mYa+Qb4PzOhEVyQjsFXb2ofGWlaYNdgPM1o5awQ68otKtvsG8rR6LpEuBsZLY664q+Y0DF3Nsan0jKSnA44EHyP/Z7H+c2DZO4G3us8/gNjaflPmB6I9WsJv75BWl2EBZ3rfL95PEshw6Ojjq+V63XRKuIBSzJXkdOxsAWBPleuX7gTBs9gYQE5JJ0kgzVpGULp2ZalMxSrqIUEuiS6i0GMBoLQIx0rkECuJHnMo4R8o/8cWu9c9MbydjuN+4BJZNdfU6sDjzChqCHhluPDDTqdl3DrFLJMmUrAgXe47JwtWk06/1xvHkRS0vkNfPEFYPyPrM0pZ9Y8m5TJN6lT4BdMvR8dOxADVO4Z2/1SCvxg27ad1P+aGqb9+uz/jSPMFGr51MNHDBH9eFhvmN5ALSLYBUuAO99LY7fyczOPAr0B7FQUMAycOePDw3FYHbR0Mt78CFsWZpbSq/KJHb4TbWcporWBVPtx/Lry+EUJuSMHk0F7z7T+dZ6l+toyQkFznN5ixBfgV X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(396003)(366004)(39860400002)(346002)(376002)(136003)(451199021)(31686004)(6916009)(4326008)(786003)(316002)(966005)(66556008)(66476007)(66946007)(186003)(53546011)(6512007)(6506007)(38100700002)(2616005)(83380400001)(66574015)(41300700001)(5660300002)(8676002)(8936002)(478600001)(6486002)(6666004)(36756003)(86362001)(31696002)(2906002)(45980500001)(43740500002); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?wvuLL4Dx2pmpzX09bhzdh+/+jfquulTTeuj1ehWZsDelPX7UAviwhLEGyAph?= =?us-ascii?Q?gCpA4D8bVuWWyu4WpyAc8KllIytZOIs9JDWefb4EfI9kou1hZQVszHIYdhy5?= =?us-ascii?Q?OZ1ir6YdJVa+CtH3jOJ89sHdNkL5lYIgwBwCSLKfgdXRPngY0nvx8Z3nsyrp?= =?us-ascii?Q?VpfFgXMmkagPK9ZJVxdas1zvc3JHiqvRU6ox40pMW3gskzI0YVrrdm30EkXN?= =?us-ascii?Q?MJjcw+TGntG3y6ZqSzoQoKBRB/BpEuBF5rNaiscc56srplEdp49iyJYhCMlg?= =?us-ascii?Q?FtY4k3xocgjN5boHrvkWrB0Ilf1RSa6MUCffl3wyCef61+Ghk9LHt9css78o?= =?us-ascii?Q?SxrKuW64XAWL8lnAMpl1fBeIxaoUUiyNOO1rID4fxhIlz7LZyCHTUfURrhpx?= =?us-ascii?Q?Ry5vUhysblFfgN11V9gXZVyc4+hr3i3YagNVDCK/NVJ7nBXTALjsjuRPFGJL?= =?us-ascii?Q?a75vWAJ27/Xlj8dt1MHYSwNQyT03b/6Zq920x8wvJH91Yk2zo5e2tAveV/6M?= =?us-ascii?Q?XInULEflQNcF33lVcl+REC+NAxKGN6jJDtD1NxtuhqbSORqr0GrZWK1eJbaG?= =?us-ascii?Q?W12cnEYMpdS9KIvD9po74VK4RMuWDml8HQnup+5Kq4ZTgWT5lvtDu0FzFjUF?= =?us-ascii?Q?6n8ChEeN2pbvkuHBveiQpXkvvC46/asbryMTOMfI79tp8P6rGiklwm0lARo+?= =?us-ascii?Q?lreo2BO/JIyLq7MmWJ3NXclC6MuDf5ulJpTtbnw3953kocIOhSVm4r8CReoL?= =?us-ascii?Q?gOT4JrZvWRLAuLcoi0ZVqs3xIKmlE1XLfHGmoGCX9Rew7YbxW+O/dAOxWbeO?= =?us-ascii?Q?vTMFLGmAhyGVLh4BmgccxXAOtcOcldmZGH+6Q94tvsEDJ6rsQJzfEGC6k6nu?= =?us-ascii?Q?GAynGFZMXjkFK1ewtU7eVhhL/DiydPjLWUoG37bDpbHjAWXvTqdXuPYzjWjW?= =?us-ascii?Q?dZbJhbaBpLW04byNRqK0+B1urrug2dAT9kpLUBCwHyLyAA3VTyuthlHp+miv?= =?us-ascii?Q?uS/hBrLHOGORCtMsbi6Pvl3bYcpbAQJM/5+AXpiwjdugyWfjl9tlBPc3v/c/?= =?us-ascii?Q?8R4618Da/WwEo0wEoIn7YFlchwBBcUExaULMULqAACNPVW56e3B1Nywoyt8Z?= =?us-ascii?Q?M/FcisyRPJMPFOm42z6t5/K7XcpT1E2wkCgov1qh0wQ6LeOIypnB9xMTkUuo?= =?us-ascii?Q?KsLIezMNxswUDp+ddDUgmLch5NNJObcdFIRWTiYq4BM0Pf35EPCLEmEQO9rZ?= =?us-ascii?Q?Y5cP+Co2Sp9LFqpSVih+g6orESuuNWKez0Ic/dDMAfbQoVVE4M3VAhcgdbH5?= =?us-ascii?Q?wJrMzUFwewaw/PM1zo1LRiguVR+aTxIhSJgG8jrpIkIlPJiWEdlo8WocmNXx?= =?us-ascii?Q?7zcn26wwAgj0cIgNpPzIsBge9x7zaDIbA9ssmf8VWzL7c7quJK2ImhnEJjD3?= =?us-ascii?Q?aSdImOKIHpV00Be2V0dYf44tOReXHI13TvrdZotD+FwZuwIlZOTcQgEYLNzV?= =?us-ascii?Q?mL4o0c0LmK1RGLraMy6l+T1SdjUPpWmZHSCngv6K4ynio/1GPPho/CMTqFUL?= =?us-ascii?Q?b+fTtNkTNIZGD3d+6EtI7u/RXT0XHdX6JOgXKdFDgPJI6X8pg66gZVBP5nrz?= =?us-ascii?Q?Kmm3+3kBDFkN3Uap5G6cmuMTGA3NWOJ7sI2OQ8OMOc4CTX09XdhWguK4JtrB?= =?us-ascii?Q?xLVeQg=3D=3D?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: cff201fc-ab93-4296-d3eb-08db3ecbceb9 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2023 22:42:07.2238 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: EOVd5eFBt/NevevUoi3BiLYL6c+h6/vhIect6zTRyjIVlvjj0OR4HyuJnSug2OJS+uCihlbvHNBdOUNs/QtCyH8V9tzfbvNCIW1wMDRniKI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4PR01MB6171 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Starlink] fiber IXPs in space 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: Sun, 16 Apr 2023 22:42:15 -0000 On 17/04/2023 10:03 am, David Lang wrote: > On Mon, 17 Apr 2023, Ulrich Speidel via Starlink wrote: > >> On 17/04/2023 5:54 am, David Fern=C3=A1ndez via Starlink wrote: >>> In case you put a DNS server in the satellite, so that it replies >>> instead of a DNS server on ground, the RTT is reduced by half. >>> >>> The idea would be that the satellite inspects IP packets and when it >>> detects a DNS query, instead of forwarding the packet to ground >>> station, it just answers back to the sender of the query. >> Understood - it's just that the gain you have from this is quite=20 >> small. DNS queries only happen the first time a host needs to resolve=20 >> a name, and then again after cache expiry much later, so they account=20 >> for only a tiny fraction of the traffic, and also for only a small=20 >> amount of the total delay in page loads. RTT isn't really the big=20 >> issue in Starlink - yes it's larger than it perhaps needs to be, and=20 >> bufferbloat seems to be present, but compared to GEO, it's now in the=20 >> range seen for terrestrial Internet. > > DNS time is more significant than you think, due to the fact that so=20 > many websites pull data from many different locations, you end up with=20 > a lot of DNS queries when hitting a new site for the first time (and=20 > many of these queries are serial not parallel) so it adds quite a bit=20 > to the first rendering time of a page. But most people don't hit new sites most of the time, and a lot of=20 cascading loads hit the same CDNs you've seen previously. > >>> CDNs or even datacenters (Cloud) in GEO or LEO is even more complex. >> >> Indeed. In so many ways. >> >> Mind though that CDNs are generally tied in with DNS nowadays, and=20 >> there's another snag: Take two users, Alice in the UK and Bob in New=20 >> Zealand - pretty much antipodean, using Starlink in bent-pipe=20 >> configuration, i.e., their traffic goes through, say, the London=20 >> gateway in the UK and the Clevedon gateway in NZ. Now imagine both=20 >> trying to resolve the same CDN hostname some time apart, but via the=20 >> same satellite DNS as the satellite has moved from the UK to NZ in=20 >> the interim. Say Alice resolves first and gets the IP address of a=20 >> CDN server in the UK. If the satellite DNS now caches this, and Bob=20 >> queries the same hostname, he gets directed to a server in the UK=20 >> literally a world away instead of the Auckland one closest to him. So=20 >> unless each satellite carries a geolocated copy of the world's DNS=20 >> entries with it and makes a decision based on user location, you have=20 >> a problem. > > This is true when the DNS answer is dynamic, but such cases also have=20 > short cache timeouts. Even with a 90 min orbit, a 15 min timeout would=20 > significantly lessen the impact (and I would expect that an orbital=20 > DNS would detect short timeouts and treat them as a signal to shorten=20 > the timeout even more) Timeout where? At the end user client or at the satellite? At the end user client, a short timeout makes no sense at all because=20 their host-to-CDN-IP server mapping shouldn't really change in bent pipe=20 - only the sat hop changes. If the timeout is meant to be on the satellite, it means that the=20 satellite knows nothing about anything when it arrives to assist you,=20 and needs to query some sort of (probably ground-based) DNS server anyway. Also, the assumption that a satellite will return to the same spot after=20 a full orbital period (of say 90 minutes) only applies to satellites in=20 equatorial orbits (or polar orbits, and then only to the poles). In all=20 other cases, the Earth's rotation will assure that the satellite's=20 return to the same location takes many orbital periods. > > David Lang > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz http://www.cs.auckland.ac.nz/~ulrich/ ****************************************************************