From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C37A13B2A4 for ; Sun, 16 Apr 2023 22:04:10 -0400 (EDT) Received: by mail-pj1-x1034.google.com with SMTP id l9-20020a17090a3f0900b0023d32684e7fso12993430pjc.1 for ; Sun, 16 Apr 2023 19:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681697050; x=1684289050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ANqZ0hVpk1D4nahWl4fmoR+o0DWtd92C2n+87Qfmxnk=; b=Ln+mAs8Ac8/SafeK4pxYfOIS90Tdb/FbFaH5wgg0vrDdr9igErBKB+IDrShaJIhpyQ OUijXTw8GWQTXwHRuHr43H5k88S0XYKZueYdrmfjdMC0NG9Bj1RoRwFIsq842xFu1UCe qsFRQcewAvpmIRk13eaZlBcHw0VQAcDVR0+5z0uZQy64vo1URVBJCAqAIO/LdnE2eA1Y G4jaGvpxc9A9GAI49EAgnQdEXZAlgo/zewsrUj0O8PEANB9XnfiL5W0LRP0noPibLwXJ o75XWdvmyibDxzATCs8oJh3q48NI7lZzpuejPP2h8yg5ZRfvowEazkx5xOdkz8LsUld8 2EpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681697050; x=1684289050; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ANqZ0hVpk1D4nahWl4fmoR+o0DWtd92C2n+87Qfmxnk=; b=CvRUzUk45WHprxRxW8doHotWinaFa1r+J5LJ4cvquwXkYXyAzC/H4IiA2y2uq3vRPe EfUfEMQOk/g1Jy9byJjVhtgwn9VAsuFq1yPWSrBUJpnLOEUikSM5EVfhUj3fjPaxj28p r1JlNeY/n8wTgDVz+Q0Or6oX7nxPRypmPN0zSmPGQ0AoyaqjYTtLerjCfZBodszEGyxp YmhjVJeFucAsbNo6tzpZJBE4t9u6ep97J1wdLQIHCP/zMlhAfQNO7zgiBI0fseTXo1xc z0Nrit01ZwKukmXRfTxsVqjxcwYDIsAnDRAvB9xOAE1oNBPVLNgbaT5pQpactXyfq1JR EXCQ== X-Gm-Message-State: AAQBX9e5BgehU5zzFPCK9Rai2yJGS1WHaVk/Oq1osg1yYRc3RDLv+gM+ qafzfjFpGMhnBUmrnUgvilUyCZ4gm1uX4afEEsu2JZNRV/jiphoB X-Google-Smtp-Source: AKy350bYOSA0e+FdDsteXclZMPPxgukDY81+EenJBpTvxqOVcDDP1QS/jZDmgFrAA8qYM07tD1FRIGnB5OaB+5iyLtY= X-Received: by 2002:a17:90a:9113:b0:233:76bd:9faa with SMTP id k19-20020a17090a911300b0023376bd9faamr13210419pjo.47.1681697049525; Sun, 16 Apr 2023 19:04:09 -0700 (PDT) MIME-Version: 1.0 References: <1681691279.13362849@apps.rackspace.com> In-Reply-To: <1681691279.13362849@apps.rackspace.com> From: "Edwin Liava'a" Date: Mon, 17 Apr 2023 15:03:58 +1300 Message-ID: To: "David P. Reed" Cc: starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="00000000000041c26405f97e9bba" 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 02:04:10 -0000 --00000000000041c26405f97e9bba Content-Type: text/plain; charset="UTF-8" Indeed an interesting and insightful discussion. Tons of thanks to everyone for sharing. Bravo! On Mon, 17 Apr 2023 at 13:28, 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 > -- Edwin Liava'a WhatsApp: +61451013850 https://www.linkedin.com/in/edwin-liavaa --00000000000041c26405f97e9bba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed an interesting and insightful discussion.

To= ns of thanks to everyone for sharing.

Bravo!

On Mon, 17 Apr 2023 = at 13:28, David P. Reed via Starlink <starlink@lists.bufferbloat.net> wrote:

