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.23.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 98E6A3B29E for ; Mon, 17 Apr 2023 16:09:16 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1681762153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=V0uJxHHJ/rRV464AYH3vMSM1eiOSvUt5cImBIo75oSY=; b=He4JnwBTfAvoi3Bz6HcXBzkBSxJ4o5hBGNjvW3uBFGoQVtVREmPp/zk7h+ezTJ3KT5DZk4 O3BJdlUydiW19wiyaeox+uwWfpey4E0uhMRypS9Ex68IuIPhq5vw7msEXx2rVC14jzzqbR 6j/Xnuh0VNjpxfgW5YdkMPWrde3oOKw= Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2170.outbound.protection.outlook.com [104.47.71.170]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-24-IT0M50PAMoGbjXsbpEUJQw-1; Tue, 18 Apr 2023 06:09:11 +1000 X-MC-Unique: IT0M50PAMoGbjXsbpEUJQw-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by SY7PR01MB8335.ausprd01.prod.outlook.com (2603:10c6:10:1ee::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.45; Mon, 17 Apr 2023 20:09:10 +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; Mon, 17 Apr 2023 20:09:10 +0000 Message-ID: <1da51aca-ddbf-ab98-2fde-4e3da5f63fa1@auckland.ac.nz> Date: Tue, 18 Apr 2023 08:09:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: starlink@lists.bufferbloat.net References: <202304171438.33HEcqi7056122@gndrsh.dnsmgr.net> <1n21p043-oqps-r637-p502-p51op49pqoss@ynat.uz> From: Ulrich Speidel In-Reply-To: <1n21p043-oqps-r637-p502-p51op49pqoss@ynat.uz> X-ClientProxiedBy: SYYP282CA0011.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:b4::21) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|SY7PR01MB8335:EE_ X-MS-Office365-Filtering-Correlation-Id: a7e87e1a-05ec-4fbf-61eb-08db3f7f9b29 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: pyc1OemVMHgymf9wSkAqKmEVUyzJDv/R4NT4SY89cd2pPLAF4ucUn2ZF8P0i78aaOzEtOkWBrGWR6Ylg74h2KcYlKG+3QloNlAMlGs5xv1NYTqT5DCTUdzSrR3G14aObbcsgXz7S+ju6Mm8IzQWebhyhjtuWm45vZbOdahj318l/ptTtnyOUNpV+k7ruM47NxZ8NVFHeJ/0QqwTLU//WoBuzSe5OMtYjd8iewg51tC+Wi/7LWButYY3ra7FU6Q4GVYFJC21tRwPf8yQVsD29l5pQ4mobyHh/mf6SCcrIc9CxNUzt83dGkKD15MUZfSrY9sMKw+WVdPfwQDIjsFH0eJRCfjBOwAMAyvUgo/F+AD5gaxpzPAMW+r59jSiEHc/QIVEKcvS9B4IWy76JmRihbPTAKYikyU22BT5b0mwuX0oCfOfQAmsWnP4ltOyKR9eMTPx3xuaTQXgcHyPTfiSb5hrWHovQra+0lt2x0uLAxyTmRouUtpLNxoM4o8PbxCRR5o7wvYHUURwArIBdNTQ1fVeJCWzKijdhES52g3vV5+2dnD0CyswJ97neBS5S7oDh7+P6XnRjfj48SsZo+zFFA35U2h2skg2cze/TsvxfD+9BhQYccYucNNTsDvlokJNkDZGeUmYVtJ8d6OQICQVf5xZEcXXe1tQaemRjl0khE10= 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)(39860400002)(376002)(366004)(346002)(396003)(136003)(451199021)(31696002)(86362001)(36756003)(2906002)(31686004)(6486002)(33964004)(186003)(53546011)(66574015)(83380400001)(2616005)(6506007)(6512007)(966005)(66946007)(66476007)(66556008)(6916009)(478600001)(41300700001)(38100700002)(786003)(316002)(166002)(8676002)(8936002)(5660300002)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yk5vaFFkL3diNmc3aW9QUVN0Z29jRGpxektXbVBYSXgvVVZTMTc1VURQc2ln?= =?utf-8?B?SFBDK0NnL1NFSUxhUnFNaDlQbkRybDBOYkxTRFdQbWNEMG9XMG1MbGRJQW8x?= =?utf-8?B?aklJNVVtSUU1dVg4Q3hueExRVHlESlhMM251dXZPejhHQTFnb3AveXJzMzFr?= =?utf-8?B?YnViaEhlTlBKK05PYmc2M2JGb2NxK2F6cXFFWk9TYllvb3AyKzNRbjZ3Z281?= =?utf-8?B?K29YWVRYc2w1VlpUa1dTdmRjVVVtc2xiWkR2ZWIrWC9MeEJhUXlTaUd2SDFt?= =?utf-8?B?eHYwczNUdnBVUVVIK2FHQ1FIblZoOWJkMy94R1BCSmUyL1R1VHZzbDVNcUs2?= =?utf-8?B?bGxKZG1raGtpS2ZYR1BNS1dBcHgveWhtcUZpSzNyOWtmYWVYeEpjZTVSZnJp?= =?utf-8?B?b3Y1czhDaFQvV2ZqWjZMTm12a3dYV1A0NytWeGkyWkxRTlRyUzZ5WWcxZHVH?= =?utf-8?B?Z2dWUHNuditnOFUzZ0xYQzc4K3g5Wml2ZEVNMERhNnhNV21ZV1dySzZqTmVU?= =?utf-8?B?aE1zS1d3TnE4WGlqV2thR0RrSUIxYjI4dldIQ28xMWsvOFQzTVpINGsvRmo2?= =?utf-8?B?VGNONEFnbFJ6RmFudjlYbDNWeWw1YVUxbGJUZklkc04rRUhWZExaRGNzc1R1?= =?utf-8?B?OThYeUhIUXRlUlpLUElZV2MrNGJkbFF2ZlZuN244TkhjOWx4MkFPWXpuNDBq?= =?utf-8?B?UmVldXRWRW5UeldDcjRVYTVmbjIxWVhIS3dma3hNQ1VJMUxBT3pqUkp5SkNY?= =?utf-8?B?eG8vTDgrd1d5dVlQZlBlLzFPVzJMakpteUMvSVJRemZ6eUJJcnBWbmNxVmMz?= =?utf-8?B?eVMyTHpid2tkWnZJblB2TXhaOVJ1SDMyS0szeWNHQnNMWUQyZnRkajVRNk9p?= =?utf-8?B?V0s2QXVEQ1FCV2QzM2lKWEVhcUg2Qm5OOUlQaWJaQzc1RzZQTTNDTXgza0tW?= =?utf-8?B?ZDk5SmFRQXNqYWxzaVZWNkI3cldDalo0N2lLc0NaT3N5NEtWSTNBL2dxWVN3?= =?utf-8?B?YWlLU1ptYWFOdnZwVmdsbk40T1RaWlg4V0tsVlhkRXVENlpYbGxpcEdLdVNu?= =?utf-8?B?Z3M1UGd3UWhJRWJ5Q3NMNnZJS0RhWlVkM1J1dmsxNW0zY2JWV1BybjhhRENl?= =?utf-8?B?cFIrd0hnTU9IZWRiRFJIdGh4NmdQYzU4TTZjK3NxM1lJekI3SVNxOFUrdC9r?= =?utf-8?B?cHYzVXIvS3B3cm1UbVdOaUNrVFhrL3EzTDIxakdjb3NCQy8vaVhpUE8zQVdX?= =?utf-8?B?aUhNRURHcHAvUGFWNGg5S25VM3JWL1JTeW1ndGtDTDlzVWswUytmZDlnK05m?= =?utf-8?B?YjhUZUJoZmNNSXFmMkxDZmJuTzg5Vk4yb1hma2tVSGlLemppallRTkpNWHh6?= =?utf-8?B?SUxnZzg2K0puVDFBR0QzbzZWZFFlZGY2aXo3M3hPSmtuNk4xNyt4aWN2S3dI?= =?utf-8?B?eXBsYmpGVW1FZ2M2MHVQc2ZLZFBwdWd6SVhiYVdKYUducDFNRFpYQW9lNzZR?= =?utf-8?B?em5aVkxRZjQ3SUZVWklJMTRCTE1nS0psYXZuRERMZjdUUk5JWW1qdnRsbTVk?= =?utf-8?B?QWZud0N2eUQ0ZitMUGRheGNFUm9NUHk4SGlhNVRwQzZkaVFSeTlLZmFURDc1?= =?utf-8?B?Q3BsTmZBUmR4Z2lNdzdCMFBnKzNaajBKemdhRWxHUVZqK3FCYkh3WnlVbjVu?= =?utf-8?B?YnZLL24xbEZxdFQ3Q3BPRzVrTXRzbElSNzIyYzNLZzJqTUN5UlZVaXN1ZnB2?= =?utf-8?B?RGJxSHZRaFU0NWc1TjFlRkdqSHEwZVhwMlBBbmZoMFZsMk40ditkZzNPaVNK?= =?utf-8?B?dysya1lQVFpLenB2eGkzZ2dUR2tVUmE5NXp6elA3NGFPdEp1SGtkQlFHSkU5?= =?utf-8?B?YmNXOS9ISDlhOWhoZWFWeklpWnlIbzkxQkIwTmZvYmtuNHVwNjVJRmN5Y2V4?= =?utf-8?B?T0NibkFKUXg2ekhGRGw1d0VCdFg0T0VncFRJZzJaV3g1b0tnVXNXQVhZZ2tE?= =?utf-8?B?c2Q1b09SdWxESnVGeWc2Y3U5bGR2ZnU4SHVsbmxwSlJaTERuTVd2enp6OWRD?= =?utf-8?B?LzZFK0Q1VWdXM2gvTzdvVzF6VUE3bHhlNTNZYTV2NzE3K0o2UHBVNE5HSXd0?= =?utf-8?B?cTlHTzdrOGZiNjNOUHRDUm52bHYxTkt4WFFkWjY5K2FMR0xGZVdJdGh5ZVlm?= =?utf-8?B?cE5WdTZCV3lvVzNsNld4bUd3WFMxVk1ENHVkZWtoSSttZ0RoVWlCVGx3d285?= =?utf-8?B?WkVPUU1XNzI2aDExSldHR2dsR1N3PT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: a7e87e1a-05ec-4fbf-61eb-08db3f7f9b29 X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2023 20:09:10.0561 (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: P6X1ZWNz7jSX4eDHM5HE1IciORQbEeTPrsqf0+yf0x4GJR8ChjMen9FQrowI2gD80s8urSV6g4nrQmIucbGHxCx4uSo1V2/h5qkD1j2qbMg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7PR01MB8335 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------vkdbRyZY4n7LmRZvqzJxg5Td" Content-Language: en-US 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: Mon, 17 Apr 2023 20:09:17 -0000 --------------vkdbRyZY4n7LmRZvqzJxg5Td Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable For all I can tell, dishy only uses one satellite at a time and so=20 routing via dishys to other satellites - while certainly an attractive=20 concept - doesn't seem to be happening. Most modern comms systems - look at your phone - run pretty complicated=20 stacks these days, and I'd be very surprised if Starlink didn't. That=20 makes it likely that there is an extra network and transport layer=20 between dishy and gateway (a term, which I'm incidentally not using for=20 the WiFi router that comes with dishy but for the gateways that connect=20 the Starlink space network to the terrestrial Internet). Any routing=20 between dishy, satellite and gateway (and any lasers along the way) will=20 therefore be happening at that extra network layer - the transport layer=20 above it has the job to make the path between dishy and gateway look=20 like a single data link layer hop. This is why you don't see a satellite=20 IP in your traceroute. Quite how that extra network and transport layer=20 is implemented is something that probably only Starlink knows. The power=20 of layered communication ;-) P.S.: I'll apologise in advance for upcoming silence over the next few=20 days - we're taking Dishy for an outing to get it away from the Clevedon=20 gateway, so we can finally get Dave some more data ;-) On 18/04/2023 7:09 am, David Lang via Starlink wrote: > if Starlink can route via in-space-lasers and in a dishy-to-dishy way=20 > (both have > been talked about, at least in future tenses) then they could also=20 > route to an > on-satellite IP. > > historically 'bent pipe' satellite support meant that the satellite just > repeated the RF signal back down with no modifications. Starlink was=20 > designed to > do routing of traffic, some to a ground station (possibly more than=20 > one), some > to other satellites (including ones at different altitudes), and some=20 > to other > dishys. It's initial deployment included no routing, just relaying=20 > between a > dishy and a ground station, but we know that it's extended beyond=20 > that, at least > when there are not ground stations in range > > David Lang > > On Mon, 17 Apr 2023, David Fern=C3=A1ndez via Starlink wrote: > > > Well, I have some concerns about how you implement an anycast address > > in a transparent satellite. > > > > If the pre-requisite for this is that the satellite is a router, I > > don't see this happening anytime soon. I am not aware of any system, > > not deployed, even designed with satellites being routers, but IRIS2 > > could be the first, maybe: > >=20 > https://defence-industry-space.ec.europa.eu/eu-space-policy/eu-space-prog= ramme/iriss_en=20 > > > > > Bufferbloat will be checked and prevented as much as possible in IRIS2. > > > > Regards, > > > > David > > > > 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes=20 > : > >>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote: > >>> > >>> > The idea would be that the satellite inspects IP packets and when i= t > >>> > detects a DNS query, instead of forwarding the packet to ground > >>> > station, it just answers back to the sender of the query. > >>> > >>> This would be a bad way to implement it. You don't want to override > >>> queries to > >>> other DNS servers, but it would be very easy to create an anycast=20 > address > >>> that > >>> is served by the satellites. > >> > >> Yes, and the later is what I proposed, the idea of intercepting > >> someone ELSE'S anycast address and processing it would be > >> wrong in many ways, in effect a Man In the Middle attack > >> as stated else where. > >> > >>> David Lang > >> -- > >> Rod Grimes > >> rgrimes@freebsd.org > >> > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink=20 > =20 > > > _______________________________________________ > 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 =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------vkdbRyZY4n7LmRZvqzJxg5Td Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

