[Starlink] IXPs in space
Hesham ElBakoury
helbakoury at gmail.com
Sun Apr 16 20:40:22 EDT 2023
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230416/5536907c/attachment-0001.html>
More information about the Starlink
mailing list