Dav= id Fernandez and others here seem to have a *profound* misunderstanding of = the core architecture of the Internet Protocols with respect to, say, Starl= ink.

=C2=A0=

I am h= aving 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 archit= ecture, and maybe there are new, better ideas that we somehow missed. Clear= ly not.

=C2=A0=

#1: Th= ere's a reason that the whole Internet is designed around "not put= ting extra functions" into the underlying network. It's outlined i= n a paper I wrote with Jerry Saltzer and David Clark, based on the work I d= id 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 fo= r goodness' sake don't read any of the Wikipedia pages that claim t= o explain the End-to-end principle or End=3Dto-end argument, as a primary s= ource I am actively barred from editing it and the paper, as a primary sour= ce, is viewed as suspect by Wikipedia, because Wikipedia requires that all = citations be *secondary* sources).=C2=A0=C2=A0https:/= /web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

=C2=A0=

#2: DN= S service doesn't specify that "geolocation" is a function of= the DNS service. It is the job of the endpoint *after resolving the DNS na= me to one of many IP addresses* to decide which IP address to use for the D= NS name. That is, "geolocation" is an endpoint function, not some= thing that the network does by spying on packet contents and faking a respo= nse from real DNS servers.

=C2=A0=

#4: In= general, IP as a protocol underlying ALL of the Internet protocols is requ= ired to deliver the content to the address specified by the sender, *withou= t either reading or modifying the content*. There are certain cases where &= quot;masquerading" as the destination is sometimes OK, but ONLY when t= he sender and receiver are specifically AWARE of this interception. This is= called a Man In The Middle *attack* otherwise.

=C2=A0=

#5: As= a special case, some IP addresses are "anycast", which has nothi= ng to do with DNS itself as a protocol, but instead provides some low-level= "neighborhood" addressing for a class of servers. Cloudflare use= s 1.1.1.1, for example, as an "anycast" address supported by the = global Internet Routing architecture (BGP, for example), that can be used a= s a DNS caching resolver (server) address. This works because the DNS datab= ase is designed to be replicatable, so one can cache subsets of the DNS dat= abase for short durations without problems, because the servers are "l= oosely" replicated. But"anycast" doesn't guarantee (anym= ore 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.

=C2=A0=

#6: Th= e 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 ad= dresses (like Ethernet addresses, e.g.). Their contents above Layer 2 canno= t be decoded. My DNS requests are DNS-over-HTTPS, except within my home I c= ache the answers on a local server that uses DNS/UDP/IP. I certainly don= 9;t trust any Elon Musk corporation not to spy on my traffic.=C2=A0

=C2=A0=

#7: Th= e general idea that one should put more function into Starlink Satellites b= asically will start to "fork" Starlink Enterprises (the Musk comp= anies) as an "alternate Internet" where applications must use onl= y the functions that Starlink supports (where other Internet providers may = support broader standards or not support the special "Starlink-only&qu= ot; 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 th= at as a great thing. Certainly the Chinese Communist Party is trying hard t= o balkanize a Chinese-only Internet, spending a lot of money to block inter= operability. Musk may envy China, I don't know.

If you= want a Balkanized, non-interoperable Internet, where the carriers feel fre= e to examine all the traffic and create their own, non-interoperable protoc= ol set, I'd suggest China might be a good place to move. Or maybe Mars?=

=C2=A0=

Now wh= at'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 damag= e, and routes around them. But to route around them, the Internet has to be= overall, *interoperable*.=C2=A0

=C2=A0=

There&= #39;s no law, and no "cryptocurrency" like Ethereum that prevents= bad ideas that destroy interoperability, in the Internet Architecture. Any= one can invent and deploy a new protocol, and you can invent new layer 2 tr= ansport 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 blocki= ng all communications).

=C2=A0=

So, my= recommendation: don't do such dumb things!

=C2=A0=

_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Edwin Liava'a
WhatsApp: +61451013850=C2=A0
<= a href=3D"https://www.linkedin.com/in/edwin-liavaa" target=3D"_blank">https= ://www.linkedin.com/in/edwin-liavaa=C2=A0


=
--00000000000041c26405f97e9bba--