For all I can tell, dishy only uses one satellite at a time and so routing via dishys to other satellites - while certainly an attractive concept - doesn't seem to be happening.

Most modern comms systems - look at your phone - run pretty complicated stacks these days, and I'd be very surprised if Starlink didn't. That makes it likely that there is an extra network and transport layer between dishy and gateway (a term, which I'm incidentally not using for the WiFi router that comes with dishy but for the gateways that connect the Starlink space network to the terrestrial Internet). Any routing between dishy, satellite and gateway (and any lasers along the way) will therefore be happening at that extra network layer - the transport layer above it has the job to make the path between dishy and gateway look like a single data link layer hop. This is why you don't see a satellite IP in your traceroute. Quite how that extra network and transport layer is implemented is something that probably only Starlink knows. The power of layered communication ;-)

P.S.: I'll apologise in advance for upcoming silence over the next few days - we're taking Dishy for an outing to get it away from the Clevedon gateway, so we can finally get Dave some more data ;-)

On 18/04/2023 7:09 am, David Lang via Starlink wrote:
=20 if Starlink can route via in-space-lasers and in a dishy-to-dishy way (both have
been talked about, at least in future tenses) then they could also route to an
on-satellite IP.

historically 'bent pipe' satellite support meant that the satellite just
repeated the RF signal back down with no modifications. Starlink was designed to
do routing of traffic, some to a ground station (possibly more than one), some
to other satellites (including ones at different altitudes), and some to other
dishys. It's initial deployment included no routing, just relaying between a
dishy and a ground station, but we know that it's extended beyond that, at least
when there are not ground stations in range

