From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 767B63B29E for ; Mon, 17 Apr 2023 10:34:41 -0400 (EDT) Received: from app43.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp7.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E76C54F1F for ; Mon, 17 Apr 2023 10:34:40 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app43.wa-webapps.iad3a (Postfix) with ESMTP id D31EF61058 for ; Mon, 17 Apr 2023 10:34:40 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 17 Apr 2023 10:34:40 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 17 Apr 2023 10:34:40 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20230417103440000000_81470" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1681742080.86281676@apps.rackspace.com> X-Mailer: webmail/19.0.22-RC X-Classification-ID: 56ee269e-1fe5-47f6-b792-72b53e7fa684-1-1 Subject: Re: [Starlink] IXPs in space, and the end-to-end argument 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 14:34:41 -0000 ------=_20230417103440000000_81470 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AThe idea that "special purpose" features should be interposed or added t= o the basic packet transport mechanisms continues to provoke people to sugg= est that it's time for the "end of" end-to-end arguments in the Internet.= =0A =0AIf one reads the initial paper, the reasons for NOT including "end t= o end functions" in the underlying transport are quite clearly laid out, an= d have nothing to do with any aspect of network technology that has changed= in the last 50 years.=0A =0ASo my answer is no.The primary sustaining reas= on is that the patterns of usage of the Internet continue to evolve, so bui= lding in ANY special, limited purpose functions beyond providing capacity a= nd low latency into the packet and network transport interferes with evolva= bility. (unless you plan to throw out the entire infrastructure for every n= ew application). This is pretty generally true, but I suppose if one is bui= lding one-time-use weaponry that blows itself up after a single standard us= e, evolvability doesn't matter.=0A =0AThe one thing that remains the same i= s that those who sell gear for networks really want some kind of product di= fferentiation beyond doing the things they are supposed to do, well. And th= ey are great at inventing plausible sales-pitches. For example, Arista Netw= orks has invented the need for massively overbuffered Ethernet switches, an= d so has added bufferbloat introduction to their sales pitch white papers. = It's a cool feature to support massive queueing delay as a "throughput enha= ncement", I understand. I'm sure they can con(vince) a few customers that e= xcessive buffering is good because, well, because they are a hot startup.= =0A =0AThe end-to-end argument doesn't say that putting really clever techn= ology into switches, routers, or into a distributed system (adding "smarts"= to the core functionality) is a bad idea. It says don't put functions that= end-points (overlaid on the packet routing and transport) can implement qu= ite well into the transport functionality.=0A =0ADNS lookup is a great exam= ple, actually. Why put it into satellite based routing and transport? It wo= rks fine, and it is currently ground based.=0A =0ASuch ------=_20230417103440000000_81470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The idea that "special= purpose" features should be interposed or added to the basic packet transp= ort mechanisms continues to provoke people to suggest that it's time for th= e "end of" end-to-end arguments in the Internet.

=0A

 

=0A

If one reads the initial paper, the reas= ons for NOT including "end to end functions" in the underlying transport ar= e quite clearly laid out, and have nothing to do with any aspect of network= technology that has changed in the last 50 years.

=0A

 

=0A

So my answer is no.The primary sustain= ing reason is that the patterns of usage of the Internet continue to evolve= , so building in ANY special, limited purpose functions beyond providing ca= pacity and low latency into the packet and network transport interferes wit= h evolvability. (unless you plan to throw out the entire infrastructure for= every new application). This is pretty generally true, but I suppose if on= e is building one-time-use weaponry that blows itself up after a single sta= ndard use, evolvability doesn't matter.

=0A

 =0A

The one thing that remains the same is that those= who sell gear for networks really want some kind of product differentiatio= n beyond doing the things they are supposed to do, well. And they are great= at inventing plausible sales-pitches. For example, Arista Networks has inv= ented the need for massively overbuffered Ethernet switches, and so has add= ed bufferbloat introduction to their sales pitch white papers. It's a cool = feature to support massive queueing delay as a "throughput enhancement", I = understand. I'm sure they can con(vince) a few customers that excessive buf= fering is good because, well, because they are a hot startup.

=0A

 

=0A

The end-to-end argument doe= sn't say that putting really clever technology into switches, routers, or i= nto a distributed system (adding "smarts" to the core functionality) is a b= ad idea. It says don't put functions that end-points (overlaid on the packe= t routing and transport) can implement quite well into the transport functi= onality.

=0A

 

=0A

DNS l= ookup is a great example, actually. Why put it into satellite based routing= and transport? It works fine, and it is currently ground based.

=0A

 

=0A

Such

 ------=_20230417103440000000_81470--