From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 498D43CB41 for ; Mon, 17 Apr 2023 16:09:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1681762156; i=moeller0@gmx.de; bh=ugVFIlqV1v73dYWqASscEp7xHi99SD7p7sCeTL49p3w=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=OSNkIqayJMO4EdXZJcRknSyHWaQ2S3WO72G2j24hvDXplaEgfQjMDfwwEl2PIBCfJ dyn4n+GZiL8OXCVkGih9aNHa0YwXYCt4l1IC77Z++t6EbtClfLxcUen84fXCAkcPJH vAGNVMcglqWRboiEDoEOWwbbdk6vrCyW5fQuy8izPKzwfgpJAopS0s+ibM8xlyo+NB CImYBuEYw4CVcR7qOgN19owv6X41OBF3c1YAYN3gd57AUaaoJctZJP7beebIlPatGQ 5G5VAUyOxvfc2jaBSMZC8yQRz6dLRHY0K/iIOtv0boDbocFakpo6nqIo9dbIroYqqf 3Blb+w+jP5mDw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([80.171.66.47]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MPog5-1q23fr2x1v-00MxC8; Mon, 17 Apr 2023 22:09:16 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 17 Apr 2023 22:09:15 +0200 Cc: "David P. Reed" , Dave Taht via Starlink Content-Transfer-Encoding: quoted-printable Message-Id: References: <1681742080.86281676@apps.rackspace.com> To: Hesham ElBakoury X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Provags-ID: V03:K1:GWIey1C3Xh139pk1UCVoOg+TYSN1OEjT940fdY+nunKaTiNTu4W /HaAQZQFZYmwB0E9mwqFpILmBAdQ1LaK5kTMLEnJgEBfKVMHJGTFMprWPPvZ8Me3acoP3V8 u7ywGHpcP7MDd5lEN7Ud8y/70s47yHVW5YEg4KF3GVmNfUNpGMhavdAPwfdpGLE1Tzt7fAF MduTlTwXhzoLDdQLrUULg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Q7IlbawBDvU=;qYYAT0IITYveySPrzDLsL15utzs NC3Dcpxhrhtz6sakpGf5Q+r4ci2i7J7MEiGhheuIZvvhYslkd0R9scvXZoKLTKzMU3hW05Ntt Btcb3cHs7LqtyoYH7+DFXtIWh+rtwOa6u+tzU+MAYaud48QXFCSqxjx/GKrPuR/8MhnLdoEaB a6ovi6fDmPPnJRaUUK5Zoo7isqjdzjkFK9T7ybaL3Kzfl3Id6G8HHsFYWzKUSkrwaLt0IQXEs Y+kU8CPAGgoHELH+kjYzYsg/UdOyej376IDm69ixfpLa8NboSJ8k+gbA72AzEgJ5w3lxYzSM3 JllhlMYvml3P1S0E5/bSR9Wk1zXnMaZmczcbE/xV+og8nimcZAkUJDH4XBFpD+1MDybkJZ9WQ DXaFcgJmqbFFBXDHzObdkMMCjHubgvKHUsRjBaIYJXULskINi/c7IhMZl2FtzX5yeXS1BCvpi j0MTp2QFxJFF+WmQaPlUJg1ObImWO8l+UyWtovLXw8y3QFaRbpYbWFW2XuvmRlWzaN4QODj6N WS9SplWoZtzp9OloKJkabEJ6SDEeSBh8htwIzpkQms4D1UvQTwrXJbF0lNG1MUakUoXdjfh0E EyGDlZMzQedv+OYBf5Rjz6Yj5fU1E5au69+AUcAp7pXPsnZrkePYAjCHuHlRv9u7kFPR25jaC XTyahJfdF96RSjGb2JLqYFAoMZSvtDRd5FDbYfjnHj5+Nob6ZMz3Vsx1xnSfEC/q3ZWTWUHzJ 5vfm5KfLmBU1udYkXB3NGjJWpU5Z5bsXoMu9o8bX7cs42ODfYQFehqBm1m/j8O+66mdly+kUk 2u/g/BPpREXsxadSnmA5bnyLwgYzoJaE/T4SFceQCWeyBMhLnsg2Lc5h5DjPfGrimOCCjEk4+ MKxzo7IuwmOrGQ2eED8ErKgJ/bRw6G6pz4GOgSeFnUyjqcvSjLRAZmml10IMKcBgI42Z+ga/B NaT1q7NPMKgX8kYGGYpCX+z1uvM= 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 20:09:20 -0000 > On Apr 17, 2023, at 21:09, Hesham ElBakoury via Starlink = wrote: >=20 > =46rom Saltzer perspective "The basis of the end-to-end principle is = that the application knows best. If the application has the ability to = tell an in-network service "Do X when you see my packets=E2=80=9D that = would seem to support the end-to-end principle." That seems to imply some sort of active opt-in.... this is as = far as I can tell not how GEO PEPs or docsis ACK-thinning was = introduced, instead the network simply forced these things onto = end-points/applications without even a structured way to opt out, no? > Other researchers have different prrspective and they think there is a = need to for a new e2e principle. What exactly is broken in the old one, requiring a fix?=20 >=20 > Hesham >=20 >=20 > On Mon, Apr 17, 2023, 7:34 AM David P. Reed via Starlink = wrote: > The idea that "special purpose" features should be interposed or added = to the basic packet transport mechanisms continues to provoke people to = suggest that it's time for the "end of" end-to-end arguments in the = Internet. > =20 > If one reads the initial paper, the reasons for NOT including "end to = end functions" in the underlying transport are quite clearly laid out, = and have nothing to do with any aspect of network technology that has = changed in the last 50 years. > =20 > So my answer is no.The primary sustaining reason is that the patterns = of usage of the Internet continue to evolve, so building in ANY special, = limited purpose functions beyond providing capacity and low latency into = the packet and network transport interferes with evolvability. (unless = you plan to throw out the entire infrastructure for every new = application). This is pretty generally true, but I suppose if one is = building one-time-use weaponry that blows itself up after a single = standard use, evolvability doesn't matter. > =20 > The one thing that remains the same is that those who sell gear for = networks really want some kind of product differentiation beyond doing = the things they are supposed to do, well. And they are great at = inventing plausible sales-pitches. For example, Arista Networks has = invented the need for massively overbuffered Ethernet switches, and so = has added 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 buffering is good because, well, because they are a hot = startup. > =20 > The end-to-end argument doesn't say that putting really clever = technology 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 quite well into the transport functionality. > =20 > DNS lookup is a great example, actually. Why put it into satellite = based routing and transport? It works fine, and it is currently ground = based. > =20 > Such > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink