From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 0361A3CB41 for ; Mon, 17 Apr 2023 15:09:49 -0400 (EDT) Received: by mail-pg1-x536.google.com with SMTP id 191so8110788pga.12 for ; Mon, 17 Apr 2023 12:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681758589; x=1684350589; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aTL37ePv18emnKQW6TGCDy3f2AOZb6QRgkrgtv9wd/U=; b=Hw0cYrk+WWQR0zRxpzirkmn+eoCXqOpm7cD+1Sww6Yw3AJL3fxy2g9bWyTvKWeXC0y KLaN9Op4DrQSSqo/nh1tBddSH1OdnGDtCDQKtHxuts32yrP9mZICAbJRp1m29Ltoog// 3NV7vCZL7fGuagv4PQcnea8JMki1PxVI3xGcuVaGdy0P/8uJUBcsfOzQWlgYWH+aBxtq Hr+1fqDYZnR5uAlqPrwAzGKA22s8RJbq0sPv7AQN+3F8nFqqG/5bQ8MGKHQhXRaNFr/t xstOS6fMVRUSsZVHq3MlICI/GXhALgt23UqcaEmvL1SMc3SGRCvzz/IZ3nh6U+zjizpo Kdew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681758589; x=1684350589; 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=aTL37ePv18emnKQW6TGCDy3f2AOZb6QRgkrgtv9wd/U=; b=jOTC5AKsRYmT0kIHUjDfBjOqVTqOEO90B+k3plQpu/iMfq99UnD6SLkcAgGvyrwMld Cjq8OF/tE0udVct0oOhq5+KVBAO9Hk3N4oLOFO6vkhdaFp+moqPOhCFASLW7xGFewe1s EUuVJE2mrajuTIW3DjNfERXCX7k73l/Je6/7xwor4DpmsG+RGL4FbIaiwezdRMPJeEkh oJTvScQIT8k8tqZbu2mJXAsqLtSJOYMWm6+7frW7Njbm1c9bqHBy1Ag+tReBsi44qd21 GPtaZlq03ipGQ3SN1IgwrQVBRyW728ddpqcDhIXEQCJoDXLlHb+nVAGro2JsYpSZx4tX XhxQ== X-Gm-Message-State: AAQBX9dt6602rsbcpOWnJEFDp6WLeThtZyXO7ZZW1WjAfZ2vU0jPqLOz MHt7/5C5LsDsn8uE+j7yGM/7wS3yRF36OXtdmLdbCLXvpG8= X-Google-Smtp-Source: AKy350a6cZop6tZv5YmGJ+RLug4lpPOLKRQJ9hZJL6Ybo0IUJnazl5yVTJVIy/7Ww3OG1e99upqvKaNfhJJecEXFM+8= X-Received: by 2002:a63:f20d:0:b0:514:cc9:e013 with SMTP id v13-20020a63f20d000000b005140cc9e013mr3372040pgh.6.1681758588989; Mon, 17 Apr 2023 12:09:48 -0700 (PDT) MIME-Version: 1.0 References: <1681742080.86281676@apps.rackspace.com> In-Reply-To: <1681742080.86281676@apps.rackspace.com> From: Hesham ElBakoury Date: Mon, 17 Apr 2023 12:09:36 -0700 Message-ID: To: "David P. Reed" Cc: Dave Taht via Starlink Content-Type: multipart/alternative; boundary="0000000000004b74c505f98cefb2" 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 19:09:50 -0000 --0000000000004b74c505f98cefb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From 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 t= o support the end-to-end principle." Other researchers have different prrspective and they think there is a need to for a new e2e principle. Hesham On Mon, Apr 17, 2023, 7:34 AM David P. Reed via Starlink < starlink@lists.bufferbloat.net> 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. > > > > 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 ha= ve > nothing to do with any aspect of network technology that has changed in t= he > last 50 years. > > > > 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 yo= u > 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. > > > > The one thing that remains the same is that those who sell gear for > networks really want some kind of product differentiation beyond doing th= e > things they are supposed to do, well. And they are great at inventing > plausible sales-pitches. For example, Arista Networks has invented the ne= ed > for massively overbuffered Ethernet switches, and so has added bufferbloa= t > introduction to their sales pitch white papers. It's a cool feature to > support massive queueing delay as a "throughput enhancement", I understan= d. > I'm sure they can con(vince) a few customers that excessive buffering is > good because, well, because they are a hot startup. > > > > 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. > > > > 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. > > > > Such > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --0000000000004b74c505f98cefb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
From Saltzer perspective "The basis of the end-to-en= d principle is that the application knows best.=C2=A0 If the application ha= s the ability to tell an in-network service "Do X when you see my pack= ets=E2=80=9D that would seem to support the end-to-end principle."
Other researchers have different = prrspective and they think there is a need to for a new e2e principle.

Hesham


On Mon, Apr 17, 2023, 7:34 AM David P. Reed via Starlink <starlink@lists.bufferbloat.= net> wrote:

The idea that "special purpose" features should be interpos= ed or added to the basic packet transport mechanisms continues to provoke p= eople to suggest that it's time for the "end of" end-to-end a= rguments in the Internet.

=C2=A0

If one rea= ds the initial paper, the reasons for NOT including "end to end functi= ons" 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.

=C2=A0

So my answ= er 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 f= unctions beyond providing capacity and low latency into the packet and netw= ork transport interferes with evolvability. (unless you plan to throw out t= he entire infrastructure for every new application). This is pretty general= ly 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.

=C2=A0

The one th= ing that remains the same is that those who sell gear for networks really w= ant some kind of product differentiation beyond doing the things they are s= upposed to do, well. And they are great at inventing plausible sales-pitche= s. For example, Arista Networks has invented the need for massively overbuf= fered Ethernet switches, and so has added bufferbloat introduction to their= sales pitch white papers. It's a cool feature to support massive queue= ing delay as a "throughput enhancement", I understand. I'm su= re they can con(vince) a few customers that excessive buffering is good bec= ause, well, because they are a hot startup.

=C2=A0

The end-to= -end argument doesn't say that putting really clever technology into sw= itches, routers, or into a distributed system (adding "smarts" to= the core functionality) is a bad idea. It says don't put functions tha= t end-points (overlaid on the packet routing and transport) can implement q= uite well into the transport functionality.

=C2=A0

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.

=C2=A0

Such

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