[Starlink] IXPs in space

[David Lang]

I think that recent experience just reinforces the idea that the network should 
be neutral to the traffic going over it (with the allowance that people should 
be able to opt-in to services provided as they want to)

David Lang

On Sun, 16 Apr 2023, Hesham ElBakoury via Starlink wrote:

> Hi David,
> With in-network computing and programmable networks which can put many
> functions in the network, do you still think the E2E argument is still
> applicable? Or time has come to update it?
>
> Hesham
>
> On Sun, Apr 16, 2023, 5:28 PM David P. Reed via Starlink <
> starlink at lists.bufferbloat.net> wrote:
>
>> David Fernandez and others here seem to have a *profound* misunderstanding
>> of the core architecture of the Internet Protocols with respect to, say,
>> Starlink.
>>
>>
>>
>> I am having a hard time sitting on my hands listening to this discussion,
>> but hey, I just was one of the few people who spent a lot of time on the IP
>> architecture, and maybe there are new, better ideas that we somehow missed.
>> Clearly not.
>>
>>
>>
>> #1: There's a reason that the whole Internet is designed around "not
>> putting extra functions" into the underlying network. It's outlined in a
>> paper I wrote with Jerry Saltzer and David Clark, based on the work I did
>> as part of the team that designed IP, TCP, and UDP, but abstracted as a
>> principle of architecture. Please read the original paper carefully (and
>> for goodness' sake don't read any of the Wikipedia pages that claim to
>> explain the End-to-end principle or End=to-end argument, as a primary
>> source I am actively barred from editing it and the paper, as a primary
>> source, is viewed as suspect by Wikipedia, because Wikipedia requires that
>> all citations be *secondary* sources).
>> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>>
>>
>>
>> #2: DNS service doesn't specify that "geolocation" is a function of the
>> DNS service. It is the job of the endpoint *after resolving the DNS name to
>> one of many IP addresses* to decide which IP address to use for the DNS
>> name. That is, "geolocation" is an endpoint function, not something that
>> the network does by spying on packet contents and faking a response from
>> real DNS servers.
>>
>>
>>
>> #4: In general, IP as a protocol underlying ALL of the Internet protocols
>> is required to deliver the content to the address specified by the sender,
>> *without either reading or modifying the content*. There are certain cases
>> where "masquerading" as the destination is sometimes OK, but ONLY when the
>> sender and receiver are specifically AWARE of this interception. This is
>> called a Man In The Middle *attack* otherwise.
>>
>>
>>
>> #5: As a special case, some IP addresses are "anycast", which has nothing
>> to do with DNS itself as a protocol, but instead provides some low-level
>> "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1,
>> for example, as an "anycast" address supported by the global Internet
>> Routing architecture (BGP, for example), that can be used as a DNS caching
>> resolver (server) address. This works because the DNS database is designed
>> to be replicatable, so one can cache subsets of the DNS database for short
>> durations without problems, because the servers are "loosely" replicated.
>> But"anycast" doesn't guarantee (anymore than DNS itself does) that the most
>> up-to-date information is available at any particular anycast instance.
>> 8.8.4.4 is another DNS anycast address of a different set of resolvers, and
>> may be more up to date or less up to date than 1.1.1.1.
>>
>>
>>
>> #6: The idea that one can "identify" DNS requests by snooping on layer 2
>> packets is so crazy it is not even wrong. Layer 2 packets have layer 2
>> addresses (like Ethernet addresses, e.g.). Their contents above Layer 2
>> cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my
>> home I cache the answers on a local server that uses DNS/UDP/IP. I
>> certainly don't trust any Elon Musk corporation not to spy on my traffic.
>>
>>
>>
>> #7: The general idea that one should put more function into Starlink
>> Satellites basically will start to "fork" Starlink Enterprises (the Musk
>> companies) as an "alternate Internet" where applications must use only the
>> functions that Starlink supports (where other Internet providers may
>> support broader standards or not support the special "Starlink-only"
>> functions). This is a way to balkanize the Internet, and maybe Musk who
>> loves Monopoly Power after all because it makes him more Powerful, sees
>> that as a great thing. Certainly the Chinese Communist Party is trying hard
>> to balkanize a Chinese-only Internet, spending a lot of money to block
>> interoperability. Musk may envy China, I don't know.
>>
>> If you want a Balkanized, non-interoperable Internet, where the carriers
>> feel free to examine all the traffic and create their own,
>> non-interoperable protocol set, I'd suggest China might be a good place to
>> move. Or maybe Mars?
>>
>>
>>
>> Now what's a powerful idea in the Internet (so far) is that what prevents
>> bad ideas like this is that the Internet interprets such stupid ideas as
>> damage, and routes around them. But to route around them, the Internet has
>> to be overall, *interoperable*.
>>
>>
>>
>> There's no law, and no "cryptocurrency" like Ethereum that prevents bad
>> ideas that destroy interoperability, in the Internet Architecture. Anyone
>> can invent and deploy a new protocol, and you can invent new layer 2
>> transport technologies too. But I daresay we who built the Internet will
>> make it very clear that anyone ought to "route around you" (including using
>> you with a tunnal that you can't interfere with except by blocking all
>> communications).
>>
>>
>>
>> So, my recommendation: don't do such dumb things!
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>