From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 943C63B2A4 for ; Sun, 16 Apr 2023 21:07:00 -0400 (EDT) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id A850E186879; Sun, 16 Apr 2023 18:06:59 -0700 (PDT) Date: Sun, 16 Apr 2023 18:06:59 -0700 (PDT) From: David Lang To: Hesham ElBakoury cc: "David P. Reed" , Dave Taht via Starlink In-Reply-To: Message-ID: <0473sos1-6ns6-8o1r-393q-sqo6r68qq731@ynat.uz> References: <1681691279.13362849@apps.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Subject: Re: [Starlink] 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 01:07:00 -0000 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@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@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> >