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 EE33B3B2A4 for ; Sun, 16 Apr 2023 20:40:35 -0400 (EDT) Received: by mail-pj1-x1034.google.com with SMTP id 98e67ed59e1d1-24769a5c2easo308811a91.2 for ; Sun, 16 Apr 2023 17:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681692035; x=1684284035; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=GRaaLSpQ5JMtXqU8pr+J9UnCtkg8oKmHvrgcyBfdKps=; b=Oh9LKXrLrQyfqttf7fPQG12BYH1+ZeiYHsV30WkvQi3lJwL6tapG/6c/Th9/LWw9qt SM3mzMp4ij6lu9tfyL5XPbDNSFd3rB55Z8Bq8wlEmnBa4KRqi4rteKJVucztIU8ewNFM YB0wEGKIlPjc//ChYCI1tgop68ftGTC8v0Vw9j3ZJJabfxtU1svuicGY7hCo/5gGGbuO kQxGSuh/ws1eLGNhq1mYQRdgJ7o1IBBLEOjcfiEoOz/7tAkrUWRwH+eZ/iAxulQLS9MF WDx9VrxXCJfTu212/JCvHpgcKgDU++w3du/IIKLFDsVUit9SM0E7nfq5DfpHbYqn5Ps8 lozg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681692035; x=1684284035; 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=GRaaLSpQ5JMtXqU8pr+J9UnCtkg8oKmHvrgcyBfdKps=; b=XGWFJATx5Yfp8YARZT1qRi51rSxw33JkRD3FRMJt6x2nhmbLef3tUe0EE0Rl5F2vD2 bhcmST6wh3sDeONtr17AK41Y6uHVtlAZLuEZbBNMOf39NVjx8P2/5n2He/L6KFi1X6oL 4sdJLG28/GIJncQL8k97/ZanE4PynfGOETUrgcL/FhHJ96PbDrSLx9RP1WH/SMju24rh 5eRoHv7DOo1acoPDPS3YnQqxsCuB0hdXXXgzVtt2quRL0tElcriyEtu6B0wT1LwbgH7V BwttVbY5i0UOnFL18qGb2QbSYbeO64RQrzZA6OiFeueM2yz0EZ35yDpY3sbt5nGRfgNl N1Dg== X-Gm-Message-State: AAQBX9d2OT7pjzSR+YvRh5hIBN/iGBvLdMUwS4qHd/F8hSdGz2+5lzfu QhdH5oD9kflzyAHW76CPmkteL/DxY0oRlOEceiFTbhKxXPY= X-Google-Smtp-Source: AKy350Y/3BW3h2nu+qrG8NvjnrX2pxJXV8BuKWaUlPOaBuzVsZd577jYXAQOdmPtVqgj8DSalT51D2Qrc3VAic4aj+w= X-Received: by 2002:a05:6a00:218b:b0:63d:22ff:10ed with SMTP id h11-20020a056a00218b00b0063d22ff10edmr593401pfi.6.1681692034642; Sun, 16 Apr 2023 17:40:34 -0700 (PDT) MIME-Version: 1.0 References: <1681691279.13362849@apps.rackspace.com> In-Reply-To: <1681691279.13362849@apps.rackspace.com> From: Hesham ElBakoury Date: Sun, 16 Apr 2023 17:40:22 -0700 Message-ID: To: "David P. Reed" Cc: Dave Taht via Starlink Content-Type: multipart/alternative; boundary="00000000000058b90e05f97d70c2" 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 00:40:36 -0000 --00000000000058b90e05f97d70c2 Content-Type: text/plain; charset="UTF-8" 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 > --00000000000058b90e05f97d70c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0David,
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 u= pdate it?

Hesham

On= Sun, Apr 16, 2023, 5:28 PM David P. Reed via Starlink <starlink@lists.bufferbloat.net> wr= ote:

David Fe= rnandez and others here seem to have a *profound* misunderstanding of the c= ore architecture of the Internet Protocols with respect to, say, Starlink.<= /p>

=C2=A0

I am havin= g 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 architectu= re, and maybe there are new, better ideas that we somehow missed. Clearly n= ot.

=C2=A0

#1: There&= #39;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 a= s part of the team that designed IP, TCP, and UDP, but abstracted as a prin= ciple of architecture. Please read the original paper carefully (and for go= odness' sake don't read any of the Wikipedia pages that claim to ex= plain the End-to-end principle or End=3Dto-end argument, as a primary sourc= e 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 cita= tions be *secondary* sources).=C2=A0=C2=A0https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf<= /a>

=C2=A0

#2: DNS se= rvice doesn't specify that "geolocation" is a function of the= DNS service. It is the job of the endpoint *after resolving the DNS name t= o one of many IP addresses* to decide which IP address to use for the DNS n= ame. That is, "geolocation" is an endpoint function, not somethin= g that the network does by spying on packet contents and faking a response = from real DNS servers.

=C2=A0

#4: In gen= eral, IP as a protocol underlying ALL of the Internet protocols is required= to deliver the content to the address specified by the sender, *without ei= ther reading or modifying the content*. There are certain cases where "= ;masquerading" as the destination is sometimes OK, but ONLY when the s= ender and receiver are specifically AWARE of this interception. This is cal= led a Man In The Middle *attack* otherwise.

=C2=A0

#5: As a s= pecial case, some IP addresses are "anycast", which has nothing t= o do with DNS itself as a protocol, but instead provides some low-level &qu= ot;neighborhood" addressing for a class of servers. Cloudflare uses 1.= 1.1.1, for example, as an "anycast" address supported by the glob= al 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 databas= e for short durations without problems, because the servers are "loose= ly" 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.

=C2=A0

#6: The id= ea that one can "identify" DNS requests by snooping on layer 2 pa= ckets is so crazy it is not even wrong. Layer 2 packets have layer 2 addres= ses (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.=C2=A0

=C2=A0

#7: The ge= neral idea that one should put more function into Starlink Satellites basic= ally will start to "fork" Starlink Enterprises (the Musk companie= s) as an "alternate Internet" where applications must use only th= e functions that Starlink supports (where other Internet providers may supp= ort broader standards or not support the special "Starlink-only" = functions). This is a way to balkanize the Internet, and maybe Musk who lov= es Monopoly Power after all because it makes him more Powerful, sees that a= s a great thing. Certainly the Chinese Communist Party is trying hard to ba= lkanize a Chinese-only Internet, spending a lot of money to block interoper= ability. Musk may envy China, I don't know.

If you wan= t a Balkanized, non-interoperable Internet, where the carriers feel free to= examine all the traffic and create their own, non-interoperable protocol s= et, I'd suggest China might be a good place to move. Or maybe Mars?

=C2=A0

Now what&#= 39;s a powerful idea in the Internet (so far) is that what prevents bad ide= as like this is that the Internet interprets such stupid ideas as damage, a= nd routes around them. But to route around them, the Internet has to be ove= rall, *interoperable*.=C2=A0

=C2=A0

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 transp= ort technologies too. But I daresay we who built the Internet will make it = very clear that anyone ought to "route around you" (including usi= ng you with a tunnal that you can't interfere with except by blocking a= ll communications).

=C2=A0

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

=C2=A0

= _______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
--00000000000058b90e05f97d70c2--