David Lang

On Mon, 17 Apr 2023, David Fern=C3=A1ndez via Starlink wrote:

> Well, I have some concerns about how you implement an anycast address
> in a transparent satellite.
>
> If the pre-requisite for this is that the satellite is a router, I
> don't see this happening anytime soon. I am not aware of any system,
> not deployed, even designed with satellites being routers, but IRIS2
> could be the first, maybe:
> https://defenc= e-industry-space.ec.europa.eu/eu-space-policy/eu-space-programme/iriss_en
>
> Bufferbloat will be checked and prevented as much as possible in IRIS2.
>
> Regards,
>
> David
>
> 2023-04-17 16:38 GMT+02:00, Rodney W. Grimes <starlink@gndrsh.dnsmgr.net>:
>>> On Sun, 16 Apr 2023, David Fern?ndez via Starlink wrote:
>>>
>>> > 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.
>>>
>>> This would be a bad way to implement it. You don't want to override
>>> queries to
>>> other DNS servers, but it would be very easy to create an anycast address
>>> that
>>> is served by the satellites.
>>
>> Yes, and the later is what I proposed, the idea of intercepting
>> someone ELSE'S anycast address and processing it would be >> wrong in many ways, in effect a Man In the Middle attack
>> as stated else where.
>>
>>> David Lang
>> --
>> Rod Grimes
>> rgrimes@freebsd.org
>>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink 
______________________________=
_________________
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=20
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------vkdbRyZY4n7LmRZvqzJxg5Td--